Waimia.
AccueilRessourcesGuidesRefonte de logiciel métier : garder, réécrire ou remplacer FR Édition française ◉ Disponible
Illustration : une grue retire un module usé d'un immeuble de modules, un module neuf attend au sol

§ Guide

Refonte de logiciel métier : garder, réécrire ou remplacer ?

En une phrase

Refondre un logiciel métier, c'est choisir entre trois voies : le garder et le nettoyer, le réécrire par morceaux, ou le remplacer par un produit du marché. Le choix se fait module par module, après trois tests : qui détient le code, quelles dépendances ne sont plus maintenues, quelles données reprendre. L'IA accélère certains travaux, pas la décision. Relevé le 16 octobre 2026.

  • Sources lues le 16 octobre 2026
  • Aucun prix de prestataire repris
  • Pas un avis juridique

Réponse directe

Faut-il garder, réécrire ou remplacer un logiciel métier ?

Réponse courte

Gardez ce qui fonctionne et que vous savez maintenir. Réécrivez, morceau par morceau, ce qui porte une règle propre à votre métier. Remplacez ce qu'un produit du marché fait sans contournement. Évitez la réécriture complète d'un coup : Martin Fowler constate que ce plan échoue le plus souvent. Avant de choisir, vérifiez qui détient le code, quelles dépendances ne sont plus maintenues et quelles données reprendre. Relevé le 16 octobre 2026.

§ Trois voies

Garder, réécrire par morceaux, remplacer : ce que chaque voie suppose

Synthèse de Waimia à partir de deux guides de prestataires lus le 16 octobre 2026 (Pulse.digital et TechMind). Ils nomment les options différemment (refactor, replatform, rebuild, replace d'un côté ; moderniser, réécrire, remplacer de l'autre) et nous ne reprenons aucun de leurs prix.
Voie Principe Elle convient si Son risque
Garder et nettoyer Garder le code, restructurer ce qui est dégradé, mettre à jour les dépendances, éventuellement changer d'hébergement. La logique métier est juste, le code est dégradé, et les fondations sont encore maintenues. Rénover un socle qui n'est plus maintenu, et repousser le problème au lieu de le traiter.
Réécrire par morceaux Reconstruire sur des fondations modernes en reprenant les règles métier éprouvées, un module après l'autre, l'ancien outil restant en service. Le module porte une règle propre à votre entreprise et son code est trop dégradé pour être sauvé. Le grand soir, ou recopier l'ancien outil écran par écran, défauts compris.
Remplacer par un produit du marché Adopter un logiciel existant et adapter vos process à ce qu'il fait. Le process n'a plus rien de spécifique et un produit du marché le couvre sans contournement. Plier le process aux cases de l'éditeur, ou sous-estimer la reprise des données.

Trois tests avant de choisir une voie

Ce guide traite d'un logiciel métier. Pour un site web, c'est un autre projet : voir le guide refonte de site internet. L'Office québécois de la langue française définit la refonte de logiciel comme le processus qui consiste à revoir la conception d'un logiciel depuis ses fondements, de façon à l'améliorer.

Le code est-il à vous ? Lisez le contrat d'origine : détenez-vous le code source, avec le droit de le modifier ? Sans lui, une réécriture à partir de l'existant est bloquée, et il reste le remplacement ou la reconstruction à partir des écrans et des règles observées. Ce n'est pas un avis juridique.

Les dépendances sont-elles maintenues ? Langage, framework, base de données, bibliothèques, hébergement : si un composant n'est plus maintenu, rénover le reste ne règle pas le risque. Pulse.digital compte parmi les coûts d'un logiciel ancien ses dépendances non maintenues, donc une surface d'attaque plus large.

Quelles données reprendre ? Historique, formats incohérents, règles implicites : Pulse.digital note que les données historiques sont souvent sous-estimées. Décidez ce que vous migrez, ce que vous archivez et ce que vous abandonnez, puis rejouez la reprise sur une copie avant toute bascule.

§ Module par module

Que faire de chaque module : valeur métier et état du code

Cadre de choix de Pulse.digital, lu le 16 octobre 2026, repris sous forme de tableau. Le choix se fait module par module, pas pour le logiciel entier.
Module Que faire
Forte valeur métier, code sain Le protéger par des tests, n'y toucher que pour corriger.
Forte valeur métier, code dégradé Priorité de la refonte : restructurer, ou reconstruire par incréments.
Faible valeur métier, code sain Changer l'environnement (hébergement, base de données) sans investissement lourd.
Faible valeur métier, code dégradé Le remplacer par un produit du marché, ou le décommissionner.

