Checklist de mise en œuvre de l’observabilité de l’IA : 20 étapes de production

Checklist de mise en œuvre de l’observabilité de l’IA : 20 étapes de production

Une checklist de mise en œuvre de l’observabilité de l’IA devrait répondre à une question plus difficile que « l’API est-elle en ligne ? ». Une fonctionnalité d’IA en production peut renvoyer HTTP 200 tout en fournissant une mauvaise réponse, en utilisant un contexte de récupération obsolète, en appelant le mauvais outil, en passant par un repli coûteux après plusieurs tentatives, en exposant des données sensibles de prompt dans les journaux, ou en prenant trop de temps pour être utile.

L’objectif pratique est de relier chaque résultat visible par l’utilisateur aux tentatives du modèle, aux étapes de récupération, aux appels d’outils, aux décisions de politique, à la latence, à l’utilisation des jetons et au coût qui l’ont produit. Cela nécessite une télémétrie applicative classique ainsi que des signaux de contexte et d’évaluation spécifiques à l’IA.

Ce guide fournit un plan de mise en œuvre par phases pour les applications LLM, les agents, les systèmes de génération augmentée par récupération et les passerelles multi-modèles. Il est neutre vis-à-vis des fournisseurs et utilise autant que possible les concepts d’OpenTelemetry. Il comprend également une carte signal-décision, une matrice de tests d’acceptation, un plan de déploiement sur sept jours, un contrat de télémétrie, un modèle d’instrumentation, un runbook d’alertes et un tableau de bord comparatif des fournisseurs afin qu’une équipe puisse passer des exigences à un lancement opérationnel.

L’observabilité de l’IA en une phrase

L’observabilité de l’IA est la capacité d’expliquer le comportement, la qualité, la fiabilité, la sécurité et le coût d’un flux de travail d’IA à partir d’un ensemble corrélé de traces, de métriques, de journaux, d’évaluations et de შედეგats utilisateurs.

La surveillance vous indique qu’un seuil a changé. L’observabilité vous aide à déterminer pourquoi il a changé et quelles requêtes, quels modèles, prompts, résultats de récupération, outils, locataires ou versions étaient impliqués.

Utilisez la checklist de mise en œuvre de l’observabilité de l’IA de ce guide comme critère de validation avant mise en production, et non comme un exercice de documentation ponctuel. Réexécutez-la chaque fois que vous modifiez un modèle, un prompt, un index de récupération, un schéma d’outil, une politique de routage ou un évaluateur.

Pour une application d’IA, une requête peut contenir plusieurs tentatives distinctes :

action de l’utilisateur
  └─ flux de travail de l’application
      ├─ requête de récupération
      ├─ tentative de modèle 1
      ├─ appel d’outil
      ├─ tentative de modèle 2
      └─ validation et résultat visible par l’utilisateur

Si ces étapes ne peuvent pas être reliées sous une même trace ou une même identité de requête, le débogage devient une affaire de conjectures.

Le modèle de données minimal pour l’observabilité de l’IA

Le modèle de données est la base de la checklist de mise en œuvre de l’observabilité de l’IA, car chaque tableau de bord, alerte, évaluation et requête d’incident dépend de champs de corrélation cohérents.

Commencez avec une trace au niveau du flux de travail et des spans enfants pour chaque opération significative. OpenTelemetry définit les traces, les métriques, les journaux et le baggage comme signaux fondamentaux. Ses conventions sémantiques pour l’IA générative fournissent un vocabulaire en développement pour les opérations des modèles et des agents et, au 4 août 2026, sont maintenues dans le dépôt dédié des conventions sémantiques OpenTelemetry. Comme ces conventions peuvent évoluer, figez la version que vous implémentez et conservez une petite couche de compatibilité interne plutôt que d’éparpiller des noms de champs propres à un fournisseur dans tout votre code.

Au minimum, capturez ces groupes de champs.

Évitez de traiter le prompt brut et la réponse comme des champs obligatoires. Dans de nombreux systèmes, ils doivent être désactivés par défaut ou stockés uniquement dans un jeu de données d’évaluation contrôlé séparément.

Mapper chaque signal à une décision opérationnelle

Plus de télémétrie n’est pas automatiquement mieux. Avant d’ajouter un attribut, une métrique ou un tableau de bord, nommez la décision qu’il prend en charge et la personne qui en est responsable.

