Pourquoi les projets d’IA agente échouent à l’échelle et ce que les entreprises doivent corriger en premier

L’IA agente devient rapidement un élément critique de toutes les entreprises. Les entreprises intègrent des pilotes dans leurs opérations, les environnements de démonstration impressionnent les dirigeants et les feuilles de route sont réécrites autour de flux de travail d’IA autonomes.

Mais pour beaucoup de ces projets, quelque chose se brise entre l’environnement de démonstration contrôlé et le déploiement de production. Le projet stagne, les déploiements s’étendent de mois à des années et les équipes responsables de la livraison sont laissées pour expliquer pourquoi l’agent qui fonctionnait parfaitement à l’essai se comporte de manière imprévisible dans le monde réel.

Dans presque tous les cas, la réponse n’est pas le modèle lui-même, mais l’état des données, la couche d’orchestration, le cadre de gouvernance et l’infrastructure héritée que la plupart des entreprises n’ont jamais modernisée avant de décider de construire des agents intelligents au-dessus.

L’environnement de preuve de concept est un piège

La plupart des entreprises évaluent les modèles. Beaucoup moins évaluent le comportement de l’agent de bout en bout. Un modèle peut être très précis et l’agent construit au-dessus de lui peut encore échouer gravement. C’est parce que les agents enchaînent les appels d’outils de manière séquentielle et qu’une mauvaise étape produit une mauvaise réponse que l’étape suivante traite comme une entrée correcte, aggravant l’erreur en aval avant que quelqu’un ne s’en aperçoive.

L’environnement de preuve de concept est conçu pour cacher cela. Les entrées sont contrôlées, la portée est étroite et quelqu’un surveille la sortie. Aucune de ces conditions n’existe en production. L’agent qui a obtenu de bons résultats à l’essai gère maintenant des instructions ambiguës, rencontre des erreurs de permission et prend des décisions séquentielles sur des données qu’il n’a jamais été testé contre. L’équipe qui l’a construit découvre que les cadres d’évaluation conçus pour les performances des modèles ne disent pas si un agent a escaladé correctement, géré un cas de bord de manière élégante ou su lorsqu’il devait s’arrêter.

Selon le rapport État de l’IA 2025 de McKinsey, 88 % des organisations utilisent maintenant l’IA dans au moins une fonction commerciale, mais seulement environ un tiers ont réussi à la mettre à l’échelle dans l’ensemble de l’entreprise. L’écart entre l’adoption et la mise à l’échelle commence par la manière dont les entreprises évaluent leurs pilotes. Les équipes qui mettent à l’échelle avec succès traitent l’analyse du mode de défaillance comme une exigence de conception. Avant le déploiement, elles créent un catalogue de la manière dont l’agent est censé échouer et de la réponse lorsqu’il le fait. Cela semble évident. Très peu d’entreprises le font réellement.

Données de mauvaise qualité, agents de mauvaise qualité

Les entreprises demandent sans cesse pourquoi leurs agents sous-performent en production. La réponse revient presque toujours aux données. L’état des données n’était pas prêt. Les sources étaient fragmentées à travers des dizaines de systèmes construits à différents moments pour différents objectifs. Les définitions étaient incohérentes entre les unités commerciales. Il n’y avait pas de couche sémantique. Il n’y avait pas de source unique de vérité. Il y avait juste des années de dette de données accumulées que personne n’a priorisé parce que les anciens systèmes fonctionnaient suffisamment bien.

Cette dette ne disparaît pas lorsque vous construisez un agent au-dessus. Elle devient la réalité opérationnelle de l’agent. Un agent naviguant dans des sources de données fragmentées ne raisonne pas sur une image cohérente de l’entreprise. Il fait de son mieux avec ce qu’il peut trouver, en réconciliant les contradictions à la volée et en produisant des sorties qui semblent plausibles jusqu’à ce que quelqu’un qui connaît l’entreprise les examine de près. L’agent n’est pas cassé. Les données qu’il a reçues étaient cassées avant que le projet ne commence.

Le dérive des données et le dérive des concepts aggravent cela avec le temps. Lorsque la distribution d’entrée réelle se déplace de ce sur quoi le modèle a été formé, l’agent ne lance pas d’erreur. Il continue à fonctionner et commence à générer des sorties incorrectes, avec confiance et à grande échelle. Sans un pipeline MLOps ou AIOps intégré dans la couche d’orchestration de l’agent, il n’y a pas de mécanisme pour détecter cela avant que les dégâts ne se produisent. L’agent qui fonctionnait correctement au lancement se dégrade discrètement pendant des semaines avant que quelqu’un ne relie la qualité de la sortie à un problème de données qui existait dès le début.

La modernisation des données et la modernisation de l’IA sont souvent traitées comme des flux de travail parallèles, séquencés de manière indépendante et financés séparément. Ils ne sont pas parallèles. Vous ne pouvez pas construire un agent fiable sur une architecture de données qui était cassée avant que le projet ne commence. La séquence est énormément importante et sauter la couche de données pour avancer plus vite sur la couche d’IA est l’une des erreurs les plus courantes et coûteuses que les entreprises font.

Un tableau de bord incorrect donne à quelqu’un le mauvais numéro. Une action incorrecte d’un agent peut déclencher un processus en aval avant que quelqu’un ne s’en aperçoive, en approuvant une facture qui n’aurait pas dû l’être, en routant incorrectement un drapeau de conformité ou en ajustant les prix en dehors de la plage prévue. Les systèmes agents nécessitent une observabilité conçue à des fins spécifiques, et non des tableaux de bord recyclés à partir de la surveillance d’applications générales.

