Audit d'application WinDev :
décider avant de migrer.

Pourquoi commencer par un audit ?

Une application WinDev qui tourne depuis des années a souvent été écrite par plusieurs développeurs successifs, sans documentation à jour. Personne ne sait exactement combien de fenêtres sont encore utilisées, quelles règles de calcul s'appliquent, ni quelles données sont fiables. Lancer une migration sans le savoir, c'est découvrir les problèmes en cours de route, au moment où ils coûtent le plus cher.

L'audit répond à quatre questions avant tout engagement :

• Que fait réellement l'application ? Écrans, traitements, éditions, échanges avec d'autres logiciels.
• Où sont les règles métier ? Et sont-elles cohérentes d'un écran à l'autre ?
• Quels sont les risques ? Dépendances, sécurité, qualité des données, connaissances concentrées sur une seule personne.
• Quelle suite donner ? Migration progressive, refonte complète ou maintenance de l'existant, avec un chiffrage des charges et des délais.

C'est la première des six étapes de notre méthode de migration. Elle est utile même si vous n'êtes pas encore décidé : elle vous donne les éléments pour choisir.

Ce que l'audit analyse, brique par brique

Chaque élément d'un projet PC SOFT est examiné, et chacun débouche sur une information utile pour la suite.

Exemple : ce que l'audit trouve dans le code

L'audit ne se contente pas de compter les fenêtres : il lit le code. Voici deux constats typiques, tirés de situations que l'on rencontre souvent dans les applications WinDev.

Un risque de sécurité

Une recherche construit sa requête SQL en collant directement le texte saisi par l'utilisateur. Une apostrophe dans un nom suffit à la faire échouer, et une saisie malveillante peut modifier la requête.

// Clic sur BTN_Rechercher · requête construite par concaténation
sSQL est une chaîne = "SELECT * FROM Client WHERE Nom LIKE '" + SAI_Nom + "%'"
HExécuteRequêteSQL(REQ_Recherche, hRequêteDéfaut, sSQL)

La correction est simple et peut être faite tout de suite dans l'application WinDev, sans attendre la migration : la valeur saisie devient un paramètre de requête.

// Requête REQ_ClientParNom créée dans l'éditeur, avec un paramètre
REQ_ClientParNom.ParamNom = SAI_Nom + "%"
HExécuteRequête(REQ_ClientParNom)

Une règle métier en double

Le plus précieux d'un audit, c'est la cartographie des règles métier. Chaque règle est décrite dans une fiche : où elle se trouve, ce qu'elle fait, et les écarts éventuels entre plusieurs versions du même calcul.

Règle RG-012 · Remise fidélité
  Où         CalculTotalClient (procédure globale)
             + BTN_Valider de FEN_Commande (copie modifiée)
  Règle      Total des commandes du client > 1 000 € → remise de 5 %
  Écart      FEN_Commande compare avec ">=" au lieu de ">"
  À trancher Quelle version est la bonne ? (question posée au service commercial)
  Test       Client à 1 000 € pile : remise ou pas ?

Ces fiches servent ensuite deux fois : elles indiquent aux développeurs quoi reprendre dans la nouvelle technologie, et elles deviennent des tests de non-régression qui prouvent que le nouveau logiciel calcule comme l'ancien.

Les livrables de l'audit

• Inventaire de l'application : fenêtres ou pages, procédures, requêtes, états, composants, avec leur usage réel ;
• Cartographie des règles métier, sous forme de fiches réutilisables ;
• Analyse de la base HFSQL : modèle de données, anomalies, proposition de schéma cible ;
• Liste des risques : sécurité, dépendances, données, connaissances ;
• Recommandation de technologie cible, argumentée selon votre contexte ;
• Scénario de migration (progressif ou complet), découpé en lots, avec un chiffrage des charges et des délais.

Les pièges que l'audit permet d'éviter

Migrer ce qui ne sert plus

Une application ancienne contient presque toujours des écrans, des états et des traitements que plus personne n'utilise. Les reprendre coûte du temps pour rien. L'audit, croisé avec les échanges utilisateurs, permet de les écarter.

Oublier une dépendance

Une DLL d'un fournisseur disparu, un export vers la comptabilité lancé chaque nuit, un lecteur de badge : ces dépendances sont rarement visibles depuis l'interface. Découvertes tard, elles bloquent la mise en production.

Sous-estimer les données

Des dates invalides, des doublons ou des liaisons orphelines dans la base HFSQL peuvent faire échouer la reprise. L'audit les mesure en amont. Voir notre page HFSQL vers PostgreSQL.

Choisir la technologie avant de connaître le besoin

Application de bureau, web ou mobile ? C# ou Node.js ? Flutter ou React Native ? La bonne réponse dépend de vos utilisateurs, de vos équipes et de vos contraintes. L'audit vous donne les éléments pour choisir, plutôt que de suivre une tendance.

Comment se déroule l'audit

1. Premier échange, gratuit et sans engagement. Nous parlons de votre application, de vos objectifs et de vos contraintes.
2. Cadrage. Périmètre de l'audit, cadre de confidentialité, accès aux sources et aux données.
3. Analyse du code et de la base. Le code WLangage est cartographié, même sans documentation. Si vous le souhaitez, l'IA peut accélérer cette lecture, avec relecture systématique par un développeur.
4. Échanges avec les utilisateurs. Pour comprendre les usages réels et les irritants du quotidien.
5. Restitution. Présentation des constats, des recommandations et du scénario de migration chiffré.

Selon la cible retenue, la suite se fait vers C# / .NET, React pour un site WebDev ou Flutter pour une application mobile. Nous pouvons aussi assurer la maintenance de votre application WinDev avant, pendant et après la migration.