← Tous les articles

Le théâtre de l'IA : pourquoi 90 % des entreprises « utilisent l'IA » mais seulement 23 % créent de la valeur

11 min de lecture

L’enquête mondiale sur l’IA de McKinsey en 2025 a révélé que 90 % des organisations déclarent utiliser l’IA sous une forme ou une autre, mais seulement 23 % déploient des agents IA à l’échelle de la production. Les 67 % restants font du théâtre de l’IA : un investissement visible sans résultats mesurables.1

J’ai été témoin de trois formes de théâtre de l’IA au cours de ma carrière et j’en ai moi-même pratiqué une.

TL;DR

Le théâtre de l’IA décrit un comportement organisationnel où les entreprises investissent de manière visible dans l’IA (recrutement d’équipes IA, annonces d’initiatives IA, lancement de projets pilotes IA) sans créer de valeur commerciale mesurable. Après 12 ans de leadership en conception produit chez ZipRecruiter et une année à construire une infrastructure d’agents IA de manière indépendante, j’ai vu les deux côtés : des organisations faisant du théâtre de l’IA et mes propres premiers travaux qui en étaient proches. L’écart entre l’adoption de l’IA et la création de valeur par l’IA a trois causes profondes : des incitations mal alignées qui récompensent l’activité plutôt que les résultats, une dette technique qui empêche les systèmes d’IA d’accéder aux données de production, et des structures organisationnelles qui isolent les équipes IA des décideurs métier.

L’écart entre adoption et valeur

McKinsey a interrogé 1 400 dirigeants dans divers secteurs. Le résultat phare : l’utilisation de l’IA a atteint une quasi-ubiquité. Le résultat enfoui : la création de valeur n’a pas suivi le même rythme.2

Indicateur Pourcentage
Organisations « utilisant l’IA » 90 %
Organisations avec l’IA en production ~33 %
Organisations déployant des agents IA à l’échelle 23 %
Organisations bloquées au stade pilote 67 %
Organisations rapportant un ROI significatif de l’IA ~15 %

L’écart entre « utiliser » et « créer de la valeur » n’est pas une courbe de maturité que toutes les entreprises parcourront naturellement. La majorité des entreprises bloquées au stade pilote partagent des caractéristiques structurelles qui empêchent toute progression sans changement organisationnel délibéré.3

Trois formes dont j’ai été témoin

Forme 1 : le jeu des annonces

Dans une entreprise que j’ai conseillée de manière informelle, l’équipe produit a annoncé une fonctionnalité de « recherche propulsée par l’IA » qui se résumait à faire passer les requêtes des utilisateurs par une API de modèle de fondation sans fine-tuning, sans cadre d’évaluation et sans métriques au-delà de « nous l’avons lancée ». Le communiqué de presse a généré de la couverture médiatique. La fonctionnalité a généré un taux d’utilisation de 2 % et a été discrètement abandonnée six mois plus tard.

La question diagnostique : la fonctionnalité IA dispose-t-elle de métriques d’utilisation, de taux de rétention et de scores de satisfaction client ? Ou bien l’équipe ne suit-elle que « nous avons lancé une fonctionnalité IA » ?4

Forme 2 : l’usine à projets pilotes

Une entreprise de taille moyenne que je connais par mon réseau professionnel a lancé 12 preuves de concept IA dans différents départements en 2024. Chaque pilote avait une équipe dédiée, un cas d’usage spécifique et un calendrier de 90 jours. Un seul pilote a atteint la production. Les 11 autres ont produit des démos impressionnantes que les dirigeants ont montrées lors des réunions du conseil d’administration. L’organisation manquait de l’infrastructure (MLOps, pipelines de données, monitoring) nécessaire pour exploiter des systèmes d’IA à l’échelle.

La question diagnostique : combien de projets pilotes IA de 2024 fonctionnent aujourd’hui en production sans intervention manuelle ?5

Forme 3 : la stratégie recruter-et-espérer

Un ancien collègue a rejoint une entreprise en tant que « Responsable de l’IA », s’attendant à transformer les opérations. L’équipe IA a construit des démos impressionnantes qui ont ébloui les dirigeants, mais n’avait pas accès aux bases de données de production, aux systèmes orientés client, ni aux tableaux de bord des métriques métier. Chaque demande de données nécessitait un ticket à l’équipe d’ingénierie des données, avec un délai de traitement de 2 à 3 semaines. Après 18 mois, l’équipe s’est réorientée vers la construction de chatbots internes.6

