Fausse alerte : comment le product manager traverse ses heures les plus sombres comme on affronte un typhon

Commençons par une phrase qui va peut-être déplaire : la grande majorité des « heures les plus sombres » que vous traverserez dans votre vie finiront comme ce typhon — en fausse alerte. Et ces deux mots, « fausse alerte », tuent un product manager plus sûrement que le typhon lui-même.

Le typhon n°9 de l’année, « Bawei », a bifurqué vers le sud cette nuit. Il n’a pas frappé Zhoushan de plein fouet ; il s’est affaibli au rang de simple typhon et a filé vers la côte, entre Wenling dans le Zhejiang et Xiapu dans le Fujian. Alors, de ce côté-ci, à Zhoushan et à Putuo, les ferries suspendus dès le 9 juillet, les vols annulés, ces bateaux de pêche déplacés en pleine nuit de leur mouillage jusqu’au quai ouest de Shenjiamen — vus après coup, tout cela semble n’avoir servi à rien. Ce matin, quelqu’un a déjà lancé dans le groupe de discussion : « Si on avait su, on n’aurait pas eu à sortir les bateaux en pleine nuit. »

Arrêtons-nous sur cette phrase. Parce que tout ce qu’il y a de plus intéressant dans cette histoire se cache justement dans ce « si on avait su ».

Dans mon texte précédent sur Putuoshan, je disais : n’allez pas prier Guanyin de détourner le typhon à votre place, allez plutôt réparer la digue — n’attribuez pas le fait de « ne pas avoir été touché » à une protection mystérieuse, c’est une erreur d’attribution. Ce texte-ci fait un pas de plus : la digue est réparée, l’alerte se déclenche pour de vrai cette nuit-là — et vous, qui tenez la barre, que devez-vous faire, au juste ?

Ma réponse : affronter un typhon n’a jamais été un seul geste, mais trois gestes qui s’enchaînent — avant le typhon, tout préparer ; en plein cœur du typhon, encaisser la tempête ; après le typhon, ramasser les débris. Ces trois choses-là, même si neuf fois sur dix c’est une fausse alerte, on ne peut en sacrifier aucune. C’est comme ça qu’on traverse les heures les plus sombres du métier de product manager.

I. Avant le typhon : votre sang-froid, vous l’avez tout entier accumulé avant

Dans les heures les plus sombres, la chose la plus trompeuse, c’est le sang-froid.

Vous verrez des gens dont le système plante au milieu de la nuit, dont les données ne collent plus, à qui le patron téléphone — et qui restent pourtant assis, à démêler les choses une par une. Vous croyez que c’est un tempérament inné, une improvisation réussie. Non. Dans les heures les plus sombres, il n’y a pas un gramme de sang-froid qui pousse sur place ; tout a été accumulé, petit à petit, pendant les « jours sans typhon ».

Pour qui fait du produit, qui construit des systèmes, ce qu’on « accumule » ce sont des choses très concrètes : un interrupteur de rollback prêt à être actionné à tout moment ; un déploiement progressif qui vous laisse d’abord tester sur 1 % du trafic, au lieu de pousser 100 % de vos utilisateurs à l’eau d’un coup ; un dispositif de monitoring et d’alertes qui vous prévient de l’endroit où ça saigne avant que les utilisateurs ne se mettent à râler ; un plan d’urgence écrit noir sur blanc et réellement répété ; et cette réserve de confiance et de trésorerie que l’on met de côté, petit à petit, tant qu’on n’en a pas besoin.

Le mot-clé ici, c’est « réellement répété ».

