La refonte complète d'un SI (greenfield) reste le choix le plus risqué en transformation digitale. Plus de 70 % des projets de ce type dépassent leur budget initial, et la fenêtre de compétitivité se ferme pendant les 2 à 3 ans que dure le chantier.
À l'inverse, les architectures progressives permettent de livrer de la valeur dès les premières semaines, de préserver la continuité de service et de maîtriser les coûts. Elle s'appuie sur des patterns éprouvés — Strangler Fig, Dual Write, API Layer — pour remplacer le legacy module par module, sans jamais couper la production. Cet article vous en présente les mécanismes, les pièges et une feuille de route actionnable.
Le Strangler Fig Pattern consiste à construire le nouveau système en parallèle du legacy, en détournant progressivement le trafic via un proxy. L'ancien code est décommissionné module par module, sans jamais interrompre la production. Voici comment l'implémenter en pratique.
Pendant la phase de coexistence, les deux systèmes doivent rester synchronisés. Deux patterns s'affrontent selon le niveau de cohérence requis et la tolérance à l'intrusivité.
Le Dual Write écrit simultanément dans les deux bases depuis la couche applicative — cohérence forte, mais requiert une compensation obligatoire en cas d'échec partiel.
Le Change Data Capture capture passivement les modifications depuis le journal de transactions de la base legacy et les propage via Kafka — zéro modification du code legacy, mais cohérence éventuelle : quand une donnée est modifiée dans la source (la base legacy), cette modification doit voyager jusqu'au système cible (le nouveau SI). Ce voyage prend du temps, même si ce temps est court (quelques centaines de millisecondes à 1 seconde avec Kafka bien configuré). Pendant ce laps de temps, les deux systèmes voient des données différentes. Éventuellement, ils convergent vers le même état.
Le choix entre les deux dépend d'un seul critère : peut-on accepter un délai de propagation même s’il est minime?
Positionné devant le SI legacy, l'API Gateway joue le rôle de traducteur universel : il reçoit des appels modernes (REST/JSON, GraphQL, gRPC) depuis les consommateurs, les convertit dans le format attendu par le legacy (SOAP/XML, appels directs base), puis renvoie une réponse normalisée.
Le code source du legacy n'est jamais modifié. À gauche, les composants legacy continuent de fonctionner exactement comme avant. Au centre, le Gateway permet le versioning, centralise la sécurité et crée le point de contrôle pour tous les routages à venir. À droite, les consommateurs modernes accèdent à des APIs propres, versionnées et documentées via OpenAPI 3.0.
La modernisation progressive n'est pas un projet figé : c'est un programme itératif structuré en phases. Voici la feuille de route que nous appliquons sur nos missions de transformation, adaptée aux DSI de taille moyenne (50 à 500 collaborateurs IT) du marché franco-marocain.
La modernisation progressive n'est pas un compromis timide : c'est une stratégie d'ingénierie mature, utilisée par Amazon, Netflix et Booking.com pour migrer leurs monolithes sans jamais couper le service, ce n'est pas un événement, c'est un processus continu.
Les patterns présentés dans cet article — Strangler Fig, Dual Write, CDC, API Layer — ont fait leurs preuves dans des contextes réels, en France comme au Maroc, la modernisation est accessible pour des entreprises de toute taille, avec des équipes de 5 à 10 personnes et des budgets raisonnables. La seule erreur est d'attendre que le legacy devienne une urgence.
Pour un CTO ou un DSI, le message est simple : le premier projet de modernisation progressive doit être petit (un seul module fonctionnel), mesurable (KPIs clairs : temps de réponse, taux d'erreur, coût de maintenance) et réversible (feature flags, possibilité de rollback rapide). C'est ce premier succès visible qui crée la confiance dans la démarche et débloque le budget pour la suite.
Les 5 règles d'or pour une transformation progressive réussie
1. Ne jamais migrer sans filet : tests de caractérisation avant toute extraction.
2. L'API Gateway d'abord : c'est le pivot qui rend tout le reste possible.
3. Domaine métier > technologie : découpez par valeur business, pas par couche technique.
4. Mesurer en continu : sans observabilité (Prometheus, Grafana, ELK), vous volez à l'aveugle.
5. Embarquer le métier : la transformation SI est une transformation organisationnelle autant que technique.
La question n'est plus "faut-il moderniser ?" mais "par où commencer ?". Identifiez le module qui coûte le plus cher à maintenir, ou celui qui bloque le plus vos ambitions digitales. C'est là que votre transformation commence.
