Agent d'investigation de tickets support : le pattern de John Yeo qu'on peut reproduire

La plupart des équipes ops traitent l’investigation automatisée de tickets comme une fonctionnalité du futur, quelque chose qu’on pourra peut-être faire quand les agents seront plus mûrs. John Yeo vient de publier la recette qui montre que c’est déjà buildable aujourd’hui, et qu’elle tient en trois ingrédients : des logs structurés et requêtables, des skills Claude Code qui encodent la connaissance par domaine d’investigation, et un MCP qui pointe l’agent vers le système d’observabilité. Le ticket arrive, l’agent investigue seul, et l’ingénieur reçoit la racine de cause avec, quand le pattern est bien câblé, un fix proposé. Ce n’est pas de la science-fiction. C’est trois composants qu’un dev backend peut assembler en deux semaines, et la majeure partie du travail est dans le premier ingrédient.

Le post de Yeo mérite d’être lu pour ce qu’il documente. Voici ma lecture pratique de ce qu’il faut faire pour reproduire, et des deux pièges qu’il signale et qu’on aurait découverts seul à ses dépens.

Trois ingrédients, dans cet ordre

L’erreur commune quand on aborde cette catégorie de problème est de commencer par l’agent. Yeo commence par les logs. C’est l’ordre correct.

Ingrédient 1, Logs requêtables. L’agent ne peut pas investiguer ce qu’il ne peut pas requêter. Si vos logs sont des chaînes de texte non structurées, des stack traces sans contexte, ou des événements éparpillés dans plusieurs systèmes, aucun MCP ne va sauver l’investigation. Cet ingrédient est aussi le plus coûteux à réparer rétrospectivement, et c’est ce qui fait que la majorité des équipes ne franchissent jamais l’étape 2.

Ingrédient 2, Skills par domaine d’investigation. Une fois les logs disponibles, l’agent doit savoir où regarder pour quoi. Un skill par domaine, billing, webhooks Stripe, entitlements, auth, etc., qui décrit comment ce sous-système fonctionne sous le capot et quelles queries sont pertinentes pour quelles symptômes. C’est la couche de jugement qui transforme l’agent générique en investigateur expert.

Ingrédient 3, MCP qui expose les logs. Le serveur MCP, ici Axiom dans le cas de Yeo, est la plomberie qui connecte l’agent aux logs. C’est l’ingrédient le plus simple parce qu’il existe déjà, la plupart des grandes plateformes d’observabilité shipped maintenant leur MCP officiel ou communautaire.

Les trois ingrédients sont nécessaires mais asymétriques en coût. L’ordre dans lequel on les construit détermine si le projet aboutit ou s’enlise.

Logs structurés : la condition préalable, et le geste qui les rend utiles

Le bon logging n’est pas une question de quantité mais de forme. Le principe que Yeo documente, et qu’il appelle wide logging, tient en deux règles.

Logs centrés sur la requête. Chaque appel API émet un seul payload JSON à la fin, qui agrège tout ce qui s’est passé pendant la requête. Pas dix lignes éparpillées. Une ligne par requête, riche, qui porte le contexte tenant, le body request/response, les timestamps, l’auth, la version d’API. Un middleware enrichit le logger à chaque étape :

ctx.logger = addAppContextToLogs({
  logger: ctx.logger,
  appContext: {
    org_id: ctx.org?.id,
    customer_id: ctx.customerId,
    env: ctx.env,
    api_version: ctx.apiVersion?.semver,
    ...
  },
});

Le résultat : chaque investigation commence par un filtre org_id = X AND customer_id = Y et arrive en une seconde sur les vingt-quarante lignes de log qui décrivent l’incident. Le réflexe, souvent évident une fois posé, mais qu’on oublie en pratique, c’est que le contexte tenant est de très loin le filtre le plus utile et le point de départ de la majorité des enquêtes. C’est l’ajout qui rentabilise le plus tôt.

Un champ extras append-only. Pour chaque endpoint, on enrichit la requête au fur et à mesure qu’elle se déroule. Pas juste “j’ai fait ça”, l’état au moment précis où la décision a été prise. Sur un upgrade : quel plan sortant, quel plan entrant, est-ce qu’il y avait une cancellation programmée, quel est le timing de facturation choisi. Ces champs deviennent les indices que l’agent assemble pour reconstruire un timeline cohérent. Sans cette discipline, l’agent reçoit du bruit ; avec elle, il reçoit du signal.

C’est aussi pour ça que le journal d’audit reste la fonctionnalité de sécurité IA la plus sous-estimée, la même règle de discipline structurelle, appliquée au domaine de la sécurité, produit les mêmes gains pour l’investigation post-incident humain ou agentique.

Skills par domaine : la couche de jugement qui transforme l’agent

Le second ingrédient est l’endroit où la majorité des tentatives échouent silencieusement. Un agent générique branché sur les logs peut investiguer, mais pas efficacement. Il lui manque la connaissance du domaine : que signifie un certain pattern de webhooks Stripe ratés ? Comment fonctionne le cache d’entitlements de votre stack ? Quelles queries Axiom révèlent quels symptômes ?

