En bref. Migrer une application WinDev à l'identique semble la voie la plus sûre. C'est souvent la plus chère. Après quinze ans d'évolutions, une application cache des écrans que plus personne n'ouvre, des règles métier jamais documentées, des données HFSQL hétérogènes et des échanges oubliés avec d'autres logiciels. Les repérer avant de chiffrer change le budget, le planning et le résultat.
« On veut juste la même chose, mais en web. » C'est la phrase que nous entendons le plus souvent lors d'un premier rendez-vous avec un dirigeant qui s'interroge sur son logiciel WinDev. Elle paraît raisonnable. Pourtant, une migration WinDev à l'identique est rarement la bonne façon d'aborder le projet.
Depuis plus de 26 ans, nous développons des applications métier, dont beaucoup en WinDev. Nous avons aussi accompagné plusieurs entreprises vers le web, de la reprise d'un logiciel d'agence de voyage WinDev 24 et HFSQL jusqu'à la refonte d'un CRM complet dans le regroupement de crédit. Ces projets nous ont appris une chose. Ce qui coûte cher dans une migration, ce n'est pas le code que l'on réécrit, c'est tout ce que l'on n'avait pas vu avant de commencer.
- Pourquoi une migration WinDev à l'identique coûte-t-elle plus cher que prévu ?
- Faut-il vraiment reprendre tous les écrans de l'application ?
- Où se cachent les règles métier d'une application WinDev ?
- Que deviennent les données HFSQL pendant la migration ?
- Quels échanges avec d'autres logiciels faut-il recenser ?
- Rester, moderniser ou migrer, comment choisir ?
- Que peut apporter l'IA dans une refonte WinDev ?
- Par où commencer avant de demander un devis ?
- Questions fréquentes
Pourquoi une migration WinDev à l'identique coûte-t-elle plus cher que prévu ?
Parce qu'elle reproduit tout, y compris ce qui ne sert plus, et qu'elle part du principe que l'on connaît déjà l'application. Or une application qui tourne depuis dix ou quinze ans a toujours des zones d'ombre. Le tableau ci-dessous résume l'écart que nous constatons presque à chaque audit.
| Ce que l'on pense migrer | Ce que l'audit fait apparaître | Effet sur le projet |
|---|---|---|
| Toutes les fenêtres de l'application | Une part importante n'est plus utilisée | Du budget dépensé pour des fonctions oubliées |
| Des écrans et des formulaires | Des règles métier enfouies dans le code | Des écarts de calcul découverts en recette |
| Une base HFSQL « propre » | Des doublons, des dates en texte, des champs détournés | Une reprise de données à traiter comme un chantier à part |
| Une application autonome | Des exports, des fichiers et des macros qui en dépendent | Des pannes au lendemain de la bascule |
Faut-il vraiment reprendre tous les écrans de l'application ?
Non. Après dix ou quinze ans, une application accumule des fenêtres créées pour un client parti, un état demandé une seule fois, un module remplacé depuis longtemps par un tableur. Personne ne les supprime, parce que personne n'est sûr qu'ils soient inutiles.
Pendant l'audit, nous croisons le code avec l'usage réel. La question n'est pas de compter les écrans. Il s'agit de savoir lesquels sont ouverts chaque semaine, et par qui. Ce tri pèse plus sur le budget que le choix entre Symfony, .NET ou Angular. Migrer à l'identique revient à payer une deuxième fois des fonctions que l'entreprise avait déjà oubliées.
Où se cachent les règles métier d'une application WinDev ?
Dans le code, et presque nulle part ailleurs. Le plafond de remise accordé à un commercial, l'arrondi particulier d'une facture d'acompte, le contrôle qui bloque une commande quand le client a un impayé. Ces règles vivent dans un événement de champ, une procédure globale, parfois un trigger HFSQL.
Le développeur qui les a écrites est peut-être parti. L'utilisateur qui en dépend ne sait pas qu'elles existent. Pour lui, « le logiciel fait comme ça ».
C'est la partie la plus délicate d'une refonte, et la plus sous-estimée. Avant d'écrire une ligne de code, nous reconstituons ces règles avec les utilisateurs clés, puis nous les transformons en scénarios de test. Un nouveau logiciel n'est pas validé quand il ressemble à l'ancien. Il l'est quand il calcule exactement la même chose. C'est tout l'objet d'un audit de l'application avant de changer de technologie.
Que deviennent les données HFSQL pendant la migration ?
Elles se reprennent, mais rarement telles quelles. Dans les fichiers HFSQL, on trouve des dates saisies en texte, des codes clients en double, des champs détournés de leur usage. Un champ « Remarque 2 » contient parfois un numéro de contrat depuis des années. Rien d'anormal, c'est la vie d'une base sur quinze ans.
La reprise des données mérite donc son propre chantier, avec ses contrôles. Pour nous, cela signifie au minimum une reprise à blanc, une comparaison des totaux entre l'ancien et le nouveau système (chiffre d'affaires, encours, stocks) et une validation par le métier avant la bascule. Notre guide HFSQL vers PostgreSQL détaille cette étape. Un code se réécrit. Un historique client faux se rattrape beaucoup plus difficilement.
Quels échanges avec d'autres logiciels faut-il recenser ?
Tous, y compris ceux que personne n'a documentés. Un export comptable récupéré chaque mois par le cabinet. Un fichier déposé sur un FTP pour un transporteur. Une macro Excel qui interroge directement la base. Ces flux n'apparaissent dans aucun cahier des charges, jusqu'au jour où ils s'arrêtent.
Nous les inventorions dès le départ, avec pour chacun sa fréquence, son format et la personne qui en dépend. Cela évite la pire des découvertes, celle qui arrive le lendemain de la mise en production.
Rester, moderniser ou migrer, comment choisir ?
En partant de chiffres et d'objectifs, pas de la pression d'une facture. L'évolution des conditions de licence chez PC SOFT pousse beaucoup d'entreprises à décider dans l'urgence. Pour mesurer votre exposition, consultez notre article sur le prix d'une licence WinDev en 2026. Trois trajectoires existent ensuite, et aucune n'est la bonne par principe.
- Rester sur WinDev et fiabiliser l'existant, si l'application est saine et le coût de licence soutenable.
- Moderniser par étapes, en sortant d'abord les données vers PostgreSQL, en ouvrant des API, puis en migrant module par module. C'est la méthode progressive.
- Migrer vers une architecture web complète, quand l'application doit être utilisée à distance, par des clients ou des partenaires, ou quand la dépendance à un seul environnement devient un risque.
Le bon choix repose sur le coût annuel de l'existant, celui de la refonte, la maintenance à cinq ans et surtout ce que l'entreprise veut pouvoir faire demain avec son outil.
Que peut apporter l'IA dans une refonte WinDev ?
Un gain de temps réel, à condition de l'encadrer. L'IA aide nos équipes à lire et cartographier du WLangage, à repérer les dépendances, à produire une première version du code et des tests. Nos développeurs reprennent ensuite chaque livrable et le valident.
Elle ne remplace ni la compréhension des règles métier, ni le contrôle des données. Elle réécrit très vite le code qu'on lui donne. Elle ne sait pas qu'un champ « Remarque 2 » contient un numéro de contrat.
C'est sur ce principe que repose notre programme de refonte et migration WinDev. Il propose jusqu'à 40 % sur la refonte grâce au développement augmenté par l'IA, toujours après un audit de l'application.
Programme réservé aux refontes d'applications WinDev, WebDev et WinDev Mobile. Économie estimée par rapport à la méthodologie traditionnelle d'Euro Tech Conseil, à périmètre fonctionnel comparable. Le gain dépend de la qualité du code, de la documentation, de la couverture de tests, de la technologie d'origine et de la complexité fonctionnelle. Évaluation après audit technique.
Par où commencer avant de demander un devis ?
Par cinq questions à se poser en interne. Elles demandent peu de temps et font gagner beaucoup d'échanges ensuite.
- Quels écrans sont réellement utilisés chaque semaine ?
- Qui connaît les règles de calcul critiques (prix, remises, TVA, stocks) ?
- Combien coûte l'existant chaque année, licences et maintenance comprises ?
- Quels logiciels, fichiers ou partenaires dépendent de l'application ?
- Que devrait faire votre outil dans trois ans qu'il ne fait pas aujourd'hui ?
Si les réponses sont claires, la moitié du cadrage est déjà faite. Si elles restent floues, c'est exactement ce qu'un audit d'application WinDev doit éclaircir.
Questions fréquentes
Peut-on migrer une application WinDev à l'identique ?
Techniquement oui, mais c'est rarement le meilleur choix. Une reprise à l'identique reproduit aussi les écrans inutilisés et les défauts de l'existant. Un tri préalable réduit le périmètre et le budget.
Comment retrouver les règles métier qui ne sont pas documentées ?
En analysant le code WLangage et en interrogeant les utilisateurs clés. Chaque règle retrouvée devient un scénario de test, qui sert ensuite à valider le nouveau logiciel.
Les données HFSQL peuvent-elles être reprises sans perte ?
Oui, avec une reprise à blanc, des contrôles de cohérence et une comparaison des totaux entre l'ancien et le nouveau système. La validation par le métier intervient avant la bascule définitive.
L'IA peut-elle migrer seule une application WinDev ?
Non. Elle accélère la lecture du code et la production d'une première version, mais un développeur doit valider chaque livrable. Les règles métier et la reprise des données demandent toujours une analyse humaine.
Par quoi commence une migration WinDev ?
Par un audit de l'existant. Il mesure l'usage réel des écrans, recense les règles métier, les données et les échanges, puis propose une trajectoire chiffrée.
Vous réfléchissez à l'avenir de votre application WinDev, WebDev ou WinDev Mobile ? Nous réalisons un audit de l'existant, avec un premier retour sous 48 h. Vous pouvez aussi nous appeler au 01 42 01 11 12.
