Tout dirigeant finit par croiser la question en réunion budgétaire : faut-il construire cela, ou l’acheter ? Cela ressemble à une comparaison de coûts. Ce n’en est presque jamais une, car le tableur qui met en regard un abonnement et un devis de développement compare deux objets de nature différente, une charge et un actif, comme s’il s’agissait de la même chose.
La comparaison échoue dans les deux sens. Elle sous-estime le coût de l’achat, puisque la licence est la seule ligne qui atterrit dans le tableur : les contournements, la colle d’intégration et les compromis de processus n’y figurent jamais. Elle sous-estime aussi la valeur du développement, parce qu’un actif qui s’améliore chaque trimestre n’entre pas dans une cellule conçue pour accueillir un prix d’abonnement. Deux chiffres faux, débattus dans une réunion où la voix la plus forte l’emporte.
Le cadre que nous appliquons chez nos clients, comme dans les sociétés où notre propre participation est en jeu, tient en un déplacement : la question n’est pas ce qui coûte le moins cher, mais ce qui capitalise.
Le logiciel loué se déprécie le jour de la signature
Un abonnement SaaS résout la version du jour de votre problème avec la version du jour de leur produit. C’est souvent exactement ce qu’il faut : la paie, la messagerie, un CRM pour un cycle de vente standard. Ce sont des problèmes standards, et des problèmes standards méritent des solutions standards. Les acheter n’est pas un compromis, c’est de la discipline.
Mais regardez ce que vous louez réellement : un processus conçu pour la moyenne de tous leurs clients. Chaque trimestre, l’exploitation s’écarte un peu plus de cette moyenne, une règle de tarification ici, un traitement d’exception là, et vous payez une seconde redevance, invisible : la couche tableur. Exports, ressaisies, contournements, « le fichier que maintient Sandrine ». Personne ne la budgète. Elle croît exactement en proportion de ce qui différencie votre activité.
Les clauses cachées du loyer
La licence est la partie visible du prix. Les parties invisibles méritent d’être nommées, car ce sont elles qui font mal au moment précis où vous pouvez le moins vous le permettre. La tarification par utilisateur est un impôt sur la croissance : l’outil coûte le plus cher le trimestre où vous recrutez le plus. La hausse des tarifs suit la dépendance au fournisseur ; les devis de renouvellement ont une fâcheuse tendance à doubler une fois que vos données, vos intégrations et les habitudes des équipes vivent à l’intérieur du produit. La feuille de route ne vous appartient pas, et la fonctionnalité dont dépend votre exploitation peut être dépréciée, repositionnée dans une offre supérieure, ou tout simplement jamais construite : le seul recours est alors un ticket de support.
Vient ensuite la gravité des données. Au bout de trois ans, le coût de sortie d’un outil SaaS profondément intégré dépasse souvent ce qu’aurait coûté la construction de la capacité au départ, non parce que le logiciel est bon, mais parce que le quitter suppose un export, une migration, une reformation et un trimestre de risque opérationnel. L’enfermement n’est pas un complot, c’est le modèle économique. Il mériterait une ligne dans le tableur de comparaison. Il ne l’obtient jamais.
Le logiciel possédé capitalise, à condition de construire les bonnes choses
Le logiciel sur mesure se comporte autrement, au bilan comme dans l’exploitation. Chaque processus qu’il absorbe, chaque intégration qu’il gagne, chaque exception qu’il apprend à traiter rend l’amélioration suivante moins chère. C’est cela, la capitalisation : le même mécanisme que les bénéfices réinvestis, appliqué à la connaissance des processus.
La boucle est concrète. Le système capte les données dans votre forme à vous, ce qui fait passer l’intégration suivante d’un mois à une semaine ; l’intégration fait entrer un nouveau processus sous le même toit, ce qui fait apparaître le candidat suivant à l’automatisation. Chaque incrément se pose sur le précédent au lieu de se poser à côté. Cinq ans plus tard, la différence entre un socle loué et une plateforme possédée n’est pas une liste de fonctionnalités : l’une a accumulé votre savoir opérationnel pendant tout ce temps, l’autre a accumulé la feuille de route de quelqu’un d’autre.
Les effets de second ordre sont sous-estimés. Les nouveaux arrivants se forment sur le processus réel de la maison, et non sur un outil générique accompagné d’un dossier de contournements documentés. La due diligence, lors d’une cession ou d’une levée, va plus vite quand l’exploitation se lit dans un seul système : les acquéreurs paient pour des opérations qu’ils peuvent lire. Et le logiciel lui-même est un actif qui a une valeur, ce qu’on ne peut pas dire d’un empilement d’abonnements.
Construire seulement là où le processus est le produit. Acheter partout où il est le même que chez tout le monde.
Le test tient en une question : si ce processus était deux fois meilleur que le standard du secteur, vos clients le remarqueraient-ils ? Si la réponse est oui, et c’est le cas pour la vitesse de cotation chez un transporteur, le délai de traitement d’un sinistre chez un assureur, l’expérience d’admission dans un groupe de cliniques, alors ce processus est un actif qui capitalise et mérite un logiciel possédé. Si la réponse est non, achetez le standard et passez à autre chose.
Deux quadrants méritent un commentaire. « Acheter, puis adapter » est la case où les entreprises de taille intermédiaire devraient se tenir bien plus souvent qu’elles ne le font : garder le socle standard et ne construire que la fine couche qui encode ce qui vous distingue, le moteur de tarification par-dessus le CRM standard, le traitement des exceptions par-dessus l’ERP standard. Quant à « acheter le meilleur », la formule se prend au pied de la lettre : sur un processus standard, l’outil premium revient presque toujours moins cher que l’outil bon marché augmenté des frictions qu’il engendre.
L’arithmétique qui tranche vraiment
Quand le processus passe le test, la décision de construire devient une question de délai d’amortissement, et ce délai se calcule honnêtement : coût de développement plus coût de fonctionnement, face aux heures supprimées, aux erreurs évitées et au chiffre d’affaires débloqué. Dans nos propres propositions, s’il dépasse douze mois, nous déconseillons de construire. Et nous mettons cette recommandation par écrit.
Tenez ce compte avec de vrais chiffres plutôt qu’avec des espoirs. Côté coûts : le devis de développement, puis la maintenance, dont un ordre de grandeur raisonnable se situe de 15 à 20 % du coût de développement par an, plus l’hébergement et le temps interne nécessaire pour en assumer la propriété. Côté retour : les heures pleinement chargées que le processus consomme aujourd’hui, le coût des erreurs qu’il produit, le chiffre d’affaires que débloquent des cycles plus courts. Si le retour repose surtout sur une ligne molle de « valeur stratégique » et que les chiffres durs ne portent pas le dossier, c’est le calcul qui vous dit d’acheter.
Trois modes d’échec à éviter. Construire du logiciel standard par orgueil : « nous sommes différents » n’est pas vrai pour la paie, et le développement se retrouvera à concurrencer des produits qui ont mille personnes d’avance. Acheter du logiciel différenciant par impatience : l’abonnement démarre vite, puis la couche tableur pousse autour de lui jusqu’à ce que l’avantage de vitesse ait disparu. Construire la bonne chose avec le mauvais périmètre, enfin : une v1 qui tente de tout couvrir arrive en retard, sur une exploitation qui a déjà cessé d’y croire. Une v1 doit être d’une étroitesse gênante et réellement utilisée.
Les objections courantes, traitées honnêtement
« Nous ne sommes pas une entreprise de logiciel. » Vous n’avez pas besoin de l’être. Il vous faut un responsable de votre côté de la table et un partenaire redevable du reste, exactement comme vous possédez un immeuble sans être une entreprise de construction. Ce qu’il ne faut pas faire, c’est construire sans avoir réglé par écrit la question de la maintenance.
« Le sur-mesure finit en système vieillissant. » Le sur-mesure mal construit, oui. Comme tout outil SaaS que vous finissez par dépasser, à ceci près qu’un éditeur, cela ne se refactorise pas. Un logiciel bâti sur des technologies ennuyeuses et répandues, documenté et couvert par des tests, reste maintenable pendant une décennie. C’est un critère de choix de prestataire, pas un argument contre la propriété.
« Et si l’éditeur sortait notre fonctionnalité l’an prochain ? » Alors votre outil loué s’améliore, pour vous et pour tous les concurrents qui le louent le même après-midi. Les fonctionnalités que sort un éditeur sont, par définition, celles qui ne vous différencient pas. La capacité qui pousse les clients à vous choisir est précisément celle que vous ne pouvez pas attendre.
Le vieillissement de la décision
Construire ou acheter n’est pas une décision qu’on prend une fois : c’est un portefeuille qu’on rééquilibre. Un processus qui relevait du standard il y a trois ans est peut-être devenu votre terrain de compétition, c’est souvent le cas de l’onboarding client, et une capacité construite en 2019 est peut-être devenue un standard que trois éditeurs vendent mieux que vous. Donnez à ce portefeuille une cadence annuelle : pour chaque système possédé, demandez s’il passe toujours le test de capitalisation ; pour chaque abonnement significatif, demandez ce que coûte désormais la couche tableur qui l’entoure.
Soyez aussi prêt à retirer un logiciel possédé qu’à en construire un. Éteindre un outil sur mesure dont le processus s’est banalisé n’est pas un aveu d’échec : c’est le portefeuille qui fonctionne. Le vrai mode d’échec est l’inertie, dans un sens comme dans l’autre, louer ce qui vous différencie parce que construire fait peur, ou entretenir vos systèmes hérités parce qu’ils ont coûté cher autrefois. Le bilan se moque de ce que les choses ont coûté à apprendre ; il regarde ce qui capitalise à partir d’aujourd’hui.
Par où commencer
Faites l’inventaire de votre couche tableur. Chaque contournement est un vote : l’exploitation vous indique où elle a déjà dépassé ses outils loués. Chiffrez ces heures honnêtement, appliquez le test de capitalisation, et la décision se prend généralement toute seule. La liste sera plus longue que votre appétit, et c’est l’état sain : classez par délai d’amortissement, construisez en partant du haut, et laissez le retour mesuré de chaque projet financer la volonté de faire le suivant.
Et quand un projet franchit la barre, tenez-le au standard qui a justifié son dossier : un indicateur nommé avant la première ligne de code, du logiciel qui tourne en semaines et non en trimestres, un périmètre assez étroit pour être gênant. Le logiciel possédé ne capitalise que s’il arrive en production, qu’il est utilisé et qu’il continue d’absorber l’exploitation autour de lui. Cette partie-là n’est pas une question de stratégie. C’est une question d’exécution.