Réécrire sans arrêter l'activité : le principe du figuier étrangleur

Dans son billet StranglerFigApplication (version du 22 août 2024), Martin Fowler constate que le plan de remplacement qui paraît simple échoue le plus souvent. Remplacer un système sérieux prend du temps, les utilisateurs n'attendent pas de nouvelles fonctions, et une partie des comportements reproduits n'était pas voulue. Il propose de commencer par de petits ajouts, puis de déplacer peu à peu les comportements de l'ancien système vers le nouveau.

Concrètement, l'ancien outil reste en service jusqu'à ce que le nouveau ait prouvé, morceau par morceau, qu'il porte la charge : c'est la formulation de TechMind. Chaque morceau migré se valide face à l'existant avec les utilisateurs clés avant la bascule, puis l'extinction de l'ancien se planifie, comme le décrit Pulse.digital.

Les erreurs relevées dans ces guides se ressemblent : recopier l'ancien outil écran par écran, changer l'outil et les process en même temps, continuer à faire évoluer l'ancien pendant le chantier, négliger l'adhésion des utilisateurs.

L'IA accélère l'écriture du code. Elle ne dit pas ce qu'il faut garder, ni quand éteindre l'ancien outil.

Ce que l'IA change à une réécriture, et ce qu'elle ne change pas

La documentation de Claude Code décrit un assistant qui lit une base de code, modifie des fichiers et lance des commandes. Parmi les tâches qu'elle cite : écrire des tests pour du code qui n'en a pas, corriger des erreurs de lint sur tout un projet, résoudre des conflits de fusion, mettre à jour des dépendances. Ses bonnes pratiques recommandent aussi de lui poser, sur une base de code inconnue, les questions qu'on poserait à un autre ingénieur.

Pour une réécriture, cela touche surtout quatre travaux : comprendre l'existant, poser des tests avant de modifier, mettre à jour les dépendances, migrer des fichiers par lots. La documentation donne en exemple une migration fichier par fichier de Python 2 vers Python 3. Ces travaux se vérifient : elle demande de donner à l'outil un test ou un build qu'il peut lancer, et conclut que ce que l'on ne peut pas vérifier ne se livre pas (bonnes pratiques).

Ce que l'IA ne change pas : décider ce que l'on garde, reprendre les données, obtenir l'adhésion des utilisateurs, relire. La page sécurité d'Anthropic indique que vous restez responsable de la relecture du code et des commandes proposés avant approbation. Ce guide ne donne aucun chiffre de gain de temps : il dépend de votre code, de ses tests et de ses données, et nous ne reprenons aucune promesse chiffrée.

Un générateur d'application par IA convient surtout au prototype : voir le comparatif Lovable ou développement sur mesure. Le raisonnement sur le coût d'un outil sur mesure est dans l'article développer ou acheter un outil interne.

§ La méthode

Une refonte en six étapes

La trame que nous suivons pour un outil métier. Elle reprend les étapes des guides lus (audit, priorisation, migration par incréments, parité, extinction) et le cadre de Waimia.

  1. Inventorier l'existant

    Avant de coder

    Modules, flux, intégrations, usages réels : qui se sert de quoi, et ce qui n'est plus utilisé du tout.

  2. Classer chaque module

    Une décision par module

    Valeur métier et état du code : le tableau ci-dessus donne la voie de chacun.

  3. Reprendre les données sur une copie

    Sur une copie

    Extraire, nettoyer, rejouer la reprise et contrôler des cas connus avant toute bascule.

  4. Livrer un premier morceau

    Périmètre étroit

    Un périmètre étroit, fixé par écrit. Chez Waimia : sprint de cadrage de 10 heures à 999 € HT, qui livre un prototype testé.

  5. Faire tourner l'ancien et le nouveau en parallèle

    En parallèle

    Basculer par groupe d'utilisateurs, valider la parité avec les utilisateurs clés. La mise en production relève du pilote, dès 2 000 € HT.

  6. Éteindre l'ancien outil

    Extinction planifiée

    À une date écrite. Code, base de données et documentation de la nouvelle version vous sont remis.

§ Position Waimia

Quand nous confier la refonte, et quand acheter ou attendre

Recommandations de Waimia.

