OpenTelemetry pour l'IA : quoi tracer sans tout enregistrer

OpenTelemetry peut relier un parcours IA entre interface, service, modèle, base de données et outil externe. Son utilité n'est pas de tout enregistrer : elle consiste à répondre rapidement à une question opérationnelle, comme « pourquoi cette action a-t-elle échoué ? », « où la latence apparaît-elle ? » ou « quelle version dégrade le résultat ? ».

Commencez par un workflow critique et un plan de décision. Instrumenter toute l'architecture avant de savoir ce que vous cherchez produit surtout du coût, du bruit et des risques de confidentialité.

Ce qu'OpenTelemetry apporte

OpenTelemetry est un cadre ouvert pour produire et transporter des signaux d'observabilité, notamment traces, métriques et logs. Une trace représente le parcours d'une opération ; ses spans décrivent les étapes et leurs relations.

Dans un workflow IA, une trace peut relier :

• la demande utilisateur ;
• la récupération de contexte ;
• l'appel au modèle ;
• l'utilisation d'un outil ;
• une validation humaine ;
• l'écriture finale ;
• le résultat métier observé plus tard.

OpenTelemetry ne fournit pas à lui seul une évaluation de qualité, une politique de sécurité ou une interface de correction. Il donne une structure de corrélation sur laquelle ces capacités peuvent s'appuyer.

Commencer par quatre questions

1. Quelle décision prendra-t-on à partir du signal ?
2. Quel parcours mérite une corrélation de bout en bout ?
3. Quelles données sont nécessaires pour diagnostiquer sans exposer le contenu ?
4. Qui peut consulter le signal et combien de temps ?

Si aucune décision n'est liée à un attribut, ne le collectez pas par défaut.

Le schéma minimal d'une trace IA

Identité technique de l'opération

Un identifiant de trace, un identifiant de span et, si nécessaire, un identifiant pseudonyme du parcours. Évitez l'adresse email ou le nom comme clé de corrélation.

Version

Version de l'application, du workflow, du prompt ou de la configuration, fournisseur et modèle. La version permet de comparer avant/après et de revenir en arrière.

Performance

Latence totale, latence par étape, temps d'attente externe, nombre de tentatives et taille approximative des entrées/sorties.

Coût

Tokens ou unités facturées, coût estimé et nombre d'appels. Mesurez ensuite le coût par résultat métier, pas seulement par requête.

État

Succès technique, erreur, timeout, refus, fallback ou validation humaine. Un appel modèle réussi peut néanmoins produire un résultat métier invalide : conservez la distinction.

Qualité reliée

Identifiant d'évaluation, score selon un critère défini, correction humaine et résultat observé. La trace transporte le lien ; elle ne remplace pas le protocole d'évaluation.

Faut-il enregistrer les prompts et les réponses ?

Pas par défaut. Le contenu peut contenir des données personnelles, secrets, données de santé, propriété intellectuelle ou instructions malveillantes. Il augmente aussi le coût et la surface d'accès.

Préférez d'abord :

• longueur ou catégorie de l'entrée ;
• hash ou identifiant d'un gabarit ;
• version du prompt ;
• type de document ;
• présence d'une validation ;
• code d'erreur ;
• résultat agrégé.

Si le contenu est indispensable pour un échantillon de qualité, utilisez un environnement restreint, une finalité documentée, une durée courte, un accès contrôlé et une politique de masquage. Vérifiez que le contenu reste désactivé ailleurs.

Exemple : assistant de dossier

Un utilisateur demande un brouillon à partir de trois documents.

La trace montre : récupération des documents, filtrage des droits, génération, vérification de citations, validation humaine et export. Un timeout survient lors de la vérification des citations. Le système repasse en mode brouillon non validé et empêche l'export automatique.

La trace utile ne contient pas nécessairement les documents. Elle conserve les identifiants autorisés, versions, durées, état du contrôle et décision de fallback.

Relier technique et métier

Une observabilité purement technique répond à « le service a-t-il fonctionné ? ». Le produit a aussi besoin de savoir « l'utilisateur a-t-il obtenu le résultat ? ».

Reliez la trace à un événement métier sans copier le contenu : proposition validée, action exécutée, dossier résolu ou correction demandée. La corrélation peut être différée et pseudonymisée.

Plan pilote en deux heures

1. choisir un workflow avec un échec coûteux ;
2. dessiner cinq à huit étapes ;
3. définir un identifiant de corrélation ;
4. ajouter version, latence, état et coût ;
5. simuler une erreur et un fallback ;
6. vérifier qu'aucune donnée sensible inattendue n'apparaît ;
7. écrire la décision que le signal permettra de prendre.

Erreurs fréquentes

• tracer tous les appels mais aucun résultat ;
• enregistrer le prompt complet « pour plus tard » ;
• mélanger erreur technique et mauvaise qualité ;
• ne pas versionner prompt et configuration ;
• conserver sans limite ;
• donner un accès large aux traces ;
• oublier de tester l'instrumentation elle-même ;
• adopter des attributs expérimentaux comme contrat immuable.

Les conventions sémantiques GenAI d'OpenTelemetry évoluent. Épinglez la version utilisée et prévoyez une couche de traduction plutôt que de disperser des noms d'attributs dans tout le code.

FAQ

OpenTelemetry remplace-t-il Sentry ?

Non nécessairement. Sentry se concentre sur l'expérience de diagnostic d'erreurs applicatives ; OpenTelemetry standardise la production et la corrélation de signaux. Ils peuvent être complémentaires.

OpenTelemetry suffit-il pour évaluer un modèle ?

Non. Il relie la trace aux évaluations. Il faut encore définir les cas, critères, seuils et revues humaines.

Faut-il l'utiliser dès le prototype ?

Seulement si un workflow critique traverse déjà plusieurs composants ou si la confiance l'exige. Un journal structuré minimal peut suffire au tout début.

Prochaine étape

Utilisez la checklist OpenTelemetry pour workflow IA sur un seul parcours. Si vous ne pouvez pas nommer la décision associée à un signal, retirez-le. Pour une revue de schéma, écrivez à contact@yumea.fr avec l'objet « OTEL ».

Sources

• OpenTelemetry, Semantic conventions for generative AI systems.
• OpenTelemetry, documentation sur traces, métriques et logs.
• CNIL, recommandations de sécurité pour le développement des systèmes d'IA.