Observabilité IA : tableau de bord de suivi des dérives et des hallucinations d'un système d'IA en production

Observabilité IA, comment suivre les dérives et les hallucinations ?

Série « L’IA en production, le guide du DSI », épisode 4

Un système d’IA défaillant se met à répondre à côté, sans bruit. Sans observabilité, ce sont vos clients, vos auditeurs ou la presse qui vous préviendront.

En juillet 2025, Deloitte Australie remet au ministère de l’Emploi un rapport de 273 pages facturé 440 000 dollars australiens. Un universitaire y trouve une citation inventée de toute pièce d’un jugement fédéral et des références à des travaux qui n’existent pas. Le cabinet reconnaît avoir utilisé Azure OpenAI et rembourse la dernière échéance du contrat. Le modèle n’était pas en cause, le problème est que personne ne contrôlait ce qu’il produisait.

C’est exactement le rôle de l’observabilité IA.

Qu’est ce que l‘observabilité IA ?

L’observabilité IA est la capacité à savoir, à tout moment, ce que fait un système d’IA en production, pourquoi il le fait et s’il le fait correctement. Elle couvre les modèles de langage (LLM), les assistants RAG, les agents et les modèles de machine learning classiques.

Une supervision sait dire si une application répond mais elle ne sait pas dire si la réponse est juste. Un assistant peut afficher 100 % de disponibilité et un temps de réponse satisfaisant tout en inventant et cela peut avoir des conséquences dramatiques.

Supervision classique vs Observabilité IA
Critère Supervision classique Observabilité IA
Question posée Le service fonctionne-t-il ? Le service répond-il correctement ?
Ce qu’on mesure Disponibilité, latence, erreurs Qualité, exactitude, dérive, coût par requête
Type de panne Visible : le service s’arrête Silencieuse : la qualité se dégrade
Qui juge L’outil L’outil, le métier et des contrôles humains
Comportement Déterministe Probabiliste : deux questions identiques, deux réponses

On parle aussi de monitoring IA, d’observabilité des LLM ou de LLMOps pour désigner l’ensemble des pratiques d’exploitation des modèles de langage. L’observabilité est la brique centrale.

Pourquoi l’observabilité IA est nécessaire ?

Parce que les IA sont passées en production plus vite que les moyens de les surveiller.

L’AI Act ajoute une obligation. Pour les systèmes à haut risque, le déployeur doit surveiller leur fonctionnement et conserver les journaux au moins six mois (article 26). Ces obligations s’appliqueront le 2 décembre 2027 après le report voté dans l’Omnibus IA (voir l’épisode 1).

Quels sont les indicateurs à surveiller ?

Le dispositif doit suivre cinq catégories d’indicateurs, avec un seuil d’alerte et un destinataire pour chacune.

Les 5 familles d’indicateurs à surveiller

01

Qualité des réponses

Ce qu’on mesure

Taux de bonnes réponses sur un jeu de tests, satisfaction des utilisateurs

Exemple de seuil d’alerte

Baisse de plus de 5 points sur une semaine

Qui est alerté : Responsable métier

02

Hallucinations

Ce qu’on mesure

Réponses non fondées sur les sources, citations inventées

Exemple de seuil d’alerte

Plus de 2 % des réponses contrôlées

Qui est alerté : Responsable métier et équipe IA

03

Dérive

Ce qu’on mesure

Évolution des questions posées, des données d’entrée, des réponses

Exemple de seuil d’alerte

Écart significatif avec la période de référence

Qui est alerté : Équipe IA

04

Coûts

Ce qu’on mesure

Coût par requête, par utilisateur, par cas d’usage

Exemple de seuil d’alerte

Dépassement de 20 % du budget mensuel

Qui est alerté : Responsable FinOps

05

Sécurité et conformité

Ce qu’on mesure

Tentatives d’injection, fuites de données, actions hors périmètre

Exemple de seuil d’alerte

Toute occurrence

Qui est alerté : RSSI

Le pilotage des coûts fera l’objet d’un épisode dédié de cette série, consacré au FinOps IA.

Comment détecter les hallucinations IA en production ?

