Services de modernisation de logiciels legacy pour les entreprises US & UE

La tarification est à périmètre fixe et tout compris, chiffrée en USD sur trois paliers. Un audit plus quick wins démarre à partir de 2 300 $ ; un refactoring systémique des premiers contextes délimités à partir de 9 200 $ ; une modernisation complète de bout en bout à partir de 28 700 $. Le chiffre exact dépend de la taille et du couplage du système, du risque de migration des données, du périmètre de conformité et de la plateforme cible. Vous voyez le budget détaillé ligne par ligne à la fin de la découverte et le validez avant qu'une seule ligne de code soit écrite. Aucune marge de recrutement, aucun surcoût d'outils, et les frais cloud tournent sur vos propres comptes, vous gardez donc le levier de coût.

Dans la plupart des cas, moderniser. Les réécritures complètes échouent à un taux bien supérieur à 50 % parce qu'elles gèlent la roadmap, multiplient le périmètre et imposent une bascule unique à haut risque. Notre approche par défaut est le patron strangler fig : maintenir le système legacy en production, router le nouveau trafic vers des microservices extraits un contexte délimité à la fois, et ne retirer le code legacy qu'après que le nouveau chemin est éprouvé en production. Une réécriture n'est justifiée que lorsque la pile legacy est impossible à maintenir, qu'il ne reste plus aucun ingénieur ou que la conformité l'impose — et même dans ce cas, nous la phaseons.

Le strangler fig est un patron de refactoring incrémental : une couche de routage se place devant le système legacy et redirige progressivement les requêtes vers de nouveaux microservices. Le code legacy continue de fonctionner pour tout ce qui n'a pas encore été migré. Chaque contexte délimité — commandes, facturation, identité — est extrait, déployé, exécuté en double pour validation, puis basculé. Le rollback est un changement de routage, pas un redéploiement. Au fil des mois, le nouveau système « étrangle » l'ancien jusqu'à ce que l'application legacy puisse être sereinement dépréciée.

La découverte et le plan de migration durent 4 à 6 semaines. La migration elle-même dépend de la taille du système et de l'appétit au risque : un monolithe .NET Framework ou PHP de taille moyenne avec 200 à 400 KLOC se stabilise généralement en 9 à 18 mois de bascule incrémentale. Les programmes mainframe et COBOL sont multi-annuels par conception. Nous travaillons par phases de 2 à 3 mois avec une bascule démontrable à la fin de chaque phase, de sorte que la valeur métier arrive en continu plutôt qu'en attendant une livraison tout-ou-rien.

Oui, c'est précisément l'intérêt du strangler fig. Le système legacy reste en production tout au long du processus. Le trafic se déplace derrière une couche de routage (passerelle API, reverse proxy ou feature flag) au fur et à mesure que chaque contexte délimité passe en ligne. Nous exécutons l'ancien et le nouveau chemin en double, comparons les résultats et ne basculons l'écriture canonique qu'une fois la parité confirmée. Les fenêtres de maintenance se limitent aux bascules de base de données et durent généralement moins d'une heure, planifiées avec votre équipe d'exploitation.

Oui. Nous avons livré des modernisations sur .NET Framework 4.x vers .NET 8, Java 8 vers Java 21 sur Spring Boot, PHP 5/7 vers PHP 8 et Node.js, Delphi/Pascal vers C# et TypeScript, Oracle Forms et PL/SQL vers PostgreSQL avec des services Node ou Java, ASP classique et VB6 vers des stacks web modernes, et AngularJS/Knockout/jQuery vers React, Vue ou Next.js. Les charges de travail COBOL et mainframe sont traitées en partenariat avec des éditeurs spécialistes du re-hébergement si nécessaire.

Les données représentent la partie la plus risquée de toute modernisation, et nous les traitons comme un flux de travail de premier ordre. Nous commençons par la capture des données modifiées (Debezium, log shipping natif ou CDC éditeur) pour maintenir les nouveaux et anciens référentiels en synchronisation. Pendant la double exécution, les écritures vont aux deux systèmes et un job de réconciliation signale les divergences dans l’heure. Nous gelons le chemin d’écriture legacy seulement après une fenêtre de parité — généralement 2 à 4 semaines — et conservons la base de données legacy en lecture seule pendant 90 jours après la bascule.

Oui, et c’est le cas par défaut. Le strangler-fig permet à la piste fonctionnalités et à la piste modernisation de fonctionner en parallèle : les nouvelles fonctionnalités atterrissent sur les microservices extraits dès le premier jour, tandis que le code legacy gère les bounded contexts pas encore migrés. Nous coordonnons les conventions de branches, les règles de frontières de service et une liste de modules legacy à ne pas toucher pour que les deux pistes ne se télescopent pas. En pratique, 20 à 30 % de la capacité de sprint de l’équipe fonctionnalités est réservée aux travaux d’intégration de modernisation ; nous en tenons compte dans le plan de phase.

Les intégrations externes sont cataloguées en discovery et classifiées par risque de migration. Les intégrations avec des API documentées sont d’abord encapsulées derrière une couche adaptateur interne, de sorte que les nouveaux microservices appellent l’adaptateur plutôt que le connecteur legacy directement. Les API fournisseur en fin de vie sont signalées et remplacées ou dotées d’un shim de compatibilité pendant la migration. Les intégrations non remplaçables pendant la migration restent dans le système legacy et sont migrées en dernier.

Cela arrive, et nous le planifions. Pendant la double exécution, un job de réconciliation compare les sorties des chemins legacy et nouveau pour chaque transaction. Les divergences sont classifiées en différences attendues (changements de comportement délibérés), bugs legacy désormais visibles, et nouveaux bugs introduits dans le code migré. Les bugs legacy découverts pendant la migration sont documentés et triagés avec vous — certains corrigés dans le nouveau service, d’autres notés comme problèmes connus à corriger après bascule.

Nous définissons trois niveaux de métriques de succès dès le départ : techniques (couverture de tests, fréquence de déploiement, MTTR, taux d’erreur sur les services migrés), opérationnels (réduction des incidents, delta de coût infrastructure, charge d’astreinte) et métier (vélocité de fonctionnalités sur le nouveau stack, time-to-market pour les nouvelles capacités). Ces métriques sont rapportées lors des revues mensuelles de programme. Chaque phase se termine par une bascule démontrable et un tableau de bord de santé affichant le pourcentage de trafic legacy.