Observabilité & coût : traces, coût par tâche réussie

Pourquoi ce module

Deux questions que pose tout client sérieux, et auxquelles la plupart des candidats répondent mal : « qu'est-ce que ça coûte ? » et « comment saurez-vous que ça se dégrade ? »

La réponse à la première n'est pas un prix au million de tokens. La réponse à la seconde n'est pas « on regardera les logs ». Ce module donne les deux bonnes réponses.

Objectifs pédagogiques

1. Instrumenter un système agentique en traces et spans
2. Nommer la seule métrique de coût qui veut dire quelque chose, et la défendre
3. Décomposer un coût par requête et identifier le poste dominant
4. Concevoir des évaluations continues en production
5. Expliquer ce qu'on surveille pour détecter une dégradation silencieuse

Plan détaillé

1. Traces et spans
2. Le coût par tâche réussie
3. Décomposer un coût
4. Les leviers de réduction
5. Évaluations continues
6. Six points d'instrumentation
7. Glossaire du module

1. Traces et spans

Le vocabulaire vient de l'observabilité classique et il faut l'employer correctement :

• Une trace couvre une requête utilisateur de bout en bout
• Un span est une étape dans cette trace, avec un début, une fin, et des attributs
• Les spans sont imbriqués : un appel d'outil est un span enfant de la génération

Ce qu'on attache à chaque span : durée, tokens entrée/sortie, modèle utilisé, coût calculé, et — le plus important pour le débogage — l'identifiant du tenant et celui de la requête.

🎯 Pourquoi la trace est la bonne unité. Parce que le débogage d'un système agentique est une question de chemin, pas de valeur. « La réponse était mauvaise » ne se diagnostique qu'en rejouant la séquence : quels passages ont été récupérés, dans quel ordre, quel outil a été appelé, avec quels arguments. Une log ligne à ligne ne reconstitue pas ça.

2. Le coût par tâche réussie

C'est la métrique du module, et probablement la meilleure phrase à sortir en entretien sur ce sujet.

🎯 La formulation. « Le coût par million de tokens est un prix catalogue, pas une métrique de système. Le coût par requête est déjà mieux, mais il ignore les échecs : un système deux fois moins cher par requête et qui échoue une fois sur trois coûte plus cher au total, parce que l'utilisateur relance. La seule métrique honnête, c'est le coût par tâche réussie — elle inclut les reprises, les abandons, et les réponses qu'il a fallu redemander. »

Le corollaire, souvent demandé en relance : cette métrique impose de savoir ce qu'est une tâche réussie, donc d'avoir des critères de succès (module F8) et une évaluation (module F4). C'est ce qui relie les trois modules — et le dire montre qu'on a une vue système.

3. Décomposer un coût

💡 Le poste qu'on oublie systématiquement : les reprises. Un agent qui boucle trois fois avant d'aboutir coûte trois fois. Sans trace, cette dépense n'apparaît nulle part — elle est noyée dans un total. C'est la première chose à regarder quand une facture surprend.

4. Les leviers de réduction

Dans l'ordre du meilleur rapport gain/risque :

1. Le cache de prompt. Le préfixe stable d'un prompt (consignes système, schémas d'outils) est facturé une fraction du prix s'il est identique d'une requête à l'autre. Gain élevé, risque nul. Condition : que le préfixe soit vraiment stable — un horodatage en tête de prompt annule tout le bénéfice.
2. Le routage de modèle. Classification et extraction sur un petit modèle, raisonnement sur un grand. Gain élevé, risque modéré, à valider par une évaluation : c'est le levier où l'on dégrade sans s'en apercevoir.
3. Moins de passages. Diviser par deux le nombre de passages injectés réduit l'entrée d'autant — et améliore souvent la qualité (module F1, lost in the middle). Le seul levier qui améliore les deux à la fois.
4. Plafonner les itérations. Un agent qui ne converge pas doit s'arrêter et le dire, pas continuer.

⚠️ Le piège du routage. Router vers un modèle moins cher sans harnais d'évaluation, c'est troquer un coût mesurable contre une dégradation invisible. La règle : on ne change pas de modèle sans repasser les évals. Un candidat qui propose le routage sans mentionner la validation donne une mauvaise réponse.

