L'enquête annuelle de McKinsey sur l'état de l'IA, publiée le 25 août 2026, contient beaucoup de chiffres attendus et un seul qui surprend. Les chiffres attendus disent que l'adoption progresse, que les grandes entreprises vont plus vite que les petites, et que l'impact financier, lui, ne bouge pas. Le chiffre qui surprend tient en une ligne : 32 % des répondants déclarent que leur organisation a renoncé à acheter au moins un produit logiciel ou une fonctionnalité parce qu'elle pouvait désormais la construire en interne avec des agents de code.
Près d'un sur trois. Et chez les 6 % d'organisations que McKinsey classe en « haute performance » — celles qui attribuent au moins 5 % de leur résultat d'exploitation à leur usage de l'IA — c'est près d'une sur deux.
Disons tout de suite ce que vaut cette mesure, parce que la suite en dépend. L'enquête a été menée du 4 mai au 8 juin 2026 auprès de 1 719 répondants dans 97 pays, pondérée par la contribution de chaque pays au PIB mondial ; 36 % travaillent dans des organisations de plus d'un milliard de dollars de chiffre d'affaires. C'est du déclaratif, sur un panel qui n'est pas un échantillon aléatoire d'entreprises. Et McKinsey vend du conseil en transformation par l'IA : le cabinet a un intérêt évident à ce que ses lecteurs concluent qu'il faut accélérer. Ça ne disqualifie pas les chiffres — ils sont cohérents d'une année sur l'autre, et l'enquête publie ses écarts entre prévisions et réalité, ce qui est plutôt à son honneur. Ça invite simplement à lire les recommandations autrement que les données.
« Ne pas acheter » n'est pas « avoir construit »
Première précaution de lecture, et elle est importante : la question porte sur une décision, pas sur une livraison. Un répondant qui déclare avoir renoncé à un achat ne déclare pas que le logiciel de remplacement tourne en production, qu'il est maintenu, ni qu'il a coûté moins cher.
C'est une nuance, mais c'est celle qui sépare un signal d'un résultat. Ce que mesure le 32 %, c'est le moment où l'arbitrage a basculé dans la tête de quelqu'un : le coût de construction a suffisamment baissé pour que « on le fait nous-mêmes » redevienne une phrase qu'on ose dire en comité d'investissement. C'est déjà considérable. Ça ne dit rien de ce qui arrive ensuite.
Or l'arbitrage acheter/construire n'a jamais reposé uniquement sur le coût de construction. Il reposait sur ce que l'achat contenait en plus du logiciel.
Ce que l'achat contenait, et qu'on reprend à son compte
Quand une entreprise achète une brique logicielle à un éditeur, elle n'achète pas des fonctions. Elle achète, groupés dans un abonnement, quatre choses qu'on ne voit jamais sur la facture :
- une feuille de route — quelqu'un, ailleurs, décide de ce que le produit devient et le finance ;
- une maintenance — les montées de version, les correctifs de sécurité, la compatibilité avec le reste de l'écosystème ;
- une conformité portée par un tiers — certifications, engagements contractuels, responsabilité juridique en cas de manquement ;
- un responsable au bout du fil — l'interlocuteur qu'on appelle quand ça casse un vendredi soir.
Ces quatre lignes ne disparaissent pas quand on construit. Elles changent de propriétaire. La décision mesurée par McKinsey est donc moins « on économise une licence » que « on internalise un cycle de vie » — avec ce que ça suppose de gouvernance : savoir qui décide des évolutions, qui sait encore comment ça marche dans dix-huit mois, et sur quelle base on tranchera un jour de l'abandonner.
Ce n'est pas un argument contre la construction. C'est l'argument qui décide si elle tient. Un agent de code fait s'effondrer le coût du premier jet ; il ne fait rien pour le coût de possession. C'est exactement le déplacement que nous décrivions à propos des 40 jours et 2,3 milliards de tokens de Luc Bonnin : le travail ne disparaît pas, il se déplace vers l'aval — et l'aval, ici, s'étale sur des années.
Le paradoxe du haut de tableau
Le passage le plus intéressant de l'enquête est celui que personne ne reprendra dans un post LinkedIn, parce qu'il contredit la promesse d'économie.
McKinsey rapporte qu'environ 20 % des répondants disent que les coûts d'exploitation de l'IA (tokens compris) contraignent leur usage. Une proportion modérée, stable selon la taille des organisations. Mais quand on isole les « hauts performeurs » — ceux qui construisent le plus, qui déploient le plus d'agents de code, qui renoncent le plus souvent à des achats — le chiffre change de nature : ils déclarent être contraints par le coût de leurs agents de code environ trois fois plus souvent que les autres. Et cet écart leur est propre : sur les autres types d'outils IA, ils sont contraints ni plus ni moins que la moyenne.
Même si le coût par token a baissé, le nombre de tokens consommés et générés a augmenté plus vite encore.
La phrase est de Michael Chui, senior fellow de McKinsey, dans le commentaire qui accompagne l'enquête ; il ajoute que les directions financières découvrent que l'IA n'est pas « too cheap to meter » dès qu'il s'agit de développement logiciel agentique et de tâches de raisonnement complexes.
Autrement dit : réussir avec les agents de code, c'est rencontrer leur facture. Le succès ne protège pas de la contrainte de coût, il y mène. C'est la même mécanique qu' Uber, qui a consommé son budget IA annuel en quatre mois — un épisode qui se lit mieux comme un symptôme de maturité que comme un dérapage. Une entreprise qui ne rencontre jamais son plafond de tokens est rarement une entreprise frugale ; c'est le plus souvent une entreprise qui n'a pas encore mis ses agents au travail.
La conséquence pratique est une phrase de Lieven Van der Veken, senior partner, que je retiens parce qu'elle est actionnable dès demain : les organisations qui avancent le plus vite traitent les coûts d'exploitation comme une contrainte de conception, et non comme un détail qu'on regardera plus tard. Traiter le coût comme une contrainte de conception, ça veut dire décider du modèle, du contexte envoyé et du périmètre d'une tâche avant de la lancer — pas découvrir la facture en fin de mois.
80 % contre 37 % : le trou où tombe la valeur
Le troisième chiffre de l'enquête est celui qui revient chaque année, et il ne bouge toujours pas. 80 % des répondants disent que l'IA a amélioré leur productivité individuelle, et environ la moitié qu'elle les aide à mieux décider. Mais 37 % seulement attribuent à l'IA un effet positif sur le résultat d'exploitation de leur organisation — soit, à peu de chose près, la même proportion que l'an dernier, malgré une année de déploiements supplémentaires.
Il faut résister à la lecture facile (« donc l'IA ne sert à rien ») comme à la lecture inverse (« donc la valeur est là, cachée »). Les deux chiffres ne mesurent pas la même chose : le premier est un ressenti individuel, le second une attribution comptable. Un gain de vingt minutes par jour et par personne est parfaitement réel et parfaitement invisible dans un compte de résultat, tant que rien dans l'organisation ne le convertit en quelque chose — une livraison de plus, un délai plus court, une personne libérée pour autre chose.
C'est le même angle mort que celui pointé par l'Institut Montaigne quand il concluait que le problème n'est pas la technologie mais l'organisation. L'enquête McKinsey le formule à sa manière, sous la plume de Tara Balakrishnan : le facteur limitant est de plus en plus la capacité de l'organisation à absorber le changement.
Un détail mérite d'être relevé, parce qu'il est rarement cité : l'expérience n'est pas uniforme selon l'étage. 47 % des managers intermédiaires et des contributeurs individuels rapportent avoir subi au moins un effet négatif lié à l'IA, contre 31 % des dirigeants et cadres supérieurs. L'enthousiasme mesuré en haut n'est pas celui vécu en bas — et une transformation pilotée sur le seul ressenti des dirigeants se trompera de diagnostic.
Le chiffre qui devrait rendre prudent sur tous les autres
McKinsey publie une comparaison qu'on aimerait voir plus souvent : ce que les répondants prévoyaient l'an dernier, confronté à ce qu'ils constatent cette année.
En 2025, 32 % des répondants s'attendaient à une baisse des effectifs de leur organisation liée à l'IA sur l'année à venir. Cette année, 14 % rapportent une baisse effective — moins de la moitié. Les deux tiers déclarent peu ou pas de changement. Et pour l'année qui vient, la prévision remonte à 39 %.
Il y a là une leçon de méthode qui vaut pour toutes les enquêtes de ce genre, y compris celle-ci : un questionnaire mesure bien les anticipations, et mal l'avenir. Les mêmes personnes qui se sont trompées d'un facteur deux sur les effectifs répondent aussi aux questions sur la productivité et sur l'impact financier. Ce qui ne rend pas leurs réponses inutiles — ça rappelle seulement qu'une intention déclarée n'est pas un fait, et qu'un ressenti de productivité n'est pas une mesure de productivité.
C'est aussi ce qui rend la trajectoire du 32 % intéressante à surveiller. Si l'an prochain la même enquête montre que les renoncements à l'achat se sont traduits par des logiciels internes en production et maintenus, le mouvement sera réel. S'ils se sont traduits par des projets arrêtés en chemin, on retrouvera le scénario que nous décrivions à propos des projets IA coupés sans qu'on sache pourquoi, avec une aggravation : on n'aura pas seulement perdu un projet, on aura aussi perdu le logiciel qu'on n'a pas acheté.
Ce que font les 6 %
McKinsey décrit un petit groupe d'organisations — 6 % du panel, proportion inchangée depuis l'an dernier — qui attribuent à l'IA au moins 5 % de leur résultat d'exploitation. Trois traits les distinguent, et aucun n'est technologique :
- elles refondent les processus au lieu d'y insérer l'IA. Près des trois quarts déclarent avoir fondamentalement redessiné des flux de travail (contre 55 % l'an dernier), là où un quart seulement des autres le font ;
- leurs dirigeants s'engagent visiblement — elles sont deux fois plus nombreuses à le déclarer ;
- elles ont un processus défini pour mesurer l'impact de leurs initiatives IA — là encore deux fois plus souvent que les autres.
Le troisième point est celui qui m'intéresse le plus, parce qu'il est le moins coûteux à mettre en place et le plus souvent sacrifié. Mesurer l'impact ne rapporte rien tant que tout va bien ; ça ne devient précieux qu'au moment d'arbitrer, c'est-à-dire trop tard pour l'installer rétroactivement. Que les organisations les plus performantes soient aussi celles qui mesurent n'établit pas de lien de cause à effet — l'enquête ne le permet pas — mais la corrélation est suffisamment franche pour qu'on se demande dans quel camp on veut être.
Ce que ça change pour qui décide de construire
Si vous faites partie du tiers qui a renoncé à un achat, vous venez de reprendre à votre compte une feuille de route, une maintenance et une conformité. Trois questions se posent alors, et aucune n'est technique :
- Où vit la spécification ? Un éditeur documentait son produit pour vous. En interne, si le seul endroit où le comportement attendu est écrit est le code que l'agent a produit, la connaissance est déjà perdue. C'est le sujet que nous avons traité sous l'angle de la spécification comme actif, et la décision de construire le rend soudain beaucoup moins théorique.
- Qui est responsable, nommément ? Le contrat d'éditeur désignait un responsable par défaut. Un logiciel construit en interne sans propriétaire désigné n'a pas de responsable : il en a zéro, et ça ne se voit que le jour de l'incident.
- Quel est le coût réel, par fonctionnalité ? Une licence se compare à une autre licence. Une construction interne se compare à ce qu'elle a coûté — en tokens, en temps de revue, en reprises. Un coût rattaché à un mois ne permet aucun arbitrage ; un coût rattaché à une fonctionnalité et à une version, oui.
C'est très exactement le travail que fait Survol, et je ne vais pas prétendre que c'est une coïncidence : nous construisons un outil de pilotage pour des produits développés par des agents, donc ces trois questions sont notre matière première. Mais elles se posent avec ou sans nous, et elles se posent le jour où la décision est prise — pas dix-huit mois plus tard, quand plus personne ne sait pourquoi le module fait ce qu'il fait.
Le vrai enseignement de l'enquête n'est donc pas que l'IA permet de construire au lieu d'acheter. C'est que la décision de construire est redevenue une décision de gouvernance, après vingt ans pendant lesquels elle était surtout une décision de budget. Ce qui est bien moins confortable — et nettement plus intéressant.
Sources
- Dan Tinkoff, Lieven Van der Veken et Michael Chui, avec Tara Balakrishnan, « The state of AI in 2026: On the road to ROI », McKinsey & Company (QuantumBlack), 25 août 2026. Enquête en ligne menée du 4 mai au 8 juin 2026 auprès de 1 719 répondants dans 97 pays, pondérée par la contribution de chaque pays au PIB mondial. Tous les chiffres et les citations de cet article en proviennent.
