Anthropic a confié l'astreinte de première ligne de son CI/CD interne à Claude Tag. Dans la note publiée le 18 août, deux chiffres résument bien la situation : une fois un ticket d'incident ouvert, Claude produit sa première analyse étayée par des preuves en 14 minutes en médiane ; dans les cas favorables, 4 minutes suffisent pour que le rapport initial pointe déjà la cause racine.
Le contexte qui a motivé cette évolution est énoncé sans détour : le volume de code livré par ingénieur et par trimestre a été multiplié par 8. Avec cette production démultipliée, le nombre absolu d'échecs de build, de tests instables et de rollbacks de déploiement a suivi la même courbe, et chaque diagnostic mobilise souvent plus d'une heure, fréquemment en dehors des heures de travail.
Quelles clés Claude a-t-il en main
Si le système fonctionne, c'est grâce à la configuration des permissions, pas au modèle lui-même. Via des connecteurs MCP, Claude obtient un ensemble d'accès : Grafana et le stockage des logs pour consulter métriques et stack traces, Datadog en complément de la supervision, GitHub pour parcourir les commits, examiner les modifications et ouvrir des PR, Kubernetes pour formuler des recommandations au niveau du cluster, ainsi que PagerDuty et plusieurs canaux Slack pour recevoir les alertes et transmettre ses conclusions. Il dispose de son propre compte de service, dont les actions sont auditables.
La décision de réveiller ou non quelqu'un est directement formulée comme une règle en langage naturel. L'exemple donné dans le billet : un taux d'erreur supérieur à 2 % pendant plus de 5 minutes, en dehors d'une fenêtre de déploiement connue, déclenche l'appel de l'astreinte. Ce type de seuil vivait autrefois dans les fichiers de configuration du système de supervision, et chaque modification devait passer par le processus de release ; formulé en règle lisible par Claude, le coût d'un ajustement se réduit désormais à la modification d'une seule ligne de texte. Outre les alertes automatiques, les membres de l'équipe et la page interne des incidents peuvent aussi déclencher l'astreinte manuellement.
La phase de tri tourne en parallèle
Quand un incident arrive, Claude lance un agent orchestrateur, qui dépêche à son tour plusieurs sous-agents pour examiner en parallèle différentes dépendances : l'un parcourt les logs, l'un compare les commits récents, l'un observe les courbes de métriques. Ce « flux de travail dynamique » produit précisément cette analyse en 14 minutes.
Le jugement s'appuie sur deux types de fichiers. Le premier regroupe des fichiers de compétence (skill files), rédigés comme des manuels d'investigation par type d'incident — l'un d'eux traite spécifiquement du cheminement pour traquer une catégorie de bug particulièrement coriace, sur 617 lignes. Le second est lessons.md, que Claude complète lui-même après chaque incident, pour le consulter en priorité la prochaine fois qu'un schéma similaire se présente. Ces deux types de fichiers résident sur GitHub et suivent le même processus de revue que le code.
L'étape de correction laisse une place à l'humain. Le résultat le plus courant est une PR, dont le déploiement n'est décidé qu'après relecture par un ingénieur ; le déploiement progressif est piloté par des feature flags ; pour ce qui touche au cluster, Claude propose de vider, d'isoler ou de faire monter en charge, mais l'exécution reste tranchée par un humain. Une fois la correction faite, Claude revérifie le correctif avec le même jeu d'outils.
À qui revient le reste du travail
Anthropic réserve explicitement plusieurs tâches aux humains : les améliorations d'architecture à moyen et long terme ; compléter les hypothèses avec Claude en mode partagé, car son jugement n'est pas toujours juste du premier coup et l'intuition humaine doit parfois le recadrer ; le verrou de relecture des PR ; ainsi que le ton de la communication — le format des rapports de statut a dû être retravaillé sur plusieurs itérations avant de convenir à l'équipe, un aspect que l'automatisation n'a pas su absorber.
La passation elle-même a été transformée en produit. Il existe un rapport hebdomadaire consolidé, des résumés quotidiens, et un autre agent baptisé ci-weather qui compile plusieurs incidents en un point de statut visible en externe.
Un calcul facile à négliger
Ce chiffre multiplié par 8 n'a pas le même sens selon qu'on le place du côté du « pourquoi le faire » ou du « ce que ça donne une fois fait ». C'est d'abord la source de la pression : à taille d'équipe égale, si le volume livré est multiplié par 8, le nombre de tickets d'incident ne reste pas stable. Mais c'est aussi la condition qui rend ce système d'astreinte viable — si le code était encore tapé ligne par ligne par des humains, la forme, la fréquence et l'explicabilité des incidents resteraient plus proches de l'intuition des ingénieurs, et le bénéfice marginal du tri par IA serait bien moins net. Une fois que l'IA participe massivement à l'écriture du code, il devient logique, dans la même chaîne, de lui confier aussi le premier niveau de diagnostic.
Le seuil d'adoption est lui aussi clairement posé : il faut un plan Team ou Enterprise de Claude, et la connexion des outils ainsi que la configuration des permissions prennent quelques heures au départ. Pour la plupart des équipes, la difficulté ne réside sans doute pas dans le raccordement technique, mais dans le courage de confier un compte de service capable d'ouvrir des PR et de piloter le cluster.
Sources : blog officiel d'Anthropic, CocoLoop ; les chiffres de 14 minutes de médiane pour le tri, 4 minutes pour l'identification la plus rapide de la cause racine, la multiplication par 8 du volume trimestriel livré et les 617 lignes du fichier de compétence ont été recoupés avec la communication publique de l'entreprise.