Pour refondre un logiciel existant, ne choisissez pas d’abord entre réparer et tout refaire. Décidez capacité par capacité. Au 8 septembre 2026, notre recommandation est de privilégier une modernisation progressive lorsque le logiciel contient encore des règles, des données et des parcours utiles. Une reconstruction devient cohérente si le produit cible a profondément changé, si le système est petit et isolable, ou si aucune évolution sûre n’est possible.
Pourquoi le choix entre améliorer et reconstruire est-il trompeur ?
Un logiciel métier n’est pas seulement du code ancien. Il contient des règles, des droits, des historiques et des habitudes de travail. La bonne question n’est donc pas « faut-il jeter le logiciel ? », mais « quelles capacités faut-il conserver, corriger, remplacer ou arrêter ? ». La saisie d’une commande, la facturation et le reporting peuvent suivre trois trajectoires différentes.
Cette décomposition évite deux erreurs. La première consiste à réparer indéfiniment une base qui empêche toute évolution. La seconde consiste à reconstruire à l’identique, y compris des comportements dont personne n’a plus besoin. Martin Fowler rappelle qu’un remplacement apparemment simple se heurte souvent à des détails de fonctionnement mal connus et au risque de reproduire des fonctions inutiles (Martin Fowler).
Quelles sont les trois trajectoires possibles ?
Une refonte logicielle peut combiner amélioration ciblée, modernisation progressive et reconstruction. Le choix dépend de la valeur encore présente dans l’existant et du risque de transition.
| Trajectoire | À choisir si | Ce qu’elle implique | Limite à accepter |
|---|---|---|---|
| Amélioration ciblée | Le parcours reste pertinent et le code peut être modifié puis testé | Corriger un point précis, ajouter des tests et mesurer l’effet | Les contraintes du socle restent présentes |
| Modernisation progressive | Le service doit continuer et des modules peuvent être isolés | Faire coexister ancien et nouveau, migrer par lots et préparer le retour arrière | L’architecture transitoire coûte du temps et doit avoir une fin |
| Reconstruction | Le produit cible diffère fortement, le petit système est isolable ou le socle ne permet plus d’évolution sûre | Redéfinir les règles utiles, reprendre les données, tester et organiser la bascule | Le nouveau logiciel ne bénéficie pas automatiquement des années d’exceptions accumulées |
Une quatrième option mérite d’être examinée : remplacer le logiciel par un outil existant. Si votre besoin correspond à un produit du marché et que les adaptations restent limitées, un SaaS peut éviter de reconstruire une fonction devenue standard. La décision doit inclure les intégrations, l’export des données, les droits et le coût dans la durée.
Comment évaluer l’existant avant de décider ?
Évaluez chaque capacité métier selon quatre axes. Cette grille ne produit pas un score automatique ; elle fait apparaître le problème qui doit guider la trajectoire.
| Axe | Questions à documenter | Ce que la réponse change |
|---|---|---|
| Usage et valeur | Qui utilise cette capacité ? Quelle tâche échoue, ralentit ou oblige à contourner le logiciel ? | Un problème d’interface appelle rarement, à lui seul, une reconstruction du moteur métier |
| Fragilité technique | Le code est-il accessible, testable et déployable ? Les incidents sont-ils compris ? Une évolution touche-t-elle plusieurs modules sans rapport ? | Une zone isolable favorise un lot ciblé ; une dépendance généralisée augmente le coût de toute option |
| Continuité de service | Combien de temps le service peut-il être indisponible ? Peut-on faire travailler un groupe pilote ? Quel retour arrière est possible ? | Une activité continue favorise une bascule progressive et réversible |
| Données et migration | Quelles données font foi ? Qui les modifie ? Quels outils lisent la même base ? Comment vérifier la reprise ? | Une migration inconnue interdit de considérer la reconstruction comme un simple nouveau développement |
AWS recommande d’examiner la portée métier, fonctionnelle, technique et financière d’une modernisation, puis de documenter bénéfices, risques et dépendances (AWS Prescriptive Guidance). Son questionnaire rend visibles interfaces, services partagés, dépendances de base de données, tests, sécurité et besoins de reprise (questionnaire AWS).
Exemple rempli : un logiciel de gestion de commandes
Prenons une PME fictive de distribution. Son logiciel gère clients, commandes, stock, facturation et export comptable. La saisie est lente, l’export échoue parfois et le framework de l’interface n’est plus maintenu. Huit années d’historique et plusieurs règles de remise restent utiles. L’activité ne peut pas s’arrêter une journée entière.
Trois propositions émergent : refaire seulement l’interface, reconstruire tout le logiciel sur le web, ou remplacer progressivement les modules. La grille est remplie par capacité plutôt que pour le produit entier.
| Capacité | Constat | Décision proposée | Conséquence attendue |
|---|---|---|---|
| Saisie de commande | Parcours pénible, règles de prix encore valides, module isolable | Nouveau module web connecté d’abord aux règles existantes | Une équipe pilote teste le nouveau parcours sans imposer une bascule générale |
| Export comptable | Échecs intermittents, cause non mesurée, opération critique | Instrumenter, corriger et ajouter un contrôle de rapprochement | Le risque immédiat baisse et la reprise future dispose d’une règle de vérification |
| Facturation | Stable, liée à plusieurs exceptions et à l’historique | Conserver pendant le premier lot | Le projet ne recode pas une fonction stable avant d’avoir compris ses dépendances |
| Base clients | Données partagées par les commandes et la facturation | Préparer une interface d’accès, puis migrer après validation | Ancien et nouveau utilisent une source contrôlée pendant la transition |
| Reporting | Plusieurs exports peu utilisés | Mesurer les rapports réellement ouverts, arrêter les autres | La reconstruction ne reproduit pas automatiquement chaque écran historique |
La décision n’est ni « réparer » ni « tout refaire ». Le premier lot stabilise l’export comptable et livre une nouvelle saisie de commande à un groupe pilote. La facturation reste dans l’ancien logiciel. La migration des clients vient après la vérification des doublons, des droits et des dépendances.
Cette trajectoire a un coût : un adaptateur entre les deux systèmes, des contrôles de cohérence et une période de support double. Elle achète aussi une possibilité de retour arrière. Si le module web ne tient pas ses critères, l’entreprise peut interrompre le lot sans avoir parié toute son activité sur une bascule unique.
Pourquoi une modernisation progressive réduit-elle certains risques ?
Le modèle Strangler Fig remplace progressivement des fonctionnalités tout en maintenant le système historique pour les parties non migrées. Microsoft décrit une façade qui oriente les demandes vers l’ancien ou le nouveau système et souligne que l’ancien peut rester en service pendant la transformation (Microsoft Azure Architecture Center).
Cette approche exige une séparation nette, par exemple un module, une API, un parcours ou une catégorie d’utilisateurs. La façade peut devenir un point de défaillance et les deux systèmes doivent parfois synchroniser leurs données. Microsoft recommande de traiter cette organisation comme une architecture transitoire avec un coût. Donnez à chaque composant transitoire un responsable, une condition de retrait et une date de réévaluation.
Quand repartir de zéro devient-il raisonnable ?
Une reconstruction mérite d’être étudiée lorsque plusieurs conditions convergent, pas seulement parce que la technologie est ancienne.
- Le produit cible a changé. Le logiciel historique automatise un processus que l’entreprise ne veut plus conserver. Reproduire ses écrans serait plus coûteux que redéfinir le parcours.
- Le système est petit et isolable. Peu d’utilisateurs, de règles, d’interfaces et de données rendent une bascule complète vérifiable. Microsoft indique aussi que le remplacement peut être plus simple pour un petit système.
- Aucune séparation sûre n’est possible. Les requêtes ne peuvent pas être interceptées, le code source n’est pas accessible ou chaque modification menace l’ensemble. Le modèle progressif peut alors être inadapté.
- Le niveau de sécurité ou de fiabilité requis est inaccessible. Cette conclusion doit venir de preuves : composants non corrigeables, absence de contrôle, tests impossibles ou architecture incompatible avec l’exigence cible.
- La connaissance de l’existant peut être reconstituée. Les règles utiles, données à reprendre, interfaces et critères d’acceptation sont documentés. Sinon, le nouveau logiciel risque seulement de découvrir les omissions plus tard.
Même dans ces situations, « repartir de zéro » ne signifie pas ignorer l’ancien. La migration des données, la formation, la coexistence temporaire, les contrôles et le retour arrière forment un chantier distinct. Préparez son enveloppe en plus de la construction ; notre guide sur le prix d’une application mobile montre pourquoi les parcours visibles ne représentent qu’une partie du budget.
Comment choisir un premier lot de refonte ?
Le premier lot doit produire une amélioration observable et réduire une inconnue. Choisissez une capacité qui respecte cinq conditions :
- un problème métier nommé par ses utilisateurs ;
- un périmètre assez isolé pour ne pas entraîner tout le logiciel ;
- des données de test et une règle de vérification disponibles ;
- une bascule limitée et un retour arrière explicite ;
- une mesure après livraison, par exemple le temps d’une tâche, le nombre d’erreurs, les incidents ou le délai nécessaire pour livrer l’évolution suivante.
Une nouvelle charte graphique fait rarement un bon premier lot si le risque principal porte sur les données. Une migration technique invisible peut être nécessaire, mais elle doit nommer la capacité débloquée ou le risque réduit. Demandez au prestataire au moins deux trajectoires avec leurs hypothèses, exclusions, flux de données, règle de bascule et comportement en cas d’échec.
Les erreurs qui fragilisent une refonte logicielle
- Choisir d’abord une technologie. Un framework ne définit ni le parcours cible, ni la reprise de données, ni le niveau de service.
- Confondre dette technique et ancienneté. La dette technique est le surcoût futur créé par des choix qui rendent les modifications plus difficiles. Un module ancien mais stable n’est pas automatiquement prioritaire.
- Attendre la fin pour préparer la migration. Les règles de rapprochement, volumes, formats, propriétaires et dépendances doivent être connus avant la bascule.
- Faire coexister deux systèmes sans sortie. Une transition sans condition de décommissionnement transforme un coût temporaire en double maintenance durable.
- Promettre une parité complète. Commencez par prouver quels comportements sont encore utiles. Chaque exception recopiée doit avoir un utilisateur ou une obligation identifiée.
Klaapp accompagne le diagnostic et la refonte de logiciels, d’applications et de sites. Un premier échange peut servir à cartographier un parcours, ses dépendances et ses risques de bascule, puis à choisir un lot testable. La conclusion peut être de reconstruire, de moderniser progressivement ou de conserver une partie du logiciel : l’objectif est de rendre cette décision défendable avant d’engager le chantier.
Questions fréquentes
Combien de temps faut-il pour décider entre refonte et reconstruction ?
Il n’existe pas de durée universelle. La décision devient exploitable lorsque les parcours critiques, les dépendances, les données, les incidents, la continuité et l’état des tests sont documentés. Une exploration technique peut être nécessaire si le code ou une intégration reste inconnu.
Peut-on refaire seulement l’interface d’un logiciel métier ?
Oui, si les règles, les données et les interfaces du socle restent adaptées. Vérifiez toutefois que la nouvelle interface ne masque pas des lenteurs, des droits incohérents ou une API impossible à faire évoluer. Une amélioration visuelle ne corrige pas une fragilité située ailleurs.
Faut-il arrêter les nouvelles fonctionnalités pendant la refonte ?
Pas nécessairement. Une modernisation progressive permet de continuer à livrer, à condition de définir quelles évolutions vont dans l’ancien système et lesquelles préparent la cible. Sans cette règle, l’équipe développe deux versions concurrentes de la même fonction.
Comment vérifier qu’une migration de données a réussi ?
Définissez avant la reprise les volumes attendus, les champs obligatoires, les doublons acceptables, les totaux à rapprocher et des échantillons contrôlés par le métier. Conservez un journal des transformations et un plan de retour arrière tant que la nouvelle source n’est pas validée.
Sources
- Microsoft Azure Architecture Center — Strangler Fig pattern
- AWS Prescriptive Guidance — Evaluating modernization readiness for applications
- AWS Prescriptive Guidance — Application modernization questionnaire
- Martin Fowler — Strangler Fig
Thomas R. est cofondateur de Klaapp. Il porte les choix techniques et relie les possibilités du logiciel aux contraintes concrètes du projet. Découvrir le studio Klaapp.