La question diagnostique : l’équipe IA a-t-elle un accès direct aux bases de données de production, aux systèmes orientés client et aux tableaux de bord des métriques métier ? Ou bien chaque demande de données nécessite-t-elle un ticket auprès d’une autre équipe ?

Mon propre moment de théâtre de l’IA

Je vais être honnête : mon premier système de hooks Claude Code comportait des éléments de théâtre de l’IA. J’ai construit 25 hooks le premier mois. Beaucoup étaient des démos impressionnantes : injection de contexte, application de philosophie, validation de principes de design. Mais je n’avais pas mesuré s’ils amélioraient la qualité du code, réduisaient les bugs ou faisaient gagner du temps. J’optimisais pour le sentiment de sophistication plutôt que pour des résultats mesurables.

Le point de bascule a été la construction du linter de qualité pour le blog. Contrairement aux hooks précédents, le linter avait des critères mesurables : exactitude des citations, longueur des méta-descriptions, balises de langage des blocs de code, intégrité des notes de bas de page. Je pouvais compter les anomalies avant et après. Je pouvais mesurer les taux de faux positifs. Le linter est passé de « propulsé par l’IA » à « mesurément utile » parce que j’avais défini des critères de succès avant de le construire.

Ma checklist anti-théâtre désormais : 1. Définir la métrique avant de construire. « Quel chiffre change si ça fonctionne ? » Si je ne peux pas répondre, je construis du théâtre. 2. Mesurer la référence de base. Comment le processus actuel fonctionne-t-il sans IA ? Mes articles de blog avaient en moyenne 4,2 anomalies détectées par le linter avant le système automatisé. Après : 0,3. 3. Suivre la valeur dans le temps. Mes 95 hooks s’exécutent à chaque session. Le recursion-guard a bloqué 23 tentatives d’emballement de spawn. Le git-safety-guardian a intercepté 8 tentatives de force-push. Ce sont des chiffres réels.7

Causes profondes

Incitations mal alignées

La plupart des organisations récompensent les équipes IA pour l’activité (pilotes lancés, modèles entraînés, fonctionnalités annoncées) plutôt que pour les résultats (revenus générés, coûts réduits, décisions améliorées). Les métriques d’activité sont plus faciles à mesurer et à rapporter.8

Le désalignement des incitations se répercute en cascade. Les équipes IA optimisent pour le lancement de pilotes impressionnants parce que les lancements sont célébrés. Les opérations de production sont ignorées parce que la maintenance est invisible.

La dette technique bloque l’accès aux données

Les systèmes d’IA nécessitent un accès aux données de production. Les données de production résident dans des systèmes construits avant que l’IA ne soit une priorité stratégique. L’investissement en infrastructure de données coûte généralement 3 à 5 fois le coût de développement du modèle. Les organisations qui budgétisent pour « l’IA » sans budgétiser pour « l’infrastructure de données qui permet l’IA » sous-performent systématiquement.9

Isolement organisationnel

Les équipes IA positionnées comme « équipes d’innovation » ou « centres d’excellence » opèrent en dehors du processus de développement produit. Les entreprises qui réussissent à faire passer l’IA à l’échelle intègrent les ingénieurs IA au sein des équipes produit, suivant le même modèle qui s’est avéré efficace pour les designers intégrés et les analystes intégrés. Le schéma organisationnel compte plus que la technologie.10

Ce qui fonctionne réellement

Commencer par la décision, pas par le modèle

Les organisations qui créent de la valeur avec l’IA commencent par identifier une décision métier spécifique que l’IA pourrait améliorer. L’approche centrée sur la décision contraint le système d’IA à un résultat mesurable : quantifier la qualité de décision actuelle, mesurer la qualité assistée par l’IA, calculer la différence.11

Mon linter de blog suit ce schéma. La décision : « Quels articles de blog répondent aux standards de qualité pour la publication ? » La métrique : anomalies détectées par le linter par article. La référence de base : 4,2 anomalies par article sans le linter. L’état actuel : 0,3 anomalie par article avec le linter et la barrière automatisée de pré-publication.

Investir d’abord dans l’infrastructure de données

Les organisations qui font passer l’IA au-delà des pilotes investissent dans l’infrastructure de données avant le développement de modèles :

  • Pipelines de données qui livrent en continu des données de production nettoyées
  • Feature stores qui maintiennent des définitions de features cohérentes
  • Systèmes de monitoring qui détectent la dégradation des modèles
  • Cadres de gouvernance qui suivent la lignée des données12

Intégrer l’IA dans les équipes produit

