Une application WinDev qui tourne depuis douze ans n’est pas un problème. Une application WinDev que deux personnes savent faire évoluer, dont la chaîne de compilation n’a pas été rejouée depuis trois ans, et qui émet vos factures clients : c’est un sujet d’arbitrage.
Quatre décisions sont possibles. Aucune n’est mauvaise par nature. Elles se choisissent sur des chiffres, pas sur une opinion. Cet article donne la structure de coûts, les délais réalistes et les risques de chacune, puis une grille à six critères pour trancher.
Pourquoi la question se pose en 2026, et pas en 2023
Trois facteurs se sont additionnés.
Le calendrier fiscal. Depuis le 1er septembre 2026, toutes les entreprises assujetties à la TVA doivent être en mesure de recevoir une facture électronique via une plateforme agréée. L’obligation d’émission s’applique déjà aux grandes entreprises et aux ETI. Elle s’étend aux TPE et PME au 1er septembre 2027. Si l’une de vos applications WinDev émet des factures, vous avez douze mois, pas trois ans.
La rareté de la ressource. Le WLangage reste un environnement productif et largement déployé dans le tissu industriel français. Mais le marché des développeurs qui le maîtrisent est étroit, et il ne s’élargit pas. Le risque n’est pas technique, il est humain : que se passe-t-il si votre développeur WinDev part en juillet ?
Le cycle éditeur. PC SOFT publie une version majeure par an, la version courante étant WINDEV 2026. Rester dans le cycle a un coût récurrent connu. En sortir a un coût différé, qui ne devient visible qu’au premier incident système.
Le coût de la non-décision, lui, est toujours le même : vous payez le scénario 1 en croyant ne rien décider.
Les quatre chiffres à réunir avant d’arbitrer
Aucun scénario ne se chiffre sans ces quatre données. Si vous ne les avez pas, la première dépense à engager est un audit, pas une migration.
- Le volume réel : nombre d’applications, lignes de WLangage, nombre de fenêtres et d’états, taille et structure de la base HFSQL.
- Le facteur de dépendance : combien de personnes, aujourd’hui, peuvent livrer une évolution en production. Si la réponse est 1, c’est votre risque numéro un, quel que soit le scénario retenu.
- La part différenciante : quel pourcentage des règles métier est spécifique à votre activité, et quel pourcentage est un processus standard que 200 progiciels savent faire.
- Le rythme d’évolution : nombre de demandes de modification par an sur les trois dernières années. Une application stable et une application sous pression ne s’arbitrent pas de la même façon.
Vous n’avez pas ces quatre chiffres ?
Un audit de code source les produit en quelques jours, avant tout engagement de migration.
Comparatif des quatre scénarios
Lecture des indices. Indice 100 = le coût complet de votre parc WinDev sur douze mois aujourd’hui : licences et abonnements, ressource de développement interne ou externe, TMA, hébergement. Les indices ci-dessous sont des ordres de grandeur destinés à structurer l’arbitrage, pas un devis. Deux parcs de taille identique peuvent varier d’un facteur 3 selon la qualité du code et le niveau de documentation.
| Scénario | Investissement initial | Coût annuel ensuite | Délai de mise en œuvre |
|---|---|---|---|
| 1. Rester et payer | Nul | 100, avec une dérive de 5 à 12 % par an | Immédiat |
| 2. Figer la version | 5 à 15 (gel propre) | 55 à 75, puis remontée en année 3 | 1 à 3 mois |
| 3. Réécrire | 250 à 600 | 50 à 80 | 6 à 18 mois |
| 4. Solution du marché | 120 à 350 | 70 à 130 (abonnement et intégrations) | 4 à 12 mois |
| Scénario | Risque principal | Réversibilité | Le bon choix quand |
|---|---|---|---|
| 1. Rester et payer | Dépendance à une ressource rare | Totale | Le parc est stable et l’équipe l’est aussi |
| 2. Figer la version | Sécurité et compatibilité système | Bonne les 24 premiers mois | Une fin de vie est déjà datée |
| 3. Réécrire | Effet tunnel, perte de règles métier | Faible passé le cadrage | L’application porte votre différenciation |
| 4. Solution du marché | Écart fonctionnel sur les 20 % spécifiques | Faible après reprise de données | Le processus est standard |
Scénario 1. Rester et payer
Vous maintenez l’abonnement, vous montez de version chaque année, vous continuez à faire évoluer en WLangage.
Coût. Trois lignes : abonnement ou licences par poste de développement, ressource de développement (interne, ESN ou TMA), hébergement et serveur HFSQL. La dérive annuelle vient rarement de l’éditeur. Elle vient du prix de la ressource : plus le vivier se réduit, plus le taux journalier monte.
Délai. Aucun. C’est le seul scénario qui ne demande aucun projet.
Risques. Le premier est la dépendance à une ou deux personnes. Le deuxième est la dette d’interface : chaque nouvelle brique du système d’information (plateforme agréée de facturation, portail client, application mobile) doit se connecter à un existant qui n’a pas été conçu pour cela. Le troisième est le plus insidieux : la décision n’est jamais prise, elle est reportée douze mois de plus, chaque année.
Quand c’est le bon choix. Le parc est stable, les demandes d’évolution sont peu nombreuses, l’équipe est en place et le restera, et aucune échéance réglementaire ne touche les applications concernées. C’est un scénario parfaitement défendable, à condition de l’avoir choisi.
Signal d’alerte. Une seule personne détient la connaissance, et son départ n’a pas de plan de continuité. Traitez ce point avant tout le reste : documentation, reprise de la chaîne de compilation, binôme. Cela coûte quelques jours, pas un projet.
Scénario 2. Figer la version
Vous arrêtez les montées de version. L’application reste en production, en l’état, sans évolution fonctionnelle. Vous ne payez plus que le maintien en conditions opérationnelles.
Coût. Le gel propre est un mini-projet, pas une non-action : archiver la chaîne de compilation complète, geler l’environnement de développement dans une machine virtuelle documentée, sauvegarder les sources et les schémas HFSQL, écrire la procédure de restauration et la tester. Comptez 5 à 15 points d’indice. Ensuite, la facture baisse réellement, les deux premières années.
Délai. 1 à 3 mois pour geler correctement.
Risques. Ils sont tous différés, et ils arrivent tous en même temps.
- Compatibilité système : une montée de Windows Server, une politique TLS durcie, un changement de pilote d’impression, et l’application ne démarre plus. Sans environnement de build reconstituable, vous ne pouvez même pas recompiler un correctif.
- Sécurité : plus de correctifs applicatifs. Si l’application est exposée ou manipule des données personnelles, l’exposition RGPD devient un sujet de gouvernance, pas d’informatique.
- Réglementaire : c’est le mur le plus prévisible. Une application figée qui émet des factures ne passera pas l’échéance du 1er septembre 2027 pour les TPE et PME. Une application figée qui produit un FEC ou tient un journal d’encaissement soumis à la norme NF525 pose la même question.
- Recrutement : plus personne n’acceptera de reprendre le sujet, y compris en prestation.
Quand c’est le bon choix. Une fin de vie est déjà datée et documentée : arrêt d’un site, sortie d’une activité, remplacement déjà engagé par ailleurs. Figer 24 mois pour financer autre chose est un arbitrage sain.
La règle non négociable. Un gel sans date de sortie n’est pas un scénario, c’est un report. Inscrivez la date au comité de direction, avec le budget associé.
Scénario 3. Réécrire
Vous reconstruisez l’application sur une stack contemporaine (web, mobile, base relationnelle standard) en repartant des règles métier existantes.
Coût. 250 à 600 points d’indice, étalés. Le poste le plus sous-estimé n’est jamais le développement, c’est la récupération des règles métier. Après quinze ans d’exploitation, la spécification n’est pas dans un document. Elle est dans le code, et dans la tête de trois utilisateurs. En régime établi, le coût annuel redescend en dessous du niveau actuel, principalement parce que le vivier de développeurs s’élargit.
Délai. 6 à 18 mois selon le périmètre. En dessous de 6 mois, vous réécrivez un module, pas un parc, ce qui est souvent la bonne façon de commencer.
Risques. L’effet tunnel est le premier : dix-huit mois sans livraison intermédiaire, et le projet perd son sponsor. La perte de règles métier non documentées est le deuxième, et le plus coûteux à réparer après mise en production. Le troisième est l’adoption : un utilisateur qui saisissait 40 lignes en aveugle au clavier ne veut pas d’une interface plus jolie mais plus lente.
Ce qui réduit ces risques, et c’est vérifiable dans nos projets : découper en lots livrés en production, garder l’ancien et le nouveau en fonctionnement parallèle sur un périmètre restreint, et impliquer les utilisateurs qui connaissent les cas limites. Chez OPmobility, la solution MES a été déployée sur une usine avant d’être étendue à trois sites en deux ans. Chez Idélia Santé, le CRM sur mesure a été livré en 4 mois pour 800 apprenants multi-sites, avec 40 % de temps de traitement en moins. Chez CEVA Logistics, l’application de saisie a réduit les erreurs de 65 %, avec zéro bug critique en production, en 10 semaines.
Quand c’est le bon choix. L’application porte un processus qui vous différencie, le rythme d’évolution est soutenu, et vous avez besoin d’un accès web ou mobile que l’existant ne couvre pas. C’est aussi le seul scénario où vous récupérez la maîtrise complète de votre code.
Scénario 4. Remplacer par une solution du marché
Vous abandonnez le développement spécifique pour un progiciel ou un ERP, que vous paramétrez.
Coût. 120 à 350 points en projet (paramétrage, reprise de données, formation, fonctionnement en parallèle), puis un abonnement récurrent de 70 à 130 points par an. Attention à la ligne qui fait déraper les budgets : les développements spécifiques nécessaires pour couvrir vos écarts fonctionnels. Vous recréez alors du sur mesure, mais chez un éditeur, à son tarif et à son rythme.
Délai. 4 à 12 mois. Le paramétrage est rapide. La reprise de données depuis HFSQL, la reprise des historiques et la réconciliation comptable ne le sont pas.
Risques. L’écart fonctionnel sur les 20 % spécifiques est le risque central : ce sont précisément ces 20 % qui expliquent pourquoi une application sur mesure existait. Viennent ensuite la reprise de données (qualité, historiques, correspondances de comptes) et la dépendance à un nouvel éditeur, avec sa feuille de route et ses hausses tarifaires.
Quand c’est le bon choix. Vos processus sont standards, le spécifique relève de l’habitude plus que de la nécessité, et vous préférez un coût récurrent prévisible à un actif à maintenir. Pour une PME dont l’application WinDev fait de la gestion commerciale et de la facturation classiques, c’est souvent le scénario le plus rationnel, et la conformité réglementaire devient le problème de l’éditeur.
La question à poser en démonstration. Non pas « savez-vous faire X ? », mais « montrez-moi X sur mes données, avec mes cas limites ». La réponse départage vite.
La grille de décision : six critères
Notez chaque critère de 0 à 2. La grille n’automatise pas la décision, elle rend visible ce qui la détermine.
| Critère | 0 point | 1 point | 2 points |
|---|---|---|---|
| Dépendance humaine | 1 seule personne | 2 à 3 personnes | Équipe ou prestataire structuré |
| Différenciation métier | Processus standard | Mixte | Cœur d’avantage concurrentiel |
| Rythme d’évolution | Moins de 3 demandes par an | De 3 à 15 par an | Plus de 15 par an |
| Exposition réglementaire à 18 mois | Aucune | Indirecte | Facturation, TVA, NF525, données personnelles |
| Contrainte d’accès | Poste fixe suffisant | Souhait de mobilité | Web ou mobile indispensable |
| Documentation et testabilité | Aucune | Partielle | Sources, build et tests maîtrisés |
Comment lire votre score
- 0 à 3 points. Vous êtes en zone de risque, pas en zone de choix. Priorité absolue : sécuriser la connaissance et la chaîne de compilation. Décidez ensuite.
- 4 à 6 points, différenciation faible. Orientation solution du marché. Le sur mesure ne se justifie plus.
- 4 à 8 points, différenciation forte, faible rythme d’évolution. Orientation rester et payer, ou figer avec une date de sortie.
- 7 à 12 points, différenciation forte, fort rythme, contrainte d’accès. Orientation réécriture, par lots.
- Exposition réglementaire à 2 points. Ce critère prime. Aucun scénario ne peut ignorer une échéance légale, et figer devient impossible sur le périmètre concerné.
En pratique, on combine
Les cas purs sont rares. La configuration la plus fréquente sur un parc de trois à cinq applications WinDev :
- L’application de gestion commerciale banale part vers une solution du marché.
- L’application métier différenciante est réécrite, par lots, sur 12 mois.
- Deux petits outils périphériques sont figés proprement, avec une date de sortie à 24 mois.
Ce découpage coûte moins cher qu’un scénario unique appliqué à tout le parc, et il échelonne le risque. Il demande en revanche un vrai inventaire au départ. C’est exactement l’objet d’un audit applicatif ou d’un projet de modernisation applicative cadré.
Et le Crédit Impôt Innovation dans tout cela ?
Un point d’honnêteté budgétaire, parce qu’il est souvent présenté à l’envers.
Le CII (article 244 quater B II k du CGI) permet aux PME au sens européen de récupérer 30 % des dépenses éligibles, dans la limite de 400 000 € de dépenses par an, soit jusqu’à 120 000 € de crédit d’impôt. Euro Tech Conseil est agréée par le Ministère de l’Enseignement Supérieur et de la Recherche, ce qui permet au client de bénéficier du dispositif sur les dépenses sous-traitées.
Mais une réécriture à l’identique n’est pas un projet d’innovation. Reproduire les mêmes fonctions sur une stack plus récente ne crée pas, en soi, de produit nouveau. Ce qui peut être éligible, c’est la part du projet qui introduit une fonction ou une performance nouvelle par rapport à l’état du marché. Cette frontière se qualifie dossier par dossier, avec votre conseil fiscal, pas dans une réunion commerciale.
Autrement dit, le CII peut alléger le scénario 3, mais il ne le justifie pas. Si un prestataire vous vend une réécriture en s’appuyant d’abord sur les 30 %, demandez-lui d’écrire noir sur blanc quelle part du projet il considère comme éligible, et pourquoi.
Faut-il migrer une application WinDev vers la dernière version chaque année ?
Non. Ce qui est nécessaire, c’est de pouvoir le faire. Une organisation capable de recompiler et de tester une montée de version en quelques jours peut sauter des versions sans risque. Une organisation qui ne sait plus reconstituer son environnement de build est bloquée, quelle que soit sa version.
Combien coûte la réécriture d’une application WinDev ?
Il n’existe pas de réponse hors audit. Le facteur déterminant n’est pas le nombre de lignes, mais la part de règles métier non documentées et la qualité de la base de données. À volume égal, l’écart entre un parc propre et un parc opaque atteint couramment un facteur 3.
Peut-on garder HFSQL et moderniser seulement l’interface ?
Oui, et c’est parfois le meilleur premier lot : exposer les données via une couche de services, puis construire un accès web ou mobile au-dessus, sans toucher au cœur existant. Cela réduit le risque et livre de la valeur en quelques mois. Ce n’est pas une solution définitive, mais c’est une bonne façon de sortir du tout ou rien.
Mon application WinDev est-elle conforme à la facturation électronique 2027 ?
La question exacte est : sait-elle produire une facture au format structuré attendu et l’acheminer via une plateforme agréée. Si la réponse n’est pas documentée, considérez qu’elle ne l’est pas, et traitez le sujet avant le premier trimestre 2027. Vérifiez le calendrier applicable à votre entreprise sur impots.gouv.fr.
Que faire si notre seul développeur WinDev part dans trois mois ?
Conclusion
Un parc WinDev en 2026 ne pose pas une question technologique, il pose une question de maîtrise : savez-vous ce que vous avez, qui peut le modifier, et à quelle échéance la loi vous l’imposera. Les quatre scénarios sont tous défendables. Ce qui ne l’est pas, c’est de laisser le scénario 1 s’appliquer par défaut pendant trois ans.
Euro Tech Conseil développe des logiciels sur mesure depuis 2000 : 26 ans, 455 projets livrés, 50 experts seniors, 99 % de satisfaction clients. Nous conduisons des réécritures, et nous disons aussi à des clients que leur besoin relève d’une solution du marché, ou qu’un gel de 24 mois est le bon arbitrage. Un audit qui ne débouche sur aucun projet est un audit qui a fait son travail.
