Auditer une application WinDev avant migration

Introduction

Avant une migration, l’audit d’une application WinDev doit répondre à une question simple : qu’est-ce qui doit continuer à fonctionner, de quoi cela dépend-il, et qu’est-ce qui peut casser pendant le changement ? La méthode consiste à partir de l’application réellement exploitée, puis à remonter vers les sources, les données, les interfaces et les choix techniques. Pas l’inverse.

Le mot " migration " recouvre d’ailleurs plusieurs réalités. Passage à une version plus récente de WinDev, changement de moteur de base, déplacement d’infrastructure, remplacement d’un composant, évolution vers une architecture différente, reprise partielle vers le web. Les risques ne sont pas les mêmes.

Sur une application métier qui tourne depuis dix ou quinze ans, le projet ouvert dans l’éditeur ne raconte qu’une partie de l’histoire. Il y a les exécutables réellement déployés, les fichiers de configuration, les tâches planifiées, les droits, les imprimantes particulières, les exports attendus par la comptabilité, les composants tiers, les habitudes utilisateurs et quelques traitements que personne ne veut toucher un vendredi.

C’est ce décalage entre le projet théorique et le système réellement utilisé qu’il faut mesurer avant de décider comment migrer.

Définir la migration avant de commencer l’audit

Un audit devient vite inutile si la cible reste floue.

" Migrer l’application " peut vouloir dire mettre le projet à niveau dans une version récente de WinDev sans changer son architecture. Cela peut aussi vouloir dire conserver l’interface mais déplacer HFSQL, remplacer une base SQL, revoir le mode de déploiement ou sortir certains traitements vers d’autres services.

La première étape consiste donc à écrire une phrase de cadrage très simple :

Nous voulons faire évoluer tel périmètre, depuis telle situation, vers telle cible, sans interrompre tels usages critiques.

Cette phrase oblige à nommer le point de départ et le résultat attendu. Elle évite aussi de mélanger plusieurs chantiers.

Une montée de version WinDev et une migration de base de données peuvent être réalisées dans le même programme. Cela ne signifie pas qu’elles doivent être évaluées comme un seul risque. Plus on empile les changements, plus il devient difficile d’expliquer une régression.

Le cadrage précise au minimum :

• la version de WinDev aujourd’hui utilisée pour produire l’application ;
• la version réellement déployée sur les postes ;
• le ou les moteurs de données ;
• les environnements concernés ;
• les modules inclus ou exclus ;
• les contraintes de calendrier métier ;
• la cible envisagée ;
• les éléments qui ne doivent pas changer pendant la migration.

Ce dernier point est souvent négligé. Il est pourtant utile. Si la migration porte sur la version WinDev, on évite d’y glisser en même temps une refonte fonctionnelle de la facturation et une réorganisation des droits.

Partir de la production, pas du dépôt de sources

Le premier inventaire se fait depuis ce qui tourne.

Je cherche d’abord à savoir ce que les utilisateurs lancent réellement, où se trouvent les données, quels serveurs répondent, quels échanges sortent de l’application et quels traitements continuent à fonctionner sans intervention visible.

Un projet WinDev peut être propre alors que la production repose sur une ancienne bibliothèque déposée manuellement sur trois postes. L’inverse existe aussi : des sources historiques donnent une impression de désordre alors que le périmètre exploité est finalement assez stable.

Il faut relever les versions d’exécutables, les modes d’installation, les répertoires partagés, les paramètres locaux, les serveurs sollicités, les traitements automatiques et les composants non livrés par le projet lui-même.

Pour les applications WinDev anciennes, je vérifie aussi s’il existe plusieurs branches de fait : une version chez certains utilisateurs, une autre sur un site distant, un exécutable corrigé directement pour un client interne, ou une installation dont personne n’a conservé la procédure.

Ce travail n’a rien de spectaculaire. Il évite pourtant de préparer une migration sur un système qui n’existe plus vraiment.

Reconstituer le périmètre fonctionnel réellement utilisé

Une application métier contient souvent plus de fonctions que l’entreprise n’en utilise encore.

À l’inverse, quelques écrans anodins peuvent être vitaux. Un export mensuel lancé par une seule personne peut alimenter la paie, la comptabilité ou un client important.

L’audit doit donc distinguer trois choses :

Les entretiens avec les utilisateurs servent ici à identifier les écarts. Je ne demande pas seulement " qu’utilisez-vous ? “. Je demande aussi ce qu’ils font avant, après, et à côté de l’application.

C’est souvent là qu’apparaissent les fichiers Excel intermédiaires, les réimportations, les contrôles manuels, les éditions imprimées puis ressaisies, les manipulations d’images ou de PDF, les envois par messagerie et les exports vers des logiciels tiers.

Ces étapes périphériques font partie du périmètre de migration dès qu’elles conditionnent le résultat métier.

