Anthropic a publié le 18 août 2026 un retour d’expérience sur l’utilisation de Claude comme premier répondant lors d’incidents CI/CD. L’entreprise annonce des rapports initiaux généralement produits en moins de quinze minutes. Au-delà des chiffres, le cas est intéressant parce qu’il décrit une architecture reproductible : accès en lecture seule, outils contrôlés, mémoire versionnée et validation humaine avant toute modification.
1. Ce que le retour d’expérience affirme
Anthropic décrit un agent nommé Claude Tag utilisé comme premier répondant pour des incidents liés à l’intégration et au déploiement continus. Selon les données internes publiées, l’agent a produit le premier rapport de situation dans chaque incident récent qui en possédait un, généralement dans les quinze minutes. La médiane annoncée pour une analyse fondée sur des preuves est de quatorze minutes et, dans les cas les plus rapides, une cause racine a été identifiée en quatre minutes.
Ces résultats proviennent de l’environnement d’Anthropic et ne constituent pas un benchmark indépendant. Ils montrent néanmoins qu’une partie du travail initial d’astreinte peut être structurée : rassembler les signaux, formuler des hypothèses, citer les éléments observés et préparer une transmission.
2. Le bon rôle pour un agent d’astreinte
Le premier objectif n’est pas de remplacer l’ingénieur d’astreinte. Il est de réduire le temps perdu à ouvrir plusieurs outils, recouper des horaires et reconstruire le contexte d’un changement.
Un agent bien conçu peut récupérer les alertes, déploiements récents, erreurs, traces et discussions associées. Il peut ensuite proposer une chronologie, les services affectés, les hypothèses et les prochaines vérifications. L’humain conserve la décision, notamment lorsqu’une action peut aggraver l’incident.
Cette répartition est cohérente avec le principe de validation humaine des systèmes IA : automatiser la collecte et la synthèse, mais maintenir une responsabilité claire sur les actes à fort impact.
3. Une architecture en deux temps
Le modèle décrit sépare le déclenchement déterministe de l’investigation agentique. Les alertes et règles classiques détectent un état connu : échec de pipeline, taux d’erreur, délai ou saturation. Elles lancent ensuite l’agent avec un périmètre et un identifiant d’incident.
Un orchestrateur peut déléguer plusieurs pistes à des sous-agents : analyser les métriques, examiner les changements Git, lire les événements Kubernetes ou retrouver des incidents similaires. Chaque résultat doit conserver les références qui permettent à l’ingénieur de le vérifier.
Cette séparation est essentielle. Le système de monitoring reste responsable de la détection et des seuils. Le modèle intervient dans la recherche, l’interprétation et la communication, là où les règles rigides atteignent leurs limites.
4. Pourquoi commencer en lecture seule
Anthropic fournit un kit de démarrage créant un rôle initial en lecture seule. C’est la bonne approche pour un premier déploiement. Un agent capable de consulter les métriques et journaux apporte déjà de la valeur sans pouvoir arrêter un service ou modifier une configuration.
Le kit public est présenté sans auto-remédiation : les humains décident des actions et les déploient. Le système interne décrit par Anthropic comprend aussi un agent distinct pouvant gérer des déploiements progressifs derrière des feature flags ; cette capacité ne doit pas être confondue avec le périmètre initial du kit.
Les droits doivent être attribués par outil et par environnement. Lire les événements d’un cluster de test ne justifie pas l’accès aux secrets de production. Consulter une pull request ne nécessite pas le droit de la fusionner.
Chaque requête doit être journalisée avec l’identité de l’agent, l’incident, l’outil, la portée et le résultat. Les identifiants temporaires et les jetons de courte durée limitent l’impact d’une fuite.
5. L’accès aux outils via MCP
Le retour d’expérience mentionne l’accès à Datadog ou Grafana, PagerDuty, GitHub, Kubernetes et Slack via MCP. Le protocole facilite une interface commune, mais il ne constitue pas en lui-même un contrôle de sécurité.
Chaque serveur MCP doit exposer un sous-ensemble explicite d’actions, valider les paramètres et appliquer les droits côté service. Il faut éviter les outils génériques de type “exécuter une commande arbitraire” ou “faire une requête libre” lorsqu’une fonction plus étroite suffit.
Les réponses des outils doivent être considérées comme des données non fiables. Un message Slack ou un nom de branche peut contenir du texte conçu pour détourner l’agent. Le modèle ne doit jamais transformer une instruction trouvée dans une source en autorisation d’action.
6. Mémoire, instructions et apprentissage
Anthropic décrit une mémoire alimentée par Slack, des instructions permanentes en Markdown versionnées dans Git et un fichier de leçons tirées des incidents précédents. Cette organisation est préférable à un prompt opaque modifié dans une interface.
Les instructions doivent préciser l’ordre des vérifications, les sources fiables, le format du rapport, les seuils d’escalade et les actions interdites. Toute modification passe par une revue de code et peut être reliée à un incident précis.
La mémoire doit être filtrée. Un postmortem contient parfois des secrets, des données personnelles ou des hypothèses devenues fausses. Conservez des résumés validés et une date de péremption plutôt qu’un accès illimité à toutes les conversations historiques.
7. Les garde-fous avant une action
Lorsqu’un pilote en lecture seule est maîtrisé, certaines actions réversibles peuvent être proposées : ouvrir un ticket, préparer une pull request, relancer un job non destructif ou générer une commande à valider.
La correction décrite par Anthropic reste revue, fusionnée et déployée par l’ingénieur d’astreinte. Cette frontière doit être explicite dans l’interface. Un bouton de validation ne suffit pas si l’utilisateur ne comprend pas précisément les effets.
Pour une action automatique, exigez au minimum une politique déterministe, une portée limitée, un journal signé, un délai, une condition de retour arrière et une preuve de vérification après exécution.
8. Un plan de déploiement en quatre phases
La phase 1 est hors ligne : rejouez des incidents clos et comparez le rapport de l’agent au postmortem. La phase 2 est l’observation en temps réel, sans notification opérationnelle. La phase 3 ouvre le rapport à l’astreinte, toujours en lecture seule. La phase 4 autorise quelques actions préparatoires ou réversibles.
À chaque étape, définissez des critères de passage : taux de citations correctes, absence d’accès hors périmètre, temps de réponse, qualité des hypothèses et charge de vérification humaine.
Ne sautez pas directement à la remédiation automatique. L’incident est précisément le moment où le contexte est incomplet, les systèmes dégradés et les erreurs coûteuses.
9. Les indicateurs à suivre
Mesurez le temps jusqu’au premier rapport utile, le temps jusqu’à la cause racine, la précision des faits, le nombre d’hypothèses réfutées et le temps de revue humaine. Suivez aussi les incidents où l’agent n’a apporté aucune valeur.
Un bon système doit réduire le délai de compréhension sans augmenter le risque. Le taux de “bon diagnostic” seul est insuffisant : une analyse correcte mais non sourcée peut être impossible à utiliser sous pression.
L’expérience publiée par Anthropic montre une direction crédible pour l’infogérance et le SRE. Sa transposition exige cependant une architecture de permissions, des outils étroits et une progression mesurée.
Partitech peut accompagner la mise en place d’un assistant d’astreinte : intégration aux outils, rôles en lecture seule, jeux de replay, tableaux de bord, validation humaine et procédure de retour arrière.