Checklist avant mise en production

Ne laissez rien au hasard

La procédure complète pour des maintenances sans stress ni mauvaises surprises.

Pourquoi cette checklist existe

Chaque webmaster expérimenté a une histoire de maintenance qui a mal tourné :

  • Le backup qui n’était pas complet
  • Le rollback qui n’avait jamais été testé
  • La mise à jour qui a cassé un module critique
  • La maintenance « de 30 minutes » qui a duré 6 heures

Cette checklist est le fruit de ces expériences douloureuses. Elle couvre les trois phases critiques : avant, pendant, et après la maintenance.

Conseil : Imprimez cette checklist ou utilisez notre Maintenance Planner pour générer une version personnalisée à cocher.

Phase 1 : Préparation (J-7 à J-1)

1.1 Planification

1.2 Documentation

Documentez votre procédure dans un format portable. Mdconverter.io convertit vos notes Markdown en PDF ou HTML propre, idéal pour partager avec l’équipe.

1.3 Environnement de test

Règle d’or : Ne déployez JAMAIS en production quelque chose qui n’a pas été testé en staging. Même une « petite mise à jour de sécurité ».

Phase 2 : Jour J – Avant de lancer

2.1 Backups (CRITIQUE)

Script backup avant maintenance

#!/bin/bash
# backup-pre-maintenance.sh

DATE=$(date +%Y%m%d_%H%M)
SITE="monsite"
BACKUP_DIR="/home/backups/$SITE/$DATE"

mkdir -p $BACKUP_DIR

# Backup base de données
echo "?? Backup BDD..."
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME | gzip > $BACKUP_DIR/database_$DATE.sql.gz

# Backup fichiers
echo "?? Backup fichiers..."
tar -czf $BACKUP_DIR/files_$DATE.tar.gz \
    --exclude='var/cache/*' \
    --exclude='var/logs/*' \
    /var/www/$SITE/

# Vérification
echo "✅ Backups créés :"
ls -lah $BACKUP_DIR/

# Télécharger en local
echo "⬇️ Téléchargement recommandé :"
echo "scp -r user@server:$BACKUP_DIR ./backups/"

Ne passez pas cette étape. 90% des catastrophes de maintenance auraient pu être évitées avec un backup valide et récupérable.

2.2 Vérifications techniques

# Vérifier l'espace disque
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       100G   65G   35G  65%  /
# ✅ 35G disponibles

# Vérifier la RAM
$ free -h
              total        used        free
Mem:           16G         10G         6G
# ✅ 6G disponibles

# Vérifier les processus gourmands
$ top -bn1 | head -15

# Désactiver les crons temporairement
$ crontab -l > /tmp/crontab_backup.txt
$ crontab -r
# ⚠️ Ne pas oublier de réactiver après !

2.3 Page de maintenance

2.4 Communication

Phase 3 : Pendant la maintenance

3.1 Activation

# Activer la maintenance
$ echo "7200" > /var/www/monsite/.maintenance

# Vérifier depuis l'extérieur (via proxy ou autre connexion)
$ curl -I https://monsite.com
HTTP/1.1 503 Service Unavailable
Retry-After: 7200
# ✅ Maintenance active

3.2 Exécution

Template de suivi d

# Maintenance [DATE] - Journal d'exécution

## Équipe
- Lead : [NOM]
- Support : [NOM]

## Timeline

| Heure | Étape | Statut | Notes |
|-------|-------|--------|-------|
| 02:00 | Activation maintenance | ✅ | 503 confirmé |
| 02:05 | Backup BDD | ✅ | 2.3 Go, 4 min |
| 02:10 | Backup fichiers | ✅ | 1.8 Go, 6 min |
| 02:20 | Mise à jour CMS | ✅ | v8.1.0 → v8.1.5 |
| 02:25 | Mise à jour modules | ⚠️ | Module X : erreur |
| 02:30 | Rollback module X | ✅ | Version précédente |
| 02:35 | Tests fonctionnels | ✅ | OK |
| 02:45 | Désactivation maintenance | ✅ | 200 OK confirmé |

## Incidents
- 02:25 : Module X incompatible, rollback effectué
- Action : Contacter l'éditeur avant prochaine tentative

## Durée totale : 45 min (estimé : 1h)

3.3 Tests avant réouverture

E-commerce : Faites un test de commande complet avec un vrai paiement (puis remboursez). Un tunnel qui « a l’air de marcher » peut échouer au moment critique.

Phase 4 : Après la maintenance

4.1 Réouverture

# Désactiver la maintenance
$ rm /var/www/monsite/.maintenance

# Vérifier
$ curl -I https://monsite.com
HTTP/1.1 200 OK
# ✅ Site accessible

# Pas de Retry-After résiduel
$ curl -sI https://monsite.com | grep -i retry
# (aucun résultat = ✅)

# Réactiver les crons
$ crontab /tmp/crontab_backup.txt
$ crontab -l
# ✅ Crons restaurés

# Purger le cache
$ php bin/console cache:clear --env=prod  # Symfony
$ wp cache flush                           # WordPress
$ php bin/console cache:clear              # PrestaShop

4.2 Communication post-maintenance

4.3 Monitoring post-maintenance (H+1 à H+24)

