2. Périmètre et typologie des systèmes d'IA

L’observabilité de l’IA couvre quatre types de systèmes qui se recouvrent. Chacun a ses propres exigences d’instrumentation et ses modes de défaillance caractéristiques. La même pile d’observabilité doit prendre en charge les quatre, car les applications réelles les combinent librement. Un agent en production effectue typiquement de la recherche documentaire et invoque des outils MCP : une seule requête sollicite trois des quatre types.

Cette typologie en quatre types est la référence pour tous les contenus du site sur l’observabilité de l’IA générative : les labs, l’article de mise en production et la méthode GenAI s’y rattachent. Les systèmes de ML classique et de vision sortent de ce périmètre : voir Au-delà du LLM : GPU et qualité des modèles.

Figure 3. Les quatre types de systèmes. Les modes de défaillance sont donnés à titre d’illustration et ne sont pas exhaustifs.

2.1 Systèmes LLM seuls

Un appel unique à un modèle de langage, sans recherche documentaire ni outil. C’est le cas le plus simple et souvent le premier mis en production.

Ce qu’il faut capturer

• Le prompt, avec le prompt système et le prompt utilisateur dans des champs séparés.
• La réponse, avec finish_reason (stop, length, content_filter, tool_call, error dans le vocabulaire des conventions OpenTelemetry).
• La consommation de jetons, en entrée et en sortie, en distinguant les jetons mis en cache lorsque le fournisseur les expose.
• La latence, de bout en bout et le délai jusqu’au premier jeton en cas de diffusion en flux (streaming).
• L’identité du modèle, y compris la version réellement servie (souvent différente du nom demandé).
• Les paramètres d’échantillonnage : température, top-p, top-k, graine (seed) si elle est fixée.

Défaillances caractéristiques

• Entités, dates ou citations hallucinées.
• Violations de format : du JSON était attendu, de la prose est arrivée.
• Injection de prompt via le contenu utilisateur.
• Dérapage des coûts quand le flux n’est pas plafonné et que la sortie dépasse les attentes.
• Pannes côté fournisseur et changements de modèle silencieux.

2.2 Chaînes RAG

La génération augmentée par recherche (retrieval-augmented generation, RAG) enchaîne un moteur de recherche (base vectorielle, BM25 ou hybride) et un modèle de langage. L’observabilité doit en plus capturer l’étape de recherche et le lien entre le contexte récupéré et la réponse générée. Le moteur de recherche introduit un second axe de défaillance : le modèle peut être parfait et produire malgré tout une mauvaise réponse parce que les mauvais documents ont été récupérés.

Ce qu’il faut capturer en plus du cas LLM seul

• La requête de recherche, qui est souvent une reformulation de la requête utilisateur.
• Les fragments (chunks) récupérés, avec leurs identifiants, leurs documents sources et leurs scores de similarité.
• La coupure top-k et les filtres appliqués (date, source, locataire).
• L’étape de reclassement (reranking) : identité du modèle, fragments en entrée, ordre en sortie.
• Les identifiants des fragments présents dans le prompt final, afin de relier chaque fragment à la réponse qui l’a utilisé.

Dimensions de qualité

• Précision du contexte (context precision) : part des fragments récupérés qui sont pertinents pour la requête.
• Rappel du contexte (context recall) : part des fragments pertinents qui ont été récupérés.
• Fidélité : la réponse est-elle étayée par le contexte récupéré, indépendamment de la justesse de ce contexte ?
• Pertinence de la réponse (answer relevancy) : la réponse traite-t-elle la question posée ?

Défaillances caractéristiques

• Rappel faible : le document pertinent n’a jamais été récupéré. Le modèle invente une réponse plausible.
• Top-k non pertinent : le score de similarité était élevé, mais les fragments ne répondent pas réellement à la requête.
• Contradiction : la réponse contredit le contexte récupéré (défaut de fidélité).
• Fragments périmés : l’index n’a pas été mis à jour depuis un changement pertinent.
• Fragments dupliqués : le même contenu apparaît plusieurs fois et biaise la réponse.

2.3 Systèmes agentiques

