Checklist pré-déploiement : zéro panne du vendredi

On l’a tous vécu. Le vendredi, 16h47. Quelqu’un dit « ça va, c’est un petit déploiement ». Et là, bim. Alertes. Latence qui grimpe. Paiement qui tombe. Support qui sature. Et toi qui te demandes pourquoi tu n’as pas choisi une carrière dans la poterie.

Le pire, c’est que ces « pannes du vendredi » ont l’air d’un mauvais karma. Mais en vrai, elles sont très souvent... logiques. Prévisibles, même. Et c’est justement la bonne nouvelle, parce que ce qui est prévisible peut être évité.

Pourquoi les « pannes du vendredi » arrivent (et pourquoi ce n’est presque jamais de la malchance)

Le vendredi en prod, c’est un cocktail simple : pression de finir la semaine, fatigue accumulée, agenda plein, et un biais mental assez violent qui dit « on verra lundi ». Sauf que la prod, elle, ne voit pas lundi. Elle voit des utilisateurs maintenant.

Et les causes récurrentes, ce n’est pas « la malchance ». C’est plutôt :

• des changements mal cadrés, avec un scope flou. Le fameux « tant qu’on y est ».
• des validations incomplètes. Personne n’a testé le parcours critique, juste « ça marche chez moi ».
• une fenêtre de déploiement mal choisie. Déployer juste avant un pic de trafic, ou quand l’équipe d’astreinte est réduite.
• un rollback absent, ou pire, « possible en théorie » mais jamais testé.

Bref, le vrai coupable, c’est souvent un change management trop mou ou trop implicite. Pas un gros comité lourd qui bloque tout, non. Un process léger mais strict, centré sur une checklist pré-déploiement.

Promesse de cet article : une checklist actionnable, copiable, adaptable, pour viser « zéro surprise » après mise en prod. Zéro panique surtout.

Ce que veut dire « checklist pré-déploiement » (et ce qu’elle doit absolument éviter)

Une checklist pré-déploiement, c’est une suite de contrôles minimaux. Des reproductibles. Auditables. Qui doivent être vrais avant d’appuyer sur « deploy ». Pas un roman, pas un vœu pieux.

Et attention au périmètre : pré-déploiement, c’est avant prod. Donc cadrage, validations, tests, plan, rollback, communication. Le post-déploiement, c’est autre chose : monitoring, validation en prod, suivi d’incident, post-mortem.

Ce qu’une checklist doit éviter à tout prix :

• trop longue. Si personne ne la suit, elle ne sert qu’à décorer Notion.
• trop vague. « Vérifier que tout va bien » n’a jamais sauvé personne.
• non adaptée aux types de changements. Un patch front et une migration DB, ce n’est pas le même sport.

Le bon principe, c’est 80/20 : couvrir les causes fréquentes d’incidents avec des contrôles simples et obligatoires. Et si possible, automatisables.

Pré-requis : classer le changement avant de dérouler la checklist

Avant de cocher 40 cases, il faut une mini qualification. En gros : type de changement, criticité, impact, réversibilité.

Je propose 3 catégories simples, parce que si tu en mets 12, personne ne saura où ranger son change :

• Standard : faible risque, routine, rollback facile.
• Normal : risque modéré, impact possible, nécessite une vraie revue.
• Urgent : nécessaire mais risqué, souvent sous contrainte (incident, sécurité).

Ensuite, deux questions qui font mal mais qui sauvent :

• existe-t-il une marche arrière réaliste (rollback) ?
• y a-t-il une dépendance externe (vendor, réseau, DNS, certificat, paiement) ?

Et enfin, la question qui évite 80 % des drames : quelle est la fenêtre de déploiement la plus sûre ? Spoiler : pas vendredi soir, pas juste avant un pic, pas quand la moitié de l’équipe est déjà mentalement en week-end.

Les 5 questions de triage (à répondre en 2 minutes)