Cartographier les dépendances WinDev

Une application WinDev peut dépendre de nombreux éléments qui ne sautent pas aux yeux quand on ouvre le projet.

L’objectif n’est pas de produire une encyclopédie. Il faut identifier ce qui peut empêcher le démarrage, modifier un résultat ou rendre un scénario impossible après migration.

Je passe notamment en revue :

• les composants internes et externes ;
• les bibliothèques natives et DLL ;
• les composants COM, ActiveX ou .NET ;
• les pilotes ODBC ou OLE DB ;
• les accès à HFSQL, SQL Server, PostgreSQL, MariaDB ou d’autres moteurs ;
• les webservices SOAP ou REST ;
• les échanges de fichiers ;
• les répertoires réseau ;
• les automations Office ;
• les dispositifs d’impression, de scan ou de signature ;
• les tâches planifiées et services associés ;
• les outils lancés en ligne de commande ;
• les dépendances liées à un poste, un serveur ou un utilisateur particulier.

Pour chaque dépendance, je cherche un propriétaire, un usage, une fréquence, un environnement et un moyen de test.

Une dépendance non documentée n’est pas automatiquement critique. Une dépendance critique sans propriétaire, elle, mérite une attention immédiate.

Vérifier la cohérence entre sources et production

C’est un point de contrôle à traiter tôt.

Il faut être capable de répondre à cette question : si je reconstruis aujourd’hui l’application depuis les sources disponibles, est-ce que j’obtiens ce qui est en production ?

La réponse peut être non pour de nombreuses raisons : correctif non remonté, bibliothèque remplacée à la main, paramétrage oublié, branche historique, version différente d’un composant, ressource externe absente.

Tant que cet écart n’est pas compris, la migration reste difficile à sécuriser. On risque de comparer une nouvelle version reconstruite avec une production issue d’un autre état.

Je ne cherche pas forcément à remettre tout le patrimoine documentaire au propre avant d’avancer. Il faut au moins identifier la version de référence et figer les écarts connus.

Le livrable utile tient parfois sur une page : quelle source fait foi, quel exécutable fait foi, quelles différences sont acceptées, lesquelles doivent être résolues.

Auditer les données comme un sujet à part entière

Une migration applicative se joue souvent dans les données.

Le modèle défini dans l’analyse WinDev donne une base de travail, mais il faut aussi regarder les volumes, l’historique, les fichiers réellement présents, les valeurs atypiques, les doublons connus, les règles de suppression et les données qui ne sont plus exploitées.

Sur HFSQL, j’examine la topologie réelle : Classic ou Client/Serveur, bases locales éventuelles, réplications, sauvegardes, accès directs par d’autres outils. Sur un moteur SQL externe, la question reste la même : qui lit et qui écrit en dehors de l’application ?

Une table qu’aucun écran WinDev ne semble utiliser peut alimenter un reporting externe.

La migration doit donc distinguer :

• les données nécessaires au fonctionnement ;
• les données nécessaires à l’historique ;
• les données nécessaires à des tiers ;
• les données devenues inutiles mais encore présentes ;
• les données dont la qualité pose déjà problème avant tout changement.

Il vaut mieux découvrir une incohérence avant migration. Sinon, elle sera souvent attribuée à la migration, même si elle existait depuis cinq ans.

Identifier les règles métier qui ne sont écrites nulle part

Les applications métier anciennes contiennent beaucoup de savoir implicite.

Une règle peut être dans le code. Elle peut aussi être dans un paramètre de base, une valeur par défaut, une procédure suivie par les utilisateurs ou un contrôle manuel réalisé après l’édition d’un document.

L’audit cherche les endroits où le résultat dépend d’une connaissance détenue par une personne.

Quelques questions aident beaucoup :

• Quels écrans personne n’ose modifier ?
• Quelles opérations nécessitent de " savoir comment faire " ?
• Quels résultats sont vérifiés manuellement ?
• Quels calculs sont comparés à un fichier externe ?
• Quels traitements ne doivent jamais être lancés deux fois ?
• Que fait-on quand une interface externe ne répond pas ?
• Qui sait restaurer une situation après incident ?

Le but n’est pas de documenter tout le métier. Il s’agit de repérer les règles qui devront être conservées ou vérifiées pendant la migration.

Mesurer la capacité de régression

Une migration sans capacité de comparaison est une migration difficile à piloter.

Avant de changer quoi que ce soit, il faut construire un jeu de scénarios de référence. Pas des centaines. Les scénarios qui couvrent les opérations qui comptent.

Pour une application de gestion, cela peut inclure une création de commande, une modification, une facturation, un avoir, une clôture, une édition, un export, une recherche sur historique et un échange avec un système tiers.

Chaque scénario doit avoir un résultat attendu observable.

