Acheter un logiciel donne la parité. Seul ce que vous construisez vous distingue.

La question vient presque toujours de la table de la direction, et elle est enveloppée de coût : construire notre propre logiciel ou souscrire un SaaS qui existe déjà ? Formulée ainsi, la réponse ressemble à une feuille de calcul. Elle ne l'est pas. C'est une question sur l'endroit où vit votre avantage. Acheter un logiciel résout ce qui est commun et vous livre ce que le marché entier a déjà. Construire sur mesure est pour le noyau qui vous distingue. Ce qui est pareil ne vous place devant personne, et c'est par là que cette décision doit se lire avant de se lire par le prix.

Ce qui est vraiment en train d'être décidé

L'ingénieur Martin Fowler propose une division simple et utile. Il y a le logiciel utilitaire, dont tout le monde a besoin et qui n'a qu'à fonctionner, et il y a le logiciel stratégique, celui où la façon dont il remplit une fonction fait partie de ce qui le rend meilleur que la concurrence. La paie est l'exemple classique de l'utilitaire : personne ne gagne des clients en traitant les salaires de manière plus ingénieuse. Et c'est de là que sort la règle d'acheter ou de construire.

Since the definition of utility is that there's no differentiator, the obvious thing is to go with the package. [...] For a strategic function you don't want the same software as your competitors because that would cripple your ability to differentiate. Martin Fowler, Utility Vs Strategic Dichotomy, 2019

Ce n'est pas une idée isolée. Geoffrey Moore, dans Dealing with Darwin, sépare le core, ce qui crée la préférence d'achat, du context, tout ce qu'il faut faire pour se maintenir sur le marché mais qui ne distingue pas, et recommande de minimiser ou d'externaliser le context pour libérer les meilleures personnes pour le core. Gartner range le même instinct dans une architecture à trois couches : les systèmes d'enregistrement, qui durent une décennie et n'ont qu'à être justes ; les systèmes de différenciation, qui codent ce que l'entreprise fait différemment ; et les systèmes d'innovation, courts, pour tester de nouvelles opportunités. Trois langages, une conclusion : on achète l'enregistrement, on construit ce qui différencie.

Acheter vous donne la parité, et parfois c'est suffisant

Il convient de dire ce que le SaaS fait bien, car il le fait. Pour la comptabilité, le courrier électronique, le traitement des salaires ou un CRM en phase initiale, acheter est la décision correcte et presque toujours la moins chère. Il ne vaut pas la peine de construire ce dont la différence ne change rien pour le client. Mais il y a un prix qui n'est pas sur la facture, et il n'est pas financier. Quand vous souscrivez le même outil que celui que souscrivent les concurrents, vous héritez de la capacité et vous héritez aussi des limites. Le système a été conçu pour servir mille entreprises, non la vôtre, et la vôtre finit par mouler le processus sur l'outil. En context, c'est acceptable. En core, c'est livrer la différence à un fournisseur qui la vend à l'identique au voisin d'à côté.

Le prix affiché n'est pas le coût

La seconde erreur est de croire que le coût du SaaS est le chiffre de la grille. La dépense mondiale en applications SaaS devrait approcher les 300 milliards de dollars en 2025, au-dessus d'un peu plus de 250 milliards en 2024, selon Gartner. Ce n'est pas le volume du marché qui importe ici, c'est ce qu'il cache à l'intérieur de chaque entreprise qui compose ce total.

Trois coûts entrent rarement dans le calcul d'emblée. Le premier est que le prix monte. L'indice de Vertice, une plateforme qui aide les entreprises à négocier leurs achats de logiciels, a enregistré une hausse moyenne des prix du SaaS de l'ordre de 12% sur une période de douze mois, contre 6% en 2019. C'est une valeur avec un intérêt propre, et j'y reviens juste après, mais la direction est connue de qui renouvelle des contrats : la mensualité que vous avez souscrite n'est pas la mensualité que vous paierez dans trois ans.