1. Quel est l’impact utilisateur si ça casse (SLA, parcours critique, chiffre d’affaires) ?
2. Quelle est la surface de changement (front, API, DB, infra, sécurité) ?
3. Existe-t-il une marche arrière réaliste (rollback) ?
4. Y a-t-il une dépendance externe (vendor, réseau, DNS, certificat, paiement) ?
5. Quelle est la fenêtre de déploiement la plus sûre (pas vendredi soir, pas avant un pic) ?

Si tu bloques sur une réponse, c’est souvent un signal : soit le change est mal défini, soit il est trop risqué pour être « vite fait ».

Checklist pré-déploiement : la version « zéro panne du vendredi » (à copier-coller)

Utilisation recommandée : coche avec des preuves. Des liens vers PR, pipeline, ticket, runbook. Pas juste « oui ». Le « oui » s’oublie. Le lien, non.

Autre règle : tout ce qui peut être vérifié par CI/CD devrait l’être. Moins d’humain, moins d’oublis.

Voici la checklist, en blocs : cadrage → validation → préparation technique → sécurité → plan de déploiement → rollback → communication.

1) Cadrage et documentation du changement

• Objectif du changement écrit en une phrase (le « pourquoi »).
• Périmètre clair : ce qui change, et ce qui ne change pas (pas de « tant qu’on y est »).
• Critères de succès mesurables : métriques, logs attendus, comportement applicatif observables.
• Ticket ou change record à jour : owner, date et heure, environnements, liens vers PR, release, artefacts.
• Inventaire des composants touchés : services, tables, jobs, files, caches, feature flags, IAM si concerné.

Tu veux un truc bête ? Si tu n’arrives pas à décrire le scope en 5 lignes, c’est probablement trop gros pour un déploiement serein. Ou pas assez pensé.

2) Revue et validations (humaines) indispensables

• Code review faite par une personne non auteure (focus : logique, edge cases, lisibilité, risques).
• Validation produit ou ops si impact utilisateur (parcours critique, message support, timing).
• Approbation alignée à la criticité (ex : manager on-call, ou un mini CAB pour changement à risque).
• Plan de test clair : qui teste quoi, où, quand. Et ce qui est bloquant.

C’est ici que beaucoup d’équipes trichent sans s’en rendre compte. « Oui c’est relu » veut parfois dire « j’ai scrollé la PR ». Non. Il faut une vraie lecture, même courte.

3) Qualité et tests (ce qui doit être vrai avant prod)

• Pipeline CI au vert : build, tests unitaires, lint, analyse statique.
• Tests d’intégration ou e2e exécutés sur un environnement proche de la prod (staging réaliste).
• Non régression sur les flux critiques : login, paiement, recherche, création, selon ton produit.
• Gestion des données : migrations testées sur données réalistes, temps d’exécution estimé, verrouillages connus.
• Performance : pas de régression évidente (latence, CPU, mémoire, DB). Un check simple suffit parfois.

Point sensible : les migrations DB. Le « ça devrait passer » est un mensonge poli. Mesure le temps, vérifie les index, estime les locks. Et si c’est long, planifie une fenêtre adaptée.

4) Gestion des dépendances et de la configuration

• Dépendances listées : versions d’API, librairies, images Docker, jobs, queues, caches.
• Compatibilité ascendante et descendante validée (backward et forward compatibility) si déploiement progressif.
• Configuration séparée du code : variables d’environnement, secrets, paramètres, fichiers de config.
• Feature flags prêts : stratégie d’activation progressive, et désactivation possible sans redéployer.
• DNS, certificats, quotas vérifiés si concernés (souvent oubliés, souvent catastrophiques).

Le piège classique : « on change juste un endpoint ». Et tu découvres après que le client mobile en prod n’est pas à jour. Donc compatibilité, toujours.

5) Sécurité et conformité (sans transformer ça en usine à gaz)

• Scan secrets : aucun secret commité, y compris dans l’historique récent si possible.
• Contrôles de vulnérabilités minimum sur les composants modifiés (SCA, containers).
• Revue des permissions si changement infra ou IAM (principe du moindre privilège).
• Logs et audit : l’observabilité ne régresse pas (niveau de logs, traçage, corrélation).

