Un pilote qui classe les demandes clients est validé en janvier. Il fonctionne : cas réels, relecture humaine, feu vert du comité, mise en production. En juin, les plaintes arrivent : demandes envoyées au mauvais service, réponses à côté de la plaque. L’équipe fait ce qu’il faut et vérifie le prompt, le modèle, la configuration. Tout est exactement comme en janvier. « Personne n’a rien changé », conclut-on, et la discussion glisse vers « l’IA n’est pas fiable ».
La thèse en une ligne : quand un agent se dégrade sans que personne touche au code, ce sont ses entrées qui ont changé, et le test de janvier a seulement prouvé qu’il fonctionnait pour les gens, les formulaires et le calendrier de janvier. « Personne n’a rien changé » n’est pas la défense du système ; c’est le diagnostic.
Pourquoi un agent IA se dégrade avec le temps alors que le code est le même
Parce qu’un agent n’est pas un programme qui fait toujours la même chose : c’est une fonction de ce qu’il reçoit, et ce qu’il reçoit change. Une validation mesure le comportement sur un échantillon précis d’entrées. Si la réalité s’éloigne de cet échantillon, le chiffre du test ne la suit pas. C’est la raison pour laquelle un taux de réussite ne suffit pas en production : la précision n’est pas une propriété du modèle, c’est une propriété du système et de ses données, et les données bougent.
Quatre façons dont les entrées changent sans prévenir
- Le calendrier. Campagnes, clôtures de trimestre, haute saison, mois de congés. L’agent validé sur le trafic d’un mois calme rencontre, un autre mois, un autre type de demande : plus urgente, plus ambiguë.
- De nouvelles personnes qui écrivent autrement. Un nouveau canal, un client d’un autre pays, un segment qui n’arrivait pas avant. Messages plus longs, une autre langue mêlée, d’autres abréviations. L’échantillon du test ne les contenait pas.
- Un système en amont qui change. Un formulaire qui ajoute un champ facultatif, un CRM qui modifie le format d’une date, un fournisseur qui renomme une colonne. Personne ne prévient l’agent, car personne ne sait que cette dépendance existe.
- L’entreprise change, pas le prompt. Nouveau produit, nouveaux tarifs, une autre politique de retours. Les instructions décrivent toujours l’entreprise de janvier.
Dérive des entrées et dérive du modèle ne se corrigent pas pareil
Mieux vaut ne pas les confondre, car la première question d’un diagnostic est de savoir laquelle des deux on a. La dérive du modèle vient du fournisseur : il met à jour ou retire une version et le même prompt se comporte autrement. On la contient avec une version figée et une batterie de cas rejouée à chaque changement, ce que détaille notre guide pour changer de modèle sans casser tes automatisations.
La dérive des entrées se produit même si on fige tout. On peut geler le modèle, le prompt et l’infrastructure pendant un an : si le monde qui l’alimente change, l’agent se dégrade quand même. C’est pourquoi la réaction habituelle, essayer un autre modèle, est souvent une erreur, comme on l’explique dans changer de modèle ne répare pas ton processus : on déplace le problème et on paie une migration en plus.
Une question d’une minute départage les deux cas : est-ce le système qui a changé, ou ce qui y entre ? Si le modèle, le prompt et les intégrations sont inchangés et que la performance baisse, commence par les entrées.
Comment repérer la dérive des entrées avant le client
Un signal qui arrive par les plaintes arrive tard : à ce moment-là, on cumule des semaines d’erreurs. Les quatre contrôles qui prennent les devants coûtent peu, mais doivent exister avant d’en avoir besoin :
- Garde l’instantané de la validation. L’échantillon d’entrées sur lequel l’agent a été approuvé est ta référence. Si tu ne l’as pas conservé, il n’y a rien à comparer.
- Compare chaque semaine ce qui arrive à cet instantané. Pas besoin de statistiques sophistiquées : longueur des messages, langue, répartition par catégorie, champs vides, part de cas que l’agent n’a jamais vus. Un changement brusque sur l’un d’eux est l’alarme.
- Surveille les exceptions par type d’entrée. Le taux de cas que l’agent passe à une personne, ou qu’une personne corrige, monte avant les plaintes, et ventilé par type il t’indique où la réalité bouge.
- Relance les évaluations avec des cas récents. Une batterie figée de janvier ne t’apprend que ce que tu savais déjà. Ajoute chaque mois de nouveaux cas réels, étiquetés par une personne, comme décrit dans les évaluations pour savoir si ton IA fonctionne vraiment.
Cette première étape n’existe d’ailleurs que si tu as pris une base de référence. C’est le même principe que mesurer la performance de tes automatisations : le chiffre qu’on n’a pas pris avant ne se prend pas après.
Que faire quand l’entrée a déjà bougé
Il y a trois réponses, et le choix dépend de l’ampleur du déplacement et du coût d’une erreur :
- Mettre la référence à jour. Intégrer les nouveaux cas à la validation et réajuster instructions et exemples. C’est la bonne réponse quand le changement est stable et que l’agent peut apprendre à le couvrir.
- Élargir le périmètre avec un parcours dédié. Si un type d’entrée nouveau et distinct est apparu (autre langue, autre canal), traite-le comme un nouveau cas avec sa propre validation, pas comme une variante de l’ancien.
- Réduire l’autonomie en attendant. Ce que l’agent ne reconnaît plus part vers une personne, et l’agent passe de décider à proposer. C’est le mécanisme des niveaux d’autonomie d’un agent : descendre d’un cran est réversible ; l’éteindre ne l’est pas toujours.
Rien de tout cela ne marche sans responsable. Personne en particulier ne repère la dérive des entrées, parce que ce n’est le travail de personne en particulier : ni de celui qui a construit l’agent, déjà sur un autre projet, ni de ceux qui l’utilisent. Il faut une personne nommée, une cadence (hebdomadaire, pour commencer) et l’autorité de modifier l’agent quand les données l’exigent. Le reste du plan est dans le guide sur la maintenance des automatisations IA. Et si tu préfères ne ni le monter ni le tenir toi-même, c’est ce qu’on fait quand on surveille l’IA en production : instrumenter les entrées, les exceptions et les cas de référence, et agir quand ils bougent.
Comment savoir si ça t’arrive en ce moment
- Personne ne peut te montrer l’échantillon d’entrées sur lequel l’agent a été approuvé.
- La dernière fois qu’on a ajouté de nouveaux cas à la validation, c’était avant le lancement.
- Les exceptions se comptent au total, pas par type d’entrée.
- Si tu demandes qui surveille tout ça, la réponse est « l’équipe », pas une personne.
Si deux affirmations sur quatre sont vraies, ton agent a sans doute déjà bougé et il te manque seulement l’instrument pour le voir.
La phrase à retenir : un agent ne se dégrade pas parce qu’il vieillit, il se dégrade parce que le monde continue de changer et que personne n’a revérifié qu’ils parlaient encore la même langue.