Un agent itère sur une boucle planifier, agir, observer. L’observabilité doit capturer la structure de la boucle et le raisonnement à chaque étape. Les agents sont le type de système le plus difficile à observer, car leurs modes de défaillance incluent des comportements non bornés : boucles, explosion des coûts, arrêt prématuré.

Ce qu’il faut capturer en plus du cas LLM seul

• Le raisonnement du planificateur à chaque étape, lorsque le modèle l’expose. Pour les modèles de raisonnement, la chaîne de pensée est elle-même un attribut de span.
• Les appels d’outils avec leur nom, leurs arguments et la charge utile de la réponse.
• Le nombre d’itérations et la raison de la fin de boucle (succès, budget, nombre maximal d’itérations, erreur).
• Le coût et la latence par étape, avec les cumuls sur l’ensemble de la trace.
• La détection d’appels d’outils répétés avec des arguments identiques, qui signale généralement une boucle.

Défaillances caractéristiques

• Boucles infinies ou quasi infinies, bornées seulement par le nombre maximal d’itérations ou le budget.
• Mauvais choix d’outil lorsque plusieurs outils ont des descriptions qui se recouvrent.
• Arguments d’outil mal formés (types erronés, champs obligatoires manquants, valeurs d’énumération inventées).
• Arrêt prématuré, quand l’agent répond sans avoir terminé la tâche.
• Explosion des coûts lorsque le contexte croît linéairement avec les itérations.

2.4 MCP et systèmes à outils

Le Model Context Protocol (MCP) normalise la façon dont les modèles de langage invoquent des outils, quel que soit le fournisseur. Lorsque des serveurs MCP font partie du système, l’observabilité doit capturer le niveau protocolaire, pas seulement l’appel de fonction. Le serveur MCP peut devenir un goulet d’étranglement partagé entre plusieurs agents et applications.

Ce qu’il faut capturer

• L’identité et la version du serveur MCP.
• Le nom de l’outil, ses arguments et la charge utile de la réponse.
• La latence et le taux d’erreur par outil et par serveur.
• La portée d’authentification utilisée pour chaque appel (le jeton ou l’identité propagés).
• Les événements de découverte d’outils : le moment où l’agent a demandé pour la première fois la liste des outils disponibles.
• La sélection d’outils entre serveurs lorsque plusieurs serveurs MCP sont connectés.

Défaillances caractéristiques

• Indisponibilité d’outil : le serveur MCP est arrêté ou lent.
• Dérive de schéma entre serveur et client lorsque le serveur publie une nouvelle signature d’outil.
• Élévation de portée lorsqu’un agent utilise un outil qui exige plus de droits que n’en possède l’utilisateur.
• Outils lents qui bloquent la boucle de l’agent : un seul outil avec un délai d’expiration de 30 secondes peut dominer le coût de la trace.
• Empoisonnement d’outil (tool poisoning) : le serveur MCP renvoie une sortie forgée pour manipuler l’agent.

2.5 La forme de la trace dépend du type de système

La même bibliothèque de spans produit des arbres de traces très différents selon le type de système. La figure 4 montre une trace réaliste d’agent RAG qui combine les quatre types : un span racine, une boucle d’agent, deux appels LLM, deux étapes de recherche, un appel d’outil MCP et trois spans d’évaluation rattachés après la génération.

Figure 4. Arbre de trace d’une requête d’agent RAG. La même trace contient les quatre types de systèmes : appels LLM, recherche documentaire, boucle d’agent et outil MCP. Les évaluations s’y rattachent comme spans enfants.

Trois enseignements à retenir de cette forme :

• Les évaluations vivent dans la même trace que la requête qu’elles évaluent. Ce ne sont pas des journaux séparés.
• Les retours asynchrones (le pouce baissé de l’utilisateur, par exemple) sont rattachés hors bande, mais indexés par identifiant de trace.
• La latence par étape se lit sur la largeur des barres. La barre la plus large représente le coût dominant : optimisez-la en premier.

Suite : 3. La feuille de route de maturité.

Révisé le 4 octobre 2026 : typologie en quatre types présentée comme la référence du site, périmètre (ML classique et vision exclus) rappelé.

Marquer comme lue