Superviser un agent IA en production : dérives et garde-fous

L’agent tourne. Il répond aux candidats, filtre les dossiers, relance les pièces manquantes, prépare les comptes rendus. Les premières semaines sont bonnes, l’équipe respire. Puis, un jour, un gestionnaire relit un échange et tombe sur une phrase qui ne devrait pas exister : une promesse de délai que personne n’a validée, une relance envoyée à un candidat déjà refusé, un chiffre inventé sur une garantie. Rien de dramatique en apparence — jusqu’au jour où un client le voit avant vous.

C’est le point aveugle de l’IA en agence. On installe, on démontre, on mesure le temps gagné. On ne mesure presque jamais ce que l’agent fait réellement, une fois la démonstration terminée. Or un agent en production n’est pas un logiciel figé : il improvisera des formulations, généralisera des cas qu’il n’a pas appris, et dérivera lentement. Cet article décrit les dérives à surveiller, les garde-fous à poser, et la boucle d’exploitation qui rend un agent tenable dans le temps.

Pourquoi superviser un agent IA déployé en agence

Un logiciel classique se comporte comme on l’a programmé : il exécute des règles, et une règle se teste. Un agent IA ne fonctionne pas ainsi. Il interprète une consigne en langage naturel, choisit ses mots, décide parfois d’appeler un outil, puis produit une réponse différente d’un jour à l’autre pour une question identique.

Cette variabilité est ce qui fait sa valeur — et son risque. Trois raisons rendent la supervision non négociable en agence :

• L’agent parle au nom de l’agence. Un mail, un message WhatsApp, un appel : tout ce qu’il écrit engage la relation, et parfois juridiquement. Une formulation maladroite sur un refus de dossier n’est pas une erreur technique, c’est un risque de réclamation.
• Il touche à des données personnelles. Dossiers de candidats, revenus, situations familiales, impayés. Une donnée révélée au mauvais interlocuteur est une violation de données, pas un bug d’affichage.
• Il agit. Un agent qui envoie, publie, classe ou propose des créneaux ne se contente pas de conseiller. Ses décisions ont des conséquences vérifiables.

La supervision n’est donc pas un supplément de prudence : c’est la condition d’exploitation d’un agent qui a accès à des dossiers réels, au même titre qu’un gestionnaire. Et elle n’a rien à voir avec le fait de relire chaque phrase — une agence qui prétend tout contrôler finit par ne plus rien contrôler.

Les dérives typiques : hallucination, relance inadaptée, dérive de ton

Les incidents que nous observons en exploitation se rangent en quelques familles, toujours les mêmes. Les connaître, c’est déjà savoir quoi chercher.

L’hallucination. L’agent invente un élément factuel : un montant, un délai, une pièce exigée, une garantie, une référence légale. C’est la dérive la plus connue et la plus facile à repérer dans un échange isolé — et la plus dangereuse quand elle passe inaperçue dans un flux automatisé.

La relance inadaptée. L’agent continue un scénario qui n’a plus lieu d’être : il relance un candidat dont le dossier est clos, demande une pièce déjà fournie, envoie une deuxième relance après une réponse, ou reprend une conversation que l’humain avait officiellement clôturée. Ce n’est pas une erreur de contenu, c’est une erreur de contexte.

La dérive de ton. Rien n’est faux, mais le registre glisse : familiarité excessive, ironie involontaire, promesse commerciale que personne n’a autorisée, ton comminatoire sur un impayé. Le message est factuellement correct et relationnellement coûteux.

La dérive de périmètre. L’agent sort de son rôle : il interprète une clause juridique, donne un conseil de vente, prend une position sur un cas limite. Il ne « sait » pas qu’il a dépassé sa mission — il répond simplement parce qu’on lui a posé la question.