Ce tableau évite le mode de défaillance courant où un tableau de bord contient des dizaines de graphiques, mais où personne ne sait quelle action un changement devrait déclencher.

A Practical Trace Shape

Utilisez une seule trace pour le flux de travail visible par l’utilisateur, et non une trace distincte et sans lien pour chaque appel à un fournisseur. La racine doit décrire la tâche du client, tandis que les spans enfants décrivent les opérations qui ont contribué au résultat.

workflow: answer_support_question
  attributes: tenant_class, release, accepted_outcome, final_status
  ├─ retrieval.search
  │    attributes: index_version, top_k, authorization_result
  ├─ gen_ai.attempt
  │    attributes: provider, requested_model, resolved_model, attempt=1
  ├─ tool.lookup_order
  │    attributes: tool_schema_version, idempotency_key, result
  ├─ gen_ai.attempt
  │    attributes: provider, resolved_model, attempt=2, fallback_reason
  └─ evaluation.validate_answer
       attributes: evaluator_version, pass, score_band

Les conventions sémantiques pour l’IA générative d’OpenTelemetry évoluent encore. Traitez-les comme un vocabulaire partagé, mais figez la version de la convention, consignez toutes les extensions locales et testez les mises à niveau en préproduction. Conservez les résultats métier tels que accepted_outcome dans votre propre espace de noms applicatif stable afin qu’un changement de convention sémantique ne casse pas les rapports produit.

Phase 1: Définir les résultats avant d’ajouter des tableaux de bord

1. Nommez le workflow et le résultat accepté

Ne commencez pas par des graphiques de tokens à l’échelle du fournisseur. Commencez par une tâche client telle que :

• réponse de support acceptée sans escalade ;
• le correctif de code passe les tests ;
• l’extraction correspond au schéma requis ;
• l’agent exécute l’action demandée sans reprise manuelle ;
• le média généré passe la porte de revue du produit.

Créez un nom workflow lisible par machine et un accepted_outcome ou un résultat équivalent. Cela devient le dénominateur des métriques de qualité, de coût et de fiabilité.

2. Définissez la taxonomie des défaillances

Séparez au moins ces classes :

• défaillance de transport : expiration de délai, erreur de connexion ou 5xx en amont ;
• défaillance de capacité : limite de débit, quota, saturation de file d’attente ou limite de contexte ;
• défaillance de contrat : JSON invalide, champ manquant, schéma d’outil non pris en charge ou flux interrompu ;
• défaillance de qualité : la réponse est hors sujet, incorrecte, incomplète ou non étayée ;
• défaillance de sécurité : violation de politique, réussite d’une injection de prompt ou exécution d’outil non sûre ;
• défaillance métier : sortie techniquement valide que l’utilisateur rejette ou abandonne.

Une simple dimension error=true ne suffit pas. Elle masque le fait que vous ayez besoin d’un travail d’infrastructure, d’un changement de prompt, d’un changement de modèle ou d’un changement produit.

3. Choisissez les indicateurs initiaux de niveau de service

Commencez avec un petit ensemble qui reflète l’expérience utilisateur :

workflow availability = accepted workflow completions / eligible workflow starts

quality pass rate = evaluator-passing completions / evaluated completions

p95 end-to-end latency = p95(workflow completed - workflow started)

cost per accepted outcome = total workflow cost / accepted outcomes

Considérez la disponibilité du fournisseur comme une métrique de diagnostic, et non comme le SLI du produit. Un fournisseur peut être en bonne santé alors que votre workflow échoue parce que la récupération, les outils, la validation ou le routage sont défaillants.

Phase 2 : Instrumentez le chemin de requête complet

4. Créez un span racine par workflow visible pour l’utilisateur

Générez la trace racine à la frontière de l’application, avant le démarrage de la récupération ou du routage du modèle. Propagez ce contexte à travers les files d’attente, les workers, les passerelles, les services d’outils et les callbacks.

Utilisez des spans enfants pour :

• la récupération et le reranking ;
• chaque tentative de modèle ;
• chaque appel d’outil ;
• les vérifications de guardrail ou de politique ;
• l’analyse et la validation de la sortie ;
• la sélection du fallback ;
• la persistance et la livraison en aval.

5. Enregistrez la route demandée et la route résolue

Le modèle nommé par le client n’est pas toujours le modèle qui a servi la requête. Enregistrez les deux :

