LO
Déploiement réelAutomatisation cognitive2026-05-28
Deux ingénieurs de Google ont décrit les agents que leur propre organisation SRE fait tourner dans la réponse aux incidents : regroupement d'alertes, documents de passation, brouillons de postmortem et, dans certains cas, atténuation autonome
Ingénieur DevOps / plateforme / SREpage du métier →
Date de l'événement / signalement
2026-05-28
Stade de la preuve
Déploiement réelUn employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.
Tâches concernées
Être réveillé
Décider à trois heures du matin, sous la pression du temps et avec une information partielle, quoi revenir en arrière, quoi dégrader et quoi dire aux gens pendant que c'est encore cassé.
Encore menée par des humains✓ Appuyé sur des preuves
Où ceci s'applique
Google décrit ses propres opérations et ne vend pas à quelqu'un d'autre : le texte est signé par un Distinguished Software Engineer et un Distinguished Site Reliability Engineer, et publié sur le blog de l'entreprise. Ce qu'il affirme au passé ou au présent est la moitié qui mérite d'être enregistrée : l'équipe SRE a développé des agents qui surveillent et améliorent les playbooks et la documentation de production à partir de leur usage pendant les incidents, et qui peuvent générer de nouveaux playbooks à partir de ceux-ci ; un agent d'alerte qui les regroupe, les prétraite et les enrichit avant que des gestionnaires autonomes ne les prennent ; des agents qui consolident les espaces de discussion, les enregistrements et les documents de suivi utilisés pendant un incident, créent des documents de passation entre SRE, rédigent des brouillons de postmortem et gèrent la communication interne et externe de l'incident ; des agents créés pour enquêter sur les incidents et, selon les mots du texte, dans certains cas pour les atténuer de façon autonome ; et AI Insights, un système qui relit les incidents passés et rend ce qu'il en extrait à ces agents. Le reste du texte relève du projet et n'est pas enregistré. Trois limites, et la première est la plus grande. Il n'y a pas un seul chiffre : ni la proportion d'incidents concernés, ni le nombre d'agents en service, ni un avant et un après, ni le nombre de personnes dans l'astreinte aujourd'hui. Deuxièmement, l'intérêt est direct et le cadrage à la première personne ne le dissimule pas : chaque composant nommé en dessous est un produit Google (Gemini, l'Agent Development Kit, la Gemini Enterprise Agent Platform, MCP sur l'infrastructure d'API de Google), de sorte que ce texte est aussi une architecture de référence de ce que l'éditeur vend. Troisièmement, c'est un seul opérateur, et un opérateur particulier : une organisation qui pratique sa propre discipline de fiabilité depuis vingt ans ne remplace pas une équipe de quatre qui se passe le bipeur. Ce qui en fait une preuve sur cette tâche et non sur des outils, c'est la place qu'occupent les agents : le travail autour de la décision de trois heures du matin — rassembler le contexte, passer la main, dire aux gens où l'on en est, écrire ensuite — est la partie qui a bougé, et le texte précise qu'une approche par agents n'implique pas nécessairement de retirer les personnes du processus pour les services les plus à risque.
Ce que cela veut dire
Chez un très grand opérateur, les parties d'un incident de trois heures du matin passées d'abord au logiciel sont celles qui entourent la décision, non la décision elle-même : rassembler le contexte, regrouper les alertes, passer la main à l'ingénieur suivant, dire où l'on en est, écrire ensuite. Le texte dit aussi que les agents atténuent dans certains cas de façon autonome, et que pour les services les plus à risque l'approche ne retire pas nécessairement les personnes.
Ce que cela ne montre pas encore
Il n'y a pas un seul chiffre dans le texte. Il ne dit pas quelle proportion d'incidents ces agents touchent, combien sont en service, ce qui a changé avant et après, ni combien de personnes sont aujourd'hui dans l'astreinte. Il ne dit pas non plus si quelqu'un est réveillé moins souvent — la question dont cette tâche parle vraiment.
Ce que vous pouvez vérifier
Reprenez vos trois derniers incidents et marquez quelles minutes sont allées à comprendre ce qui se passait, lesquelles à décider, lesquelles à prévenir les gens. La première et la troisième sont les parties que cet employeur a confiées ; la deuxième est celle qu'il dit avoir gardée. Si votre répartition ne ressemble en rien à cela, le dossier ne se transpose pas chez vous — et cela aussi mérite d'être su.
Cela change-t-il l'évaluation ?
Non. L'indice d'impact n'est jamais déplacé par un seul événement. Ce que ce dossier a fait : 1 jugement de tâche lié ci-dessus repose désormais sur une preuve au lieu d'une inférence.
Source
Google Cloud — Stevan Malesevic and Christopher Heiser, AI in SRE: where and how Google is deploying agentic AI to improve operations (28 May 2026) · vérifié 2026-09-22 · VOLO agent · interprété 2026-09-22 · VOLO agent
Source primaire — publiée par la partie qui a fait la chose, ou par l'autorité de référence. Aucune contresignature nécessaire.