Observabilité des sessions

Pourquoi l’observabilité des sessions agentiques

Un agent de développement exécute des dizaines d’actions par session : lectures de fichiers, écritures, exécutions de commandes, appels d’outils. Contrairement à un développeur humain qui garde en mémoire ce qu’il a fait et pourquoi, un agent ne laisse rien de visible par défaut.

Point clé : L’observabilité consiste à rendre visible et exploitable ce que l’agent a fait, pourquoi il l’a fait, à quel coût, et avec quel résultat.

Sans observabilité, on est en situation de « boîte noire » : on constate le résultat final sans pouvoir diagnostiquer les problèmes, optimiser les coûts, ou auditer les actions. C’est l’équivalent d’un serveur en production sans logs ni métriques.

Les quatre piliers

Ces quatre piliers ne sont pas indépendants. Les logs alimentent le replay. Les métriques de coût sont extraites des logs. L’audit trail combine les logs avec l’identité du demandeur et le contexte de la demande.

Logs d’actions

Ce qu’on logge

Les éléments essentiels à tracer dans chaque session :

• Chaque appel d’outil : lecture de fichier, écriture, exécution de commande, recherche
• Le résultat de chaque action : succès, erreur, sortie console
• Les erreurs et les tentatives de correction (boucles fermées)
• Le raisonnement de l’agent quand il est exposé (plan mode, mode verbose)

Niveaux de détail

Attention : Un log trop verbeux sur toutes les sessions génère du bruit et un coût de stockage disproportionné. Le niveau standard est un bon défaut ; le verbose se réserve aux sessions qui posent problème.

Métriques de coût

Les tokens sont la devise du développement agentique. Sans métriques, impossible de savoir si une session a été efficiente ou si l’agent a tourné en rond.

Métriques essentielles

• Tokens par session — entrée et sortie, ventilés par tour de boucle
• Coût monétaire — calculé à partir du tarif du modèle utilisé
• Nombre de tours de boucle — indicateur de complexité ou de boucle improductive
• Ratio progression/tour — les tours qui font avancer la tâche vs ceux qui stagnent

Point clé : Une session dont le nombre de tours explose sans progression des tests est un signal clair de boucle improductive. L’observabilité permet de détecter ce pattern et de couper avant que le coût s’envole.

Replay de session

Le replay va au-delà du log linéaire : il reconstitue le contexte de l’agent à chaque étape. Pourquoi a-t-il choisi de modifier ce fichier ? Qu’avait-il en contexte à ce moment-là ? Quel résultat d’outil l’a conduit à cette décision ?

Cas d’usage

• Diagnostic d’échec — comprendre pourquoi l’agent est parti dans la mauvaise direction
• Formation — montrer aux développeurs les bons et mauvais patterns de prompting
• Optimisation de prompts — identifier à quel moment le prompt ou le contexte a induit l’agent en erreur

Lien avec ZTE et l’Agentic Layer

L’observabilité est une condition préalable au ZTE (Zero Trust Execution). Sans logs, pas d’audit. Sans métriques, pas de détection de boucle infinie. Sans replay, pas de diagnostic post-incident.

Point clé : Dans l’Agentic Layer, l’observabilité est l’un des quatre composants fondamentaux (avec les skills/workflows, la configuration, et les garde-fous). Une Agentic Layer sans observabilité est comme un serveur de production sans monitoring.

Pour une équipe, l’observabilité centralisée permet de comparer les pratiques, détecter les patterns de prompting inefficaces, et partager les bonnes pratiques à partir de données concrètes. C’est aussi le socle de toute exigence de conformité (RGPD, audit trail, traçabilité des modifications).