Ce bloc doit rester léger, mais non négociable. Le déploiement « rapide » qui introduit un secret en clair, c’est une dette qui explose très vite.

6) Plan de déploiement minute par minute (le vrai anti-panique)

• Runbook simple : étapes ordonnées, commandes, prérequis, temps estimés.
• Stratégie de déploiement choisie et justifiée : canary, blue green, rolling, ou maintenance.
• Freeze défini sur les systèmes dépendants pendant la fenêtre (pas de change concurrent).
• Pré-prod check : version exacte à déployer, tags, artefacts immuables, checksum si pertinent.
• Point d’arrêt go ou no go défini : qui décide, et sur quels signaux.

Un bon runbook, ce n’est pas un doc parfait. C’est un doc qui évite la phrase « attends je retrouve la commande ».

7) Rollback / plan de retour arrière (non négociable)

• Rollback réaliste défini : version précédente, switch de trafic, désactivation feature flag.
• Cas DB traité : migrations réversibles, scripts de correction, sauvegarde, ou stratégie restore.
• Temps de rollback estimé + seuil de décision : à partir de quand on annule (ex : erreurs 5xx > X % pendant Y minutes).
• Rollback testé au moins une fois sur staging. Sinon, c’est un mythe.

Le rollback, c’est le cœur du « zéro surprise ». Pas parce qu’il sera forcément utilisé. Parce que le simple fait de le préparer force à comprendre le change. Et ça, ça réduit déjà le risque.

8) Communication et coordination (le change management côté humain)

• Parties prenantes informées : support, on-call, équipes dépendantes, stakeholders.
• Canal unique pendant le déploiement (Slack, Teams) + un responsable de communication.
• Plan d’escalade clair : qui contacter si DB, réseau, vendor, paiement, sécurité.
• Message prêt pour incident : statut, impact, contournement, ETA.

C’est bête, mais préparer un message type te fait gagner un temps énorme quand ça chauffe. Et surtout, ça évite les silences radio qui paniquent tout le monde.

Les garde-fous spécifiques pour éviter le déploiement « à risque » le vendredi

Règle simple : éviter les changements irréversibles en fin de semaine. Typiquement : DB, infra, auth, paiement, IAM, réseau, DNS. Tout ce qui peut casser large, et qui demande plusieurs personnes pour réparer.

Mettre une « fenêtre safe » aide beaucoup : déployer tôt, mardi ou mercredi. Laisser le temps d’observer. Avoir une journée pleine devant soi si ça part de travers.

Et si vraiment tu dois déployer en fin de semaine, il te faut des conditions très strictes : rollback testé, runbook clair, monitoring renforcé, astreinte disponible, et pas de dépendances externes instables.

Exemples concrets : ce qui passe / ce qui ne passe pas

Passe :

• changement derrière feature flag désactivé.
• patch documentation, ou changement interne sans impact prod.
• config non critique avec rollback immédiat.

Passe avec conditions :

• hotfix client impactant, mais avec runbook, rollback testé, et validation monitoring en direct.
• petit correctif ciblé, canary sur un pourcentage faible, puis montée progressive.

Ne passe pas :

• migration DB non réversible.
• changement IAM large (permissions, rôles, policies).
• refonte réseau ou DNS.
• upgrade majeur sans canary ni compatibilité.
• changement sur paiement ou authentification sans fenêtre large et équipe complète.

Si tu lis « ne passe pas » et que tu te dis « oui mais on n’a pas le choix »… alors il faut traiter ça comme un changement urgent, avec une vraie cellule de déploiement. Pas un coup de poker.

Comment rendre la checklist réellement appliquée (sinon elle finit dans un dossier)

Une checklist n’échoue pas parce qu’elle est mauvaise. Elle échoue parce qu’elle est en dehors du flux.

Donc :

• intègre-la au template de pull request. Avec cases à cocher, et liens demandés.
• intègre-la au template de ticket de changement. Même logique.
• rends certains points bloquants via CI/CD : tests, lint, scan secrets, scans vulnérabilités.
• prépare l’observabilité : un dashboard prêt, et des alertes de base (erreurs, latence, saturation).
• impose une mécanique simple de feature flags, pour activer ou désactiver vite.