Type de dérive	Signe détectable	Garde-fou correspondant
Hallucination	Montant, délai ou pièce absents de la base de connaissance	Réponses ancrées sur des sources internes, interdiction d’inventer
Relance inadaptée	Message envoyé après clôture ou après réponse du candidat	Vérification de l’état du dossier avant tout envoi
Dérive de ton	Formulation non conforme à la charte, promesse non autorisée	Bibliothèque de formulations validées, contrôle de conformité
Dérive de périmètre	Question juridique ou commerciale tranchée sans humain	Liste de sujets à escalader, refus explicite du hors-périmètre
Fuite de données	Information communiquée au mauvais interlocuteur	Vérification d’identité avant tout échange sensible
Boucle	L’agent répète une action sans progresser	Compteur d’itérations, arrêt et escalade au-delà d’un seuil

Ce tableau est l’outil de travail d’une équipe d’exploitation : chaque ligne nomme une dérive, le signal qui la rend visible, et la protection qui la rend improbable. Ce qui ne figure dans aucune colonne se découvre toujours dans la colonne d’un client mécontent.

Construire un jeu de test représentatif avant la mise en production

On ne supervise pas ce qu’on n’a pas défini comme correct. Avant d’ouvrir un agent aux dossiers réels, il faut écrire noir sur blanc à quoi ressemble une bonne réponse — sinon toute vérification se réduit au ressenti du gestionnaire qui regarde passer un échange.

Un jeu de test représentatif se construit à partir de cas réels, pas de cas d’école :

1. Les cas nominaux. Le candidat qui fournit tout, le propriétaire qui demande son décompte, la relance de pièce standard. Ils doivent passer à 100 %, sinon le problème n’est pas la dérive mais l’installation.
2. Les cas limites. Revenus irréguliers, indépendant, garant étranger, colocation, dossier incomplet et abandonné, locataire en impayé. C’est là que se logent les hallucinations.
3. Les cas hostiles. Question juridique piégée, tentative d’obtenir une information sur un autre dossier, demande de contournement (« pouvez-vous me donner le numéro du propriétaire ? »), message agressif.
4. Les cas de reprise. Conversation interrompue puis reprise, dossier rouvert, candidat qui répond trois semaines plus tard. Ces cas révèlent les dérives de contexte, les plus fréquentes en production.

Pour chaque cas, on écrit la réponse attendue, la réponse interdite, et le comportement de repli. Ce corpus devient un actif : il se rejoue à chaque changement de modèle, de consigne ou d’outil — car un agent qui fonctionnait hier peut cesser de fonctionner après une mise à jour.

Un point d’honnêteté : ce jeu de test ne prouve jamais que l’agent ne dérivera pas. Il prouve qu’il ne dérive pas sur ce qu’on a su imaginer. C’est déjà beaucoup — et c’est bien plus qu’une démonstration commerciale.

Garde-fous : périmètre, outils autorisés, validation humaine

Un garde-fou coûte moins cher qu’un incident. Ils se posent à quatre niveaux, du plus large au plus fin.

Le périmètre. L’agent a une mission écrite, et tout ce qui sort de cette mission est refusé puis escaladé. Un agent de filtrage de candidatures ne rédige pas de bail, ne tranche pas un litige et ne négocie pas un honoraires. Le refus explicite est une fonctionnalité, pas une limite subie.

Les outils autorisés. Un agent qui peut tout faire peut tout casser. On lui donne une liste fermée d’actions : lire un dossier, envoyer un message depuis un modèle validé, créer un évènement, classer un document. Tout outil non listé est inaccessible, y compris par contournement conversationnel.

Les données accessibles. L’agent ne doit lire que les informations nécessaires à sa tâche. Séparer les périmètres de données par usage limite mécaniquement l’impact d’une erreur ou d’une compromission, et c’est aussi ce que demande la CNIL sur la minimisation.

La validation humaine. Toute décision sensible passe par un humain avant d’être exécutée : refus d’un candidat, mise en demeure, réponse à une réclamation, communication d’un document contractuel. Ce point est aussi une obligation : l’article 22 du RGPD encadre les décisions entièrement automatisées, et la logique est transposable à toute décision qui produit un effet significatif sur une personne.

