Observer ses agents : les métriques et traces qui comptent

Faire tourner douze agents en chaîne, c’est opérer un système distribué. Quand quelque chose dérape — lenteur, coût anormal, qualité en baisse — seule l’observabilité permet de comprendre où et pourquoi.

Les métriques essentielles

• Latence par agent : repérer le maillon lent.
• Tokens et coût par étape : identifier ce qui pèse sur la facture.
• Taux de retry / rejet de contrat : un agent qui échoue souvent signale un prompt ou un schéma à revoir.
• Taux d’approbation aux gates : trop de rejets humains = un cadrage à améliorer en amont.

Les traces, pour relier les points

Une métrique dit qu’un problème existe ; une trace dit où. Tracer le parcours complet d’une exécution — quel agent a appelé quoi, avec quel contexte, pour quel résultat — transforme un incident opaque en diagnostic clair. L’audit trail chaîné sert ici doublement : preuve et outil de debug.

Des seuils et des alertes

L’observabilité passive ne suffit pas. Fixe des seuils (coût par run, latence, taux d’échec) et déclenche des alertes. Mieux vaut être prévenu d’un run anormalement coûteux pendant qu’il tourne qu’après.

Boucler la boucle

Les données d’observabilité ne servent vraiment que si elles nourrissent l’amélioration : ajuster un prompt, déplacer une gate, changer le routage d’un provider. C’est cette boucle de feedback qui fait passer un pipeline de « ça marche » à « ça s’améliore ».