Qu’est-ce que la migration web legacy ?
La migration web legacy sort une application web de fondations qui ne la servent plus : un framework qui n’est plus maintenu, un monolithe que chaque équipe doit toucher, une couche de données qui résiste au changement ou un hébergement qui ne peut pas monter en charge. Le résultat conserve ce dont l’entreprise dépend, les règles, les données, les URL et les intégrations, sur une structure que votre équipe peut faire évoluer.
La partie la plus difficile est rarement le nouveau code. C’est tout ce que l’ancien système fait sans que personne ne l’ait écrit : le cas particulier ajouté pour un client il y a des années, la tâche nocturne qui corrige discrètement des données erronées, le partenaire qui appelle encore un endpoint oublié. Une migration réussit lorsque ces comportements sont identifiés avant la bascule, pas après.
Ce travail relève de notre expertise en conseil en développement web. Les périmètres typiques comprennent le passage d’un frontend AngularJS ou jQuery à un framework actuel, le découpage d’un monolithe en modules, la mise à niveau d’un backend en retard de plusieurs versions majeures ou le remplacement d’une plateforme maison par une solution maintenue. Lorsque des serveurs ou des data centers déménagent aussi, nos consultants cloud rejoignent le plan.
Les signes qu’il vous faut une migration web legacy
Le legacy n’est pas une question d’âge. Une application de cinq ans peut être saine et une application de deux ans être déjà un handicap. Ces signaux nous indiquent que le coût du statu quo a dépassé celui de la migration.
Le framework ou le runtime n’est plus maintenu
Les correctifs de sécurité ont cessé ou vont bientôt cesser, et chaque audit relève le même constat avec une urgence croissante.
Recruter sur la stack est devenu difficile
Peu de développeurs veulent travailler sur cette technologie, et ceux qui la connaissent sont sur le départ ou déjà surchargés.
De petites fonctionnalités exigent de gros changements
La logique métier est imbriquée avec l’interface et la base de données : une modification mineure touche des dizaines de fichiers et impose un test de non-régression complet.
Les intégrations reposent sur des protocoles dépassés
Partenaires, prestataires de paiement ou systèmes d’identité évoluent, et l’ancienne application ne peut pas suivre sans refonte majeure.
Aucun de ces signaux n’impose une réécriture complète. Ils signifient en revanche que la structure actuelle a besoin d’un plan, car attendre transforme généralement une série de phases maîtrisables en un seul projet précipité avec une échéance ferme.
Ce que couvre notre audit de migration
L’audit transforme une application qui vit dans la mémoire des équipes en une cartographie écrite. Les dépendances font l’objet d’une attention particulière, car elles déterminent l’ordre des phases ; notre guide sur la gestion des dépendances applicatives en migration explique pourquoi les blocages s’enchaînent en cascade lorsqu’ils sont découverts tard.
Inventaire des fonctionnalités et des règles métier
Chaque écran, tâche, endpoint et règle exécutés par l’ancien système, y compris ceux non documentés, repérés dans les logs et les chemins de code.
Cartographie des dépendances et des intégrations
Bases de données, partenaires, services internes et tâches planifiées, avec qui appelle quoi et à quelle fréquence.
Stack et structure cibles
Le framework, les modules et le modèle de données vers lesquels l’application migrera, choisis selon les compétences de votre équipe et votre roadmap.
Plan de phases avec rollback par phase
La migration découpée en tranches livrables, chacune avec ses critères d’entrée, ses contrôles de validation et un chemin de retour testé.
Stratégie de migration des données et des URL
Comment les enregistrements migrent et restent cohérents, et comment les liens existants, les redirections et la visibilité dans les moteurs de recherche sont préservés.
L’audit est utile en soi. Certaines équipes mènent la migration elles-mêmes, plan en main ; d’autres nous demandent de piloter les premières phases et de passer la main une fois le modèle éprouvé sur le trafic de production.
Vous préparez une migration ?
Un audit de migration dure 2 à 4 semaines et se conclut par un plan de phases, un rollback pour chaque phase et une structure cible.
Comment nous migrons : quatre phases
Ces quatre phases décrivent l’ensemble de la mission, du premier inventaire au jour où les anciens serveurs sont éteints. Au sein de la troisième, l’application elle-même migre en de nombreuses tranches plus petites, chacune livrée et validée avant que la suivante ne commence.
PHASE 01
Cartographier
Fonctionnalités, règles, dépendances et données inventoriées et vérifiées.
PHASE 02
Planifier
Structure cible, tranches, chemins de rollback et critères de validation.
PHASE 03
Migrer
Tranches livrées derrière du routage ou des feature flags, ancien système toujours en ligne.
PHASE 04
Décommissionner
Ancien code, données et infrastructure supprimés une fois le trafic parti.
Chaque tranche tourne à côté de l’ancien code avant de recevoir du trafic réel. Une couche de routage ou des feature flags envoient une petite part des utilisateurs vers le nouveau chemin, les résultats sont comparés, et le trafic n’augmente que si les contrôles sont concluants. La validation préalable dans un environnement parallèle est détaillée dans notre guide sur la parallélisation production-staging avant la bascule.
Strangler, extraction ou réécriture : quelle approche ?
L’approche de migration se choisit pour chaque partie de l’application, et non une fois pour tout le système. Le tableau compare les options que nous évaluons pendant l’audit, avec les conditions dans lesquelles chacune a du sens.
| Approche | Fonctionnement | Adaptée lorsque | Rollback |
|---|---|---|---|
| Strangler fig | Le nouveau code reprend les routes une par une | Grande application qui doit rester en ligne | Renvoyer le trafic vers l’ancien chemin |
| Extraction de modules | Des domaines sortis du monolithe derrière des interfaces | Monolithe avec des domaines métier identifiables | Rebrancher l’interface sur l’ancien module |
| Mise à niveau sur place | Framework ou runtime monté version par version | La structure est saine, seule la plateforme est dépassée | Redéployer la version précédente |
| Réécriture complète | Nouvelle application construite, puis basculée en une seule fois | Petit système ou aucune structure récupérable | Le plus difficile : exige un fonctionnement en parallèle et une synchronisation des données |
Nous privilégions par défaut les options incrémentales, car chaque étape est assez petite pour être annulée. Une réécriture complète n’est recommandée que lorsque l’ancienne structure n’a rien qui mérite d’être conservé, et même dans ce cas nous cherchons à la livrer par parties. Si la conception du backend elle-même doit être repensée, notre travail en développement backend définit la cible avant tout déplacement de code.
Risques et rollback dans une migration web
Les migrations web échouent pour une liste courte de raisons, et toutes peuvent être anticipées. Chaque risque ci-dessous a un responsable, un contrôle et un déclencheur de rollback.
Des règles métier perdues
Les comportements que personne n’a documentés disparaissent dans le nouveau code. Nous les identifions à partir des logs et des chemins de code, et comparons les résultats de l’ancien et du nouveau système sur des requêtes réelles.
Une dérive des données entre ancien et nouveau système
Deux systèmes qui écrivent les mêmes enregistrements divergent vite. Un seul système est propriétaire de chaque enregistrement à tout moment, et des contrôles de réconciliation tournent jusqu’au décommissionnement de l’ancien.
Liens cassés et visibilité perdue dans les moteurs de recherche
Des URL modifiées cassent les favoris, les liens partenaires et le positionnement. Chaque ancienne URL est associée à sa nouvelle adresse par une redirection permanente testée avant la release.
Une migration qui ne se termine jamais
Des systèmes à moitié migrés doublent la charge de maintenance. Chaque phase comporte une étape de décommissionnement, et l’ancien code est supprimé dès que le trafic l’a quitté.
La bascule de chaque tranche suit un runbook écrit avec des points de contrôle go et no-go. Nos guides sur la synchronisation des données et de l’état applicatif au cutover et sur la préparation d’une bascule sans interruption de service détaillent le contenu de ces runbooks.
Tarifs de la migration web legacy
Chaque mission commence par un diagnostic et se conclut par un devis forfaitaire. Les durées sont indicatives, pas contractuelles, et dépendent fortement de la taille de l’ancien système.
| Format | Durée | Prix |
|---|---|---|
| Audit de migration | 2 à 4 semaines | Devis forfaitaire après diagnostic |
| Migration par phases | 3 à 12 mois | Devis forfaitaire après l’audit |
| Accompagnement après migration | Mensuel | Forfait mensuel chiffré à la passation |
Ce qui fait varier le prix : la taille du code legacy, le volume et la qualité des données à migrer, le nombre d’intégrations et la part du travail que votre équipe prend en charge.
Le devis couvre uniquement des consultants seniors, un périmètre défini et les livrables de chaque phase, de l’inventaire au décommissionnement de l’ancien code. L’hébergement nécessaire pour faire tourner les deux systèmes en parallèle, ainsi que les éventuelles nouvelles licences, sont réglés séparément à leurs fournisseurs.
FAQ sur la migration web legacy
Faut-il geler les fonctionnalités pendant la migration ?
Non. Les phases sont petites et livrées en parallèle du travail produit habituel. Les nouvelles fonctionnalités sont construites sur la nouvelle structure là où elle existe, et sur l’ancienne uniquement lorsque la zone concernée n’a pas encore migré.
Une réécriture complète est-elle parfois le bon choix ?
Parfois, pour de petits systèmes ou du code sans structure réutilisable. Pour la plupart des applications métier, une migration incrémentale apporte de la valeur plus tôt et garde chaque étape réversible, ce qu’une bascule unique ne permet pas.
Comment évitez-vous de perdre des règles métier ?
En considérant l’ancien système comme la spécification. Nous inventorions les règles à partir du code et des logs, puis comparons les résultats de l’ancien et du nouveau système sur des requêtes réelles avant que chaque tranche ne reçoive la totalité du trafic.
Notre référencement va-t-il en souffrir ?
Pas si les URL sont correctement gérées. Chaque URL existante est associée à sa nouvelle adresse par une redirection permanente, les métadonnées sont reprises, et les redirections sont testées avant chaque release.
Nos développeurs peuvent-ils continuer à travailler sur l’ancien code ?
Oui. Votre équipe continue de maintenir les parties qui n’ont pas encore migré. Nous convenons des zones gelées pour chaque tranche, généralement pendant quelques jours autour de sa bascule, afin que les travaux n’entrent pas en conflit.
Que devient l’ancien système à la fin ?
Il est décommissionné par étapes : trafic retiré, données archivées selon vos règles de conservation, code supprimé et infrastructure arrêtée. Le décommissionnement est planifié dès le départ, et non laissé comme un nettoyage facultatif.