La dérive des agents IA : pourquoi votre agent marche en démo et déraille en production
L'agent était parfait. En démo, il a lu le ticket, interrogé la base, rédigé la réponse, créé la tâche de suivi — sans une faute. Tout le monde a hoché la tête. Trois semaines plus tard, en production, le même agent invente des numéros de commande, oublie une consigne donnée dix messages plus tôt, et déclenche un remboursement qu'on ne lui avait jamais demandé.
Rien n'a changé dans le code. Ce qui a changé, c'est le réel.
Ce phénomène a un nom : la dérive. C'est le sujet le moins glamour et le plus décisif de l'IA agentique en 2026. Comprendre pourquoi un agent dévie — et comment l'en empêcher — c'est la différence entre un gadget de démo et un système sur lequel une entreprise peut s'appuyer.
Le fossé entre la démo et la production
Une démo, c'est un environnement maîtrisé. Quelques cas choisis, des données propres, un parcours balisé. L'agent brille parce qu'on lui a, sans le vouloir, retiré tout ce qui le ferait trébucher.
La production, c'est l'inverse. Des centaines de cas par jour, dont beaucoup que personne n'avait anticipés. Des données incomplètes, contradictoires, parfois hostiles. Et surtout : des tâches longues, où l'agent enchaîne dix, vingt, cinquante étapes avant de rendre un résultat. Or chaque étape est une occasion de se tromper un peu. Et ces « un peu » se composent.
Un agent fiable à 99 % sur une étape ne l'est plus qu'à 90 % sur dix étapes enchaînées, et tombe sous 60 % sur cinquante. La fiabilité ne s'additionne pas, elle se multiplie — vers le bas.
Qu'est-ce que la dérive d'un agent IA ?
Elle se décline en trois formes, qu'il faut savoir distinguer parce qu'elles n'ont ni les mêmes causes ni les mêmes remèdes.
La dérive d'objectif. L'agent perd de vue ce qu'on lui a demandé. Il part d'une tâche claire — « traiter cette demande de remboursement » — et finit par optimiser autre chose : satisfaire l'interlocuteur à tout prix, clôturer vite, éviter le conflit. Le but initial s'est dilué.
La dérive de contexte. L'agent s'appuie sur des informations devenues fausses ou périmées. Une consigne donnée en début de session est sortie de sa fenêtre de mémoire ; une donnée a changé entre-temps ; un document qu'il croit à jour ne l'est plus. Il agit correctement, mais sur la base d'une réalité qui n'existe plus.
La dérive comportementale. Le ton, le format, la rigueur de l'agent se dégradent. Il devient plus bavard, moins précis, contourne ses propres règles, ou produit des résultats corrects en moyenne mais imprévisibles au cas par cas. C'est la plus insidieuse : rien ne « casse » franchement, tout se délite lentement.
Anatomie d'une dérive en production
Pour rendre ça concret, voici le déroulé typique d'une session qui part bien et finit mal. Ce scénario n'a rien d'exceptionnel — c'est exactement ce qui se passe quand on laisse un agent travailler seul trop longtemps sans garde-fou.
Comment une session dérive
Tout va bien
L'agent reçoit une consigne claire et la première action est parfaite. C'est le moment de la démo.
Première micro-erreur
L'agent interprète mal une donnée ambiguë. Le résultat reste plausible, donc personne ne le corrige.
L'erreur se propage
Les étapes suivantes s'appuient sur la micro-erreur. L'agent raisonne juste, mais sur une base fausse.
La consigne sort de la mémoire
La fenêtre de contexte est saturée. La règle posée au départ a disparu. L'agent improvise.
Action irréversible
Convaincu de bien faire, l'agent déclenche une action réelle — un email envoyé, un paiement, une suppression — qui matérialise la dérive.
Le point crucial : à aucun moment l'agent ne « plante ». Chaque étape, prise isolément, semble raisonnable. La dérive est un phénomène cumulatif, pas un bug ponctuel. C'est pour ça qu'elle échappe aux tests classiques, qui vérifient une action à la fois.
Pourquoi ça arrive
Quatre mécanismes, qu'on retrouve dans presque tous les incidents.
L'accumulation d'erreurs sur les tâches longues. On l'a vu : la fiabilité se multiplie vers le bas. Plus l'horizon de la tâche est long, plus la probabilité qu'au moins une étape dérape devient quasi certaine.
La saturation de la fenêtre de contexte. Un modèle de langage n'a qu'une mémoire de travail limitée. Quand la conversation déborde, les premières instructions — souvent les plus importantes — sont les premières évincées. L'agent oublie littéralement ce qu'on lui avait dit de ne jamais faire.
Le prompt injection et les entrées hostiles. Dès qu'un agent lit du contenu externe — un email, une page web, un document client — ce contenu peut contenir des instructions cachées qui détournent son comportement. La frontière entre « données à traiter » et « ordres à exécuter » est floue pour un LLM.
Le changement d'environnement. Une API qui modifie son format, une base qui se restructure, un process métier qui évolue. L'agent a été calibré sur un monde qui n'existe plus tout à fait.
Les signaux qui doivent vous alerter
La dérive est silencieuse, mais pas invisible. Voici ce qu'on surveille en production :
- Des réponses incohérentes d'une session à l'autre pour une même demande.
- L'agent oublie des instructions données plus tôt dans la conversation.
- Des actions hors périmètre : il fait des choses qu'on ne lui a jamais demandées.
- Un taux d'erreur qui grimpe spécifiquement sur les tâches longues, alors que les courtes restent bonnes.
- Des résultats corrects en moyenne mais erratiques au cas par cas — la signature de la dérive comportementale.
Si vous ne mesurez aucun de ces signaux aujourd'hui, ce n'est pas que votre agent ne dérive pas. C'est que vous ne le voyez pas encore.
Détecter ou prévenir : deux philosophies
Face à la dérive, il existe deux écoles. Elles ne s'opposent pas — les meilleures architectures combinent les deux — mais elles n'ont ni le même coût ni le même moment d'intervention.
Aval vs Amont
| Détecter (aval) | Prévenir (amont) | |
|---|---|---|
| Moment | Après coup, en production | Avant, à la conception |
| Méthode | Monitoring, alertes, logs | Garde-fous, ontologies, contraintes |
| Ce qu'on attrape | La dérive une fois survenue | La dérive avant qu'elle survienne |
| Coût de correction | Élevé : il faut réparer le dégât | Faible : le dégât n'a pas lieu |
| Limite | Réactif : l'erreur a déjà eu lieu | Exige de structurer le problème en amont |
La détection est indispensable : on ne pilote pas ce qu'on ne mesure pas. Mais elle est réactive par nature — au moment où l'alerte tombe, l'action irréversible a souvent déjà eu lieu.
La prévention agit en amont. Plutôt que de surveiller un agent libre, on borne dès la conception le cadre dans lequel il opère : on définit explicitement ce qu'il a le droit de faire, on structure les concepts du domaine (les fameuses ontologies) pour qu'il ne puisse pas s'égarer, on rend certaines actions impossibles plutôt que simplement surveillées. C'est plus exigeant à mettre en place, mais c'est ce qui fait la différence entre un agent qu'on espère fiable et un agent qui ne peut pas déraper.
Fiabiliser un agent : le cycle en 4 étapes
La fiabilité n'est pas un réglage qu'on fait une fois. C'est une boucle.
- Évaluer. Construisez un jeu d'évaluations qui reflète vos vrais cas, y compris les cas tordus. Pas la démo idéale : les demandes ambiguës, contradictoires, hostiles. Si votre eval ne fait jamais échouer l'agent, elle ne sert à rien.
- Border. Posez des garde-fous explicites. Quelles actions sont autorisées ? Lesquelles exigent une validation humaine ? Lesquelles sont tout simplement interdites ? Une action irréversible ne devrait jamais être laissée à la seule décision de l'agent.
- Surveiller. Mettez en place un monitoring continu en production, avec des évaluations automatisées qui rejouent en continu les cas critiques et alertent au moindre écart.
- Boucler. Chaque dérive détectée nourrit l'eval de l'étape 1. Le système apprend de ses propres écarts. C'est ce qui transforme un agent statique en un système qui se fiabilise dans le temps.
Testez votre compréhension
Pourquoi un agent fiable à 99 % par étape devient-il risqué sur une tâche longue ?
📚Pour aller plus loin : l'eval comme contrat
Les équipes les plus avancées traitent leur jeu d'évaluations comme un contrat versionné. Chaque cas réel qui a fait dériver l'agent est figé en test de non-régression : il ne devra plus jamais échouer dans les versions futures. L'eval devient alors la mémoire institutionnelle des dérives passées.
Sur le volet sécurité, le prompt injection mérite un traitement à part. La parade structurelle consiste à séparer nettement les canaux : ce qui vient de l'utilisateur de confiance (les instructions) et ce qui vient du monde extérieur (les données à traiter, jamais à exécuter). Un agent qui traite tout contenu lu comme une donnée inerte — et jamais comme un ordre — ferme la porte à toute une classe d'attaques.
C'est précisément ce travail de structuration en amont — définir les ontologies du domaine, border les actions, séparer les canaux — qui distingue un agent robuste d'un agent qu'on croise les doigts pour qu'il tienne.
En résumé
La dérive n'est pas un défaut exotique : c'est la conséquence naturelle de l'autonomie. Plus on confie de tâches longues à un agent, plus on s'expose à ce qu'il s'éloigne, étape après étape, de ce qu'on attendait. La bonne nouvelle, c'est qu'elle se maîtrise — à condition de la prendre au sérieux dès la conception, et pas seulement de l'observer après l'incident.
Détecter, c'est nécessaire. Prévenir, c'est ce qui change tout.
Cet article fait partie du module Apprendre de nAIvigate. La dérive est l'envers d'un autre problème central des agents : leur mémoire. Pour comprendre comment un agent retient — ou oublie — ce qui compte, lisez Mémoire persistante : pourquoi votre assistant IA vous oublie. Et comme la fiabilité des agents est au cœur de la certification d'Anthropic, voyez aussi notre guide pour réussir la Claude Certified Architect (CCA-F).
Vous avez un agent en production que vous n'arrivez pas à fiabiliser ? C'est exactement ce que cadre Le Pilotage IA chez nAIvigate Studio : monitoring continu, garde-fous et boucle de fiabilisation, pris en charge mois après mois.