Observabilité des systèmes d'IA : journaliser quoi, et pourquoi

L’observabilité d’un système d’IA générative est sa capacité à montrer, à partir de traces enregistrées, pourquoi il a produit chaque réponse, parce qu’un tel système ne renvoie aucune erreur quand il se trompe. Ce n’est donc pas une bonne pratique : c’est la seule façon de savoir ce qui se passe.

Sur un service applicatif, l’observabilité sert à détecter des pannes : le taux d’erreur monte, la latence explose, une dépendance tombe.

Un système d’IA générative n’a pas ces symptômes. Il répond, dans les temps, avec un code de retour normal. Quand il se dégrade, il produit simplement des réponses moins bonnes, ce qui n’apparaît dans aucun indicateur technique. Un changement de version du modèle, un corpus qui vieillit ou un contexte qui grossit passent inaperçus, comme dans le jour où le modèle a changé sans prévenir.

L’observabilité d’un système d’IA répond donc à trois questions qu’un tableau de bord technique ignore : la réponse était-elle juste, sur quels éléments reposait-elle, et qu’en a fait l’humain qui l’a reçue ?

Pour un système d’IA documentaire, cinq champs suffisent à journaliser : la question, les extraits fournis au modèle, la réponse, la décision humaine et l’horodatage. Le deuxième est celui qui décide de tout.

Devant une réponse fausse, la seule question utile est : l’information correcte figurait-elle dans ce qui a été fourni ? Si oui, le problème est dans le prompt ou le modèle. Si non, il est dans la recherche ou le corpus. Ce sont deux corrections opposées.

Sans cette trace, l’équipe modifie le prompt par défaut, ce qui installe le cycle où l’on corrige un cas en en cassant deux autres. La méthode de diagnostic est détaillée dans reprendre un système d’IA construit par quelqu’un d’autre.

Le taux de réponses « je ne sais pas », suivi dans le temps, est l’indicateur avancé le plus fiable d’un système d’IA, car il bouge plusieurs jours avant les signalements utilisateurs. C’est le seul indicateur que je place systématiquement en tête d’un tableau de bord.

Une baisse soudaine signale que le système répond là où il refusait : une dégradation, pas un progrès. Une hausse signale l’inverse : le modèle est devenu plus prudent et des questions légitimes reçoivent un refus. Pourquoi ce refus est une qualité et non un défaut est expliqué dans le refus de répondre est une fonctionnalité.

J’y adjoins le nombre moyen de jetons envoyés par requête, qui détecte la reprise de poids du contexte, et le temps jusqu’au premier jeton au quantile élevé. Ces trois mesures et leur exploitation figurent dans mesurer le coût par fonctionnalité.

Mettre en place l’observabilité d’un système d’IA se fait en cinq étapes, de la définition des champs au rendez-vous de lecture, et chacune se décide à la conception plutôt qu’en exploitation. L’ordre compte, parce que les décisions de conservation conditionnent tout le reste.

1. Fixer les cinq champs et leur format. Pour les extraits, stocker les identifiants des documents et leur position, pas leur contenu.
2. Décider la durée de conservation et les accès au journal, avec le délégué à la protection des données, avant la première requête enregistrée.
3. Capter la décision humaine dans l’interface. Accepter, corriger, rejeter : sans ce geste, le taux de correction n’existe pas.
4. Calculer les indicateurs automatiquement, chaque jour, à partir du journal : taux de non-réponse, taux de correction, longueur du contexte, latence.
5. Instituer une lecture hebdomadaire par l’exploitant, avec une personne nommée et un seuil d’alerte par indicateur.

Le journal alimente aussi le jeu de tests : les questions mal traitées deviennent des cas de test, ce qui relie l’observabilité à l’évaluation continue, le chaînon manquant.

Le dispositif d’observabilité d’un système d’IA et la traçabilité exigée en conformité sont le même enregistrement, ce qui permet de traiter les deux besoins d’un coup. C’est l’argument qui débloque le budget.

Pour l’exploitation, il permet de comprendre pourquoi une réponse était mauvaise : le bon document n’a pas été retrouvé, ou il l’a été et le modèle ne l’a pas utilisé. Ce sont deux problèmes différents, avec deux corrections différentes, et sans journal on ne peut pas les distinguer.

Pour la conformité, il constitue la trace exigée par le règlement européen sur les systèmes à haut risque, et il documente l’effectivité de la supervision humaine : notamment par le temps passé sur chaque décision. Ce que la supervision doit montrer est détaillé dans supervision humaine : la concevoir, pas la promettre.

Un responsable technique demande des journaux pour diagnostiquer. Un responsable conformité demande des traces pour démontrer. Les cinq champs satisfont les deux, à condition que les journaux soient réellement interrogeables : un fichier que personne ne sait lire ne sert ni au diagnostic ni au contrôle. L’ordre de priorité figure dans ce qui doit exister avant l’échéance.

Un journal de système d’IA contient presque toujours des données personnelles, et il ne faut pas y dupliquer le contenu des documents sensibles : leurs identifiants suffisent au diagnostic. La question posée par un salarié en dit long sur son travail ; le document retrouvé peut être confidentiel.

Trois règles que j’applique systématiquement. Une durée de conservation décidée avec le délégué à la protection des données, et appliquée automatiquement. Un cloisonnement des accès au journal lui-même, qui est souvent plus sensible que le corpus. Et un stockage des identifiants de documents plutôt que de leur contenu, ce qui suffit au diagnostic sans dupliquer la donnée.

Ajoutée sur un système d’IA déjà en exploitation, l’observabilité coûte bien plus cher qu’à la conception, parce qu’elle oblige à reprendre le schéma de données, l’interface et les règles de conservation. Prévue dès la conception, la journalisation représente une part marginale du développement.

Ajoutée après coup, elle suppose de reprendre le schéma de données, de trancher la conservation, de traiter les données personnelles déjà présentes, et souvent de modifier l’interface pour capter la décision humaine qui n’était enregistrée nulle part. J’ai vu ce chantier occuper plusieurs semaines, sur un système qui aurait pu l’intégrer en deux jours au départ.

Les erreurs les plus fréquentes sont connues :

• Journaliser la question et la réponse, mais pas les extraits. On voit l’erreur sans pouvoir l’attribuer à la recherche ou à la génération.
• Tout conserver sans durée décidée. Le journal devient un risque au lieu d’un outil.
• Multiplier les indicateurs. Au-delà de quelques courbes, personne ne lit le tableau de bord.
• Oublier la décision humaine. Sans elle, ni le taux de correction ni la preuve de supervision n’existent.

Sur un système existant, un audit de système d’IA commence précisément par vérifier ce que le journal permet de reconstituer.