Selon une enquête McKinsey, 32 % des organisations interrogées ont renoncé à acheter au moins un produit ou une fonctionnalité logicielle parce qu'elles pouvaient le construire en interne avec des outils de codage agentique. Autre chiffre : la part des grandes entreprises déployant des agents à l'échelle est passée de 27 % à 40 %, tandis que les structures plus petites stagnent à 22 %.
Nous avons rapporté mardi que la moitié du Fortune 500 privilégierait des modèles ouverts aux API. Voici le même mouvement appliqué au logiciel lui-même, et il touche un secteur entier.
Ce qui a changé dans le calcul
La décision entre construire et acheter reposait sur une asymétrie stable : développer un outil interne coûtait cher en temps de développeurs, l'acheter coûtait un abonnement. Pour tout ce qui n'était pas votre coeur de métier, acheter gagnait presque toujours.
Les outils de codage agentique déplacent ce point d'équilibre. Un outil interne simple — un tableau de bord, un connecteur, un formulaire métier — qui demandait trois semaines peut être prototypé en quelques jours.
Et surtout, l'argument décisif n'est souvent pas le coût mais l'ajustement. Un logiciel acheté impose ses concepts et ses champs ; un outil construit épouse votre manière de travailler. Cet écart justifiait rarement le coût de développement. Il le justifie plus souvent maintenant.
Un logiciel n'est pas terminé quand il fonctionne. Il faut le maintenir, corriger ses failles, l'adapter aux changements d'API, former les nouveaux arrivants, gérer le départ de celui qui l'a écrit. C'est cette charge qui rendait l'achat rationnel, et les outils agentiques ne la suppriment pas — ils accélèrent la construction, pas la maintenance. Le risque est donc réel : accumuler des dizaines d'outils internes que personne ne maintient et que personne ne comprend. On appelle cela une dette technique, et elle se paie toujours.
L'écart qui se creuse
Le second chiffre est peut-être plus important que le premier. Les grandes entreprises passent de 27 % à 40 % sur le déploiement d'agents à l'échelle ; les plus petites restent à 22 %.
C'est un écart qui s'accélère, et il contredit une idée répandue : celle selon laquelle l'IA favoriserait les petites structures agiles face aux grandes organisations lourdes.
La raison est simple et nous l'avons rencontrée plusieurs fois. Déployer des agents à l'échelle demande ce que nous décrivions comme de la traçabilité et des permissions vérifiables, une équipe de sécurité, une gouvernance des données, des budgets d'intégration. Le modèle est gratuit ; l'infrastructure autour ne l'est pas.
C'est cohérent avec ce que nous relevions à propos de l'absence de gains de productivité mesurés : ce qui manque n'est pas la capacité technique, c'est la réorganisation qui permet d'en tirer quelque chose. Et cette réorganisation coûte cher.
Ce que ça signifie pour les éditeurs
Un secteur entier est concerné : celui des logiciels dont la valeur tenait principalement au fait que les construire était fastidieux.
Ce qui résiste, ce sont les produits dont la valeur ne vient pas du code : ceux qui apportent des données que vous n'avez pas, un réseau d'utilisateurs, une conformité certifiée, ou une responsabilité contractuelle en cas de problème. C'est exactement la logique de Thomson Reuters construisant son propre modèle : la valeur est dans le corpus, pas dans le logiciel.
Ce qu'il faut retenir
La règle pratique qui se dégage est assez claire.
Construisez ce qui est spécifique à votre organisation, de petite taille, et que vous saurez maintenir. Achetez ce qui engage votre responsabilité, ce qui doit être certifié, et ce dont la valeur vient de données ou d'un réseau que vous n'avez pas.
Et méfiez-vous du moment où construire devient facile : c'est précisément là qu'on accumule ce qu'on ne saura pas entretenir. La question n'a jamais été « puis-je le faire », mais « qui s'en occupera dans deux ans ».