Elle tourne depuis dix ou quinze ans et gère vos devis, votre stock ou votre planning. Un prestataire local l’a écrite en WinDev, ou bien un salarié débrouillard l’a montée sous Access, voire dans un classeur Excel bardé de macros. Elle fait le travail, mais plus personne n’ose y toucher. Elle ne tourne en outre que sur Windows, et vos équipes terrain la contournent avec des photos et des messages WhatsApp. Moderniser une application métier dans ces conditions est une décision lourde : le risque de casser ce qui fonctionne est réel. Par ailleurs, les devis reçus vont du simple au quadruple.
Chez Playmoweb, nous reprenons régulièrement ce type d’application, notamment dans l’industrie, l’agriculture, le médical ou les services. En plus de 12 ans, nous avons vu des refontes réussies et d’autres qui ont coûté deux fois le budget prévu. Voici les 10 signes qui indiquent qu’il est temps d’agir et les 3 stratégies possibles. Nous détaillons ensuite notre méthode en 5 étapes, des ordres de grandeur de budget et les pièges à éviter.
Sommaire
Tordons d’abord le cou à une idée reçue : ni WinDev ni Access ne sont des technologies mortes. PC SOFT a en effet publié la version finale de WinDev 2026 en décembre 2025. Des mises à jour régulières ont suivi, notamment des webservices REST et des fonctions d’IA. De même, Microsoft inclut toujours Access dans Microsoft 365. Quant à la version perpétuelle Access LTSC 2024, elle est supportée jusqu’en octobre 2029. Autrement dit, les éditeurs sont là et les outils évoluent.
Le vrai sujet, c’est plutôt votre application. Prenons par exemple une application WinDev de 2012, jamais mise à jour, sans tests ni documentation. Elle pose exactement les mêmes problèmes qu’une application Java ou PHP de la même époque. Ce n’est donc pas la technologie qui vieillit mal, mais l’absence de maintenance et l’architecture d’origine. Celle-ci combine en général une base de données locale, une logique métier mélangée aux écrans et aucune interface avec le reste du système d’information.
Deux échéances restent néanmoins à surveiller. Tout d’abord, Access 2021 et Office LTSC 2021 sortent du support le 13 octobre 2026. Access 2016 et 2019 les ont précédés en octobre 2025. Ensuite, Windows 10 n’est plus supporté depuis le 14 octobre 2025. Le programme payant de mises à jour de sécurité étendues prolonge certes les correctifs, mais il s’arrête en octobre 2027. Sans lui, un poste Windows 10 qui fait tourner votre application métier est donc un poste sans correctif de sécurité.
Voici les signaux que nous relevons en audit. Lorsque trois signes sont cochés, planifiez la modernisation dans les 18 mois. À partir de cinq, c’est une priorité.
En réalité, aucun de ces signes ne se règle en changeant de langage. Il faut au contraire une architecture qui sépare données, logique métier et interfaces, ainsi qu’une maintenance prévue dès le départ.
Il n’existe pas une seule bonne réponse. C’est pourquoi nous utilisons trois stratégies, parfois combinées sur un même projet.
Encapsuler. On garde le cœur de l’application et sa base de données, mais on met une API devant. Cette API alimente une application web ou mobile moderne pour les usages qui manquent : saisie terrain, espace client, tableau de bord. C’est ce que nous avons fait pour connecter un assistant IA à l’ERP EBP via un serveur MCP. L’ERP n’a pas bougé ; en revanche, l’usage a changé. Rapide et peu risquée, l’encapsulation laisse toutefois en place la dette du cœur.
Migrer par morceaux. C’est l’approche dite « strangler » : on remplace module par module (les devis, puis le stock, puis le planning). Chaque nouveau module s’appuie alors sur une base moderne et une API. L’ancienne application rétrécit ainsi jusqu’à disparaître. C’est notre approche par défaut au-delà de 20 écrans, car elle lisse budget et risque sur 12 à 24 mois.
Réécrire complètement. On repart d’une page blanche fonctionnelle, avec une migration unique des données. C’est la bonne option lorsque le périmètre est petit ou que le code source est perdu. Elle convient aussi quand les process ont tellement changé que l’application existante n’est plus un modèle utile.
| Critère | Encapsuler | Migrer par morceaux | Réécrire |
|---|---|---|---|
| Situation type | Cœur sain mais fermé, besoin mobile ou d’intégration urgent | Application large, critique, impossible à arrêter | Petite application, code perdu, process obsolètes |
| Risque de rupture | Faible | Faible à modéré | Élevé en cas de bascule unique |
| Premier gain visible | Quelques semaines | 3 à 4 mois (premier module) | À la fin du projet |
| Dette technique résiduelle | Conservée | Réduite au fur et à mesure | Supprimée |
| Étalement du budget | Faible investissement initial | Lissé sur 12 à 24 mois | Concentré |
| Exige le code source | Non | Oui, afin de lire la logique métier | Non, mais utile |
Un critère domine toutefois souvent : avez-vous le code source et un accès direct à la base ? Sans le code, la réécriture devient en effet le choix par défaut. Posez-vous aussi la question du sur mesure ou du SaaS. Si un logiciel du marché couvre 80 % du besoin, la refonte peut alors se limiter aux 20 % vraiment spécifiques.
1. Audit de l’existant. Pendant deux à trois semaines, nous lisons d’abord le code s’il existe, analysons la base et interrogeons les utilisateurs clés. Nous listons ensuite les dépendances : versions de Windows et d’Office, imprimantes, lecteurs de codes-barres, exports comptables. C’est notre offre d’audit technique, avec un rapport qui chiffre les trois stratégies. Elle suit également la même démarche que pour reprendre une application d’un autre prestataire.
2. Cartographie des données et des flux. Quelles tables sont vivantes, quels champs servent vraiment, d’où viennent les données et où vont-elles. Dans une application de quinze ans, nous constatons régulièrement qu’un tiers des tables et des écrans ne servent plus. Les identifier évite par conséquent de payer leur réécriture.
3. Priorisation des modules. On classe les modules selon leur valeur pour les utilisateurs et leur risque technique. Le premier module livré est donc celui qui apporte un gain visible tout en restant isolable. Il s’agit souvent de la version mobile d’une saisie terrain. C’est notre logique MVP appliquée à la refonte. Autrement dit, nous validons l’architecture et l’adhésion des équipes avec 30 à 50 % du budget avant d’engager le reste.
4. Migration et nettoyage des données. Scripts de migration, dédoublonnage et normalisation des référentiels (clients, articles, unités). Puis viennent des migrations à blanc, répétées jusqu’à obtenir un résultat identique à chaque exécution. C’est pourtant la phase la plus sous-estimée.
5. Période de double run. L’ancienne et la nouvelle application tournent en parallèle pendant deux à six semaines par module. On compare les résultats (mêmes totaux, mêmes documents générés) et on forme les utilisateurs sur des cas réels. Enfin, on ne coupe l’ancien outil qu’après validation écrite des responsables métier.
Côté technologie, nous livrons une application web pour les postes de bureau. Sur mobile, notre application Kotlin Multiplatform couvre Android et iOS avec 20 à 40 % d’économie par rapport à deux développements natifs. Le tout repose sur une API unique, qui devient de ce fait la colonne vertébrale de votre système d’information.
Le budget dépend du nombre d’écrans à reconstruire, ainsi que du nombre d’utilisateurs et de rôles. Il varie également selon les règles métier cachées dans le code et l’état des données. Voici les ordres de grandeur que nous observons en 2026 pour une refonte web, mobile en option.
| Périmètre | Repères | Ordre de grandeur | Durée indicative |
|---|---|---|---|
| Encapsulation : API + application mobile ou web ciblée | Cœur conservé, 5 à 10 écrans neufs, 1 à 2 intégrations | 25 à 50 k€ | 2 à 4 mois |
| Petite application métier | 10 à 25 écrans, 5 à 30 utilisateurs, 1 à 2 rôles | 40 à 80 k€ | 3 à 6 mois |
| Application complète | 25 à 60 écrans, 30 à 200 utilisateurs, plusieurs rôles, intégration ERP ou comptabilité | 80 à 200 k€ | 6 à 12 mois |
| Plateforme étendue | Plus de 60 écrans, multi-sites, portail client, mobile terrain | 200 k€ et plus | 12 à 24 mois, par lots |
Important : ces fourchettes couvrent la conception, le développement, la migration des données et le double run. En revanche, elles n’incluent pas l’hébergement, les licences tierces ni le temps de vos équipes en recette et formation. Quant à la maintenance, également exclue, elle est à prévoir à hauteur de 15 à 25 % du coût initial par an. Sur une application ancienne, la migration et le nettoyage des données pèsent à eux seuls 10 à 20 % du budget. Par conséquent, si un prestataire les chiffre à quelques jours, demandez comment.
Ces montants sont cependant à mettre en face du coût de l’inaction. Il peut s’agir par exemple d’une journée d’arrêt d’atelier, d’une erreur de facturation ou d’une fuite de données clients. Sans parler de la seule personne qui sait redémarrer le serveur, le jour où elle quitte l’entreprise. Finalement, c’est souvent ce coût-là qui déclenche la décision.
Réécrire à l’identique. C’est le piège numéro un. En effet, reproduire écran par écran l’application de 2010 revient à conserver ses 40 champs par formulaire et ses contournements. Autrement dit, vous payez pour figer ses défauts.
Sous-estimer les données. Une base Access ou HFSQL de quinze ans contient notamment des doublons et des dates au format texte. On y trouve aussi des clés cassées et des champs détournés. Sans nettoyage, la nouvelle application hérite de ce chaos, si bien que les utilisateurs perdent confiance dès la première semaine.
Oublier les utilisateurs et la formation. L’ancienne application est laide, mais vos équipes saisissent une commande en 30 secondes les yeux fermés. Pour peu que la nouvelle demande trois clics de plus, ils reviendront à Excel. C’est pourquoi les utilisateurs clés doivent participer à la priorisation et tester chaque module.
Arrêter l’ancien outil trop tôt. Couper l’ancienne application dès la mise en production, sans double run ni retour arrière, transforme le moindre bug en crise. Au contraire, gardez-la en lecture seule au moins trois mois après la bascule.
Repartir sans API. Refaire une application fermée avec une technologie moderne, c’est en fait préparer la même refonte dans dix ans. L’API doit donc être le premier livrable, même si sa seule cliente au départ est votre interface web. En effet, c’est elle qui permettra demain le mobile, les intégrations et les assistants IA.
Si trois de ces questions restent sans réponse, c’est alors le rôle d’un audit technique. En deux à trois semaines, vous obtenez une cartographie de l’existant, un chiffrage des trois stratégies et une recommandation argumentée. Vous restez ensuite libre de poursuivre avec nous ou non.
Votre application métier montre des signes de fatigue ? Contactez-nous pour un échange gratuit et sans engagement : nous vous dirons en toute franchise s’il faut l’encapsuler, la migrer ou la réécrire. 👉 playmoweb.com/nous-contacter