L’idée, ce n’est pas de fliquer. C’est de rendre la bonne action plus facile que la mauvaise.

Mini-outillage recommandé (léger, pragmatique)

• Un modèle de checklist dans Jira, Linear, Notion ou Google Docs, selon la culture de l’équipe.
• CI avec checks obligatoires avant merge et avant release (tests, lint, scan secrets).
• Un dashboard standard par service, avec trois métriques minimales : erreurs, latence, saturation.
• Un système de feature flags simple, outil dédié ou maison, mais accessible et rapide à utiliser.

Pas besoin de révolution. Juste de la répétition. Et un peu de discipline.

Conclusion : votre objectif n’est pas « déployer plus », c’est « déployer sans surprise »

Si je résume, la checklist « zéro panne du vendredi », c’est : cadrage → validations → tests → dépendances → sécurité → plan → rollback → communication.

Et le point clé, vraiment, c’est le duo rollback testé + runbook clair. Ça enlève la panique. Ça enlève l’improvisation. Et même quand ça casse, tu sais quoi faire, dans quel ordre, avec qui.

Copie la checklist. Adapte-la à tes changements. Puis rends-la obligatoire au moins pour les changements « normal » et « urgent ». Tu verras, le nombre d’incidents baisse. Et surtout, le niveau de stress aussi.

Dernière phrase à garder en tête avant d’appuyer sur « deploy » : si tu ne peux pas expliquer comment revenir en arrière, tu n’es pas prêt à déployer.

Questions fréquemment posées

Pourquoi observe-t-on souvent des pannes en production le vendredi ?

Les pannes du vendredi sont souvent dues à un cocktail de facteurs comme la pression pour finir la semaine, la fatigue accumulée, un agenda chargé et un biais mental qui pousse à reporter les vérifications au lundi. Ces pannes ne sont généralement pas une question de malchance, mais résultent de changements mal cadrés, validations incomplètes, fenêtres de déploiement mal choisies ou absence de procédures de rollback testées.

Qu'est-ce qu'une checklist pré-déploiement efficace ?

Une checklist pré-déploiement efficace est une liste concise, claire et reproductible de contrôles minimaux à valider avant toute mise en production. Elle doit être adaptée au type de changement, auditables et centrée sur les causes fréquentes d'incidents. Elle évite d'être trop longue ou vague pour garantir qu'elle soit suivie rigoureusement.

Quels sont les éléments clés à vérifier avant un déploiement en production ?

Avant un déploiement, il faut vérifier le cadrage du changement, les validations fonctionnelles et techniques, les tests sur les parcours critiques, le plan de déploiement incluant la fenêtre horaire, la présence et le test d'un rollback réaliste ainsi que la communication avec les équipes concernées.

Comment classifier un changement avant de lancer une checklist pré-déploiement ?

Il est recommandé de classer le changement en trois catégories : Standard (faible risque), Normal (risque modéré) et Urgent (risqué et sous contrainte). Cette classification permet d'adapter les contrôles nécessaires selon la criticité, l'impact utilisateur, la réversibilité du changement et les dépendances externes.

Pourquoi éviter de déployer juste avant un pic d'activité ou en fin de semaine ?

Déployer juste avant un pic d'activité ou en fin de semaine expose à des risques accrus car l'équipe d'astreinte peut être réduite ou moins disponible. Cela complique la gestion rapide des incidents. De plus, l'activité élevée augmente l'impact potentiel des erreurs. Il est donc conseillé de choisir des fenêtres plus sûres pour limiter ces risques.

Quelles questions rapides aideront à trier efficacement un changement avant déploiement ?

Les cinq questions essentielles sont : 1) Quel est l'impact utilisateur si ça casse ? 2) Quelle est la surface du changement (front-end, API, base de données...) ? 3) Existe-t-il une marche arrière réaliste (rollback) ? 4) Y a-t-il des dépendances externes critiques (réseau, DNS, paiement) ? 5) Quelle est la fenêtre horaire la plus sûre pour le déploiement ?