Migration: sans stratégie de rollback, la vitesse devient un risque
Beaucoup de programmes pilotent la migration avec un indicateur principal: le volume déplacé. C'est compréhensible. Mais ce n'est pas suffisant.
Le bon indicateur, surtout sur des environnements critiques, c'est la qualité du retour arrière.
Ce qui se passe en cellule de crise
Quand un lot déraille, les mêmes fragilités reviennent:
- seuil de rollback non formalisé,
- responsabilités de décision floues,
- validation métier non synchronisée,
- runbook incomplet pour le retour à l'état stable.
Dans ces moments-là, on perd du temps sur la gouvernance alors qu'il faudrait exécuter.
Pourquoi le rollback doit être conçu en amont
Un rollback crédible n'est pas une annexe.
Il doit inclure:
- un point de retour techniquement validé,
- une timebox de décision explicite,
- des critères d'arrêt observables,
- une vérification post-retour orientée service métier.
Sinon, le "plan B" existe uniquement dans les slides.
Compromis réels
Oui, une bonne réversibilité coûte:
- lots plus petits,
- coexistence plus longue,
- répétition des tests,
- charge de coordination supérieure.
Mais ce coût est maîtrisable. Le coût d'un rollback improvisé, lui, est brutal: indisponibilité prolongée, dette opérationnelle, perte de confiance.
Point de vue
Ralentir un programme n'est pas un échec quand le niveau de contrôle est insuffisant. C'est souvent la décision la plus professionnelle.
En migration enterprise, la vitesse est une conséquence de la maîtrise. Jamais l'inverse.