{
  "ai.requested_model": "support-balanced",
  "ai.resolved_provider": "provider-b",
  "ai.resolved_model": "model-version-2026-07",
  "ai.route_reason": "primary_rate_limited",
  "ai.attempt": 2
}

C’est essentiel pour les systèmes multi-fournisseurs. Cela rend aussi une stratégie de fallback de modèle auditables au lieu d’être invisibles.

6. Mesurez le streaming séparément

La latence totale seule ne décrit pas une expérience de streaming. Capturez :

• la durée de file d’attente ;
• la latence de connexion et du fournisseur ;
• le temps jusqu’au premier token ou au premier événement utile ;
• la durée de génération ;
• le temps de complétion de bout en bout ;
• le temps d’annulation du client.

Une requête peut avoir une latence totale acceptable mais un mauvais temps jusqu’au premier token. Elle peut aussi produire rapidement le premier token puis se bloquer.

7. Faites des retries et des fallbacks des tentatives de premier plan

Ne remplacez jamais la première tentative échouée par le succès final. Un span de workflow doit contenir ou lier chaque tentative facturable, y compris :

• le numéro de retry ;
• le déclencheur ;
• la durée du backoff ;
• le fournisseur et le modèle ;
• les tokens et le coût ;
• l’état de la sortie partielle ;
• la disposition finale.

Cela empêche qu’une tempête de retries apparaisse comme un « succès à 100 % ».

Phase 3 : Ajoutez un contexte de qualité spécifique à l’IA

8. Versionnez les prompts, les outils, les politiques et les évaluateurs

Stockez des identifiants stables plutôt que seulement le contenu brut :

prompt_version
tool_schema_version
retrieval_index_version
policy_version
evaluator_version
route_policy_version

Ces dimensions vous permettent de comparer une version avant et après une modification. Sans versioning, une baisse de qualité devient difficile à attribuer.

9. Tracez la qualité de la récupération

Pour la génération augmentée par récupération, enregistrez :

• la version de la requête et les filtres ;
• la latence de récupération ;
• les IDs des documents ou des chunks ;
• la fraîcheur de la source ;
• le top-k et la version du reranker ;
• le taux de résultats vides ;
• la décision de contrôle d’accès ;
• le résultat de validation des citations ou de l’ancrage.

Ne placez pas les documents privés complets dans un stockage de traces à usage général. Stockez des références contrôlées ou des hachages, sauf si la politique de débogage autorise explicitement la capture du contenu.

10. Tracez les appels d’outils et les effets de bord

Chaque span d’outil doit inclure le nom de l’outil, la version du schéma, la décision d’autorisation, la latence, le résultat normalisé et s’il a produit un effet secondaire externe.

Pour les outils produisant des effets secondaires, enregistrez aussi une clé d’idempotence et l’état de réconciliation. Cela est important lorsqu’un appel de modèle expire après que l’outil s’est déjà terminé.

11. Join online and offline evaluations

Les signaux en ligne sont rapides mais bruités : pouce levé, abandon, régénération, correction, escalade ou achèvement de tâche. Les évaluations hors ligne sont plus lentes mais contrôlées : ensembles de test sélectionnés, correcteurs de barème, tests exécutables et revue humaine.

Reliez les deux aux mêmes identifiants de workflow et de version. Ne mélangez pas les scores de différentes versions d’évaluateur dans une seule courbe de tendance sans étiqueter le changement.

Phase 4: Control Privacy, Security, and Retention

12. Classify telemetry before collection

Définissez trois niveaux :

1. Métadonnées : route, timing, jetons, statut, versions et identifiants.
2. Signaux de contenu dérivés : longueur, langue, catégorie de sécurité, score d’évaluateur ou hachage.
3. Contenu brut : invites, réponses, texte récupéré, arguments d’outil et résultats d’outil.

Collectez largement les métadonnées. Collectez le contenu brut uniquement lorsque le cas d’usage, l’avis à l’utilisateur, le contrôle d’accès et la politique de conservation le permettent.

13. Redact at the collection boundary

La rédaction doit, dans la mesure du possible, avoir lieu avant l’exportation. Couvrez :