Confiez-nous la refonte si
  • Le logiciel est un outil interne dont le process est propre à votre métier : suivi de chantiers, de dossiers, de commandes
  • Vous voulez que le code, la base de données et la documentation de la nouvelle version soient remis à votre nom
  • Vous acceptez de commencer par un périmètre étroit et de garder l'ancien outil en service le temps de la bascule
Achetez ou attendez si
  • Un produit du marché couvre déjà le besoin sans contournement : achetez-le, ce sera moins cher
  • Le domaine est mûr : comptabilité, paie, signature électronique, messagerie
  • Personne ne sait écrire ce que le logiciel doit faire : commencez par un audit, pas par une réécriture
§ Charte IA · PDF gratuit

Si l'IA touche au code ou aux données de la refonte : écrivez les règles avant

Le modèle de charte IA pour PME compte neuf articles et cinq pages, dont les données qui ne passent jamais par un outil d'IA, ce qui sort d'une IA comme brouillon à relire, et la propriété intellectuelle. Le PDF part uniquement par e-mail, en pièce jointe.
  • Le modèle complet en neuf articles, mis en page pour être imprimé et signé
  • Les notes d'adaptation pour l'ajuster à votre entreprise
  • Un seul e-mail, sans inscription à une liste

Refonte de logiciel métier : questions fréquentes

Q.01 Qu'est-ce qu'une refonte de logiciel ?

L'Office québécois de la langue française la définit comme le processus qui consiste à revoir la conception d'un logiciel depuis ses fondements, à la lumière de l'état actuel des techniques et de la connaissance, de façon à l'améliorer. Pour un logiciel métier, cela recouvre trois voies : garder et nettoyer, réécrire par morceaux, ou remplacer par un produit du marché. Relevé le 16 octobre 2026.

Q.02 Refonte de logiciel ou refonte de site : quelle différence ?

Un site se refond en gardant son référencement, avec des redirections. Un logiciel métier se refond en gardant ses données, ses règles et ses utilisateurs, sans arrêter l'activité. Les deux projets n'ont ni les mêmes risques ni les mêmes étapes. Si votre sujet est un site web, le guide sur la refonte de site internet traite les redirections 301 et le référencement à conserver.

Q.03 Faut-il tout réécrire d'un coup ?

Non, d'après les trois sources lues. Martin Fowler constate que le plan de remplacement qui paraît simple échoue le plus souvent. Pulse.digital écrit que le big bang est l'anti-méthode. TechMind conseille de garder l'ancien système en service tant que le nouveau n'a pas prouvé, morceau par morceau, qu'il porte la charge. La migration se fait par incréments, avec coexistence.

Q.04 Combien coûte la refonte d'un logiciel métier ?

Cela dépend du périmètre, des dépendances et des données à reprendre. Nous ne reprenons aucune fourchette de prestataire. Chez Waimia, le sprint de cadrage dure 10 heures et coûte 999 € HT ; il livre un prototype testé. La mise en production relève du pilote, dès 2 000 € HT. Le périmètre de la première version est fixé au cadrage, par écrit, avant de construire.

Q.05 L'IA permet-elle de refondre un logiciel plus vite ?

Elle accélère certains travaux : comprendre un code inconnu, écrire des tests, mettre à jour des dépendances, migrer des fichiers par lots, d'après la documentation de Claude Code. Elle ne décide ni ce qu'on garde, ni quelles données reprendre, ni quand éteindre l'ancien outil. Nous ne donnons aucun chiffre de gain : il dépend de votre code, de ses tests et de ses données. Relevé le 16 octobre 2026.

Q.06 À qui appartient le code après la refonte ?

À vous. Pour les applications métier que nous développons, le code source, la base de données et la documentation vous sont remis, et l'application tourne sur vos comptes d'hébergement. Un autre développeur peut donc reprendre le travail. Pour l'ancien logiciel, lisez le contrat d'origine : sans accès au code source, la réécriture à partir de l'existant est bloquée. Ce n'est pas un avis juridique.

Q.07 Quand vaut-il mieux remplacer que réécrire ?

Quand le process n'a plus rien de spécifique et qu'un produit du marché le couvre sans contournement quotidien. Les domaines mûrs, comme la comptabilité, la paie, la signature électronique ou la messagerie, relèvent presque toujours de l'achat. La méthode en quatre questions est dans l'article développer ou acheter un outil interne.

Page mise à jour le par , fondateur de Waimia.