Tu as livré ton premier agent en production — une IA qui ne se contente pas de répondre aux questions mais qui fait des trucs : enchaîne 50 à 200 appels d'outils (des requêtes vers des services externes comme Slack, Linear, GitHub), écrit du code, envoie des messages, crée des tickets. Un client dépend du résultat. La vie est belle.

Puis un client reçoit une mauvaise réponse. Ton agent a écrit dans le mauvais projet Linear, mergé une PR foireuse, envoyé un DM Slack au CEO au lieu d'un dev junior. Tu dois comprendre pourquoi — avant que ça recommence.

Alors tu te tournes vers les tout nouveaux outils d'observabilité que chaque plateforme majeure a sortis en avril 2026. Le 8 avril, Anthropic a lancé Managed Agents avec du tracing de sessions et des logs d'appels d'outils intégrés. Le 10 avril, Zed a sorti Agent Metrics — des dashboards suivant 2 millions de sessions, 15,4 millions de tours, des histogrammes de latence sur 536 agents distincts. Le 15 avril, OpenAI a mis à jour son Agents SDK avec de l'auto-tracing qui enregistre chaque appel d'outil, chaque handoff et chaque sortie du modèle — zéro instrumentation supplémentaire — plus une compatibilité complète avec OpenTelemetry (OpenTelemetry étant le standard industriel pour la collecte de données de performance, une sorte de prise universelle pour les outils de monitoring).

Chaque éditeur a résolu le même problème : montre-moi ce qui s'est passé. Et ils l'ont bien fait. Tu ouvres les traces — des spans (des enregistrements individuels de chaque opération) pour chaque invocation LLM, chaque appel d'outil, chaque token (un fragment de mot que l'IA traite). De magnifiques diagrammes en cascade. Des chiffres de latence précis.

Mais voilà où ça casse. Une trace d'agent n'est pas une trace de microservice. Les microservices — ces petits programmes indépendants qui font tourner la plupart des applis web — sont déterministes : même entrée, même sortie, même bug, fix reproductible. Les agents sont non-déterministes : relance exactement la même tâche, tu obtiens des décisions différentes à l'étape 47. L'agent a choisi le chemin A, mais tu ne peux pas voir à quoi ressemblait le chemin B, ni pourquoi il a pris A plutôt que B avec ses 80 000 tokens de contexte accumulé (la "mémoire de travail" de l'IA — tout ce qu'elle a lu et généré jusqu'à ce point).

Comme Simon Willison l'a écrit dans son guide Agentic Engineering Patterns du 3 avril : "On ne peut pas garantir qu'un agent agit fidèlement ni diagnostiquer les problèmes si ses opérations sont entièrement opaques." Et le post-mortem de Sentry du 16 avril a mis le doigt exactement sur le mode de défaillance : chaque span affiche status: ok, mais la sortie est complètement fausse. Le bug vit entre les agents — un appel d'outil dégrade silencieusement l'entrée d'un autre agent deux étapes plus loin.

Débugger une mauvaise décision d'agent à partir de sa trace, c'est comme débugger une décision humaine à partir de son Google Calendar — tu vois les réunions qu'il a eues, pas ce qu'il pensait.

La rustine du marché : le LLM-as-judge — utiliser un second modèle d'IA pour évaluer les décisions du premier. Braintrust (80 M$ levés en février pour une valorisation de 800 M$), les trajectory evals de LangSmith, et Arize Phoenix ajoutent tous de l'évaluation par-dessus les traces. Mais chacun ajoute une nouvelle dépendance, un coût en tokens supplémentaire par point de décision, et — cerise sur le gâteau — le modèle juge partage les mêmes angles morts architecturaux que l'agent qu'il est censé juger.

La solution pratique aujourd'hui : forcer ton agent à émettre un raisonnement structuré à chaque point de branchement. Pas juste l'enregistrement de l'appel d'outil, mais un rationnel en JSON :

import json

def log_decision(step: int, options: list[str], chosen: str, reasoning: str):
    """Emit a searchable reasoning trail at every branch."""
    entry = {
        "step": step,
        "options_considered": options,
        "chosen_action": chosen,
        "reasoning": reasoning,
        "context_tokens_used": get_current_context_length(),
    }
    logger.info("agent_decision", extra=entry)
    return entry

# Inside your agent loop:
log_decision(
    step=47,
    options=["post to #general", "post to #engineering", "DM the assignee"],
    chosen="DM the assignee",
    reasoning="Ticket is labeled 'confidential', channel posting violates policy"
)

Oui, ça coûte des tokens en plus. Oui, ça ralentit l'exécution. Mais c'est le seul moyen de construire une piste de raisonnement consultable qu'un humain peut auditer après un incident — parce que les traces seules ne te diront jamais pourquoi l'étape 47 a dérapé.

Chaque plateforme a livré le "ce qui s'est passé". Personne n'a livré le "pourquoi ce chemin et pas l'autre". La première boîte qui construira de l'observabilité native au raisonnement — pas native aux traces, native au raisonnement — dominera la couche de débogage pour chaque agent en production, comme Datadog domine le monitoring des microservices. En attendant, tu lis l'agenda de ton agent et tu devines ce qu'il avait en tête.