McKinsey 2026 : la confiance IA monte à 2,3. Mon infrastructure n'y croit pas encore.

McKinsey vient de publier son enquête annuelle sur la maturité de la confiance en IA, cette fois cadrée comme l'ère agentique. Environ 500 organisations interrogées entre décembre 2025 et janvier 2026. Score moyen de maturité : 2,3 sur 5, en légère hausse par rapport au 2,0 de l'année précédente. 62 % expérimentent avec des agents, 23 % les scalent quelque part. Et le titre qui m'intéresse vraiment : près de deux tiers des répondants citent la sécurité et le risque comme première barrière au scaling de l'IA agentique, devant même l'incertitude réglementaire.

Ce chiffre devrait atterrir sur n'importe quelle feuille de route plateforme ce trimestre. D'où je travaille — DevOps et infrastructure pour des entreprises qui doivent défendre leur stack devant un régulateur — le message du rapport n'est pas optimiste. C'est une liste de choses qui ne sont pas encore montées sous les belles slides de la keynote.

Le cadrage de McKinsey : la confiance n'est plus du compliance, c'est de la valeur business

L'angle de cette année est délibéré. McKinsey dit que l'influence perçue de certains cadres réglementaires a baissé et que les entreprises passent d'une motivation compliance-led à une motivation value-driven. Traduction : les dirigeants veulent arrêter de voir la gouvernance IA comme un coût obligatoire et commencer à la voir comme un levier de revenue.

Ça me va comme cadre de discours. Ça me semble toxique comme cadre opérationnel si tu ne comprends pas ce qu'il y a en dessous. La partie que le rapport cite — que les organisations ayant investi plus de 25 millions de dollars dans la responsible AI affichent un impact EBIT supérieur à 5 % — n'est pas parce que la gouvernance "ajoute de la valeur" par magie. C'est parce que les entreprises qui ont mis cet argent ont aussi construit :

• Des pipelines d'évaluation avec des golden sets versionnés.
• L'attribution de coût par agent et par route.
• Des catalogues d'outils avec scopes et quotas par agent.
• Une équipe plateforme IA avec son propre on-call.
• Du lineage pour prompts, modèles, embeddings, retrieval et décisions.

Si ton CFO voit le 5 % et conclut que la gouvernance paie, parfait. Mais ne confondons pas la conclusion : ce qui paie, c'est l'infrastructure. La gouvernance, c'est ce qui la rend défendable. Sans la première, pas de produit ; sans la seconde, pas de licence d'exploitation.

Les 23 % qui "scalent des agents" sont plus petits qu'il n'y paraît

L'autre chiffre qui va circuler dans beaucoup de présentations de comité ce mois-ci, c'est que 23 % des entreprises scalent déjà des agents quelque part. Lu littéralement, c'est une étape. Lu comme un ingénieur qui doit stabiliser ces systèmes, c'est une question :

Scalés comment ? Avec quels SLOs ? Sous quelle classification de risque ? Avec quel plan d'incident ?

Le rapport est assez honnête pour dire que seulement environ un tiers des organisations rapportent un niveau de maturité de 3 ou plus en gouvernance, stratégie et gouvernance spécifique des agents. La distance entre "23 % scalent des agents" et "33 % ont une gouvernance niveau 3" est exactement l'espace où vivront les prochains incidents IA qui sortiront dans la presse.

Dans les secteurs régulés — banque, santé, énergie, secteur public — cette distance n'est pas un risque théorique. C'est un gap qu'un superviseur peut clôturer par une exigence. La question que je pose à toute équipe qui veut scaler des agents dans ces secteurs est la même qu'un examinateur de la BCE ou de l'OCC poserait : montrez-moi les preuves.

65 % contre 23 % : la différence, c'est du human-in-the-loop bien fait

L'une des données les plus utiles du rapport est l'écart entre high performers et le reste sur la validation humaine : 65 % des leaders ont des processus de human-in-the-loop définis, contre 23 % en queue de peloton. Le rapport décrit correctement un phénomène que je vois chaque semaine en audit technique : la différence entre un système IA qui tient une revue interne et un qui ne tient pas est, presque toujours, la rigueur de la couche humaine, pas la qualité du modèle.

Mais human-in-the-loop est une étiquette qui cache quatre designs très différents :

