Le rayon de souffle d'un runbook : anatomie d'un sinistre à 480 000 €

En Site Reliability Engineering, le blast radius (rayon de souffle) désigne l'étendue des dégâts qu'une opération peut provoquer si elle tourne mal. Restreindre le blast radius est une obsession saine : on segmente les environnements, on limite les permissions, on déploie progressivement. Mais l'automatisation, qui est la raison d'être du SRE, joue paradoxalement contre cette prudence.

Un runbook automatisé, c'est du pouvoir condensé. Là où un opérateur humain hésiterait avant de taper une commande sur la production, le script l'exécute en quelques millisecondes, sur des centaines d'instances, sans cligner. L'automatisation amplifie autant les bonnes décisions que les mauvaises. Et quand une mauvaise décision est encodée dans un script qui s'exécute à grande échelle, le rayon de souffle devient maximal.

Reconstituons un sinistre type, inspiré de cas réels mais anonymisé, pour comprendre comment quelques caractères de code se transforment en facture à six chiffres.

L'enjeu, pour un ingénieur SRE, n'est pas théorique. Plus votre niveau d'automatisation est élevé — et c'est ce que vos clients valorisent chez vous — plus le levier d'erreur est puissant. Vous êtes payé pour supprimer l'intervention manuelle ; or chaque suppression d'intervention manuelle retire aussi un point où un humain aurait pu dire stop. Le métier consiste donc à construire des automatismes sûrs, et la frontière entre l'automatisme qui sauve une nuit d'astreinte et celui qui ravage une production tient parfois à une seule ligne de garde.

Un ingénieur SRE prestataire opère la plateforme d'une scale-up SaaS B2B. Pour gagner du temps lors des opérations de maintenance, il a écrit un runbook qui nettoie les ressources de l'environnement de staging : suppression des anciens snapshots, des volumes orphelins, des buckets temporaires.

Le runbook lit la variable d'environnement ENV pour cibler le bon périmètre. Ce jour-là, la variable n'est pas définie dans le shell d'astreinte. Le script ne s'arrête pas : il interprète une chaîne vide. Le filtre censé cibler staging-* devient un filtre vide qui matche toutes les ressources, production comprise.

En vingt secondes, le runbook supprime des volumes de production, plusieurs buckets de stockage objet et les snapshots associés. La réplication, configurée sur le même compte, propage la suppression. Quand l'alerte de monitoring se déclenche, il est déjà trop tard : la base principale et ses sauvegardes les plus récentes ont disparu.

Le runbook a fonctionné parfaitement. Il a exécuté exactement ce qu'on lui demandait. Le problème n'était pas le code : c'était l'absence de garde-fou sur une variable vide.

Voici comment se reconstitue le préjudice total supporté par le client, et que ce dernier réclame au prestataire SRE.

Pour un ingénieur SRE indépendant ou une petite structure, ce montant est tout simplement insolvable sur fonds propres. Sans assurance, c'est la liquidation et la mise en cause du patrimoine personnel.

Notez l'effet de levier vicieux : le poste le plus lourd n'est pas le coût technique de la remise en état (60 000 €), mais le préjudice business que subit le client (downtime, données perdues, pénalités). Ce sont les dommages immatériels qui font exploser la note. Un SRE habitué à raisonner en coût d'infrastructure sous-estime presque toujours l'ampleur du préjudice commercial qu'une seconde d'indisponibilité peut représenter pour un e-commerçant en pleine campagne. C'est cette asymétrie — un acte technique minuscule, une conséquence financière massive — qui rend l'assurance indispensable plutôt qu'optionnelle.

C'est exactement le scénario pour lequel l'assurance RC Pro des métiers du numérique a été conçue. Décomposons sa prise en charge :

• Dommages immatériels : le downtime, la perte de chiffre d'affaires et la perte de données sont couverts au titre des préjudices immatériels consécutifs à votre faute professionnelle.
• Erreur d'automatisation : la suppression accidentelle via un runbook entre pleinement dans le champ de la faute professionnelle garantie.
• Pénalités SLA : selon les contrats, les pénalités contractuelles peuvent être prises en charge dans le cadre du préjudice global.
• Frais de défense : si le client engage une procédure, l'assureur finance votre défense et mandate les experts.

Reste le sujet du plafond de garantie. Sur un sinistre à 480 000 €, il faut un plafond suffisant, souvent négocié entre 500 K€ et 1 M€ pour les missions critiques. C'est précisément ce que les scale-ups exigent dans leurs contrats : un prestataire SRE dont la RC Pro plafonne à 150 000 € sera tout simplement écarté des appels d'offres sur les plateformes sensibles. Le plafond n'est donc pas qu'une protection, c'est aussi un argument commercial qui vous ouvre des missions.

Un mot enfin sur la déclaration du risque. Si vous opérez des plateformes critiques avec des SLA exigeants et des astreintes 24/7, déclarez-le à la souscription. Un risque sous-déclaré peut entraîner une réduction proportionnelle d'indemnité le jour du sinistre — exactement le moment où vous avez le plus besoin de la garantie pleine. La franchise du contrat doit aussi être calibrée : trop élevée, elle vous laisse un reste à charge douloureux ; trop basse, elle alourdit la prime sans bénéfice réel. Vérifiez les plafonds, franchises et options adaptés à votre niveau de criticité sur la page assurance ingénieur SRE.

L'assurance répare. La prévention évite. Les deux se combinent. Quelques garde-fous techniques réduisent drastiquement la probabilité d'un sinistre de ce type :

• Fail-safe sur variables vides : un set -u ou une assertion qui fait échouer le script si une variable critique est absente.
• Confirmation explicite pour toute opération destructrice sur un périmètre de production.
• Permissions IAM segmentées par environnement, pour qu'un runbook de staging ne puisse physiquement pas toucher la production.
• Sauvegardes immuables et isolées du compte opérationnel, hors d'atteinte de la réplication.
• Dry-run obligatoire avant exécution réelle.

Mais aucun garde-fou n'est parfait, et l'erreur humaine reste irréductible. Le rôle du SRE est de minimiser la probabilité ; le rôle de l'assurance est de couvrir la conséquence. Un ingénieur SRE qui a verrouillé son blast radius technique et souscrit une RC Pro adaptée a fait son travail des deux côtés de l'équation du risque.

Il y a aussi une dimension psychologique à ne pas négliger. Un ingénieur qui sait qu'une erreur d'astreinte ne le ruinera pas personnellement prend de meilleures décisions sous pression : il ne masque pas un incident par peur des conséquences, il alerte, il escalade, il déclenche le plan de remédiation sans hésiter. La couverture assurantielle, en retirant la menace existentielle de la faillite personnelle, restaure la sérénité opérationnelle dont dépend précisément la qualité de la gestion d'incident. Protéger le patrimoine du SRE, c'est aussi, indirectement, protéger la fiabilité de la plateforme qu'il opère.