Le second est que l'on paie pour ce que l'on n'utilise pas. Selon l'indice de gestion de SaaS de Zylo, les entreprises utilisent en moyenne environ la moitié, 49%, des licences qu'elles achètent, avec un gaspillage moyen de l'ordre de 18 millions de dollars par an en licences dormantes. Le troisième est structurel et c'est celui que l'on voit le moins : le SaaS est une dépense récurrente qui grandit avec chaque poste et avec chaque intégration, et qui continue de sortir du compte tous les mois tant que l'entreprise existe. Construire a un coût élevé d'emblée puis s'amortit. Acheter a un coût bas d'emblée puis se cumule, pour toujours.

La limite honnête de ces chiffres

Ici, il faut être rigoureux sur la force de cette preuve. Zylo vend de la gestion de SaaS et Vertice vend de la négociation de logiciels : les deux ont intérêt à ce que le gaspillage et l'inflation paraissent grands. L'échantillon de Zylo, ce sont des entreprises qui ont déjà engagé une gestion de SaaS, autrement dit celles qui avaient déjà un excès à maîtriser, et il penche vers les grandes organisations, ce qui tire la moyenne des 18 millions vers le haut. Le gaspillage de licences est une défaillance de gestion, non un défaut inhérent au modèle, et une hausse de prix annoncée n'est pas la hausse effectivement payée par qui négocie. Rien de tout cela ne prouve qu'acheter est mauvais. Cela prouve que le coût du SaaS n'est pas le chiffre de la grille, et que qui décide avec le chiffre de la grille décide avec une information incomplète.

L'économie que l'intelligence artificielle a changée

Il y a une raison nouvelle de rouvrir cette décision en 2026, et elle est du côté de construire. Le travail de routine du développement, le code répétitif, les tests, l'échafaudage que l'on monte avant de commencer la partie difficile, est devenu moins cher. Dans un essai contrôlé avec 95 programmeurs, le groupe ayant accès à GitHub Copilot a accompli une tâche 55,8% plus vite que le groupe sans l'outil.

The treatment group, with access to the AI pair programmer, completed the task 55.8% faster than the control group. Sida Peng, Eirini Kalliamvakou, Peter Cihon et Mert Demirer, The Impact of AI on Developer Productivity, 2023

La tâche consistait à construire un serveur HTTP en JavaScript, un exercice autonome et bien défini, exactement le type de travail qui remplit les premières semaines de tout projet. Si la moitié de ce travail devient plus rapide, le coût fixe de construire le noyau qui vous distingue baisse. Ce qui n'était rentable qu'à grande échelle devient rentable plus tôt. Voilà le changement concret : construire sur mesure a cessé d'être l'apanage de qui dispose d'une équipe de dizaines de personnes.

Ce que cela ne prouve pas

C'est la partie qui sépare un raisonnement d'un argument de vente, et c'est la partie qui va à l'encontre de l'enthousiasme facile. Le gain de 55,8% a été mesuré sur une tâche isolée, à partir de zéro, réalisée par des professionnels recrutés pour l'essai, dans une étude de GitHub elle-même. L'étude mesure la vitesse sur une tâche, elle ne mesure pas la qualité, la maintenance ni le résultat d'un produit. Et quand on mesure précisément l'autre cas, celui de travailler à l'intérieur d'un grand code qui existe déjà, le résultat s'inverse.

When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025

Dans cet essai de 2025, seize programmeurs expérimentés ont travaillé sur des dépôts qu'ils connaissaient depuis des années, sur 246 tâches réelles, et autoriser l'IA les a fait mettre 19% de temps en plus. La donnée la plus inconfortable n'est pas le ralentissement, c'est la perception. Ces mêmes programmeurs avaient prévu que l'IA les accélérerait de 24% et, après que l'expérience les eut ralentis, ils sont restés convaincus qu'elle les avait accélérés de 20%. L'outil donne une sensation de rapidité, et la sensation ne coïncide pas avec le chronomètre.

