Refermer la boucle sur les métriques

Alors que chaque étape précédente nécessite qu'une personne la déclenche, l'étape 6 déplace l'attention vers l'exécution autonome de Claude pour refermer la boucle. Par exemple, un agent de surveillance fonctionnant en continu pourrait, à la suite de la création d'un ticket de bug, créer un intent.md, puis traverser les phases d'exigences, de planification, de construction, de test et de revue. Étape 6 : Maintenir s'exécute en mode headless, avec une porte de confiance indépendante entre les étapes, une vérification déterministe ou un agent de revue adversarial, qui décide si le résultat de l'étape précédente se poursuit ou est escaladé vers un humain.

Ce qui change

Un script déterministe surveille la production et invoque Claude lorsqu'une bande de contrôle est dépassée. La surveillance d'un dépassement est un exemple utile du schéma pour la boucle fonctionnant de manière autonome, tandis que la section Claude Tag (bêta publique) à la fin de l'étape couvre le travail arrivant par différents canaux.

Ce qu'est une bande de contrôle

Une bande de contrôle est une plage autour du niveau normal d'une métrique, que le script de détection considère comme la moyenne des relevés horaires des 30 derniers jours. Le script calcule également sigma (σ), l'écart type, c'est-à-dire à quel point les relevés s'écartent habituellement de la moyenne. La bande 1σ se termine à la moyenne plus un σ, la bande 2σ à la moyenne plus deux, et ainsi de suite.

Si les relevés d'une métrique stable suivent une courbe en cloche, environ un sur six se situe au-dessus de 1σ, un sur 44 au-dessus de 2σ, et un sur 740 au-dessus de 3σ. Avec 720 relevés par mois, le hasard seul place environ quatre par jour au-dessus de 1σ, 16 par mois au-dessus de 2σ, et un par mois au-dessus de 3σ. C'est pourquoi le niveau 1σ se contente de consigner, et pourquoi même le niveau 3σ, que le bruit seul déclencherait environ une fois par mois, est limité à des voies contrôlées.

Les règles Western Electric, issues d'un manuel de contrôle qualité de 1956, détectent une dérive lente qui pourrait ne jamais franchir 3σ. Elles signalent quatre des cinq derniers relevés au-dessus de 1σ, ou huit relevés consécutifs au-dessus de la moyenne.

Pour commencer

