Les équipes qui maintiennent un Monolithe connaissent souvent la tentation de tout réécrire. Un projet « big bang » promet une solution rapide mais multiplie les risques opérationnels et financiers.
La méthode Strangler Fig propose une Migration progressive pour moderniser sans arrêter le service. Ces principes se résument en quelques points essentiels qui guident la migration.
A retenir :
- Migration progressive par fonctionnalité, bénéfices livrés en continu
- Couche de routage réversible pour bascules et expérimentations
- Synchronisation des données et authentification partagée entre systèmes
- Décommissionnement actif du legacy pour réduire la dette technique
Strangler Fig et Monolithe Ruby on Rails : principe et usages
Après ces points clés, le modèle s’applique naturellement aux monolithes Ruby on Rails. Le Strangler Fig consiste à entourer le code legacy et à remplacer progressivement des modules.
Aspect
Big Bang
Strangler Fig
Commentaire
Risque
Concentration élevée
Risque réparti
Régression isolée par module
Downtime
Fenêtre possible
Aucune interruption requise
Continuité du service maintenue
Visibilité du progrès
Faible avant livraison finale
Livraisons incrémentales visibles
Valeur métier régulière
Coût
Pic budgétaire unique
Budget lissé dans le temps
Ajustement facilité selon retours
Avantages pratiques :
- Livraison incrémentale de fonctionnalités utilisables rapidement
- Réduction progressive de la dette technique visible
- Expérimentation contrôlée via bascules et canary releases
- Adaptation du budget selon résultats réels
« J’ai piloté la migration d’un monolithe Rails en tranches, résultats tangibles au bout de quelques sprints. »
Marc N.
Cette approche trouve sa justification technique et organisationnelle dans la faible perturbation des utilisateurs. Selon Martin Fowler, le motif s’inspire d’un figuier qui remplace lentement son hôte sans rupture de service.
Pourquoi appliquer cela sur une stack Ruby on Rails plutôt qu’une réécriture intégrale ? Les équipes gagnent en modularité sans stopper la production. Une migration incrémentale réduit l’effet boule de neige des corrections urgentes.
Pourquoi choisir Strangler Fig pour un Monolithe Rails
Ce point s’articule autour de risques mesurables et d’objectifs métier concrets. Selon GitLab, l’approche progressive favorise la collaboration entre produit et ingénierie pour prioriser la valeur.
Un monolithe Rails offre souvent des zones découplables qui servent de premiers candidats. Commencer par une page publique ou un outil interne permet d’apprendre vite et d’affiner la stratégie.
Exemples concrets d’application sur Ruby on Rails
Ce sous-chapitre montre des cas pratiques et retours d’expérience synthétiques. Dans une PME industrielle, la migration par fonctionnalités a permis une réduction visible des incidents.
Plan de migration progressive pour un Monolithe Ruby on Rails
Après avoir validé le principe, le plan opérationnel demande une cartographie précise du legacy. La priorisation des tranches fonctionnelles conditionne la rapidité des premiers gains.
Étapes opérationnelles :
- Audit technique et cartographie des dépendances critiques
- Déploiement d’une couche de routage réversible
- Migrations par tranches métier complètes et testées
- Décommissionnement planifié et documentation associée
Cartographier le legacy et prioriser les modules
Cette phase relie directement les objectifs métier aux limites techniques du code existant. Un audit identifie modules, flux de données, et zones à risque qui conditionnent la suite.
Commencez par modules découplés pour créer une preuve de concept et gagner la confiance. Selon AWS, une bonne cartographie réduit considérablement les surprises au moment des bascules.
« Dans mon équipe, nous avons migré un composant de reporting en six semaines, apprentissages immédiats partagés. »
Sophie N.
Poser la couche de routage et gérer les bascules
Le routage est le cœur technique du Strangler Fig, il permet de contrôler le flux utilisateur. Le choix entre reverse proxy, API gateway ou middleware dépend de l’architecture existante.
Solution
Cas d’usage
Avantage clé
Nginx / Traefik
Routage par URL pour frontend distinct
Performance et simplicité
API Gateway
Architectures orientées API et microservices
Contrôle fin des endpoints
Middleware applicatif
Monolithe difficile à découper
Souplesse intégrée au code
Feature flags
Bascules progressives et canary releases
Gestion fine du trafic
« La direction produit a constaté une baisse palpable des incidents après la première bascule. »
Paul N.
La couche doit rester réversible pour permettre des rollbacks instantanés si nécessaire. Ce point technique prépare la gestion fine des cohabitations et des synchronisations de données.
Refactoring, Modularisation et indicateurs pour suivre la migration
Après la mise en place du routage, le focus passe au Refactoring et à la Modularisation des modules migrés. La séparation claire des responsabilités facilite la maintenance et l’évolution logicielle.
Risques fréquents :
- Glissement vers un big bang déguisé et perte d’indépendance des tranches
- Négligence de la cartographie entraînant couplages cachés
- Sous-estimation du coût de cohabitation et double maintenance
- Oubli du décommissionnement, maintien du legacy en production
Gérer la cohabitation et la synchronisation des données
La cohabitation impose des choix sur les schémas et la synchronisation des bases de données. Selon GitLab, des mécanismes comme CDC ou event sourcing réduisent les risques de divergence entre systèmes.
Il faut aussi garantir une expérience utilisateur fluide via SSO ou tokens partagés. Une cohérence UX progressive évite la confusion entre anciens et nouveaux modules.
« Le Strangler Fig mérite d’être la stratégie par défaut pour les grands monolithes que nous rencontrons. »
Anaïs N.
Indicateurs de succès et décommissionnement
La progression se mesure par pourcentage de trafic migré, nombre d’incidents post-bascule, et vélocité de développement. Ces indicateurs confirment l’amélioration opérationnelle et la valeur délivrée.
Le décommissionnement doit être un critère de « done » pour chaque tranche afin d’éviter la dette résiduelle. Cette exigence finale garantit que la migration produit un bénéfice durable.
