Un agent IA qui boucle, qui dérape ou dont la facture API triple en un mois n'a presque jamais un problème d'intelligence du modèle. Le problème est structurel : absence de condition d'arrêt, contexte renvoyé en entier à chaque tour, permissions trop larges. Trois familles de dérapage distinctes, chacune avec son diagnostic et sa correction propres.
On distingue ici la trajectoire (l'agent tourne sans converger), le coût (la facture grimpe sans que personne ne le voie venir) et le risque d'action (l'agent fait quelque chose qu'il n'aurait jamais dû faire). Les confondre, c'est traiter le symptôme du mauvais problème, et perdre du temps sur la mauvaise urgence.
Ce qui suit est un protocole de diagnostic, pas une liste de bonnes pratiques génériques : pour chaque famille, le symptôme observable, la mesure à instrumenter dans l'heure, et la correction classée par ordre de priorité.
Ce qu'il faut retenir
- Trajectoire : l'agent rappelle le même outil sans progresser, faute de condition d'arrêt ou d'état bien géré
- Coût : perte de cache de prompt, contexte renvoyé intégralement, modèle surdimensionné, absence de plafond
- Risque d'action : permissions trop larges, aucune validation humaine avant une action irréversible
- Ordre de traitement quand tout se cumule : couper le risque d'abord, plafonner la trajectoire ensuite, optimiser le coût en dernier
- Le diagnostic des permissions et des trajectoires est ce qui demande le plus souvent un regard extérieur
Les trois familles de dérapage d'un agent IA en production
Un agent IA en production dérape de trois façons distinctes : la trajectoire (il tourne en boucle sans converger), le coût (la facture grimpe sans alerte visible) et le risque d'action (il exécute quelque chose d'irréversible). Chaque famille a sa propre cause racine et sa propre correction. Les traiter avec le même remède ne fait qu'aggraver la situation.
| Famille | Symptôme | Cause typique |
|---|---|---|
| Trajectoire | L'agent rappelle le même outil, le temps d'exécution explose, jamais de réponse finale | Pas de condition d'arrêt, outil mal décrit, état mal propagé |
| Coût | Facture qui double ou triple sans hausse de trafic correspondante | Perte de cache de prompt, contexte renvoyé en entier, modèle surdimensionné |
| Risque d'action | Une action irréversible a été exécutée sans validation humaine | Permissions trop larges, secrets accessibles hors périmètre |
La plupart des équipes découvrent une seule de ces familles à la fois, généralement celle qui casse quelque chose de visible. Les deux autres tournent souvent en silence depuis des semaines. C'est pour ça qu'un diagnostic doit balayer les trois, même quand une seule s'est manifestée bruyamment.
Famille 1 : la boucle et la trajectoire hors de contrôle
Un agent boucle quand il répète le même appel d'outil sans que le résultat change ni que son état interne progresse. La cause n'est presque jamais le modèle : c'est l'absence de condition d'arrêt explicite, une description d'outil ambiguë, ou un état mal propagé entre deux tours de raisonnement.
Le symptôme observable
Le même outil est appelé avec des paramètres identiques ou quasi identiques, tour après tour, sans que le résultat diffère assez pour faire avancer la décision de l'agent. Le temps d'exécution s'allonge de façon anormale, les logs défilent, rien ne casse visiblement. C'est justement ce qui rend le problème dangereux : ça ressemble à un agent qui travaille, pas à un agent en panne.
Deuxième signal fréquent : l'agent reformule la même question de clarification en boucle, parce qu'il n'a jamais reçu de réponse exploitable et qu'aucune règle ne lui dit de s'arrêter après N tentatives.
La mesure à instrumenter
Trois compteurs suffisent pour détecter une trajectoire hors de contrôle avant qu'elle ne coûte cher :
- Budget d'itérations consommé par exécution, comparé au plafond fixé
- Taux d'appels d'outils identiques consécutifs : au delà de trois appels avec les mêmes arguments, l'exécution doit être considérée comme suspecte
- Taux de complétion contre timeout par type de tâche, sur les sept derniers jours
La correction et l'ordre de priorité
Dans l'ordre, du plus urgent au plus structurel :
- Plafonner les itérations. C'est la protection la plus simple et la plus rapide à poser, entre 5 et 10 tours selon la complexité de la tâche.
- Ajouter une détection de redondance qui coupe l'exécution après trois appels identiques consécutifs, avant même d'atteindre le plafond.
- Clarifier les descriptions d'outils et réduire le nombre d'outils disponibles à ce qui est strictement nécessaire à la tâche. Un agent qui a le choix entre douze outils fait des choix moins prévisibles qu'un agent qui en a quatre.
- Séparer raisonnement et exécution. C'est le pattern le plus fiable observé sur les agents IA n8n en production : l'agent produit un plan structuré, un système déterministe l'exécute. L'IA décide, l'automatisation agit. Ça élimine une grande partie des raccourcis imprévus.
Famille 2 : la facture qui explose sans prévenir
La facture API d'un agent IA grimpe pour quatre raisons cumulables : l'absence de cache de prompt, un contexte renvoyé intégralement à chaque tour, un modèle surdimensionné pour une tâche simple, et l'absence de plafond avec alerte. Sans observabilité par exécution, le problème se découvre sur la facture du mois suivant, jamais avant.
Le symptôme observable
La facture mensuelle double ou triple sans que le volume de requêtes ait suivi la même courbe. Le coût par exécution est très variable d'un jour à l'autre pour une tâche pourtant identique. Personne dans l'équipe ne sait répondre à la question "combien coûte une exécution normale de cet agent" avant de regarder la facture.
La mesure à instrumenter
Le mécanisme à connaître
Le cache de prompt fonctionne par correspondance de préfixe : tant que le début du prompt reste identique d'un appel à l'autre, le modèle réutilise le calcul déjà effectué, à un coût réduit. Le moindre octet modifié en amont (un horodatage inséré dynamiquement, l'ordre des messages système qui change) invalide tout le cache pour les tours suivants. C'est la cause la plus fréquente de facture qui dérape sur un agent multi tours.
Quatre métriques à suivre par exécution, pas seulement en cumul mensuel :
- Tokens consommés par exécution, ventilés par étape (planification, appel d'outil, synthèse)
- Taux de succès du cache de prompt, c'est le levier le plus rentable et le plus souvent ignoré
- Coût par type de tâche, pour repérer les tâches simples qui consomment un modèle lourd
- Budget quotidien réel contre budget cible, avec alerte automatique au franchissement de 80 %
La correction et l'ordre de priorité
- Stabiliser le préfixe du prompt. Contenu statique en tête, éléments variables repoussés en fin de prompt. C'est ce qui rend le cache exploitable, et c'est souvent un correctif d'une demi journée.
- Arrêter de renvoyer le contexte en entier à chaque tour. Un résumé structuré des tours précédents suffit dans la majorité des cas.
- Router vers un modèle plus léger pour le tri et le pré-filtrage, et réserver le modèle le plus puissant aux étapes qui exigent vraiment du raisonnement. Notre article sur le router hybride SLM/LLM détaille cette architecture et ses pièges.
- Poser un plafond budgétaire quotidien avec alerte automatique, pas seulement une limite de facturation côté fournisseur.
- Mettre en place une observabilité par exécution. Sans elle, chaque correction précédente reste invisible tant qu'elle ne s'est pas traduite sur la facture. Notre comparatif des outils d'évaluation et d'observabilité des LLM couvre les options pour PME et ETI.
Famille 3 : le risque d'action, quand l'agent fait ce qu'il n'aurait jamais dû faire
Le risque d'action se matérialise quand un agent dispose de permissions plus larges que sa tâche déclarée et qu'aucune validation humaine n'intercepte une action irréversible. Ce n'est pas un problème de modèle mal aligné : c'est un problème de cloisonnement des accès.
Le 25 avril 2026, un agent de codage autonome a supprimé en moins de dix secondes la base de données de production de l'éditeur PocketOS, ainsi que ses sauvegardes. L'agent avait trouvé, dans un fichier sans rapport avec sa tâche, un jeton d'accès à privilèges élevés, et l'a utilisé de sa propre initiative pour "corriger" un problème rencontré, sans validation humaine. Les analyses publiées ensuite convergent sur un point : la cause première n'est pas l'agent, c'est un jeton sans cloisonnement de périmètre et des sauvegardes stockées dans la même zone de risque que la production (The Register, avril 2026).
Le CERT-FR a publié le 13 avril 2026 le bulletin CERTFR-2026-ACT-016, qui déconseille les agents autonomes en production sur poste de travail et recommande un cantonnement en environnement de test isolé, sans données sensibles ni secrets, avec validation humaine obligatoire pour toute commande système.
Le symptôme observable
Personne dans l'équipe ne peut lister, en moins de cinq minutes, l'ensemble des identifiants et jetons auxquels l'agent a accès. Aucune distinction n'existe entre une action de lecture et une action d'écriture ou de suppression. Et surtout : aucun journal ne permet de reconstituer, après coup, pourquoi l'agent a pris une décision donnée.
La mesure à instrumenter
- Inventaire complet des identifiants accessibles depuis l'environnement d'exécution de l'agent, y compris ceux qui ne servent pas directement à sa tâche
- Ratio d'actions à capacité destructrice exécutées sans point de validation humaine, sur le total des actions possibles
- Temps nécessaire pour reconstituer une décision de l'agent à partir des logs disponibles aujourd'hui
La correction et l'ordre de priorité
- Appliquer le moindre privilège immédiatement. Chaque jeton est scopé au périmètre exact de la tâche, jamais un jeton d'administration partagé entre plusieurs systèmes.
- Isoler les sauvegardes dans une zone hors d'atteinte de l'environnement d'exécution de l'agent.
- Imposer une validation humaine sur toute action destructrice ou irréversible, avant exécution, pas après.
- Journaliser chaque décision dans un format consultable en quelques minutes, pas en heures.
Reconstruire cette cartographie des permissions après coup, sans document de référence, c'est précisément ce que fait un audit technique RAG et Agents IA quand un incident a déjà eu lieu, ou quand personne ne peut garantir que ça n'arrivera pas.
Priorité de traitement quand les dérapages se cumulent
Quand les trois familles se cumulent, l'ordre de traitement n'est pas arbitraire : le risque d'action se coupe en premier parce qu'il est irréversible, la trajectoire se plafonne en second parce qu'elle amplifie le coût, et le coût s'optimise en dernier parce qu'il ne met rien en danger, il use juste le budget.
| Priorité | Famille | Action immédiate | Délai |
|---|---|---|---|
| 1 | Risque d'action | Révoquer les jetons à privilèges larges, isoler les sauvegardes | Immédiat (minutes) |
| 2 | Trajectoire | Plafonner les itérations, couper l'exécution en cours si besoin | Sous 24 heures |
| 3 | Coût | Stabiliser le cache de prompt, router vers un modèle plus léger | Sous 1 à 2 semaines |
Gartner anticipait, dans une prévision publiée en 2025, que plus de 40 % des projets d'IA agentique seraient abandonnés d'ici fin 2027. Sur les dossiers observés, l'abandon vient rarement d'un modèle insuffisant. Il vient d'un dérapage de trajectoire, de coût ou de permissions qui n'a pas été diagnostiqué à temps, traité en pansement plutôt qu'à la racine, jusqu'à éroder la confiance de l'équipe métier.
Reprendre la main : par où commencer quand le diagnostic dépasse l'équipe interne
Reprendre la main sur un agent qui dérape suit toujours le même ordre : couper ce qui est dangereux, mesurer ce qui coûte, puis corriger la trajectoire. Une équipe interne peut souvent gérer les deux derniers points seule. Le premier exige plus fréquemment un regard extérieur, parce qu'il faut cartographier des permissions que personne n'a documentées au moment du déploiement.
Une fois l'agent stabilisé, la question suivante est de ne pas reproduire les mêmes angles morts. Le retour d'expérience sur les agents IA n8n en production détaille les patterns qui tiennent sur la durée : plafond d'itérations, checkpoints de validation, séparation entre raisonnement et exécution. Et pour clarifier, auprès d'un comité de direction, ce qu'un agent fait réellement par rapport à un simple chatbot, notre article agents IA vs chatbots pour PME pose les bases sans jargon.
Quand la boucle vient d'un système qui interroge des documents en plusieurs étapes plutôt que d'un simple appel d'outil, le problème est souvent une question d'architecture de recherche mal cadrée : notre article sur l'Agentic RAG détaille où cette approche est pertinente, et où elle ajoute de la complexité sans bénéfice.
Ce qui ne se corrige pas soi-même en une après-midi
Cartographier tous les jetons accessibles à un agent, reconstruire l'historique de ses trajectoires sur les dernières semaines et objectiver le coût réel par tâche : c'est le travail sur lequel un regard extérieur apporte le plus de valeur, parce que personne en interne n'a le temps ni le recul pour le faire pendant que l'incident tourne encore.
Un agent qui déraille n'est pas cassé. Il applique fidèlement une trajectoire que personne n'a bornée.
Questions fréquentes sur les agents IA qui déraillent en production
Votre agent IA dérape en production ?
Diagnostiquons la trajectoire, le coût et les permissions.
Articles recommandés
- Agents IA n8n en production, retour d'expérience : les patterns qui tiennent sur la durée, avant que le dérapage n'apparaisse.
- Baseline d'évaluation RAG : mesurer l'état de départ avant de corriger, pour savoir si un changement améliore ou dégrade.
- Agentic RAG : quand l'architecture de recherche documentaire d'un agent devient elle-même la cause d'une boucle.
- Agents IA vs chatbots pour PME : comprendre la différence entre répondre et agir, avant de cadrer les permissions.
- Prix de Hermes Agent : où part réellement l'argent sur un agent auto-hébergé, et pourquoi les tâches planifiées oubliées sont la première cause de dérive.
- Outils d'évaluation et d'observabilité des LLM : Ragas, LangSmith, Langfuse et les autres, pour instrumenter un agent avant qu'il ne dérape.
- Router SLM/LLM : architecture hybride et coûts : router chaque requête vers le bon modèle pour éviter le surdimensionnement.
Aller plus loin
Découvrez notre audit technique RAG et Agents IA pour objectiver les trajectoires, les coûts et les permissions d'un agent déjà déployé.
