Supervision des agents IA : journalisation, alertes et retour arrière en exploitation

Le lundi matin, une cliente demande pourquoi elle a reçu vendredi soir une confirmation de rendez-vous pour un jour qu’elle n’avait jamais souhaité. La collaboratrice du bureau ouvre la boîte et trouve le message, envoyé par l’agent. Ce qu’il a lu, ce qu’il en a conclu et quels outils il a utilisés pour cela, elle ne peut pas le voir. Il n’y a que le résultat.

Ce scénario est inventé, le schéma ne l’est pas. Dès qu’un agent ne se contente plus de produire des textes mais crée des rendez-vous, affecte des tickets ou écrit des données dans des systèmes, la question passe de « La réponse est-elle bonne ? » à « Qu’a-t-il réellement fait ? ». Un chatbot qui se trompe produit une information erronée. Un agent qui se trompe laisse des traces dans vos systèmes.

L’exploitation signifie donc plus que la mise à disposition. Qui déploie un agent assume une tâche connue avec les nouveaux collaborateurs : on regarde de près au début, on se fait expliquer les décisions et on ne cède la responsabilité que peu à peu. La différence est qu’un agent ne peut fournir cette explication que si elle a été enregistrée au préalable. Demander après coup n’est pas possible.

Dans les petites entreprises, cela pèse plus lourd que dans les grands groupes. Il n’y a pas de service dédié pour enquêter sur les incidents, et la personne qui a configuré l’agent est souvent la même que celle qui mène en plus les affaires courantes. Quand quelque chose tourne mal, la qualité de l’enregistrement décide si l’éclaircissement prend une heure ou une demi-journée, et si la cliente reçoit une réponse concrète ou une excuse.

Un logiciel classique se remarque quand il plante. Les agents se remarquent rarement ainsi. Ils continuent de tourner, livrent des résultats d’apparence plausible et se trompent pourtant. Cela rend la surveillance plus exigeante, car le simple signal « ça tourne » ou « ça ne tourne pas » ne dit rien de la qualité.

Parmi les types d’erreurs les plus fréquents figure la boucle. L’agent appelle sans cesse le même outil parce que la réponse ne correspond pas au schéma attendu, et consomme du temps de calcul et du budget sans avancer. Un deuxième cas est le mauvais appel d’outil : le bon outil avec de mauvais paramètres ou le mauvais outil pour la tâche. Un troisième est celui des dépassements de délai, où une interface ne répond pas et où l’agent abandonne ou poursuit avec des informations incomplètes.

Le cas le plus sournois est l’interface modifiée. Un système connecté change des noms de champs, des formats ou des codes de réponse, et l’agent interprète les nouvelles données selon l’ancien schéma. Il « fonctionne » toujours, mais de travers. Ici, une alerte sur les plantages n’aide pas, seule la comparaison entre comportement attendu et comportement réel le fait.

S’y ajoutent des erreurs qui résident dans la consigne elle-même. Une formulation qui était sans ambiguïté lors des tests est lue autrement avec une entrée inhabituelle. De telles erreurs ne se rattrapent pas par la seule technique. Elles exigent une personne qui examine régulièrement de vrais dossiers et les compare à l’intention de la consigne.

Journaliser ne signifie pas tout stocker. Un enregistrement complet de chaque appel au modèle génère de grandes quantités de données que personne ne lit et contient souvent des informations personnelles que vous ne voulez pas conserver plus longtemps que nécessaire. La question est de savoir quelles données sont nécessaires pour expliquer un dossier par la suite.

Un enregistrement par étape comportant quatre éléments suffit généralement : qu’est-ce qui est arrivé, qu’en a décidé l’agent, quelle action a-t-il déclenchée et sur quelle source la décision s’appuie-t-elle ? Complété par un identifiant de dossier, un horodatage, la version de la consigne utilisée et le résultat de l’appel d’outil, chaque dossier peut être reconstitué.

L’identifiant est plus important qu’il n’y paraît d’abord. Un dossier se compose de nombreuses étapes réparties sur plusieurs systèmes. Ce n’est que si la même clé apparaît dans la boîte de réception, le journal de l’agent et le système cible que l’on peut remonter un incident de la plainte de la cliente jusqu’à l’étape déclenchante. Sans elle, cela reste un travail de détective.

