Un prestataire de développement qui vous dit d’acheter une solution existante perd une vente. C’est pourtant le conseil que nous donnons dans la majorité des cas, et il y a une raison simple à cela : un logiciel sur mesure construit sans nécessité devient une charge que vous porterez pendant des années.
La question ne se tranche pas sur le prix d’achat. Un abonnement à 200 francs par mois coûte 12 000 francs sur cinq ans, soit l’ordre de grandeur d’un petit développement — et il ne demande ni maintenance, ni reprise, ni documentation. Le calcul naïf est presque toujours favorable au marché.
Ce qui fait basculer, ce n’est pas l’argent. C’est la distance entre votre façon de travailler et celle que le logiciel impose.
1. La question à poser en premier
Un logiciel du marché encode une manière de faire. Quand vous l’adoptez, vous adoptez aussi cette manière de faire, et c’est très souvent une bonne affaire : l’éditeur a vu mille entreprises, vous en avez vu une.
Le problème apparaît quand votre façon de faire n’est pas une mauvaise habitude à corriger, mais précisément ce qui vous distingue. Dans ce cas, plier votre processus à l’outil revient à effacer votre avantage pour économiser une licence.
Figure 1. Deux natures de spécificité
La même phrase — « notre processus est particulier » — recouvre deux situations opposées.
Le processus est particulier parce qu’il s’est sédimenté, qu’une personne l’a conçu il y a dix ans, ou qu’un ancien outil l’imposait. Personne ne le défendrait s’il fallait le justifier.
Le processus est particulier parce qu’il produit un résultat que vos concurrents n’obtiennent pas. Vos clients le remarquent, même sans savoir le nommer.
Le test pratique : demandez à trois personnes qui exécutent le processus pourquoi il se fait ainsi. Si les réponses divergent ou remontent à une contrainte disparue, la spécificité est subie.
2. Les quatre cas où le sur mesure se justifie
En dehors de ces quatre situations, notre conseil est d’acheter. Et si aucune ne s’applique mais que l’outil du marché ne couvre pas tout, la bonne réponse est souvent une troisième voie : acheter le socle, et n’automatiser sur mesure que le raccord manquant.
Le processus est votre avantage
Il produit un résultat que le marché n’obtient pas, et l’outil disponible vous forcerait à y renoncer. C’est le seul cas vraiment stratégique des quatre.
L’addition des licences dépasse le coût de construction
Arrive quand le nombre d’utilisateurs est élevé, ou quand l’éditeur facture à l’usage sur un volume qui croît. Le calcul se fait sur cinq ans, maintenance comprise, sinon il ment.
Aucun outil ne couvre le périmètre sans contorsion
Non pas « aucun outil n’est parfait », mais : il en faudrait trois, mal raccordés, avec des ressaisies entre eux. Le coût caché est dans les raccords, pas dans les licences.
Une contrainte réglementaire ou de souveraineté l’impose
Hébergement en Suisse exigé par un client, données qui ne peuvent pas sortir d’un périmètre, exigence sectorielle. Rare, mais alors dirimant.
Trois mauvaises raisons de construire
- L’outil du marché est « moche ». L’ergonomie se supporte ; une dette logicielle de cinq ans, beaucoup moins.
- Il manque une fonction. Vérifiez d’abord si elle existe dans la feuille de route de l’éditeur, ou si une intégration la couvre. Construire un logiciel entier pour une fonction est un mauvais échange.
- Pour ne pas dépendre d’un éditeur. Vous dépendrez alors de votre prestataire, ou de la seule personne qui connaît le code. Ce n’est pas moins risqué, c’est différemment risqué.
3. Ce qu’il faut exiger si vous construisez
La décision prise, quatre garanties déterminent si vous possédez réellement l’outil ou si vous avez seulement changé de dépendance. Elles se négocient avant, jamais après.
- Le code et les données vous appartiennent, et vous en avez une copie utilisable sans votre prestataire.
- Les technologies sont courantes. Un choix exotique divise par dix le nombre de personnes capables de reprendre le projet.
- La première version est étroite mais réellement en production. Un pilote qui ne sort jamais de la salle de réunion n’apprend rien.
- Une enveloppe d’entretien est budgétée dès la première année. Un logiciel sans maintenance se dégrade en dix-huit mois, quel que soit son auteur.
Note méthodologique
Cet article expose une grille de décision issue de la pratique de cadrage de Flowera, et non les résultats d’une étude. L’exemple de calcul de l’introduction est une illustration arithmétique à partir d’un abonnement hypothétique, pas un tarif observé. Les seuils évoqués — cinq ans d’horizon, dix-huit mois de dégradation — sont des ordres de grandeur de terrain, donnés pour fixer les idées et non comme des mesures. Flowera développe des logiciels sur mesure : ce texte recommande majoritairement de ne pas y recourir, ce qui va contre son intérêt commercial immédiat, et nous préférons le signaler plutôt que de le laisser deviner.
Conclusion
Le sur mesure n’est pas un niveau supérieur d’ambition. C’est un choix qui se paie en maintenance, en documentation et en dépendance à ceux qui connaissent le code. Quand il est justifié, il n’a pas d’équivalent. Quand il ne l’est pas, il transforme un problème réglé en chantier permanent.
La bonne question n’est donc jamais « peut-on le développer ». On peut presque toujours. Elle est : « ce que nous faisons différemment mérite-t-il d’être protégé, ou serait-il mieux remplacé ? »
Et la réponse la plus fréquente, dans les PME que nous accompagnons, est un mélange : acheter le socle, construire le raccord. C’est moins spectaculaire qu’un logiciel maison, et c’est presque toujours ce qui tient le mieux dans le temps.
Sources
- Grille de décision et ordres de grandeur issus de la pratique de cadrage de Flowera. Aucun chiffre de cet article ne constitue un résultat mesuré chez un client ni un tarif publié.
Votre spécificité est-elle subie ou choisie ?
Nous passons la grille avec vous, processus par processus, et nous vous disons honnêtement lesquels méritent du sur mesure. Y compris quand la réponse est « aucun ».
Voir l’offre développement