L’avantage d’une plate-forme de données unifiée

Les entreprises qui sont passées à une plate-forme de données unifiée avant de commencer leurs programmes d’IA agente mettent à l’échelle plus rapidement que celles qui ne l’ont pas fait. Lorsque le lac de données, l’entrepôt de données, le modèle sémantique et les pipelines vivent tous dans un même environnement, comme c’est le cas dans Microsoft Fabric, les agents ont une surface cohérente unique à interroger. Cela supprime une classe entière de défaillance qui provient des agents qui rebondissent entre des systèmes avec des schémas différents, des cycles de rafraîchissement différents et des définitions différentes de la même métrique commerciale.

C’est pourquoi les plateformes que les entreprises choisissent pour l’unification des données sont si importantes pour leurs résultats d’IA agente. L’approche unifiée de Microsoft Fabric rassemble le lac de données, l’entrepôt de données, le modèle sémantique et les pipelines dans un même environnement, donnant aux entreprises centrées sur Microsoft (MSFT ) un avantage structurel lorsqu’elles passent de l’expérimentation à une utilisation opérationnelle réelle.

Databricks livre le même principe à travers l’architecture du lac de données et le catalogue d’unité, donnant aux équipes de données et d’IA une couche de gouvernance unifiée sur les données structurées et non structurées avec l’intégration de MLflow pour suivre le comportement du modèle en production. L’approche de Snowflake repose sur son Cortex AI et sur un couplage étroit entre le cloud de données et l’inférence d’IA, permettant aux entreprises de faire tourner des charges de travail d’agent directement contre des données vivantes et gérées sans la latence et les risques de cohérence qui proviennent du déplacement de données entre les systèmes.

Chacune de ces plateformes représente un chemin différent vers le même résultat. Une couche de données qui est cohérente, observable et digne de confiance pour supporter la prise de décision de l’agent à grande échelle. Le bon choix dépend de la pile existante de l’entreprise. Ce qui n’est pas optionnel, c’est de faire ce choix et de s’y engager avant de construire la couche d’agent au-dessus. Ce qui sépare les équipes qui font des progrès de celles qui sont encore bloquées dans les pilotes, ce n’est pas la plateforme qu’elles ont choisie. C’est qu’elles ont corrigé la couche de données en premier.

La gouvernance avant, et non après

La gouvernance construite après coup n’est pas une gouvernance du tout. Lorsqu’un agent a une autorité de prise de décision en aval et que des garde-fous sont ajoutés six mois après le déploiement, l’entreprise a déjà accumulé six mois de décisions non auditées. La traçabilité doit être conçue avant que l’agent ne soit mis en ligne, et non rétrofitée après le premier incident.

Le même principe s’applique à la sécurité de l’IA, au contrôle d’accès basé sur les rôles et à la définition des autorisations. Un agent sans autorisations correctement définies peut accéder à des données qu’il ne devrait pas, exécuter des actions en dehors de sa limite prévue ou devenir une surface d’attaque active. Ce sont des risques qui doivent être abordés à la phase de développement, et non découverts lors de l’examen du déploiement.

Si la gouvernance n’est pas intégrée avant que les pipelines de formation ne soient construits, des données incorrectes ou adverses peuvent pénétrer le processus de formation sans être détectées. Un modèle formé sur des données compromises se comporte bien sur les benchmarks mais dérive en production, exactement le type de défaillance silencieuse qui est le plus dangereux lorsque les décisions de l’agent ont de véritables conséquences commerciales.

Le règlement AI de l’UE et les cadres réglementaires croissants autour de la responsabilité de l’IA rendent cela plus difficile à ignorer, et les entreprises qui n’ont pas intégré la gouvernance dans leurs architectures d’agent accumulent une exposition à la conformité qui coûtera beaucoup plus cher à dénouer plus tard.

De la phase pilote à la production : ce qu’il faut vraiment

Les entreprises qui ferment l’écart de production sont celles qui corrigent la couche de données avant de construire la couche d’agent. Elles intègrent la gouvernance dans la conception, et non après que les dégâts ont été faits. Elles construisent l’observabilité dans l’architecture d’orchestration et exécutent la gestion du changement en parallèle avec la livraison technique. Elles traitent l’analyse du mode de défaillance comme une exigence de conception importante.

Selon les recherches sur l’IA d’entreprise de Deloitte, l’accès des travailleurs à l’IA a augmenté de 50 % en 2025 seul et la part des entreprises exécutant plus de 40 % de leurs projets d’IA en pleine production devrait doubler dans les six prochains mois. Les entreprises qui gagnent en ce moment ne sont pas celles qui ont les modèles les plus avancés. Ce sont celles qui ont construit l’infrastructure opérationnelle pour exécuter l’IA de manière fiable et l’ont fait avant de construire les agents.

Chaque entreprise qui exécute encore des pilotes non connectés devrait se concentrer sur la garantie que l’investissement dans les modèles et les interfaces est proportionnel à l’investissement dans la préparation des données et l’architecture de gouvernance qui déterminera si ces agents sortiront jamais de l’environnement de démonstration. C’est là que beaucoup d’entreprises échouent.

Jusqu’à ce que cela change, beaucoup de projets d’IA agente dans lesquels les entreprises ont investi des ressources et espéraient porter leurs fruits mourront sur la vigne.