Le 31 janvier 2017, GitLab a connu un incident que l’on raconte encore aujourd’hui. Un ingénieur, tard dans la nuit, a tapé une commande de suppression sur la mauvaise base de données et a effacé les données de la base de production. Effacer la base, en soi, n’est pas la fin du monde — ce qui a vraiment glacé le dos de tout le monde, c’est ce qui a suivi : ils disposaient de cinq mécanismes de sauvegarde et de réplication, et à l’analyse, aucun n’était réellement utilisable. Les sauvegardes automatiques par pg_dump, à cause d’une erreur de configuration, n’avaient en fait jamais tourné avec succès ; l’échec des sauvegardes aurait dû déclencher des alertes par e-mail, mais ces e-mails étaient silencieusement rejetés par un réglage DMARC, personne ne les recevait ; il existait bien des snapshots de disque Azure, mais leur restauration prenait plus de 18 heures. Ce qui a finalement ramené GitLab du bord du gouffre, c’est un snapshot qu’un ingénieur avait pris à la main, par hasard, six heures avant l’incident. C’est grâce à ce seul « par hasard » qu’ils n’ont perdu que six heures de données.

Cet épisode a mis à nu, dans toute sa crudité, le vrai sens de ces mots, « tout préparer » : vous croyiez avoir réparé la digue, et c’est quand le typhon arrive que vous découvrez qu’elle était peinte sur le mur. Cinq sauvegardes, ça sonne comme un rempart inébranlable, et pourtant aucune n’avait été sérieusement vérifiée, sérieusement répétée. Un plan d’urgence qu’on n’a pas répété n’est pas un plan, c’est un vœu. Cette phrase que vous avez écrite dans votre documentation — « nous disposons d’un plan de reprise après sinistre robuste » — vaut, avant l’arrivée du typhon, exactement autant qu’un souhait de bonne chance.

Une approche plus radicale encore : ne pas attendre du tout que le typhon arrive. Netflix élève un programme baptisé « Chaos Monkey », dont le travail quotidien consiste à éteindre au hasard, en pleine production, quelques machines en train de servir — et à le faire exprès en plein jour, quand tout est calme. Ça ressemble à de l’automutilation ; c’est en réalité la forme la plus honnête de répétition. Plutôt que d’attendre le vrai typhon pour découvrir que la digue était peinte, autant lâcher soi-même chaque jour un singe fou dans la salle des machines, faire planter une bonne fois le système qui n’a pas encore lâché, et voir s’il tient le coup ou non. Le sang-froid capable d’encaisser Chaos Monkey, celui-là est vrai ; le sang-froid qui n’a jamais subi une telle épreuve, c’est juste de la chance pas encore épuisée.

C’est là qu’apparaît la première couche de « fausse alerte » : tous ces rollbacks, ces répétitions, ces sauvegardes que vous avez accumulés, l’immense majorité ne vous serviront jamais, pas une seule fois de toute votre vie. Ne pas servir, ça donne l’impression d’avoir travaillé pour rien. Mais changez d’angle — les jours paisibles que vous avez vécus, ce n’est pas de la chance, c’est une préparation que vous avez achetée. Celui qui ne « prépare jamais pour rien » n’a simplement pas encore vu son tour venir.

II. En plein cœur du typhon : c’est vous qui devez vous tenir devant, sous la pluie

Aussi solide soit la préparation, l’instant où le typhon vous frappe le visage pour de vrai, ça fait quand même mal. Et là, ce qui est mis à l’épreuve, c’est autre chose : la capacité à assumer.

En plein cœur de la crise, il y a deux choses qu’un homme à la barre ne doit absolument pas faire — fuir, et se défausser.

Fuir, c’est se cacher soi-même en attendant que la vague passe ; se défausser, c’est se précipiter pour trouver « qui a appuyé sur ce bouton ». Sur le moment, ces deux gestes vous soulagent un peu, mais ils détruisent du même coup la chose la plus précieuse : la volonté de votre équipe de continuer à foncer. Assumer, c’est faire tout l’inverse — se tenir tout devant, prendre la décision la plus difficile sur l’instant, mais qu’il faut prendre immédiatement. D’abord, arrêter l’hémorragie : rollback quand il faut, mise hors ligne quand il faut, coupe quand il faut, aveu quand il faut, notification aux utilisateurs sans la repousser à demain. La facture, vous la reconnaissez d’abord à votre nom.

