La dérive silencieuse des agents en production : détecter qu'un agent change de comportement avant qu'il ne cause un incident

L'agent fonctionne. Jusqu'au jour où il ne fonctionne plus vraiment.

Votre agent de traitement des commandes tourne depuis six mois. Aucune alerte, aucun ticket. Les logs sont verts. Et pourtant, le taux de réclamations clients a doublé sur le dernier trimestre. Les commerciaux signalent des délais de confirmation "bizarres". Le service comptable retrouve des écarts inexpliqués.

L'agent n'est pas en panne. Il a dérivé.

C'est le scénario le plus fréquent — et le plus coûteux — dans une infrastructure agentique en production. Pas l'effondrement brutal, détectable en quelques minutes. Mais l'érosion progressive de la qualité de décision, invisible aux tableaux de bord classiques, qui s'accumule jusqu'à l'incident métier.

Pourquoi un agent dérive sans qu'on le remarque

Un agent autonome prend des décisions à partir de trois éléments : ses instructions initiales, les données qu'il reçoit, et les services qu'il interroge. Les trois peuvent changer indépendamment de lui.

• Les données évoluent. Un fournisseur modifie son format de catalogue. Les codes produits changent de structure. Une nouvelle catégorie apparaît sans métadonnées associées.
• Les processus métier bougent. Le workflow de validation passe de deux à trois étapes. Un nouveau champ devient obligatoire dans l'ERP. Les règles de marge évoluent.
• Les APIs en amont se mettent à jour. Le service de tarification renvoie un format légèrement différent. Un endpoint déprécié continue de répondre mais avec des données partielles.

L'agent continue d'exécuter ses instructions. Il ne plante pas — il fait ce qu'il sait faire avec ce qu'il reçoit. Sauf que "ce qu'il reçoit" ne correspond plus à "ce pourquoi il a été conçu".

La supervision classique ne voit pas la dérive

Les outils de monitoring traditionnels surveillent trois choses : la disponibilité, le temps de réponse, et les erreurs explicites. Un agent qui dérive ne déclenche aucune de ces alertes.

Il reste disponible. Il répond dans les temps. Il ne renvoie pas d'erreur — il renvoie un résultat. Simplement, ce résultat est progressivement moins pertinent, moins fiable, moins aligné avec l'intention métier initiale.

Exemple concret : un agent de qualification de leads reçoit depuis deux mois des formulaires avec un nouveau champ "taille d'entreprise". Ce champ n'existait pas à son déploiement. L'agent l'ignore — il ne sait pas quoi en faire. Résultat : tous les leads enterprise sont scorés comme des PME. Le commercial découvre le problème quand il appelle un prospect du CAC40 avec un pitch TPE.

Le système n'a jamais alerté. Parce qu'il n'y avait pas d'erreur au sens technique.

Ce que nous surveillons : les signaux faibles de dérive

Chez Lynakor, nous avons structuré une supervision orientée détection de dérive, pas seulement de panne. L'objectif n'est pas de savoir si l'agent répond, mais de savoir s'il répond comme prévu.

Nous instrumentons quatre familles de signaux :

• Distribution des décisions. Si un agent de routage envoyait 60% des demandes vers le canal A et qu'il passe à 85% sans changement de politique, c'est un signal. Pas une erreur, un écart à investiguer.
• Temps de traitement par type de cas. Une augmentation progressive du temps moyen sur certaines catégories peut indiquer que l'agent "hésite" — il reçoit des données qu'il ne reconnaît plus bien.
• Taux d'utilisation des fallbacks. Un agent bien calibré utilise peu ses chemins de secours. Si le taux de fallback augmente, c'est que les chemins nominaux ne matchent plus les cas réels.
• Cohérence entrée/sortie. On compare statistiquement les caractéristiques des entrées avec les décisions produites. Une déconnexion progressive entre les deux est un marqueur de dérive.

L'alerte n'est pas "erreur" mais "écart significatif"

Cette approche change la nature même des alertes. On ne reçoit pas "Agent en erreur — code 500". On reçoit "Agent de facturation : distribution des montants facturés hors intervalle de confiance depuis 72h".

C'est plus subtil à interpréter. Ça demande un contexte métier. Mais c'est précisément ce qui permet d'intervenir avant l'incident, pas après.

Dans notre expérience, une dérive détectée à J+3 se corrige en quelques heures. La même dérive découverte à J+60 génère des semaines de nettoyage de données et de réconciliation manuelle.

L'exemple du distributeur industriel

Un de nos clients — distribution B2B, 200 M€ de CA — avait déployé un agent de gestion des réapprovisionnements. L'agent tournait depuis quatre mois sans incident remonté.

Notre supervision a détecté un glissement : le ratio commandes automatiques / commandes manuelles dérivait de 75/25 vers 55/45. Pas d'erreur, pas de blocage. Juste de plus en plus de cas où l'agent passait la main à un humain.

Investigation : un fournisseur majeur avait changé ses codes articles trois mois plus tôt. L'agent ne retrouvait plus les correspondances et, par prudence, renvoyait vers le processus manuel. Personne ne s'en plaignait — les équipes traitaient les cas sans réaliser que c'était anormal.

Correction : deux heures de mise à jour du référentiel. Sans détection, la dérive aurait continué jusqu'à saturation du service achats.

Intégrer la détection de dérive dans la gouvernance

La détection de dérive n'est pas qu'un sujet technique. C'est un sujet de gouvernance. Elle pose la question : qui est responsable de la qualité de décision d'un agent dans la durée ?

Nous recommandons trois pratiques :

• Un propriétaire métier par agent. Quelqu'un qui comprend ce que l'agent est censé faire et peut interpréter un écart de comportement.
• Une revue périodique des métriques de distribution. Pas tous les jours, mais une fois par mois : est-ce que l'agent décide toujours de la même façon pour des cas similaires ?
• Un processus de recalibration documenté. Quand une dérive est confirmée, comment met-on à jour les instructions, les référentiels, les seuils ?

Un agent en production n'est pas un logiciel qu'on installe et qu'on oublie. C'est un collaborateur digital qui a besoin d'un minimum de supervision métier.

La fiabilité se construit dans la durée

Déployer un agent qui fonctionne le jour J, n'importe quel intégrateur peut le faire. Maintenir un agent fiable à M+12, M+24, dans un environnement métier qui évolue — c'est une autre affaire.

La dérive est inévitable. La question n'est pas de l'empêcher, mais de la détecter assez tôt pour qu'elle reste un ajustement, pas une crise.