migration-windev modernisation-legacy software-factory claude-code spec-driven agentic-coding sdlc

Extraire les règles métier d'une application WinDev avec l'IA : la rétro-documentation spec first

15 octobre 2026

Une application WinDev de dix ans porte des règles de tarification, de contrôle et de calcul que personne n'a écrites ailleurs que dans son WLangage, souvent par un développeur parti depuis. Les retrouver est le premier chantier d'une migration, et souvent le seul qui compte. L'IA le rend abordable, à condition de lui demander une spécification plutôt qu'une paraphrase. Ce chantier fait partie de notre guide de la migration WinDev.

Le principe : spécifier l'ancien avant d'écrire le nouveau

Le 20 septembre 2026, Hamadi Jabloun publiait sur sfeir.dev la doctrine que nous appliquons à chaque patrimoine legacy : « L'IA ne doit pas commencer par écrire le nouveau code. Elle doit commencer par écrire la spécification de l'ancien. »¹ Le risque majeur d'une refonte est fonctionnel : perdre la règle codée en dur par quelqu'un qui est parti depuis. La démarche prolonge le spec-driven development sur un dépôt existant, tel que nous l'avons décrit avec OpenSpec en brownfield : la spécification précède le code, et sur un existant elle commence par décrire ce qui tourne.

Dev-Booster, dans son billet du 14 septembre 2026 sur la réécriture de NomadBiz en .NET, précise que son équipe connaissait déjà l'application, ses utilisateurs et ses règles de gestion². La rétro-documentation reconstitue ce savoir quand il a quitté les têtes.

Étape 1 : rendre le code lisible

Les projets WinDev sont stockés en formats binaires. Depuis la version 25, l'enregistrement en mode texte, réservé aux projets hors GDS, écrit dans des fichiers texte le code des éléments et les caractéristiques principales des fenêtres et des champs ; les propriétés plus avancées restent au format binaire, selon la documentation de PC SOFT³. PC SOFT l'a conçu pour versionner le projet dans Git. Un modèle le lit sans difficulté, complété par :