Et construire comporte un risque, même quand cela devient moins cher. Le CHAOS Report de 2020 du Standish Group classe 31% des projets comme réussis, 50% compromis par le délai ou le budget et 19% échoués. Le rapport lui-même est critiqué par des universitaires, qui relèvent que l'échantillon est propriétaire et que ses définitions, fondées uniquement sur la précision des estimations, biaisent les chiffres, et c'est pourquoi il se lit par la direction et non par la valeur exacte : construire à partir de zéro est un pari que l'on budgète avec une marge d'erreur, non une économie garantie. La conclusion honnête n'est pas de tout construire. C'est que l'IA a abaissé le coût de construire ce qui compte, et non la probabilité de se tromper quand on construit ce qui ne comptait pas.

Où se trouve la ligne, en pratique

Cela posé, la décision cesse d'être acheter ou construire et devient où tracer la ligne, entreprise par entreprise. La réponse pratique est hybride, et le test tient en une seule question : ce système code-t-il ce qui fait que l'on vous choisit vous ? Si la réponse est non, on achète. La comptabilité, le courrier, les salaires, le CRM tant que l'entreprise est petite, la visioconférence : c'est du context, et le context s'achète prêt à l'emploi et bon marché. Si la réponse est oui, on construit. Le moteur opérationnel que personne sur le marché ne fait comme vous, la logique de prix ou de logistique qui est votre avantage, le respect d'une règle spécifique à votre secteur qu'aucun paquet générique ne couvre sans vous obliger à être identique à tous : c'est du core, et le core ne se loue pas.

Il y a un signal qui décide beaucoup de ces lignes. Quand un paquet sur étagère vous oblige à changer votre processus pour y tenir, et que ce processus est précisément ce qui vous distingue, vous payez pour devenir identique à la concurrence. En context, se mouler sur l'outil est sensé et fait gagner du temps. En core, c'est acheter la parité que vous devriez éviter.

Ce qui reste au bilan

Au bout du compte, la différence entre acheter et construire est la différence entre une dépense et un actif. Le logiciel que vous achetez sort du compte tous les mois et n'est pas le vôtre : c'est une capacité louée, identique à celle que le concurrent loue à la porte d'à côté. Le logiciel qui code ce qui vous distingue reste, se capitalise et travaille pour vous une fois payé. Nous existons pour convertir la perception en actif financier, et l'architecture technologique qui soutient cette perception obéit à la même règle. Ce qui est pareil n'a pas d'autorité, et ce qui est pareil n'entre pas non plus au bilan comme valeur. Il y entre comme coût récurrent.

Sources

Chaque chiffre de cet article a été vérifié à la source primaire. Là où la source ne soutient pas la lecture courante, nous le disons dans le corps du texte.

1. Martin Fowler, Utility Vs Strategic Dichotomy, martinfowler.com, 2019. martinfowler.com/bliki/UtilityVsStrategicDichotomy.html
2. Geoffrey A. Moore, Dealing with Darwin (Portfolio, 2005), le modèle core vs context. en.wikipedia.org/wiki/Dealing_with_Darwin
3. Gartner, Pace-Layered Application Strategy (systèmes d'enregistrement, différenciation et innovation). gartner.com/en/documents/3297020
4. Gartner, prévision de dépense mondiale en SaaS (~250 milliards USD en 2024, ~300 milliards en 2025), via CIO Dive, 2024. ciodive.com/news/cloud-spend-growth-forecast-2025-gartner
5. Zylo, 2024 SaaS Management Index (utilisation moyenne de 49% ; ~18 millions USD de gaspillage moyen annuel). zylo.com/news/2024-saas-management-index
6. Vertice, SaaS Inflation Index (hausse moyenne ~12% sur douze mois, contre 6% en 2019), via CFO Dive, 2023. cfodive.com/news/saas-prices-jumped-vertice
7. Sida Peng, Eirini Kalliamvakou, Peter Cihon et Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv 2302.06590, 2023. arxiv.org/abs/2302.06590
8. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025. metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
9. The Standish Group, CHAOS Report 2020: Beyond Infinity (31% réussis, 50% compromis, 19% échoués), avec la critique d'Eveleens et Verhoef, IEEE Software, 2010. recension du rapport