Quels critères utilisez-vous pour choisir entre un rollback et un hotfix ?

Question

Accepted Answer

Par défaut, **rollback** — c'est la façon la plus rapide et la plus fiable de rétablir un état connu comme sain. Ne recourir à un **hotfix** que lorsque le rollback est impossible ou plus dangereux que de corriger en avançant. Dans un incident actif, la priorité est de **stopper l'hémorragie d'abord**, diagnostiquer ensuite.

## Les critères de décision

- **Le rollback est-il sûr et possible ?** Si la version précédente est connue comme saine et que rien d'irréversible ne s'est produit, faire un rollback. C'est la réponse habituelle.
- **La mauvaise release a-t-elle créé un état irréversible ?** Une **migration de base de données** ou une corruption de données peut rendre le rollback pire que le bug. Si vous ne pouvez pas revenir en arrière en sécurité, vous devez corriger en avançant.
- **Comprenons-nous le correctif ?** Le rollback ne nécessite aucun diagnostic — c'est sa force. Un hotfix que vous ne comprenez pas pleinement peut aggraver l'incident ; ne jamais livrer une supposition en prod sous pression.
- **Temps jusqu'à un état sûr.** Choisir la voie qui atteint la stabilité le plus vite avec le moins de risque. Un hotfix d'une ligne bien compris peut battre un rollback complexe ; un fix-forward risqué ne bat jamais un revert propre.
- **Rayon d'impact et sévérité.** Une panne totale exige le rétablissement le plus rapide possible (généralement un rollback) ; une dégradation mineure peut autoriser un hotfix soigné.

## Une table de décision rapide

| Situation | Choisir |
| --- | --- |
| Version précédente saine, pas de migration | Rollback |
| Migration DB irréversible livrée | Hotfix / fix-forward |
| Cause inconnue, impact sévère | Rollback (gagner du temps) |
| One-liner trivial et bien compris | Hotfix |
| Le rollback lui-même est risqué/non testé | Hotfix |

## Arbitrages et pièges

- Le **rollback** est sûr mais ne traite que le symptôme — vous devez toujours un vrai correctif et un postmortem.
- Le **hotfix** s'attaque à la cause racine mais saute le filet de sécurité habituel ; les bugs dans les hotfixes sont fréquents précisément parce qu'ils sont précipités.
- Un **chemin de rollback non testé** est un piège — si vous ne l'avez jamais répété, il peut échouer au moment où vous en avez le plus besoin. Répétez les rollbacks avant d'en avoir besoin.
- Se méfier du **débogage en production** sous pression ; si vous êtes à plus de quelques minutes d'un correctif sûr, faites un rollback et enquêtez calmement.

## Pourquoi c'est important

Cette décision survient au pire moment possible — système down, horloge qui tourne, tout le monde qui regarde. Un Tech Lead doté d'une règle claire et répétée pour cela réduit drastiquement le MTTR et évite l'erreur classique de vouloir être malin en plein incident alors que l'ennuyeux revert était juste là. Rétablir d'abord, être malin ensuite.

Situation	Choisir
Version précédente saine, pas de migration	Rollback
Migration DB irréversible livrée	Hotfix / fix-forward
Cause inconnue, impact sévère	Rollback (gagner du temps)
One-liner trivial et bien compris	Hotfix
Le rollback lui-même est risqué/non testé	Hotfix