• les clés API, jetons bearer, cookies et en-têtes d’autorisation ;
• les adresses e-mail, numéros de téléphone, numéros de compte et identifiants gouvernementaux ;
• les secrets dans les arguments d’outil ou les documents récupérés ;
• les URL signées et les chaînes de connexion de base de données ;
• le contenu spécifique à un locataire interdit dans les magasins d’observabilité partagés.

Utilisez des allowlists pour les attributs exportés. Une denylist finira par omettre un nouveau champ contenant un secret. Appliquez la même discipline décrite dans ce guide de gestion des clés API pour l’IA.

14. Set retention and access by data class

Le contenu brut ne doit pas hériter de la même conservation que des métriques à faible risque. Définissez des stockages, un chiffrement, des rôles d’accès, des journaux d’audit et des processus de suppression distincts. Testez la suppression au lieu de supposer qu’un document de politique suffit.

Le NIST AI Risk Management Framework et son Generative AI Profile mettent l’accent sur la mesure continue, la documentation et la gestion des risques tout au long du cycle de vie du système. L’observabilité aide à fournir des preuves, mais une journalisation indiscriminée peut créer un nouveau risque de confidentialité et de sécurité.

15. Control high-cardinality dimensions

Ne transformez pas les identifiants utilisateur, les identifiants de trace, le texte des invites, les identifiants de documents ou les messages d’erreur bruts en libellés de métriques. Conservez les données à forte cardinalité dans les traces ou les journaux, puis dérivez des métriques bornées telles que le workflow, la famille de modèle, la classe d’erreur, l’environnement et la région.

Phase 5: Build Alerts That Point to Action

16. Alert on user-impacting symptoms

Déclenchez une alerte sur des symptômes tels que :

• un taux d’achèvement accepté inférieur à l’objectif ;
• une baisse du taux de réussite qualité au-delà de la limite de garde de la version ;
• une latence p95 ou un temps jusqu’au premier jeton consommant le budget d’erreur ;
• un coût par résultat accepté dépassant sa limite ;
• un effet secondaire dangereux ou une défaillance de politique ;
• un taux de repli dépassant sa plage normale.

Utilisez les erreurs du fournisseur, les pics de jetons et les manques de récupération comme alertes de diagnostic ou signaux de tableau de bord, sauf s’ils menacent directement l’objectif côté utilisateur.

17. Utiliser des fenêtres de burn-rate pour les alertes SLO

Un seuil statique peut être bruyant. L’alerte par burn-rate du budget d’erreur demande à quelle vitesse le service consomme le budget de panne autorisé. Les recommandations SRE de Google conseillent de combiner une fenêtre plus rapide avec une fenêtre de confirmation plus lente afin que les incidents graves déclenchent rapidement une alerte sans rendre chaque bref pic exploitable.

18. Ajouter des annotations de version et de route

Chaque tableau de bord doit afficher les versions du prompt, de l’application, du routage, du modèle et de l’évaluateur. Ajoutez des annotations de déploiement et comparez les cohortes canary et de contrôle. Sinon, l’équipe verra une courbe bouger sans voir ce qui a changé.

Phase 6 : Valider avant le déploiement complet

19. Exécuter des exercices d’échec

Testez au minimum :

• expiration du délai en amont ;
• limite de débit et épuisement du quota ;
• sortie structurée mal formée ;
• interruption partielle du streaming ;
• la récupération ne renvoie aucun contexte autorisé ;
• l’outil réussit mais la réponse est perdue ;
• le fallback modifie le comportement du modèle ;
• l’exporteur de télémétrie est indisponible ;
• la règle de masquage reçoit un champ inconnu.

Confirmez que le flux de travail échoue de manière sûre, que la trace reste cohérente et que l’alerte identifie le bon responsable.

20. Déployer en quatre étapes

1. Shadow : émettre la télémétrie sans modifier le routage ni le comportement utilisateur.
2. Canary : activer pour une petite tranche de trafic et comparer la surcharge, la cardinalité et la qualité des données.
3. Production protégée : associer des seuils de version et des règles de retour arrière.
4. Production complète : étendre après validation des contrôles de confidentialité, de fiabilité et de coûts.

OpenTelemetry prend en charge les schémas d’échantillonnage en tête et en fin de parcours. Conservez toutes les erreurs et les classes rares de défaillance lorsque c’est possible, puis échantillonnez le trafic de succès courant pour maîtriser les coûts. Les règles d’échantillonnage ne doivent pas supprimer les traces exactes nécessaires pour expliquer un incident.