le script SQL généré depuis l'analyse (structure des fichiers HFSQL) ;
les procédures globales, classes et collections de procédures ;
les constantes, paramètres et fichiers de configuration ;
en version 2026, le document « vue d'ensemble » que la commande /init_project du compagnon IA génère dans le fichier companion.md, d'après la documentation des nouveautés de WinDev 2026 (version d'avril 2026)⁴ : un premier élément de contexte pour vos propres agents.

Étape 2 : le prompt d'archéologie

Demander « que fait ce code ? » donne une paraphrase. Nous demandons des livrables structurés, avec une interdiction explicite de proposer la moindre amélioration. Le prompt exige, dans l'ordre :

les règles de gestion, une par ligne, en langage métier, avec la ligne de code d'origine ;
les critères d'acceptation en Gherkin, un scénario par branche d'exécution, y compris les branches d'erreur, avec les valeurs de frontière nommées ;
les valeurs en dur porteuses de sens métier (seuils, taux, codes, dates pivots) et l'hypothèse qu'elles encodent ;
les incohérences entre ce que le code fait et ce que ses noms ou commentaires annoncent, sans trancher ;
les zones d'ombre : ce que le modèle ne peut pas déterminer, et ce qu'il lui faudrait pour trancher.

Deux contraintes complètent le prompt¹ : toute supposition porte la mention « HYPOTHÈSE : », et une section sans contenu s'écrit « NÉANT » au lieu d'être remplie. Les sections 4 et 5 rentabilisent l'exercice : vos vraies règles s'y cachent.

Un exemple de sortie Gherkin, sur une règle de remise :

Scénario: Remise volume au-delà de 10 articles
  Étant donné une commande de 11 articles à 20 €
  Quand la commande est validée
  Alors le total est de 198 €

Scénario: Pas de remise à exactement 10 articles
  Étant donné une commande de 10 articles à 20 €
  Quand la commande est validée
  Alors le total est de 200 €
  # INCOHÉRENCE : le commentaire annonce « à partir de 10 »

Étape 3 : la double exécution, un détecteur d'hallucination

Nous faisons tourner le même prompt deux fois, dans deux sessions distinctes¹. Les règles présentes dans les deux sorties sont fiables. Celles qui n'apparaissent qu'une fois partent en relecture humaine. Hamadi Jabloun rappelle que la qualité des modèles chute sur les langages peu représentés dans leurs données d'entraînement, et cite COBOL, RPG, ABAP ou PL/I¹. Le WLangage, encore moins répandu dans le code public, relève à notre avis du même cas : sur un projet WinDev, nous ne sautons jamais la double exécution.

Étape 4 : les ADR rétroactifs

Pour chaque structure surprenante (une table dupliquée, un traitement contourné, un fichier temporaire qui persiste), nous demandons au modèle quelle décision d'architecture explique cette structure. Ces ADR rétroactifs (Architecture Decision Records) documentent les contournements et évitent de reproduire un choix dont la raison a disparu¹.

Étape 5 : valider les zones d'ombre avec le métier

Certaines questions ne se tranchent ni par lecture ni par déduction. Dans l'exemple de la remise, personne ne sait si le seuil réel est 10 ou 11 articles : le commentaire ment peut-être, ou tout le canal commercial s'est aligné depuis des années sur le comportement du programme. Nous exécutons l'application pour observer, puis nous allons voir le métier avec la question écrite. Les réponses rejoignent le référentiel et deviennent des décisions tracées.

La chaîne de rétro-documentation : l'export WinDev alimente un prompt d'archéologie à cinq sections, exécuté deux fois ; seules les règles communes aux deux sorties sont tenues pour fiables, le reste passe en relecture humaine, les zones d'ombre vont au métier, et le tout rejoint un référentiel versionné.

Supprimer avant de documenter

Sur un monolithe mature, 20 à 40 % du code est mort¹. Avant la rétro-documentation, nous croisons l'analyse statique des appels avec les usages réels et classons chaque élément en actif, suspect ou probablement mort. Chaque fenêtre supprimée en amont sort du périmètre de documentation, de test et de réécriture.

Le livrable, et sa valeur même sans migration

Le résultat est un référentiel versionné : règles de gestion, fichiers .feature, valeurs en dur, ADR, décisions métier. Il garde sa valeur si vous décidez de rester sur WinDev :

il réduit la dépendance à une personne clé ;
il accélère l'intégration d'un nouveau développeur ;
il éclaire une négociation avec l'éditeur, parce que vous savez ce que coûterait la sortie ;
il devient la spécification de la future application le jour où vous migrez.

Les scénarios Gherkin servent ensuite d'entrée aux tests de non-régression par golden master inversé.

Questions fréquentes

Faut-il des développeurs WinDev pour relire ?

Oui, au moins un sachant. Le modèle accélère la lecture ; le sachant garantit l'exactitude et tranche ce qui n'est sorti que d'une session.

Le code doit-il quitter notre SI ?

Pas nécessairement. Le code contient vos règles de tarification et parfois des données ; l'environnement d'exécution des agents se choisit en conséquence.

Combien de temps prend la rétro-documentation ?

Elle dépend du nombre de modules et de la disponibilité du métier pour les zones d'ombre, qui est dans la plupart des cas le facteur limitant.

Peut-on documenter sans le mode texte ?

Difficilement. L'export texte, même partiel, est la matière première ; il suppose un projet hors GDS.

Passer à l'action

La rétro-documentation est l'étape 2 de notre méthode en six étapes, menée avec des agents Claude Code. Pour revenir au guide complet, voir la migration WinDev.

Sources

Hamadi Jabloun, Du Legacy à l'état de l'art : moderniser avec l'IA sans rejouer le Big Bang — sfeir.dev, 20 septembre 2026.
Dev-Booster, Comment Windev nous a fait économiser 33490 euros ! — dev-booster.com, 14 septembre 2026.
PC SOFT, documentation WINDEV, Mode texte : enregistrement des éléments du projet au format texte — doc.windev.com.
PC SOFT, Nouveautés WINDEV 2026 — doc.pcsoft.fr, version d'avril 2026.