Une limite en fait partie : le journal est une documentation d’exploitation, pas une archive permanente. Définissez combien de temps il est conservé, qui peut le consulter et quels champs sont masqués. Pour les données à caractère personnel s’applique le principe de minimisation des données ; vous devriez clarifier la mise en œuvre concrète avec votre déléguée à la protection des données. Ce texte n’est pas un conseil juridique.

Un test pratique de la qualité de la trace : demandez à quelqu’un qui n’a pas configuré l’agent d’expliquer un dossier quelconque à partir du journal. Si cela réussit sans question au développeur, la trace est exploitable. S’il doit deviner ou chercher dans trois systèmes, un champ manque ou l’identifiant n’est pas transmis. Ce test coûte un quart d’heure et révèle des lacunes avant qu’un vrai incident ne le fasse.

La solution évidente serait un tableau de bord avec des indicateurs : nombre de dossiers, durée moyenne, taux d’erreur. C’est utile et insuffisant, car il ne montre le comportement de l’agent qu’en moyenne. Une seule confirmation de rendez-vous erronée disparaît dans une statistique, mais reste un incident pour la cliente concernée.

Une deuxième option consiste à tout laisser au fournisseur du modèle ou de la plateforme et à utiliser ses analyses intégrées. Cela économise de l’effort, mais lie la traçabilité à une interface tierce. Si vous changez de fournisseur ou combinez deux outils, la trace se rompt. Nous tiendrions donc les journaux dans un format simple et à vous, dans votre environnement, et utiliserions les valeurs de la plateforme en complément.

Une troisième possibilité est le contrôle purement manuel : quelqu’un lit régulièrement des dossiers. C’est indispensable, mais pas viable seul, car cela ne passe pas à l’échelle et ne trouve les erreurs qu’une fois qu’elles sont survenues. C’est pourquoi nous combinons trois niveaux qui se complètent : des alertes automatiques pour les violations claires des règles, des indicateurs continus pour les tendances et des contrôles par sondage par des personnes pour ce qu’aucun jeu de règles ne détecte.

Cette combinaison est un compromis. Plus d’alertes signifient plus de dérangements et, à terme, de l’accoutumance ; plus de contrôles par sondage mobilisent du temps. Le niveau du seuil dépend de ce que coûte une erreur. Un agent qui trie des notes internes peut être surveillé plus légèrement qu’un agent qui écrit à des clients ou prépare des offres.

Une alerte n'est utile que si quelqu'un sait quoi faire ensuite. C'est pourquoi nous associons chaque alerte à une courte consigne d'action : qui est informé, que vérifie-t-on, l'agent peut-il continuer ou est-il mis en pause ? D'après notre expérience, les alertes sans étape suivante définie finissent dans une boîte de réception et sont ignorées.

Dans le suivi des coûts, le montant total compte moins que l'écart par rapport au comportement habituel. Un agent qui a soudain besoin de bien plus d'appels au modèle par dossier a généralement un problème de boucles, de contexte trop long ou de nouvelles tentatives défectueuses. Un plafond strict par dossier et une limite quotidienne contiennent les dégâts avant qu'un humain puisse intervenir. Lorsque la limite est atteinte, le dossier devrait être transmis à une personne, et non écarté silencieusement.

Les revues par échantillonnage comblent la lacune que les alertes ne voient pas. Nous commencerions avec un rythme fixe, par exemple un petit nombre de dossiers tirés au hasard chaque semaine, complétés par tous ceux pour lesquels l'agent était incertain ou les a transmis à un humain. Le relecteur voit l'entrée, la trace et le résultat côte à côte et les évalue selon une grille courte : correct, acceptable, faux.

De cette grille naît un savoir. Si les jugements « acceptable » s'accumulent sur un type de demande précis, la consigne y est trop ouverte. Si les jugements « faux » s'accumulent après une certaine date, il vaut la peine d'examiner une modification de l'interface ou de la consigne. La revue est donc à la fois un contrôle qualité et un système d'alerte précoce.