Une hallucination est une réponse fausse présentée avec beaucoup d’assurance, comme un chiffre, une référence ou une source inventés. Ce n’est pas à proprement parler un bug, le modèle de langage produit ce qui est le plus probable, ce qui n’est pas forcément la vérité.

On ne supprime pas les hallucinations mais on les réduit et on les détecte.

Réduction des hallucinations

Ancrer les réponses

L’architecture RAG oblige le modèle à répondre à partir de vos documents source.

Exiger les sources

Chaque réponse doit citer le passage sur lequel elle s’appuie.

Autoriser le refus

Le système doit savoir répondre « Je ne sais pas » plutôt que d’inventer.

Tenir la base documentaire à jour

Une source obsolète amène forcément une réponse fausse.

Détection des hallucinations

Contrôle d’ancrage automatique

Vérifier que chaque affirmation de la réponse est bien dans les sources.

Évaluation par un second modèle

Un modèle « juge » évalue la réponse selon une grille prédéfinie avec le métier.

Échantillonnage humain

Un expert métier relit de manière hebdomadaire un échantillon de réponses.

Retours des utilisateurs

Un bouton de signalement, analysé chaque semaine, est à disposition.

La dérive, ce système qui fonctionnait mais qui se dégrade

Un système d’IA validé ne garde pas cet état ad vitam aeternam. Voici les quatre principales causes de dérive.

  1. Les questions changent car les utilisateurs posent des questions que le jeu de tests initial ne couvrait pas.
  2. Les données changent avec l’arrivée de nouveaux produits, une nouvelle réglementation, des documents remplacés (on parle de data drift).
  3. Le modèle change car le fournisseur a déployé une nouvelle version (parfois sans prévenir) et le comportement varie.
  4. Les usages s’étendent comme par exemple un assistant IA conçu pour les RH qui finit par répondre à des questions juridiques.

Pour garder la maîtrise, il suffit d’appliquer deux règles. La première consiste à relancer les tests de non-régression à chaque nouvelle version du modèle, et au moins une fois par mois. La seconde consiste à mettre à jour le jeu de tests chaque mois en y ajoutant les questions réellement posées par les utilisateurs.

Un agent ne se contente pas de répondre. Il lit des données, appelle des outils, décide et agit. L’observabilité doit donc reconstituer toute la chaîne.

Pour chaque exécution, la journalisation doit permettre de répondre à cinq questions :

  • Qui a déclenché l’agent et avec quelle identité ?
  • Quelles données a-t-il lues et dans quels systèmes sources ?
  • Quels outils a-t-il appelés avec quels paramètres ?
  • Quelle décision a-t-il prise et sur quelle base ?
  • Qui l’a validée quand une validation humaine était requise ?

Le niveau d’observabilité suit le niveau d’autonomie défini dans l’épisode 2. Un assistant qui propose se contente d’un échantillonnage. Un agent qui agit seul a besoin d’une journalisation exhaustive, d’alertes temps réel et d’un arrêt d’urgence testé.

Ces éléments alimentent la rubrique « Contrôles » de la fiche d’identité de chaque système, telle que décrite dans l’épisode 3.

Quels outils sont nécessaires à l’observabilité IA ?

Plusieurs options s’offrent à vous et dans la réalité des projets, on les mixe souvent.

  • Étendre votre outil d’observabilité actuel : Datadog, Dynatrace, Elastic, New Relic ou Splunk proposent des modules dédiés aux LLM. C’est le choix le plus simple si vos équipes les maîtrisent déjà.
  • Adopter un outil spécialisé : Langfuse et MLflow (Open source) ou le français Giskard vont plus loin sur l’évaluation de la qualité et les jeux de tests.
  • Utiliser les modules de votre plateforme cloud : Azure AI Foundry, Google Vertex AI ou AWS Bedrock intègrent une supervision de base, suffisante pour démarrer.

Au delà des fonctionnalités, le critère de compatibilité avec OpenTelemetry (le standard ouvert de journalisation) est déterminant. Ses conventions pour l’IA générative sont encore en développement, mais les exiger dès maintenant vous permettra de changer d’outil sans refaire toute l’intégration.

