← Tous les articles
    4 juillet 2026 · production · supervision · qualité

    Superviser des agents IA en production

    Un agent qu'on ne regarde plus dérive sans prévenir. Voici quoi instrumenter.

    Par Marie Van Haecke

    Une automatisation classique qui casse, ça se voit : plus rien n'arrive, quelqu'un râle. Un agent IA qui se dégrade, ça ne se voit pas. Il continue de produire des sorties, elles ont toujours l'air correctes, et la qualité baisse d'un cran tous les mois sans qu'aucun voyant ne s'allume. C'est la différence structurelle entre les deux, et c'est pour ça que la supervision d'un agent ne s'improvise pas après coup.

    Pourquoi ça dérive alors que rien n'a changé

    Le paradoxe qu'on me signale souvent : « On n'a rien touché et ça marche moins bien. » Plusieurs causes, toutes banales.

    • Le modèle a changé. Ton fournisseur a mis à jour la version derrière le même nom d'API. Le comportement bouge, parfois en mieux, parfois pas sur ton cas précis.
    • Les entrées ont changé. Tes clients écrivent différemment, un nouveau canal est apparu, un formulaire a gagné un champ. L'agent voit des données qu'il n'a jamais vues au réglage.
    • Le contexte a changé. La base documentaire s'est enrichie de fichiers moyens. Une procédure a évolué et le prompt parle encore de l'ancienne.
    • L'usage a changé. Les gens ont compris ce que l'agent sait faire et lui envoient des cas plus durs. Le taux de réussite baisse alors que l'agent est identique.

    Aucune de ces causes ne produit d'erreur technique. D'où la nécessité de mesurer la qualité, pas seulement la disponibilité.

    Ce qu'il faut logger dès le premier jour

    Le réflexe à prendre, c'est de tout écrire au moment où on construit, pas quand un problème apparaît. Reconstituer après coup est impossible.

    Pour chaque exécution, garde :

    • L'horodatage et un identifiant unique, pour pouvoir retrouver un cas dont on te parle.
    • L'entrée brute, telle que reçue.
    • La version du prompt et le modèle appelé, avec son numéro de version exact.
    • Le contexte injecté — quels documents, quels enregistrements ont été passés au modèle. Sans ça, tu ne pourras jamais expliquer une réponse bizarre.
    • La sortie brute avant post-traitement.
    • La décision finale : envoyé, escaladé, corrigé, rejeté.
    • Le coût et la latence de l'exécution.

    Attention aux données personnelles : ce journal en contient, il est soumis aux mêmes règles que le reste de tes traitements, avec une durée de conservation définie et un accès restreint. Ce n'est pas un avis juridique, et sur ce point précis fais valider par quelqu'un dont c'est le métier.

    Les quatre indicateurs qui parlent

    Il en existe beaucoup. Quatre suffisent à voir venir presque tout.

    Le taux d'escalade. La part d'exécutions où l'agent passe la main. C'est le meilleur détecteur précoce dont je dispose. Il monte : quelque chose a changé dans les entrées, ou le modèle est devenu plus prudent. Il baisse d'un coup : c'est presque toujours mauvais signe — l'agent a cessé de reconnaître ses limites.

    Le taux de correction humaine. Parmi les sorties validées par un humain, quelle proportion est modifiée avant envoi ? Il capte la qualité perçue par ceux qui travaillent avec l'outil. Il demande un geste minimal côté interface : un bouton « validé tel quel » face à une modification, sinon la donnée n'existe pas.

    Le coût par exécution. Pas le coût total du mois, qui masque tout. Le coût unitaire moyen. Sa dérive révèle un contexte qui a grossi, une boucle d'agent qui tourne plus longtemps, des relances silencieuses.

    La latence, au 95e centile. La moyenne ment. Ce qui compte, c'est ce que subissent les cas lents, parce que ce sont eux qui font abandonner l'outil.

    Un tableau avec ces quatre courbes sur douze semaines vaut plus que n'importe quel rapport d'évaluation ponctuel.

    Relire un échantillon, à la main

    Les indicateurs disent qu'il se passe quelque chose. Ils ne disent jamais quoi. Pour ça, il faut lire.

    Le rythme que je recommande : vingt à trente cas par mois, tirés au hasard, relus par quelqu'un qui connaît le métier. Pas par la personne qui a construit l'agent — elle voit ce qu'elle a voulu faire, pas ce que ça produit.

    Pour chaque cas, une seule question, notée : cette sortie est-elle acceptable telle quelle, oui ou non ? Pas de note sur cinq, pas de nuance. Le pourcentage d'acceptables, suivi mois après mois, est l'indicateur de qualité le plus honnête que je connaisse.

    Ajoute-y une deuxième pile, non aléatoire celle-là : tous les cas escaladés de la semaine, parcourus rapidement. C'est là que se trouvent les nouveaux types de demandes.

    La revue mensuelle, une heure

    Un créneau fixe, les mêmes participants, l'ordre du jour toujours identique :

    1. Les quatre courbes, sur douze mois glissants. Ce qui a bougé, et pourquoi.
    2. Le résultat de la relecture d'échantillon. Le pourcentage, et deux ou trois cas lus à voix haute.
    3. Les incidents du mois et ce qu'on en fait.
    4. Une décision : on ajuste, on élargit le périmètre, on le restreint, ou on arrête.

    Le point 4 est celui qu'on saute, et c'est le seul qui justifie la réunion. Une revue qui ne décide rien devient un rituel, puis disparaît.

    Prévois aussi, dès la conception, le bouton d'arrêt : comment couper l'agent en moins de cinq minutes, et qui a le droit de le faire. Une supervision sans capacité d'arrêt est un système d'alarme sans extincteur.

    Le réflexe à installer

    Aucun agent ne part en production chez moi sans que trois choses existent : un journal complet, un tableau des quatre indicateurs, et une date de première revue inscrite dans un agenda. C'est trois quarts d'heure de travail au moment du lancement. C'est ce qui fait la différence entre un outil qu'on pilote et un outil qu'on subit.

    À lire aussi

    Vous travaillez sur un sujet proche ?

    J'accompagne les organisations sur l'audit IA, le cadrage de produits IA, les agents et l'automatisation. Si cet article recoupe une question que vous vous posez, on peut en parler.