Un tiers des entreprises a renoncé à acheter un logiciel : le coût de possession que personne n'a chiffré
Près d'un tiers des organisations, 32 % exactement, déclarent avoir renoncé à acheter au moins un produit ou une fonctionnalité logicielle parce qu'elles pouvaient le construire en interne avec des agents codeurs. Le chiffre vient de l'édition 2026 de l'enquête mondiale State of AI de McKinsey, publiée le 25 août 2026, menée du 4 mai au 8 juin auprès de 1 719 répondants dans 97 pays. La même enquête mesure une accélération cohérente chez les grandes entreprises : la part de celles qui passent des agents à l'échelle dans au moins une fonction est montée de 27 % à 40 % en un an, pendant que les organisations plus petites restent à 22 %.
Le réflexe, devant ce chiffre, consiste à se demander si l'on saurait construire aussi. La question est déjà tranchée dans un tiers des cas, et l'enquête contient une indication plus utile. Les entreprises que McKinsey classe en haut du panier, celles qui attribuent au moins 5 % de leur EBIT à l'IA et ne représentent que 6 % des répondants, sont aussi celles qui renoncent le plus à acheter, près d'une sur deux contre 31 % pour les autres. Ce sont également celles qui déclarent, environ trois fois plus souvent que les autres, que leurs coûts d'exploitation limitent leur usage des agents codeurs. Le groupe qui construit le mieux est donc le premier à toucher le plafond de la facture.
L'article du 27 juillet sur l'arbitrage agentique regardait ce basculement du côté du marché, celui des 234 milliards de dollars de dépenses SaaS dont le modèle de prix ne tient plus. Ce qui suit se place à l'autre bout, du côté du bilan de l'acheteur qui vient de dire non. Une licence annulée est une ligne de dépense qui disparaît, et une dizaine de lignes qui apparaissent ailleurs, réparties sur des budgets que personne n'a consolidés avant la décision.

Ce que l'enquête dit, et ce qu'elle ne dit pas
Il faut lire le chiffre avec précision, parce qu'il est facile de lui faire dire plus qu'il ne dit. Les 32 % désignent une décision de ne pas acheter, pas un système livré, ni un système en production, ni un système qui a remplacé le produit écarté. C'est un arbitrage d'achat, mesuré au moment où il est pris, et l'enquête n'observe pas ce qu'il devient ensuite.
La répartition sectorielle suit la maturité de la fonction engineering. McKinsey place en tête la technologie et la santé, suivies des services professionnels et de l'énergie et des matériaux. Rien de surprenant : renoncer à un achat suppose une équipe capable de reprendre le périmètre, et l'écart entre secteurs mesure surtout la profondeur de cette capacité.
Le contexte financier général de l'enquête mérite d'être posé en face. La part de répondants qui attribuent un effet EBIT à l'IA n'a pas bougé en un an, elle reste à 37 %, alors même que 80 % constatent un gain de productivité individuelle. Un écart aussi stable entre le ressenti individuel et le résultat consolidé invite à la prudence sur toute économie annoncée au niveau d'une équipe. Une licence évitée est visible dans le budget logiciel dès le premier trimestre ; le coût qu'elle déplace apparaît ailleurs, plus tard, et souvent sans être rattaché à la décision d'origine.
Les mots de la décision d'achat
Agent codeur : système qui reçoit une intention en langage naturel et produit du code, des tests et parfois une intégration complète, en enchaînant plusieurs étapes sans intervention à chaque étape.
Coût total de possession : somme de toutes les dépenses attachées à un système sur sa durée de vie, construction comprise mais surtout exploitation, maintenance, sécurité, conformité et retrait.
Coût de run : la part récurrente du coût de possession, celle qui tombe chaque mois que le système soit utilisé ou non.
Fournisseur et déployeur (provider, deployer) : les deux qualités distinctes du règlement européen sur l'IA. Utiliser un système acheté fait de vous un déployeur. Le construire, ou le faire construire pour votre compte, fait de vous un fournisseur, avec un jeu d'obligations nettement plus lourd.
La facture ne tombe pas la première année
Le coût de construction n'est plus le sujet, et c'est précisément ce qui rend la décision piégeuse. Ce qui change, c'est la forme du code produit et donc le prix de sa possession.
La mesure la plus solide disponible sur ce point vient de GitClear, qui a analysé 623 millions de changements de code entre 2023 et 2026 dans un rapport publié en juin 2026. Huit signaux de maintenabilité se dégradent simultanément. La duplication de blocs progresse de 81 % par rapport à 2023, passant de 40,3 à 73,0 lignes dupliquées par million de lignes modifiées, son plus haut niveau enregistré. Le refactoring, mesuré par les lignes déplacées, recule de 70 %. La connectivité entre fonctions, c'est-à-dire la fréquence à laquelle du code neuf appelle une fonction existante ailleurs, baisse de 35 %, de 343 à 223 appels pour mille lignes modifiées. Et la maintenance du code ancien, la part des changements qui touchent du code non modifié depuis plus de douze mois, chute de 74 %, de 1,7 % à 0,46 %.
Le renversement le plus parlant tient dans une comparaison. En 2022, dernière année avant l'adoption massive des assistants, les développeurs déplaçaient du code deux fois plus souvent qu'ils n'en copiaient. En 2026, ils en copient environ cinq fois plus souvent qu'ils n'en déplacent, avec 15,7 % de copier-coller contre 3,8 % de code déplacé. Un bloc dupliqué n'est pas une faute en soi, il installe une obligation : le jour où l'un des exemplaires change, quelqu'un doit retrouver les autres, dans des fichiers et des domaines qu'il ne connaît pas forcément, et décider si le changement doit se propager. Cette obligation ne se déclenche pas au moment de la livraison. Elle se déclenche en année deux, quand la personne qui a piloté l'agent est passée à autre chose.