1. HITL d'approbation explicite — l'agent propose, l'humain signe. C'est le pattern qu'un régulateur comprend sans traduction. Lent, mais défendable.
2. HITL par exception — l'agent décide en autonomie sous un seuil de confiance, l'humain intervient au-dessus. Nécessite un confidence estimator calibré. Beaucoup d'équipes utilisent ici la probabilité brute du logit comme proxy, ce n'en est pas un. Calibre ou meurs.
3. HITL post-hoc — l'humain revoit un échantillon statistique a posteriori. Utile pour la détection de drift, insuffisant comme contrôle primaire en secteur régulé.
4. HITL théâtral — il y a un humain dans le workflow, mais son vrai rôle est de cliquer approuver sur des lots de 200 parce que la file avance trop vite. Ce n'est pas de la gouvernance, c'est de l'absolution au clavier. Ça ressort au premier audit sérieux.

Quand on travaille avec un client à 65 %, il utilise presque toujours un mélange calibré du 1 et du 2 avec un échantillonnage statistique du 3. Quand on travaille avec un client à 23 %, il est presque toujours au 4 sans le savoir. C'est la vraie différence, et elle est architecturale avant d'être culturelle. Il y a un long chapitre que j'ai déjà écrit là-dessus que mon moi du passé doit continuer à prêcher.

"Faire la mauvaise chose" est un problème nouveau pour le runbook

McKinsey introduit une distinction qui vaut la peine d'être reprise telle quelle : à l'ère agentique, les entreprises ne doivent plus seulement se préoccuper des systèmes qui disent la mauvaise chose, mais aussi des systèmes qui font la mauvaise chose — qui prennent des actions non voulues, font un mauvais usage des outils ou opèrent hors guardrails.

Ce changement casse la plupart des runbooks que je vois chez des clients sortant de l'ère chatbot. Toute la discipline d'observabilité bâtie autour de latence, error rate, throughput reste nécessaire, mais n'est plus suffisante. Il faut un deuxième axe de monitoring :

• Inventaire des outils disponibles par agent, avec scopes, rate limits et destinations autorisées. Si l'agent A peut toucher Salesforce, l'agent B ne devrait pas pouvoir y arriver transitivement via delegation.
• Quotas de coût et d'action par agent et par fenêtre temporelle. Une boucle infinie d'un agent qui appelle une API externe est un incident finance avant d'être un incident SRE.
• Alarmes de comportement, pas seulement d'erreur : l'agent qui faisait une chose hier et fait autre chose aujourd'hui sur des données réelles — même s'il n'échoue pas techniquement — est le signal d'incident propre à cette ère.
• Audit trail signé pour chaque action d'outil exécutée, pas seulement pour les messages du modèle. En environnement régulé, qui a fait quoi sur mon système d'enregistrement est la question de l'examinateur, pas qu'a dit le LLM.

Si ta stack ne génère pas ce deuxième flux, tu ne fais pas tourner des agents en production. Tu fais tourner une démo avec des permissions élevées. La distance entre les deux se paie en incident, en titre de presse ou en amende, dans cet ordre.

Ce qui change exactement en environnement régulé

Le rapport parle de l'EU AI Act et de l'horizon trois ans jusqu'à l'application complète. Il note correctement qu'une approche conservatrice — anticiper les standards probables sur la supervision humaine, la protection des données et l'équité — aide les entreprises à prendre de l'avance. Je souscris. Et j'ajoute, depuis l'ingénierie, ce que "prendre de l'avance" veut dire pendant que la réglementation se concrétise :

1. Classification de risque du système, pas du modèle. La plupart des équipes classifient le risque du LLM. Ce que le régulateur veut classifier, c'est le système socio-technique complet : modèle + retrieval + outils + flux humain + données. Sans cette carte, tu ne peux même pas commencer à répondre à l'Article 9 de l'AI Act.
2. Versionnage conjoint du modèle, du prompt et de l'index de retrieval. Un changement dans l'un des trois doit produire un artifact immuable, signé et traçable. Si tu versionnes le modèle mais pas l'index de retrieval, tu ne peux pas reproduire une décision vieille de six mois sous citation judiciaire. Ce n'est plus une préférence d'ingénierie, c'est une exigence.
3. Politiques d'isolation de données appliquées à la sortie du retrieval, pas seulement à l'entrée. La majorité des fuites que je vois dans des pilotes régulés viennent du retrieval qui ramène trop et du modèle qui le récite avec confiance. La politique s'applique avant que le contexte n'atteigne le modèle, pas après.
4. Gates de déploiement avec preuve. Un push de nouveau prompt en production devrait passer une batterie minimale d'evals automatisées — alignement, biais, fuites, comportement d'outils — avant de toucher du trafic réel. L'idée de proof-carrying deployment cesse d'être académique au moment où le superviseur te demande la preuve de ce que tu as validé avant le changement.
5. Plan de retrait contrôlé. Chaque agent en production devrait avoir un kill switch documenté, testé et d'exécution mesurée en minutes. Pas "on peut le dépublier au prochain sprint". En minutes. En environnement régulé, l'option de ne pas agir est souvent plus sûre qu'agir ; ton système doit savoir le faire.