Toujours GitLab, ce jour-là. Ils ont fait une chose qui reste, aujourd’hui encore, très contre-intuitive : ils ont restauré la base de données en diffusant tout en direct, publiquement. Des milliers de personnes les regardaient étaler peu à peu leur honte — la base effacée, les cinq couches de sauvegarde toutes hors service — et réparer tout ça pièce par pièce. Ce n’était pas du spectacle. C’est la forme la plus dure de « l’assumer » : j’ai tout cassé, je le répare devant tout le monde, je ne me cache pas. Une entreprise qui ose faire ça, et alors les ingénieurs de son équipe savent : ici, quand un pépin arrive, le premier réflexe est de réparer, pas de dissimuler.

Comparez avec ces endroits où, dès qu’un incident survient, on convoque d’abord une réunion pour désigner un coupable. À peine l’incident déclaré, le premier réflexe de chacun est de chercher à se disculper : vite, sauvegarder les logs, capturer les conversations, lâcher un « ce module-là, ce n’est pas moi qui m’en occupe ». Le contraire d’assumer, ce n’est pas la panique, c’est le rejet de la faute. Celui qui refile la responsabilité vers le bas, sur l’équipe, ou vers l’extérieur, sur « la malchance », c’est la seule chose que tout le monde retiendra de lui une fois le vent tombé : cette silhouette tapie à l’arrière.

C’est le passage le plus difficile des trois, parce que prendre la pluie, ça caille pour de vrai. Trois heures du matin, l’affaire n’a toujours ni queue ni tête, tous les regards sont braqués sur vous : ce n’est pas une sensation agréable. Mais à cet instant, ce que votre équipe regarde n’a jamais été si vous paniquez ou non, si vous avez la bonne réponse toute prête — ce qu’elle regarde, c’est si, quand le feu était au plus fort, vous avez fait un pas en avant ou un pas en arrière. Ce que pèsent vraiment les heures les plus sombres, c’est la direction de ce pas-là.

III. Après le typhon : les débris partout, voilà le vrai examen

Le typhon passé, le ciel se dégage, et c’est le relâchement le plus dangereux qui s’installe. Beaucoup ont tenu bon sous la tempête, pour finir par mourir de « la flemme de nettoyer ».

Le chantier laissé par le typhon, une fois le vent tombé, voilà où l’on juge vraiment le métier. Nettoyer, ce n’est pas seulement remettre de l’ordre dans le bazar et refaire tourner le système — ça, c’est juste rétablir. Le vrai nettoyage, c’est transformer la douleur de cette fois en une règle sur laquelle on ne remarchera plus la prochaine fois : la rétrospective doit remonter jusqu’au mécanisme, changer la leçon d’aujourd’hui en une vérification qui s’appliquera automatiquement la prochaine fois, en un risque supprimé, en un plan d’urgence mis à jour.

Knight Capital, justement, est mort de ne pas avoir nettoyé. Le matin du 1er août 2012, cette société de trading haute fréquence a mis en production une nouvelle version de code ; l’ingénieur l’a déployée à la main sur 8 serveurs — et en a oublié 1. Or, sur ce serveur précisément, traînait encore un vieux bout de code d’une fonctionnalité abandonnée depuis longtemps, mais que personne n’avait jamais supprimée, portant le nom de code « Power Peg ». Le nouveau code réutilisait un interrupteur portant le même nom ; alors, sur cette machine non mise à jour, ce code mort qui aurait dû rester au tombeau s’est réveillé et s’est mis à envoyer des ordres au marché comme un fou. En 45 minutes, il a exécuté près de 397 millions d’actions sur 154 titres, pour une perte avant impôts de 440 millions de dollars. La société a été rachetée avant la fin de l’année. Disparue.

Regardez comme la chaîne est courte : un bout de code mort qu’on aurait dû supprimer mais qu’on a eu la flemme d’enlever, plus un déploiement sans vérification qui a oublié une machine — et voilà toute une entreprise qui y laisse sa peau. C’est le « ne pas nettoyer » poussé à l’extrême : les débris laissés dans le système ne disparaissent pas d’eux-mêmes, ils attendent simplement, en silence, l’étincelle qui les enflammera.