Points de vigilance : les 5 erreurs les plus fréquentes

  1. 1

    Surveiller l’infrastructure et pas les réponses

    Les tableaux de bord sont verts, la qualité s’est effondrée.

  2. 2

    Pas de jeu de tests de référence

    Sans lui, impossible de dire si le système s’est dégradé.

  3. 3

    Des alertes sans destinataire

    Elles s’accumulent dans un outil que personne ne consulte.

  4. 4

    Des journaux incomplets

    Au premier incident, impossible de reconstituer ce que l’agent a fait.

  5. 5

    Journaliser sans protéger les données personnelles

    Les questions des utilisateurs contiennent des données personnelles, qu’il faut masquer et conserver selon une durée définie avec le DPO.

Le monitoring classique surveille l’infrastructure : disponibilité, latence, taux d’erreur. Il ne détecte pas une régression de la qualité des réponses. C’est cet indicateur qu’il faut ajouter au run, avec ses seuils et ses alertes.

Luc Doladille, Directeur Conseil de Smartpoint

Par où commencer pour superviser vos IA ?

  1. Partir de l’inventaire. Reprenez la liste de vos systèmes d’IA et classez-les par criticité. Commencez par ceux qui répondent à des clients ou qui agissent seuls.
  2. Fixer les indicateurs avec le métier. Pour chaque système, choisissez trois à cinq indicateurs, leurs seuils et un jeu de tests de référence d’au moins 50 questions validées par le métier.
  3. Instrumenter. Journalisez chaque requête et chaque action d’agent, au format OpenTelemetry si possible, puis construisez un tableau de bord par système.
  4. Organiser le run. Désignez qui reçoit chaque alerte, écrivez la procédure à suivre, testez l’arrêt d’urgence et tenez une revue mensuelle de la qualité avec le métier.

L’observabilité n’est pas tant un projet qu’un rituel d’exploitation, proche de celui de la gestion des incidents.

Les questions à nos experts Data IA sur l’observabilité IA

Qu’est-ce que l’observabilité IA ?

C’est la capacité à savoir et à tout moment, ce que fait un système d’IA en production, pourquoi il le fait et s’il le fait convenablement Elle suit la qualité des réponses, les hallucinations, la dérive, les coûts et la sécurité.

Quelle différence entre monitoring et observabilité IA ?

Le monitoring vérifie que le service fonctionne : Disponibilité, temps de réponse, erreurs. L’observabilité IA vérifie qu’il répond correctement et permet de comprendre pourquoi une réponse est fausse.

Comment détecter une hallucination en production ?

En utilisant plusieurs moyens de contrôle comme la vérification automatique que la réponse s’appuie sur les sources, la notation par un second modèle, la relecture d’un échantillon par un expert métier et l’analyse des signalements des utilisateurs.

Qu’est-ce que le LLMOps ?

Le LLMOps regroupe les pratiques d’exploitation des modèles de langage en production : Déploiement, versions, évaluation, observabilité et maîtrise des coûts. C’est l’équivalent du MLOps pour l’IA générative. Nous le détaillons pour les assistants RAG dans Opérer un RAG en production.

Faut-il un outil dédié à l’observabilité IA ?

Pas forcément pour démarrer. Votre outil d’observabilité actuel ou votre plateforme cloud couvrent souvent les besoins de base. Un outil spécialisé devient utile quand vous gérez plusieurs systèmes critiques et des jeux de tests importants.

L’AI Act impose-t-il une surveillance des systèmes d’IA ?

Oui, pour les systèmes à haut risque. Le fournisseur doit organiser une surveillance après commercialisation (article 72) et le déployeur doit surveiller le fonctionnement du système et conserver ses journaux au moins six mois (article 26), à partir du 2 décembre 2027.

Mesurer pour garder la confiance

Vos utilisateurs feront confiance à vos IA tant qu’elles répondent juste. L’observabilité est ce qui vous permet de le prouver, à eux comme à vos auditeurs. Elle transforme une IA qui fonctionne en IA qu’on peut exploiter.

Pour aller plus loin