Matrice de test d’acceptation en production

Les tests d’acceptation prouvent que la checklist de mise en œuvre de l’observabilité de l’IA fonctionne dans des scénarios d’échec, de confidentialité et de perte de télémétrie, et pas seulement sur les requêtes réussies.

Ne déclarez pas l’observabilité terminée simplement parce que des spans apparaissent dans un visualiseur de traces. Exécutez des tests contrôlés et conservez des preuves pour chaque jalon de validation.

Pour chaque test, consignez le propriétaire, la date du test, l’ID de trace, l’alerte attendue, l’alerte observée et le ticket de remédiation. Cela transforme l’observabilité en un contrôle de version reproductible, plutôt qu’en un projet d’instrumentation ponctuel.

Plan de mise en œuvre sur sept jours

Pour une équipe focalisée, la checklist de mise en œuvre de l’observabilité de l’IA peut être appliquée comme une séquence de sept jours qui laisse chaque journée avec des preuves examinables.

Cette séquence est volontairement étroite. Elle fournit une tranche verticale fiable avant que l’équipe n’élargisse la couverture.

1. Jour 1 — Contrat de résultat : choisissez un workflow à forte valeur, définissez les démarrages éligibles, les résultats acceptés, les classes d’échec et les formules SLI.
2. Jour 2 — Squelette de trace : créez le span racine du workflow et propagez le contexte à travers l’application, la file d’attente, la passerelle, la couche de récupération et les outils.
3. Jour 3 — Tentatives du modèle : capturez les routes demandées et résolues, les tentatives, la latence, la raison de fin, l’utilisation du fournisseur, les réessais et les solutions de repli.
4. Jour 4 — Qualité et coût : associez les résultats du validateur, les versions de l’évaluateur, les résultats utilisateur et le coût normalisé du workflow.
5. Jour 5 — Contrôles de confidentialité : classez les champs, mettez en œuvre l’export par liste d’autorisation, testez la rédaction, définissez la rétention et vérifiez les limites d’accès.
6. Jour 6 — SLO et tableaux de bord : construisez le tableau de bord minimal, ajoutez des annotations de version, définissez des alertes de burn rate et attribuez des responsables.
7. Jour 7 — Exercices d’échec : exécutez la matrice d’acceptation, corrigez les lacunes, lancez un canary et documentez les conditions de retour arrière.

À la fin du septième jour, l’objectif n’est pas une instrumentation universelle. L’objectif est un workflow de production dont le comportement, la qualité, la fiabilité, la sécurité et le coût peuvent être expliqués de bout en bout.

Tableau de bord minimal pour le lancement

Le tableau de bord est la vue opérationnelle de la liste de contrôle de mise en œuvre de l’observabilité de l’IA. Il doit d’abord exposer les résultats clients, puis les détails de l’infrastructure.

Gardez la première vue opérationnelle suffisamment réduite pour être utilisable pendant un incident :

• Ligne Résultat : démarrages éligibles, complétions acceptées, taux de réussite qualité, et abandon ou escalade.
• Ligne Fiabilité : erreurs normalisées, taux de repli, amplification des réessais et consommation du budget d’erreur.
• Ligne Latence : p50/p95/p99 de bout en bout, temps en file d’attente, temps jusqu’au premier jeton, latence de récupération et latence des outils.
• Ligne Économie : jetons d’entrée/de sortie/cachés, coût total du workflow et coût par résultat accepté.
• Ligne Changement : application, prompt, politique de routage, modèle, index de récupération, schéma d’outil et versions de l’évaluateur.
• Liens d’investigation : traces représentatives pour chaque classe d’échec, version, route et workflow affecté.

Le tableau de bord doit prendre en charge un parcours du symptôme à la trace. Si une alerte indique une baisse de qualité mais que l’équipe ne peut pas accéder aux traces des workflows affectés en quelques clics, la boucle d’investigation est incomplète.

Grille d’évaluation de la plateforme d’observabilité de l’IA

L’évaluation commerciale doit vérifier si une plateforme prend en charge votre modèle opérationnel, et non si elle possède la liste de fonctionnalités la plus longue. Évaluez les candidats par rapport au même workload pilote instrumenté.

