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

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.

C'est le point qui rend l'effort rentable. Le même enregistrement sert deux besoins qu'on traite d'ordinaire séparément.

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.

Un journal d'IA contient des données personnelles, presque toujours. 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.

Prévue dès la conception, la journalisation représente une part marginale du développement.

Ajoutée sur un système en exploitation, 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.

La question, les extraits fournis au modèle, la réponse, la décision humaine et l'horodatage. Cinq champs, et 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, 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.

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é.

Le dispositif d'observabilité et celui exigé en conformité sont le même, ce qui permet de traiter les deux besoins d'un coup. C'est l'argument qui débloque le budget.

Un responsable technique demande des journaux pour diagnostiquer. Un responsable conformité demande des traces pour démontrer. Les cinq champs satisfont les deux.

Deux précautions les accompagnent : une durée de conservation décidée explicitement en tenant compte de la protection des données, et des journaux 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.