Trente-deux pour cent des organisations ont décidé de ne pas acheter au moins un produit ou une fonctionnalité logicielle parce qu'elles pouvaient le construire en interne avec des outils de codage agentiques (McKinsey, 2026). Ce n'est pas une prévision sur les achats. C'est déjà arrivé, pendant le dernier cycle budgétaire.
La ligne build-vs-buy a bougé, et elle a bougé en silence — aucun fournisseur ne l'a annoncé, personne n'a présenté de business case au conseil. Quelqu'un a ouvert un e-mail de renouvellement, regardé le prix, regardé un agent de codage, et refusé.
Voici la partie qui devrait faire ralentir un Head of Operations avant la clôture des renouvellements du T4. Dans la même enquête, les organisations les plus avancées dans cette substitution — les AI high performers de McKinsey, dont près de la moitié ont évité un achat de cette manière contre 31 pour cent de tous les autres — déclarent être contraintes par les coûts dans leur usage des agents de codage environ trois fois plus souvent que les autres répondants (McKinsey, 2026). La cohorte la plus expérimentée en matière de « construire plutôt qu'acheter » est celle qui a trouvé le plafond en premier.
Cet ordre compte plus que le chiffre d'ouverture.
Ce que dit réellement l'enquête
Le dixième State of AI annuel de McKinsey a été publié le 25 août 2026, administré du 4 mai au 8 juin, avec 1 719 répondants dans 97 pays, pondérés par la contribution de chaque pays au PIB mondial. Trente-six pour cent des répondants travaillent dans des organisations dépassant le milliard de dollars de chiffre d'affaires annuel.
Une mise en garde à poser tout de suite, car elle détermine si tout ceci vous concerne : McKinsey découpe les données par chiffre d'affaires, pas par effectif. « Organisations plus petites » dans cette enquête signifie moins d'un milliard de dollars de revenus, ce qui inclut des entreprises bien au-delà de la tranche 50–500 ETP. Lisez la direction des résultats ; n'y projetez pas votre propre organigramme.
Cela dit, trois constats s'emboîtent.
La substitution est réelle et concentrée. Trente-deux pour cent au global, plus fréquente dans la technologie et la santé, puis dans les services professionnels et l'énergie et les matériaux. Près de la moitié chez les high performers.
Le plafond est réel et il tombe sur les mêmes outils. Environ 20 pour cent de l'ensemble des répondants déclarent que les coûts opérationnels liés à l'IA, y compris les coûts de tokens, ont contraint leur usage de l'IA. Pour les agents de codage spécifiquement, les high performers rencontrent cette contrainte environ trois fois plus souvent que les autres — et ils ne sont pas contraints de façon disproportionnée sur les coûts des autres types d'outils. Le frottement est spécifique à ce vers quoi ils se sont substitués.
La capacité n'est pas répartie uniformément. Les organisations au-dessus du milliard de dollars de revenus sont passées de 27 pour cent à 40 pour cent pour le passage à l'échelle d'agents IA dans au moins une fonction, d'une année sur l'autre. Les organisations plus petites sont restées essentiellement stables à 22 pour cent. Environ deux répondants sur dix déclarent avoir mis à l'échelle des agents de codage, contre 31 pour cent dans les grandes entreprises.
Donc les entreprises les mieux placées pour remplacer du logiciel par des agents sont aussi celles qui en paient déjà le privilège. Et les entreprises les plus tentées par l'arithmétique — celles dont la facture SaaS fait le plus mal — sont les moins susceptibles d'avoir mis un agent à l'échelle.
Pourquoi l'échange paraît bon marché en septembre
L'attrait n'est pas imaginaire, et ce n'est pas du battage de fournisseur. Les prix du logiciel montent plus vite que presque tout le reste de votre compte de résultat.
L'indice de Vertice a mesuré une inflation SaaS de 12,1 pour cent en avril 2026, 14,2 pour cent en mai et 16,4 pour cent en juin — un nouveau record, dépassant le précédent pic de 14,7 pour cent de novembre 2025, et la plus rapide accélération sur deux mois jamais enregistrée (Vertice, 2026). Vertice la situe à près de cinq fois le taux général d'inflation. Le même indice signale aussi une shrinkflation qui l'accompagne : prix catalogue en hausse tandis que l'accès aux fonctionnalités au même palier se réduit discrètement.
Asseyez-vous en réunion de renouvellement avec ce chiffre et un agent de codage qui fonctionne, et l'échange paraît évident. Une hausse de 16 pour cent sur un outil utilisé par trois personnes, contre une construction livrable en quinze jours.
Le problème, c'est que la comparaison qui est faite n'est pas la comparaison qui est achetée.
Ce qui se transfère réellement dans un échange construire-au-lieu-d'acheter
Un contrat SaaS est un engagement fixe, supporté, maintenu à l'extérieur, avec une date de renouvellement connue. Ce qui le remplace, ce sont trois choses distinctes, dont une seule apparaît dans le business case.
Une facture de tokens variable. La licence était prévisible ; l'inférence est facturée à l'usage et croît avec l'utilisation, les reprises, et tout ce qu'un agent décide de lire. C'est précisément la ligne sur laquelle les high performers de McKinsey déclarent buter.
Un propriétaire interne permanent de la maintenance. Pas celui qui l'a construit. Celui qui le tient en 2028, quand l'API qu'il appelle change et que le seul ingénieur qui le comprenait est parti.
Les caractéristiques de maintenabilité du code écrit par des agents, mesurablement moins bonnes que celles du code qu'il remplace.
Le propriétaire de la maintenance que personne ne nomme
L'étude Maintainability Gap de GitClear a analysé 623 millions de modifications de code entre 2023 et 2026 et a trouvé les signaux de qualité évoluant tous dans le mauvais sens en même temps : duplication de blocs de code +81 pour cent, copier/coller au sein d'un même commit +41 pour cent, constructions masquant les erreurs +47 pour cent, churn à deux semaines +15 pour cent — tandis que les lignes déplacées par refactoring ont chuté de 70 pour cent, les appels de fonction inter-fichiers (le signal de réutilisation) de 35 pour cent, et la maintenance du code legacy de long terme de 74 pour cent par rapport aux niveaux de 2022 (GitClear, 2026).
Leur formule pour ce que cela produit est la bonne : des composants en V1 perpétuelle. Du code qui part en production et n'est jamais consolidé, parce que personne ne refactorise ce qu'un agent peut régénérer.
Le programme DORA de Google arrive au même endroit par un autre chemin. Sur environ 5 000 répondants, l'adoption de l'IA chez les développeurs est passée de 76 pour cent à 90 pour cent, et le débit de livraison assisté par IA est revenu à neutre ou mieux — mais l'instabilité de livraison a persisté comme coût de l'adoption, et la lecture que DORA fait de l'IA est celle d'un amplificateur du système organisationnel dans lequel elle atterrit (DORA, 2025). L'édition de l'année précédente avait mesuré une baisse de 7,2 pour cent de la stabilité de livraison pour chaque hausse de 25 pour cent de l'adoption de l'IA (TechTarget, 2025).
Amplificateur est le mot à retenir. Une entreprise de 300 ETP avec un seul développeur interne surchargé et aucun pipeline de déploiement n'acquiert pas la discipline d'un éditeur de logiciels en générant un remplaçant de son produit. Elle acquiert sa propre discipline, plus vite.
La cohorte la plus avancée a trouvé le plafond en premier
La plupart des débats technologiques portent sur la question de savoir si les sceptiques auront raison plus tard. Celui-ci a déjà fait tourner l'expérience, et le résultat se trouve dans le même jeu de données que l'enthousiasme.
Les organisations qui ont substitué le plus agressivement sont celles qui déclarent aujourd'hui des contraintes de coûts sur les agents de codage trois fois plus souvent que toutes les autres (McKinsey, 2026). Pas des contraintes de coûts en général — celles-là, elles les déclarent à des taux normaux. Spécifiquement sur la classe d'outils vers laquelle elles ont basculé.
Voilà à quoi ressemble un plafond quand on le découvre de l'intérieur. Vous remplacez une ligne fixe par une ligne variable, l'usage croît parce que la chose est utile, et la ligne variable cesse d'être plus petite que celle que vous avez annulée.
Pour un opérateur du mid-market, la conclusion n'est pas « ne construisez pas ». C'est que la courbe de coûts qu'on vous montre au moment de la décision en est le premier mois.
Le contre-argument honnête
Trois limites, dites franchement.
Des données d'enquête auto-déclarées ne sont pas un audit. Les chiffres de McKinsey sont ce que les répondants disent de leur propre organisation. Personne n'a rapproché la construction interne revendiquée d'un grand livre comptable, et « décidé de ne pas acheter » inclut des décisions qui n'auraient de toute façon jamais abouti.
La construction l'emporte réellement dans un ensemble de cas définissables. Là où le workflow est spécifique à votre entreprise, là où aucun fournisseur ne convient sans configuration lourde, là où la chose est petite, stable et lit dans des systèmes que vous possédez déjà — construire a toujours été défendable, et les agents abaissent le seuil à partir duquel ça le devient. Les 32 pour cent ne sont pas uniformément une erreur.
Une année de données qualité n'est pas un verdict sur une décennie. GitClear mesure à quoi ressemble aujourd'hui l'écriture de code assistée par IA, alors que l'outillage et les pratiques sont l'un et l'autre immatures. Ces signaux pourraient s'améliorer. Ils ne l'ont pas encore fait.
Ce que rien de tout cela ne change : l'échange convertit le problème de bilan d'un fournisseur en le vôtre. C'est un transfert, pas une économie, sauf si vous valorisez le transfert.
Quels renouvellements rendent l'échange défendable
Quatre mouvements avant la clôture du T4. Aucun ne nécessite un nouveau fournisseur, et aucun n'exige d'abandonner le dossier de construction.
- Chiffrez la ligne tokens sur douze mois d'usage en croissance, pas sur le volume du pilote. Si le remplaçant n'est moins cher qu'au volume d'appels d'aujourd'hui, vous n'avez pas trouvé une économie — vous avez trouvé un décalage. Modélisez-le à trois fois l'usage actuel et voyez si la décision tient.
- Nommez le propriétaire de la maintenance avant d'annuler le contrat. Un nom, un pourcentage de son temps, et un successeur. Si personne ne veut mettre un chiffre, la construction est financée par des effectifs non alloués, c'est-à-dire par les soirées de quelqu'un.
- Classez les renouvellements selon qui absorbe la panne. Tout ce qui touche la paie, la conformité, la facturation client ou des données réglementées garde un fournisseur avec SLA et garantie. Le reporting interne, la glu entre des systèmes que vous possédez déjà et les outils de workflow d'une seule équipe : c'est là que le dossier de construction est honnête.
- Traitez un devis de renouvellement à 16 pour cent comme un signal de négociation, pas comme un verdict. Une inflation SaaS à près de cinq fois l'inflation générale signifie que la hausse proposée est dictée par le marché et souvent négociable. Faire le benchmark d'un renouvellement coûte moins cher que de posséder une base de code, et vous pouvez le faire ce mois-ci.
Une licence que vous annulez est un coût que vous cessez de payer. Un système que vous construisez est un coût dont vous devenez propriétaire — et les organisations les plus avancées sur cette route vous disent, dans l'enquête même qui a rendu l'échange attirant, exactement où il cesse d'être bon marché.
Avant que le prochain renouvellement ne parte, prenez un outil promis au couperet et écrivez qui maintient son remplaçant en 2028. Si la ligne reste vide, renouvelez.