Utilisez une note de 1 à 5 pour chaque critère, multipliez-la par le poids et exigez des preuves écrites issues du pilote. Une plateforme qui ne peut pas préserver votre contrat de télémétrie ou exporter vos données crée un verrouillage opérationnel, même si ses tableaux de bord sont soignés.

Contrat de télémétrie copiable

Le moyen le plus rapide de rendre opérationnelle une checklist de mise en œuvre de l’observabilité de l’IA consiste à la transformer en un contrat de télémétrie versionné. Le contrat définit ce que chaque workflow et chaque tentative du modèle doit émettre, quels champs sont facultatifs, quelles valeurs sont autorisées et quels champs sont interdits dans les index à fort volume.

L’exemple ci-dessous utilise un espace de noms interne. Mappez-le aux conventions OpenTelemetry GenAI épinglées dans un seul adaptateur plutôt que d’exposer le code applicatif aux changements de conventions.

telemetry_contract:
  version: "2026-08-04"
  workflow_span:
    required:
      - ai.workflow.name
      - ai.workflow.version
      - ai.request.id
      - deployment.environment
      - service.version
      - ai.outcome.status
      - ai.outcome.accepted
      - ai.latency.total_ms
    optional:
      - ai.tenant.tier
      - ai.experiment.id
      - ai.user.feedback
    prohibited:
      - end_user.email
      - end_user.name
      - raw.authorization_header

  model_attempt_span:
    required:
      - ai.attempt.number
      - ai.route.requested_model
      - ai.route.resolved_provider
      - ai.route.resolved_model
      - ai.result.status
      - ai.usage.input_tokens
      - ai.usage.output_tokens
      - ai.latency.first_token_ms
      - ai.latency.total_ms
    conditional:
      - ai.fallback.reason
      - ai.error.class
      - ai.error.provider_code
      - ai.usage.cached_input_tokens

  content_capture:
    default: "off"
    allowed_when:
      - approved_evaluation_dataset
      - explicit_debug_session
    controls:
      - redact_before_export
      - access_logged
      - retention_approved

Examinez ce contrat en code review comme un schéma d’API. Un nouveau fournisseur de modèle, un outil d’agent, une politique de repli ou un évaluateur ne doit pas être mis en production tant que ses champs de télémétrie ne correspondent pas au contrat et ne passent pas les mêmes tests d’acceptation.

Modèle d’instrumentation pour un workflow IA

Ne laissez pas chaque équipe inventer indépendamment les noms de spans et les attributs. Fournissez un petit wrapper qui crée le span racine du workflow, enregistre les tentatives enfants, capture les résultats normalisés et applique la redaction avant l’export.

Cet exemple Python est intentionnellement neutre vis-à-vis des fournisseurs. Les noms d’attributs internes doivent être traduits vers la version figée de votre convention sémantique OpenTelemetry dans le wrapper ou la couche du collecteur.

from opentelemetry import trace

tracer = trace.get_tracer("checkout-assistant")


def run_ai_workflow(request, router, evaluator):
    with tracer.start_as_current_span("ai.workflow.checkout_help") as workflow_span:
        workflow_span.set_attribute("ai.workflow.name", "checkout_help")
        workflow_span.set_attribute("ai.workflow.version", "2026-08-04")
        workflow_span.set_attribute("ai.request.id", request.request_id)

        result = None
        for attempt_number in range(1, 3):
            with tracer.start_as_current_span("ai.model.attempt") as attempt_span:
                route = router.resolve(request, attempt_number)
                attempt_span.set_attribute("ai.attempt.number", attempt_number)
                attempt_span.set_attribute("ai.route.requested_model", request.model)
                attempt_span.set_attribute("ai.route.resolved_provider", route.provider)
                attempt_span.set_attribute("ai.route.resolved_model", route.model)

                result = route.generate(request)
                attempt_span.set_attribute("ai.result.status", result.status)
                attempt_span.set_attribute("ai.usage.input_tokens", result.input_tokens)
                attempt_span.set_attribute("ai.usage.output_tokens", result.output_tokens)

                if result.status == "ok":
                    break

                attempt_span.set_attribute("ai.error.class", result.error_class)

        evaluation = evaluator.score(request, result)
        workflow_span.set_attribute("ai.outcome.status", result.status)
        workflow_span.set_attribute("ai.outcome.accepted", evaluation.accepted)
        workflow_span.set_attribute("ai.evaluator.version", evaluation.version)
        workflow_span.set_attribute("ai.quality.score", evaluation.score)
        return result