Je préfère dix scénarios rejouables avec des données connues à une longue liste de tests théoriques que personne n’exécutera le jour de la bascule.

L’audit doit aussi dire qui valide. Le développeur peut vérifier que l’application ne plante pas. Il ne peut pas toujours confirmer qu’un calcul de marge, une règle de remise ou une séquence de clôture reste juste.

Examiner l’exploitation avant l’architecture cible

Le fonctionnement quotidien pèse beaucoup dans le risque de migration.

Je regarde comment l’application est installée, mise à jour, sauvegardée, surveillée et dépannée. Je vérifie aussi comment un poste neuf est préparé et comment un utilisateur distant travaille.

Si personne ne sait reconstruire un poste ou restaurer une base, la migration ajoute un risque alors que l’exploitation n’est déjà pas reproductible.

Les points à documenter sont assez terre-à-terre :

• où sont les sauvegardes ;
• quand une restauration a été testée pour la dernière fois ;
• qui peut déployer ;
• comment les paramètres diffèrent entre développement, recette et production ;
• comment les incidents sont tracés ;
• quels droits administratifs sont nécessaires ;
• quels certificats, comptes techniques ou licences sont requis ;
• comment revenir à la version précédente.

Le retour arrière ne doit pas être une phrase dans un planning. Il faut savoir ce qui sera restauré, dans quel ordre et à partir de quel état de données.

Traiter la sécurité dans le même audit, sans la confondre avec tout le reste

Une migration est un bon moment pour relever les fragilités de sécurité, mais l’audit de migration n’est pas automatiquement un audit de sécurité complet.

L’ANSSI distingue plusieurs activités possibles : audit d’architecture, de configuration, d’organisation, de code ou test d’intrusion. Elle rappelle aussi qu’un simple test automatisé de vulnérabilités ne couvre pas à lui seul une démarche d’audit.

Pour une application WinDev, je relève au minimum les points qui peuvent bloquer ou aggraver la migration : comptes partagés, secrets dispersés, droits excessifs, accès directs à la base, composants obsolètes, postes trop privilégiés, flux non chiffrés ou sauvegardes mal protégées.

Pour les fonctions web ou les API associées, l’OWASP ASVS fournit une grille de contrôle plus structurée. Il ne remplace pas l’analyse du contexte métier, mais il aide à ne pas oublier des familles de contrôles.

L’idée reste de séparer les constats. Une faiblesse de sécurité urgente peut nécessiter une correction avant migration. Une amélioration souhaitable peut être planifiée plus tard.

Lire le code pour répondre à des questions précises

Le code entre dans l’audit après la cartographie.

Je ne cherche pas à noter la qualité générale du projet. Cette note serait subjective et assez peu utile pour décider d’une migration.

Je cherche plutôt les zones qui influencent directement le changement envisagé :

• fort couplage entre interface, règles métier et accès aux données ;
• procédures globales utilisées partout ;
• comportements dépendants de variables globales ;
• traitements qui supposent un chemin ou un poste précis ;
• appels à des composants externes ;
• fonctions anciennes ou spécifiques à une version ;
• logique métier dupliquée ;
• absence de séparation entre calcul et affichage ;
• zones modifiées fréquemment et déjà fragiles.

Les outils d’audit de WinDev peuvent apporter des signaux. Ils ne remplacent pas cette lecture orientée risque.

Une application peut contenir beaucoup de code ancien sans poser de problème à la migration visée. Inversement, quelques dizaines de lignes autour d’une interface critique peuvent concentrer l’essentiel du risque.

Construire une matrice de risque utile à la décision

Après l’inventaire, il faut sortir du catalogue.

Je classe les sujets avec quatre critères :

Cette grille permet de distinguer un vieux module stable et isolé d’une interface récente mais mal comprise qui alimente la facturation.

La priorité n’est pas toujours le composant le plus ancien.

Je demande aussi pour chaque risque : peut-on le réduire avant la migration, le tester pendant, l’isoler du périmètre, ou faut-il l’accepter temporairement ?

C’est à ce moment que l’audit commence réellement à produire une trajectoire.

Décider entre migration directe, stabilisation et découpage

Tous les audits ne doivent pas mener au même plan.

Migration directe

Elle est raisonnable lorsque le périmètre est maîtrisé, les dépendances sont connues, les scénarios de régression existent et le retour arrière est crédible.

Cela ne signifie pas que l’application est parfaite. Elle est suffisamment comprise pour changer dans des conditions contrôlées.

Stabilisation avant migration

Elle s’impose quand les sources et la production divergent fortement, quand les incidents sont déjà nombreux, quand les sauvegardes ne sont pas fiables ou quand plusieurs composants critiques restent inconnus.

La stabilisation peut être courte. Le but est de réduire l’incertitude avant d’ajouter un changement de plateforme ou de version.

