Migrer WinDev avec la Software Factory 10x : la méthode SFEIR en six étapes, de l'audit à la bascule
Depuis le printemps 2025, nos ingénieurs mènent leurs chantiers avec Claude Code ; depuis début 2026, chaque Sfeirian. Une migration WinDev suit chez nous le même cycle de production. Donner du WLangage à un agent occupe une petite partie du travail ; le reste tient dans le cycle qui l'entoure : six étapes, un livrable vérifiable au bout de chacune, trois décisions tenues par des humains, l'exécution confiée aux agents. Voici ce cycle, étape par étape. Pour le contexte général, commencez par notre guide complet de la migration WinDev.
Le cadre : un SDLC conçu pour des agents
Cette pratique quotidienne a structuré notre SDLC piloté par l'IA en onze phases : 0 Setup, 1 Define, 2 Plan, 3 Build, 4 Verify, 5 Review, 6 Compound-1, 7 Ship, 8 Ops, 9 Compound-2, 10 Deprecation. Des humains tiennent trois gates : Define, Plan et Ship. Les agents prennent en charge le reste, sous contrôle.
La Software Factory 10x répartit l'effort humain à environ 80 % sur la planification et la revue, 20 % sur l'exécution. Sur une migration WinDev, ce ratio se justifie plus qu'ailleurs : le code s'écrit vite, et le risque est d'écrire le mauvais.
Étape 1 : l'audit du patrimoine (phases Setup et Define)
Ce que font les agents. Ils parcourent l'export texte des projets, le script SQL généré depuis l'analyse et les ressources du projet, puis dressent l'inventaire : fenêtres, procédures globales et locales, états, requêtes, traitements par lots, composants externes, dépendances matérielles. Ils croisent cet inventaire avec les journaux d'usage quand ils existent et classent chaque élément : actif, suspect, probablement mort. Sur un monolithe mature, 20 à 40 % du code est mort, selon Hamadi Jabloun sur sfeir.dev1.
Ce que font les humains. Le tech lead et le référent métier valident le périmètre et tranchent les éléments suspects.
Livrable. inventaire.md et une carte des modules, avec la volumétrie et une première estimation du code mort.
Étape 2 : l'extraction des règles métier (Define)
Les agents appliquent un prompt d'archéologie, dans l'esprit de celui que Hamadi Jabloun décrit sur sfeir.dev1 : il interdit toute amélioration et exige cinq sections, règles de gestion, scénarios Gherkin, valeurs en dur, incohérences, zones d'ombre. Le même prompt tourne deux fois, dans deux sessions distinctes ; les règles qui n'apparaissent qu'une fois passent en relecture humaine.
Livrable. Un fichier .feature par module et une liste de questions ouvertes. La gate Define se franchit quand le métier a répondu aux questions bloquantes. Le détail est dans notre méthode d'extraction des règles métier.
Étape 3 : les spécifications (Plan)
Pour chaque module, un spec.md décrit le comportement attendu à partir des règles validées : du spec-driven development appliqué à un existant. Un plan.md fixe l'architecture cible, le découpage en lots, l'ordre de passage et les points de cohabitation avec l'application en place. Nous explorons souvent plusieurs options d'architecture avant d'en retenir une.
Gate Plan. Rien ne se construit tant que l'architecte et le tech lead n'ont pas validé le plan. La stack se décide ici (voir notre comparatif des stacks cibles).
Étape 4 : la réécriture par agents (Build, Verify, Review)
Les agents Claude Code reçoivent la spécification, le plan et le jeu de référence du module. Ils écrivent le code cible, exécutent les tests et réinjectent les échecs dans leur boucle de travail. Quatre revues parallèles couvrent le code, la sécurité, les tests et la performance.
Deux règles ne se négocient pas :
- aucune nouvelle fonctionnalité pendant la migration d'un module, sinon on perd le référentiel de comparaison ;
- tout écart où le nouveau code semble plus juste que l'ancien remonte au métier, parce que la décision appartient au produit.
Cette répartition entre réflexion et exécution se retrouve ailleurs : un playbook public et anonyme, publié sur GitHub le 9 juin 2026 sous licence MIT, décrit une migration WinDev et HFSQL vers .NET pilotée par Claude Cowork pour l'analyse et Claude Code pour l'exécution2.
Livrable. Le code du module, la liste du code mort supprimé, la liste des écarts à arbitrer.
Étape 5 : les tests de non-régression (Verify)
Nous refusons les tests dont le LLM a écrit les valeurs attendues. Le principe est posé sur sfeir.dev : « le LLM génère les ENTRÉES. Le code legacy, lui seul, génère les SORTIES »1. Le LLM propose donc les entrées ; l'application WinDev, exécutée, produit les sorties. Nous figeons ces sorties dans un golden master, puis nous comparons : écritures en base, états, exports.
Livrable. golden_master.json par module, rapport de comparaison, score de mutation de la suite. Détail : la méthode du golden master inversé.
Étape 6 : la bascule des données et du module (Ship)
Le chantier données démarre en général en amont : nous branchons l'application WinDev sur PostgreSQL par les accès natifs avant la réécriture, et cette étape est la bascule finale de chaque module. Les données HFSQL passent vers PostgreSQL par migrations à blanc successives, chacune accompagnée d'un rapport de conformité. Le module migré tourne en shadow run à côté de l'ancien jusqu'à un taux de divergence nul, puis bascule derrière un feature flag.
Gate Ship. L'humain valide sur preuve d'exécution, jamais sur la déclaration de l'agent. Livrables : scripts de bascule, rapport de conformité, procédure de retour arrière. Voir HFSQL vers PostgreSQL.
Les phases que l'on oublie : capitaliser et décommissionner
Les phases Compound-1 et Compound-2 transforment chaque correction en règle versionnée que le cycle suivant recharge, le mécanisme du compound engineering. Sur une migration, le module 5 profite des erreurs commises sur les modules 1 à 4. La phase Deprecation planifie l'extinction de l'application WinDev, des licences et des postes.
Les rôles humains
| Rôle | Responsabilité principale |
|---|---|
| Référent métier | Valide les règles, tranche les zones d'ombre et les écarts |
| Tech lead | Tient le Setup, la capitalisation et la qualité des livrables |
| Architecte | Valide le plan et la stack à la gate Plan |
| Binôme de développement | Pilote les agents, relit et corrige |
| QA | Construit le golden master et pilote le shadow run |
| Ops/SRE | Prépare la bascule et l'exploitation |
Ce que nous mesurons
Nous comptons en livrables, jamais en jours-homme : règles extraites et validées, modules spécifiés, modules basculés. Deux indicateurs de qualité guident le pilotage : le Rework Rate (part du travail refait) et le nombre d'itérations de correction par module. Sur nos propres cycles, nous observons environ 30 % d'itérations de correction en moins après dix cycles, effet direct des phases Compound (mesure publiée dans notre article sur le SDLC à onze phases).
Questions fréquentes
Faut-il donner tout le code WinDev à Claude Code d'un coup ?
Non. Nous travaillons module par module, avec le contexte utile (analyse, procédures partagées, constantes) : du context engineering appliqué au legacy. Un contexte trop large dilue la précision.
Nos développeurs WinDev ont-ils un rôle ?
Un rôle central : ils connaissent les règles et les pièges. Ils deviennent relecteurs et arbitres. SFEIR Institute forme 6 000 professionnels par an et a formé et certifié les 50 développeurs de l'éditeur Asys à Claude Code en moins de deux mois.
Le code produit nous appartient-il ?
Oui, en totalité, dans une stack ouverte, sans redevance d'exécution.
Peut-on démarrer par une seule étape ?
Oui. L'audit et l'extraction des règles ont une valeur propre, même sans migration.
Passer à l'action
Le point d'entrée est le Diagnostic 10x : trente minutes d'échange et un rapport en dix points. L'audit de votre patrimoine WinDev vient ensuite, première étape de la méthode. Pour le budget, voir le coût d'une migration WinDev ; pour la vue d'ensemble, revenez au guide pour réécrire une application WinDev avec l'IA. Notre offre Software Factory et notre pratique Claude Code détaillent le dispositif ; SFEIR est partenaire Preferred du Claude Partner Network (communiqué du 5 octobre 2026).
Sources
- Hamadi Jabloun, Du Legacy à l'état de l'art : moderniser avec l'IA sans rejouer le Big Bang — sfeir.dev, 20 septembre 2026.
- Playbook windev-vers-dotnet (organisation anonyme, licence MIT) — github.com, 9 juin 2026.
Poser votre patrimoine WinDev sur le cycle à onze phases, module par module
Échanger avec SFEIRArticles similaires
Migration WinDev : réécrire vos applications PC SOFT avec l'IA, sans big bang
Une migration WinDev se joue sur deux chantiers : retrouver les règles métier enfouies dans vingt ans de fenêtres, puis prouver que la nouvelle application fait la même chose que l'ancienne. Méthode SFEIR en six étapes, stack cible, ordres de grandeur et grille rester, geler ou migrer.
Extraire les règles métier d'une application WinDev avec l'IA : la rétro-documentation spec first
Les règles de gestion d'une application WinDev vivent dans son WLangage et nulle part ailleurs. Comment les extraire avec l'IA : export en mode texte, prompt d'archéologie à cinq sections, double exécution, Gherkin, ADR rétroactifs et validation métier.
Tests de non-régression d'une migration WinDev : la méthode du golden master inversé
Une application migrée qui tourne ne prouve rien. Il faut montrer qu'elle produit les mêmes écritures, états et exports que l'application WinDev, bugs compris. Notre méthode : le LLM propose les entrées, WinDev seul produit les sorties, et le nouveau code est jugé contre ce golden master.
HFSQL vers PostgreSQL : migrer les données d'une application WinDev sans perte
Migrer une base HFSQL vers PostgreSQL sans perte : transposer le schéma, déclarer les clés que le code gardait implicites, nettoyer avant de migrer, répéter les migrations à blanc jusqu'à deux rapports de conformité sans écart, faire tourner WinDev sur PostgreSQL, puis basculer.