Nous utilisons déjà un backend de tracing. Le problème n'est-il pas résolu ?

Un backend vous fournit la capture et le stockage. Ce pattern concerne les trois aspects qu'un backend ne décide pas pour vous : si un identifiant unique relie l'ensemble de l'exécution, si la fidélité est suffisante pour la reconstruire sans les systèmes sources, et si ce que vous avez enregistré peut être conservé en toute sécurité. Des équipes disposant d'excellents outils échouent régulièrement au test de reconstruction.

Une capture complète n'entre-t-elle pas en conflit avec la minimisation des données ?

Ce serait le cas si la capture signifiait tout conserver à l'état brut. Le contrôle énonce délibérément les deux aspects — assez pour reconstruire, rien qui ne transforme le journal en violation de données — et le moyen de concilier les deux est le masquage au niveau des champs lors de la capture, associé à une rétention liée à l'obligation qui justifie l'enregistrement. Ce que vous ne pouvez pas faire, c'est éluder cette tension en conservant tout et en qualifiant cela de conformité.

Quel niveau de fidélité est suffisant ?

Exactement assez pour réussir le test de reconstruction sur une exécution choisie au hasard, et pas plus. Ce seuil peut être découvert en essayant, c'est pourquoi le test doit faire partie de la routine plutôt que d'un audit. Tout ce qui est capturé au-delà représente un coût et un risque juridique sans répondre à aucune question.

FiabilitéMis à jour 2026-08-25 · Version 1.0

Trace d'exécution corrélée

Un identifiant unique relie toute une exécution d'agent — entrées, modèle et version, chaque appel d'outil avec ses arguments et son résultat, l'action finale — dans un enregistrement que vous pouvez rejouer des mois plus tard. Le plus difficile n'est pas la capture. C'est d'être assez complet pour reconstruire l'exécution et assez mesuré pour que le stockage des traces ne devienne pas une seconde copie des données qu'il décrit.

Preuve: Observation du secteurConfiance: MoyenSource: Observation du secteurSource: Publication scientifique

Lisible par machine: JSON

Définition

Une trace d'exécution corrélée est un enregistrement immuable, doté d'un identifiant unique, de tout ce qu'une exécution d'agent a décidé et fait, capturé avec une fidélité qui permet de reconstruire l'exécution de bout en bout a posteriori sans accès aux systèmes qui l'ont produite, et expurgé afin que la trace ne devienne pas une cible plus facile que la source. Il s'agit d'un enregistrement des décisions de l'agent, et non d'un journal de requêtes.

Problème

Les agents sont non déterministes et multi-étapes, de sorte que « ce qui s'est passé » ne peut être déduit du résultat. La plupart des équipes effectuent des journaux d'activité, mais ne peuvent toujours pas expliquer pourquoi une exécution spécifique a agi ainsi : les étapes se trouvent dans des systèmes différents sans identifiant partagé, le prompt a été enregistré sous forme de référence de modèle qui a changé depuis, ou la version du modèle n'a jamais été capturée, de sorte que personne ne peut dire si c'est le comportement ou le modèle qui a dérivé.

Quand l'utiliser

Tout agent dont les actions ont des conséquences sur lesquelles on s'interrogera plus tard : un processus réglementé où la trace constitue la piste d'audit et où la traçabilité est une obligation plutôt qu'une préférence, un incident nécessitant une analyse de cause racine, un client contestant un résultat, ou une boucle d'évaluation qui a besoin de défaillances réelles pour apprendre.

Solution

Générez un identifiant d'exécution unique au point d'entrée et propagez-le à travers chaque étape, service et tentative. La corrélation fait toute la valeur : des enregistrements non liés d'une même exécution ne sont que trois journaux, pas une trace.

Enregistrez le prompt généré, pas une référence à celui-ci. Un ID de template résout ce que le template contient aujourd'hui, ce qui n'est pas ce que le modèle a vu.

Capturez le modèle et sa version lors de chaque appel. Sans cela, un changement de comportement et un changement de modèle sont impossibles à distinguer après coup.

Enregistrez les appels d'outils sous forme d'arguments accompagnés de leur résultat, y compris les échecs et les tentatives. Une trace qui ne montre que les appels réussis décrit une exécution qui n'a pas eu lieu.

Masquez lors de la capture, pas à la lecture. Appliquez des règles au niveau des champs pour supprimer ou hacher les secrets et les données personnelles avant l'écriture de l'enregistrement, car un masquage appliqué au moment de la requête laisse toujours la valeur brute dans le stockage.

