Blog · Recette
Pas de documentation ? Le code source en tient lieu : aucune règle métier oubliée en route
Les applications WINDEV® de quinze ou vingt ans ont rarement une documentation à jour. Leurs règles métier existent pourtant : elles sont écrites dans le code des fenêtres, des états et des procédures. Nous les en extrayons pour bâtir le carnet de recette.
Le vrai risque d’une migration : la règle oubliée
Une migration échoue rarement sur ce qui se voit. Les écrans, on les compare ; les états imprimés, on les rapproche au centime. Ce qui coûte cher, c’est la règle que personne n’a pensé à mentionner, parce qu’elle s’applique toute seule depuis des années : une remise automatique, un contrôle d’encours, un bouton grisé dans un cas précis.
Les référents métier connaissent leur travail, pas le code. Les développeurs d’origine sont partis. La seule source complète, c’est le code source.
Un carnet de recette tiré du code
Pour chaque fenêtre, chaque état et chaque procédure, nous relevons les règles : l’action de l’utilisateur, la règle appliquée, l’effet sur la base de données et le résultat attendu. Voici un extrait pour la fenêtre FEN_SaisieCommande, bouton « Valider » : 5 règles sur les 12 relevées.
| Réf. | Action utilisateur | Règle métier | Impact sur la base | Résultat attendu |
|---|---|---|---|---|
| R-01 | Valider sans saisir de quantité | Quantité supérieure à 0 | Aucune écriture | Message « Quantité obligatoire » |
| R-04 | Valider au-delà du plafond client | Encours + montant ≤ plafond | Aucune écriture | Message « Plafond dépassé » |
| R-07 | Valider pour un client grand compte | Remise de 5 % pour la catégorie « GC » | INSERT commande, UPDATE client.encours | Commande listée, encours à jour |
| R-09 | Changer de client en cours de saisie | Prix repris de la grille tarifaire du client | SELECT tarif_client | Prix unitaires recalculés |
| R-12 | Supprimer une commande facturée | Une commande facturée est intouchable | Aucune écriture | Bouton « Supprimer » grisé |
Trois étapes
- Extraction. L’IA lit les fenêtres, les états, les procédures, les traitements batch et les déclencheurs de la base, et en tire les règles, avec leur emplacement dans le code. Nos développeurs relisent ce relevé.
- Validation. Le carnet est relu avec vos référents métier, avant le début des travaux. C’est là qu’apparaissent les règles devenues obsolètes : vous décidez de les garder, de les modifier ou de les retirer.
- Recette. Suivie par un Product Owner dédié. Le carnet pilote d’abord nos tests automatisés, puis votre recette : chaque ligne est vérifiable, et chaque écart est soit corrigé, soit justifié par écrit.
Ce que le carnet vous laisse
- Une documentation métier, écran par écran, que vous n’aviez plus.
- Une base de tests de non-régression pour les évolutions futures de la nouvelle application.
- Un support de transmission pour les nouveaux arrivants, développeurs comme utilisateurs.
Ce que le carnet ne remplace pas
Le code dit ce que fait l’application, pas toujours pourquoi, ni comment les utilisateurs la contournent. Les habitudes de saisie, les exports retravaillés dans un tableur, les manipulations « à ne pas faire » se recueillent en atelier avec vos équipes. Le carnet donne la base ; vos référents la complètent.
Pour voir la démarche appliquée à une application réelle, lisez notre cas pratique ERP, et la page Méthode pour le déroulé complet.
Estimer ma migration en 2 minutes Demander mon devis gratuit
Autres articles : Migrer sans tout casser · Rester en WINDEV 2025 : un sursis · Traduire ligne à ligne ne suffit pas · Éditeurs : la redevance et votre marge. Tous nos articles sont sur le blog ; les versions courtes, sur LinkedIn.