Le code de production doit également enregistrer la durée, le délai jusqu’au premier token, les raisons de repli, l’annulation, les erreurs de streaming et les exceptions. Le choix de conception important est la hiérarchie : un workflow client contient une ou plusieurs tentatives facturables, et le workflow enregistre le résultat final accepté.

Politique d’alerte et runbook de première réponse

Une checklist de mise en œuvre de l’observabilité de l’IA est incomplète si les tableaux de bord n’ont pas de règles de réponse. Chaque métrique de lancement a besoin d’un déclencheur, d’un responsable et d’une première requête de diagnostic.

La vue d’astreinte doit renvoyer directement d’une alerte vers les traces filtrées par workflow, version, modèle demandé, chemin résolu et classe d’erreur. Si les intervenants doivent reconstruire manuellement ces filtres pendant un incident, le système n’est pas prêt pour le lancement.

Responsabilités et passation de production

Attribuez la checklist à des rôles nommés avant le déploiement. Une responsabilité partagée sans décideur explicite produit généralement des tableaux de bord que tout le monde peut consulter et que personne ne maintient.

Planifiez une revue 30 jours après le lancement. Supprimez les champs inutilisés, faites remonter les requêtes de débogage réutilisées fréquemment dans des vues de tableau de bord, examinez la cardinalité et le coût de stockage, et mettez à jour le contrat lorsque le comportement du workflow change.

Checklist de mise en œuvre de l’observabilité de l’IA

Utilisez cette liste comme condition de lancement :

• [ ] Définir chaque workflow et le résultat client accepté.
• [ ] Définir les défaillances de transport, de capacité, de contrat, de qualité, de sécurité et métier.
• [ ] Sélectionner les SLIs de disponibilité, de qualité, de latence et de coût par résultat.
• [ ] Approuver un contrat de télémétrie versionné avec des champs obligatoires, facultatifs et interdits.
• [ ] Créer une trace racine par workflow visible par l’utilisateur.
• [ ] Propager le contexte à travers les files d’attente, les outils, la récupération et les passerelles.
• [ ] Enregistrer les routes fournisseur/modèle demandées et résolues.
• [ ] Créer un span distinct pour chaque tentative de nouvelle exécution et de repli.
• [ ] Capturer le temps d’attente en file, le temps jusqu’au premier token et la latence totale.
• [ ] Capturer l’utilisation des tokens indiquée par le fournisseur et le coût normalisé.
• [ ] Versionner les prompts, les outils, les index de récupération, les politiques, les routes et les évaluateurs.
• [ ] Enregistrer les références de récupération, la fraîcheur, l’autorisation et les résultats d’ancrage.
• [ ] Enregistrer l’autorisation de l’outil, l’idempotence, le résultat et l’état des effets de bord.
• [ ] Associer les retours utilisateur et les résultats d’évaluation hors ligne aux traces.
• [ ] Classer la télémétrie en métadonnées, signaux dérivés ou contenu brut.
• [ ] Masquer les secrets et les champs sensibles avant l’exportation.
• [ ] Appliquer des politiques distinctes de conservation et d’accès par classe de données.
• [ ] Éviter les valeurs à forte cardinalité dans les libellés des métriques.
• [ ] Déclencher des alertes sur les SLOs ayant un impact utilisateur et sur la consommation du budget d’erreur.
• [ ] Annoter les versions et comparer le canary au contrôle.
• [ ] Exécuter des exercices de défaillance, de confidentialité, d’échantillonnage et de panne de l’exportateur.
• [ ] Conserver les preuves des tests d’acceptation et les IDs de trace pour la condition de passage en production.
• [ ] Comparer les plateformes d’observabilité avec un scorecard pilote pondéré unique.
• [ ] Désigner des responsables comptables pour les résultats, le schéma, la confidentialité, les SLOs, la qualité et le coût.
• [ ] Lier chaque alerte nécessitant une action immédiate à une procédure de première réponse et à une requête de trace.

Erreurs courantes en observabilité de l’IA

Consigner des prompts sans politique de données

Les prompts bruts semblent utiles pendant le débogage, mais ils peuvent contenir des données client, des secrets, du matériel protégé par le droit d’auteur ou des informations réglementées. Commencez avec des métadonnées et n’activez la capture de contenu contrôlée que lorsqu’elle est justifiée.

