J'ai essayé de prendre des vacances en mars 2024. Ça a duré quatre jours.

Dès le deuxième jour, j'ai répondu à ' juste une petite question ' sur Slack. Le troisième jour, j'étais dans le hall d'un hôtel à débugger un incident de production — un problème sur nos serveurs accessibles aux clients. Le quatrième jour, ma moitié m'a dit : ' Retourne bosser. C'est pas des vacances. ' Elle avait raison.

Le problème, ce n'était pas mon équipe. Ils étaient compétents. Le problème, c'est que mon cerveau était la seule copie de la moitié des opérations de la boîte. La procédure de déploiement ? Dans ma tête. Le processus d'escalade client ? Dans ma tête. Comment relancer le service de facturation quand il freeze ? Aussi dans ma tête. Je n'étais pas indispensable parce que j'étais brillant. J'étais indispensable parce que je n'avais rien écrit.

Six mois plus tard, en septembre 2024, j'ai pris deux semaines complètes. Pas de laptop. Pas de Slack. Pas de ' petits appels '. Rien n'a cassé.

Voici ce que j'ai fait pendant ces six mois.

Étape 1 : Trouve ton bus factor

Le ' bus factor ' — une métrique morbide mais utile : combien de personnes dans ton équipe doivent disparaître avant qu'un processus s'arrête complètement ? Si la réponse est ' une ' et que c'est toi, tu n'as pas un système. Tu as une prise d'otage.

J'ai listé chaque tâche récurrente dont j'étais responsable et posé une seule question : ' Si je disparaissais demain, qui pourrait faire ça ? '

Tâche Bus factor Qui d'autre sait ?
Déploiements en production 1 (moi) Personne
Problèmes de facturation clients 1 (moi) Personne
Réponse aux alertes serveur 1 (moi) Personne
Planification de sprint 2 Co-lead
Revues de code 3 N'importe quel dev senior
Entretiens d'embauche 2 Co-lead

Trois processus critiques avec un bus factor de 1. Trois trucs qui s'arrêteraient net si j'attrapais une intoxication alimentaire. Ça, ce n'est pas de l'opérationnel. C'est un one-man-show déguisé en équipe.

Le concept vient de la culture open source, où les projets vivent ou meurent selon le nombre de contributeurs. L'article Wikipédia sur le bus factor liste des exemples chez les géants de la tech — même problème, plus grande échelle.

Étape 2 : Écris des runbooks, pas de la documentation

Cette distinction est importante. La documentation explique comment quelque chose fonctionne. Un runbook — un document de procédure opérationnelle, une recette étape par étape pour gérer une situation précise — explique quoi faire.

Documentation : ' Le service de facturation utilise les webhooks Stripe (des notifications automatiques envoyées par Stripe quand un événement de paiement se produit) pour traiter les paiements. Les événements sont mis en file d'attente dans Redis et traités par le worker de facturation. '

Runbook : ' Quand la facturation est bloquée : 1) Vérifier la taille de la file Redis : redis-cli llen billing_queue. 2) Si la file > 100, redémarrer le worker de facturation : systemctl restart billing-worker. 3) Si le redémarrage ne vide pas la file en 5 minutes, vérifier le dashboard Stripe pour les webhooks en erreur. '

Tu vois la différence ? La documentation demande de comprendre. Un runbook demande de suivre des instructions. N'importe qui sachant taper des commandes dans un terminal — l'interface texte où tu entres des commandes directement — peut suivre un runbook. Pas besoin de comprendre pourquoi Redis (une base de données en mémoire rapide souvent utilisée comme file de messages) est impliqué. Juste besoin de savoir quoi taper.

PagerDuty, une entreprise qui a construit tout son business autour de la gestion d'incidents, a publié un excellent guide sur l'écriture de runbooks qui couvre le même principe : optimiser pour l'action, pas pour la compréhension.

J'ai écrit des runbooks pour mes trois processus à bus factor 1. Chacun m'a pris 30 à 60 minutes. Voici le format :

Runbook : Déploiement en Production

Quand l'utiliser :
Lors d'un merge sur main et déploiement en production.

Prérequis :
- Accès SSH au serveur de prod (demande à l'IT si tu ne l'as pas)
- Accès au channel Slack #deploys

Étapes :
1. Merger la PR sur main
2. Attendre que les checks CI passent (GitHub Actions, ~5 min)
3. Se connecter au serveur : ssh [email protected]
4. Lancer : bash /srv/app/deploy.sh
5. Vérifier le health check : curl -s http://localhost:8080/health | jq .
6. Si le health check échoue : bash /srv/app/rollback.sh
7. Poster le résultat dans #deploys

En cas de problème :
- Le script de déploiement échoue → vérifier les logs dans /var/log/deploys/
- Le health check renvoie 503 → vérifier quel sous-système a échoué dans la réponse JSON
- Impossible de se connecter en SSH → contacter l'IT, vérifier le VPN
- Le rollback échoue → appeler Capitan. Pas sur Slack. Par téléphone.

Escalade :
Si tu es bloqué depuis plus de 15 minutes, appelle Capitan. Téléphone, pas Slack.

Pas de théorie. Pas de diagrammes d'architecture. Juste : ' quand ça arrive, fais ça. '

Étape 3 : La semaine fantôme

