Garder un agent en état de marche
Un agent en production pose un problème d’exploitation que la supervision classique ne couvre pas. Les instruments habituels mesurent la disponibilité, la latence et le taux d’erreur technique, et ces trois indicateurs peuvent rester parfaitement verts pendant qu’un système donne des réponses fausses depuis six semaines. Le mode de défaillance dominant ici n’est pas la panne, c’est la dégradation silencieuse : un fournisseur change de version de modèle, une source d’entrée modifie son format, un nouveau type de cas apparaît, et le système continue de répondre en produisant des sorties moins bonnes sans qu’aucun signal ne remonte. Trois dispositifs traitent cela, et ils se conçoivent avant la mise en service parce qu’aucun ne se reconstitue après. Une trace de décision qui permette de savoir ce que le système a fait et pourquoi. Un jeu d’évaluation rejoué automatiquement, qui transforme une dégradation en alerte. Et une surveillance du coût et du nombre d’étapes, qui empêche une exécution aberrante de consommer jusqu’à la facture.
La trace de décision
Une journalisation qui conserve la question posée et la réponse rendue suffit pour un assistant et ne suffit pas ici. Quand un agent produit un résultat aberrant, la question qui se pose est celle de l’étape où le raisonnement a dévié, et elle ne se répond pas sans trace intermédiaire.
Ce qu’il faut conserver, par étape : l’entrée, la décision prise, l’outil appelé avec ses paramètres, la sortie obtenue, la durée et le coût. Cela paraît volumineux et l’est moins qu’il n’y paraît, parce que le nombre d’étapes est borné par construction dans un système bien conçu.
Une contrainte accompagne cette trace : elle contient les données du client. Sa durée de conservation, son chiffrement et les droits d’accès qui la protègent se décident au même moment que son format, faute de quoi on crée un actif sensible par accident.
Le jeu d’évaluation rejoué
C’est le dispositif le plus important et le plus souvent absent. Un ensemble de cas réels, étiquetés par des personnes compétentes, rejoué automatiquement à intervalle régulier et après chaque changement de version chez un fournisseur.
Sans lui, une organisation apprend les régressions par les plaintes de ses utilisateurs, c’est-à-dire plusieurs semaines après qu’elles ont commencé, et souvent sous une forme qui ne permet pas d’identifier la cause. Avec lui, une baisse déclenche une alerte le jour même et le changement responsable est identifiable.
Une précaution de lecture s’impose : une moyenne cache l’échec qui compte. Un système dont la justesse globale reste stable peut s’être effondré sur une catégorie de cas précise, celle qui intéresse le client le plus important. Les résultats se lisent donc par catégorie et non en agrégat.
Le coût et le nombre d’étapes
Deux indicateurs suffisent et ils sont rarement en place : le coût par requête et le nombre d’étapes par exécution. Le second prédit le premier et se surveille plus facilement.
Un plafond d’étapes est indispensable. Un agent qui ne converge pas boucle, et une boucle consomme jusqu’à ce que quelqu’un s’en aperçoive. Sur un système ouvert au public, cette découverte se fait parfois par la facture mensuelle, ce qui est la façon la plus coûteuse d’apprendre qu’un cas particulier n’avait pas été prévu.
La distribution du nombre d’étapes apprend en outre quelque chose d’utile sur le système. Si la médiane est basse et la queue longue, une petite catégorie de cas pose problème, et l’examiner conduit souvent à une amélioration simple. Si la distribution est uniformément haute, la conception elle-même mérite d’être revue.
Ce que la supervision classique ne voit pas
Les instruments d’exploitation habituels restent nécessaires et ils mesurent une autre chose. La disponibilité dit que le système répond. La latence dit qu’il répond vite. Le taux d’erreur technique dit qu’aucun appel n’a échoué.
Aucun des trois ne dit que les réponses sont justes, et c’est exactement le mode de défaillance dominant ici. Un agent parfaitement disponible, rapide et sans erreur technique peut produire des sorties fausses pendant six semaines, avec tous les voyants au vert et une équipe d’exploitation qui n’a rien à se reprocher.
L’ajout à faire est donc modeste en volume et décisif en nature : les indicateurs de qualité mesurée, de nombre d’étapes, de coût et de taux de remontée rejoignent le tableau de bord existant plutôt que de le remplacer. Une équipe d’exploitation accepte généralement bien cet ajout, à condition qu’on lui explique pourquoi ses indicateurs habituels ne suffisent pas.
Le taux de remontée vers une personne
Un dernier indicateur, moins évident, mesure la santé réelle du système : la proportion de cas que l’agent transmet à une personne plutôt que de traiter lui-même.
Cette proportion doit exister. Un système qui ne remonte jamais rien ne reconnaît pas ses limites, ce qui signifie qu’il traite avec assurance des cas qu’il ne maîtrise pas. Sa valeur est alors surestimée et le sera jusqu’au premier incident.
Sa variation est aussi instructive que son niveau. Une hausse soudaine signale un changement dans les entrées, souvent avant que la mesure de qualité ne bouge. C’est l’un des rares indicateurs qui alerte en amont plutôt qu’en aval, et il ne coûte rien à mettre en place.