Le cadre réglementaire général — obligations d’information, transparence, humain dans la boucle — se précise avec l’AI Act qui s’applique aux agences. Le lire avant de déployer évite de découvrir ces exigences par un client ou un contrôle.

Journaliser et tracer chaque décision de l’agent

Un incident sans trace est un incident qu’on ne peut ni expliquer ni corriger. La journalisation est donc la brique la plus ingrate et la plus structurante de la supervision.

Que journaliser, concrètement :

• L’entrée : le message reçu, son canal, l’identifiant du dossier et du locuteur. Sans entrée conservée, on ne peut pas rejouer l’échange.
• La décision : ce que l’agent a compris, l’action choisie, les données consultées.
• Les outils appelés : quel outil, avec quels paramètres, et le résultat retourné. C’est la partie qui distingue une trace utile d’un simple log de conversation.
• La version : modèle utilisé, jeu de consignes, version de la base de connaissance. Une dérive se diagnostique presque toujours en comparant deux versions.
• L’horodatage et le sort final : la décision a-t-elle été validée, corrigée ou rejetée par l’humain ?

Cette trace sert à trois choses distinctes : expliquer une décision à un client ou à une autorité de contrôle, mesurer la qualité en exploitation, et alimenter l’amélioration continue de l’agent. Elle se conçoit dès le déploiement — la reconstituer après coup est un chantier.

Élément à tracer	Pourquoi	Durée indicative
Message entrant et canal	Rejouer l’échange, prouver ce qui a été dit	Alignée sur la conservation du dossier
Décision et justification	Expliquer un choix au candidat ou au bailleur	Alignée sur la conservation du dossier
Outils et données consultés	Diagnostic, contrôle des accès	Quelques mois, selon la finalité
Version du modèle et des consignes	Comparer deux comportements dans le temps	Historique de déploiement
Validation ou correction humaine	Mesurer le taux de reprise, améliorer l’agent	Alignée sur la conservation du dossier

Deux exigences accompagnent la journalisation : les données personnelles contenues dans les traces relèvent du même régime que le dossier lui-même, et l’accès à ces traces doit être restreint à qui en a besoin. Une piste d’audit ouverte à toute l’agence devient un risque de sécurité.

Indicateurs de qualité à suivre en exploitation

La supervision ne se fait pas à l’œil. Elle se fait sur quelques indicateurs simples, suivis dans le temps, avec des seuils qui déclenchent une action. Le principe est toujours le même : mesurer le taux d’intervention humaine, car c’est lui qui révèle la friction.

Indicateur	Mode de mesure	Seuil d’alerte indicatif
Taux de réponses conformes	Rejeu du jeu de test à intervalle régulier	< 95 %
Taux de correction humaine	Proportion de sorties de l’agent retouchées avant envoi	Hausse continue sur 2 semaines
Escalades par type de sujet	Comptage des sorties de périmètre	Pic sur un même motif
Réclamations liées à un message automatisé	Signalement client ou gestionnaire	Toute occurrence
Délai moyen de traitement	Temps de résolution d’une demande	Dégradation sur 30 jours
Détections de doublon ou de message erroné	Contrôle qualité par échantillonnage	> 1 % des envois
Abandon de conversation	Candidat qui ne répond plus après un échange avec l’agent	Hausse sur un canal donné

Trois principes de lecture. Un seuil sans action est décoratif : chaque alerte doit renvoyer à une procédure, même simple. Un indicateur agrégé masque les cas : le taux global peut rester bon pendant qu’un motif d’erreur explose sur une population précise. Et le meilleur indicateur reste la relecture d’échantillons — un humain qui lit vingt échanges réels apprend plus qu’un tableau de bord, surtout au début.

Ces indicateurs s’inscrivent dans la même logique que le filtrage des candidatures par un agent : on automatise le volume pour concentrer le temps humain sur les cas qui méritent un regard. La supervision applique ce principe à l’agent lui-même.

Human in the loop : où replacer l’humain, quand