Les lignes de coût que la licence payait pour vous
Le prix d'une licence achète rarement un logiciel seul. Il achète un fournisseur qui corrige ses failles, publie ses correctifs, tient sa documentation, assure une astreinte, garde une compatibilité ascendante et répond aux auditeurs quand ils se présentent. Renoncer à l'achat transfère ces charges, une par une, à l'intérieur.
Six lignes méritent d'être chiffrées avant la décision, pas après. La maintenance corrective et évolutive sur la durée de vie attendue. L'astreinte, avec son coût direct et son coût de rétention. Les correctifs de sécurité, qui supposent une veille active sur les dépendances retenues par l'agent, dépendances que personne n'a choisies explicitement. La documentation d'audit, dans sa forme exigée par vos auditeurs et non dans celle qui vous arrange. La dette de dépendances, qui inclut le jour où l'une d'elles est abandonnée. Et la continuité, c'est-à-dire ce qu'il advient quand part la personne qui savait ce que l'agent avait produit et pourquoi.
Une septième ligne a changé de nature cet été, et elle est régulièrement absente des discussions. Le règlement européen sur l'IA distingue le fournisseur du déployeur, et cette qualité se gagne en développant le système ou en le faisant développer pour son compte. Une entreprise qui achetait un outil de tri de candidatures en était déployeur ; la même entreprise qui le reconstruit avec ses agents en devient fournisseur, avec la gestion des risques, la gouvernance des données, la documentation technique, la journalisation, la surveillance humaine et l'évaluation de conformité qui vont avec.
Le calendrier a bougé et il faut le lire correctement. Le règlement (UE) 2026/1744, dit Digital Omnibus sur l'IA, a été publié au Journal officiel le 24 juillet 2026 et est entré en vigueur le 27 juillet, six jours avant l'échéance initiale. Il reporte les obligations du niveau haut risque pour les systèmes autonomes de l'annexe III, qui couvre notamment le recrutement, le scoring de crédit, l'éducation et les infrastructures critiques, au 2 décembre 2027, et celles des systèmes embarqués dans des produits déjà réglementés de l'annexe I au 2 août 2028. Ces dates sont fixes et ne dépendent plus de la publication des normes harmonisées. En revanche, les obligations de transparence de l'article 50 et les pouvoirs de sanction de l'AI Office sur les modèles à usage général sont bien entrés en application le 2 août 2026, sans report. Le niveau haut risque a donc reçu une piste d'élan, pas une dispense, et cette piste se consomme exactement pendant la fenêtre où les systèmes construits en interne aujourd'hui entreront en production.
Sur le terrain, le point de rupture n'est presque jamais technique. Il se situe au moment où la fonction achats retire la ligne de licence du budget de l'année suivante, pendant que la charge de run correspondante n'a été inscrite dans aucun budget d'exploitation, faute d'avoir été chiffrée par quelqu'un au moment de l'arbitrage. Le système fonctionne, l'économie est réelle sur le papier, et l'équipe qui le maintient n'a reçu ni budget ni effectif pour le faire.
Une grille à trois zones, et un chiffrage sur vingt-quatre mois
La décision se cadre proprement avec deux instruments. Le premier trie les périmètres en trois zones.
Internaliser convient quand le périmètre est stable, qu'il touche une spécificité métier qu'aucun éditeur ne couvrira jamais correctement, qu'il ne relève ni de l'annexe I ni de l'annexe III du règlement européen, et qu'une équipe nommée en porte la charge d'exploitation avec un budget identifié. Acheter reste le bon choix quand le périmètre est banalisé, quand l'obligation réglementaire est lourde et qu'un fournisseur la porte à votre place, quand la conformité de votre système engagerait votre responsabilité de fournisseur, ou quand le sujet est critique sans être différenciant. Différer s'impose dans tous les cas où vous ne savez pas répondre, chiffre à l'appui, à la question de qui paiera l'exploitation en année deux et avec quel effectif.
Le second instrument est un modèle de coût de run sur vingt-quatre mois, à poser en face du prix de la licence évitée, sur la même page et dans la même unité. Vingt-quatre mois parce que la dégradation mesurée par GitClear se manifeste sur ce genre d'horizon, pas sur un trimestre, et que la comparaison à douze mois donne systématiquement raison à la construction. Le modèle n'a pas besoin d'être sophistiqué. Il a besoin d'être écrit, signé par la personne qui portera la charge, et relu par la fonction achats avant que la ligne de licence ne disparaisse du budget.
À mettre en route cette semaine
Recensez les achats logiciels écartés au cours des douze derniers mois au motif que vous pouviez construire l'équivalent. L'inventaire tient sur une page et il est presque toujours plus long que ce que la direction technique estime de mémoire, parce que la décision se prend rarement en comité.
Pour chacun, posez le nom de la personne qui porte aujourd'hui la charge d'exploitation et le budget qui la finance. Une case vide à cet endroit ne signale pas un oubli administratif, elle signale un coût de run qui sera payé en incident.
Mesurez la duplication et la connectivité de fonctions sur les dépôts concernés, et comparez ces deux valeurs à celles d'un dépôt ancien de votre parc. Vous cherchez un écart, pas une valeur absolue, et l'écart se lit en une heure sur des outils que vos équipes ont déjà.
Passez chaque périmètre construit en interne au filtre fournisseur contre déployeur du règlement européen, et repérez ceux qui tomberaient sous l'annexe III. Ceux-là ont une échéance datée au 2 décembre 2027 et une charge documentaire qu'il vaut mieux instruire sur deux exercices que sur un trimestre.
Ajoutez le chiffrage du coût de run sur vingt-quatre mois à votre procédure d'arbitrage d'achat, comme pièce obligatoire du dossier au même titre que le devis du fournisseur écarté. Une décision de construire sans cette pièce n'est pas une décision, c'est un report de facture.
Conclusion
Le renoncement à l'achat n'est plus un signal faible, il est le comportement d'un tiers du marché et de près de la moitié des entreprises qui tirent le plus de valeur de leur IA. Ce qui manque n'est pas la capacité de construire, elle est acquise et elle progresse vite ; c'est l'instrument comptable qui permet de comparer une licence à une charge de possession étalée sur deux ans, avec le même sérieux qu'un comité d'investissement applique à n'importe quel actif. Tant que cet instrument n'existe pas, chaque achat évité produit une économie parfaitement visible et un engagement parfaitement invisible, et l'écart entre les deux se règle au moment le plus défavorable.
Sources : As of August 2026
- [Primary] The state of AI in 2026: on the road to ROI — McKinsey & Company (QuantumBlack) — 25 août 2026 — https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- [Primary] The maintainability gap: AI code quality in 2026 — GitClear — juin 2026 — https://www.gitclear.com/the_ai_code_quality_maintainability_gap
- [Primary] AI Copilot code quality: 2025 data suggests 4x growth in code clones — GitClear — février 2025 — https://www.gitclear.com/ai_assistant_code_quality_2025_research
- [Primary] AI Omnibus enters into force — Commission européenne, Shaping Europe's digital future — 27 juillet 2026 — https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
- [Primary] Regulatory framework for AI, calendrier d'application consolidé — Commission européenne — consultée le 11 septembre 2026 — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- [Secondary] EU AI Omnibus enters into force, amending the AI Act — White & Case — juillet 2026 — https://www.whitecase.com/insight-alert/eu-ai-omnibus-enters-force-amending-ai-act
- [Secondary] A comprehensive EU AI Act summary, mise à jour d'août 2026 — Software Improvement Group — 14 août 2026 — https://www.softwareimprovementgroup.com/blog/eu-ai-act-summary/
Comments ()