Application métierMéthodeSur-mesurePMEMaintenance
Refonte d'une application métier : tout réécrire ou moderniser par étapes
10 min de lecture
Pour refondre une application métier sans mettre l'entreprise en danger, la méthode la plus sûre consiste rarement à tout réécrire d'un bloc. On place plutôt le nouveau logiciel à côté de l'ancien, on lui confie les fonctions une par une, dans un ordre choisi selon leur valeur et leur risque, et on éteint l'ancien quand il ne sert plus à rien. La réécriture complète reste le bon choix pour une petite application aux règles bien connues.
Notre article sur la refonte d'un logiciel métier obsolète ou plus maintenu traite du « quand » : les signaux qui doivent alerter et les grandes étapes. Celui-ci traite du « comment » : choisir la stratégie, découper, ordonner les modules, faire cohabiter deux logiciels et continuer à facturer pendant toute la durée du chantier.
Cinq façons de traiter une application vieillissante
Avant de parler de réécriture, posez la question à l'envers : faut-il vraiment reconstruire ? Le guide de migration d'AWS, qui fait référence sur le sujet, classe les options en sept stratégies (relevé du 06/11/2026). Ramenées à la situation d'une PME, elles se résument à cinq.
| Option | Ce qu'on fait | Quand c'est pertinent |
|---|---|---|
| Conserver | On sécurise et on documente, sans reconstruire | L'outil marche, évolue peu, et un développeur le maintient |
| Retirer | On arrête la fonction ou l'outil | Plus personne ne s'en sert, ou un autre outil le fait déjà |
| Déplacer | On change le serveur ou la version, pas le logiciel | Le problème est l'hébergement, pas le code |
| Remplacer par un produit | On achète un progiciel ou un SaaS | Le besoin est standard et vos règles tiennent dans l'outil |
| Reconstruire | On réécrit, d'un bloc ou par étapes | Le logiciel porte un savoir-faire propre et bloque l'activité |
Une même application peut combiner plusieurs options : on retire les écrans morts, on remplace la comptabilité par un logiciel du marché, et on ne reconstruit que ce qui fait votre différence. Ce tri peut réduire nettement le périmètre de la refonte avant même d'avoir écrit une ligne. Le raisonnement « acheter ou faire » est détaillé dans logiciel sur mesure ou progiciel.
Réécriture d'un bloc ou modernisation par étapes
Si la reconstruction est retenue, reste à choisir comment la mener.
| Critère | Réécriture complète | Modernisation par étapes |
|---|---|---|
| Première mise en production | À la fin du projet | Dès le premier module |
| Risque de la bascule | Concentré sur un jour | Réparti sur plusieurs petites bascules |
| Découverte des oublis | Tardive, souvent en recette | Au fil de l'eau, module par module |
| Travail de raccordement | Faible | Réel : deux logiciels partagent la donnée |
| Possibilité d'arrêter en route | Faible : rien d'utilisable avant la fin | Forte : chaque étape livrée reste acquise |
| Adapté à | Petit outil, règles connues, données sûres | Logiciel central, ancien, peu documenté |
La réécriture complète séduit parce qu'elle paraît plus simple à piloter : un cahier des charges, un projet, une date. Son défaut est structurel : pendant des mois, l'entreprise paie un logiciel qu'elle n'utilise pas, pendant que l'ancien continue d'évoluer et que l'écart se creuse.
La modernisation par étapes demande plus de rigueur technique, mais elle transforme un grand pari en une suite de petits paris, chacun vérifiable.
La méthode de l'étrangleur, expliquée simplement
Le nom vient d'une image proposée par Martin Fowler dans son article Strangler Fig Application (version du 22 août 2024) : le figuier étrangleur pousse autour d'un arbre hôte jusqu'à pouvoir tenir seul. Microsoft en a fait un patron d'architecture documenté, le modèle Strangler Fig (page mise à jour le 29 mai 2026).
Concrètement, la méthode repose sur trois pièces.
Une façade qui aiguille
Les utilisateurs passent par un point d'entrée unique : un menu, un portail, une adresse web. Derrière, chaque fonction est servie soit par l'ancien logiciel, soit par le nouveau. Pour un utilisateur, le changement se résume à un écran qui change d'apparence. Pour une application de bureau ancienne, la façade peut être plus simple : le nouveau logiciel remplace un menu à la fois, et l'ancien reste installé pour le reste.
Une donnée qui ne se contredit pas
C'est le cœur technique de la méthode. Pendant la cohabitation, une donnée ne doit avoir qu'un seul maître. Trois montages sont possibles :
- le nouveau logiciel lit et écrit dans l'ancienne base, le temps de la transition : simple, mais il hérite de ses défauts ;
- chaque module migré devient maître de ses données, et les renvoie à l'ancien logiciel qui en a encore besoin ;
- une synchronisation dans les deux sens : à éviter autant que possible, c'est la source de la plupart des incohérences.
Le guide de Microsoft le dit clairement : la méthode suppose de pouvoir intercepter les échanges avec l'ancien système, ou au moins d'accéder à sa base de données. Sans aucun point d'accès, elle ne s'applique pas.
Un retrait réel des fonctions migrées
Une fonction reconstruite doit être retirée de l'ancien logiciel, ou au moins rendue inaccessible. Sinon, une partie de l'équipe continue d'utiliser l'ancienne version, les données divergent, et la refonte ne finit jamais. L'objectif final est explicite : éteindre l'ancien logiciel, à une date qu'on rapproche à chaque étape.
Découper et ordonner les modules
Le découpage se fait par usage métier, pas par couche technique. « Prise de commande », « planning des interventions », « facturation » sont de bons modules. « La base de données » ou « l'interface » n'en sont pas : on ne livre rien d'utile en refaisant l'une sans l'autre.
Pour ordonner les modules, notez chacun selon deux axes :
- la valeur : temps gagné, erreurs évitées, irritant supprimé, obligation à tenir (la facturation électronique, par exemple) ;
- le risque : nombre de règles métier, de liens avec les autres modules, volume et qualité des données concernées.
| Valeur / risque | Risque faible | Risque élevé |
|---|---|---|
| Valeur forte | À faire en premier | À préparer tôt, à basculer une fois rodé |
| Valeur faible | À regrouper avec un module voisin | À retirer ou à remplacer par un produit |
Le premier module idéal est utile, bien délimité et peu couplé : un portail de consultation pour les clients, un écran de saisie pour le terrain, un tableau de bord qui remplace un export manuel. Il prouve la méthode, rode les raccordements de données et donne confiance à l'équipe. Le cœur du logiciel vient ensuite, quand on sait que la cohabitation tient.
Maintenir l'activité pendant la refonte
Une refonte réussie ne se voit presque pas au quotidien. Cinq règles y contribuent.
- Basculer par périmètre, pas par date. Un module, puis un service, puis une agence. Un premier groupe d'utilisateurs volontaires essuie les plâtres avant tout le monde.
- Prévoir le retour arrière. Avant chaque bascule, on sait comment revenir à l'ancien fonctionnement en quelques minutes, et quelles données réconcilier si cela arrive.
- Contrôler en double, brièvement. Pendant quelques jours, on compare les résultats des deux logiciels sur les opérations sensibles : totaux de factures, stocks, plannings. Au-delà, la double saisie épuise l'équipe et doit s'arrêter.
- Limiter les évolutions de l'ancien logiciel. Corrections et obligations légales seulement. Toute nouvelle demande est notée pour le nouveau logiciel.
- Former juste avant, pas trois mois avant. Une démonstration courte, la veille de la bascule, vaut mieux qu'une formation générale oubliée au moment de s'en servir.
La reprise des données suit la même logique : elle se fait module par module, sur des copies d'abord, avec une personne du métier qui valide les résultats. Le sujet est détaillé dans notre article sur la reprise de données lors d'une migration de logiciel.
Reconstituer les règles métier avant de coder
Le code d'une application de dix ans contient des règles que plus personne ne connaît, et des fonctions que plus personne n'utilise. Les deux pièges sont symétriques : oublier une règle utile, ou reconstruire fidèlement une fonction morte.
Trois sources se complètent pour les retrouver :
- les utilisateurs, observés en situation réelle, pas seulement interrogés en réunion ;
- les données : un champ jamais rempli depuis cinq ans signale une fonction morte, un champ libre détourné signale un besoin mal servi ;
- le code, quand il est accessible, pour les calculs : tarifs, remises, arrondis, échéances. Un audit de l'application existante en fait l'inventaire.
Ensuite, validez la cible sur un prototype visuel : les écrans du futur module, cliquables, montrés aux utilisateurs avant le développement. Un oubli coûte quelques minutes à corriger sur un prototype, et plusieurs jours une fois le module développé.
Les erreurs qui font échouer une refonte
- Reproduire l'ancien à l'identique. On recopie les détours que l'outil imposait, au lieu de repartir du travail réel.
- Tout améliorer en même temps. Dix ans de souhaits ajoutés au périmètre transforment une refonte en projet sans fin. Les améliorations attendent que la base soit saine.
- Commencer par le module le plus complexe pour « régler le plus dur d'abord ». Sans raccordements rodés, c'est là que le projet s'enlise.
- Négliger l'ancien logiciel pendant la transition. Il tourne encore des mois : sauvegardes, mises à jour de sécurité et surveillance restent dues.
- Ne jamais fixer de date d'extinction. Deux logiciels maintenus en parallèle coûtent plus cher qu'un seul, indéfiniment.
- Confier la refonte sans référent métier. Une personne de l'équipe, disponible quelques heures par semaine, tranche les questions de règles. Sans elle, le prestataire devine.
Qui fait quoi, et comment le contractualiser
Une refonte par étapes se découpe naturellement en lots, chacun avec son périmètre, son prix et sa date de mise en production. C'est ce qui la rend compatible avec un forfait : on engage un module à la fois, sur un périmètre validé, plutôt qu'un budget global sur un projet de plusieurs mois. Les différences entre forfait et régie prennent ici tout leur sens : en régie, la durée de cohabitation se paie au temps passé.
Le budget lui-même, poste par poste, est traité dans notre article sur le prix de la refonte d'un logiciel métier. Avant de signer, vérifiez aussi ce que vous récupérez en fin de contrat : code, données, documentation, avec des droits définis au cas par cas dans le contrat.
Le cas particulier des logiciels de bureau
Beaucoup d'applications métier de PME sont des logiciels Windows installés poste par poste : WinDev, Access, Delphi, Visual Basic. Leur refonte ressemble aux autres, avec deux particularités. La façade est souvent un simple menu, puisqu'il n'y a pas d'adresse web à aiguiller. Et la base de données est la meilleure porte d'entrée : le nouveau logiciel web peut la lire pendant la transition. Nous détaillons ces deux cas dans migrer de WinDev vers le web et migrer une base Access vers une application web.
La check-list avant de lancer la refonte
- La liste des fonctions de l'ancien logiciel, avec qui s'en sert et à quelle fréquence.
- Le tri : conserver, retirer, remplacer par un produit, reconstruire.
- Les modules, notés en valeur et en risque, et le premier choisi.
- Le maître de chaque donnée pendant la cohabitation.
- Le prototype du premier module, validé par ses utilisateurs.
- Un référent métier nommé, avec du temps réservé.
- Une date cible d'extinction de l'ancien logiciel, même provisoire.
- Le plan de maintenance du nouveau logiciel, pour ne pas recréer la même situation dans dix ans (voir la maintenance d'une application métier).
Par où commencer
Rassemblez trois choses : la liste des écrans ou menus que votre équipe utilise vraiment, un export de la base de données, et le module qui fait le plus souffrir aujourd'hui. Cela suffit pour un premier échange, et pour découper la refonte module par module.