Refonte d'un logiciel métier : quand, comment, combien

Ce qu'il faut retenir

• Une refonte s'impose sur des signaux précis, pas sur l'âge du logiciel : le développeur qui le connaissait est parti, la plateforme ne reçoit plus de correctifs, ou l'outil bloque l'entreprise. Windows 10, Access, Excel et Office 2016 et 2019 sont hors support depuis le 14 octobre 2025.
• Il existe quatre options : encapsuler l'existant dans une surcouche, le migrer vers une plateforme maintenue, le remplacer par un SaaS ou le réécrire. La réécriture est la dernière branche de l'arbre.
• Un agent de code lit l'ancien logiciel avant qu'on le réécrive : il cartographie les dépendances, inventorie les règles métier avec leur emplacement dans le code et aide à écrire des tests qui comparent l'ancien et le nouveau.
• Pour une PME, la migration progressive, module par module, l'emporte presque toujours sur la bascule en une fois. La reprise des données reste le risque le plus sous-estimé.
• Nous situons une réécriture menée de façon classique entre 80 000 et 150 000 €, pour 6 mois. Avec notre méthode AI-First Delivery, un premier module est en production en 4 semaines, à partir de 20 000 € HT.

Refonte logiciel : de quoi parle-t-on dans une PME ?

Un projet de refonte logiciel commence rarement par une envie. Il commence par une alerte : le seul développeur qui connaissait l'outil part à la retraite, un audit signale des postes encore sous Windows 10, ou une agence rachetée ne peut pas se connecter à la base Access du siège. La refonte d'un logiciel métier consiste à reprendre une application existante pour en changer la technologie, l'architecture ou le périmètre, sans perdre les règles de gestion qu'elle applique.

Ces applications ont des visages connus : une base Access enrichie de code VBA, une application WINDEV, un programme en Visual Basic 6, un intranet en PHP, un classeur Excel chargé de macros. Trois mots à distinguer :

• la refonte : on reconstruit l'application, en tout ou en partie ;
• la migration logicielle : on garde la logique et on change de plateforme (version, base de données, serveur) ;
• le remplacement : on abandonne l'outil pour un progiciel ou un SaaS.

La question se pose avec plus d'acuité depuis le 14 octobre 2025 : ce jour-là, Microsoft a cessé de corriger Access, Excel et l'ensemble d'Office 2016 et 2019, sur lesquels reposent beaucoup d'outils maison, et ne corrige plus Windows 10 que sur les postes inscrits à un programme payant.

Si votre outil est un classeur partagé, voyez comment remplacer Excel par une application métier. S'il tourne sur un IBM i, lisez notre article sur l'AS400.

Quand faut-il refondre un logiciel métier ? Les signaux d'alerte

Le développeur unique est parti, ou va partir

C'est le signal le plus sérieux, parce qu'il ne se voit pas. Le logiciel continue de tourner ; ce qui disparaît, c'est la capacité à le modifier. Posez la question franchement : si cette personne était absente trois mois, qui corrigerait une anomalie ? Dans l'industrie, ce code peut contenir un savoir-faire écrit nulle part ailleurs, comme une règle de tolérance ou un ordre de priorité entre commandes.

La plateforme ne reçoit plus de correctifs de sécurité

Un poste sous Windows 10 continue de fonctionner, rappelle Microsoft ; il ne reçoit plus de correctifs sans souscription au programme ESU. Le guide d'hygiène informatique de l'ANSSI fixe la conduite à tenir : les composants obsolètes qui ne sont plus supportés par leur éditeur doivent être isolés du reste du système d'information, par un filtrage strict des flux et par des secrets d'authentification dédiés. Isoler une base Access partagée entre plusieurs sites est rarement simple.

Le logiciel empêche l'entreprise d'évoluer

L'outil fonctionne, mais il bloque : les conducteurs de travaux n'y accèdent pas depuis un chantier, les données sont ressaisies dans l'ERP, une entreprise rachetée ne trouve pas sa place dans le modèle de données. Chaque contournement ajoute un fichier, une ressaisie ou une personne qui « sait comment faire ».