5. Évaluations continues

Le harnais du module F4 tourne avant livraison. Mais un système en production se dégrade pour des raisons qui n'existaient pas au moment du test : le corpus grossit, les questions changent, le fournisseur met à jour son modèle.

Ce qu'on surveille, et il faut savoir citer les quatre :

💡 Le jeu témoin figé est la clé. Un ensemble de requêtes qui ne change jamais, rejoué chaque semaine. Si son score bouge alors qu'il n'a pas bougé, c'est le système qui a changé. Sans point fixe, on ne peut attribuer aucune variation.

Et la boucle qui compte : les traces de production alimentent le jeu de cas d'évaluation. Les vraies questions des vrais utilisateurs sont un meilleur jeu de test que tout ce qu'un ingénieur peut imaginer — c'est la même idée qu'au module F4, appliquée en continu.

6. Six points d'instrumentation

6.1 Ce qu'une trace préserve qu'un log plat ne préserve pas

La structure d'arbre. Sans elle, impossible de répondre à « quel outil, avec quels arguments, et combien de temps ». Un log plat donne une suite d'événements ; il ne dit pas lequel est enfant de lequel.

La formule à retenir : la trace est la trajectoire. C'est ce qui relie ce module à l'évaluation de trajectoire du F4 — sans traces structurées, cette évaluation est impossible.

6.2 Ce qu'on enregistre d'un appel d'outil

Au-delà du nom : les arguments.

Les arguments sont ce qui rend la validité d'arguments mesurable a posteriori — l'une des métriques déterministes de trajectoire.

Avec une contrainte : caviarder les PII à l'entrée, mais garder la forme. [EMAIL] plutôt que la suppression, exactement comme au module F5 — pour la même raison, et parce qu'un argument absent est indiscernable d'un argument vide.

6.3 Échantillonner, mais pas uniformément

Tout conserver en fidélité complète coûte trop cher. Mais :

Les échecs sont rares et denses en information — c'est là que doit aller le budget de rétention. L'échantillonnage uniforme jette précisément les exécutions utiles.

La règle : 100 % des traces en échec, un échantillon des réussites. Ce qui impose une conséquence technique à savoir énoncer — la décision d'échantillonnage ne peut pas être prise au début de la trace, puisqu'on ignore encore si elle échouera. Il faut donc un échantillonnage différé, décidé à la fin, ou une mise en tampon de la trace complète jusqu'à son issue.

6.4 La cardinalité des attributs de span

Ajouter l'identifiant utilisateur en attribut de span pour déboguer par client : bonne idée, avec deux contreparties.

Les étiquettes à forte cardinalité sont acceptables en attributs de span — où elles servent à la recherche — et ruineuses en dimensions de métriques, où chaque valeur distincte crée une série temporelle.

Et le point que les équipes oublient : un stockage de traces contenant des identifiants utilisateur hérite de toutes les obligations de rétention et d'effacement de la base primaire. Une demande d'effacement RGPD porte aussi sur les traces.

6.5 « Tokens × prix » est faux dès qu'il y a du cache

Le modèle de coût naïf s'effondre en présence de cache de prompt, et pour une raison contre-intuitive :

Un premier appel qui alimente le cache peut coûter plus cher qu'un appel sans cache. Donc sur un tenant à faible trafic, où le cache expire entre deux appels, le cache peut coûter davantage.

Ce que seule la mesure par exécution révèle. C'est un excellent argument pour le coût par tâche réussie : il capture ce genre d'effet, la formule ne le capture pas.

6.6 Le plafond de dépense, et la perte entre deux maillons

Un client demande un plafond mensuel dur. La bonne réponse n'est pas « on mettra une alerte de facturation » :

Les alertes de facturation sont des indicateurs retardés. L'application du budget appartient à la même couche que le plafond d'étapes d'agent — un compteur consulté avant l'appel, qui refuse quand le plafond est atteint. Et les deux doivent être observables.

Le pipeline en trois étages qui perd des documents relève du même angle mort. Chaque étage rapporte un succès, et pourtant des documents n'arrivent jamais en base :