Yeo nomme un point qui mérite d’être entendu directement : “these skills were written very intentionally. We’ve tried one-shotting these skills before but they were never effective.” La discipline pour les écrire, une demi-journée par domaine, à itérer avec Claude, à lui montrer comment vous investigueriez personnellement, quels filtres vous appliqueriez, comment vous reconnaissez tel symptôme, est ce qui sépare un skill utile d’un skill qui reste dormant.

C’est le même principe que j’avais isolé dans MiniGun : la valeur d’un skill ne vient pas de la liste d’outils qu’il expose, elle vient du jugement qu’il encode, quand procéder, quand demander confirmation, quand pousser back. Pour l’investigation de tickets, le jugement encode comment vous pensez quand vous investigez ce domaine. Si vous n’avez jamais formalisé ce processus en écrit, écrire le skill est en soi un exercice de clarification qui améliore votre propre pratique.

C’est aussi ce que j’avais posé comme principe général sur les skills : un skill utile montre la forme attendue par exemples positifs, pas par interdits. Pour un domaine d’investigation, ça veut dire : “voici une session d’investigation type sur un cas de cancellation+upgrade”, pas “ne fais pas X”.

Local vs cloud : un écart de qualité qu’il faut anticiper

C’est l’avertissement que Yeo livre sans détour, et qui vaut la peine d’être pris au sérieux avant de promettre quoi que ce soit à son équipe.

L’investigation tourne très bien en local, Claude Code branché sur Axiom MCP et les skills bien écrits, on lit le ticket, l’agent investigue, propose un fix. C’est buildable. Mais quand on déplace cette même architecture en cloud, pour automatiser le déclenchement à l’arrivée d’un ticket, la qualité chute notablement. Yeo le dit en termes mesurés : “MCP auth is flaky, skills don’t seem to trigger correctly, and the overall understanding of our codebase feels noticeably worse.”

C’est l’écart qu’il faut concevoir d’avance. Deux conséquences pratiques :

D’abord, l’auto-investigation cloud ne remplace pas l’investigation locale. Elle fait un premier passage, le poste dans Slack, et l’humain, ou l’humain lançant une session Claude Code locale, reprend la main pour les cas non triviaux. C’est un triage automatisé, pas une délégation complète.

Ensuite, ne pas dimensionner les attentes de l’équipe sur la démo locale. Une démo qui marche parfaitement sur un poste de dev produira un système de production qui rate un tiers des cas. C’est une régression structurelle, pas un bug, et il vaut mieux la nommer avant que l’équipe ne s’en rende compte à ses dépens.

Slack comme interface : utile pour le triage, clunky pour l’enquête profonde

Yeo nomme aussi la limite ergonomique. Quand l’investigation se fait via une conversation Slack, “the slack interface just feels kinda clunky. There are a lot of features which aren’t quite optimised, like agent thinking, tool calling, etc. At some point, the overhead of continuing an investigation over Slack becomes higher than just opening a new Claude Code session locally.”

C’est une observation honnête qui mérite d’être absorbée. Slack est excellent pour notifier, “voici la racine de cause probable, voici un PR proposé”. Slack est mauvais pour itérer, la pensée d’agent, le tool-calling, les diff de code passent mal dans une conversation. Le bon design ergonomique, c’est : agent investigue, agent poste un résumé Slack avec un lien vers une session Claude Code pré-configurée, ingénieur clique et continue en local.

C’est exactement la direction que Yeo entrevoit : “the future would be about exposing functionality to existing harnesses like Claude Code or Codex, rather than rebuilding those interaction patterns from scratch.” Le harness existe ; il faut juste lui transmettre le contexte au bon moment.

La recette buildable, en cinq étapes

Pour qui veut reproduire ce pattern dans sa propre stack, et c’est largement à votre portée si vous avez un système de logs et une équipe support active, voici l’ordre que je suggérerais.

Auditer la structure de vos logs. Sont-ils requêtables par tenant ? Portent-ils l’état métier au moment de chaque décision ? Si non, c’est l’étape 1 et elle prend une semaine. Pas de skill ni de MCP ne vous sauve d’une dette de logging mal posée.
Câbler le MCP de votre plateforme d’observabilité. Axiom, Datadog, Honeycomb, Grafana, la plupart ont un MCP officiel ou communautaire. Si la vôtre n’en a pas, en écrire un de base prend un après-midi.
Écrire le premier skill, sur le domaine où vous recevez le plus de tickets. Une demi-journée minimum. Pas one-shot. Itérez avec Claude, montrez-lui une vraie investigation de bout en bout. Faites tourner le skill sur cinq cas réels, raffinez.
Tester en local avant le cloud. Sur cinquante tickets archivés, mesurez le taux de fois où l’agent arrive à la bonne racine de cause. C’est votre plafond. Le cloud sera en dessous.
Déployer en cloud comme triage, pas comme remplacement. L’agent fait le premier passage, l’humain garde la décision. Reprendre la main en local pour les cas complexes via une session Claude Code que l’agent cloud a pré-câblée.

C’est exactement l’esprit dont je parlais avec les petites boucles d’agent qui composent un trimestre : on n’attend pas l’agent universel autonome ; on construit le pipeline pour le domaine où la valeur est la plus claire, on le tient, et il finit par cumuler.

Si cela vous a parlé, vous aimerez Écrire des skills que votre agent de code utilisera vraiment et MiniGun de Ran Aroussi : la vraie innovation, c’est le skill qui apprend au modèle quand dire non. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.