Échantillonnez sur la fin (tail-based), pas au début (head-based). Décidez de ce qu'il faut conserver après la fin de l'exécution, afin que les erreurs, les escalades et les anomalies soient conservées et que les succès de routine soient ceux qui sont réduits.

Rendez le stockage accessible uniquement en écriture à la suite (append-only) et attribuez-lui les contrôles d'accès du système le plus sensible qu'il décrit, et non ceux fournis par défaut avec un backend de journalisation.

Composants

Un identifiant d'exécution généré à l'entrée et propagé à travers chaque étape, service, tentative et continuation asynchrone.Un span par étape avec un schéma stable : entrées, modèle et version, nom de l'outil, arguments, résultat, latence, utilisation des tokens.Un masquage au niveau des champs appliqué lors de la capture, avec une liste explicite de ce qui est supprimé, de ce qui est haché et de ce qui est conservé intact.Un échantillonnage tail-based qui décide après coup, de sorte que les exécutions anormales survivent et que les exécutions de routine soient réduites.Un stockage en écriture à la suite (append-only) avec une rétention alignée sur l'obligation qui justifie l'enregistrement, et un contrôle d'accès correspondant aux systèmes sources.Un chemin de relecture qui reconstruit une exécution à partir de la seule trace, utilisé assez souvent pour que ses lacunes soient connues.

Avantages

Rend les échecs non déterministes diagnostiquables : vous pouvez expliquer pourquoi cette exécution a agi ainsi, au lieu de la reproduire jusqu'à ce que cela se reproduise.
Transforme les obligations de tenue de registres en un artefact plutôt qu'en une promesse. La reconstruction fonctionne sur une exécution passée aléatoire, ou elle ne fonctionne pas.
Alimente l'évaluation avec des échecs réels plutôt qu'inventés, ce qui fait toute la différence entre un benchmark et une suite de non-régression.
Sépare la dérive du déploiement. Avec la version du modèle dans l'enregistrement, « cela s'est dégradé » devient une question qui a une réponse.

Risques

Le stockage des traces comme cible la plus vulnérable : il contient les mêmes données que les systèmes qu'il décrit, généralement avec un contrôle d'accès plus faible et une rétention plus longue.
Un coût de capture qui augmente avec le trafic jusqu'à ce que quelqu'un applique un échantillonnage head-based pour économiser de l'argent, supprimant discrètement les exécutions qui méritaient précisément d'être conservées.
Un masquage qui supprime ce dont la reconstruction avait besoin. Un sur-masquage reste invisible jusqu'au jour où quelqu'un tente de rejouer une exécution et n'y parvient pas.
Le volume confondu avec la couverture. Des téraoctets de spans sans identifiant partagé ne permettent toujours pas de répondre à une seule question sur une exécution donnée.

Quand ne pas l'utiliser

Appels déterministes à étape unique où l'entrée et la sortie résument toute l'histoire. Un journal de requêtes permet déjà de les reconstruire.
Prototypes sans utilisateurs ni obligations, où le coût du pipeline de traces dépasse tout ce que vous pourriez en apprendre.
Lorsque la règle applicable interdit totalement de conserver le contenu. Dans ce cas, la trace enregistre qu'une décision a eu lieu ainsi que ses métadonnées, et le contenu reste exclu — il s'agit d'un artefact différent, et prétendre le contraire crée la responsabilité que la règle visait à éviter.

Technologies

OpenTelemetry GenAI semantic conventionsDistributed tracing backendsTail-based samplingField-level redaction at captureAppend-only / WORM storageStructured logging with a propagated run id

Exemples

Un incident où un agent a envoyé un e-mail au mauvais client. L'identifiant d'exécution lie la récupération qui a renvoyé le mauvais enregistrement, l'appel d'outil qui l'a utilisé et le message envoyé, de sorte que la cause racine se résume à une seule requête plutôt qu'à une semaine de tentatives de reproduction.
Un régulateur demande comment une décision a été prise il y a six mois. Le chemin de relecture reconstruit l'exécution à partir de la seule trace, y compris la version du modèle en vigueur ce jour-là.
Une baisse de qualité après la mise à niveau d'un modèle. Comme chaque span contient la version du modèle, la comparaison s'effectue entre deux populations d'exécutions réelles plutôt qu'entre des impressions.

