Rollback en développement : ce que c'est, méthodes et fonctionnement

Qu'est-ce que le rollback en développement

Le rollback est une opération qui ramène le système à un état stable antérieur. Dans le contexte du développement, cela peut signifier annuler un commit dans Git, revenir sur une transaction dans la base de données ou retourner à une version précédente d'une application sur le serveur. Le terme vient de l'anglais « rollback » et est solidement établi dans le vocabulaire des développeurs de toutes les plateformes.

Le besoin d'un rollback survient lorsqu'une nouvelle modification casse la fonctionnalité, provoque des erreurs ou échoue aux contrôles de qualité. Dans un processus de développement bien organisé, le rollback n'est pas un signe d'échec, mais une procédure standard intégrée au flux de travail. Plus une équipe peut rapidement annuler une modification problématique, plus l'impact du bug sur les utilisateurs est faible.

Différents outils offrent différents mécanismes de rollback : Git propose un choix entre revert sûr et reset destructif, les bases de données prennent en charge le rollback transactionnel, et les systèmes CI/CD peuvent basculer le trafic entre les versions. Le choix de l'approche dépend du contexte et des exigences de conservation de l'historique des modifications.

Git revert vs git reset : quelle est la différence

Git revert est une méthode de rollback sûre qui crée un nouveau commit annulant les modifications précédentes. L'historique reste linéaire et tous les anciens commits sont préservés. C'est le seul choix correct pour annuler dans une branche partagée sur laquelle plusieurs développeurs travaillent. Git revert ne supprime pas l'historique — il ajoute le fait du rollback comme une nouvelle modification.

Git reset déplace le pointeur de la branche actuelle vers un commit spécifique, supprimant toutes les modifications suivantes. Selon le flag — soft, mixed ou hard — reset gère le répertoire de travail et l'index différemment. Le mode hard supprime complètement les modifications de l'historique, ce qui le rend dangereux pour les branches partagées et adapté uniquement au travail local.

Quand utiliser revert

Revert est utilisé dans les branches partagées : main, develop, release. Il préserve l'historique et permet aux autres développeurs de comprendre qu'une modification a été annulée. Après revert, vous pouvez faire git pull en toute sécurité — le système ne produira pas de conflits liés à l'historique réécrit. Dans le travail d'équipe, revert est la norme par défaut.

# Annuler le dernier commit en créant un nouveau commit
git revert HEAD

# Annuler un commit spécifique par hash
git revert a1b2c3d

Quand utiliser reset

Reset est approprié dans une branche locale où vous n'avez pas encore publié les modifications. Si vous expérimentiez et souhaitez nettoyer complètement l'historique — reset hard le fera. Dans une branche locale, vous pouvez utiliser reset mixed pour annuler les commits tout en conservant les modifications dans le répertoire de travail pour les re-commiter.

# Annuler le dernier commit, conserver les modifications dans le répertoire de travail
git reset HEAD~1

# Annuler complètement — les modifications sont supprimées définitivement
git reset --hard HEAD~2

Rollback dans les bases de données : transactions et ACID

Le rollback de transaction est une opération qui annule toutes les modifications effectuées dans la transaction en cours et ramène la base de données à l'état au début de la transaction. Cela garantit l'atomicité — l'un des quatre principes ACID (Atomicity, Consistency, Isolation, Durability). Si une erreur survient à n'importe quelle étape de la transaction, un rollback est exécuté et les données retrouvent leur état d'origine.

Le mécanisme de rollback est implémenté via le journal d'écriture anticipée (Write-Ahead Log, WAL). Avant de modifier une page de données, le SGBD écrit les anciennes et nouvelles valeurs dans le journal. Pendant le rollback, le système lit le journal et restaure les valeurs d'origine pour toutes les pages modifiées. Cela garantit que même en cas de panne de courant, la transaction peut être correctement annulée.

BEGIN TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

-- Rollback on error
ROLLBACK;

Savepoint : rollback partiel

Dans les transactions longues, il est pratique d'utiliser des savepoints — des points de sauvegarde intermédiaires vers lesquels vous pouvez revenir sans terminer toute la transaction. Cela permet de gérer les erreurs au sein d'une opération complexe sans perdre la progression sur d'autres parties. Les savepoints sont pris en charge par la plupart des SGBD relationnels : PostgreSQL, MySQL, Oracle.

SAVEPOINT sp1;

UPDATE orders SET status = 'cancelled'
WHERE id = 42;

ROLLBACK TO sp1;

Rollback lors du déploiement : stratégies et outils

Le rollback de déploiement consiste à ramener une application en cours d'exécution à une version précédente après un déploiement échoué. C'est une capacité critique pour les environnements de production : le temps de récupération (MTTR) affecte directement le SLA et l'expérience utilisateur. Les plateformes modernes offrent plusieurs stratégies de rollback selon l'architecture et les exigences de disponibilité.

Déploiement Blue-green

Blue-green est une stratégie où deux environnements identiques fonctionnent simultanément : blue (version actuelle) et green (nouvelle version). Le trafic bascule vers green après un déploiement réussi. Si la nouvelle version fonctionne incorrectement, le commutateur de trafic revient à blue. Le rollback est effectué instantanément, sans redéploiement — il suffit de modifier le routage.

Canary release avec rollback automatique

Le déploiement Canary dirige une petite partie du trafic vers la nouvelle version et surveille les métriques : taux d'erreur, temps de réponse, pourcentage de requêtes réussies. Si les métriques se dégradent, le système annule automatiquement le canary et redirige tout le trafic vers la version stable. Kubernetes et les maillages de services (Istio, Linkerd) prennent en charge cette stratégie nativement.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Exemples pratiques de rollback en développement

Examinons trois scénarios typiques dans lesquels un développeur doit annuler des modifications. Chaque scénario nécessite sa propre approche — d'une simple commande dans le terminal à une procédure en plusieurs étapes impliquant CI/CD.

Scénario 1 : commit accidentel dans main

Vous avez accidentellement poussé un commit avec un bug dans main. Votre tâche est d'annuler les modifications sans perdre l'historique pour l'équipe. Utilisez git revert pour créer un commit d'annulation, puis git push. Tous les membres de l'équipe verront le rollback et pourront continuer à travailler sans conflits. C'est la méthode la plus sûre et la plus transparente.

git checkout main
git pull origin main
git revert HEAD
git push origin main

Scénario 2 : migration de base de données échouée

Une migration de base de données a échoué et certaines données sont corrompues. Utilisez le rollback transactionnel dans le script de migration et restaurez à partir de la sauvegarde pour les modifications déjà appliquées. Dans un système bien conçu, chaque migration est encapsulée dans une transaction — en cas d'erreur, le SGBD effectue automatiquement un rollback.

Scénario 3 : déploiement avec bug critique

Après avoir déployé une nouvelle version, vous découvrez que l'authentification ne fonctionne pas. Si vous utilisez blue-green, le rollback consiste à rebasculer le routeur. Si c'est une mise à jour continue — la commande kubectl rollout undo ramènera la version précédente. Idéalement, le processus de rollback devrait être automatisé et ne pas prendre plus d'une minute.