Pour moderniser une application historique sans arrêter l’activité, on évite la réécriture complète et la bascule unique. On remplace l’application module par module, pendant que l’ancienne continue de fonctionner : une façade oriente chaque usage vers l’ancien ou le nouveau système, et la part du nouveau grandit à chaque livraison jusqu’à ce que l’ancien puisse être éteint. Cette méthode, dite du figuier étrangleur, réduit le risque, livre de la valeur dès les premiers mois et laisse le temps aux équipes de s’adapter.
Beaucoup de PME et d’ETI tournent sur un outil métier développé il y a quinze ou vingt ans : un client lourd, une base Access devenue critique, une application web d’une autre génération. Il fonctionne, mais chaque évolution coûte cher, plus personne ne le maîtrise vraiment, et il bloque des projets (portail client, mobilité, intégration avec le CRM). Voici comment en sortir sans mettre l’entreprise en danger.
Pourquoi la refonte « big bang » échoue si souvent ?
L’idée paraît rationnelle : figer l’ancien outil, reconstruire un équivalent moderne, basculer un week-end. En pratique, elle accumule les risques.
L’existant est mal connu. Des années de corrections, d’exceptions et de règles implicites sont enfouies dans le code. Joel Spolsky l’a résumé dans un texte devenu classique, Things You Should Never Do : un vieux code paraît désordonné, mais il contient des années de corrections éprouvées en conditions réelles. Il prenait l’exemple de Netscape, dont la décision de tout réécrire avait laissé près de trois ans sans nouvelle version majeure.
Les métiers ne peuvent pas attendre. Pendant la reconstruction, les besoins continuent d’évoluer. Soit on gèle l’ancien outil et l’entreprise prend du retard, soit on le fait évoluer en parallèle et la cible bouge sans cesse.
La parité fonctionnelle est un piège. Ian Cartwright, Rob Horn et James Lewis, directeurs techniques chez Thoughtworks, dans leur série sur le remplacement des systèmes historiques, décrivent la reconstruction à l’identique comme un facteur récurrent d’échec : spécifier l’existant est un chantier énorme, le résultat n’apporte aucune valeur nouvelle et il mène le plus souvent à une bascule unique.
La bascule concentre tout le risque. Données mal reprises, utilisateurs non formés, intégration oubliée : tout se révèle le même jour.
Qu’est-ce que le modèle du figuier étrangleur ?
Le figuier étrangleur est une liane tropicale qui pousse autour d’un arbre hôte, s’en nourrit et finit par le remplacer. Martin Fowler a vu ces arbres dans les forêts du Queensland en 2001 et en a tiré une métaphore pour la modernisation : construire le nouveau système autour de l’ancien, et lui transférer progressivement ses fonctions.
La documentation d’architecture de Microsoft décrit le modèle en quatre temps :
- Introduire une façade entre les utilisateurs (ou les autres applications) et l’ancien système. Au départ, elle transmet presque tout à l’ancien.
- Déplacer les fonctions une à une vers le nouveau système, la façade redirigeant progressivement les demandes.
- Désactiver l’ancien système quand plus rien n’en dépend.
- Retirer la façade, devenue inutile.
La façade peut être technique (un routage des requêtes, une API qui centralise les appels) ou fonctionnelle (un nouveau portail qui ouvre, selon les écrans, l’ancien ou le nouvel outil). L’important est que l’utilisateur ait un point d’entrée stable pendant que l’arrière-plan change.
La couche anti-corruption
Pendant la transition, les deux systèmes doivent dialoguer. Le nouveau a besoin de données que l’ancien gère encore, et inversement. Une couche anti-corruption est un adaptateur qui traduit les échanges entre les deux, pour que le nouveau système n’hérite pas des conventions de l’ancien (codes obscurs, formats dépassés, champs détournés). Microsoft la présente comme le complément naturel du figuier étrangleur dans sa documentation dédiée. C’est typiquement le travail d’une équipe d’intégrations et d’API.
Refondre, remplacer ou moderniser : comment choisir ?
La modernisation progressive n’est pas toujours la bonne réponse. Microsoft note elle-même que le modèle convient mal à un petit système, qu’on peut remplacer simplement, ou à un ancien outil dont on ne peut ni intercepter les échanges ni modifier le code.
| Situation | Approche adaptée | Pourquoi |
|---|---|---|
| Petite application, peu d’utilisateurs, peu d’intégrations | Refonte complète avec bascule unique | La transition coûterait plus cher que le risque qu’elle évite |
| Besoin standard, désormais couvert par une solution du marché | Remplacement par un outil du marché et reprise des données | Pas de raison de maintenir du sur mesure sur un processus commun |
| Application critique, nombreux modules, forte activité | Modernisation progressive (figuier étrangleur) | Le risque d’une bascule unique est trop élevé |
| Code ancien mais sain, technologie encore maintenue | Remise à niveau et remboursement de la dette | Moderniser l’existant suffit, inutile de reconstruire |
| Code source indisponible, éditeur disparu | Modernisation par les données et les échanges, puis remplacement | On contourne l’ancien système faute de pouvoir le modifier |
Le quatrième cas est souvent négligé. Une application ancienne n’est pas forcément obsolète ; elle peut simplement être endettée. Notre article sur la dette technique aide à faire la différence.
Par quel module commencer ?
Le premier module modernisé fixe le ton du programme. Il doit prouver que l’approche fonctionne, rassurer la direction et les utilisateurs, et rester maîtrisable. Les critères qui comptent :
- Une valeur métier visible : un irritant connu de tous, un processus qui fait perdre du temps chaque jour.
- Peu de dépendances : un périmètre qu’on peut isoler sans toucher au cœur des données.
- Un nombre d’utilisateurs limité au départ, pour une montée en charge contrôlée.
- Un usage fréquent, pour obtenir rapidement des retours.
Un bon candidat est souvent une nouvelle surface plutôt qu’un remplacement : un portail client, une application mobile pour les techniciens, un tableau de bord. Elle se branche sur les données de l’ancien système, apporte une valeur immédiate et installe les fondations (authentification, API, hébergement) dont les modules suivants auront besoin. Cartwright, Horn et Lewis parlent de « détourner le flux » : commencer par sortir de l’ancien système les activités qui n’y ont plus leur place.
À l’inverse, évitez de commencer par le module le plus complexe, comme la facturation ou le calcul des tarifs, ou par celui que tout le monde redoute. Il viendra quand l’équipe connaîtra le domaine et que l’architecture de transition aura fait ses preuves.
La donnée, cœur de la modernisation
Pendant des mois, voire plus, deux systèmes vont coexister. Ils doivent partager une vérité commune sur les clients, les commandes, les stocks ou les interventions. Trois options principales existent :
- Base partagée : le nouveau module lit et écrit dans la base de l’ancien. Simple au départ, mais il hérite de ses contraintes.
- Synchronisation : chaque système a sa base, et les changements sont propagés de l’une à l’autre, par exemple par capture des modifications de données. Plus propre, plus exigeant.
- Bascule par domaine : on migre les données d’un domaine (par exemple les fiches clients) vers la nouvelle base, qui devient la référence, et l’ancien système la consulte.
L’exemple de Microsoft illustre la troisième voie : extraire un domaine de la base monolithique, synchroniser pendant une période de validation, puis faire de la nouvelle base le système de référence. Point important, le retour arrière reste possible tant que les anciennes tables existent ; leur suppression doit être une étape délibérée, une fois le nouveau système validé.
Chaque transfert de domaine est une petite migration à part entière, avec ses contrôles et ses rapprochements. Notre checklist de migration de données s’applique à chacune.
Le plan de modernisation en sept étapes
- Inventorier l’existant : modules, utilisateurs, volumes, intégrations, règles critiques, personnes qui le maîtrisent.
- Définir les objectifs : réduire le coût des évolutions, ouvrir un portail, sécuriser une technologie obsolète. Ils guideront les arbitrages.
- Découper l’application en domaines métier qui peuvent être remplacés séparément.
- Prioriser les domaines selon la valeur, les dépendances et le risque.
- Mettre en place la façade et l’architecture de transition : point d’entrée unique, API, synchronisation des données.
- Livrer domaine par domaine, avec des utilisateurs pilotes, puis une généralisation.
- Éteindre chaque partie de l’ancien système dès qu’elle n’est plus utilisée, sans attendre la fin du programme.
Les deux premières étapes relèvent d’une phase de cadrage : quelques semaines pour cartographier l’existant, fixer les objectifs et dessiner la trajectoire, avant tout engagement sur la totalité.
Ce qui fait réussir une modernisation
Au-delà de la technique, trois conditions reviennent dans tous les programmes réussis. Un sponsor métier qui arbitre les priorités et accepte que certaines fonctions historiques ne soient pas reconduites. Une équipe stable qui accumule la connaissance du domaine au fil des modules. Un accompagnement des utilisateurs à chaque étape, car changer d’outil change des habitudes de travail ; c’est le sujet de notre article sur la conduite du changement.
Cartwright, Horn et Lewis le rappellent : si l’organisation ne change pas sa façon de travailler, elle aura probablement besoin d’un nouveau remplacement quelques années plus tard. La modernisation est l’occasion de mettre en place des livraisons régulières, des tests automatisés et une documentation tenue à jour, pour que la nouvelle application web ne devienne pas l’application historique de demain.
Vous avez un outil historique critique et vous vous demandez par où commencer ? Décrivez-le dans notre diagnostic de projet : nous vous aiderons à identifier le premier module à moderniser.
