Échapper au mirage prototype : pourquoi l’IA d’entreprise stagne

Cet article a été co-écrit par Reya Vir et Rahul Vir.

a fondamentalement changé à l’ère GenAI. Avec l’omniprésence des outils de codage d’ambiance et des IDE axés sur les agents comme Antigravity de Google, le développement de nouvelles applications n’a jamais été aussi rapide. De plus, les concepts puissants inspirés des frameworks viraux open source comme OpenClaw permettent la création de systèmes autonomes. Nous pouvons déposer des agents en sécurité Harnaisfournissez-leur l’exécutable Python Compétenceset définir leur Personnages système dans de simples fichiers Markdown. Nous utilisons le récursif Boucle Agentique (Observer-Think-Act) pour l’exécution, configurer le mode sans tête Passerelles pour les connecter via des applications de chat, et compter sur État de mue pour conserver la mémoire lors des redémarrages à mesure que les agents s’améliorent eux-mêmes. Nous leur donnons même un Jeton de non-réponse afin qu’ils puissent produire du silence au lieu de leur nature bavarde habituelle.

Construire des agents autonomes a été un jeu d’enfant. Mais la question demeure : si la construction est si fluide aujourd’hui, pourquoi les entreprises voient-elles un flot de prototypes et une fraction remarquablement petite d’entre eux se transforment-elles en produits réels ?

1. L’illusion du succès :

Lors de mes discussions avec les dirigeants d’entreprise, je vois d’innombrables prototypes développés au sein des équipes, prouvant qu’il existe un immense intérêt ascendant dans la transformation d’applications logicielles fatiguées et rigides en agents d’assistance entièrement automatisés. Toutefois, ces premiers succès sont trompeurs. Un agent peut brillamment performer dans un notebook Jupyter ou dans une démo mise en scène, générant suffisamment d’enthousiasme pour mettre en valeur son expertise en ingénierie et obtenir des financements, mais il survit rarement dans le monde réel.

Cela est dû en grande partie à une augmentation soudaine du codage vibratoire qui donne la priorité à l’expérimentation rapide plutôt qu’à une ingénierie rigoureuse. Ces outils sont formidables pour développer des démos, mais sans discipline structurelle, le code résultant n’a pas la capacité et la fiabilité nécessaires pour créer un produit de production. [Why Vibe Coding Fails]. Une fois que les ingénieurs retournent à leur travail quotidien, le prototype est abandonné et commence à se détériorer, tout comme les logiciels non entretenus.

En fait, le problème de la maintenabilité est plus profond. Si les humains sont parfaitement capables de s’adapter à l’évolution naturelle des workflows, les agents ne le sont pas. Un changement subtil de processus métier ou un changement de modèle sous-jacent peut rendre l’agent inutilisable.

Un exemple de soins de santé: Disons que nous avons un Agent d’accueil des patients conçu pour trier les patients, vérifier l’assurance et planifier des rendez-vous. Dans une démo codée en ambiance, il gère parfaitement les contrôles standard. Utiliser un Porteil discute avec les patients par messagerie texte. Il utilise des bases Compétences pour accéder à l’API d’assurance, et à ses Personnalité du système donne un ton poli et clinique. Mais dans une clinique en direct, l’environnement est saturé et désordonné. Si un patient mentionne une douleur thoracique au cours d’une prise de routine, l’agent Boucle Agentique doit reconnaître instantanément l’urgence, abandonner le flux de planification et déclencher une escalade de sécurité. Il devrait utiliser le Jeton de non-réponse pour supprimer les discussions de réservation tout en acheminant le contexte vers une infirmière humaine. La plupart des prototypes échouent de façon spectaculaire à ce test.

Aujourd’hui, une grande majorité d’initiatives prometteuses poursuivent un « prototype mirage » : un flux incessant d’agents de preuve de concept qui semblent productifs lors des premiers essais mais disparaissent lorsqu’ils sont confrontés à la réalité de l’environnement de production.

2. Définir le mirage prototype

Le Prototype Mirage est un phénomène dans lequel les entreprises mesurent leur succès en fonction du succès des démonstrations et des premiers essais, pour ensuite les voir échouer en production en raison de problèmes de fiabilité, d’une latence élevée, de coûts ingérables et d’un manque fondamental de confiance. Cependant, il ne s’agit pas d’un bug pouvant être corrigé, mais d’une défaillance systémique de l’architecture.

Les principaux symptômes comprennent :

• Fiabilité inconnue: La plupart des agents ne répondent pas aux exigences strictes des entreprises en matière d’accords de niveau de service (SLA). Alors que les erreurs au sein des systèmes mono- ou multi-agents s’aggravent à chaque action (c’est-à-dire la décroissance stochastique), les développeurs limitent leur pouvoir d’action. Exemple : Si l’agent d’accueil des patients s’appuie sur un grand livre d’état partagé pour assurer la coordination entre un « sous-agent de planification » et un « sous-agent d’assurance », une hallucination à l’étape 12 d’un processus de vérification d’assurance en 15 étapes fait dérailler l’ensemble du flux de travail. UN étude récente montre que 68 % des agents de production sont volontairement limités à 10 étapes ou moins pour éviter les déraillements.
• Fragilité de l’évaluation: La fiabilité reste une variable inconnue car 74 % des agents s’appuient sur l’évaluation Human-in-the-loop (HITL). Bien qu’il s’agisse d’un point de départ raisonnable compte tenu de l’utilisation d’agents dans ces domaines hautement spécialisés où les références publiques sont insuffisantes, l’approche n’est ni évolutive ni maintenable. Passer à des évaluations structurées et à un LLM en tant que juge est la seule voie durable à suivre (Pan et coll., 2025).
• Dérive du contexte: Les agents sont souvent conçus pour capturer les flux de travail humains existants. Cependant, les processus métier évoluent naturellement. Exemple : si l’hôpital met à jour ses niveaux Medicaid acceptés, l’agent ne dispose pas de l’introspection ou de la boucle métacognitive pour analyser ses propres journaux d’échecs et s’adapter. Ses chaînes d’invite rigides se brisent dès que l’environnement s’écarte du contexte de formation, rendant l’agent obsolète.

