Un vendredi soir en prod down : ce que j'ai changé après

Un vendredi soir, 19h. On déploie.

20h30, l'app est complètement down.

La migration de base de données avait tout cassé. Les utilisateurs ne pouvaient plus se connecter. Les messages ont commencé à arriver. Et moi, les mains dans le terminal, à essayer de comprendre ce qui venait de se passer.

Ce soir-là, j'ai appris plus de choses sur mon métier qu'en 6 mois de développement.

Ce qui s'était passé

La migration semblait simple. Un ajout de colonne, une modification de contrainte. Validée en local, validée en staging. Sauf que le volume de données en production était 5000 fois supérieur à celui de staging.

La migration a tourné, verrouillé les tables, et tout s'est arrêté.

2h pour revenir à un état stable. 2h de sueur froide, de rollback partiel, de requêtes SQL écrites à la main sous pression, en espérant ne pas aggraver la situation.

Ce genre d'incident ne prévient pas. Une migration qui passe sans problème en local et en staging peut se comporter de façon complètement différente face au volume réel de la production. Et c'est précisément ce qui rend ce type de panne si dangereux : tous les signaux étaient au vert, jusqu'au moment où plus rien ne l'était.

Pourquoi les migrations sont le point le plus fragile d'un déploiement

Un déploiement de code, dans le pire des cas, se rollback en quelques secondes : on redéploie la version précédente, et l'app revient à son état stable. Une migration de base de données, c'est différent. Elle modifie un état persistant. Si elle échoue à mi-chemin, ou qu'elle verrouille des tables trop longtemps, revenir en arrière n'est ni instantané ni automatique.

C'est ce qui explique pourquoi une migration "simple" sur le papier peut devenir l'incident le plus long à résoudre : le rollback n'est pas un bouton, c'est une opération à concevoir.

Ce que j'ai changé le lundi matin

1. Plus jamais de déploiement le vendredi

Pas parce que c'est une règle qu'on m'a apprise dans un livre de best practices. Parce que je l'ai payée de ma soirée.

Un bug détecté un lundi, vous avez toute l'équipe disponible dans les heures qui suivent. Un bug détecté un vendredi soir, vous êtes seul, avec un week-end entier qui peut basculer dans la gestion de crise. Le risque n'est pas seulement technique, il est organisationnel : la disponibilité de l'équipe au moment de l'incident compte autant que la qualité du code déployé.

2. Le staging doit ressembler à la prod, pas y ressembler un peu

Un staging avec 1000 lignes de données ne teste pas ce qu'une migration fait sur 5 000 000 de lignes. Ce n'est pas du staging, c'est un faux sentiment de sécurité.

Un environnement de staging dont le volume de données diffère de plusieurs ordres de grandeur avec la production ne valide rien sur le comportement réel d'une migration : temps de verrouillage des tables, charge sur les index, temps d'exécution. Ces problèmes n'apparaissent qu'à l'échelle. Se contenter d'un jeu de données minimal en staging, c'est valider la syntaxe SQL, pas la viabilité opérationnelle de la migration.

3. Chaque migration doit avoir un plan de rollback écrit avant d'être exécutée

Pas dans la tête. Écrit, testé, prêt à être lancé en 30 secondes.

Quand l'app est down et que le stress monte, on ne pense plus clairement. Le plan de rollback, c'est ce qu'on a écrit quand on pensait encore bien - avant le déploiement, à froid, sans la pression d'un service down et d'utilisateurs qui n'arrivent plus à se connecter. Concevoir le rollback en même temps que la migration, et pas après coup en pleine crise, change complètement la vitesse à laquelle on retrouve un état stable.

Ce que j'applique aujourd'hui en mission

Depuis cet incident, l'audit d'un pipeline de déploiement chez un client passe systématiquement par ces vérifications :

1. Fenêtre de déploiement. Pas de migration risquée en fin de semaine ni juste avant un jour férié, sauf urgence assumée avec toute l'équipe mobilisée.
2. Représentativité du staging. Le volume de données de staging doit être suffisamment proche de la prod pour révéler les problèmes de performance, pas seulement les erreurs de syntaxe.
3. Plan de rollback documenté et testé. Chaque migration significative doit avoir sa procédure de retour arrière écrite avant l'exécution, jamais improvisée pendant l'incident.
4. Migrations découpées en étapes réversibles. Séparer l'ajout d'une colonne, son remplissage, puis l'ajout de la contrainte, plutôt qu'une seule opération bloquante sur une grande table.
5. Monitoring actif pendant le déploiement. Quelqu'un doit surveiller les métriques en temps réel pendant et juste après la migration, pas seulement recevoir une alerte une fois que tout est déjà cassé.

En conclusion : la maturité technique se voit dans la gestion de l'incident, pas dans son absence

L'app est revenue en ligne. Les utilisateurs n'ont pas tous remarqué l'incident.

Mais moi, je ne l'ai pas oublié.

Les meilleures pratiques de déploiement que j'applique aujourd'hui ne viennent pas d'une formation ou d'un article de blog. Elles viennent de ce vendredi soir où j'aurais voulu être n'importe où sauf devant mon terminal. Aucune équipe technique n'est à l'abri d'un incident en production. La vraie différence se joue dans la préparation en amont, et dans la rapidité à revenir à un état stable quand ça arrive quand même.

---

P.S. : Si votre équipe déploie encore des migrations critiques un vendredi après-midi sans plan de rollback écrit, ce n'est qu'une question de temps avant que ça vous arrive aussi.

FAQ : incidents de production et migrations de base de données

Pourquoi une migration de base de données qui fonctionne en staging peut-elle casser la production ?

Parce que le comportement d'une migration dépend fortement du volume de données. Un staging avec un jeu de données réduit ne révèle ni le temps de verrouillage des tables, ni la charge sur les index, ni les risques de timeout que ce même script peut provoquer sur des millions de lignes en production.

Faut-il vraiment éviter tout déploiement le vendredi ?

Pas systématiquement, mais les déploiements à risque (migrations de base de données, changements structurels) doivent être évités en fin de semaine. La raison n'est pas superstitieuse : c'est une question de disponibilité de l'équipe pour réagir vite en cas de problème, largement réduite un vendredi soir ou un week-end.

Comment préparer un plan de rollback pour une migration de base de données ?

Le plan doit être écrit et testé avant l'exécution de la migration, jamais improvisé pendant l'incident. Il inclut la procédure exacte pour annuler les changements de schéma, un script de restauration si nécessaire, et idéalement un test préalable sur un environnement représentatif du volume de production.

Quelles pratiques réduisent le risque d'incident lors d'un déploiement ?

Découper les migrations en étapes réversibles plutôt qu'une seule opération bloquante, maintenir un environnement de staging représentatif du volume réel de production, documenter un plan de rollback avant chaque migration critique, et assurer un monitoring actif pendant et après le déploiement.