Écrire des runbooks ne suffit pas. Il faut les tester sur de vrais humains.

J'ai organisé une ' semaine fantôme ' — une semaine où je restais disponible mais sans toucher à aucun des trois processus. Quelqu'un d'autre suivait le runbook. J'observais.

Résultats :

  • Runbook de déploiement : Fonctionnel du premier coup. Le collègue a trouvé une coquille à l'étape 4 (mauvais chemin de fichier). Corrigé en deux minutes.
  • Runbook de facturation : Échoué à l'étape 3. J'avais écrit ' vérifier le dashboard Stripe ' sans expliquer comment s'y connecter. Les identifiants étaient dans mon gestionnaire de mots de passe perso, pas dans celui de l'équipe. Ajout d'un accès partagé — problème résolu.
  • Runbook de monitoring : Partiellement fonctionnel. Les étapes étaient correctes, mais l'interface de l'outil de monitoring avait changé depuis la rédaction du doc. Captures d'écran mises à jour.

Chaque runbook a nécessité au moins une correction. C'est normal. Quand tu écris de mémoire, tu sautes les étapes qui te semblent ' évidentes ' parce que tu les as faites 500 fois. La semaine fantôme expose ces lacunes avant qu'elles comptent — à 3h du mat' un samedi.

L'équipe SRE de Google — le groupe responsable du bon fonctionnement de l'infrastructure Google — couvre ce principe dans son livre gratuit Site Reliability Engineering : une documentation qui n'a pas été testée en conditions réelles est de la fiction.

Étape 4 : La réunion de transfert de connaissances

Pour chaque runbook, j'ai organisé une session de transfert de 30 minutes. Pas de la formation — du transfert. La formation enseigne des compétences. Le transfert transmet du contexte.

Structure :

  1. Parcourir le runbook ensemble (10 min) — la personne suit chaque étape pendant que j'observe. Pas d'aide sauf si elle est bloquée.
  2. Expliquer le ' pourquoi ' des étapes critiques (10 min) — pas nécessaire pour l'exécution, mais utile pour le jugement. ' On redémarre le worker de facturation avant d'investiguer parce que le downtime coûte X € par minute. La vitesse d'abord, la cause ensuite. '
  3. Questions-réponses (10 min) — leurs questions révèlent exactement ce que j'ai oublié de documenter.

Après la réunion, la personne est propriétaire du processus. Pas ' aide sur le processus '. Propriétaire. Je deviens le backup, pas le titulaire.

Étape 5 : Le test vacances

Deux mois après la semaine fantôme, j'ai pris un long week-end de trois jours sans laptop. Aucune urgence. Aucune ' petite question '. Les runbooks ont tenu.

Un mois plus tard, une semaine complète. Un problème mineur : le runbook de monitoring ne couvrait pas un cas particulier — disque plein sur une partition non standard. La personne d'astreinte a improvisé correctement et ajouté le cas au runbook après coup. Le système s'est amélioré tout seul, sans moi. C'est le signe que ça marche.

Un mois après : deux semaines complètes. Zéro incident nécessitant mon intervention. L'équipe m'a envoyé la photo d'un tableau blanc qui disait : ' Jour 9 : Capitan n'a pas appelé. On pense que le système marche. '

Ce dont personne ne parle

Se retirer des processus, ça ressemble à se rendre dispensable. C'est exactement ça. Et c'est le but.

Mais ça touche à quelque chose d'inconfortable — la part de ton identité liée au fait d'être ' celui qui sait tout '. Celui qu'on appelle. Celui qui sauve la mise.

Je vais être honnête : c'était bizarre quand les déploiements se faisaient sans moi. Quand les problèmes de facturation se réglaient sans un message. Quand l'alerte serveur se déclenchait et que quelqu'un d'autre la traitait en 8 minutes chrono. Une part de moi voulait qu'on ait besoin de moi.

Voici ce que j'ai obtenu à la place : la liberté. Pas seulement la liberté des vacances — la liberté au quotidien. J'ai cessé d'être un goulot d'étranglement — le point unique où toutes les décisions s'empilaient en attente. Le travail qui faisait la queue derrière moi se faisait désormais en temps réel. L'équipe allait plus vite. Je me concentrais sur les décisions qui nécessitaient vraiment mon jugement, au lieu de tâches qui nécessitaient juste ma mémoire.

Ta liste d'actions

En mars 2026, j'ai reproduit ce processus dans trois organisations différentes. Le schéma tient à chaque fois. Si tu ne peux pas prendre deux semaines de congé sans que tout casse, tu n'as pas un système — tu as l'habitude d'être occupé.

Voici ta checklist :

  1. Audite ton bus factor — liste chaque tâche récurrente, note qui d'autre peut la faire
  2. Écris des runbooks pour tout ce qui a un bus factor = 1 (compte 30 à 60 minutes chacun)
  3. Fais une semaine fantôme — quelqu'un d'autre exécute, tu observes et corriges la doc
  4. Organise des réunions de transfert — 30 minutes par processus, structurées
  5. Teste avec de vraies vacances — long week-end d'abord, puis une semaine, puis deux

Écris le runbook. Fais la semaine fantôme. Pars en vacances.

Tu reviendras reposé, et l'équipe sera plus compétente qu'avant ton départ. Ça, ce n'est pas être dispensable. C'est du bon engineering.