Débugger un incident de prod avec un agent : ce qui change, ce qui ne change pas

Dans les articles sur le heap dump et le thread dump, j'insistais sur une discipline précise : ne jamais conclure sur une seule mesure, toujours comparer plusieurs dumps espacés dans le temps. Depuis que je débugue une partie de mes incidents avec un agent plutôt qu'en lisant les dumps à la main, cette discipline est justement ce qui ne bouge pas. Ce qui bouge, c'est tout ce qu'il y a autour.

Ce qu'un agent fait mieux, et plus vite#

Lire un dump brut et le corréler avec le code source, c'est exactement le type de reconnaissance de motifs où un agent excelle. Coller le bloc « Found one Java-level deadlock » de l'article sur le thread dump, avec accès au repo, et l'agent identifie l'ordre d'acquisition des verrous incohérent, cite la ligne exacte dans Account.transfer, et propose la correction (verrouiller systématiquement le compte à l'identifiant le plus petit) sans que j'aie besoin de faire l'aller-retour dump-code moi-même.

Tâche	Avant, à la main	Avec un agent
Repérer le dominateur dans un rapport MAT	Parcourir l'arbre manuellement, trier par retained size	Coller le rapport « Leak Suspects », l'agent pointe directement le champ responsable et le chemin vers les GC roots
Corréler un thread bloqué avec le code	Chercher la ligne exacte dans le repo à partir de la stack trace	L'agent a déjà accès au repo, fait le lien stack trace/code en un seul aller
Rédiger le post-mortem	30 à 45 minutes de rédaction après coup	Premier jet généré directement à partir des dumps et des commandes exécutées pendant l'incident

Ce gain est réel, mais il porte sur la vitesse de lecture, pas sur la qualité du diagnostic. C'est là que la distinction devient importante.

Ce qui ne change pas : la discipline de la preuve#

Un agent auquel on demande d'expliquer un dump produit un récit plausible aussi facilement à partir d'un seul cliché qu'à partir de trois mesures espacées dans le temps. La différence entre les deux, un vrai signal de fuite mémoire contre un pic normal qui redescend après un GC complet, ne saute pas aux yeux d'un modèle de langage plus qu'à un humain pressé. C'est une discipline qui doit être imposée depuis l'extérieur : demander explicitement plusieurs dumps avant toute conclusion, jamais la laisser à l'appréciation du modèle.

Le principe est le même que celui décrit dans l'article sur l'audit d'architecture avec un agent : un agent ne doit jamais être la source d'un fait, seulement le rédacteur d'une synthèse à partir de faits produits par un outil déterministe. Sur un incident, ça se traduit par une règle simple à faire respecter dans le prompt ou dans un hook : toute conclusion doit citer une ligne précise d'un dump ou d'un log précis, jamais une affirmation sans pointeur vers la preuve brute qui la soutient.

Ce qui ne change pas non plus : l'accès en production#

La tentation, en plein incident, est de donner à l'agent un accès direct au serveur pour qu'il génère et lise les dumps lui-même. C'est exactement le mauvais moment pour tester les limites d'un accès non restreint : un incident de production n'est jamais l'endroit où on découvre qu'un hook mal configuré (voir agent, harnais, skills, hooks) laisse l'agent exécuter une commande qu'on n'aurait pas validée à froid. La pratique qui tient, c'est d'exporter les dumps et les logs vers un espace de travail que l'agent peut lire, et de garder toute commande qui modifie l'état du système en dehors de sa portée pendant l'incident lui-même. Le schéma résume le circuit complet, avec la boucle de vérification et la frontière d'accès :

Un exemple concret#

Reprenons le cas du cache qui ne s'arrête jamais de grandir, déjà décrit dans l'article sur le heap dump. Un agent auquel on colle le rapport « Leak Suspects » identifie en quelques secondes le HashMap statique sans politique d'expiration, et propose la correction avec Caffeine. Ce qu'il ne fait pas tout seul, c'est vérifier que le plancher mémoire (la consommation juste après un GC complet) augmente réellement d'un dump à l'autre plutôt que d'être un pic isolé lié à un trafic ponctuel. Cette vérification reste une étape que je dois demander explicitement, avec un deuxième dump pris plus tard, avant d'accepter la conclusion.

Ce que ça change concrètement#

Le gain net, c'est le temps entre l'incident et la première hypothèse solide : ce qui prenait vingt minutes de lecture de dump prend maintenant deux minutes de synthèse. Les deux choses qui empêchent réellement un post-mortem erroné, la mesure répétée dans le temps et la citation d'une preuve brute plutôt qu'un récit plausible, ne viennent pas automatiquement avec l'agent. Elles restent une discipline à concevoir dans le processus, exactement comme avant, juste appliquée à un collaborateur qui lit plus vite qu'on ne pourrait le faire soi-même.