15h42, un vendredi. Le site d’un client vient de passer sur la nouvelle version après un déploiement qui semblait sans histoire en recette. Trois minutes plus tard, les commandes ne passent plus : une erreur fatale PHP s’affiche sur le tunnel de paiement, invisible en recette parce que la clé d’API de paiement de test ne déclenchait jamais ce chemin de code précis. Ce n’est pas un scénario rare, et c’est exactement le genre de situation où la vitesse de réaction compte plus que l’analyse complète du bug.
Le réflexe à avoir n’est pas de corriger le bug en urgence en production, mais de revenir à l’état précédent, stable, le temps de comprendre calmement ce qui s’est passé. Encore faut-il que cette procédure de retour en arrière soit prête avant l’incident, pas improvisée pendant.
Symptôme : comment reconnaît-on un déploiement cassé
Les signaux qui doivent déclencher un rollback immédiat plutôt qu’une investigation en production : une page blanche (erreur fatale PHP non affichée), un code HTTP 500 sur des parcours critiques, une chute brutale du taux de conversion sur un tunnel de commande, ou des erreurs remontées par le monitoring d’uptime juste après l’heure de déploiement connue. La corrélation temporelle avec le déploiement est le signal le plus fiable : un problème qui apparaît dans les minutes qui suivent une mise en production est, dans l’immense majorité des cas, causé par elle.
Diagnostic express avant de décider
Avant de lancer le rollback, une vérification de trente secondes suffit généralement à confirmer l’hypothèse : consulter le journal d’erreurs PHP pour voir si une erreur fatale est apparue à l’heure du déploiement.
tail -n 100 /var/log/php/error.log | grep -i "fatal"
Si une erreur fatale correspond à l’heure de bascule, la décision est prise : on revient en arrière, on n’essaie pas de corriger en direct sous pression.
Correctif : rollback des fichiers
Le rollback des fichiers dépend entièrement de la méthode de déploiement utilisée. Avec un déploiement basé sur Git et une release symlinkée (schéma classique inspiré de Capistrano, aussi utilisé par Deployer), le retour en arrière consiste à repointer le lien symbolique vers la release précédente, déjà présente sur le disque :
cd /var/www/exemple.test
ls releases/
# 20240925-1520 20240925-1540 <- la release fautive
ln -sfn releases/20240925-1520 current
sudo systemctl reload php8.2-fpm
Cette opération prend quelques secondes, car aucun fichier n'est retransféré : on change simplement la cible du lien symbolique vers du code déjà déployé et déjà validé. C'est précisément l'intérêt d'un déploiement à base de releases plutôt qu'un simple rsync qui écrase les fichiers en place, où le retour en arrière demanderait de retransférer une ancienne version complète.
Correctif : rollback de la base de données
Le rollback des fichiers seul suffit pour la majorité des incidents, mais si le déploiement a exécuté une migration de base de données (ajout de colonne, transformation de données existantes), revenir au code précédent sans restaurer la base peut créer une incompatibilité — l'ancien code ne sait pas lire la nouvelle structure de données.
# restauration d'une sauvegarde prise juste avant le déploiement
wp db import backup-avant-deploiement-20240925-1535.sql
wp cache flush
C'est pour cette raison qu'une sauvegarde de la base juste avant chaque déploiement en production n'est pas une option : sans elle, un rollback de fichiers seul peut aggraver la situation plutôt que la résoudre.
Le vrai piège : les migrations irréversibles
Certaines migrations ne peuvent tout simplement pas être annulées proprement : une migration qui supprime une colonne et sa donnée, ou qui fusionne deux champs en un seul avec perte d'information, rend le retour en arrière du code incompatible avec un retour en arrière naïf de la base. La seule protection réelle contre ce piège consiste à séparer la migration de schéma (ajout de colonne, sans suppression) du déploiement de code qui l'utilise, sur deux étapes distinctes espacées dans le temps — une pratique connue sous le nom de migration à expansion puis contraction.
Une migration qui supprime quelque chose ne devrait jamais partir dans le même déploiement que le code qui en dépend. On sépare toujours en deux étapes : d'abord ajouter, déployer, valider ; ensuite, seulement, supprimer l'ancien.
Prévention : répéter la procédure à froid
Une procédure de rollback qui n'a jamais été testée en dehors d'un incident réel a de fortes chances d'échouer précisément au moment où elle est nécessaire. Nous recommandons de rejouer le scénario complet — déploiement d'une version factice, puis rollback — sur l'environnement de recette au moins une fois par trimestre, chronomètre en main. C'est souvent à cette occasion qu'on découvre qu'un script de sauvegarde ne tournait plus depuis des semaines, ou qu'un dossier de releases n'avait jamais été nettoyé et occupait tout l'espace disque restant.
En résumé
Un déploiement raté n'est pas grave en soi : c'est le temps mis à revenir en arrière qui détermine l'impact réel sur les utilisateurs. Avoir des releases symlinkées, une sauvegarde de base systématique avant chaque déploiement et une procédure de rollback déjà testée à froid transforme un incident potentiellement long en un simple contretemps de quelques minutes.