L'effort reste raisonnable si la trace est bien lisible. Un relecteur n'a besoin que de quelques minutes par dossier, à condition de ne pas devoir d'abord rassembler des données issues de trois systèmes. C'est une raison de plus pour investir dans la structure du journal avant la mise en production du premier agent.

La consigne qui indique à un agent comment agir est le levier le plus efficace et, en même temps, la source d'erreurs la plus fréquente. Une phrase modifiée peut changer le comportement dans des cas auxquels personne n'a pensé lors de la modification. Pourtant, les consignes sont souvent éditées dans un champ de texte, sans historique ni validation.

Nous les traitons donc comme du code. Chaque modification reçoit un numéro de version, une brève justification et un responsable. Le journal indique avec quelle version une étape a été produite. En cas d'incident, on peut ainsi établir s'il est survenu avant ou après une modification et quels dossiers ont été touchés par une version défectueuse.

Avant l'activation, un jeu de tests fixe vérifie la nouvelle version : cas standards, cas particuliers connus et anciennes erreurs qui ne doivent plus jamais se reproduire. Cela ne remplace pas l'observation en exploitation, mais détecte les régressions grossières. Ensuite, la nouvelle version ne tourne d'abord que pour une petite partie des dossiers ou uniquement pour les types de demandes non critiques.

L'essentiel est le retour en arrière. Une version antérieure doit pouvoir être réactivée d'un simple geste, sans que personne n'ait à reconstituer l'ancienne formulation à partir d'un e-mail. Les dossiers traités entre-temps avec la version défectueuse peuvent être retrouvés et revérifiés grâce au journal. Toutes les actions ne sont pas réversibles, par exemple un message déjà envoyé. C'est pourquoi le retour en arrière implique aussi de se demander ce que l'agent avait le droit de déclencher seul pendant la période critique.

Sur le plan technique, une structure simple suffit pour commencer. Chaque étape est écrite comme un enregistrement structuré, et non comme du texte libre, par exemple au format JSON dans une base de données ou un système de logs. Structuré signifie que des champs comme l'identifiant du dossier, l'étape, l'outil, les paramètres, le statut de la réponse, la durée et la version de la consigne sont consultables individuellement. Le texte libre est réservé aux justifications et aux citations de la source.

L'enregistrement relève de la couche qui appelle les outils, pas de la consigne. Si c'est l'agent lui-même qui doit « journaliser », l'exhaustivité dépend de sa docilité. Si chaque appel d'outil passe par une couche intermédiaire qui conserve automatiquement l'entrée et le résultat, la trace est complète même lorsque l'agent se comporte autrement que prévu.

C'est aussi sur cette couche que l'on peut placer les mécanismes de protection : un plafond d'appels par dossier, une limite de temps par étape, une vérification du format de réponse par rapport au schéma attendu. Si le schéma diffère, par exemple parce qu'un champ manque ou porte un autre nom, on ne devine pas : le dossier est arrêté et signalé. Cela permet de détecter les modifications d'interface silencieuses qu'un agent seul ne remarque pas.

Pour les alertes, des règles simples suffisent au départ : le même appel plus de trois fois de suite, une étape plus longue que le temps défini, des coûts au-dessus du seuil, un schéma de réponse non respecté. Les notifications vont vers un canal que quelqu'un lit réellement. Une détection d'anomalies sophistiquée ne vaut la peine que lorsqu'il y a assez de données d'exploitation pour savoir ce qui est normal.

Un cas particulier est la dérive progressive. Rien ne casse, mais la qualité se dégrade : de nouveaux types de demandes apparaissent, un nom de produit change, une règle interne est ajustée sans que la consigne suive. Ni les alertes ni les taux d'erreur ne montrent ces écarts. Ils se révèlent lors des échantillonnages, surtout lorsque les relecteurs recherchent aussi des tendances au lieu de seulement évaluer des dossiers isolés.

Un deuxième cas est celui des erreurs différées. L'agent crée aujourd'hui une entrée de façon erronée, et le problème n'apparaît que des semaines plus tard, lorsque quelqu'un y accède. C'est là que la trace est précieuse, car elle montre quels dossiers avaient la même cause. Celui qui ne regarde que le système cible voit une seule donnée erronée. Avec le journal, on peut retrouver tous les cas similaires et les corriger ensemble.

