Une conviction qui se brise à chaque incident

Dans un billet publié récemment, l’ingénieur Aniruddha, passé par Twitter et Mixpanel, livre un témoignage sur la face cachée de l’astreinte. Il y raconte la conviction, partagée par de nombreux développeurs, qu’une erreur personnelle peut mettre fin à une carrière — ou pire, à l’avenir d’une entreprise. À chaque fois, cette prédiction s’est révélée fausse.

Des incidents marquants chez Twitter

Aniruddha décrit plusieurs épisodes vécus au sein de Twitter. Dès ses premières semaines après l’embauche, il est chargé d’un test de charge pour un nouveau magasin de graphes. Le test se déroule correctement, mais provoque une panne de niveau SEV0 qui plonge toute l’observabilité de l’entreprise dans le noir. « Je suis resté assis à mon bureau pendant une heure à calculer sérieusement quels amis appeler pour un nouveau travail », confie-t-il. Aucune suite n’est donnée, et il restera des années chez Twitter.

Parmi les autres incidents, il cite la panne du cluster Mesos, qui a déclenché une alerte pour toutes les équipes dépendantes. Il évoque aussi le bug qui a supprimé le célèbre tweet d’Ellen DeGeneres lors des Oscars. « J’étais convaincu qu’il n’y aurait pas de retour en arrière », écrit-il. Or, quelques mois plus tard, lors de l’introduction en bourse de Twitter, plus personne ne s’en souvenait.

Chez Mixpanel, des erreurs aux conséquences potentiellement fatales

Aniruddha rejoint ensuite la start-up Mixpanel, une société d’analyse de données. Lors de sa première année, une mise à jour efface cinq jours de données clients — une faute gravissime pour une entreprise dont la mission est de les préserver. L’équipe passe des heures à tenter de récupérer ce qui peut l’être, puis se rend à une retraite d’entreprise à Lake Tahoe « convaincue que c’était la fin de l’équipe et que de nombreux clients allaient résilier leur contrat ». Là encore, l’entreprise continue de croître.

Plus tard, une modification du SDK React provoque la capture de données sensibles, comme des mots de passe. Aniruddha croit la société condamnée. Le bug est corrigé, l’activité se poursuit. Peu avant son départ, un collègue accumule une facture Google Cloud Platform à six chiffres en une seule journée à cause d’un processus incontrôlé. « Je suis sûr qu’il a ressenti la même terreur que moi lors de ma première semaine chez Twitter », note-t-il.

Le cas CrowdStrike : une panique mondiale sans suite durable

Deux étés plus tard, à l’aéroport de Seattle après un séminaire Pocus, Aniruddha assiste à la mise à jour du capteur CrowdStrike qui paralyse la moitié des compagnies aériennes mondiales. « Depuis le sol du terminal, on aurait dit la fin de CrowdStrike. » L’action de la société a presque triplé depuis son plus bas post-incident.

Une asymétrie systématique dans l’évaluation des risques

Aniruddha tire une leçon générale : la prédiction d’un résultat catastrophique est presque toujours « sauvagement pire » que la réalité. Ce biais ne concerne pas seulement les individus ; les organisations surestiment elles aussi les conséquences des nouvelles sources de risque. Les exceptions notables existent : Knight Capital, qui a perdu plus de 400 millions de dollars en 45 minutes à cause d’un seul déploiement et a disparu en quelques jours. Mais ce type de défaillance, rappelle-t-il, est rare et limité à des secteurs comme la finance, les paiements ou les dispositifs médicaux. « Ailleurs, GitLab est plus typique : ils ont supprimé leur base de production, perdu six heures de données et ont introduit l’entreprise en Bourse quatre ans plus tard. »

Les sauvegardes ne sont pas toutes égales

Le récit ne nie pas l’importance des garde-fous. Feature flags, tableaux de bord, rotations d’astreinte et procédures de retour en arrière ont limité l’impact de chaque incident. Mais le premier réflexe après une panne – ajouter une nouvelle couche de processus – est selon lui « presque toujours le pire type de sauvegarde ». Car ce type de mesure pénalise toutes les modifications futures et donne un sentiment de sécurité trompeur.

La meilleure question à se poser, écrit-il, est : qu’est-ce qui aurait effectivement attrapé le bug ? Un test, un drapeau de fonctionnalité, un typage plus strict, un changement de produit.

Le coût silencieux de la lenteur

Les équipes d’ingénierie les plus solides ne sont pas celles qui accumulent le plus de barrières entre le code et la production. Elles investissent dans des capacités qui permettent d’aller vite en toute sécurité. Chez Mixpanel, Aniruddha et son équipe ont développé Miffy, un outil de test de régression qui fait de l’ombre au trafic de production contre le code candidat des API, détectant les problèmes avant qu’ils ne soient déployés. L’objectif n’était pas de ralentir les déploiements, mais de les rendre possibles avec confiance.

Le coût de la lenteur, souligne-t-il, est bien réel et presque jamais pris en compte : l’affaire perdue parce que l’intégration a pris six mois, la fonctionnalité que le concurrent a lancée en premier, l’ingénieur qui cesse d’innover parce qu’un incident passé a remodelé son appétit pour le risque. « Le côté négatif d’une mauvaise release est bruyant, public, visible sur un tableau de bord, tandis que le côté négatif de la lenteur est silencieux et n’apparaît nulle part ailleurs que dans ce que vous n’avez pas construit. »

L’astreinte comme école de résilience

En conclusion, Aniruddha affirme que l’astreinte apprend comment les systèmes se brisent. Mais regarder un système se briser sous sa propre responsabilité apprend surtout ce que votre carrière, votre équipe et votre entreprise peuvent absorber – presque toujours bien plus que ce que vous n’auriez prédit.