La tentation est forte pour un éditeur logiciel d'accepter des développements spécifiques pour séduire un client. C'est souvent une erreur stratégique majeure qui dilue le produit, alourdit la maintenance et détruit la scalabilité du modèle.
Il existe deux modèles économiques fondamentalement différents dans le logiciel : l'éditeur de logiciel (qui vend le même produit à de nombreux clients) et la société de services (qui développe des solutions sur mesure pour chaque client). Ces deux modèles ont des économies, des organisations et des cultures radicalement opposées. Le problème survient quand un éditeur commence à dériver vers le spécifique pour satisfaire un client — souvent avec les meilleures intentions du monde.
La logique de l'éditeur
L'éditeur construit une fois, vend plusieurs fois. Sa valeur vient de l'effet d'échelle : chaque client supplémentaire génère du revenu marginal sans coût marginal proportionnel. Le produit s'améliore pour tous au même rythme. La roadmap est pilotée par les besoins communs de la base installée, pas par les demandes d'un seul client. C'est un modèle qui demande une discipline rigoureuse : dire non aux demandes qui ne s'appliquent qu'à un cas particulier.
La tentation du spécifique
Un grand client arrive, intéressé par le produit, mais avec des besoins particuliers. Il est prêt à payer pour des développements sur mesure. La proposition semble gagnant-gagnant : le client obtient ce qu'il veut, l'éditeur finance son développement. En réalité :
- Le code spécifique doit être maintenu en parallèle du produit standard — pour toujours
- Les mises à jour du produit doivent être requalifiées sur la version spécifique
- L'équipe passe du temps sur un seul client au lieu d'améliorer le produit pour tous
- La roadmap devient otage des demandes de ce client particulier
- Si le client résilie, tout ce travail n'a servi personne d'autre
Produit et services peuvent coexister — à condition de maintenir une séparation stricte.
Quand le spécifique se justifie
Il existe des cas légitimes : le connecteur vers un système tiers que d'autres clients utilisent aussi (il devient générique), la fonctionnalité pilotée par un client précurseur qui anticipe un besoin marché, ou le projet de services clairement séparé du produit, avec une équipe dédiée et une facturation transparente. La règle d'or : si vous ne pouvez pas le vendre à trois clients différents, ce n'est pas une feature produit, c'est une prestation de service.
L'organisation qui protège le produit
Les éditeurs matures séparent clairement les équipes : une équipe produit qui construit le core, une équipe services qui gère les spécifiques et les intégrations. Les revenus services financent parfois le produit — mais les deux activités restent étanches. Sans cette séparation, le produit finit par ressembler à une collection de cas particuliers, impossible à maintenir et impossible à vendre simplement.