Le legacy n'est pas votre problème, le big bang l'est
En 2026, la plupart des entreprises européennes ne sont pas freinées par un manque d'idées, mais par des systèmes qu'elles n'osent plus toucher. Un ERP de 2011, un back-office en PHP 5, une base de données dont plus personne ne connaît toutes les tables, un cœur métier écrit par des gens partis depuis longtemps. Ces systèmes marchent, encaissent le chiffre d'affaires, et bloquent en même temps chaque nouveau projet.
La tentation classique est la réécriture complète, le fameux big bang. On gèle les évolutions pendant dix-huit mois, on reconstruit tout en neuf, on bascule un week-end. C'est aussi le scénario qui échoue le plus souvent : dérive budgétaire, périmètre qui gonfle, et le jour de la bascule, mille détails métier oubliés qui n'existaient que dans l'ancien code.
La bonne nouvelle, c'est qu'il existe une alternative éprouvée et beaucoup moins risquée : la migration progressive par étranglement, ou strangler-fig. En 2026, avec des exigences réglementaires qui se durcissent, c'est devenu la stratégie de modernisation par défaut pour tout système que l'on ne peut pas se permettre d'arrêter.
Le pattern strangler-fig, concrètement
L'image vient du figuier étrangleur, cette plante qui pousse autour d'un arbre hôte, l'enveloppe peu à peu, puis finit par le remplacer entièrement une fois qu'elle tient debout seule. Appliqué au logiciel, le principe est le même : on construit le nouveau système autour de l'ancien, fonctionnalité par fonctionnalité, jusqu'à ce que l'ancien puisse disparaître sans que personne ne s'en aperçoive.
En pratique, cela repose sur quelques mécanismes simples :
- ▸Une façade de routage placée devant le système existant, qui décide pour chaque requête si elle part vers l'ancien code ou vers le nouveau. Le client final ne voit rien changer.
- ▸Un découpage par capacité métier, pas par couche technique. On sort d'abord un domaine bien délimité (la facturation, l'authentification, le catalogue), on le réécrit proprement, puis on redirige le trafic vers lui.
- ▸Une synchronisation des données pendant la période de cohabitation, pour que l'ancien et le nouveau restent cohérents tant que les deux tournent.
- ▸Une bascule réversible : chaque morceau migré peut être remis en arrière en modifiant une règle de routage, sans redéploiement d'urgence à 3 heures du matin.
L'intérêt est double. On livre de la valeur toutes les quelques semaines au lieu d'attendre la fin d'un tunnel de deux ans. Et on apprend le comportement réel de l'ancien système morceau par morceau, au lieu de le découvrir brutalement le jour de la mise en production.
Réduire le risque : la checklist de migration
Une migration strangler-fig réussie tient moins à l'élégance du code neuf qu'à la discipline du processus. Voici les étapes que nous suivons, dans l'ordre.
- ▸Cartographier avant de coder. Inventoriez les flux, les intégrations, les tâches planifiées et les zones de code que personne ne comprend. Ce que vous ne cartographiez pas cassera pendant la bascule.
- ▸Choisir un premier domaine à faible risque et forte visibilité. Assez isolé pour être migré sans tout entraîner, assez utile pour prouver la valeur de la démarche au métier et à la direction.
- ▸Poser des tests de caractérisation. Avant de réécrire, capturez le comportement actuel du système, y compris ses bizarreries, sous forme de tests. Ils deviennent votre filet de sécurité.
- ▸Installer la façade et mesurer. Mettez en place le routage et l'observabilité (logs, traces, métriques) dès le premier jour, pour comparer ancien et nouveau sur des données réelles.
- ▸Migrer par tranches fines, en shadow puis en canary. Faites tourner le nouveau code en parallèle sans impact, comparez les résultats, puis basculez un petit pourcentage du trafic avant de généraliser.
- ▸Garder le retour arrière permanent. Tant que l'ancien module existe, une seule règle doit suffire à revenir en arrière.
- ▸Nettoyer sans attendre. Dès qu'une tranche est stabilisée, supprimez le code mort de l'ancien système. Sinon vous maintenez deux systèmes au lieu d'un.
Cette approche transforme un projet à haut risque en une série de petites décisions réversibles. C'est précisément ce qui rassure un comité de direction : à chaque étape, on peut mesurer, arrêter ou continuer.
Pourquoi 2026 rend la modernisation urgente
Le calendrier réglementaire européen fait de la dette technique un risque de conformité, plus seulement un inconfort d'ingénierie.
- ▸NIS2 élargit le nombre d'entités soumises à des obligations de cybersécurité et engage la responsabilité des dirigeants. Un système legacy non patché, sans authentification moderne ni journalisation exploitable, devient un problème juridique autant que technique.
- ▸DORA, applicable au secteur financier, impose une résilience opérationnelle démontrable, la gestion du risque lié aux prestataires et des tests réguliers. Un cœur bancaire monolithique et opaque est très difficile à mettre en conformité tel quel.
- ▸Le RGPD continue de sanctionner l'incapacité à honorer les droits des personnes. Beaucoup de vieux systèmes ne savent tout simplement pas retrouver ni effacer proprement une donnée.
- ▸L'EU AI Act monte en puissance en 2026 avec ses obligations pour les systèmes à haut risque : traçabilité, documentation, supervision humaine. Vouloir greffer de l'IA sur une base ingérable rend ces exigences quasi impossibles à tenir.
Moderniser progressivement permet d'introduire au fil de l'eau le chiffrement, la journalisation, la gestion fine des consentements et la traçabilité que ces textes réclament, sans attendre une hypothétique refonte totale.
Comment nous construisons chez TuniCyberLabs
Nous sommes une société d'ingénierie logicielle ancrée dans l'Union européenne, avec une maison mère estonienne à Tallinn, un bureau à Chypre et notre équipe d'ingénierie en Tunisie, à Sousse. Concrètement, pour un client français, cela veut dire un partenariat nearshore : même fuseau horaire que vous, contrats et cadre GDPR via l'entité estonienne, et des équipes qui travaillent en français, en anglais et en arabe, à un coût nettement inférieur à celui d'un prestataire parisien à qualité équivalente.
Notre façon de mener une modernisation suit quatre temps :
- ▸Comprendre. Nous auditons l'existant, cartographions les flux et identifions le domaine par lequel commencer, avec le métier dans la boucle.
- ▸Concevoir. Nous définissons l'architecture cible, la stratégie de routage et de synchronisation, et un plan de découpage réversible.
- ▸Construire et déployer. Nous livrons des systèmes de production sécurisés, testés, observables, avec intégration continue et bascules canari maîtrisées.
- ▸Supporter et faire évoluer. Une fois l'ancien étranglé, nous restons pour opérer, durcir la conformité et accompagner les évolutions suivantes.
Un système legacy n'est pas une punition. C'est un condensé de règles métier qui ont fait la preuve de leur valeur pendant des années. Bien migré, il ne disparaît pas : il redevient une base sur laquelle vous pouvez à nouveau construire vite, en confiance, et en conformité avec les règles de 2026. C'est exactement le travail que nous aimons faire.