4.4 Suivi SEO (J+1 à J+7)

Procédure de rollback

Le rollback est votre filet de sécurité. Il doit être documenté, testé, et exécutable en moins de 15 minutes.

Quand déclencher un rollback ?

Immédiat

  • Site totalement inaccessible après mise à jour
  • Erreurs 500 en cascade
  • Base de données corrompue

Rapide (< 30 min)

  • Fonctionnalité critique cassée (paiement, connexion)
  • Performances dégradées > 50%
  • Bugs majeurs détectés

À évaluer

  • Bugs mineurs non bloquants
  • Problèmes esthétiques
  • Fonctionnalité secondaire impactée

→ Peut-être corriger en avant plutôt que rollback

Script de rollback type

rollback.sh

#!/bin/bash
# rollback.sh - Restauration d'urgence

set -e  # Arrêter au premier problème

SITE_DIR="/var/www/monsite"
BACKUP_DIR="/home/backups/monsite/20241214_0200"  # À adapter
DB_NAME="monsite_prod"
DB_USER="monsite"

echo "?? ROLLBACK EN COURS"
echo "===================="
echo "Backup source : $BACKUP_DIR"
echo ""

# Confirmation
read -p "Confirmer le rollback ? (oui/non) : " confirm
if [ "$confirm" != "oui" ]; then
    echo "Annulé."
    exit 1
fi

# 1. Activer maintenance
echo "1/5 - Activation maintenance..."
echo "3600" > $SITE_DIR/.maintenance

# 2. Restaurer la base de données
echo "2/5 - Restauration BDD..."
gunzip -c $BACKUP_DIR/database_*.sql.gz | mysql -u $DB_USER -p $DB_NAME

# 3. Restaurer les fichiers
echo "3/5 - Restauration fichiers..."
cd /var/www
tar -xzf $BACKUP_DIR/files_*.tar.gz

# 4. Vider les caches
echo "4/5 - Purge des caches..."
rm -rf $SITE_DIR/var/cache/*
# Adapter selon CMS

# 5. Désactiver maintenance
echo "5/5 - Désactivation maintenance..."
rm $SITE_DIR/.maintenance

echo ""
echo "✅ ROLLBACK TERMINÉ"
echo "Vérifiez le site : https://monsite.com"

Testez votre rollback AVANT d’en avoir besoin. Un rollback non testé est un rollback qui échouera au pire moment.

Checklists par type d’intervention

Mise à jour CMS mineure (WordPress, PrestaShop)

Durée typique : 15-30 min | Guide WordPress détaillé | Guide PrestaShop détaillé

Mise à jour CMS majeure

Durée typique : 1-3h

Migration de serveur

Durée typique : 2-6h (+ propagation DNS)

Pour les migrations complexes, Foxop propose un accompagnement infrastructure complet.

Mise à jour de sécurité urgente

Durée typique : 15-60 min

Pour les failles critiques activement exploitées, la rapidité prime sur le processus complet. Mais ne sautez JAMAIS le backup.

La checklist ultime (résumé)

☐ AVANT

  1. ☐ Backup complet vérifié
  2. ☐ Test sur staging OK
  3. ☐ Rollback documenté
  4. ☐ Équipe prête
  5. ☐ Page maintenance prête
  6. ☐ Communication préparée

☐ PENDANT

  1. ☐ Maintenance activée
  2. ☐ 503 + Retry-After vérifié
  3. ☐ Procédure suivie pas à pas
  4. ☐ Logs surveillés
  5. ☐ Tests avant réouverture
  6. ☐ Rollback si problème

☐ APRÈS

  1. ☐ Maintenance désactivée
  2. ☐ 200 OK vérifié
  3. ☐ Cache purgé
  4. ☐ Crons réactivés
  5. ☐ Monitoring OK
  6. ☐ Communication envoyée

Générez votre checklist personnalisée

Sélectionnez votre CMS, votre type d’intervention, et obtenez une checklist sur mesure.

Lancer le Maintenance Planner

Questions fréquentes

Combien de temps conserver les backups ?

Minimum 7 jours pour les backups quotidiens, 4 semaines pour les hebdomadaires, 12 mois pour les mensuels. Pour une maintenance spécifique, conservez le backup « pré-maintenance » au moins 30 jours, le temps de détecter d’éventuels problèmes latents.

Faut-il vraiment tester le rollback à chaque fois ?

Pour les maintenances majeures (mise à jour CMS, migration), oui. Pour les mises à jour mineures de routine, avoir une procédure de rollback documentée et testée une fois suffit. L’essentiel est que le backup soit vérifié à chaque fois.

Que faire si la maintenance dépasse le temps prévu ?

Communiquez immédiatement : mise à jour Retry-After, post réseaux sociaux, email si > 2h de dépassement. Évaluez s’il vaut mieux continuer ou rollback. Ne restez jamais silencieux.

Peut-on automatiser ces checklists ?

Partiellement. Les backups, le monitoring, la page de maintenance peuvent être automatisés. Mais les tests fonctionnels et la décision de continuer ou rollback restent humains. L’idéal : un script qui exécute les étapes automatisables et s’arrête pour validation humaine aux points critiques.