Tu as déployé un vendredi à 17h. Tu savais que la migration n'avait pas tourné sur le staging — cet environnement qui reproduit la production pour tester avant que les vrais utilisateurs ne voient quoi que ce soit. Tu t'es dit que tu avais fait ça des centaines de fois. À 17h47, la base de données s'est verrouillée. À 18h12, ton téléphone a sonné. Tu as passé ton samedi à réparer ce qu'une vérification de deux minutes aurait empêché. 📋

Je le sais parce que j'ai été cette personne. Et parce que chaque post-mortem d'incident que j'ai lu raconte la même histoire : quelqu'un a sauté une étape qu'il savait exister.

Un pilote, un fleuve et une checklist

Le 15 janvier 2009, le commandant Chesley Sullenberger a posé le vol US Airways 1549 sur l'Hudson. Les deux moteurs avaient lâché après une collision avec des oies. Les 155 personnes à bord ont survécu. Quand les journalistes lui ont demandé comment, il n'a pas dit ' l'expérience ' ni ' l'instinct '. Il a dit que son équipage avait suivi ses checklists. La checklist panne moteur double. La checklist amerrissage. Étape par étape, sous pression maximale.

L'aviation fait ça depuis 1935, quand un vol d'essai du Boeing Model 299 s'est écrasé parce que le pilote avait oublié de déverrouiller une commande. L'avion — un prototype de bombardier quadrimoteur — était littéralement trop complexe pour la mémoire d'une seule personne. La réponse de Boeing n'a pas été ' recrutons de meilleurs pilotes '. Ça a été une simple checklist sur une fiche cartonnée. Le taux d'accidents a chuté. L'industrie n'est jamais revenue en arrière.

Ton déploiement en production — le processus qui pousse du nouveau code vers les serveurs que tes utilisateurs touchent vraiment — n'est pas moins complexe qu'un pré-vol de bombardier de 1935. Ta réponse aux incidents n'est pas moins critique qu'un amerrissage d'urgence. Mais tu te reposes encore sur ta mémoire, ton expérience, et le ' on a toujours fait comme ça '.

Pourquoi les gens compétents sautent des étapes

Ce n'est pas une question d'intelligence. C'est une question de fonctionnement du cerveau.

Les chirurgiens qui utilisent des checklists réduisent les complications de 35 % et les décès de 47 %, selon une étude majeure de l'OMS publiée dans le New England Journal of Medicine en 2009. Ce sont des personnes avec dix ans de formation médicale. Elles ne sautent pas d'étapes par négligence — elles les sautent parce que la mémoire de travail humaine cède sous la pression séquentielle.

Atul Gawande, le chirurgien qui a écrit The Checklist Manifesto, a identifié deux types de défaillance :

Les défaillances d'ignorance : Tu ne sais pas quoi faire. Elles se réduisent à mesure que le savoir se diffuse en ligne.

Les défaillances d'inaptitude : Tu sais exactement quoi faire mais tu échoues à l'exécuter. Elles augmentent parce que les systèmes deviennent toujours plus complexes. Le savoir existe. L'exécution s'effondre.

En tech, presque chaque incident de production que j'ai investigué était une défaillance d'inaptitude. Quelqu'un savait qu'il fallait lancer la migration de base de données — ce script qui met à jour la structure de la base pour correspondre au nouveau code — avant de déployer. Quelqu'un savait qu'il fallait vérifier le plan de rollback — les étapes documentées pour revenir à la version précédente si tout casse. Quelqu'un savait qu'il fallait s'assurer que le feature flag — cet interrupteur qui garde les nouvelles fonctionnalités cachées tant qu'on n'est pas prêt — était bien sur off.

Ils savaient. Ils ont oublié. À 23h, après une journée de dix heures, ils ont sauté l'étape 7 sur 12 parce que leur cerveau leur a murmuré ' j'ai fait ça des centaines de fois '. 🫶

Trois checklists dont chaque équipe tech a besoin

Voici le système. Trois checklists. Chacune cible un moment précis où la mémoire humaine flanche le plus.

Checklist 1 : La checklist de déploiement