KPI

Taux de réussite de la reconstruction: Part des exécutions passées choisies au hasard qui peuvent être reconstruites de bout en bout à partir de la seule trace. Il s'agit du propre test du contrôle, et c'est le seul chiffre ici qui ne peut pas être amélioré simplement en capturant davantage de données.
Complétude de la corrélation: Part des spans d'une exécution qui portent l'identifiant d'exécution. Tout résultat inférieur à 100 % signifie qu'une étape est invisible, et l'étape manquante est rarement la plus banale.
Taux d'échappement des champs sensibles: Part des enregistrements échantillonnés contenant une valeur que les règles de masquage auraient dû supprimer. L'objectif est de zéro ; tout autre chiffre signifie que le stockage des traces accumule un risque juridique.
Rétention des exécutions anormales: Part des exécutions en erreur ou escaladées conservées après échantillonnage. L'échantillonnage head-based pousse ce chiffre vers le taux d'échantillonnage global, ce qui constitue précisément la défaillance que cette métrique vise à détecter.

Modes de défaillance observés

La trace qui ne prouve rien : chaque étape est journalisée, aucune étape ne partage d'identifiant, et reconstruire une exécution implique de corréler les horodatages à la main.
Le prompt enregistré par référence. Le template a changé, de sorte que le journal décrit désormais un prompt que le modèle n'a jamais vu, et personne ne s'en aperçoit jusqu'à ce qu'une reconstruction contredise la sortie.
L'échantillonnage head-based qui conserve l'ordinaire. L'exécution dont vous avez besoin a été rejetée au point d'entrée, avant même que l'on sache qu'elle allait être intéressante.
Le journal comme source de violation de données : les arguments bruts des outils acheminent des données personnelles vers un stockage doté d'un accès plus large et d'une rétention plus longue que la base de données dont ils proviennent.
Version du modèle manquante. Un changement de comportement et une mise à jour silencieuse du modèle semblent identiques dans l'enregistrement, et l'investigation stagne sur une question à laquelle la trace aurait dû répondre.

Leçons apprises

La corrélation est le produit ; la capture est la matière première. Les équipes qui achètent un backend de tracing et font l'impasse sur l'identifiant se retrouvent avec du stockage plutôt qu'avec des réponses.
Testez la reconstruction, pas le pipeline. Choisissez une exécution passée au hasard et reconstruisez-la — les lacunes se trouvent toujours là où personne n'a placé d'instrumentation, et seule cette tentative permet de les trouver.
Masquez au moment de l'écriture. Chaque masquage différé au moment de la lecture est une décision de conserver la valeur brute, et le stockage survit à l'intention.
Échantillonnez sur la fin (tail-based). L'échantillonnage head-based est une décision d'écarter les exécutions intéressantes avant même de savoir de quelles exécutions il s'agit.
Enregistrez la version du modèle partout. Cela ne coûte qu'un champ et cela fait toute la différence entre diagnostiquer une dérive et en débattre.

FAQ

Nous utilisons déjà un backend de tracing. Le problème n'est-il pas résolu ?: Un backend vous fournit la capture et le stockage. Ce pattern concerne les trois aspects qu'un backend ne décide pas pour vous : si un identifiant unique relie l'ensemble de l'exécution, si la fidélité est suffisante pour la reconstruire sans les systèmes sources, et si ce que vous avez enregistré peut être conservé en toute sécurité. Des équipes disposant d'excellents outils échouent régulièrement au test de reconstruction.
Une capture complète n'entre-t-elle pas en conflit avec la minimisation des données ?: Ce serait le cas si la capture signifiait tout conserver à l'état brut. Le contrôle énonce délibérément les deux aspects — assez pour reconstruire, rien qui ne transforme le journal en violation de données — et le moyen de concilier les deux est le masquage au niveau des champs lors de la capture, associé à une rétention liée à l'obligation qui justifie l'enregistrement. Ce que vous ne pouvez pas faire, c'est éluder cette tension en conservant tout et en qualifiant cela de conformité.
Quel niveau de fidélité est suffisant ?: Exactement assez pour réussir le test de reconstruction sur une exécution choisie au hasard, et pas plus. Ce seuil peut être découvert en essayant, c'est pourquoi le test doit faire partie de la routine plutôt que d'un audit. Tout ce qui est capturé au-delà représente un coût et un risque juridique sans répondre à aucune question.