Les ingénieurs IA qui travaillent au sein des équipes produit partagent les objectifs de l’équipe, comprennent ses contraintes et voient ses données au quotidien. Les applications internes d’IA les plus réussies de Google (détection de spam, classement publicitaire, qualité de recherche) ont été construites par des ingénieurs IA intégrés au sein des équipes produit responsables de ces systèmes.13

La frontière des agents

Le rapport de McKinsey met en avant les agents IA comme le prochain point d’inflexion. Parmi les organisations qui créent déjà de la valeur avec l’IA, 62 % expérimentent des agents. Parmi les organisations encore au stade pilote, seulement 8 % travaillent avec des agents.14

Les agents amplifient les défis du théâtre de l’IA. Un agent qui agit de manière autonome nécessite une confiance plus élevée dans les sorties du modèle, un monitoring plus robuste et une gouvernance plus claire. Mon système de délibération répond à cela avec des seuils de consensus adaptatifs par tâche (85 % pour les décisions de sécurité, 50 % pour la documentation) et l’application de budgets de spawn. Les organisations qui ne parviennent pas à déployer un modèle de recommandation ne parviendront pas à déployer un agent autonome.

Points clés à retenir

Pour les dirigeants : - Auditez les initiatives IA sur des métriques de résultats (revenus, coûts, qualité des décisions) plutôt que sur des métriques d’activité ; si l’équipe rapporte de l’activité sans résultats, l’organisation fait du théâtre de l’IA - Budgétisez 3 à 5 fois le coût de développement du modèle pour l’infrastructure de données ; l’infrastructure est le prérequis de tout système d’IA en production

Pour les responsables IA/ML : - Intégrez les ingénieurs IA au sein des équipes produit plutôt que de construire des équipes IA centralisées ; la proximité organisationnelle avec les systèmes de production détermine le succès du passage à l’échelle - Arrêtez les pilotes qui ne peuvent pas articuler un chemin vers la production sous 90 jours ; un pilote sans plan de mise en production est une démo

Pour les praticiens individuels : - Définissez des critères de succès mesurables avant de construire toute fonctionnalité IA ; « quel chiffre change ? » est la question anti-théâtre - Suivez la valeur dans le temps, pas les métriques de lancement ; mon git-safety-guardian a intercepté 8 tentatives de force-push, et ce chiffre compte plus que « nous avons déployé un hook de sécurité »

Références

  1. McKinsey & Company, « The State of AI in 2025 », McKinsey Global AI Survey, 2025. ↩

  2. McKinsey & Company, « Superagency in the Workplace: Empowering People to Unlock AI’s Full Potential », McKinsey Global Institute, 2025. ↩

  3. Davenport, Thomas & Ronanki, Rajeev, « Artificial Intelligence for the Real World », Harvard Business Review, janvier-février 2018. ↩

  4. Nagle, Tadhg et al., « Only 8% of Companies That Do AI Are Scaling It », MIT Sloan Management Review, 2020. ↩

  5. Sculley, D. et al., « Hidden Technical Debt in Machine Learning Systems », NeurIPS 2015. ↩

  6. Fountaine, Tim et al., « Building the AI-Powered Organization », Harvard Business Review, juillet-août 2019. ↩

  7. Métriques de l’infrastructure Claude Code de l’auteur. 95 hooks, décompte des interceptions du git-safety-guardian, décompte des blocages de spawn du recursion-guard. Suivi dans ~/.claude/state/. ↩

  8. Brynjolfsson, Erik & McAfee, Andrew, « The Business of Artificial Intelligence », Harvard Business Review, 2017. ↩

  9. Sambasivan, Nithya et al., « ‘Everyone Wants to Do the Model Work, Not the Data Work’: Data Cascades in High-Stakes AI », CHI 2021. ↩

  10. Iansiti, Marco & Lakhani, Karim R., Competing in the Age of AI, Harvard Business Review Press, 2020. ↩

  11. Agrawal, Ajay et al., Prediction Machines, Harvard Business Review Press, 2018. ↩

  12. Polyzotis, Neoklis et al., « Data Lifecycle Challenges in Production Machine Learning », SIGMOD 2018, ACM. ↩

  13. Sculley, D. et al., « Machine Learning: The High-Interest Credit Card of Technical Debt », NeurIPS 2014. Initialement publié en tant que recherche interne de Google sur la préparation des systèmes ML à la production. ↩

  14. McKinsey & Company, « Agents for Enterprise: The Next Frontier », McKinsey Digital Report, 2025. ↩