Revenons encore à GitLab. Face à un incident tout aussi mortel, ils ont ensuite rédigé une rétrospective publique jusqu’à l’automutilation, détaillant point par point comment chacune des cinq couches de sauvegarde avait échoué, puis en corrigeant chaque point l’un après l’autre. L’un a transformé ses débris en immunité, l’autre a laissé ses débris sur place à attendre l’explosion. Ce que sont devenues ces deux entreprises aujourd’hui, vous le savez.

Il y a encore, dans le nettoyage, un point qu’on inverse très facilement : nettoyez le mécanisme, pas les gens. Le but d’une rétrospective, c’est que « la prochaine fois, ce trou-là se rebouche tout seul », pas d’épingler le malheureux qui a appuyé sur le mauvais bouton. Dès que vous commencez à épingler les gens, la première chose que chacun apprend, c’est de dissimuler dès le prochain incident ; si vous ne réparez que le mécanisme, sans demander qui, alors chacun ose crier le problème dès la première seconde. Cette rétrospective « qui s’attaque aux faits, pas aux personnes » n’a pas d’abord été inventée par l’informatique : elle a poussé dans l’aviation. Quand un avion tombe, le seul but de la commission d’enquête est que les appareils du même modèle ne tombent plus jamais du ciel — pas de clouer le pilote au pilori. Parce que dès qu’on se met à clouer les gens, le prochain équipage qui commet une erreur choisira de cacher, et cacher fera tomber l’avion suivant encore plus durement. Google a plus tard inscrit cette approche dans son manuel SRE, sous un nom : le « blameless postmortem ». L’ingénieur de GitLab qui avait effacé la base n’a pas été exécuté en public — ce n’est pas de la mollesse, c’est de la lucidité. Avoir eu mal une fois, ce n’est pas grandir ; transformer la douleur en une règle qu’on ne transgressera plus, ça, c’est grandir.

IV. Retour à ce « si on avait su, pas besoin d’évacuer en pleine nuit »

Revenons maintenant au début, à cette phrase de ce matin : « Si on avait su, on n’aurait pas eu à sortir les bateaux en pleine nuit. »

Cette phrase, en réalité, est le miroir de l’erreur d’attribution du texte précédent. La dernière fois, les gens attribuaient la « sécurité » à la protection de Guanyin ; cette fois, ils attribuent la « sécurité » au fait qu’« il ne serait de toute façon rien arrivé ». L’un crédite la déesse, l’autre crédite la chance — et tous deux, en douce, annulent votre préparation de la prochaine fois.

Or la vérité, c’est que la grande majorité des « fausses alertes » sont précisément le visage d’une préparation réussie. Une organisation qui, toutes ces années, n’a jamais connu la moindre « journée passée à s’agiter pour rien », il n’y a que deux possibilités — soit elle se ment à elle-même, prenant chaque coup de chance pour la preuve que « notre système est sans faille » ; soit elle a déjà été réellement renversée une fois, et a payé son écolage dans le sang. Knight Capital n’a jamais connu de « fausse alerte », parce qu’elle lisait chaque mise en production sans incident comme un « le process est sans défaut » — et elle a lu ainsi jusqu’à ces 45 minutes.

Le typhon « Bawei » a filé vers le sud cette fois, Zhoushan passera très probablement au travers sans dommage. Mais ce qui permettra à ces pêcheurs de dormir tranquilles ce soir, ce n’est pas la petite saute d’humeur d’un typhon qui a changé d’avis, ce sont ces bateaux sortis du mouillage en pleine nuit hier soir.

Que les prochaines heures les plus sombres vous frappent ou non de plein fouet, vous ne le décidez pas. Ce que vous pouvez décider, ce sont seulement ces trois choses que ceux qui affrontent les typhons ne laissent jamais de côté : avant le typhon, réparer la digue jusqu’à ce qu’elle arrête vraiment les vagues, au lieu de la peindre sur le papier ; en plein cœur du typhon, se tenir tout devant la troupe pour y prendre la pluie ; après le typhon, balayer les débris jusqu’au bout, jusqu’à en faire une règle qu’on ne transgressera plus. Faites ces trois choses jusqu’au bout, et les autres diront que vous avez eu de la chance ; bâclez-les, et ces 45 minutes de Knight Capital finiront, tôt ou tard, par vous revenir.