Le problème à résoudre
Réécrire un système critique d’un seul coup (big bang) est la cause numéro un d’échec des projets de modernisation. Mais ne rien faire condamne l’entreprise à une dette technique paralysante.
La promesse pour la direction
Votre développeur senior maîtrise le pattern Strangler Fig : remplacer un monolithe morceau par morceau, sans interruption, en redirigeant progressivement le trafic vers les nouveaux services — la seule approche éprouvée pour moderniser sans risque.
Ce que le parcours débloque
(maîtrisé)
Risque de modernisation Progressif
Nulle
Interruption de service
moment
Réversibilité Possible à tout
Le cadre
| Élément | Valeur |
|---|---|
| Profil cible | Développeur senior / lead |
| Prérequis | Architecture, APIs, un langage objet |
| Durée | 6 mois (accélérateur) |
| Format | Blended · 70 % de pratique |
Pile technique maîtrisée à l’issue
Kong · Traefik · Spring Boot / Node · Kafka · PostgreSQL · Docker · Kubernetes
Les jalons
Une trajectoire pour un collaborateur déjà en poste. Chaque mois est validé par un livrable et un critère d’acceptation écrit à l’avance.
| Mois | Thème | Atelier | Validation |
|---|---|---|---|
| M1 | Stratégie de remplacement Strangler Fig | Identifier le premier domaine à extraire | ✔ Domaine pilote choisi et justifié |
| M2 | API Gateway / façade Routage progressif | Placer une façade devant le monolithe | ✔ Trafic routable vers l’ancien et le neuf |
| M3 | Extraction d’un domaine Service autonome | Réécrire un domaine en service indépendant | ✔ Service nouveau fonctionnel |
| M4 | Bascule progressive Canary / pourcentage | Router 10 % puis 100 % du trafic | ✔ Bascule sans incident utilisateur |
| M5 | Cohérence des données Synchronisation | Gérer les données pendant la coexistence | ✔ Données cohérentes entre les deux |
| M6 | Projet de modernisation Remplacement réel | Étrangler un module d’un système réel | ✔ Soutenance + module remplacé |