En bref : une application WinDev ancienne contient des centaines de règles métier qui ne sont écrites nulle part ailleurs que dans le code. Les migrer sans les avoir extraites, c'est risquer d'en perdre. La rétro-documentation consiste à les repérer dans les sources, l'analyse, les requêtes et les états, puis à les formaliser et à les faire valider par les métiers. C'est la première phase de toute migration sérieuse.
Vous envisagez de migrer votre application WinDev vers le web, .NET ou Java. Avant même de choisir la technologie cible, une question doit être réglée : savez-vous précisément ce que fait votre application ? Dans la plupart des entreprises, la réponse honnête est non. Les règles de calcul, les contrôles de saisie, les exceptions accordées à tel client ou tel produit ont été ajoutés au fil des années, souvent sans documentation. Cet article explique comment extraire ces règles métier et produire une documentation exploitable avant la migration. Il complète notre article sur l’audit d’une application WinDev avant migration.
- Pourquoi la documentation de l'application WinDev est l'étape critique
- Étape 1 : réunir les sources et les personnes
- Étape 2 : cartographier l'application
- Étape 3 : extraire et formaliser les règles métier
- Étape 4 : faire valider par les métiers et capturer le comportement
- Comment cette étape s'inscrit dans la méthode MIRROR
- Questions fréquentes
Pourquoi la documentation de l'application WinDev est l'étape critique
Une règle métier est une décision de gestion traduite en code : « une remise de 5 % s'applique au-delà de 50 unités, sauf pour les produits en promotion », « une commande ne peut pas être validée si le client a une facture impayée de plus de 60 jours ». Ces règles sont la vraie valeur de votre application. La technologie, elle, est remplaçable.
Le problème, c'est que ces règles sont dispersées. Dans une application WinDev typique, on les retrouve :
- dans le code des fenêtres et des champs (événements de saisie, de sortie, de clic) ;
- dans les procédures globales et les collections de procédures ;
- dans les requêtes de l'éditeur de requêtes et les requêtes SQL écrites à la main ;
- dans les états imprimés, qui contiennent parfois leurs propres calculs ;
- dans l'analyse (le modèle de données), à travers les liaisons et les contraintes ;
- et dans la tête des utilisateurs, qui contournent certaines limites par des habitudes de saisie.
Si vous migrez sans avoir fait cet inventaire, l'équipe de développement reconstruira ce qu'elle voit à l'écran. Les règles invisibles, elles, disparaîtront. On ne s'en apercevra qu'en production, au premier calcul faux.
Étape 1 : réunir les sources et les personnes
Une rétro-documentation commence par un inventaire matériel. Il vous faut :
- Les sources complètes du projet, dans la version réellement en production : projet, analyse, fenêtres, états, requêtes, composants externes.
- Une copie anonymisée des données, pour vérifier les hypothèses sur des cas réels.
- La liste des utilisateurs clés par domaine : comptabilité, commerce, production, logistique.
- Tout document existant, même ancien : cahier des charges initial, notes de version, procédures internes.
Si les sources sont chez un prestataire ou si vous n'êtes pas certain d'avoir la bonne version, commencez par là. Notre article récupérer le code source d’une application WinDev détaille la démarche. Et si le développeur historique est sur le départ, chaque semaine compte : notre plan d’action en cas de départ du développeur WinDev vous aide à organiser la transmission.
Étape 2 : cartographier l'application
Avant d'entrer dans le détail des règles, il faut une vue d'ensemble. La cartographie répond à trois questions : quels sont les modules fonctionnels, quelles données ils manipulent, et comment ils échangent avec l'extérieur.
- Inventaire des fenêtres et des états, regroupés par domaine fonctionnel.
- Modèle de données : fichiers HFSQL, rubriques, clés et liaisons, avec leur volumétrie.
- Flux externes : imports, exports, échanges avec la comptabilité, l'ERP, des fichiers Excel ou des webservices.
- Traitements planifiés : tâches de nuit, calculs périodiques, purges.
- Code mort : fenêtres et procédures qui ne sont plus appelées. Les repérer évite de les migrer pour rien.
Cette cartographie sert aussi à estimer l'effort de migration. Elle constitue la base du chiffrage dans un audit d’application WinDev.
Étape 3 : extraire et formaliser les règles métier
C'est le cœur du travail. Pour chaque module, l'analyste lit le code, identifie chaque décision de gestion et la reformule en langage clair. Une bonne fiche de règle métier contient :
| Champ | Exemple |
|---|---|
| Identifiant | CMD-012 |
| Énoncé | Une commande est bloquée si le client a une facture échue depuis plus de 60 jours. |
| Déclencheur | Validation de la commande |
| Exceptions | Clients marqués « grand compte » |
| Emplacement dans le code | Procédure de validation, fenêtre de saisie des commandes |
| Données concernées | Fichiers Commande, Client, Facture |
| Statut | Validée par le responsable ADV |
Trois pièges reviennent souvent. Les valeurs codées en dur (un taux, un seuil, un code client) qui devraient être des paramètres. Les règles contradictoires, appliquées différemment selon l'écran par lequel on passe. Et les effets de bord, quand une procédure modifie des données qu'on n'attendait pas. Chacun doit être signalé explicitement : faut-il le reproduire tel quel ou le corriger pendant la migration ?
Les outils d'analyse de code, y compris ceux qui s'appuient sur l'intelligence artificielle, accélèrent la lecture et le repérage. Ils ne remplacent pas la validation humaine : seul un utilisateur métier peut dire si une règle est voulue ou si c'est un bug devenu habitude.
Étape 4 : faire valider par les métiers et capturer le comportement
Une règle extraite du code n'est qu'une hypothèse tant qu'elle n'est pas confirmée. Organisez des ateliers courts, par domaine, avec les utilisateurs clés. Pour chaque règle, trois réponses possibles : on garde, on modifie, on supprime.
En parallèle, il faut enregistrer le comportement actuel de l'application sur des cas réels : pour telle entrée, tel résultat. Ces jeux de référence serviront plus tard à vérifier que le nouveau système produit exactement les mêmes résultats. Sans eux, la recette repose sur des impressions.
Le livrable final regroupe la cartographie, le catalogue des règles métier validées et les jeux de référence. C'est un actif pour l'entreprise, utile même si la migration est reportée : il réduit la dépendance à une seule personne et facilite toute maintenance future.
Comment cette étape s'inscrit dans la méthode MIRROR
Chez ETC SOFT, nous avons formalisé cette démarche dans MIRROR, notre méthode de migration en six phases. Les deux premières phases correspondent exactement à ce que décrit cet article :
- Map (cartographier) : inventorier le code, les flux et chaque règle métier, y compris ce qui n'est écrit nulle part.
- Imprint (capturer) : enregistrer le comportement actuel, entrées, traitements et résultats, pour en faire la référence.
Les phases suivantes, Rebuild, Reconcile, Operate et Release, s'appuient directement sur ce travail. Le principe est simple : chaque règle métier identifiée est vérifiée par un test, ce test produit une preuve de parité entre l'ancien et le nouveau système, et une trace de validation est conservée.
Quelle que soit la cible retenue, cette étape reste la même. Elle précède aussi bien une migration WinDev vers le web qu'une migration WinDev vers C# / .NET, et elle prépare la migration des données HFSQL vers PostgreSQL.
Questions fréquentes
Qu'est-ce que la rétro-documentation d'une application ?
C'est la production, à partir du code et des données existants, de la documentation qui n'a jamais été écrite : cartographie, modèle de données et catalogue des règles métier.
Combien de temps faut-il pour documenter une application WinDev ?
Cela dépend de la taille de l'application et de l'état du code. Un audit initial permet d'estimer cet effort avant de s'engager sur la documentation complète.
Peut-on automatiser l'extraction des règles métier ?
En partie. Les outils d'analyse de code et d'intelligence artificielle accélèrent le repérage, mais la validation par les utilisateurs métier reste indispensable.
Faut-il documenter même si la migration n'est pas décidée ?
Oui. Une documentation à jour réduit la dépendance à un développeur unique, facilite la maintenance et vous permet de décider de la migration en connaissance de cause.
Que faire des règles obsolètes trouvées dans le code ?
Les faire valider par les métiers, puis les supprimer explicitement pendant la migration. Ne pas les migrer par défaut évite d'alourdir le nouveau système.
Avant de migrer, sachez ce que fait vraiment votre application. Demandez un audit de votre application WinDev : nous cartographions le code, identifions les règles métier et chiffrons la migration.