À l'inverse, l'âge et l'apparence ne suffisent pas. Pour Access, une montée de version vers Access 2024 peut suffire. Le moteur d'exécution de Visual Basic 6 reste supporté sur Windows 11, même si Microsoft recommande fortement de remplacer ces applications. Un outil ancien, documenté, maintenu et qui fait son travail peut rester en place : une refonte se justifie par un risque ou un blocage, pas par l'envie d'un écran neuf.

Réécrire, migrer, remplacer ou encapsuler : l'arbre de décision

Quatre questions, posées dans l'ordre, suffisent à choisir.

1. Le processus est-il propre à votre entreprise ? Pour la paie ou la comptabilité, non : un progiciel porte les règles externes à votre place. Option : remplacer.
2. Le cœur du logiciel est-il maintenu, par un éditeur ou par une équipe ? S'il ne manque que des écrans, un accès mobile ou une intégration, on construit autour. Option : encapsuler.
3. Le code est-il compris, et la plateforme a-t-elle une version supportée ? On change de version ou de socle en gardant la logique. Option : migrer.
4. Sinon, les règles sont à vous et la plateforme n'a pas d'avenir. Option : réécrire, de préférence module par module.

Dans un guide du 23 septembre 2026, Anthropic distingue la montée de version (uplift), la réécriture à comportement constant (transform) et la reconstruction qui change le comportement (reimagine). Décidez donc, module par module, si le nouveau logiciel reproduit l'ancien ou le fait évoluer : mélanger les deux rend chaque écart ambigu.

Migration logicielle : changer de plateforme sans tout réécrire

Quand elle est possible, la migration est l'option la plus économique. Pour une base Access, Microsoft fournit l'outil SQL Server Migration Assistant (SSMA) for Access, qui transfère la base vers SQL Server ou Azure SQL ; l'application Access existante peut ensuite être reliée aux tables migrées. Vous gardez les formulaires, le code VBA et leurs limites. Pour un intranet PHP, migrer consiste à monter vers une branche maintenue au-delà de 2026 (8.3, 8.4 ou 8.5 au 16 octobre 2026).

Remplacer Access ou un outil maison par un SaaS

Le remplacement convient aux processus standard. Il a deux coûts que l'on oublie : l'organisation s'adapte à l'outil, et la licence suit l'effectif. Les critères de choix, réversibilité comprise, sont détaillés dans notre article SaaS ou sur mesure.

Encapsuler l'existant dans une surcouche

Si le logiciel en question est votre ERP, notre conseil ne varie pas : on ne le remplace pas pour régler un problème d'écran ou d'accès, car une erreur sur l'ERP arrête la production. On construit autour : une interface qui expose les données utiles, des écrans pour les usages qu'il couvre mal (voir ERP sur mesure ou ERP français). La surcouche est aussi une étape de la migration progressive : Anthropic décrit des enveloppes d'API autour des composants anciens qui restent en place pendant que le nouveau code prend le relais.

Comment réussir la refonte d'une application métier ?

1. Faire lire l'ancien logiciel par un agent de code

Comprendre ce que fait le code est l'étape la plus chère d'une modernisation, écrit Anthropic dans un article du 23 février 2026 consacré aux applications COBOL. Un agent de code, comme Claude Code, change cette étape. L'article décrit la démarche : l'agent lit l'ensemble du code, repère les points d'entrée, suit les flux de données, cartographie les dépendances, puis signale les modules très couplés, risqués à moderniser, et les composants isolés, bons candidats pour commencer. Le guide de septembre ajoute l'inventaire des règles métier, chacune avec l'endroit du code d'où elle vient.

La démarche vaut, à notre sens, pour du VBA, du WLangage ou du PHP, à condition d'extraire d'abord le code, les requêtes et la structure de la base sous une forme lisible par l'agent.

2. Faire valider les règles par ceux qui s'en servent

L'inventaire produit par l'agent est une hypothèse. Une règle peut être du code mort ; une autre n'existe pas dans le code, parce qu'un utilisateur l'applique à la main. Le référent métier tranche, règle par règle : à garder, à changer, à abandonner.

