Rollback : Revenir en arrière n'est pas aussi simple qu'il n'y paraît

Vous venez de déployer une nouvelle version de votre application. Cinq minutes plus tard, des erreurs apparaissent dans le tableau de bord de surveillance. Les utilisateurs signalent des problèmes. Votre premier réflexe est évident : remettre l'ancienne version en place. C'est le rollback dans sa forme la plus simple — revenir au dernier état stable connu pour vous donner le temps de comprendre ce qui a mal tourné.

Pour de nombreuses équipes, le rollback est la stratégie de récupération par défaut. C'est intuitif. Si la nouvelle version a tout cassé, l'ancienne fonctionnait parfaitement. Il suffit de les échanger. Mais la réalité est plus complexe. Le rollback fonctionne différemment selon ce que vous restaurez : le code applicatif, le schéma de base de données ou la configuration d'infrastructure. Chacun a ses propres mécanismes, risques et limites.

Rollback applicatif : le cas relativement simple

Revenir à une version antérieure du code applicatif est le scénario le plus simple. Vous avez une instance en cours d'exécution de votre application, et vous remplacez la nouvelle version par l'ancienne. La méthode dépend de votre stratégie de déploiement.

Si vous utilisez un déploiement blue-green, le rollback consiste à rediriger le trafic vers l'environnement qui exécute encore l'ancienne version. L'environnement green redevient actif, et l'environnement blue est retiré de la rotation. Ce basculement peut se faire en quelques secondes car les deux environnements sont déjà opérationnels et prêts.

Si vous utilisez des releases canary, le rollback signifie arrêter le flux de trafic vers la nouvelle version et tout rediriger vers la version précédente. Le canary est tué, et la version stable reprend toutes les requêtes.

Si vous utilisez des rolling updates simples, le rollback implique de redéployer l'artefact précédent sur les mêmes serveurs ou conteneurs. Cela prend plus de temps car chaque instance doit être mise à jour une par une, mais le processus reste prévisible.

Par exemple, si vous utilisez Kubernetes, une seule commande peut restaurer un déploiement vers sa révision précédente :

kubectl rollout undo deployment/my-app -n production

Cette commande demande à Kubernetes de réduire les nouveaux pods et de remonter les anciens, inversant ainsi la mise à jour progressive. Vous pouvez également spécifier une révision particulière si vous devez revenir plus d'un pas en arrière :

kubectl rollout undo deployment/my-app -n production --to-revision=3

Pour voir l'historique des révisions avant de revenir en arrière :

kubectl rollout history deployment/my-app -n production

Le principal avantage du rollback applicatif est qu'il ne modifie pas les données. Vous changez uniquement le code qui traite les requêtes entrantes. La base de données reste intacte, et aucune donnée utilisateur n'est perdue ou transformée. Cela rend le rollback applicatif relativement sûr et rapide.

Le diagramme suivant cartographie les chemins de décision pour chaque type de rollback abordé dans cette section.

flowchart TD A[Quel type de rollback ?] --> B[Application] A --> C[Base de données] A --> D[Infrastructure] B --> B1[Blue-Green : basculer le trafic] B --> B2[Canary : arrêter le trafic canary] B --> B3[Rolling : redéployer l'ancien artefact] C --> C1[Schéma modifié ?] C1 -- Oui --> C2[Exécuter la migration descendante] C1 -- Non --> C3[Aucune action BD nécessaire] C2 --> C4[Risque de perte de données ?] C4 -- Oui --> C5[Restaurer depuis la sauvegarde] C4 -- Non --> C6[Schéma restauré] D --> D1[Revenir aux fichiers de configuration] D1 --> D2[Vérifier les dépendances] D2 --> D3[Appliquer l'état précédent]

Rollback de base de données : là où ça se complique

Le rollback de base de données est un tout autre défi. Les bases de données stockent un état qui change en permanence. Lorsqu'une nouvelle version de l'application modifie le schéma de la base de données — ajout d'une colonne, renommage d'une table, changement de type de données — revenir au code applicatif seul ne suffit pas. Vous devez également restaurer la structure de la base de données à son état précédent.

C'est là que la complexité se multiplie. Prenons un scénario simple : votre nouvelle version ajoute une colonne appelée phone_number à la table users. L'application commence à écrire des numéros de téléphone dans cette colonne. Après une heure, vous découvrez un bug critique et décidez de revenir en arrière. Vous déployez l'ancien code applicatif, mais l'ancien code ne connaît pas la colonne phone_number. Plus important encore, les données déjà écrites dans cette colonne doivent être traitées. Les supprimez-vous ? Les déplacez-vous ailleurs ? Les laissez-vous en espérant que l'ancien code les ignore ?

