Superviser un système IA : concevoir des capteurs qui savent dire non

La réponse, tout de suite

Superviser un système agentique, ce n'est pas ajouter un tableau de bord ni brancher des alertes. C'est se donner le moyen de distinguer trois états : le système fait ce qu'il prétend faire, il ne le fait pas, ou personne ne sait.

La question qui tranche la qualité d'une supervision tient en une phrase : ce capteur a-t-il déjà été vu en train de refuser ? S'il n'a jamais rien signalé, rien ne dit qu'il en est capable.

Un capteur qu'on n'a jamais vu échouer est indiscernable d'un capteur absent. Tout ce qui suit découle de ce constat, et il coûte peu à mettre en place au moment de la conception.

Pourquoi « pensée dès la conception » ne suffit pas

La recommandation courante consiste à concevoir la supervision en même temps que l'agent, plutôt que de l'ajouter après le premier incident. Elle est juste, et elle est insuffisante.

Nos propres incidents en production l'illustrent. Dans les trois cas les plus coûteux que nous avons rencontrés, le dispositif de surveillance existait avant l'incident, il avait été conçu en amont, et il n'a rien empêché.

Un mécanisme de reprise a transformé une anomalie en avalanche. Une contrainte d'unicité était déclarée mais ne pouvait jamais entrer en conflit. Un contrôle quotidien se déclarait en bonne santé parce qu'il ne savait pas lire ce qu'il surveillait.

Le récit détaillé de ces trois pannes est dans notre article sur les agents IA marketing. Ce qui nous occupe ici est ce qu'elles ont en commun : le moment où le dispositif a été posé n'était pas le problème.

Ce qui manquait était la preuve. Aucun de ces trois dispositifs n'avait jamais été exercé dans les conditions où il devait refuser. Le sujet du design n'est donc pas le calendrier, c'est la démonstration.

Un contrôle a trois verdicts, pas deux

La faute de conception la plus fréquente consiste à écrire un contrôle qui ne peut rendre que deux réponses : tout va bien, ou quelque chose ne va pas. Il en manque une troisième, et c'est elle qui fait les pannes longues.

Un contrôle lit une donnée, l'interprète, puis conclut. Quand la lecture échoue, un code écrit naturellement produit une valeur vide, et une valeur vide ressemble à une absence d'anomalie. Le contrôle annonce alors que tout va bien, indéfiniment, avec une conviction parfaite.

Les trois verdicts à écrire explicitement sont les suivants.

• Sain : la mesure a été faite, elle est dans la plage attendue.
• En défaut : la mesure a été faite, elle est hors plage.
• Indéterminé : la mesure n'a pas pu être faite, et c'est un événement à nommer.

Le troisième verdict ne doit jamais se confondre avec le premier dans le message rendu, ni dans la couleur d'un tableau de bord. Un « je n'ai pas su lire » silencieux revient à débrancher la surveillance en croyant l'avoir installée.

Le même raisonnement s'applique à un verdict qui ne peut prendre qu'une seule valeur. Un contrôle dont la réponse est toujours la même, quelle que soit la réalité, ne mesure rien : il décore.

Le test négatif, seule preuve qu'un capteur fonctionne

Un capteur se prouve en le faisant refuser. Nous appelons cela le test négatif, et c'est le geste de conception qui distingue une supervision réelle d'une supervision déclarative.

Le principe est simple : fabriquer un cas qui doit ressortir, le passer au capteur, et exiger qu'il le signale. Si le cas passe au vert, le capteur est inutile, quelle que soit son élégance.

Trois exigences rendent ce test concluant, et elles se posent au moment où l'on écrit le capteur.

• Le test s'exécute sur le code réellement en service, en production ou dans un environnement de préproduction qui en est la copie conforme, et jamais sur un extrait recopié à la main.
• Il compare l'ancien et le nouveau comportement, et il exige au moins un désaccord entre les deux.
• Il porte au moins un cas qui doit être refusé, pas seulement des cas qui doivent passer.

La nuance compte : une préproduction ou un bac à sable qui rejoue le code tel quel est un banc d'essai légitime, et c'est même le seul endroit où éprouver un correctif sans risque. Ce qui ne vaut rien, c'est un test écrit sur une copie retouchée, qui finit par valider une version que personne n'exécute.

Sur nos propres sondes, cette contre-épreuve a régulièrement trouvé des défauts réels. Sur l'une d'elles, rejouer les critères sur le code d'avant correction a produit six échecs sur quatorze cas, ce qui a prouvé que la correction faisait bien quelque chose.

Le test négatif est aussi ce qui protège d'une erreur plus subtile : un banc d'essai qui reproduit la même erreur que le code testé passe au vert et confirme la panne. Écrire le cas qui doit échouer oblige à formuler ce que le capteur est censé attraper.