3. Figer le comportement par des tests de non-régression

On rejoue des cas réels dans l'ancien logiciel, on enregistre ses résultats (un devis, un calcul de délai, un état mensuel), puis on exige que le nouveau donne les mêmes. Anthropic décrit des tests conçus par l'IA pour vérifier que le code migré produit des résultats identiques. L'agent rédige ces tests vite ; le choix des cas (exceptions, clients particuliers, clôtures de fin de mois) revient au métier. L'ANSSI compte d'ailleurs les tests de non-régression et la procédure de migration des données parmi les ressources à prévoir pour chaque logiciel en fin de vie.

4. Bascule en une fois ou migration progressive ?

Martin Fowler a nommé la seconde approche le figuier étrangleur (strangler fig), une plante qui pousse autour d'un arbre jusqu'à le remplacer. Il rappelle qu'un remplacement complet prend du temps, que les utilisateurs ne peuvent pas attendre de nouvelles fonctions et que le comportement exact de l'existant est difficile à établir. Pour une PME, la migration progressive est presque toujours le bon choix ; la bascule en une fois garde sa place pour un outil simple, planifiée sur une période creuse.

5. Migrer les données : le risque le plus sous-estimé

Le code se réécrit ; les données se reprennent, avec leurs défauts : doublons, champs détournés de leur usage (une « remarque » qui contient une date de livraison), dates saisies en texte, accents mal encodés. Cinq précautions :

• décider ce qu'on reprend : tout l'historique, ou les affaires ouvertes et les référentiels, avec l'ancien en lecture seule pour le reste ;
• appliquer les durées de conservation : le RGPD impose de ne pas conserver de données personnelles identifiantes plus longtemps que nécessaire au regard de leur finalité, et la reprise est le moment de purger ;
• répéter la migration plusieurs fois sur une copie avant le jour réel ;
• contrôler par des chiffres : nombre de clients, d'affaires ou d'articles, totaux des montants, comparés entre l'ancien et le nouveau ;
• prévoir le retour arrière : qui décide, à partir de quel écart, et comment.

Enfin, une refonte n'est terminée que lorsque l'ancien logiciel est arrêté : passez-le en lecture seule à une date fixée, archivez ses données, puis éteignez-le.

Combien coûte la refonte d'un logiciel métier, et en combien de temps ?

Garder l'existant a aussi un prix. Pour les organisations, Microsoft vend les mises à jour de sécurité étendues de Windows 10 61 $ par poste la première année, un prix qui double chaque année, pour trois ans au plus ; les années sont cumulatives : qui souscrit la deuxième année paie aussi la première. Exemple illustratif : couvrir 20 postes sous Windows 10 sur les trois années du programme coûte 20 × (61 + 122 + 244) = 8 540 $ de licences. Ces mises à jour couvrent Windows : elles ne corrigent ni Access 2016 ni le code de votre application.

Appliquée à une refonte, la phase 1 met en production le cœur du besoin : le premier module, celui qui porte le plus de risque ou de valeur. Le forfait de phase 2 consolide ce module (sécurité, tests, supervision) ; les modules suivants peuvent s'ajouter au fil de l'abonnement, qui inclut de nouvelles fonctionnalités chaque mois. Les 4 semaines comptent une semaine de recueil des besoins et d'architecture, deux de développement, une de mise en production et de formation. L'IA écrit le code ; nos ingénieurs et docteurs en IA le relisent et le valident. Le délai suppose un référent métier disponible et un accès rapide aux données.

La facture varie surtout avec le volume de règles métier, l'état des données, les intégrations (ERP, annuaire, comptabilité), les exigences de sécurité et la durée de coexistence entre l'ancien et le nouveau. Taux journaliers et coût sur cinq ans : voir le prix d'un logiciel sur mesure.

Quel impact concret pour une PME ou une ETI ?

Dans l'industrie, le code d'un outil métier décrit votre façon de produire : s'il doit être lu par un modèle d'IA, l'endroit où tourne ce modèle compte. C'est le sujet de notre offre d'IA souveraine, sur nos propres serveurs GPU en France. Dans le BTP et les travaux publics, l'enjeu est plus direct : un outil de chiffrage ou de suivi de chantier qui ne s'ouvre qu'au bureau oblige à ressaisir ce qui a été noté sur le terrain.

