Tests de non-régression d'une migration WinDev : la méthode du golden master inversé

Une application migrée qui s'ouvre, affiche ses écrans et enregistre une commande ne prouve rien. La preuve attendue est ailleurs : la nouvelle application produit les mêmes écritures, les mêmes documents et les mêmes exports que l'application WinDev, bugs compris, sauf décision explicite du métier. Voici la méthode que nous appliquons, et l'erreur que presque tous les pipelines d'IA commettent. Elle s'inscrit dans notre guide complet de la migration WinDev.

Le piège : laisser le LLM écrire les valeurs attendues

Une application WinDev ancienne n'a généralement pas de tests. On génère donc des tests de caractérisation : leur but est de figer le comportement actuel du code, qu'il soit juste ou faux.

Le réflexe consiste à demander au modèle d'écrire ces tests. Il écrit alors aussi les valeurs attendues, à partir de sa lecture du code et des commentaires, jamais de son exécution. Il fige son interprétation. Quand le test échoue sur l'existant, la tentation est de corriger le code pour faire passer le test : vous modifiez une règle en production avant d'avoir migré la première fenêtre.

Notre règle ne souffre aucune exception : aucun test dont le LLM a écrit les valeurs attendues. Hamadi Jabloun l'a formulée le 20 septembre 2026 sur sfeir.dev : « le LLM génère les ENTRÉES. Le code legacy, lui seul, génère les SORTIES »¹.

L'inversion : le LLM propose les entrées, WinDev produit les sorties

Le modèle repère bien les frontières à tester : zéro, valeurs négatives, champs vides, seuils, dates de fin de mois, débordements. Il est disqualifié pour dire ce qui doit en sortir. Cette autorité appartient à l'application qui tourne en production.

Le circuit se déroule en quatre temps :

1. le LLM propose des jeux d'entrées qui maximisent la couverture des branches, à partir du code et des scénarios Gherkin issus de l'extraction des règles métier ;
2. ces entrées sont rejouées sur l'application WinDev, dans un environnement de test ;
3. les sorties observées, y compris les erreurs, sont enregistrées : c'est le golden master ;
4. la nouvelle application est jugée contre ce golden master, et contre lui seul.

Ce que l'on compare dans une application WinDev

Une fonction WinDev renvoie rarement une simple valeur. Ses effets sont ailleurs : dans les tables, dans les états imprimés, dans les fichiers exportés.

Les écritures en base. Après chaque scénario, on capture l'état des tables concernées : lignes créées, modifiées, supprimées, valeurs calculées. L'étape transitoire où l'application WinDev tourne sur PostgreSQL facilite la comparaison, puisque les deux applications écrivent dans le même moteur (voir HFSQL vers PostgreSQL).

Les états. Factures, bons, étiquettes : on compare les documents produits, par extraction du texte et des montants ou par comparaison visuelle avec une tolérance définie. Un état peut s'ouvrir sans erreur et produire un document différent.

Les exports. Fichiers comptables, EDI, CSV : comparaison octet par octet, après normalisation des éléments variables (horodatages, identifiants techniques).

Rendre le golden master reproductible

Un golden master qui change à chaque exécution ne vaut rien. Il faut neutraliser les sources d'indéterminisme : date et heure courantes, numéros aléatoires, compteurs, appels réseau. On introduit des points de contrôle (horloge paramétrable, numérotation injectée) et on interdit tout autre changement dans la même modification : le commit qui rend l'application testable ne touche à aucune règle.

Mesurer le filet, pas le décor

Un taux de couverture élevé ne dit rien de la qualité des assertions. La mesure qui compte est le score de mutation : on injecte volontairement des erreurs dans le code cible et on vérifie que la suite les détecte, avec des outils comme PIT ou mutmut¹. C'est le seul indicateur qui mesure un filet, et c'est ce filet qui conditionne l'effet multiplicateur décrit par DORA.

Aspirer de la vraie donnée

Le meilleur golden master reste le trafic réel : enregistrer, sur une période représentative, les couples entrée et sortie de production. Aucun modèle n'inventera vos cas tordus mieux que vos utilisateurs. Prévoyez au moins une clôture de mois dans la période.

Shadow run et cohabitation

Avant de basculer un module, nous faisons tourner les deux implémentations en parallèle sur le flux réel, ce que l'article de sfeir.dev appelle le shadow traffic¹. Seule la réponse de l'application WinDev fait foi ; les divergences sont journalisées et analysées une par une. Chaque divergence est soit un défaut du nouveau code, soit un bug de l'ancien que le métier décide de corriger. Dans ce second cas, la correction est une décision produit, tracée et portée par le métier.

Quand le taux de divergence tombe à zéro sur une période représentative, la bascule derrière un feature flag devient un non-événement. Pendant toute la cohabitation, l'ancien module reste disponible pour un retour arrière : c'est le motif Strangler Fig, module par module, que décrit le même article¹.

Les écarts à arbitrer

Le modèle qui écrit le code cible reçoit une consigne explicite : si un cas du golden master lui paraît erroné, il ne le corrige pas, il le signale dans une liste d'écarts à arbitrer. Sans cette consigne, il améliore le comportement en silence et la comparaison perd son sens.

D'autres acteurs du marché appliquent le même principe. Winfall, par exemple, écrit que « chaque procédure migrée reçoit ses tests unitaires C#, dont les valeurs attendues sont capturées sur l'application d'origine »².

Questions fréquentes

Faut-il une copie de la production pour le golden master ?

Une copie anonymisée et représentative est idéale. Les données de production non anonymisées ne doivent pas circuler hors de l'environnement prévu.

Que faire d'un bug historique découvert ?

Le documenter, le faire arbitrer par le métier, et ne le corriger qu'après la bascule du module, pour garder le référentiel de comparaison intact.

Le shadow run est-il possible sur une application desktop ?

Oui, au niveau des traitements et des écritures : on rejoue les mêmes opérations sur les deux implémentations et on compare les effets.

Combien de cas faut-il dans un golden master ?

Assez pour obtenir un score de mutation satisfaisant sur le module. Le volume compte moins que la couverture des frontières.

Passer à l'action

Le golden master est l'étape 5 de notre méthode en six étapes ; il répond au risque n° 6 de notre liste des risques. Pour la vue d'ensemble, lisez notre guide pour réécrire une application WinDev avec l'IA.

Sources

1. Hamadi Jabloun, Du Legacy à l'état de l'art : moderniser avec l'IA sans rejouer le Big Bang — sfeir.dev, 20 septembre 2026.
2. Winfall, Migration WinDev vers C# / .NET — winfall.fr.