9. Concevoir un changement réversible
Pourquoi ce chapitre existe
Beaucoup de plans de livraison supposent un monde idéal : le déploiement est atomique, les données sont compatibles, le comportement est immédiatement observable et un rollback restaure tout. Dans les systèmes réels, ces hypothèses échouent régulièrement. Une ancienne version peut continuer à tourner, un message peut être consommé tardivement, un partenaire peut avoir reçu un effet impossible à annuler, ou une migration peut avoir transformé des données de manière irréversible.
La réversibilité est la capacité à réduire les conséquences d'une décision erronée. Elle ne signifie pas que tout peut être annulé. Elle signifie que le chemin de retour, de compensation ou de limitation a été pensé avant que l'équipe n'en ait besoin sous pression.
Les idées essentielles
- Un rollback de code ne restaure pas automatiquement l'état, les données, les messages ni les effets externes.
- La réversibilité se construit par le séquencement, la compatibilité et la limitation du rayon d'action.
- Lorsqu'une action est irréversible, la stratégie doit déplacer la sécurité vers la prévisualisation, le contrôle et la compensation.
- Un plan de changement est crédible lorsqu'il décrit aussi l'arrêt, l'observation et la réparation.
Les différentes formes de retour
Il est utile de distinguer plusieurs réponses à une dégradation. Les confondre crée de faux sentiments de sécurité.
| Réponse | Ce qu'elle fait | Limite principale |
|---|---|---|
| Rollback | Revient à une version de logiciel antérieure | Ne défait pas les données ou effets produits par la nouvelle version |
| Désactivation | Coupe un chemin par configuration ou feature flag | Ne corrige pas ce qui a déjà été exécuté ; le flag ajoute de la complexité |
| Compensation | Produit un effet correctif explicite | Peut être coûteuse, incomplète ou soumise à des règles métier |
| Réconciliation | Compare des états et répare les écarts | Détecte souvent après coup et exige une source de vérité claire |
| Dégradation | Préserve un service réduit plutôt que l'opération complète | Peut modifier l'expérience et doit être explicite pour l'utilisateur |
Un changement sûr combine souvent plusieurs de ces mécanismes. Pour une nouvelle écriture de données, on peut introduire un schéma additif, déployer du code capable de lire les deux formes, activer progressivement la nouvelle écriture, vérifier les compteurs, puis seulement retirer l'ancien chemin. Ce déroulement peut paraître plus long que « migrer et déployer ». Il est surtout plus facile à interrompre quand une hypothèse se révèle fausse.
La compatibilité est un choix de conception
La stratégie expand / contract n'est pas réservée aux bases de données. Elle s'applique aux API, événements, fichiers et configurations. Ajouter une propriété optionnelle est généralement compatible ; changer le sens d'une propriété existante ne l'est pas. Un consommateur tolérant ne rend pas un contrat ambigu acceptable : il réduit seulement le risque de transition.
Avant de modifier un contrat, identifier les versions qui peuvent coexister et la durée réaliste de cette coexistence. Les clients mobiles, jobs planifiés et partenaires externes ont souvent des cycles bien plus lents qu'un service interne. La compatibilité doit être construite à cette échelle, non à celle du pipeline le plus rapide.
Les changements irréversibles exigent un autre niveau de preuve
Supprimer des données, envoyer un message contractuel, déclencher un paiement, publier une donnée sensible ou appliquer une règle légale à un historique sont des actions parfois irréversibles. Les traiter comme de simples déploiements transfère un risque excessif à la production.
Pour ces changements, la protection se déplace vers l'amont et l'aval : aperçus sur données représentatives, approbation informée par un propriétaire métier, limites de volume, exécution par lots, journal d'audit, sauvegarde vérifiée, réconciliation et procédure explicite de correction. Le but n'est pas d'exiger une certitude impossible. C'est de savoir, avant l'action, quel dommage est possible et qui pourra le réparer.
Un flag peut arrêter le nouveau comportement pour les requêtes futures. Il ne retire pas un événement déjà publié, ne recrée pas une donnée supprimée et ne rembourse pas un client. Son usage doit donc être accompagné d'une stratégie de traitement des effets déjà produits et d'une date de retrait.
Séquencer une transition de données et de contrat
Les changements les plus difficiles combinent souvent deux transitions : les données changent de forme pendant que les consommateurs changent de contrat. Les traiter dans une même bascule empêche de savoir où un écart est né. Une séquence plus sûre sépare les engagements : rendre le stockage capable de porter l'ancien et le nouveau sens ; déployer des lecteurs tolérants ; alimenter la nouvelle forme ; observer et réconcilier ; déplacer les consommateurs ; retirer l'ancien chemin lorsque l'usage est réellement nul.
Ce séquencement crée temporairement de la complexité. Il doit donc être associé à un critère de nettoyage. La question n'est pas « pouvons-nous garder les deux formats ? », mais « quelle preuve nous autorise à ne plus les garder ? ». Un compteur d'anciens lecteurs, une date de fin de contrat, une cohorte migrée et un rapprochement sans écart peuvent former cette preuve.
| Étape | Propriété à préserver | Échec détectable |
|---|---|---|
| Étendre le modèle | Anciennes écritures et lectures restent valides | Déploiement d'une version antérieure en environnement contrôlé |
| Lire les deux formes | Aucune donnée historique n'est perdue | Comptes et échantillons représentatifs |
| Écrire progressivement la nouvelle forme | Le nouveau comportement est correct | Cohorte, métrique et validation de contenu |
| Déplacer les consommateurs | Aucun contrat actif ne dépend de l'ancien chemin | Mesure d'usage et tests de contrat |
| Contracter | La complexité de transition disparaît sans dommage | Vérification de suppression et surveillance post-retrait |
Prévoir le point de non-retour
Certaines transitions comportent un moment où le retour exact devient trop coûteux : notification réglementaire envoyée, paiement capturé, donnée agrégée puis consommée, suppression confirmée. Ce point doit être nommé dans le plan. Avant lui, l'équipe maximise les validations et l'exposition limitée ; après lui, elle passe d'une logique de rollback à une logique de compensation, d'information et de réconciliation.
Exemple filé — Renommer un statut sans changer son sens
Une équipe remplace le statut active par deux états plus précis : trialing et paid. Modifier la valeur en place serait une rupture pour les exports et consommateurs inconnus. Elle ajoute d'abord les nouveaux états, maintient la lecture de l'ancien, publie les deux représentations dans une période de transition et mesure les clients qui lisent encore active. Les anciens enregistrements sont classés selon une règle documentée, avec une file d'exceptions pour les contrats qui ne peuvent pas être inférés. Le retrait arrive seulement lorsque les consommateurs, les données et les processus support ont quitté l'ancien vocabulaire.
Anti-patterns
Présenter le rollback comme plan complet
Un bouton de rollback est rassurant. Il est insuffisant lorsqu'un changement écrit un nouveau format, provoque des effets externes ou dépend d'une configuration elle-même modifiée. Un plan qui ne précise pas l'état après rollback ne décrit pas réellement un retour.
Mélanger migration, bascule et nettoyage
Concentrer ces trois étapes dans un même déploiement réduit le nombre apparent de tickets mais augmente la difficulté de diagnostic. Si un écart survient, l'équipe ne sait pas si la donnée, le code ou la suppression de l'ancien chemin est responsable. Séparer les étapes crée des points d'observation et de décision.
Garder indéfiniment les mécanismes de sécurité provisoires
Les flags, doubles écritures et chemins de compatibilité deviennent eux-mêmes une source de complexité s'ils ne sont pas retirés. Chaque mécanisme temporaire doit avoir un propriétaire, un critère de retrait et une échéance de réexamen. La réversibilité ne justifie pas une architecture durablement bifurquée.
Bonnes pratiques
Écrire le plan d'arrêt en même temps que le plan de livraison
Pour un changement à impact notable, documenter : les conditions d'activation, les signaux observés, le seuil qui impose d'arrêter, l'action immédiate, l'état à vérifier ensuite et la personne qui décide. Ce plan transforme une réaction improvisée en décision préparée.
Utiliser les petits lots pour apprendre, pas seulement pour livrer plus souvent
Déployer une cohorte réduite permet d'observer un comportement réel avec un rayon d'action limité. Cela ne vaut que si l'équipe a choisi ce qu'elle regarde et peut agir rapidement. Une exposition progressive sans métrique, sans seuil ni capacité de réponse est simplement un déploiement lent.
Tester la réparation quand elle est critique
Une sauvegarde jamais restaurée, un script de compensation jamais exécuté et un runbook jamais suivi sont des promesses. Les changements les plus sensibles doivent inclure un exercice raisonnable de restauration ou de réconciliation. Le test ne prouve pas tout, mais il révèle souvent les permissions, durées et hypothèses manquantes.
Checklist — Un changement peut-il être interrompu sans aggraver le problème ?
- Quelles versions, schémas ou contrats peuvent coexister pendant la transition ?
- Que restaure exactement un rollback, et quels effets lui échappent ?
- Quelle action permet de désactiver ou limiter rapidement l'exposition ?
- Comment détecterons-nous un écart, le qualifierons-nous et le réparerons-nous ?
- Les changements de données ou effets externes disposent-ils d'une compensation ou d'une réconciliation réaliste ?
- Quel mécanisme temporaire devra être retiré, par qui et selon quel signal ?
À retenir
La réversibilité n'est pas une assurance que rien ne se passera mal. C'est la capacité préparée à contenir, diagnostiquer et corriger une erreur lorsque le monde réel contredit une hypothèse. Elle s'obtient par des transitions compatibles, des lots limités et des plans de réparation aussi concrets que le plan de livraison.