Pourquoi les changements sont difficiles
- Les tests ne reproduisent jamais toutes les données, charges, configurations et dépendances réelles.
- Les API et services tiers évoluent indépendamment.
- Une version peut regrouper plusieurs changements, ce qui complique l’identification du responsable.
- Un retour à une ancienne version peut aussi annuler des améliorations sans rapport avec l’incident.
- Ne plus changer n’est pas viable : le produit, les besoins et les dépendances continuent d’évoluer.
Le risque combine la probabilité d’un incident et son impact. Les feature flags agissent surtout sur l’impact : moins d’utilisateurs exposés, détection plus nette et désactivation immédiate.
Réactions classiques avant les flags
Une version peut contenir plusieurs fonctionnalités, dont une seule est fautive. Un rollback remet tout le monde sur la version précédente, mais retire aussi les changements sains et peut prendre plusieurs minutes ou heures. Un revert ou correctif isole le changement, mais exige de modifier, tester et redéployer sous pression. Ni l’un ni l’autre ne restaure forcément une migration de données ou une dépendance externe. Le problème fondamental est le couplage entre le binaire déployé et le comportement actif.