Golden master

Figer le comportement observé, bugs compris

Un golden master est l'enregistrement des sorties réelles d'un logiciel existant pour un jeu d'entrées donné : ce que produit le programme qui tourne, y compris ses bugs, et non ce que sa documentation annonce. Toute réécriture est ensuite jugée contre cet enregistrement. Michael Feathers a nommé cette pratique « tests de caractérisation » dans Working Effectively with Legacy Code (Pearson, 2004) : un test de caractérisation décrit ce que le code fait, pour mettre sous contrôle un code legacy qu'il définit comme du code dépourvu de tests.

En 2014, J. B. Rainsberger appelle « golden master » la copie de la dernière sortie jugée acceptable, conservée et comparée à chaque exécution. L'approval testing outille le même principe : la bibliothèque ApprovalTests, dont Llewellyn Falco est le créateur, prend un instantané du résultat et vérifie qu'il n'a pas changé. Le kata Gilded Rose d'Emily Bache fournit des approval tests prêts à l'emploi dans une quarantaine de langages pour s'entraîner à refactoriser un code sans tests.

Le piège à l'ère des LLM

Demander à un modèle d'écrire les tests d'un code legacy produit des tests dont il écrit aussi les valeurs attendues, à partir de sa lecture du code et des commentaires, jamais de son exécution. Le test fige une interprétation. Quand il échoue sur l'existant, l'équipe corrige le code pour faire passer le test, et modifie une règle en production avant d'avoir migré la première ligne. Hamadi Jabloun décrit ce sabotage dans son article du 20 septembre 2026 sur sfeir.dev : les tests de caractérisation servent à « figer son comportement actuel, bugs compris », et un modèle qui invente les sorties ne fige rien.

Le golden master inversé

La règle tient en une phrase, posée par Hamadi Jabloun dans le même article : « le LLM génère les ENTRÉES. Le code legacy, lui seul, génère les SORTIES ». Le modèle repère bien les frontières à tester : zéro, champs vides, seuils, dates de fin de mois, débordements. L'autorité sur les sorties appartient au programme qui tourne en production. Les entrées proposées sont rejouées sur l'application d'origine dans un environnement de test, les sorties observées, erreurs comprises, sont enregistrées, et la nouvelle application est jugée contre cet enregistrement seul. Le modèle qui écrit le code cible reçoit la consigne de signaler tout cas qui lui paraît erroné dans une liste d'écarts à arbitrer, au lieu de le corriger en silence ; le métier tranche entre défaut du nouveau code et bug historique.

Le score de mutation mesure le filet : PIT en Java ou mutmut en Python injectent des fautes dans le code et comptent celles que la suite détecte, quand un taux de couverture de lignes ne dit rien de la qualité des assertions. Le shadow traffic sécurise la bascule : la production est routée vers les deux implémentations en parallèle, seule la réponse de l'ancienne fait foi, et les divergences sont journalisées. Un module bascule quand le taux de divergence reste nul sur une période représentative.

D'autres acteurs du marché appliquent le même principe. Winfall, qui migre des applications WinDev et WebDev vers C# et .NET, écrit : « Chaque procédure migrée reçoit ses tests unitaires C#, dont les valeurs attendues sont capturées sur l'application d'origine. »

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, nombres aléatoires, compteurs et numérotations, appels réseau, singletons statiques. On introduit des points de contrôle, les seams de Feathers : horloge paramétrable, numérotation injectée, wrapper autour de l'appel externe. Le commit qui rend l'application testable ne touche à aucune règle métier.

Ce que l'on compare dépend de l'application. Une fonction d'un progiciel de gestion renvoie rarement une simple valeur ; ses effets sont dans les tables, les documents imprimés et les fichiers exportés. On capture l'état des tables après chaque scénario (lignes créées, modifiées, supprimées, valeurs calculées), on compare les états imprimés par extraction du texte et des montants ou visuellement avec une tolérance définie, et on compare les exports octet par octet après normalisation des horodatages et des identifiants techniques. Le meilleur golden master reste l'enregistrement du trafic de production sur une période représentative, avec au moins une clôture de mois.

Dans la pratique SFEIR : l'étape 5 de la migration

Le golden master inversé est l'étape 5 de la méthode de migration en six étapes que SFEIR applique aux applications WinDev, et sa gate Ship : un module ne bascule qu'à divergence nulle (la méthode détaillée, le guide de la migration WinDev). Les scénarios Gherkin issus de l'extraction des règles métier fournissent les premières entrées ; la phase transitoire où l'application d'origine tourne sur PostgreSQL permet de comparer des écritures dans le même moteur. Le livrable par module : un fichier golden_master.json, le rapport de comparaison et le score de mutation de la suite.

Une migration livrée sans ce filet nourrit le rework rate, ces déploiements non planifiés qui corrigent ce que la recette n'a pas vu. La fiche modernisation legacy situe la pratique dans l'ensemble de la démarche.