3. Alignement sur les OKR d’entreprise

Chaque entreprise fonctionne sur un ensemble d’objectifs et de résultats clés (OKR) définis. Pour briser cette illusion, nous devons considérer ces agents comme des entités chargées d’optimiser des indicateurs commerciaux spécifiques.

Alors que nous visons une plus grande autonomie – permettant aux agents de comprendre l’environnement et de s’adapter continuellement pour relever les défis sans intervention humaine constante – ils doivent être conscients du véritable objectif d’optimisation.

Les OKR fournissent un objectif supérieur à atteindre (par exemple, réduire les temps d’attente critiques pour les patients de 20 %) plutôt qu’un objectif intermédiaire (par exemple, traiter 50 formulaires d’admission par heure). En comprenant l’OKR, notre agent d’accueil des patients peut ainsi détecter de manière proactive les signaux qui vont à l’encontre de l’objectif de temps d’attente des patients et y remédier avec une implication humaine minimale.

Des recherches récentes de Berkeley CMR encadre cela dans la théorie principal-agent. Le « Principal » est la partie prenante responsable de l’OKR. Le succès dépend de la délégation de l’autorité à l’agent de manière à aligner les incitations, garantissant qu’il agit dans l’intérêt du mandant, même lorsqu’il agit inaperçu.

Cependant, l’autonomie se mérite et ne s’acquiert pas dès le premier jour. Le succès suit un modèle d’autonomie guidée :

• Connus Connus: Commencez par des cas d’utilisation formés avec des garde-fous stricts (par exemple, l’agent ne s’occupe que des examens physiques de routine et de la vérification d’assurance de base).
• Escalade: L’agent reconnaît les cas extrêmes (par exemple, des symptômes contradictoires) et les transmet aux infirmières de tri plutôt que de deviner.
• Évolution: À mesure que l’agent acquiert une meilleure traçabilité des données et démontre un alignement avec les OKR, une plus grande liberté d’action est accordée (par exemple, gestion des références de spécialistes).

4. La voie à suivre

Une stratégie prudente à long terme est essentielle pour transformer ces prototypes en véritables produits évolutifs dans le temps. Nous devons comprendre que les applications agentiques doivent être développées, évoluées et entretenues pour passer de simples assistants à des entités autonomes, tout comme les applications logicielles. Les mirages codés par vibration ne sont pas des produits, et vous ne devriez faire confiance à personne qui dit le contraire. Il s’agit simplement de preuves de concept pour un retour d’information précoce.

Pour échapper à cette illusion et obtenir un réel succès, nous devons apporter alignement du produit et discipline d’ingénierie au développement de ces agents. Nous devons construire des systèmes pour lutter contre les difficultés spécifiques de ces modèles, telles que celles identifiées dans 9 modèles de défaillance critiques.

Au cours des prochaines semaines, cette série vous guidera à travers les piliers techniques nécessaires à la transformation de votre entreprise.

• Fiabilité: Passage de « Vibes » aux Golden Datasets et au LLM-as-a-Judge (afin que notre agent d’admission des patients puisse être testé en continu par rapport à des milliers d’histoires de patients complexes simulées).
• Économie: Maîtriser l’économie des jetons pour optimiser le coût des workflows agents.
• Sécurité: Implémentation de la sécurité agent via le lignage de données et le contrôle de flux.
• Performance: Atteindre les performances des agents à grande échelle pour améliorer la productivité.

Le passage d’un « prototype » à un « déployé » ne consiste pas à corriger des bugs ; il s’agit de construire un architecture fondamentalement meilleure.

Références

1. Vir, R., Ma J., Sahni R., Chilton L., Wu, E., Yu Z., Columbia DAPLab. (7 janvier 2026). Pourquoi le codage Vibe échoue et comment y remédier. Laboratoire de données, d’agents et de processus, Université de Columbia. https://daplab.cs.columbia.edu/general/2026/01/07/why-vibe-coding-fails-and-how-to-fix-it.html
2. Pan, MZ, Arabzadeh, N., Cogo, R., Zhu, Y., Xiong, A., Agrawal, LA,… et Ellis, M. (2025). Agents de mesure en production. arXiv. https://arxiv.org/abs/2512.04123
3. Jarrahi, MH et Ritala, P. (23 juillet 2025). Repenser les agents IA : une perspective principal-agent. Examen de la direction de Berkeley en Californie. https://cmr.berkeley.edu/2025/07/rethinking-ai-agents-a-principal-agent-perspective/
4. Vir, R., Columbia DAPLab. (8 janvier 2026). 9 modèles de défaillances critiques des agents de codage. Laboratoire de données, d’agents et de processus, Université de Columbia. https://daplab.cs.columbia.edu/general/2026/01/08/9-critical-failure-patterns-of-coding-agents.html

Toutes les images générées par Nano Banana 2