Aucune de ces cinq choses ne vient gratuitement avec une plateforme agentique vue sur le marché cette année. Les cinq sont du travail d'architecture maison. McKinsey les vend comme architecture de gouvernance vérifiable ; je préfère les appeler runbook qu'un avocat peut signer.

Le biais du rapport : optimiste par construction

Un avertissement sur les données. L'enquête McKinsey est répondue, par définition, par des profils ayant déjà une responsabilité directe ou une expertise en gouvernance IA, en gestion de risque ou en décisions d'investissement IA. C'est un échantillon auto-sélectionné vers les entreprises qui ont ces fonctions définies. La réalité du mid-market est pire que celle rapportée — pas parce que McKinsey trompe, mais parce que les entreprises sans AI risk officer ne répondent pas à ce type d'enquête et n'apparaissent donc ni au numérateur ni au dénominateur.

Si ton organisation n'a personne qui pourrait répondre cette enquête, ton niveau de maturité réel n'est probablement pas 2,3. Il est plus proche de 1, et la première tâche n'est pas de monter à 3 ; c'est de construire le rôle qui permet de le mesurer honnêtement.

Ce que je mettrais sur ma propre feuille de route ce trimestre

S'il faut traduire le rapport en actions concrètes pour une équipe plateforme dans un secteur régulé, voici ce que je ferais avant le prochain board update :

1. Un inventaire réel des agents en production, pas seulement ceux que le marketing appelle agents. En comptant les cron jobs, les webhooks et les scripts qui appellent un LLM avec des permissions élevées.
2. Un seul tableau qui répond à qui peut faire quoi : agent, outils, scopes, données accessibles, humain responsable, métriques de comportement. Si ça ne tient pas dans un tableau, tu ne peux pas le défendre.
3. Un budget explicite de gouvernance : personnes, outils, evals, plateforme. Le rapport dit que ceux qui investissent > 25 M$ voient un retour. Ton chiffre ne sera pas celui-là, mais le principe tient : la gouvernance sans budget est du théâtre.
4. Un exercice de kill switch par agent critique, chronométré. Si ça prend plus de dix minutes, tu n'en as pas.
5. Une conversation adulte avec le risque et la conformité. La maturité de gouvernance grandit quand ingénierie, risque et conformité partagent le même vocabulaire. Le rapport identifie correctement cette brèche comme barrière primaire pour beaucoup d'entreprises ; le remède est culturel et organisationnel avant d'être technique.

La ligne que je trace

L'enquête McKinsey a raison sur l'observation centrale : l'IA agentique déplace le problème de dire à faire, et ça change le type de gouvernance qu'il faut avoir monté pour mettre quoi que ce soit en production. Ma question n'est pas si le secteur global est plus mûr (oui, un peu) ou si le risque monte (clairement). Ma question est si, dans ton système concret, un examinateur pourrait demander le log d'actions, le lineage de la décision, l'historique de validation humaine et le résultat de la dernière eval avant déploiement — et tu pourrais lui poser les quatre artefacts sur la table dans la même heure.

Si la réponse est oui, tu es dans le 33 % à maturité réelle et tu peux commencer à parler de valeur business. Si la réponse est non, le 2,3 moyen du rapport reste aspirationnel pour toi, quoi que dise la slide du comité.

Les entreprises qui gagneront l'ère agentique ne seront pas celles qui scaleront le plus vite. Ce seront celles qui, quand le régulateur, l'auditeur ou l'investigateur d'incident apparaîtront, pourront ouvrir le runbook et tourner les pages sans détourner le regard.

---

Sources :

• McKinsey & Company, State of AI trust in 2026: Shifting to the agentic era, avril 2026. mckinsey.com
• McKinsey & Company, Trust in the age of agents — Agentic AI governance for autonomous systems. mckinsey.com
• McKinsey & Company, Deploying agentic AI with safety and security: A playbook for technology leaders. mckinsey.com

Tu mets des agents IA en production sous un vrai régulateur et tu n'es pas sûr que ton runbook tienne le premier audit ? Parle à un CTO — on t'aide à séparer la maturité réelle de la slide.