Découpage du périmètre

C’est souvent le meilleur choix pour une grosse application.

On peut migrer un socle d’abord, laisser un module critique sur sa version actuelle, traiter une interface externe séparément ou différer une reprise de données historique.

Ce découpage doit respecter les dépendances. Un module " petit " n’est pas autonome simplement parce qu’il possède peu d’écrans.

Remise en question de la migration

Parfois, l’audit montre que la cible choisie ne traite aucun problème prioritaire.

Passer à une nouvelle version de WinDev peut être nécessaire pour le support ou la compatibilité. Cela ne corrigera pas, à lui seul, une organisation de données fragile, une dépendance à une personne ou un processus métier incohérent.

L’audit doit avoir le droit d’arriver à cette conclusion.

Les livrables que j’attends à la fin de l’audit

Un audit avant migration ne devrait pas se terminer par un document de cinquante pages que personne ne relira.

J’attends plutôt un ensemble court de livrables utilisables pendant le projet :

• une cartographie du périmètre et des dépendances ;
• une liste des fonctions critiques ;
• un état des sources, versions et environnements ;
• une cartographie des flux de données ;
• un registre des risques classés ;
• les prérequis à traiter avant migration ;
• les scénarios de régression ;
• les principes de retour arrière ;
• une recommandation de séquencement ;
• les points qui demandent encore une décision métier ou technique.

Pour chaque risque important, il faut un propriétaire et une action. " À surveiller " n’est pas une action.

Le résultat de l’audit doit pouvoir servir de base à une réunion de décision sans avoir besoin de réexpliquer tout le système oralement.

Ce que je considère comme des signaux d’alerte

Certains constats ne condamnent pas une migration. Ils changent son niveau de préparation.

Je creuse davantage lorsqu’on rencontre plusieurs des situations suivantes :

• personne ne sait produire l’exécutable actuellement utilisé ;
• la base de production ne correspond plus au modèle attendu ;
• les sauvegardes existent mais n’ont jamais été restaurées ;
• un seul collaborateur connaît les règles critiques ;
• des bibliothèques anciennes ne peuvent plus être retrouvées ;
• plusieurs postes disposent de correctifs différents ;
• les accès externes ne sont pas inventoriés ;
• la recette se résume à " les utilisateurs nous diront si ça marche " ;
• aucun environnement ne permet de rejouer des scénarios représentatifs ;
• le retour arrière implique des manipulations improvisées sur les données.

Pris séparément, chacun peut être gérable. Leur accumulation indique surtout que le chantier comporte plus d’incertitude que la migration elle-même ne le laisse penser.

Une méthode en deux passages

Sur les applications WinDev anciennes, je préfère travailler en deux passages.

Le premier est rapide et large. Il sert à cartographier l’application, les usages, les données, les dépendances et l’exploitation. On identifie les zones qui méritent du temps.

Le second approfondit seulement les sujets qui influencent la migration : module très couplé, composant tiers ancien, conversion de données, installation atypique, fonction métier critique, sécurité d’un flux, ou impossibilité de rejouer un scénario.

Cette façon de travailler évite de passer plusieurs jours sur une partie du code qui ne changera pas.

Elle permet aussi d’expliquer le budget d’audit. On ne promet pas de " tout analyser “. On montre quelles incertitudes doivent être levées pour prendre une décision.

Définitions utiles

Audit applicatif : analyse structurée d’une application, de son usage, de ses dépendances et de son exploitation afin d’évaluer les risques et la capacité d’évolution.

Migration : changement de version, de plateforme, de moteur de données, d’infrastructure ou de périmètre technique, avec conservation d’un service attendu.

Régression : comportement qui fonctionnait avant le changement et qui ne fonctionne plus, ou produit un résultat différent, après migration.

Dépendance : composant, service, configuration, donnée, matériel ou acteur dont l’application a besoin pour assurer un fonctionnement attendu.

Retour arrière : procédure permettant de revenir à l’état antérieur lorsque la migration ne peut pas être validée dans les conditions prévues.

Le mot de la fin

Auditer une application WinDev avant migration sert d’abord à réduire l’incertitude.

La valeur de l’audit n’est pas dans le nombre d’anomalies relevées. Elle est dans la capacité à expliquer ce qui doit être préservé, ce qui peut être changé, ce qui risque de casser et comment on le vérifiera.

Pour une PME, c’est souvent ce qui fait la différence entre une migration qui reste un projet technique isolé et une migration qui peut être pilotée sans mettre l’exploitation sous tension.

Chez EloNeva, c’est aussi le point de départ d’une trajectoire raisonnable : conserver ce qui fonctionne, traiter les fragilités qui comptent et éviter de transformer une montée de version ou un changement de socle en refonte générale sans justification.