Pourquoi vos agents d'IA s'effondrent : les 5 goulots
Tokens, harness, compréhension humaine : les 5 points de rupture qui font échouer les systèmes autonomes en production, expliqués simplement.
Imaginez une brigade de cuisine recrutée après des semaines d’auditions. Les cuisiniers sont talentueux, la salle est magnifique, et les répétitions se sont parfaitement déroulées. Puis vient le soir de la grande ouverture. Le fournisseur livre en retard, les bons de commande s’accumulent, le chef de salle ne comprend pas ce que la cuisine lui envoie. En une heure, le service s’effondre.
Ce scénario, chaque équipe qui déploie un agent d’IA en production finit par le vivre. L’agent fonctionnait en démo. Il échoue en production. Et la tentation est de conclure que le modèle n’est pas assez bon.
C’est rarement le bon diagnostic.
Un système autonome s’effondre presque toujours pour des raisons identifiables et prévisibles : des goulots d’étranglement qui n’ont pas été anticipés. On en distingue cinq, répartis en trois niveaux.
Niveau 1 - Les goulots cognitifs : dans la tête du modèle
Ces goulots sont liés aux limites physiques du modèle de langage lui-même. Ils ne se corrigent pas en changeant de fournisseur. Ils se gèrent en concevant le système différemment.
Goulot 1 : La limite des tokens - la mémoire de travail du cuisinier
Un modèle de langage n’a pas une mémoire infinie. Il dispose d’une fenêtre de contexte : un espace de travail borné dans lequel il peut tenir compte de toutes les informations disponibles avant de répondre.
Pensez au plan de travail d’un cuisinier. Si vous lui demandez de préparer un plat simple avec 10 ingrédients posés devant lui, il est à l’aise. Si vous en ajoutez 50, il commence à faire tomber des choses, à perdre de vue certains éléments, à se tromper d’ordre dans la recette.
Le modèle réagit de la même façon. Au-delà d’un certain volume de données injectées, il ne “lit” plus tout avec la même attention. Il commence à synthétiser, à résumer, à sauter des étapes. Et ce qu’il saute peut être précisément ce qui comptait.
La conséquence pratique : injecter l’intégralité d’un référentiel de 300 pages dans chaque requête n’est pas une stratégie de précision. C’est une stratégie de dilution. La réponse sera en apparence cohérente mais sera construite sur des informations partielles, sans que le système le signale.
La solution n’est pas un modèle avec une fenêtre de contexte plus grande. C’est un filtre qui sélectionne les bonnes informations avant de les injecter.
Goulot 2 : L’attention qui se dilue - ce qui se perd au milieu
Même quand la fenêtre de contexte est respectée, l’attention du modèle n’est pas uniforme. Les recherches sur les LLMs ont mis en évidence un phénomène appelé “Lost in the Middle” : un modèle retient bien ce qui se trouve au début d’un document et ce qui se trouve à la fin. Ce qui est au milieu a tendance à s’estomper.
Imaginez une recette de cuisine de quatre pages. Un cuisinier pressé va retenir les ingrédients listés en introduction et le dressage final décrit en conclusion. Mais l’étape critique de cuisson, mentionnée en page trois, risque de passer à la trappe.
Pour un agent chargé d’analyser un contrat de 80 pages, cela signifie qu’une clause d’exclusion de responsabilité placée au milieu du document a statistiquement moins de chances d’être correctement prise en compte qu’un titre en page un ou une conclusion en page quatre-vingts.
Ce goulot a une implication directe sur la conception des documents que vous fournissez à vos agents. Les informations critiques ne doivent pas être enfouies. Elles doivent être structurées, isolées, et idéalement transmises comme des fragments ciblés plutôt que comme un bloc monolithique.
Niveau 2 - Les goulots d’ingénierie : dans le harness
Ces goulots concernent l’environnement technique autour du modèle : les outils que l’agent utilise pour agir, les APIs qu’il interroge, et les traces qu’il laisse (ou ne laisse pas).
Goulot 3 : La latence et la fragilité des outils externes
Un agent autonome n’agit pas seul. Il s’appuie sur des outils externes : une API réglementaire, une base de données interne, un outil de génération de fichiers. Sa performance est donc directement tributaire de la performance de ces outils.
C’est le fournisseur qui livre les légumes avec deux heures de retard. La brigade est compétente. La cuisine est prête. Mais sans ingrédients, le service s’arrête.
En pratique, une API qui répond en temps normal en 200 millisecondes peut, sous charge ou en cas d’incident, répondre en 8 secondes ou ne pas répondre du tout. Un agent non préparé à cette situation va soit attendre indéfiniment, soit échouer sans explication, soit - et c’est le cas le plus dangereux - continuer à fonctionner en ignorant l’erreur et produire un résultat faux présenté comme valide.
Ce goulot se gère par la conception du harness : des mécanismes de timeout explicites, des stratégies de retry exponentiel (si l’outil ne répond pas, on attend 1 seconde, puis 2, puis 4 avant d’abandonner proprement), et des modes de dégradation gracieuse qui indiquent clairement à l’utilisateur que la réponse est partielle.
Goulot 4 : L’absence d’observabilité - piloter dans le noir
Ce goulot est l’un des plus insidieux parce qu’il ne se manifeste pas immédiatement. Un agent sans système de traces peut fonctionner pendant des semaines avant qu’un problème ne soit détecté. Et au moment où on le détecte, il est impossible de remonter à la cause.
L’analogie de la cuisine : imaginez un restaurant sans bon de commande, sans ticket de caisse, sans registre de service. Personne ne sait quel plat a été servi à quelle table, à quelle heure, par quel cuisinier. Si un client tombe malade le lendemain, l’enquête est impossible.
Sans observabilité, chaque décision intermédiaire d’un agent est une boîte noire. On connaît l’entrée et la sortie. Mais on ne sait pas pourquoi l’agent a choisi d’appeler cet outil plutôt qu’un autre, pourquoi il a inclus cette information et pas celle-là, ni combien de tokens cette requête a consommé.
Ce qu’un système de production doit tracer de façon systématique :
- Chaque appel d’outil avec ses paramètres et sa durée de réponse.
- Chaque décision intermédiaire avec le raisonnement associé.
- Le coût en tokens de chaque échange.
- Les erreurs et les comportements inattendus, avec leur contexte complet.
L’observabilité n’est pas un luxe de grande entreprise. C’est la condition minimale pour qu’un agent soit auditable et améliorable.
Niveau 3 - Le goulot humain : le plus sous-estimé
Les quatre goulots précédents sont techniques. Ils ont des solutions techniques. Ce cinquième goulot est organisationnel. Il est souvent le plus coûteux, et il est presque toujours ignoré jusqu’au premier incident grave.
Goulot 5 : La compréhension humaine et la confiance mal calibrée
Ce goulot se manifeste sous trois formes distinctes.
a) La boîte noire opaque
Si le professionnel qui utilise l’agent ne comprend pas ce qu’il fait ni comment il prend ses décisions, deux choses se produisent. Soit il lui fait une confiance aveugle et valide sans vérifier. Soit il ne lui fait aucune confiance et relit tout manuellement. Dans les deux cas, le système ne fonctionne pas comme prévu.
C’est le chef de salle qui ne comprend pas ce que fait la cuisine. Il ne sait pas quand il doit intervenir, ni quand il peut laisser la brigade travailler seule. Il finit soit par bloquer toutes les assiettes au passe, soit par envoyer des plats sans les regarder.
La solution n’est pas de rendre l’agent plus simple. C’est de concevoir des interfaces de transparence : des résumés de raisonnement lisibles par un non-technicien, des indicateurs de confiance, et des alertes explicites quand l’agent est hors de son domaine de certitude.
b) Le handoff flou : qui décide quoi ?
C’est le goulot organisationnel le plus coûteux. L’agent prend une décision. L’humain aurait dû valider. Mais personne n’avait défini la frontière entre les deux.
Résultat : soit l’agent agit sur des périmètres qui ne lui ont pas été délégués, soit l’humain valide systématiquement tout et le gain de temps est nul.
Ce n’est pas une question de technologie. C’est une question de gouvernance. Avant tout déploiement, il faut définir explicitement :
- Quelles décisions peuvent être prises par l’agent sans validation humaine.
- Quelles décisions nécessitent une validation légère (une revue rapide avant envoi).
- Quelles décisions ne peuvent jamais être déléguées à un système automatique.
Cette liste doit être écrite, partagée et révisée régulièrement. Elle n’est pas figée : elle évolue à mesure que la confiance dans le système se construit.
c) La confiance mal calibrée
Il existe deux modes de confiance dysfonctionnels.
L’over-trust (confiance excessive) : l’utilisateur valide tout sans lire. L’agent peut propager une erreur factuelle dans un rapport officiel, compléter un formulaire avec une donnée incorrecte, ou prendre une décision réglementaire sur la base d’un article mal interprété. Le risque n’est pas dans la machine. Il est dans la délégation sans vérification.
L’under-trust (méfiance excessive) : l’utilisateur relit et corrige tout systématiquement. Le gain de temps est proche de zéro, les équipes perçoivent l’outil comme une charge supplémentaire plutôt qu’une aide, et le projet d’automatisation finit par être abandonné discrètement.
La bonne calibration repose sur une règle simple : faire confiance à l’agent sur les tâches à faible enjeu et haute répétabilité, valider systématiquement les décisions irréversibles ou engageantes. Cette règle ne se découvre pas en théorie. Elle se construit par l’expérience, les incidents mineurs bien documentés, et les revues régulières du périmètre de délégation.
Les goulots ne sont pas des bugs
Un goulot d’étranglement n’est pas un défaut de conception qu’un patch corrigera. C’est une propriété structurelle de tout système complexe. Les ingénieurs aéronautiques ne cherchent pas à supprimer la résistance de l’air. Ils conçoivent des ailes qui travaillent avec elle.
La même logique s’applique aux systèmes autonomes. La limite des tokens existe. L’attention dégradée existe. Les APIs tombent. Les humains ont du mal à calibrer leur confiance dans des systèmes qu’ils ne comprennent pas entièrement. Ces contraintes sont réelles et permanentes.
Mais elles sont toutes prévisibles avant le déploiement.
La différence entre un agent qui s’effondre le soir de la grande ouverture et une brigade qui tient tout un service, c’est que la seconde avait anticipé ce qui pouvait mal tourner - et avait conçu le système en conséquence.