Tout dirigeant finit par affronter 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. 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, parce que 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. Et elle sous-estime 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, tous les deux faux, débattus dans une réunion où c’est la voix la plus forte qui gagne.
Voici le cadre que nous utilisons avec nos clients, et avec les sociétés où notre propre participation est en jeu : ne demandez pas ce qui coûte le moins cher. Demandez ce qui capitalise.
Le logiciel loué se déprécie le jour où vous signez
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 de commodité, et les problèmes de commodité méritent des solutions de commodité. Les acheter n’est pas un compromis ; c’est de la discipline.
Mais remarquez ce que vous louez réellement : un flux de travail conçu pour la moyenne de tous leurs clients. Chaque trimestre où votre exploitation s’écarte de cette moyenne - une règle de tarification ici, un traitement d’exception là - vous payez une seconde redevance, invisible : la couche tableur. Exports, ressaisies, contournements, « le fichier que maintient Sanja ». Personne ne la budgète, et elle croît exactement en proportion de ce qui différencie votre activité.
Le loyer comporte des clauses cachées
La licence est la partie visible du prix. Les parties invisibles méritent d’être nommées, car ce sont elles qui font mal précisément au moment où vous pouvez le moins vous le permettre. La tarification au siège est un impôt sur la croissance- l’outil coûte le plus cher le trimestre où vous recrutez le plus. L’escalade tarifaire suit l’enfermement- les devis de renouvellement ont une fâcheuse tendance à doubler une fois que vos données, vos intégrations et les habitudes de vos équipes vivent à l’intérieur du produit. La feuille de route n’est pas la vôtre - 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, et votre seul recours est 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érite simplement une ligne dans le tableur de comparaison, et il ne l’obtient jamais.
Le logiciel possédé capitalise - à condition de construire les bonnes choses
Le logiciel sur mesure se comporte différemment au bilan et dans l’exploitation. Chaque flux de travail 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 capture vos données dans votre forme, ce qui fait passer l’intégration suivante d’un mois à une semaine. L’intégration fait entrer un nouveau flux de travail sous le même toit, ce qui fait apparaître le prochain candidat à 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 une pile louée et une plateforme possédée n’est pas une liste de fonctionnalités : c’est que l’une a accumulé votre savoir opérationnel pendant tout ce temps, et que 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 votre processus réel, et non sur un outil générique accompagné d’un dossier de documents de contournement. La due diligence, lors d’une cession ou d’une levée, va plus vite quand l’exploitation est lisible 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’une pile d’abonnements.
Construisez uniquement là où votre processus est le produit. Achetez partout où votre processus est le même que celui de tout le monde.
Le test tient en une question : si ce flux de travail était deux fois meilleur que le standard du secteur, vos clients le remarqueraient-ils ? Si oui - 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 - ce flux de travail est un actif qui capitalise et mérite un logiciel possédé. Si non, achetez la commodité et passez à autre chose.
Deux des quadrants méritent un commentaire. « Acheter, puis adapter » est l’endroit où la plupart des entreprises de taille intermédiaire devraient se tenir plus souvent qu’elles ne le font : gardez le socle de commodité et ne construisez 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. Et « acheter le meilleur » mérite d’être pris au pied de la lettre : pour les flux de travail de commodité, l’outil premium revient presque toujours moins cher que l’outil bon marché plus les frictions qu’il engendre.
L’arithmétique qui tranche vraiment
Quand le flux de travail passe le test, la décision de construire devient une question d’amortissement, et elle doit se calculer honnêtement : coût de développement pluscoût de fonctionnement, face aux heures supprimées, aux erreurs évitées et au chiffre d’affaires débloqué. Dans nos propres propositions, si cet amortissement dépasse douze mois, nous déconseillons de construire - et nous mettons cette recommandation par écrit.
Tenez ce compte avec de vrais chiffres, pas avec des espoirs. Côté coûts : le devis de développement, puis la maintenance - un ordre de grandeur raisonnable pour planifier est 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 flux de travail consomme aujourd’hui, le coût des erreurs qu’il produit et le chiffre d’affaires que débloquent des cycles plus courts. Si le côté 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 de commodité 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. Et construire la bonne chose avec le mauvais périmètre - une v1 qui tente de tout couvrir arrive en retard et atterrit 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. Vous avez besoin d’un responsable de votre côté de la table et d’un partenaire redevable du reste - de la même façon que 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é la question de la maintenance par écrit.
« Le sur-mesure finit toujours en legacy. »Le sur-mesure mal construit, oui. Comme tout outil SaaS que vous finissez par dépasser - sauf 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.
Comment la décision vieillit
Construire ou acheter n’est pas une décision qu’on prend une fois ; c’est un portefeuille qu’on rééquilibre. Un flux de travail qui relevait de la commodité il y a trois ans est peut-être devenu votre terrain de compétition - l’onboarding client fait souvent ce trajet - et une capacité que vous avez construite en 2019 est peut-être devenue une commodité 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 flux de travail est devenu une commodité 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 votre legacy parce qu’il a coûté cher autrefois. Le bilan se moque de ce que les choses ont coûté à apprendre ; il regarde ce qui capitalise à partir de maintenant.
Par où commencer
Faites l’inventaire de votre couche tableur. Chaque contournement est un vote - votre exploitation qui 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 de construire ou d’acheter se prend généralement toute seule. La liste sera plus longue que votre appétit, et c’est l’état sain : classez par amortissement, construisez en partant du haut, et laissez le retour mesuré de chaque projet financer la volonté de faire le suivant.
Et quand un développement franchit la barre, tenez-le au standard qui a justifié son dossier : une métrique nommée avant la première ligne de code, du logiciel qui fonctionne en semaines et non en trimestres, et un périmètre assez étroit pour être gênant. Le logiciel possédé ne capitalise que s’il est livré, 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.