Migration WinDev : les 10 risques qui font échouer un projet, et comment les maîtriser

Dix-neuf jours pour réécrire NomadBiz, l'application WinDev de Dev-Booster : l'éditeur, qui raconte ce chantier le 14 septembre 2026, en compte dix de tests et de corrections pour cinq de réécriture¹. Les migrations WinDev qui échouent le font rarement pour une raison technique. Elles échouent parce qu'une règle a disparu, qu'un état a été découvert en recette, ou qu'un test vert ne prouvait rien. Voici les dix risques que nous rencontrons le plus, et la parade que nous appliquons à chacun. Pour la vue d'ensemble, voir notre guide complet de la migration WinDev.

1. Le big bang

Le risque. Réécrire toute l'application, puis basculer un week-end. Le jour J concentre tous les écarts accumulés pendant des mois.

La parade. Une migration progressive selon le motif strangler fig, que Hamadi Jabloun détaille sur sfeir.dev le 20 septembre 2026² : une façade route chaque fonction vers l'ancien ou le nouveau système, module par module. Chaque module migré est débranché de l'ancien, jamais dupliqué.

2. Les règles métier oubliées

Le risque. Une remise exceptionnelle codée dans le traitement d'un champ, un seuil en dur, une exception pour un client historique. Le nouveau code compile, la règle a disparu. Dev-Booster le dit à sa manière en expliquant pourquoi ses 19 jours ne valent pas pour d'autres logiciels : « nous connaissions déjà NomadBiz, ses utilisateurs et ses règles de gestion »¹. Sans cette connaissance, le délai n'a aucun sens.

La parade. Extraire les règles avant d'écrire le code cible, avec un prompt d'archéologie exécuté deux fois dans deux sessions distinctes², et une liste explicite de zones d'ombre que le métier valide. Voir extraire les règles métier avec l'IA.

3. Les états sous-estimés

Le risque. Factures, bons de livraison, étiquettes, relevés : les états WinDev sont souvent nombreux, très calibrés, et absents de l'inventaire initial. Smartshift, qui publie sa propre méthode de migration vers .NET, qualifie ce poste de « systématiquement sous-estimé »³.

La parade. Inventorier tous les états dès l'audit, les comparer en sortie (PDF ou image) dans le golden master, et choisir l'outil de reporting tôt.

4. Les traitements par lots invisibles

Le risque. Tâches planifiées, exports comptables nocturnes, imports de tarifs fournisseurs : ils ne se voient pas dans l'IHM et personne ne les inscrit au périmètre.

La parade. Recenser les planificateurs, les services et les exécutables secondaires ; tester les lots avec les mêmes jeux d'entrée que l'ancien système.

5. Le matériel

Le risque. Douchettes, imprimantes thermiques, balances, lecteurs de cartes : le pilotage direct depuis WinDev ne se transpose pas dans un navigateur.

La parade. Traiter le matériel dès la gate Plan : il conditionne le choix entre web, desktop ciblé ou Flutter. Voir le choix de la stack cible.

6. Les tests écrits par le LLM

Le risque. Le plus difficile à voir. Si vous demandez au modèle d'écrire les tests, il écrit aussi les valeurs attendues, à partir de sa lecture du code. Il fige son interprétation ; le comportement réel de l'application, personne ne l'a observé. Exemple classique : un commentaire dit « remise à partir de 10 articles », le code teste > 10. Le LLM écrit un test qui attend une remise pour 10 articles, le test échoue sur l'existant, et quelqu'un « corrige » le code : vous venez de changer une règle de facturation. Chaque correction de ce type grossit le rework rate du projet, ce temps passé à reprendre du code produit vite.

La parade. Le golden master inversé : le LLM propose les entrées, l'application WinDev produit les sorties². Winfall applique le même principe à sa façon : chaque procédure migrée reçoit ses tests unitaires C#, « dont les valeurs attendues sont capturées sur l'application d'origine »⁴. Un score de mutation (PIT, mutmut) mesure ensuite si ces tests détectent quelque chose². Voir la méthode du golden master inversé.

7. La dérive du legacy pendant le projet

Le risque. L'application WinDev continue d'évoluer pendant la migration. La cible poursuit une référence qui bouge.

La parade. Gel fonctionnel du module en cours de migration. Les évolutions urgentes passent par un circuit explicite, et l'équipe recapture le golden master après chaque changement.

8. La conduite du changement

Le risque. Les utilisateurs connaissent leurs raccourcis, leurs écrans, leurs habitudes. Une application plus moderne peut leur sembler moins efficace.

La parade. Associer des utilisateurs clés dès l'extraction des règles, mesurer les parcours critiques (nombre de clics, temps de saisie) et former avant la bascule de chaque module.

9. Les données

Le risque. Orphelins, doublons, dates vides, montants en flottant : un import peut avoir le bon nombre de lignes et de mauvaises données.

La parade. Migrations à blanc répétées et rapports de conformité qui recalculent les totaux métier des deux côtés. Voir HFSQL vers PostgreSQL.

10. La dépendance à une personne clé

Le risque. Un seul développeur connaît l'application. Le projet ne tient que par lui, et il peut partir en cours de route. Platane, acteur du marché de la migration, écrivait le 5 août 2026 que « les développeurs WLangage se raréfient »⁵ : le remplacer sera plus long qu'avant.

La parade. Faire de la rétro-documentation le premier livrable : elle transfère la connaissance de la personne vers un référentiel. Le sachant relit et arbitre, au lieu de porter seul le projet.

Un risque transverse : la qualité des modèles sur le WLangage

Les modèles de langage perdent en fiabilité sur les langages rares, faute de données d'entraînement : Hamadi Jabloun le constate sur sfeir.dev pour COBOL, RPG, ABAP ou PL/I², et nous classons le WLangage dans le même cas. Toute sortie du modèle sur le code source doit donc être recoupée (double exécution) et relue par quelqu'un qui connaît WinDev.

Questions fréquentes

Quel est le risque le plus sous-estimé ?

Les tests écrits par le LLM. Ils donnent une impression de sécurité alors qu'ils figent une interprétation du code.

Peut-on éviter totalement la cohabitation ?

Pour une très petite application, oui. Dès qu'il y a plusieurs modules et plusieurs utilisateurs, la cohabitation est ce qui rend la migration réversible.

Combien de temps garder l'application WinDev après la bascule ?

Jusqu'à ce que tous les modules aient basculé et que le shadow traffic, le trafic réel rejoué en parallèle sur l'ancienne et la nouvelle application², n'ait plus révélé de divergence sur une période représentative, y compris une clôture mensuelle.

Passer à l'action

Nos garde-fous sont intégrés à chaque étape de notre méthode, avec trois gates humains issus de notre SDLC piloté par l'IA. Pour la vue d'ensemble, revenez à notre guide pour réécrire une application WinDev avec l'IA.

Sources

1. Dev-Booster, Comment Windev nous a fait économiser 33490 euros ! — dev-booster.com, 14 septembre 2026.
2. Hamadi Jabloun, Du Legacy à l'état de l'art : moderniser avec l'IA sans rejouer le Big Bang — sfeir.dev, 20 septembre 2026.
3. Smartshift, WinDev vers .NET / C# : la migration la plus directe — smartshift.fr, page mise à jour le 24 juillet 2026.
4. Winfall, Migration WinDev vers C# / .NET — winfall.fr.
5. Platane, Redevance WinDev : ce que le nouveau PC SOFT change pour votre logiciel métier — platane.io, 5 août 2026.