Il est 2h13 du matin. PagerDuty se déclenche pour checkout-service, p95 au-dessus du seuil depuis quatre minutes. Vous ouvrez Datadog, vous tombez sur le mauvais dashboard, puis le bon, puis l’outil CI pour les déploiements récents, puis Jira pour les incidents ouverts, puis #incidents sur Slack pour voir si un collègue est déjà dans la war room. Huit minutes plus tard, vous avez une hypothèse.
Ce n’est pas de la gestion d’incident. C’est une taxe de chargement de contexte que paie l’on-call avant même de commencer à travailler.
Les agents de code, comme Claude Code, ont dévoré l’inner loop. L’outer loop, c’est une autre histoire. Le travail opérationnel (gestion d’incident, exécution de runbook, investigation SLO, passations on-call) ressemble encore presque exactement à ce qu’il était il y a cinq ans. Le problème n’est pas le modèle. C’est l’infrastructure pour exécuter des outils agentiques à l’échelle d’une équipe, en production, avec les garanties d’auth, de périmètre et d’audit qu’un programme SRE exige.
Cet article porte sur la couche d’exécution. Le substrat de données en dessous est l’autre moitié du problème, j’en ai écrit sur le blog ClickHouse.
TL;DR
- Claude Code fonctionne déjà dans l’outer loop. L’interface, le raisonnement, le contrat d’appel d’outil : tout se transfère. Ce qui change, ce sont les sources de données.
- Cinq workflows le prouvent. Triage d’incident, exécution de runbook, rédaction de postmortem, investigation SLO, passations on-call. Chacun d’eux est fait pour Claude.
- Le manque en auth, périmètre et audit est le goulet d’étranglement. Les serveurs MCP pour la plupart des outils SaaS existent déjà. Le problème : quand chaque ingénieur câble sa propre connexion, vous héritez d’une autorisation incohérente, de credentials trop permissifs et d’aucune piste d’audit. Utile pour une personne au mieux. Un incident d’exposition de données au pire.
- Ce qu’il manque, c’est un runtime MCP, pas un modèle. Auth managée, compute hébergé, gouvernance au niveau de l’outil, logs d’audit persistants. Tant que quelque chose ne fournit pas les quatre, l’IA outer loop reste un gadget.
- Un runtime MCP, c’est plus qu’une gateway MCP. Une gateway route les outils MCP sous une seule URL. Un runtime MCP ajoute le compute qui les exécute, l’auth qui les scope, et la piste d’audit qui les rend sûrs en production. Arcade.dev est un runtime MCP avec une gateway intégrée.
Cinq workflows IA SRE et les serveurs MCP qui les alimentent
Si vous ne lisez qu’une chose dans cet article, lisez ce tableau.
| # | Workflow | Serveurs MCP | Ce que fait Claude Code | Ce que fait l’on-call |
|---|---|---|---|---|
| 1 | Triage d’incident | PagerDuty, Datadog, Slack, GitHub | Récupère le payload PagerDuty, corrèle les signaux Datadog sur la fenêtre, vérifie les déploiements récents, scanne Jira et #incidents, rédige un post de war room | Décide la prochaine action |
| 2 | Exécution de runbook | Confluence, Kubernetes, GitHub | Parse le doc Confluence en étapes, présente la séquence de diagnostic avec les commandes et les sorties attendues, propose toute commande d’écriture | Exécute les étapes, approuve chaque écriture |
| 3 | Rédaction de postmortem | Slack, PagerDuty, Datadog, Confluence | Reconstruit la chronologie depuis Slack, PagerDuty, Datadog et le journal de déploiement, remplit le modèle d’équipe avec des preuves sourcées | Rédige la cause racine et les actions à mener |
| 4 | Analyse des SLO | Datadog, PagerDuty, Snowflake, Confluence | Identifie l’inflexion de burn, corrèle déploiements, changements de config, variations de trafic et incidents amont, classe les hypothèses avec preuves sourcées | Évalue les hypothèses, décide des actions |
| 5 | Passation d’astreinte | PagerDuty, Datadog, Slack, Zendesk | Compose le briefing de relève à partir des alertes, incidents actifs, déploiements en cours, burn des SLO et actions ouvertes, le livre en DM Slack | Relit, ajoute du contexte, valide |
Workflow 1 : le triage d’incident, c’est surtout de l’archéologie
Scénario
Le triage manuel décrit ci-dessus est un problème de parallélisme, pas de compétence. Un ingénieur, cinq workflows, des chargements de contexte séquentiels. Tous les ingénieurs d’astreinte que je connais racontent la même histoire : « J’ai passé les dix premières minutes à comprendre ce qui se passait. »
Ce que fait Claude Code
Confiez l’alerte à Claude Code : « Triage cette alerte spécifique, en corrélant avec les métriques Datadog, les logs du service et l’historique de déploiement. Scanne l’historique Slack pour d’autres pannes corrélées. »
Claude Code restitue le contexte de l’alerte en deux phrases, les trois signaux corrélés les plus significatifs avec des liens Datadog directs, et les déploiements les plus susceptibles d’être impliqués classés par proximité dans le graphe de services, avec les SHAs de commits et les auteurs. Deux à trois minutes de bout en bout, pendant que vous ouvrez l’ordinateur. L’équipe de Grafana a rapporté une réduction de 3,5x du temps d’identification de la cause racine avec un schéma similaire.
Ce que fait l’ingénieur d’astreinte
Quand l’ingénieur d’astreinte passe de l’alerte sur son téléphone à l’ouverture de son ordinateur, l’analyse initiale de Claude Code l’attend déjà. Il lit le résumé, le confronte aux dashboards, croise les déploiements classés avec ce qu’il sait avoir été mis en production récemment, et décide de la prochaine action. Il repère aussi les failles : la corrélation qui est spurious, le déploiement que le graphe de services ne connaît pas, le thread #incidents qui n’était que du bruit. Claude Code compresse l’archéologie. L’ingénieur d’astreinte l’évalue.
Le problème d’auth, de périmètre et d’audit
PagerDuty, Datadog, Slack, Jira et GitHub livrent tous des serveurs MCP. Le problème, c’est de les faire tourner à l’échelle d’une équipe, pas de les construire.
Si la configuration n’est pas cohérente pour chaque ingénieur de la rotation, le workflow lâche précisément lors du tour qui en a le plus besoin. Des permissions mal configurées produisent des analyses non concluantes, et une analyse non concluante à 3h du matin est pire que pas d’analyse du tout. Les ingénieurs qui câblent leurs propres connexions s’octroient souvent des périmètres plus larges que nécessaire, et la prochaine revue d’accès se transforme en chantier de nettoyage que personne n’avait prévu. Le scénario le plus critique : si l’accès aux outils n’est pas correctement délimité, une étape de diagnostic peut déclencher par inadvertance une action en écriture, muter l’état en production, et faire du triage lui-même un incident. Configuration cohérente, credentials scopés et lecture seule imposée : ce sont des propriétés du runtime MCP, pas de la configuration individuelle de l’ingénieur.
Workflow 2 : exécution de runbook à 3h du matin
Scénario
Les équipes matures maintiennent leurs runbooks. Ceux utilisés en permanence restent à jour parce que les gens les corrigent après chaque incident. La dégradation se cache dans deux endroits plus discrets. Les runbooks qui se déclenchent une fois par trimestre dérivent entre deux utilisations, et personne ne s’en aperçoit jusqu’à ce que la prochaine alerte à 3h révèle que la moitié des commandes pointent vers des outils dépréciés et des clusters renommés. Et les nouveaux ingénieurs dans la rotation ne savent souvent pas quel runbook s’applique à l’alerte qui leur fait face. Trouver le bon document à 3h du matin est une compétence à part entière, qui prend des mois de rotation à acquérir.
« Les runbooks sont un mensonge qu’on se raconte. »
Pendant la période où je dirigeais la fiabilité chez Confluent et Dropbox, j’ai vu ce schéma se reproduire sur des stacks très différentes. Ce n’est pas un problème propre à une organisation. C’est la loi de la priorisation qui s’applique : les runbooks qui se déclenchent souvent reçoivent de l’attention, ceux qui se déclenchent rarement, non.
Ce que fait Claude Code
Trouver le bon runbook. Une fois le triage effectué, l’ingénieur d’astreinte doit savoir quel runbook s’applique et quoi exécuter. Pointez Claude Code sur l’alerte. Il confronte les métadonnées (service, symptôme, tag) à l’index des runbooks, fait remonter le meilleur candidat et présente la séquence de diagnostic avec les commandes exactes, les systèmes ciblés et la sortie attendue à chaque étape.
Garder les runbooks à jour. La plupart des équipes matures organisent des semaines qualité ou des sprints fiabilité pour actualiser leurs runbooks. Chez Confluent, nous le faisions chaque trimestre. Claude Code rend ces sprints moins coûteux dans un environnement sûr : rejouez chaque runbook en lot sur le staging, signalez les commandes pointant vers des outils dépréciés ou des clusters renommés, régénérez les étapes selon l’infra actuelle. La dette accumulée depuis la dernière révision est détectée en heures, pas en semaines.
Ce que fait l’astreinte
L’astreinte exécute les étapes. Claude Code établit le plan, l’ingénieur l’applique. Ouvrir un accès production illimité à un agent de code ne passe pas le test du bon sens dans aucune équipe fiabilité où j’ai travaillé, et ce à juste titre. L’ingénieur vérifie que Claude Code a choisi le bon runbook, lance chaque diagnostic dans son propre terminal avec ses propres credentials limités, et note les résultats au fil de l’eau. Quand Claude Code se trompe de runbook, l’astreinte le recadre, et cette correction alimente l’index pour la prochaine alerte.
Le manque de gouvernance sur l’auth, les périmètres et l’audit
Si Claude Code n’exécute pas directement en production, l’application des règles devient l’enjeu central. Le runbook doit être limité à l’utilisateur qui l’exécute, à l’environnement ciblé et aux actions que l’étape en cours requiert réellement. Une étape sans risque en staging peut être dangereuse en prod. Une étape anodine pour un SRE senior peut être catastrophique pour un nouvel arrivant qui apprend encore le cluster. Sans gouvernance au niveau des outils tenant compte de l’utilisateur, de l’environnement et de l’action ensemble, on en revient à faire confiance à chaque ingénieur pour lire attentivement à 3h du matin. C’est exactement le mode d’échec que le runbook était censé prévenir. Trouver le bon runbook et appliquer les bons périmètres sont deux problèmes distincts. Claude Code résout le premier. Le runtime MCP résout le second, avec une gouvernance définie par utilisateur, par environnement et par action. Les deux doivent fonctionner, et aucun ne remplace l’autre.
Workflow 3 : la rédaction des postmortems échoue à l’étape archéologie
Scénario
L’incident s’est résolu à 16h. La rétrospective est jeudi. Quelqu’un doit rédiger le brouillon. La partie difficile n’est pas la réflexion. C’est l’archéologie : historique Slack, timeline PagerDuty, graphes Datadog, historique des déploiements, modèle de l’équipe. L’équipe d’incident.io estime la reconstruction manuelle à 60 ou 90 minutes par incident. Ce chiffre correspond à toutes les équipes que j’ai dirigées.
La plupart des postmortems sont rédigés à la va-vite au dernier moment. La rétrospective part d’une base fragile, et la même classe d’incident revient six mois plus tard.
Ce que fait Claude Code
Tapez dans Claude Code : « Rédige le postmortem pour INC-4729 en utilisant le modèle de l’équipe. » Claude Code assemble l’archéologie. Il récupère la transcription Slack, la timeline PagerDuty, les panneaux Datadog du tableau de bord de l’incident et le journal des déploiements pour chaque service touché. Il intègre tout cela dans le modèle de l’équipe avec des liens sources, de sorte que chaque entrée de la timeline renvoie au panneau, au commit ou au message d’origine.
Le brouillon s’arrête à l’archéologie. Timeline, impact, services affectés, preuves. Les champs cause racine, facteurs contributifs et actions sont volontairement laissés vides. Les équipes qui laissent l’IA remplir ces sections transforment chaque rétrospective en séance de nettoyage. L’équipe de Zalando a signalé des taux d’hallucination atteignant 40 % dans les premières analyses de postmortem rédigées par IA, et la leçon n’est pas de mieux prompter. C’est d’exclure tout élément causal du brouillon.
Ce que fait l’astreinte
L’astreinte et le groupe de rétrospective relisent le brouillon. Ils ne le réécrivent pas. Ils corrigent les entrées de timeline erronées, ajoutent les signaux que l’archéologie a manqués (un rapport client arrivé par e-mail, un incident connexe trois jours plus tôt, le déploiement deux sprints en arrière qui a introduit le bug latent), et consacrent leur temps à ce qui compte : les 5 pourquoi, la validation de la cause racine, les décisions sur les actions.
L’effet de levier est le plus fort sur la longue traîne. Dans mon expérience, 80 à 90 % des incidents que gère une équipe mature sont des événements à fort volume et faible priorité où l’archéologie est mécanique et le compte-rendu paraît banal. C’est là que les équipes font des coupes, et que les incidents répétitifs s’accumulent discrètement. Claude Code absorbe le travail routinier pour que le travail à haute valeur de jugement reçoive de l’attention sur chaque incident, pas seulement sur les gros.
Le manque de gouvernance sur l’auth, les périmètres et l’audit
Les outils que sollicite le brouillon contiennent les données les plus sensibles de l’entreprise. #incidents héberge des PII clients et des secrets de fournisseurs. Le journal des déploiements contient des messages de commit qui laissent parfois fuiter du contexte de sécurité. Les tableaux de bord Datadog exposent les patterns de trafic sur l’ensemble du parc. L’ingénieur qui a configuré le connecteur Slack dispose généralement d’un accès lecture workspace plus large que ce dont le rôle postmortem a besoin, et le brouillon finit par citer des messages qu’il n’avait pas à lire.
La limitation des périmètres doit se faire au niveau de la couche outil, pas au niveau du prompt. Quels canaux le brouillon peut lire, quels tableaux de bord il peut récupérer, quelles tables il peut requêter : tout cela encadré par des règles et lié à l’utilisateur qui déclenche le workflow. Puis une piste de provenance dans un journal persistant, montrant ce que l’IA a consulté, quand, et sous quelle identité. C’est la moitié dont la conformité demandera des comptes, et celle qui détermine si le workflow survit à sa première revue de sécurité.
Workflow 4 : investigation SLO et revues de budget d’erreur
Scénario
Chez Confluent, mon équipe passait en revue notre SLO de disponibilité chaque lundi. On extrayait les incidents de la semaine, mesurions leur impact sur le SLO et le SLA client, et remappions les causes racines de chaque postmortem vers les services et les thèmes. L’objectif : voir si le budget d’erreur de la semaine avait été consommé par un problème récurrent ou éparpillé sur cinq incidents sans lien.
La majeure partie de la préparation était une corrélation manuelle : delta de budget d’erreur, rapproché de l’incident PagerDuty, rapproché de la régression Datadog, rapproché de l’historique des déploiements, rapproché du postmortem, rapproché du seau thématique. Un SRE passait généralement quatre à six heures sur ce pipeline avant le début de la réunion. La réflexion avait lieu pendant la revue. La préparation, c’était du travail de terrain.
Ce que fait Claude Code
Demandez à Claude Code de préparer la revue du lundi. Il récupère les deltas SLO et SLA, extrait chaque incident PagerDuty sur la période, relie chacun à la régression Datadog correspondant en temps et en service, tire le postmortem depuis Confluence et en extrait la section cause racine. Il regroupe les causes racines en thèmes selon la taxonomie existante de l’équipe et restitue un brief structuré : delta de budget d’erreur, incidents qui en sont responsables, thèmes identifiés et questions ouvertes que les postmortems n’ont pas résolues.
Ce que Claude Code ne fait pas : quantifier en pourcentage la part de consommation imputable à chaque incident. C’est de l’analyse causale que les modèles actuels font mal, et un pourcentage inventé dans une revue de métriques est pire qu’aucun chiffre.
L’IA traque. L’humain décide.
Ce que fait l’astreinte
Le SRE qui anime la revue lit le brief, valide les correspondances incident-régression (Claude Code en ratera certaines), rédige l’histoire causale que l’IA a refusé de deviner, décide quels thèmes méritent des actions, et soulève les questions ouvertes en réunion. Quatre heures de préparation deviennent trente minutes de relecture et correction.
Le manque de gouvernance sur l’auth, les périmètres et l’audit
Les workflows adossés à un entrepôt de données sont ceux que les équipes SRE ont le plus longtemps différés, et la raison est le périmètre. Vous ne pouvez pas donner à Claude Code un accès illimité à l’entrepôt en espérant que le prompt engineering l’éloignera des PII. Vous ne pouvez pas lui accorder un budget de requêtes sans limite et attendre de voir une scan à cinq mille dollars sur la facture du mois prochain. L’application des périmètres au niveau du runtime MCP change le calcul : cette tâche interroge ces tables et pas d’autres, coûte moins de cinquante dollars, ne touche jamais les chemins d’écriture en prod. Sans ça, le workflow reste un prototype et n’intègre jamais la rotation.
Workflow 5 : Les passations d’astreinte perdent le contexte que personne n’a écrit
Scénario
Les passations de service sont le rituel le plus sous-estimé du travail SRE, car les incidents qu’elles évitent ne sont jamais comptabilisés. La qualité d’une passation dépend du niveau de fatigue de l’ingénieur sortant, ce qui signifie que les pires passations surviennent après les shifts les plus chargés, c’est-à-dire exactement quand elles importent le plus. Le coût non évident : l’incident du matin où l’ingénieur d’astreinte ne savait pas qu’un déploiement était encore en cours, et se retrouve à appeler son prédécesseur à 8h pour savoir ce qui s’est passé la nuit.
Ce que fait Claude Code
Claude Code génère le briefing à chaque rotation, sans que personne n’ait à le déclencher. Il agrège les 24 dernières heures d’alertes avec leurs notes de résolution, les incidents actifs, les déploiements en cours, les SLOs ayant franchi un seuil de burn, les fils #incidents non résolus, les escalades Zendesk et les rapports clients reçus via l’alias email d’astreinte. Il liste les actions ouvertes assignées à la rotation. Le briefing est livré en DM Slack, avec une copie dans le doc Confluence de passation de l’équipe.
Ce que fait l’ingénieur d’astreinte
L’ingénieur sortant ajoute ce que lui seul peut apporter : ce qu’il pense être une fausse alerte, quel rapport client surveiller, quel déploiement l’inquiète, quelle alerte il a silencée et pourquoi. C’est ce savoir de passation qui vit dans sa tête et nulle part ailleurs. Claude Code rassemble les faits. L’ingénieur d’astreinte apporte le jugement.
Le problème d’auth, de périmètre et d’audit
Le briefing se déclenche à 17h qu’un ingénieur soit connecté ou non, ce qui nécessite des credentials qui existent en dehors de la session de n’importe quel individu. Les dotfiles sur un laptop fermé ne font pas l’affaire. Un workflow planifié sans identité de service persistante n’est pas un workflow : c’est un cron job qui s’arrête silencieusement dès que quelqu’un quitte l’équipe. L’identité de service persistante est une propriété du runtime MCP, pas du laptop de l’ingénieur.
Claude Code est un assistant, pas un SRE IA autonome
Cinq workflows, un seul schéma. Claude Code lit, corrèle, rédige et attend. L’humain décide.
La majorité du marché des SRE IA parie sur l’inverse. Traversal, Resolve, Anyshift, et d’autres construisent des agents autonomes capables d’alerter, de remédier et de clore des incidents seuls. Je reste sceptique. La qualité d’un modèle dépend de ses capacités et du contexte qu’on lui fournit. Les modèles actuels font l’archéologie de manière fiable. Ils ne peuvent pas encore recevoir suffisamment de contexte délimité ni les bons outils pour remédier à la production sans supervision. C’est un problème de contexte et d’outillage, pas de modèle, et je préfère livrer une forme qui fonctionne déjà.
Claude Code s’exécute quand vous le demandez. Il s’arrête dès que l’étape suivante requiert un jugement humain. Il n’alerte, ne rollback et ne clôture jamais un incident seul.
Un assistant évite aussi la bataille d’achat qui bloque les déploiements autonomes. Vous ne remplacez pas un rôle ni n’ajoutez un niveau d’astreinte. Vous orientez l’outil que votre équipe utilise déjà vers des sources de données qu’elle connaît déjà, avec un runtime MCP qui délimite ce qu’il peut faire. La revue sécurité passe de « nouveau vendor, nouveau risque » à « outils délimités dans un agent existant ».
Chaque workflow de cet article commence comme un prompt et évolue en compétence. Le prompt de triage, le dispatcher de runbooks, le rédacteur de postmortems, le pipeline SLO, le briefing de passation : chacun débute par ce qu’un ingénieur tape une fois, et devient une compétence packagée que toute l’équipe d’astreinte invoque de la même façon. Cette compétence s’affine continuellement : une nouvelle source de données ici, un prompt plus précis là, une correction après qu’un incident révèle un angle mort. L’astuce d’une personne devient l’infrastructure de l’équipe, et cette infrastructure s’accumule.
La fiabilité vient d’un programme de fiabilité sérieux, et un tel programme repose essentiellement sur des rituels opérationnels : triage, runbooks, postmortems, revues SLO, passations. Claude Code justifie son usage en rendant ces rituels assez peu coûteux pour avoir lieu à chaque shift, pas seulement quand quelqu’un a l’énergie de s’y consacrer.
Ce qu’un SRE IA attend de sa couche d’intégration MCP
Chaque workflow ci-dessus a besoin des mêmes quatre choses.
- Authentification et autorisation gérées pour tous les outils. Flux OAuth pour chaque outil connecté, credentials rafraîchis automatiquement, délimités par utilisateur, accessibles depuis n’importe quel appareil, y compris un téléphone à 3h du matin.
- Compute géré, toujours disponible, pour toute l’équipe. Les outils tournent sur une infrastructure partagée, hébergée dans le cloud ou on-prem, avec le même comportement que le déclencheur vienne d’un laptop, d’un téléphone, d’un webhook ou d’un cron job.
- Gouvernance au niveau de l’outil et de l’agent. Politiques de permissions par outil, budgets de coût par tâche et limites d’accès aux données par requête, appliqués là où l’appel se produit, pas là où le modèle le propose. C’est la différence entre un workflow que la sécurité approuve et un qu’elle tue dès le premier regard.
- Journaux d’audit persistants. Chaque appel d’outil journalisé avec l’utilisateur déclencheur, les arguments, la réponse et l’horodatage, dans un log que l’agent ne peut pas modifier. Sans ça, vous ne pouvez pas auditer l’IA, et vous ne pouvez pas lui faire confiance.
Arcade.dev : un runtime MCP pour les workflows SRE IA
Arcade est un runtime MCP conçu pour combler exactement ce manque. OAuth géré prend en charge chaque outil connecté, avec des credentials qui se rafraîchissent automatiquement et ne touchent jamais le modèle de langage. Chaque appel d’outil s’exécute au nom de l’utilisateur qui l’a déclenché, de sorte que les permissions natives dans PagerDuty, Datadog et Snowflake s’appliquent exactement comme en dehors de l’agent. Vous connectez PagerDuty une fois, et chaque session Claude Code de votre équipe en bénéficie avec le bon périmètre.
Le runtime exécute les outils sur des workers hébergés, déployables dans votre cloud ou on-prem, et applique des politiques par outil là où l’appel se produit, pas là où le modèle le propose. Le même workflow déclenché depuis un téléphone, un laptop ou un cron job s’exécute sur une infrastructure partagée. Les politiques s’appliquent au niveau du runtime MCP : « ce workflow interroge ces tables Snowflake et pas d’autres », « ce workflow peut proposer des actions PagerDuty mais ne peut pas les exécuter sans approbation », « ce workflow dispose d’un budget de requêtes de 25 $ ».
Chaque appel d’outil atterrit dans un journal d’exécution compatible OpenTelemetry, avec l’utilisateur déclencheur, les arguments, la réponse et l’horodatage. Il s’intègre directement dans le pipeline d’observabilité que votre équipe plateforme fait déjà tourner. Quand votre postmortem demande ce que Claude Code a fait pendant l’incident, vous avez la réponse. Quand la conformité réclame toutes les requêtes que cet agent IA a lancées contre l’entrepôt le trimestre dernier, vous avez la réponse.
Les outils préconstruits couvrent PagerDuty, Datadog, Slack, Jira, Confluence, GitHub, Snowflake et d’autres. Vous pouvez aussi apporter vos propres serveurs MCP dans le runtime : les serveurs PagerDuty, Datadog, Snowflake et Kubernetes listés dans le tableau ci-dessus s’intègrent tels quels et héritent de la même authentification gérée, du même contrôle des politiques et des mêmes journaux d’audit que les outils préconstruits. Vous étendez votre investissement MCP existant au lieu de le remplacer.
Vous pouvez construire tout ceci sans Arcade, et la raison de ne pas le faire est la même que celle qui vous a évité d’écrire votre propre système CI : le travail est réel, les cas limites sont pénibles, et ce n’est pas là que vit votre différenciation en fiabilité. Une équipe expérimentée peut mettre en place un OAuth managé, des workers hébergés, un contrôle des politiques par outil et un journal d’audit infalsifiable. Quelques équipes plateforme que je connais ont commencé ce chemin et ont conclu que c’était trop coûteux à maintenir, ou tout simplement pas là où elles voulaient dépenser leur budget fiabilité.
Réduire la charge d’astreinte, c’est là que vit le levier SRE
La boucle externe n’a pas rattrapé la boucle interne parce que l’infrastructure nécessaire pour exécuter des outils agentiques en toute sécurité sur des systèmes de production était absente. Un assistant de code n’a besoin que de votre dépôt et de votre éditeur. Un assistant opérationnel a besoin d’une identité gérée, de compute hébergé, d’une gouvernance appliquée et d’une piste d’audit, car il atteint des systèmes où les erreurs réveillent le CTO.
Les équipes SRE qui résoudront ce problème dans l’année à venir prendront de l’avance sur celles qui ne le feront pas, de la même façon que les équipes qui ont adopté Claude Code pour le travail en boucle interne en 2024 ont distancé celles qui ont attendu. La boucle interne est résolue. La boucle externe est là où vit le levier maintenant, posée sur un substrat de données qui est lui-même un problème de conception à part entière.
Claude Code ne remplace pas l’ingénieur d’astreinte. Il lui permet juste de commencer à la page 5 plutôt qu’à la page 1.
Questions fréquentes
Qu’est-ce qu’un IA SRE ?
Un IA SRE est un assistant IA qui aide les ingénieurs de fiabilité dans leur travail opérationnel : triage d’incidents, exécution de runbooks, rédaction de postmortems, investigation des SLO et passations d’astreinte. La plupart des déploiements pratiques d’IA SRE fonctionnent aujourd’hui comme des compagnons qui lisent, corrèlent et rédigent pendant qu’un ingénieur humain décide de la prochaine action, plutôt que comme des agents autonomes qui déclenchent des alertes, remédient et clôturent les incidents seuls.
Quelle est la différence entre une gateway MCP et un runtime MCP ?
Une gateway MCP route les outils MCP sous une URL unique pour que n’importe quel client MCP puisse les appeler. Un runtime MCP va plus loin : il ajoute le compute qui exécute les outils, l’authentification gérée, l’application des permissions par outil et des journaux d’audit persistants. Une gateway est une infrastructure de routage. Un runtime est une infrastructure de production. Arcade.dev est un runtime MCP avec une gateway intégrée.
Claude Code peut-il remplacer un ingénieur d’astreinte ?
Non. Claude Code fonctionne mieux comme compagnon de l’ingénieur d’astreinte, pas comme remplaçant. Il compresse l’archéologie (récupération des alertes, corrélation des signaux, rédaction des résumés) pour que l’ingénieur démarre avec le contexte déjà chargé. Chaque décision qui requiert du jugement (rollback d’un déploiement, alerte d’un collègue, clôture d’un incident) reste entre les mains de l’humain.
Comment utiliser Claude Code pour le triage d’incidents ?
Pointez Claude Code sur l’alerte avec un prompt tel que « Triage cette alerte, corrélée avec les métriques Datadog, les logs du service et l’historique des déploiements. Scanne Slack pour des incidents corrélés. » Avec des serveurs MCP pour PagerDuty, Datadog, Slack et GitHub reliés à un runtime MCP, Claude Code renvoie un résumé, les principaux signaux corrélés, les déploiements candidats et un brouillon de post war room en deux à trois minutes.
Est-il sûr de laisser Claude Code exécuter des runbooks en production ?
Claude Code ne devrait pas exécuter directement en production. Le modèle le plus sûr consiste à laisser Claude Code analyser le runbook, détailler la séquence de diagnostic et proposer des commandes, pendant que l’ingénieur d’astreinte exécute chaque étape dans son propre terminal avec ses propres credentials scopés. Un accès production non borné pour un agent de code ne devrait pas passer une revue de fiabilité.
Quels serveurs MCP faut-il pour les workflows IA SRE ?
L’ensemble de base couvre les outils déjà présents dans une rotation SRE : PagerDuty, Datadog, Slack et GitHub pour le triage d’incidents ; Confluence et Kubernetes pour l’exécution de runbooks ; Snowflake pour l’investigation des SLO ; Zendesk pour les passations d’astreinte. Chacun dispose d’un serveur MCP prêt pour la production qui peut s’exécuter dans un runtime MCP comme Arcade, lequel gère l’auth, les politiques et les journaux d’audit sur l’ensemble.
Comment Arcade fonctionne-t-il avec Claude Code ?
Arcade est un runtime MCP qui gère OAuth, les politiques de permissions par outil et les journaux d’audit pour chaque outil appelé par Claude Code. Vous connectez PagerDuty, Datadog ou Snowflake une fois, et chaque session Claude Code de votre équipe récupère les outils au bon périmètre. Arcade exécute aussi vos propres serveurs MCP, donc les intégrations existantes fonctionnent telles quelles.
Quelle est la différence entre des outils IA SRE comme Traversal et l’utilisation de Claude Code avec un runtime MCP ?
Traversal, Resolve et Anyshift construisent des agents autonomes qui déclenchent des alertes, remédient et clôturent les incidents par eux-mêmes. Claude Code avec un runtime MCP adopte l’approche compagnon : lire, corréler, rédiger et attendre que l’ingénieur décide. Le modèle compagnon est disponible aujourd’hui. Le pari autonome, non.
Le store d’observabilité sous-jacent compte-t-il autant que le runtime MCP au-dessus ?
Oui. Un agent IA lance 10 à 30 requêtes par investigation, et la plupart des stores d’observabilité n’ont pas été conçus pour servir ce schéma à la rétention et à la cardinalité dont un SRE a besoin. Le runtime MCP gère la couche d’exécution ; le store d’observabilité gère le substrat cognitif. Les deux comptent. J’ai écrit sur la question du substrat ici.
