Rejeu de traces
Chaque exécution d'agent est enregistrée avec assez de détails pour la rejouer exactement — pour que « pourquoi l'IA a-t-elle fait ça ? » devienne une question avec une réponse plutôt qu'un haussement d'épaules.
Pensez à une boîte noire d'avion. Après un pépin en vol, les enquêteurs ne devinent pas — ils rejouent exactement ce que les instruments ont vu et ce que les systèmes ont fait. Le rejeu de traces, c'est une boîte noire pour vos workflows d'IA : la réponse étrange de jeudi passé peut être rejouée aujourd'hui, exactement comme elle s'est produite.
Le problème, en mots simples
Un utilisateur rapporte que l'agent a donné une réponse bizarre jeudi passé. Vous essayez la même question aujourd'hui — ça marche très bien. Et maintenant ? Les documents ont changé depuis jeudi, les réponses du modèle varient d'une fois à l'autre, et les outils retournent d'autres données que ce jour-là. Alors « impossible à reproduire » s'écrit sur le billet, le bogue reste en vie, et tout le monde sait tout bas qu'il reviendra — à un pire moment.
Ce que nous mettons en place
La trace — l'enregistrement d'une exécution — capture chaque entrée qui aurait pu changer le comportement de l'agent : l'événement qui l'a déclenchée, les passages exacts retournés par le retrieval, les entrées et sorties de chaque appel d'outil, les réglages du modèle (ses paramètres), et la réponse du modèle elle-même. Le rejeu refait rouler le même workflow contre ces entrées capturées, pour qu'une développeuse voie précisément ce que l'agent a vu ce jour-là. En développement, les vrais outils sont remplacés par des doublures qui répondent à partir de l'enregistrement (des stubs) : rejouer une exécution ne touche jamais aux systèmes réels — aucun remboursement n'est réémis pendant qu'on débogue. Et quand un rejeu diverge de ce que la production a réellement fait, cette différence est elle-même suivie : quelque chose a influencé l'exécution sans être capté par la trace, ce qui est une trouvaille en soi.
Comment ça fonctionne, étape par étape
- Chaque exécution est enregistrée en vol
Événement de départ, passages récupérés, appels d'outils et leurs résultats, réglages du modèle et réponse du modèle — captés au moment où ça se passe.
- Une mauvaise sortie reçoit un identifiant de trace
Le billet pointe vers l'exécution exacte, pas vers la description vague de ce dont quelqu'un se souvient.
- L'exécution est rejouée depuis l'enregistrement
Mêmes entrées, mêmes passages, mêmes réponses d'outils. La développeuse retraverse jeudi passé exactement comme il s'est déroulé.
- Les rejeux ne touchent à rien de réel
Les doublures d'outils répondent à partir de l'enregistrement : déboguer ne déclenche jamais un vrai geste une deuxième fois.
- Les différences sont un signal
Quand le rejeu diverge de ce que la production a fait, quelque chose a échappé à l'enregistrement — et ce trou-là se corrige aussi.
Ce qui change pour vous
Avant : les bogues d'agents finissaient en « impossible à reproduire » et en attente silencieuse que le problème frappe encore. Après : le débogage redevient de l'ingénierie ordinaire — sortir la trace, la rejouer, regarder le mauvais virage se produire, corriger, rejouer pour confirmer. La phrase la plus inquiétante des opérations d'IA, « on ne sait pas pourquoi il a fait ça », prend sa retraite. Ce qu'il ne fera pas : le rejeu ne peut reproduire que ce qui a été enregistré. Une exécution d'avant la mise en place des traces, ou une entrée qui a glissé entre les mailles, reste hors d'atteinte — la discipline d'enregistrer vient en premier, et la récompense la suit.