Cinq décisions permettent de démarrer :

1. Faire l'inventaire des outils maison, de leur plateforme et de sa date de fin de support : c'est la première précaution que l'ANSSI recommande contre l'obsolescence.
2. Isoler dès maintenant ce qui n'est plus supporté, sans attendre la refonte.
3. Faire lire le code avant de demander un prix : un devis établi sans lecture de l'existant repose sur des suppositions.
4. Commencer par le module le plus risqué ou le plus utile, et le mettre en production avant de lancer le suivant.
5. Exiger le code source et la documentation, pour ne pas remplacer la dépendance à une personne par la dépendance à un prestataire. Dans notre offre de développement de logiciel sur mesure, le code vous appartient et vous est livré documenté.

Pour savoir quel outil traiter en premier, un diagnostic data et IA, cofinançable selon votre situation, classe les chantiers. Si votre équipe préfère mener la lecture elle-même, notre formation Claude Code pour les développeurs dure deux jours ; en intra, les exercices portent sur son propre code.

Les limites d'une refonte assistée par l'IA

L'agent lit le code, pas les usages. Les contournements et les règles transmises oralement n'y figurent pas : seuls les utilisateurs peuvent les décrire.

Les tests ne valent que par les cas choisis. Un cas rare, absent du jeu de tests, passera sans alerte.

Sur un langage propriétaire ou peu répandu, vérifiez avant de vous fier. Pour du WLangage ou un VBA ancien, contrôlez la lecture de l'agent sur un échantillon de règles connues avant de l'étendre à tout le logiciel.

Le goulot se déplace vers l'organisation. Anthropic l'écrit lui-même : quand l'IA produit vite les modifications, la difficulté devient de mobiliser l'organisation autour d'elles. Ses publications décrivent d'ailleurs une méthode, pas une mesure indépendante de ses résultats.

Conclusion : refondre les règles, pas seulement le code

Ce qui a de la valeur dans un vieux logiciel métier, ce sont les règles qu'il applique et que personne n'a écrites ailleurs. Une refonte réussie les retrouve, les fait valider, les fige dans des tests, puis les reconstruit module par module sur une plateforme maintenue.

Ce qui a changé, c'est le coût de la première étape. Quand un agent de code peut lire un logiciel ancien et en extraire l'inventaire des règles, la question n'est plus de savoir si l'entreprise peut payer l'analyse, mais quel outil traiter en premier, avant que la seule personne qui le comprenait ne soit partie.

Lire aussi : AS400 (IBM i) : le garder, le moderniser ou le remplacer

Sources

• Microsoft Learn — Ending Support in 2025, cycles de vie d'Access 2024, de Windows 10 Enterprise LTSC 2021 et de Windows 10 Enterprise LTSC 2019, programme Extended Security Updates (ESU) de Windows 10 (consultés le 16/10/2026)
• Microsoft Learn — Support Statement for Visual Basic 6.0 et SQL Server Migration Assistant for Access (consultés le 16/10/2026)
• The PHP Group — Supported Versions et Unsupported Branches (consultés le 16/10/2026) ; PC SOFT — WINDEV 2026 (consulté le 16/10/2026)
• ANSSI — Guide d'hygiène informatique, mesures 34 et 35 (version 2.0, septembre 2017)
• Anthropic — How AI helps break the cost barrier to COBOL modernization (23/02/2026) et How to prepare for AI-driven code modernization projects (23/09/2026)
• Martin Fowler — Strangler Fig Application (version du 22/08/2024)
• CNIL — Règlement général sur la protection des données, chapitre II, article 5 (consulté le 16/10/2026)

Votre logiciel métier repose-t-il sur une seule personne, ou sur une version d'Access qui ne reçoit plus de correctifs ? Savez-vous quelles règles de gestion il applique, et où elles sont écrites ? Parlons-en : nous vous aidons à choisir l'outil à traiter en premier, puis à mettre son remplaçant en production en 4 semaines.