Maintenir : boucler sur les métriques

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Détecter les écarts de production de façon déterministe, avec des bandes de contrôle
• Graduer ce que Claude a le droit de faire selon la gravité de l’écart
• Transformer un écart en nouvel intent.md qui relance le cycle

Ce qui change

Traditionnellement, la maintenance est réactive : tickets et incidents attendent qu’une personne agisse. Une alerte à 3 heures du matin peut être manquée, un ticket peut dormir dans le backlog, et les actions décidées en post-mortem n’atteignent pas toujours le code si un autre incendie se déclare.

Dans un cycle AI-native, un script déterministe surveille la production et fait appel à Claude quand une bande de contrôle est franchie. Claude diagnostique, puis produit un intent.md qui reprend le cycle depuis l’étape 1 : besoins, plan, construction, tests, revue. Les humains trient et relisent ce travail ; ils n’ont plus à le lancer.

Ce qu’est une bande de contrôle

Une bande de contrôle est un intervalle autour du niveau normal d’une métrique. Le script prend comme référence la moyenne des 30 derniers jours de relevés horaires, et calcule l’écart-type, noté σ (sigma), qui mesure de combien les relevés s’écartent habituellement de la moyenne. La bande 1σ s’arrête à la moyenne plus un σ, la bande 2σ à la moyenne plus deux σ, et ainsi de suite.

Pour une métrique stable dont les relevés suivent une loi normale, environ un relevé sur six dépasse 1σ, un sur 44 dépasse 2σ, et un sur 740 dépasse 3σ. Avec 720 relevés par mois, le hasard seul place donc environ quatre relevés par jour au-dessus de 1σ, seize par mois au-dessus de 2σ et un par mois au-dessus de 3σ. D’où la gradation : à 1σ on se contente de journaliser, et même le palier 3σ, que le bruit déclenche environ une fois par mois, reste cantonné à des actions encadrées.

Les règles de Western Electric, issues d’un manuel de contrôle qualité de 1956, repèrent aussi une dérive lente qui ne franchit jamais 3σ : par exemple quatre des cinq derniers relevés au-dessus de 1σ, ou huit relevés d’affilée au-dessus de la moyenne.

Pour démarrer

• Prérequis : intent.md (leçon 2), qui donne à la boucle une sortie structurée ; la revue par l’IA (leçon 10) ; les hooks comme frontière d’action (leçon 11) ; un chemin de retour arrière éprouvé en CI/CD (leçon 12).
• Infrastructure : un entrepôt de métriques interrogeable par le script (Prometheus, l’API de la CI, ou équivalent), un accès en lecture au dépôt, et un moyen d’exécuter Claude Code en mode non interactif en CI, ou l’Agent SDK pour un service qui reçoit des webhooks.

Mise en œuvre

1. Le responsable du service choisit une métrique à référence stable : taux d’échec des tests en CI, taux d’erreurs 5xx après déploiement, ou durée de cycle des pull requests.
2. Il écrit le script de détection — moyenne et écart-type sur une fenêtre glissante, plus des règles de dérive. Le script est versionné et testé ; la détection reste entièrement déterministe, sans modèle.
3. Il associe une action à chaque palier :

4. Le déclencheur peut être une tâche planifiée dans GitHub ou GitLab, un webhook de la supervision existante, ou une tâche cron dans le réseau. Claude s’exécute sans état, en tâche non interactive ou en service Agent SDK dans un conteneur isolé : la boucle peut commencer et finir sans que personne ne la lance.
5. Claude rédige un intent.md au format de l’étape 1 : l’anomalie et ses preuves, un résultat proposé, les systèmes touchés, les questions ouvertes. Le constat suit ensuite le cycle comme n’importe quelle intention.
6. Le responsable du service ou l’astreinte trie la file : corriger maintenant, planifier, ou écarter ; les écarts écartés servent à ajuster les bandes et à réduire le bruit.
7. Quand un correctif est livré, ajoutez une évaluation pour l’incident (leçon 9), pour qu’il ne puisse pas revenir sans être détecté.

Le travail qui arrive par d’autres canaux

Tout ne vient pas d’une métrique : des demandes et des signalements arrivent aussi dans les canaux de discussion de l’équipe. Avec Claude Tag, en bêta publique, Claude travaille dans les canaux Slack de l’équipe : il peut trier ces demandes et en faire, lui aussi, des intentions qui entrent dans le cycle.

Gouvernance et mesure

Chaque palier a son plafond d’autonomie, imposé par les hooks et les permissions : lecture seule pour diagnostiquer, pull request ou procédure approuvée pour agir. Chaque déclenchement, diagnostic et proposition est tracé.

• Indicateur avancé : le délai entre le franchissement d’une bande et l’intent.md enregistré.
• Indicateur retardé : le délai de rétablissement, et la part des incidents détectés par la boucle avant qu’un utilisateur ne les signale.

À vous de jouer

Une métrique, trois paliers. Choisissez une métrique stable, par exemple le taux d’échec des tests en CI. Calculez sa moyenne et son écart-type sur trente jours de relevés horaires, puis comptez les relevés au-dessus de 1σ, 2σ et 3σ : sont-ils proches de ce que prévoit la loi normale ? Écrivez l’action de chaque palier, ce que Claude a le droit de faire à chacun, et vérifiez que le retour arrière existe et a été répété.

Sources officielles : Closing the loop on metrics (Claude Academy) · The AI-native SDLC playbook — Stage 6: Maintain · Agent SDK overview · Introducing Claude Tag

Points clés à retenir

• Une détection déterministe, sans modèle, sur des bandes de contrôle autour d’une référence glissante
• Des paliers gradués : journaliser à 1σ, diagnostiquer en lecture seule à 2σ, proposer par PR ou procédure approuvée à 3σ
• La sortie est un intent.md qui relance tout le cycle ; les humains trient au lieu de lancer
• Chaque incident corrigé devient une évaluation