Une chaîne dont chaque maillon réussit isolément peut perdre du travail entre deux maillons. Il manque une réconciliation de bout en bout : compter à l'entrée, compter à la sortie, et alerter sur l'écart.

Le symptôme est indiscernable de « cet équipement n'a pas de documentation » — c'est ce qui le rend si difficile à détecter sans compteur.

7. Trois situations de terrain

7.1 Premier jour : qu'instrumente-t-on avant tout le reste ?

Les traces avec spans imbriqués, en premier. Avant les métriques, avant le tableau de bord, avant les alertes.

Puis, dans le même mouvement : coût et latence par span (pas seulement par requête), arguments d'outil enregistrés avec PII caviardées, et les contrôles déterministes de sortie — qui ne coûtent rien.

La justification à donner, et c'est elle qui convainc : « au trentième jour, il y aura un incident. À ce moment-là, soit j'ai la trace et je réponds en dix minutes, soit je ne l'ai pas et je passe trois jours à reproduire. Rajouter l'instrumentation après l'incident est le chemin coûteux — et on ne récupère jamais les traces de l'incident lui-même. »

🎯 La relance : « la sécurité du client refuse le stockage des prompts. » — Réponse : on stocke la structure sans le contenu. Noms d'outils, arguments caviardés, durées, coûts, verdicts de garde-fous, identifiants de passages. C'est 90 % de la valeur de débogage sans aucun texte utilisateur conservé.

7.2 Ça marchait en recette, ça déraille en production

On part de la trace, pas de la sortie. C'est la première phrase, et elle vous distingue immédiatement de quelqu'un qui va relire le prompt.

Le déroulé :

1. Ouvrir la trace du cas qui déraille — passages récupérés, outils appelés, arguments
2. Chercher des formes d'échec concrètes : récupération vide, passage en quarantaine, outil en timeout, boucle d'itérations
3. Vérifier si ce cas est dans le jeu d'évaluation
4. S'il en est absent — c'est ÇA la trouvaille. Le jeu ne couvre pas la production. On l'ajoute avant de corriger quoi que ce soit
5. S'il y passe, alors la différence est environnementale : version de modèle, contenu de l'index, configuration
6. Vérifier les garde-fous : une quarantaine silencieuse est indiscernable d'une documentation manquante (cf. F5)

⚠️ La relance dure : « il n'y a pas de trace, l'équipe précédente n'a rien instrumenté. » — On instrumente d'abord, on reproduit ensuite. Déboguer un système agentique sans trace, c'est deviner ; et le temps passé à deviner est systématiquement supérieur au temps d'instrumenter.

7.3 Le tableau de bord : ce qu'on y met, et ce qu'on n'y met pas

On demande d'abord qui le lit. Un tableau de bord pour tout le monde n'est lu par personne.

Ce qu'on exclut explicitement : les métriques flatteuses sans décision associée. Le nombre de tokens traités, le nombre de requêtes servies, le temps de disponibilité — ils montent tout seuls et ne déclenchent aucune action.

Le taux de refus mérite sa place comme indicateur avancé : il monte avant que la satisfaction ne baisse.

🎯 La relance : « le sponsor veut un seul chiffre. Lequel ? » — Le taux de réussite face au seuil convenu au cadrage. C'est le seul qui répond à la question qu'il se pose vraiment : est-ce que ça marche comme on avait dit ?

8. Glossaire du module

Atelier (60 min)

1. La métrique (15 min) — répondez à « what does this cost? » en anglais, en une minute, en aboutissant au coût par tâche réussie et en disant pourquoi les deux autres formulations trompent.
2. Décomposer (20 min) — pour un RAG type, estimez la part de chaque poste et nommez le dominant. Puis dites lequel se voit seulement dans les traces.
3. La dégradation silencieuse (25 min) — « comment saurez-vous que ça se dégrade ? » Citez les quatre signaux et expliquez le rôle du jeu témoin figé.

Pour aller plus loin

• 🎯 Parcours : F5 — Sûreté & garde-fous ← → F7 — Déploiement entreprise
• 📚 Approfondissement : M2 — Token economics et J4 — Observabilité production
• 🛠 Entraînement : thème observability_cost de la banque fransys-fde — 12 QCM