Troisièmement, l'interaction entre plusieurs agents ou avec d'autres automatisations. Si un agent rédige un e-mail auquel un second système réagit automatiquement, des réactions en chaîne peuvent apparaître, qu'aucun des deux n'a causées seul. Les parades sont des plafonds pour les actions de suite déclenchées automatiquement et un marquage indiquant quels messages ont été générés par une machine.

Et enfin, la défaillance de la surveillance elle-même. Si le journal ne fonctionne plus, personne ne s'en aperçoit tant que l'agent continue de travailler. Nous mettrions donc en place une contre-alerte : si aucune entrée de journal n'arrive dans un délai attendu alors que des dossiers sont en cours, un signalement est émis. Un agent surveillé dont la surveillance est tombée en panne sans que personne ne le remarque est plus risqué qu'un agent volontairement tenu de près.

Le suivi ne rend pas un agent plus intelligent, il le rend contrôlable. L'intérêt est que les erreurs se remarquent plus tôt, que les causes se trouvent plus vite et que les modifications sont moins risquées. L'effet ressenti au quotidien dépend de l'usage : du nombre de dossiers, des systèmes connectés et de la gravité des conséquences d'une erreur.

On peut le mesurer avec des indicateurs proches de l'exploitation. Parmi eux : le délai entre l'apparition et la découverte d'une erreur, la part des dossiers transmis à des humains, la répartition des jugements d'échantillonnage au fil des semaines et l'évolution du coût par dossier. Relevez ces valeurs dès le début, même si elles paraissent peu spectaculaires au départ. Seule une évolution sur plusieurs semaines permet de juger.

Ce que l'on ne peut pas promettre : l'absence d'erreurs. Un agent reste un système qui travaille avec des probabilités, et une bonne surveillance réduit les dégâts sans les exclure. On ne peut pas non plus dire à l'avance combien d'alertes surviendront au début. Pendant la phase de lancement, elles sont généralement plus nombreuses que par la suite, car les seuils ne sont pas encore calés sur l'exploitation réelle.

Un autre avantage honnête est la sérénité. Si vous savez que chaque action est traçable, vous pouvez confier progressivement davantage de tâches à l'agent. Sans cette base, l'usage reste limité aux domaines où une erreur ne coûte rien, et ce n'est que rarement le domaine où un agent soulage le plus.

Quelques règles se dégagent de cette analyse. Premièrement : journalisez avant la mise en production de l'agent, pas après. Une trace ajoutée après coup ne montre que l'avenir, pas l'incident qui l'a motivée. Deuxièmement : gardez la trace petite et structurée, avec les quatre questions : entrée, décision, action et source. Troisièmement : prenez les consignes au sérieux comme un logiciel, avec versions, tests et retour en arrière.

Quatrièmement, il faut clarifier les responsabilités. Qui lit les alertes, qui tire les échantillons, qui peut revenir à une version antérieure ? Sans personnes désignées, le meilleur suivi reste un dossier plein de données. Cinquièmement, un démarrage ciblé aide : un processus, un type de demande, peu d'outils. La manière de choisir un tel processus pilote est décrite dans une étude à part.

Sixièmement, il faut introduire les alertes avec parcimonie et discernement. Cinq règles que quelqu'un prend au sérieux valent mieux que vingt qui sont mises en sourdine au bout d'une semaine. De nouvelles règles ne s'ajoutent que lorsqu'un incident réel montre qu'il y a une lacune. Ainsi, l'ensemble des règles se construit à partir de l'expérience réelle et non d'une liste de contrôle de manuel.

Votre prochaine étape est modeste. Prenez un dossier qu'un agent ou une automatisation traite aujourd'hui et demandez-vous : pourrais-je expliquer en cinq minutes pourquoi cette étape précise a été décidée ainsi ? Sinon, la trace manque. Nous examinons volontiers votre processus avec vous et vous disons honnêtement quelle surveillance est adaptée à votre cas et laquelle serait excessive.