# Rejouer une conversation d’agent après un incident : ce qu’exige un rejeu fidèle > Graine, version du modèle, horodatage des outils : l'architecture à mettre en place pour reconstituer exactement une session d'agent après un incident. - Auteur : Clément Hadrot - Publié le : 2025-10-11 - Mis à jour le : 2025-10-11 - Catégorie : IA & MCP - URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/rejouer-conversation-agent-incident-rejeu-fidele/ ## L’essentiel - Un rejeu fidèle exige de figer la version du modèle utilisée, pas seulement son nom - La graine seule ne suffit pas si les appels d'outils ne sont pas horodatés dans l'ordre exact - Un rejeu approximatif donne une fausse confiance, pire qu'aucun rejeu du tout Un modèle change de version, un outil externe renvoie une réponse différente d'une minute à l'autre, l'ordre des appels varie selon la latence réseau du moment : reconstituer exactement ce qu'un agent a « vu » et décidé lors d'un incident est bien plus exigeant que de relire simplement la transcription de la conversation. Cet article détaille l'architecture de journalisation nécessaire pour permettre un rejeu fidèle d'une session d'agent après coup, à des fins d'analyse d'incident. Il ne traite pas de la question, distincte, du stockage à long terme de ces journaux ni de leur politique de rétention. ## Pourquoi la seule transcription ne suffit pas Une transcription de conversation montre ce que l'agent a dit et fait, mais pas nécessairement ce qu'il a vu au moment de décider. Si un outil de recherche a renvoyé des résultats différents entre le moment de l'incident et une tentative de rejeu ultérieure, la transcription seule ne permet pas de distinguer un problème de raisonnement du modèle d'un simple changement de données sous-jacentes. ## Les quatre éléments à figer Un rejeu réellement fidèle repose sur quatre éléments distincts, chacun couvrant une source de variation différente. > L'essentiel à retenir : Un rejeu fidèle exige de figer la version du modèle utilisée, pas seulement son nom ; La graine seule ne suffit pas si les appels d'outils ne sont pas horodatés dans l'ordre exact ; Un rejeu approximatif donne une fausse confiance, pire qu'aucun rejeu du tout ``` journal-session/ ├── contexte.json # graine, identifiant exact de version du modèle ├── prompt-systeme.txt # version exacte du prompt système au moment T ├── appels-outils.jsonl # un appel par ligne, horodaté à la milliseconde │ ├── { "t": "...", "outil": "rechercher_stock", "entree": {...}, "sortie": {...} } │ └── { "t": "...", "outil": "creer_commande", "entree": {...}, "sortie": {...} } └── reponses-modele.jsonl # chaque réponse brute du modèle, avant post-traitement ``` ### La graine et l'identifiant exact du modèle Le nom commercial d'un modèle ne suffit pas : deux appels au même nom de modèle peuvent correspondre à deux versions internes différentes si le fournisseur a mis à jour son service entre-temps. Seul un identifiant de version explicite, quand le fournisseur en expose un, garantit qu'un rejeu utilise réellement la même version. ### Le prompt système, dans sa version exacte du moment Un prompt système versionné séparément du code applicatif change parfois plus souvent que les déploiements eux-mêmes. Le journal doit conserver la version exacte utilisée au moment de l'incident, pas seulement une référence vers la version actuelle du fichier, qui peut avoir changé depuis. ### L'horodatage précis de chaque appel d'outil L'ordre dans lequel l'agent a appelé ses outils, et le délai entre chaque appel, influence parfois la décision suivante, en particulier si un outil externe renvoie un état qui évolue avec le temps (un stock, une file d'attente). Un horodatage à la milliseconde, conservé pour chaque appel, permet de vérifier si un rejeu produit le même enchaînement ou diverge dès le deuxième appel. ### La sortie brute de chaque outil, pas seulement son résumé Si un outil externe est rappelé lors du rejeu, il peut légitimement renvoyer une réponse différente de celle du jour de l'incident. Conserver la sortie brute obtenue à l'époque, en plus de l'appel lui-même, permet de rejouer le raisonnement du modèle sur des données figées, sans dépendre de la stabilité de systèmes externes qu'on ne maîtrise pas. - Identifiant exact de version du modèle, jamais seulement son nom commercial. - Version figée du prompt système au moment de la session concernée. - Horodatage à la milliseconde de chaque appel d'outil, dans l'ordre réel d'exécution. - Sortie brute de chaque outil, conservée telle quelle, indépendamment de sa disponibilité future. > Un rejeu qui ignore l'un de ces quatre éléments ne rejoue rien : il rejoue une approximation, et une approximation qui semble concluante est plus dangereuse qu'une absence de rejeu assumée comme telle. ## Ce que cette architecture coûte en pratique Journaliser ces quatre éléments pour chaque session alourdit sensiblement le volume de données conservées, en particulier la sortie brute des outils lorsque les réponses sont volumineuses. Sur les projets où cette architecture a été mise en place, seules les sessions ayant déclenché une action jugée sensible (écriture, paiement, envoi externe) conservent l'intégralité de ces quatre éléments ; les sessions de simple consultation se contentent d'un journal allégé, sans sortie brute complète. ## En résumé Reconstituer fidèlement une session d'agent après un incident suppose de figer, au moment même de l'exécution, quatre éléments qu'on ne peut plus retrouver après coup si l'un d'eux manque : la version exacte du modèle, la version exacte du prompt système, l'horodatage précis de chaque appel d'outil, et la sortie brute obtenue à ce moment-là. Cette architecture se met en place avant l'incident, jamais après.