Mesurer par poste, jamais en agrégé

Un indicateur agrégé devient aveugle dès que deux mouvements de sens opposé tombent dans le même intervalle de mesure. Ce n'est pas une hypothèse théorique, c'est un mode de panne courant.

Nous l'avons mesuré sur notre propre infrastructure : une accumulation de dix-neuf gigaoctets et une libération de neuf gigaoctets survenues dans la même journée ont produit un relevé quasi immobile. L'incident n'a été vu que parce qu'un humain a regardé le détail.

Trois contre-mesures intuitives échouent sur ce cas, et il ne faut pas les construire.

• Abaisser le seuil : le mouvement net reste minuscule, donc il ne franchit rien.
• Surveiller la vitesse de l'agrégat : c'est la variation elle-même qui est neutralisée.
• Purger par ancienneté : un délai de rétention protège d'une accumulation lente, jamais d'un pic.

La forme correcte consiste à mesurer poste par poste, avec un seuil calibré sur la taille normale de chaque poste, et à nommer le contributeur dans l'alerte. Cette dernière information est la seule qui soit directement actionnable.

Le principe déborde largement l'espace disque. Il vaut pour un coût de modèle par usage, une consommation par service, ou un volume d'exécutions par traitement.

Ce que la supervision exige de l'humain

Une supervision honnête produit du travail humain, et un dispositif qui n'en produit jamais mérite qu'on se demande s'il fonctionne.

Le cas typique est l'acquittement. Une sonde bien conçue conserve sa dernière mesure saine tant qu'un écart n'est pas réparé, sans quoi elle adopterait l'état dégradé et éteindrait son alerte au passage suivant. Conséquence directe : quand l'écart vient d'une décision assumée, la sonde reste au rouge jusqu'à ce qu'un humain le déclare.

C'est un bon défaut, et il faut le prévoir dès la conception : un geste d'acquittement explicite, tracé, qui ne touche jamais à la logique du capteur. Assouplir un contrôle pour faire taire une alerte revient à supprimer le contrôle avec un délai.

Deux autres exigences relèvent du même registre.

• Un dispositif qui redémarre doit savoir s'arrêter, avec un plafond de tentatives et une alerte qui nomme le geste attendu.
• Une alerte qui se répète à chaque passage cesse d'informer, donc on alerte sur transition, et on notifie aussi le retour à la normale.

La grille à exiger avant de confier un système

Ces six questions permettent de juger la supervision d'un système avant sa mise en production, qu'il soit construit en interne ou par un prestataire. Elles se répondent en quelques minutes, et une réponse floue est une réponse.

Ces questions ne demandent aucune compétence technique pour être posées, et elles filtrent efficacement. Un consultant IA marketing sérieux répond aux six sans préparation, parce que ce sont les décisions qu'il a prises en concevant le système.

À l'inverse, une réponse qui renvoie systématiquement à un tableau de bord sans expliquer ce qui l'alimente signale une supervision déclarative.

Notre façon de faire

Nous concevons ces systèmes et nous les exploitons au quotidien, ce qui n'est pas la même chose que les livrer. Les principes décrits ici viennent de nos propres capteurs et de nos propres erreurs, pas d'une veille technologique.

Concrètement, tout changement passe par cinq contrôles avant d'atteindre la production : reproduire le défaut avant de le corriger, vérifier le résultat réel et non le code de retour, ne changer qu'une chose à la fois avec un retour arrière prêt, observer au moins une exécution réelle, et préférer une opération rejouable à un dispositif de reprise.

C'est cette expérience d'exploitation qui permet de concevoir des systèmes plus robustes dès le départ, et c'est ce que nos clients viennent chercher : des dispositifs qui tiennent, pas une démonstration.

Elle ne suffit pas pour autant, et le prétendre serait malhonnête. Les systèmes se complexifient, les interfaces des outils sur lesquels ils s'appuient changent sans prévenir, et une conception juste au moment où elle est faite vieillit. Aucune expérience ne protège d'un mode de panne qui n'existait pas l'année précédente.

La conséquence pratique est qu'on ne s'en tient jamais à ce qui a été conçu. Chaque incident réel devient un contrôle de plus, écrit à partir du cas qui nous a échappé, si bien que la supervision se renforce avec le temps au lieu de se figer. C'est la seule forme d'apprentissage sur laquelle nous nous engageons : elle est lente, et elle est vérifiable.

Cette exigence est aussi ce que recouvre notre travail d'expert en automatisation commerciale quand un pipeline tourne sans se plaindre : surveiller un système qui ne signale rien est un métier à part entière, décrit dans notre étude de cas Overpipe.

Si votre sujet porte plus largement sur ce qui casse après la mise en production d'une automatisation, nous l'avons traité en détail dans notre article sur l'automatisation IA en PME.