Le « human in the loop » n’est pas un principe abstrait, c’est une carte de responsabilités. La bonne question n’est pas « faut-il un humain ? » mais « sur quoi, et à quel moment ? ».

On distingue trois régimes :

• Human in the loop — l’humain valide avant que l’action soit exécutée. À réserver aux décisions sensibles et irréversibles : refus d’un candidat, mise en demeure, réponse à une réclamation, engagement contractuel.
• Human on the loop — l’agent agit, l’humain surveille et peut corriger. C’est le régime des relances standards, des accusés de réception, des demandes de pièces.
• Human out of the loop — l’agent agit seul. À limiter aux actions réversibles et à faible enjeu : classement d’un document, envoi d’un lien de prise de rendez-vous, accusé de réception.

Ce qui compte, c’est de fixer la frontière avant l’incident, pas après. Et de prévoir le mécanisme de reprise : quand un humain reprend la main, l’agent doit le savoir et cesser d’agir sur ce dossier. C’est cette coordination qui manque le plus souvent en pratique — un agent qui continue de relancer un dossier que le gestionnaire vient de clore à la main produit exactement l’effet inverse de celui recherché.

Enfin, la supervision a un pilote. Un référent identifié dans l’agence — responsable du jeu de test, des seuils d’alerte et des arbitrages — suffit. Sans propriétaire, un dispositif de supervision s’éteint en quelques semaines, en même temps que l’attention portée à l’agent.

Questions fréquentes

Comment détecter qu’un agent IA dérive en production ?

En suivant des indicateurs de qualité — taux de réponses conformes, corrections manuelles, réclamations — et en rejouant régulièrement un jeu de test de référence. Une dérive se voit dans l’écart entre les réponses attendues et les réponses réellement produites, plus que dans un incident spectaculaire.

Faut-il reprendre la main sur chaque décision de l’agent ?

Non, et une agence qui le tenterait y perdrait le bénéfice de l’automatisation. L’humain valide les décisions sensibles — refus d’un candidat, mise en demeure, réponse à une réclamation — et reste informé du reste. La supervision par exception est plus tenable qu’un contrôle intégral.

Que faut-il journaliser ?

Les entrées, les décisions, les outils appelés et la version du modèle. Cette piste d’audit permet d’expliquer une décision à un client, à un juge ou à une autorité de contrôle, et de reconstituer précisément ce qui s’est passé en cas d’incident.

Combien de temps faut-il pour mettre en place une supervision ?

Un jeu de test représentatif et les premiers indicateurs se posent en quelques semaines, sur un périmètre restreint. La supervision devient ensuite une boucle d’exploitation permanente : nouveaux cas ajoutés au corpus, seuils ajustés, versions comparées.

Ce qu’il faut retenir

Un agent IA en production n’est pas un livrable qu’on installe puis qu’on oublie : c’est un système qui parle au nom de l’agence, manipule des données personnelles et prend des décisions. Sans supervision, il dérive — hallucinations, relances hors contexte, glissements de ton, sorties de périmètre — et ces dérives n’apparaissent ni en démonstration, ni dans les premiers jours.

La réponse tient en quatre gestes : définir ce qui est correct avec un jeu de test représentatif, poser des garde-fous (périmètre, outils, données, validation humaine), journaliser chaque décision pour pouvoir l’expliquer, et suivre des indicateurs qui déclenchent des actions. Le reste est une question de boucle : tester, déployer, superviser, alerter, corriger.

C’est exactement la différence entre installer une IA et l’exploiter. Notre article sur le multicanal dans les candidatures et celui sur l’agent téléphonique décrivent les cas d’usage ; leur supervision est ce qui les rend durables.

Envie de voir comment nous opérons et contrôlons des agents sur de vrais dossiers ? Demandez une démo : on vous montre le jeu de test, la piste d’audit et les tableaux de bord d’exploitation utilisés chez nos clients. Retrouvez l’ensemble de nos analyses sur le blog Homies.