Ce que je vérifie avant chaque déploiement
Une checklist courte et pratique qui m'a sauvé d'incidents de production embarrassants plus de fois que je ne peux compter.
J'ai cassé la prod un vendredi après-midi une fois. Poussé un changement de config qui avait l'air nickel en staging mais qui référençait une URL de base de données de dev dans une variable d'environnement.
Le site entier est tombé pendant 40 minutes. Un vendredi. À 16h. Mon téléphone n'a pas arrêté de vibrer.
Depuis, j'ai une checklist. Elle n'est pas longue. Mais je la suis à chaque fois. Sans exception. Même pas pour « c'est juste un petit fix CSS ».
La checklist
1. Compare les changements
Avant de déployer, je regarde exactement ce qui part. Pas ce que je crois avoir changé — ce qui a vraiment changé.
git diff main...HEAD
Je compare le diff avec ce que j'avais prévu de modifier. S'il y a quelque chose dans le diff que je n'attendais pas, je m'arrête et je cherche pourquoi.
Ça m'a déjà permis de repérer des logs de debug accidentels, des données de test oubliées et des changements de config d'environnement que je ne savais pas avoir mis en staging.
2. Valide les fichiers de config
Les fichiers de config JSON sont fragiles. Une virgule manquante casse tout, et le message d'erreur dit généralement un truc inutile du genre « Unexpected token ».
Je colle chaque fichier de config modifié dans un validateur JSON avant de déployer. Ça attrape les erreurs de syntaxe que tes yeux vont rater à 16h un vendredi.
3. Vérifie les variables d'environnement
C'est celle qui m'a eu. Le staging et la production se ressemblent, mais les variables d'environnement sont différentes. Les URLs de base de données, les clés API, les feature flags — n'importe laquelle de ces valeurs fausse peut causer des échecs silencieux difficiles à tracer.
Je garde une checklist des variables d'environnement qui diffèrent entre les environnements et je vérifie chacune. Pénible ? Oui. Mieux que faire tomber la production ? Aussi oui.
4. Teste le parcours critique
Je ne lance pas toute la suite de tests avant chaque déploiement (c'est le boulot de la CI). Mais je teste manuellement le parcours utilisateur critique :
- Est-ce qu'un utilisateur peut s'inscrire ?
- Est-ce qu'il peut se connecter ?
- Est-ce qu'il peut faire la chose principale que notre produit fait ?
- Est-ce qu'il peut nous payer ?
Si l'un de ces trucs casse, tout le reste est sans importance.
5. Vérifie la taille des assets
Avant de livrer des changements front, je vérifie si de nouveaux assets sont déraisonnablement gros. Une image non compressée ou un bundle JavaScript non minifié peut ruiner ton temps de chargement du jour au lendemain.
Vérifications rapides :
- Aucune image au-dessus de 200KB (sauf bonne raison)
- Le CSS et le JS sont minifiés
- Pas de nouvelles polices ajoutées par accident
6. Vérifie le plan de rollback
Est-ce que je peux annuler ce déploiement rapidement si quelque chose tourne mal ?
Pour la plupart des projets, c'est git revert et redéployer. Mais si le déploiement inclut des migrations de base de données, le rollback est plus complexe. Sache ça avant de déployer, pas pendant l'incident.
Ce qui n'est pas dans ma liste
Remarque ce qui manque :
- Lancer tous les tests — la CI s'en charge. Si les tests passent en CI, je leur fais confiance.
- La code review — déjà faite avant le merge. Pas une activité de déploiement.
- Mettre à jour la documentation — important, mais pas un bloqueur pour le déploiement.
La checklist de déploiement est spécifiquement orientée « est-ce que ça va casser la prod ? ». Pas la qualité du code, la documentation ou les processus. C'est important aussi, mais ça se passe plus tôt.
La règle du vendredi
Je ne déploie plus le vendredi après-midi. Si quelque chose casse, je veux une journée de travail complète pour le corriger, pas un week-end d'angoisse.
Du lundi au jeudi, pendant les heures de bureau. C'est ma fenêtre de déploiement. Les exceptions existent, mais elles sont rares et délibérées.
Une checklist, ce n'est pas excitant. Personne n'écrit des articles de blog sur sa checklist de déploiement et ne devient célèbre. Mais l'objectif d'une checklist n'est pas d'être intéressante — c'est d'attraper le truc que tu as oublié. Et elle n'a besoin de te sauver qu'une seule fois pour valoir les deux minutes qu'elle prend.