L'approche la plus sûre est de rendre chaque migration de base de données réversible dès le départ. Cela signifie que chaque script de migration inclut à la fois une étape up qui applique le changement et une étape down qui le restaure. Lorsque vous effectuez un rollback, vous exécutez la migration down pour restaurer le schéma précédent.

Mais tous les changements ne sont pas vraiment réversibles sans perte de données. Si votre nouvelle version a supprimé une colonne encore utilisée, revenir en arrière signifie recréer cette colonne et restaurer ses données à partir d'une sauvegarde. Si votre nouvelle version a fusionné deux tables en une, revenir en arrière signifie les séparer et déterminer quelles lignes appartenaient à quelle table. Ces opérations sont risquées, chronophages et nécessitent souvent une intervention manuelle.

De nombreuses équipes acceptent cette réalité et choisissent d'éviter complètement le rollback de base de données. Au lieu de cela, elles investissent massivement dans les tests de migration avant le déploiement, en les exécutant sur des environnements de staging qui reflètent le plus possible les données de production. Quand quelque chose tourne mal, elles préfèrent écrire un correctif forward plutôt que de tenter un retour en arrière.

Rollback d'infrastructure : le réseau de dépendances caché

Le rollback d'infrastructure consiste à restaurer les modifications apportées aux serveurs, aux règles réseau, aux équilibreurs de charge ou aux services de support. Si vous gérez l'infrastructure avec des outils comme Terraform, Ansible ou Pulumi, le rollback implique généralement d'appliquer une version précédente de vos fichiers de configuration.

Le défi ici est que les changements d'infrastructure affectent rarement une seule chose. Une modification d'une règle de pare-feu peut casser la connectivité de la base de données. Un changement de configuration d'un équilibreur de charge peut affecter le routage du trafic pour plusieurs services. Revenir à un état précédent du fichier d'état Terraform pourrait supprimer des ressources créées par la nouvelle version, ce qui pourrait entraîner d'autres problèmes en cascade.

Le rollback d'infrastructure prend également du temps. Appliquer une configuration précédente nécessite d'exécuter les mêmes processus de provisionnement qui ont créé l'infrastructure initialement. Si votre infrastructure est vaste ou complexe, cela peut prendre des minutes, voire des heures — un temps pendant lequel vos utilisateurs rencontrent des erreurs.

Les limites du rollback en tant que stratégie

Le rollback n'est pas un filet de sécurité universel. Il ne fonctionne que lorsque trois conditions sont réunies :

Premièrement, l'ancienne version doit toujours être stable et compatible avec l'état actuel du système. Si votre nouvelle version a fonctionné pendant des heures et que les utilisateurs ont saisi des données que l'ancienne version ne peut pas lire, revenir en arrière entraînera une perte ou une corruption de données.

Deuxièmement, le problème doit se situer dans le code ou la configuration, pas dans les données. Si le problème est que les utilisateurs utilisent mal une fonctionnalité ou que la qualité des données s'est dégradée, revenir au code ne résoudra rien.

Troisièmement, le rollback doit être plus rapide que le temps nécessaire pour écrire un correctif forward. Si le rollback prend trente minutes mais qu'un correctif chaud en prend dix, le rollback est l'option la plus lente.

Il existe également un risque comportemental. Les équipes qui comptent trop sur le rollback peuvent devenir négligentes dans les tests pré-déploiement. L'état d'esprit devient "si ça casse, on reviendra en arrière". C'est dangereux car le rollback a un coût réel. Les utilisateurs qui ont vu des erreurs ou perdu des données ne se soucient pas que vous ayez récupéré en cinq minutes. Leur confiance a déjà été endommagée.

Liste de contrôle pratique avant de décider un rollback

Avant d'exécuter un rollback, posez-vous ces questions :

  • L'ancienne version est-elle toujours en cours d'exécution et prête à accepter du trafic ?
  • Le schéma de la base de données a-t-il changé d'une manière qui rend l'ancien code incompatible ?
  • Depuis combien de temps la nouvelle version est-elle en ligne, et combien de données utilisateur ont été saisies ?
  • La migration de base de données peut-elle être inversée sans perte de données ?
  • Le rollback est-il plus rapide que l'écriture d'un correctif forward ?
  • Avez-vous communiqué le plan de rollback à l'équipe et aux parties prenantes ?

Si la réponse à l'une de ces questions soulève un drapeau rouge, envisagez plutôt un roll-forward.

Ce qu'il faut retenir

Le rollback est une stratégie de récupération légitime, mais ce n'est pas un bouton d'annulation gratuit. Le rollback applicatif est relativement sûr et rapide. Le rollback de base de données est risqué et souvent irréversible. Le rollback d'infrastructure est lent et peut avoir des effets en cascade. Avant de faire du rollback votre réponse par défaut, comprenez ce que vous restaurez et quel sera le coût réel. Parfois, la meilleure décision est de corriger forward — et c'est ce que nous verrons ensuite.