Instrumenter la chaîne¶
Une carte de contrôle a besoin d'une série de mesures comparables. Ce chapitre décrit ce qu'il faut enregistrer à chaque run d'un orchestrateur, comment regrouper ces mesures, et quelle carte appliquer à chacune.
La télémétrie existe déjà¶
Les conventions OpenTelemetry pour l'IA générative¶
OpenTelemetry, le standard ouvert d'observabilité, définit des conventions sémantiques pour l'IA générative. Elles ont été déplacées en mai 2026 dans un dépôt dédié et sont encore au statut « Development », c'est-à-dire non stabilisées (dépôt). Elles prévoient notamment :
- des spans d'agent (
invoke_agent,execute_tool,invoke_workflow) ; - des métriques de durée (
gen_ai.invoke_agent.duration,gen_ai.execute_tool.duration) ; - des compteurs d'appels (
gen_ai.invoke_agent.inference_calls,gen_ai.invoke_agent.tool_calls) ; - des compteurs de tokens par type (entrée, sortie, cache, raisonnement).
Les plateformes de traçage comme Langfuse acceptent ces conventions (documentation).
La télémétrie de Claude Code¶
Claude Code émet nativement de la télémétrie OpenTelemetry quand on active
CLAUDE_CODE_ENABLE_TELEMETRY=1
(documentation) : coût,
tokens, lignes de code, PR et commits créés, décisions d'acceptation des
modifications, et des événements comme tool_result, api_error,
skill_activated ou api_retries_exhausted.
Ce qui manque
Ces télémétries mesurent le coût et l'activité de l'agent. Elles ne mesurent pas la qualité du résultat. Les caractéristiques de qualité — tests cachés réussis, fichiers de test modifiés, reprise dans les deux semaines — doivent être calculées par l'orchestrateur lui-même, hors de portée de l'agent.
Estampiller chaque run¶
Pour construire des sous-groupes rationnels, chaque run doit porter tout ce qui peut constituer une cause spéciale (voir le tableau des sources de variation du chapitre Un producteur stochastique) :
| Étiquette | Exemple |
|---|---|
| Identifiant exact du modèle | Pas l'alias « dernier modèle », l'identifiant daté |
| Fournisseur et région | API directe, cloud tiers |
| Version de l'orchestrateur | Hash de commit |
| Empreinte des instructions | Hash du prompt système, des CLAUDE.md, de chaque skill chargé |
| Version des outils | Versions des serveurs MCP, de l'image d'exécution |
| Type de tâche | Anomalie, documentation, dépendance, fonctionnalité |
| Dépôt et taille | Nombre de fichiers touchés |
Quand une alarme se déclenche, la première question de Shewhart est « qu'est-ce qui a changé ? ». Ces étiquettes permettent d'y répondre par une requête au lieu d'une enquête.
Le tableau des caractéristiques à surveiller¶
Les caractéristiques ci-dessous sont mesurables à chaque run. La colonne « Carte » renvoie aux choix justifiés dans la partie Fondations.
| Caractéristique | Nature | Carte | Remarque |
|---|---|---|---|
| Réussite au premier essai (tests cachés) | Proportion par lot | Carte p | La caractéristique principale ; voir le calcul de puissance |
| Fichiers de test modifiés alors que la tâche ne le demande pas | Proportion | Carte p | Signal de contournement |
Marqueurs de contournement ajoutés (skip, exit(0), except: pass) |
Comptage par run | Carte c ou u | Détection syntaxique, peu coûteuse |
| Tokens consommés par run | Continue, asymétrique | XmR sur le logarithme | Hausse soudaine = boucle ou contexte qui grossit |
| Nombre de tours ou d'appels d'outils | Comptage, asymétrique | XmR sur le logarithme | Le mode « répétition d'étapes » de MAST est le plus fréquent |
| Erreurs d'outils par run | Comptage | Carte u | Un serveur MCP cassé est une cause spéciale typique |
| Durée du run | Continue, asymétrique | XmR sur le logarithme | Corrélée à la charge du fournisseur |
| Arrêt sur limite (tours, budget, temps) | Proportion | Carte p | Mesure les runs qui n'ont pas convergé |
| Reprise à 14 jours | Proportion, différée | Carte p mensuelle | Le signal le plus proche de la qualité réelle ; arrive tard |
Erreur fréquente : une carte par métrique, sans stratification
Un orchestrateur qui traite à la fois des mises à jour de dépendances (faciles, rapides) et des correctifs de performance (durs, longs) produit un mélange de deux processus. Sur une carte unique, le simple changement de proportion entre les deux types de tâches ressemble à une dérive. Toujours une carte par type de tâche, ou des limites variables selon le type.
Sous-groupes : par lot de temps ou par version ?¶
Deux façons de regrouper les runs en points de carte :
- par fenêtre de temps (un point par jour ou par tranche de 50 runs) — convient pour détecter une dérive venue de l'extérieur (fournisseur, infrastructure) ;
- par version (un point par empreinte de prompt ou de skill) — convient pour qualifier un changement délibéré, mais donne peu de points.
En pratique, on combine les deux : une carte par fenêtre de temps, sur laquelle on annote chaque changement de version. C'est la pratique classique des cartes industrielles, où l'on note sur le graphique « changement d'outil », « nouveau lot de matière ».
À retenir
L'instrumentation de base existe (OpenTelemetry, télémétrie native des agents) mais elle mesure l'activité, pas la qualité. L'orchestrateur doit ajouter (1) des étiquettes de version sur chaque run, (2) des caractéristiques de qualité calculées hors de portée de l'agent, (3) une stratification par type de tâche. Ensuite seulement, les règles de Western Electric ont quelque chose de sensé à lire.