Imaginez un agent autonome chargé de déployer une infrastructure cloud complexe. À la troisième étape, il hallucine un paramètre de configuration, ce qui fait planter tout le pipeline. Dans un chatbot classique, c'est un simple message d'erreur. Pour un agent capable d'agir sur le monde réel, c'est une catastrophe potentielle. La réalité est que les agents LLM ne tombent pas en panne comme des logiciels traditionnels ; ils dérivent, s'embrouillent ou ignorent silencieusement un échec.
Le vrai problème, c'est la non-déterminisme. Un modèle de langage peut réussir une tâche dix fois et échouer la onzième avec une réponse parfaitement formatée mais totalement fausse. Pour transformer ces prototypes en systèmes de production fiables, on ne peut plus se contenter de simples boucles de "retry". Il faut une architecture de récupération pensée comme un filet de sécurité à plusieurs couches.
Comprendre la nature des pannes agentiques
Pour réparer un système, il faut d'abord savoir ce qui s'est cassé. Contrairement aux erreurs de syntaxe classiques, les pannes d'agents sont souvent sémantiques. On peut les classer selon le cadre SHIELDA, qui identifie des exceptions à travers trois phases critiques :
- La phase de raisonnement : L'agent formule une logique erronée ou fait une supposition fausse sur l'état de l'environnement.
- La phase de planification : L'agent crée un plan d'action où les étapes sont mal ordonnées ou redondantes.
- La phase d'exécution : L'agent appelle un outil, mais la réponse de l'API est invalide ou l'action échoue silencieusement.
Cette distinction est capitale. Si l'erreur vient du raisonnement, relancer la même commande ne servira à rien. Il faudra changer la stratégie de réflexion ou le prompt utilisé.
La validation de schéma : le premier rempart
L'une des erreurs les plus courantes est le formatage. Un agent doit souvent sortir du JSON pour appeler une fonction, mais il peut ajouter du texte superflu ou oublier une virgule. La solution consiste à ne jamais faire confiance à la sortie brute du modèle.
L'utilisation de bibliothèques comme Pydantic permet de définir des contrats stricts. Si la réponse ne respecte pas le schéma, le système ne la transmet pas à l'outil. Au lieu de cela, elle est envoyée vers un agent de sanitation spécialisé qui corrige la structure avant de tenter une nouvelle validation. C'est ce qu'on appelle une approche "validation-first".
| Type d'erreur | Symptôme | Mécanisme de récupération |
|---|---|---|
| Syntaxique / Schéma | JSON malformé, type incorrect | Agent de sanitation → Re-génération |
| Sémantique | Logique fausse, hallucination | Fallback de prompts (templates alternatifs) |
| Exécution | API timeout, erreur 500 | Exponential backoff / Retry intelligent |
| État | Action réussie mais effet absent | Vérification d'état → Re-planification |
L'orchestration de la récupération par couches
Toutes les erreurs ne demandent pas la même intelligence pour être résolues. Une approche efficace utilise une chaîne de responsabilité avec une dégradation gracieuse. On structure le système en trois niveaux :
- L'Agent Primaire : Il possède toute la capacité de raisonnement. S'il échoue, il tente d'abord d'analyser son erreur et de s'auto-corriger.
- L'Agent de Récupération : Si le primaire boucle, cet agent intervient avec une logique basée sur des templates. Il reconnaît des motifs d'échec courants et applique une solution pré-définie.
- Le Fallback d'Urgence : C'est le dernier recours. Il s'agit soit de règles rigides (hard-coded), soit d'une escalade vers un humain.
Ce modèle évite que le système ne s'effondre complètement. Dans un contexte de gestion financière, par exemple, on préférera stopper l'exécution et demander une validation humaine plutôt que de laisser un agent "inventer" une solution pour corriger un solde bancaire erroné.
Gestion de la mémoire et état du workflow
Les agents à long terme souffrent souvent de corruption de mémoire. Des informations obsolètes peuvent entrer en conflit avec des données récentes, créant des contradictions sémantiques. Pour contrer cela, il faut implémenter des mécanismes de "oubli sélectif" et de filtrage basé sur les attributs.
Une autre technique cruciale est le checkpointing. Au lieu de redémarrer tout un workflow de dix étapes après une erreur à l'étape neuf, le système sauvegarde l'état après chaque action réussie. Si une panne survient, on "rembobine" le plan vers le dernier point stable. Pour les actions destructives (comme la modification de fichiers), on utilise des formats réversibles, tels que des stashes Git, pour permettre un rollback total sans laisser de traces de corruption.
Vérification d'état : détecter les échecs silencieux
C'est le piège le plus dangereux : l'agent reçoit un code "200 OK" de l'API, mais l'action n'a pas eu l'effet escompté. Par exemple, un agent croit avoir créé un fichier de configuration, mais le disque était plein et le fichier est vide.
La solution est d'imposer une phase de vérification post-exécution. L'agent ne doit pas passer à l'étape suivante tant qu'une requête de vérification n'a pas confirmé le changement d'état. S'il y a divergence entre l'état attendu et l'état réel, le système déclenche immédiatement une re-planification avec le motif d'erreur précis (ex: "fichier_manquant").
L'humain dans la boucle (Human-in-the-Loop)
On ne peut pas automatiser la récupération à 100 %, surtout pour des tâches critiques. L'intégration de l'humain doit être stratégique et non accidentelle. Les systèmes modernes proposent des visualisations de plans et des "diffs" de modification avant toute action irréversible.
L'idée est de transformer l'erreur en donnée d'entraînement. Lorsqu'un humain corrige une action d'agent, cette correction est capturée pour affiner les prompts et les stratégies de fallback. L'humain ne sert pas seulement de filet de sécurité, il devient le superviseur qui améliore la robustesse du système.
Quelle est la différence entre un simple "retry" et une politique de récupération ?
Un simple retry consiste à renvoyer la même requête en espérant un résultat différent, ce qui est inefficace pour les erreurs sémantiques. Une politique de récupération analyse la cause de l'échec (ex: erreur de schéma vs erreur de logique) et adapte la stratégie, par exemple en changeant le prompt, en utilisant un agent de sanitation ou en remontant à un checkpoint précédent.
Comment gérer les hallucinations dans un flux de travail multi-étapes ?
La meilleure méthode est la validation systématique à chaque étape. On utilise des schémas Pydantic pour le format et des requêtes de vérification d'état pour s'assurer que l'action a réellement produit l'effet voulu dans le monde extérieur. Si une hallucination est détectée, le système déclenche un mécanisme de re-planification.
C'est quoi le framework SHIELDA ?
SHIELDA est un cadre de recherche qui propose une taxonomie structurée des exceptions pour les agents LLM. Il classifie les erreurs selon trois phases (raisonnement, planification, exécution) et suggère des patterns de gestion spécifiques pour chacune, permettant une récupération plus granulaire et efficace.
Pourquoi utiliser plusieurs templates de prompts pour la récupération ?
À cause de la nature non-déterministe des LLM. Un prompt qui échoue peut être débloqué par une légère variation dans la formulation, l'ordre des instructions ou les contraintes imposées. En ayant un registre de templates alternatifs, on augmente les chances de succès sans modifier le modèle lui-même.
Quand doit-on escalader l'erreur vers un humain ?
L'escalade est nécessaire lorsque les trois couches de récupération (primaire, spécialisé, urgence) ont échoué, ou lorsque l'action à entreprendre est jugée trop risquée (ex: suppression de données de production). L'intervention humaine est également cruciale pour résoudre des ambiguïtés majeures dans l'intention de l'utilisateur.