• Prérequis : intent.md, qui donne à la boucle une sortie structurée pour redémarrer. Les revues de PR accélérées par Claude, les hooks comme limite d'action, et un chemin de retour en arrière pour le CI/CD (que le niveau d'autonomie le plus élevé invoque).
• Infrastructure : Un magasin de métriques que le script de détection peut interroger (Prometheus, l'API du système CI, ou équivalents), un accès en lecture au dépôt, un moyen d'exécuter Claude Code de manière non interactive en CI, ou le Agent SDK pour un service qui reçoit des webhooks.

Comment l'exécuter

1. Le propriétaire du service ou l'ingénieur plateforme choisit une métrique avec une référence glissante stable, telle que le taux d'échec des tests CI, le taux d'erreurs 5xx post-déploiement, ou le temps de cycle des PR.
2. Ils écrivent le script de détection, généralement la moyenne et l'écart type sur une fenêtre glissante avec des règles (Western Electric ou similaires) afin que les bandes détectent aussi bien les dérives lentes que les pics. Le script est versionné et testé unitairement, et la détection reste entièrement déterministe, sans aucun modèle impliqué.
3. Les niveaux de réponse sont définis dans une configuration versionnée (bands.yaml ci-dessous). À 1σ, le script se contente de consigner, à 2σ il invoque Claude en lecture seule pour diagnostiquer, et à 3σ Claude peut agir, mais uniquement en ouvrant une PR vers la porte de revue ou en déclenchant un runbook pré-approuvé. Une règle de dérive compte comme 2σ.
4. La couche de déclenchement peut être un workflow planifié dans GitHub ou GitLab, un webhook provenant de la pile de surveillance existante, ou une tâche cron à l'intérieur du réseau. Claude s'exécute sans état, soit comme une étape non interactive sur un exécuteur CI, soit comme un service Agent SDK dans un conteneur en bac à sable, et le guide CI/CD couvre les options de déploiement et d'accès au modèle. Parce que l'exécution est sans état et non interactive, une boucle peut commencer et se terminer sans que personne ne la déclenche.
5. L'agent rédige son diagnostic sous forme d'intent.md au format de l'Étape 1 : Planifier, couvrant l'anomalie et ses preuves, un résultat proposé, les systèmes affectés, et toute question en suspens. À partir de là, la découverte traverse le pipeline comme n'importe quel autre élément.
6. Le propriétaire du service ou l'ingénieur de garde trie la file d'attente, en acheminant les découvertes orientées produit vers le propriétaire du produit. Corriger maintenant, planifier, ou rejeter. Les rejets ajustent les bandes et aident à réduire le bruit.
7. Lorsqu'un correctif est déployé, ajoutez une évaluation pour l'incident (le guide des évaluations continues) afin de garantir que de tels problèmes soient protégés à l'avenir.

À quoi cela ressemble

Par exemple, un bands.yaml surveillant le taux d'échec des tests CI :

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

Le reste de cet exemple applique le même fichier à une métrique de production, et seule la première ligne change, vers metric: status_5xx_rate. Cette métrique est le taux d'erreurs 5xx sur le point de terminaison de statut de sinistre d'un assureur.

La tâche planifiée qui exécute le script chaque heure recherche le niveau affiché dans bands.yaml et démarre Claude avec les outils ou voies de ce niveau. Pour le niveau propose, cela signifie une liste d'autorisation contenant gh pr create et la seule commande qui déclenche le runbook.

Les clients voient le statut de leur sinistre dans un panneau du portail, et le panneau met en cache chaque réponse pendant 60 secondes. Supposons qu'une mise en production à 13 h 52 ramène ce cache à zéro.

Chaque affichage de page atteint désormais claims-core, l'ancien système derrière le point de terminaison. Il autorise 50 requêtes par seconde et commence à les refuser. À 14 h 00, le script affiche :

{"tier": "3sigma", "rule": "reading above 3 sigma", "reading": 1.9, "mean": 0.2, "sigma": 0.02}

Le niveau 3σ correspond à propose, qui limite l'agent aux deux voies listées. Une mise en production a eu lieu quelques minutes avant le dépassement, donc l'agent exécute le runbook rollback-deploy, qui avait été approuvé au préalable. Il consigne ensuite ce qu'il a trouvé sous forme d'intent.md, dans le même format qu'une personne utiliserait à l'étape 1 :

# Intent: status endpoint 5xx after release 4f2c9e1
Author: monitoring agent (status_5xx_rate, 3 sigma). Status: draft.
## Problem
The 5xx rate on GET /claims/{id}/status read 1.9% at 14:00. The 30-day mean is 0.2%.
Release 4f2c9e1 went out at 13:52. It changes CACHE_SECONDS in StatusPanel.tsx from 60 to 0.
With no cache, every page view reaches claims-core, which allows 50 requests a second (CLAUDE.md).
## Proposed outcome
Customers get fresher status without the portal passing the claims-core limit.
## Affected users and systems
Portal customers, claims-api, claims-core API.
## Constraints
The panel's spec.md allows status to be up to 60 seconds old (R4). The claims-core limit is fixed.
## Action already taken
Ran the rollback-deploy runbook at 14:02. It reported version 8c41d07 live again at 14:04.
## Open questions
Who asked for live status, and is 60 seconds too slow for them?

Lorsque le correctif est déployé, l'incident laisse derrière lui une évaluation, comme à l'étape 7 ci-dessus. L'évaluation fournit à l'agent la requête qui a conduit à l'incident et échoue si le cache a disparu. Dans celle-ci, from est le commit à partir duquel une exécution démarre, et may_change liste les dossiers qu'elle peut toucher :

{
  "name": "status-panel-keeps-its-cache",
  "source": "Incident: status endpoint 5xx after release 4f2c9e1",
  "from": "4f2c9e1~1",
  "prompt": "Customers say the claim status panel feels stale. Make it feel live. Run the tests before you finish.",
  "may_change": ["claims-api/routes", "claims-api/tests", "portal/src"],
  "checks": [
    { "name": "tests pass", "run": "make test" },
    { "name": "lint clean", "run": "make lint" },
    { "name": "panel still caches", "run": "grep -Eq 'CACHE_SECONDS = [1-9]' portal/src/claims/StatusPanel.tsx" }
  ]
}

Considérations de gouvernance

Les limites des niveaux sont appliquées à partir d'une configuration versionnée, avec des permissions et des paramètres gérés refusant l'accès à la production. Les invocations, les découvertes et les décisions de triage sont consignées avec un horodatage. Un propriétaire de service trie et approuve les découvertes, les modifications qui en résultent passent par la porte de revue de PR habituelle, et les runbooks que l'agent peut déclencher ont été approuvés au préalable.

Comment le mesurer

• Indicateur avancé : Le temps entre le dépassement de bande et un intent.md dans la file de triage, comparé à l'ancien temps entre l'incident et l'action post-mortem. Le journal du script de détection contient l'horodatage du dépassement et le niveau de l'incident.
• Indicateur retardé : La part des découvertes qui deviennent des correctifs fusionnés (file de triage comparée à l'historique réel des PR), et les incidents récurrents de la même catégorie, qui devraient diminuer à mesure que les correctifs ajoutent des cas à la suite d'évaluations.

Exemples

• Lorsque le taux d'échec des tests CI dépasse 3σ, l'agent met en quarantaine le test instable ou ouvre une PR de retour en arrière, et la porte de revue décide.
• Lorsque le taux d'erreurs 5xx post-déploiement dépasse 3σ avec un déploiement dans la fenêtre, l'agent déclenche le pipeline de retour en arrière existant.
• Lorsque le temps de cycle des PR déclenche une règle de dérive, l'agent rédige un rapport pour la direction de l'ingénierie, ce qui montre que le harnais fonctionne aussi bien pour les métriques de processus que pour celles de production.

Claude de garde avec Claude Tag

Les incidents peuvent également arriver par d'autres moyens, tels que des applications de communication professionnelle comme Slack ou Microsoft Teams. Un incident peut se présenter sous la forme d'un message Slack à 22 h demandant une correction urgente sur un canal d'incident, et peut désormais être traité immédiatement. Claude Tag (bêta publique actuellement disponible sur Slack) fait de Claude un membre de ces canaux sous sa propre identité, de sorte que chaque nouvel incident dispose d'un premier intervenant et que la réponse elle-même devient partie intégrante de la boucle et de la mémoire pour les incidents futurs.

La conversation et les connaissances institutionnelles restent dans le canal, toute personne présente dans le canal pouvant guider et mettre en œuvre la réponse. Tout membre de l'équipe peut tester des hypothèses, explorer de nouvelles options et enquêter en temps réel, l'historique du canal renforçant l'auditabilité. Grâce à l'accès au MCP, Claude vérifie que la métrique est revenue à sa référence et le confirme dans le fil de discussion, puis consigne le post-mortem dans un fichier de leçons versionné que les enquêtes futures pourront consulter.

Les incidents ne sont pas le seul travail que Claude Tag prend en charge. Mentionné sur un ticket via MCP ou sollicité dans le canal, Claude trie le travail de la même manière. Un correctif petit et bien délimité arrive sous forme de PR via la porte de revue, et tout ce qui est plus important est rédigé sous forme d'intent.md pour l'Étape 1 : Planifier, moment à partir duquel la boucle commence à s'auto-alimenter.