Elle se lance avant chaque déploiement en production. Chaque item est binaire — oui ou non. Pas de jugement. Si un seul item est ' non ', tu t'arrêtes. En aviation, un seul ' non ' cloue l'avion au sol. Tes déploiements méritent le même respect.

## Pré-Deploy

- [ ] Tous les tests passent sur le staging
- [ ] Migrations de base de données testées sur le staging
- [ ] Plan de rollback documenté et testé
- [ ] Feature flags vérifiés (nouvelles fonctionnalités off par défaut)
- [ ] Dashboards de monitoring ouverts
- [ ] Ingénieur d'astreinte confirmé disponible
- [ ] Créneau de déploiement confirmé (pas vendredi à 17h)
- [ ] Changement annoncé dans le channel de l'équipe
- [ ] Métriques du précédent deploy stables depuis 24h+

## Vérification Post-Deploy

- [ ] Les endpoints de health check retournent 200
      (200 = la façon qu'a le serveur de dire ' je vais bien ')
- [ ] Taux d'erreurs non élevé par rapport à la baseline
- [ ] Parcours utilisateurs clés testés manuellement
- [ ] Métriques de performance dans la normale
- [ ] Deploy enregistré dans le changelog

Mon équipe a adopté cette checklist il y a 18 mois. Les incidents liés aux déploiements sont passés d'environ un toutes les deux semaines à un tous les trois mois. Pas parce qu'on est devenus plus malins. Parce qu'on a arrêté de sauter des étapes. ⚙️

Checklist 2 : La checklist de réponse aux incidents

Quand la production casse, ton cerveau passe en mode combat ou fuite. L'adrénaline monte. Tu veux réparer MAINTENANT. C'est exactement là que les checklists comptent le plus — parce que ton cortex préfrontal, la partie responsable de la pensée séquentielle, est la première chose que l'adrénaline met hors service.

## Minute 0-5 : Évaluer
- [ ] Confirmer que l'incident est réel (pas une fausse alerte du monitoring)
- [ ] Sévérité : S1 (panne totale), S2 (partielle), S3 (dégradée)
- [ ] Désigner un incident commander (une personne décide)
- [ ] Ouvrir un channel dédié à l'incident

## Minute 5-15 : Communiquer
- [ ] Status page mise à jour
- [ ] Clients impactés notifiés (si S1/S2)
- [ ] Parties prenantes internes notifiées
- [ ] ETA de la prochaine mise à jour communiquée
      (même si c'est juste ' on investigue ')

## Minute 15+ : Corriger
- [ ] Cause racine identifiée OU escalade déclenchée
- [ ] Correctif testé sur le staging d'abord (si possible)
- [ ] Correctif déployé en production
- [ ] Le monitoring confirme la résolution

## Post-Incident
- [ ] Post-mortem planifié sous 48 heures
- [ ] Chronologie documentée tant que les souvenirs sont frais
- [ ] Actions assignées avec responsables et deadlines
- [ ] Checklist mise à jour si une étape manquait

Ce dernier point est le moteur silencieux de tout le système. Chaque incident nourrit la checklist. Il manque quelque chose ? Ajoute-le. Quelque chose de redondant ? Supprime-le. La checklist est vivante — elle apprend de chaque échec pour que tu n'aies pas à les revivre. 🧘

Checklist 3 : La checklist de code review

La code review — quand un collègue relit ton code avant qu'il parte en production — sans checklist, c'est lire en espérant. Avec une checklist, c'est une vérification systématique que des catégories spécifiques de problèmes n'existent pas.

## Sécurité
- [ ] Pas de credentials, clés API ou tokens en dur
- [ ] Input utilisateur validé et assaini
- [ ] Requêtes à la base en requêtes paramétrées
      (empêche l'injection SQL — une attaque où quelqu'un
       glisse des commandes SQL dans un formulaire)
- [ ] Authentification vérifiée sur tous les endpoints protégés
      (endpoint = une URL spécifique à laquelle ton app répond)

## Fiabilité
- [ ] Gestion d'erreurs couvrant les cas d'échec
- [ ] Appels d'API externes avec timeouts configurés
      (API = un moyen pour les programmes de communiquer entre eux)
- [ ] Requêtes de base de données avec index sur les grandes tables
      (index = un raccourci de recherche, comme l'index d'un livre)
- [ ] Pas de requêtes N+1 (récupérer les données liées
      ligne par ligne au lieu d'un seul batch efficace)

## Maintenabilité
- [ ] Les fonctions font une seule chose
- [ ] Les noms de variables décrivent ce qu'elles contiennent
- [ ] La logique complexe a des commentaires expliquant POURQUOI
- [ ] Les tests couvrent les nouveaux chemins de code

Comment faire tenir les checklists dans la durée

Créer des checklists, c'est facile. Le difficile — ce dont personne ne parle — c'est d'empêcher l'abandon. Quatre règles :

Rends-les obligatoires, pas optionnelles. Intègre la checklist dans ton pipeline de déploiement — la séquence automatisée qui build et expédie ton code. Le bouton de deploy reste grisé tant que chaque case n'est pas cochée. Une checklist ' recommandée ' est utilisée 80 % du temps, ce qui veut dire qu'elle échoue précisément quand ça compte le plus : sous pression, la nuit, quand tu es fatigué.

Garde-les courtes. La recherche en aviation a montré que les checklists de plus de 9 items voient leur taux de respect chuter drastiquement. Si la tienne a 30 items, découpe-la en phases. Chaque phase : 5 à 9 items. Une checklist courte qui est suivie bat une longue qui est ignorée.

Révise-les chaque trimestre. Supprime les items qui n'attrapent jamais rien. Ajoute ceux issus des incidents récents. Une checklist obsolète engendre le mépris — les gens arrêtent de la prendre au sérieux quand la moitié des items semblent hors sujet par rapport à leur stack actuel.

Rends-les visibles. Épingle-les dans le channel de l'équipe. Mets-les dans l'interface de l'outil de deploy. Imprime-en une et colle-la à côté des écrans. La meilleure checklist est celle que tu vois sans la chercher.

Ce que ça te coûte

Soyons honnêtes sur les compromis. Les checklists ajoutent de la friction. Une checklist de déploiement ajoute 5 à 10 minutes à chaque deploy. Une checklist de réponse aux incidents semble atrocement lente quand la production brûle. Les checklists de code review rallongent les revues.

Cette friction est le but recherché. C'est de la lenteur délibérée dans des moments où la vitesse fait des dégâts. Un pilote ne bâcle pas son pré-vol parce que les passagers embarquent. Tu ne devrais pas bâcler un deploy parce que le PM l'a demandé pour la fin de journée.

L'autre coût, c'est la maintenance. Une checklist non maintenue est pire que pas de checklist du tout — elle enseigne à ton équipe que le process est du théâtre. Quelqu'un doit être propriétaire de chaque checklist, la revoir chaque trimestre et la mettre à jour après chaque incident. C'est du vrai travail.

Tu es dangereux maintenant

Tu te souviens de ce déploiement du vendredi ? Celui où tu as sauté la vérification de staging et passé ton samedi à reconstruire une base de données ?

Tu as maintenant trois checklists qui empêchent exactement ce genre de défaillance. Pas par la discipline, pas par la volonté — par un système qui part du principe que ton cerveau va flancher sous pression et qui l'intercepte avant que ça ne compte.

Les checklists ne sont pas une question de discipline. C'est une question d'humilité. Reconnaître que ton cerveau — aussi affûté soit-il — ne peut pas exécuter de façon fiable 15 étapes séquentielles sous stress sans en rater une. Les pilotes le savent. Les chirurgiens le savent. Les astronautes le savent.

La tech est la seule industrie où des professionnels expérimentés disent encore ' je n'ai pas besoin de checklist, j'ai fait ça mille fois '. Ce n'est pas de la confiance. C'est la phrase qui précède chaque incident évitable.

Écris la checklist. Suis la checklist. Mets à jour la checklist. Ton environnement de production te remerciera. Et la personne qui sera réveillée à 2h du matin aussi — et cette personne, c'est peut-être toi. 🛁