Pourquoi les agents d'IA cassent en production (et comment l'éviter)
La démo marche toujours ; c'est en production que les agents échouent en silence. Les cinq modes de défaillance que je vois le plus, pourriture du contexte, prolifération de sous-agents, absence de vérification, absence d'évals, autonomie sans limites, et comment concevoir autour de chacun.
Guillaume Rufenacht
Product Manager IA · Lisbonne
La démo marche toujours. C’est le piège. Un agent qui assure une présentation léchée sur scène va se dégrader en silence dès qu’il encaisse du vrai trafic, de vrais cas limites et un an d’exigences accumulées. L’écart entre “ça marche en démo” et “ça marche en production”, c’est là que meurent la plupart des projets d’IA, et les échecs sont assez prévisibles pour qu’on les anticipe dès la conception.
Garder des agents fiables à grande échelle, c’est le cœur de mon travail sur les pipelines derrière Geonimo. Voici les modes de défaillance que je vois le plus, et comment couper court à chacun.
Key takeaways
- La plupart des échecs en production sont des problèmes de contexte, pas de modèle : prompts surchargés, contradictions, informations manquantes.
- La prolifération de sous-agents crée des ruptures de communication ; la complexité ajoutée pour gagner en capacité finit par coûter en fiabilité.
- Sans vérification ni évals, vous ne pouvez pas savoir si un changement a aidé, alors la qualité dérive en silence.
- Un coût et une latence sans limites, et donner aux agents l'autonomie sur des actions à fort enjeu, transforment de petites erreurs en erreurs coûteuses.
- Les correctifs : simplifier, rendre la vérification native pour l'agent, mesurer avec des évals, borner le budget, et garder un humain là où les erreurs coûtent cher.
Défaillance 1 : la pourriture du contexte
La plus courante. Vous livrez un agent, puis vous lui greffez des capacités pendant des mois jusqu’à ce que le system prompt soit des centaines de lignes de règles à moitié contradictoires. Le modèle se met à faire des erreurs “bêtes”, et tout le monde accuse le modèle, alors que le vrai problème, c’est le contexte dont vous l’avez entouré. Le correctif, c’est le context engineering : gardez dans le system prompt ce qui est nécessaire à chaque fois, déplacez le reste dans des skills que l’agent va chercher à la demande, et donnez-lui le contexte minimal suffisant plutôt que tout ce que vous avez.
Défaillance 2 : la prolifération de sous-agents
Chaque nouvelle exigence devient un nouveau sous-agent jusqu’à ce que vous ayez un enchevêtrement d’instances qui se passent du travail les unes aux autres. Le coût caché, c’est la communication : la rupture entre un orchestrateur et ses sous-agents est une défaillance de production classique et difficile à déboguer. Le correctif, c’est d’aller chercher la bonne primitive de façon délibérée, et souvent de réabsorber la capacité dans un agent principal plus simple, ce que je détaille dans outil, skill ou sous-agent ?.
Défaillance 3 : pas de vraie vérification
Les équipes assimilent la vérification aux tests unitaires et au linting, qui étaient déjà automatisés. La vérification qui compte pour les agents est différente : l’agent peut-il exécuter la chose et confirmer qu’elle a réellement fonctionné ? Sans cela, un agent ne peut pas opérer sans surveillance en toute sécurité, et vous revenez à le materner. Rendez la vérification native à l’artefact pour que l’agent puisse contrôler sa propre sortie, l’habitude au centre de la façon dont l’équipe d’Anthropic travaille.
Défaillance 4 : naviguer à l’aveugle sans évals
Si vous ne pouvez pas mesurer si un changement a amélioré l’agent, la qualité dérive et vous ne le remarquerez pas avant qu’un client ne le fasse. Les agents en production ont besoin d’une suite d’évals, cas de contrôle, cas limites connus, limites de capacité, contre laquelle vous progressez pas à pas : établir une base, changer une seule chose, relancer, garder ce qui aide. C’est la différence entre faire de l’ingénierie et espérer.
Défaillance 5 : coût sans limites, et trop d’autonomie
Les agents échangent du contrôle contre de la capacité. Contrairement à un workflow figé, un agent peut explorer, et brûler des tokens, de la latence et de l’argent en le faisant. Pire, si vous lui donnez l’autonomie sur des actions dont les erreurs sont à fort enjeu et difficiles à détecter, une petite erreur en devient une coûteuse. La discipline, c’est de ne pas construire un agent là où un workflow suffirait, de borner le budget, et de garder un humain dans la boucle exactement là où le coût de l’erreur est élevé. L’autonomie, ça se gagne, capacité par capacité, ce n’est pas un réglage par défaut que vous activez.
Le fil conducteur
Comment garder des agents en vie en production
Mettez les correctifs bout à bout et un schéma se dégage : gardez l’architecture aussi simple que la tâche le permet, ingénierez le contexte au lieu de l’empiler, faites de la vérification quelque chose que l’agent fait lui-même, mesurez tout avec des évals, et bornez le coût tout en gardant des humains sur les décisions à fort enjeu. Ce n’est pas une contrainte sur l’ambition, c’est ce qui rend les agents ambitieux fiables. Faire passer l’IA d’un prototype astucieux à quelque chose auquel on peut se fier en production, c’est exactement le travail que je fais.
À retenir
Une IA fiable en production, c’est ce que je construis, chez Geonimo et au-delà. Voyez ce que j’ai livré ou contactez-moi.
Questions fréquentes
Pourquoi les agents d'IA marchent-ils en démo mais échouent-ils en production ?
Parce que les démos évitent ce qui casse les agents à grande échelle : contexte accumulé, vrais cas limites, limites de coût et actions à fort enjeu. La plupart des échecs en production sont des problèmes de contexte et de conception, pas une faiblesse du modèle.
Quel est le mode de défaillance le plus courant d'un agent ?
La pourriture du contexte. Le system prompt grossit pendant des mois en instructions surchargées et contradictoires, et le modèle fait des erreurs à cause du contexte qui l'entoure, pas parce qu'il est faible.
Comment rendre un agent d'IA fiable ?
Simplifiez l'architecture, ingénierez le contexte au lieu de l'empiler, faites de la vérification quelque chose que l'agent fait lui-même, mesurez avec une suite d'évals contre laquelle vous progressez pas à pas, et bornez le coût tout en gardant un humain sur les actions à fort enjeu.
Quand faut-il garder un humain dans la boucle ?
Partout où le coût d'une erreur est élevé et où les erreurs sont difficiles à détecter. L'autonomie se gagne capacité par capacité ; pour les actions à fort enjeu, un accès en lecture seule ou une validation humaine est l'option par défaut la plus sûre.
Travailler avec moi
Vous voulez un système comme celui-ci pour votre pipeline ?
J'aide les équipes à faire passer l'IA d'un prototype malin à une production fiable : moteurs d'outbound, intelligence des leads et les pipelines LLM en dessous. Voyez ce que j'ai livré ou écrivez-moi.