Mesurer le coût par requête au lieu du coût par résultat

Une requête peu coûteuse qui échoue à la validation n’est pas bon marché. Les nouvelles tentatives, les repliements et la correction humaine font partie du coût du workflow. Le même principe s’applique au ROI du cache de prompts : optimisez la tâche acceptée, pas un taux de tokens isolé.

Considérer chaque appel au modèle comme indépendant

Les agents et les systèmes RAG sont des workflows. Si les spans du modèle, de la récupération et des outils ne sont pas corrélés, l’équipe ne peut pas reconstituer la causalité.

S’en remettre à un seul tableau de bord du fournisseur

Les tableaux de bord du fournisseur sont utiles pour l’utilisation en amont et les erreurs, mais ils ne voient pas le résultat complet de votre application, le système de récupération, l’exécution des outils, les retours utilisateur ni le chemin de repli multi-fournisseur.

Tout instrumenter avant de définir les décisions

La télémétrie a un coût opérationnel. Chaque champ doit soutenir une décision de débogage, d’alerte, d’évaluation, de gouvernance ou d’optimisation. Supprimez les champs que personne n’utilise.

Où s’insère une passerelle d’IA

Une passerelle LLM peut constituer une frontière utile pour la corrélation et les politiques, car plusieurs applications et fournisseurs passent par un seul point de contrôle. Elle peut normaliser les métadonnées de route, de tentative, d’utilisation, de latence et d’erreur avant d’exporter la télémétrie vers votre pile d’observabilité.

La passerelle n’est pas la solution complète. Le code applicatif reste responsable des résultats du workflow, du contexte de récupération, de la sémantique des outils, des retours utilisateurs et de la conversion commerciale. La conception la plus robuste relie la télémétrie de la passerelle à ces signaux au niveau de l’application.

Flatkey fournit une couche d’accès unique compatible OpenAI pour plusieurs modèles d’IA. Si votre équipe consolide les intégrations de fournisseurs, découvrez Flatkey et utilisez cette checklist pour définir le contrat de télémétrie autour de votre application et de votre couche de routage.

Questions fréquemment posées

Que dois-je implémenter en premier pour l’observabilité de l’IA ?

Commencez la checklist de mise en œuvre de l’observabilité de l’IA avec une trace racine par workflow client, des spans enfants pour les tentatives de modèle, les champs de modèle demandés et résolus, la latence, l’utilisation, les erreurs normalisées et un signal de résultat accepté. Ajoutez plus tard la capture brute des prompts, si votre politique de confidentialité le permet.

OpenTelemetry suffit-il pour l’observabilité des LLM ?

OpenTelemetry fournit la base neutre en termes de transport pour les traces, les métriques et les logs, ainsi que des conventions sémantiques pour l’IA générative en évolution. Vous devez encore définir les workflows, les évaluations, les contrôles de confidentialité, les SLO, les tableaux de bord et les processus d’incident.

Faut-il stocker les prompts et les réponses dans les traces ?

Pas par défaut. Utilisez d’abord les métadonnées, les versions, les hachages et les signaux de qualité dérivés. Ne stockez le contenu brut que dans des systèmes contrôlés avec une finalité explicite, une politique d’accès, une durée de rétention et un processus de suppression.

Quelles métriques d’observabilité de l’IA sont les plus importantes ?

Commencez par le taux d’achèvement accepté, le taux de réussite de la qualité, la latence de bout en bout p95, le temps jusqu’au premier jeton pour le streaming, le taux de repli et le coût par résultat accepté. Ajoutez ensuite les métriques spécifiques au workflow une fois celles-ci fiables.

Comment surveiller plusieurs fournisseurs d’IA ?

Utilisez un schéma de télémétrie stable commun à tous les fournisseurs. Enregistrez, pour chaque tentative, à la fois la route demandée et le fournisseur/modèle résolu, normalisez les erreurs sans supprimer le code brut du fournisseur, et reliez toutes les tentatives sous la même trace de workflow.

Références faisant autorité

• OpenTelemetry : Signaux
• OpenTelemetry : dépôt des conventions sémantiques pour l’IA générative
• OpenTelemetry : Échantillonnage
• OpenTelemetry Collector
• Google SRE Workbook : Alerter sur les SLO
• NIST AI RMF : profil de l’IA générative
• NIST AI Risk Management Framework