Migration WinDev : pourquoi auditer votre application avant de changer de technologie ?
Puis vient le moment où une question se pose : faut-il continuer à faire évoluer l’application existante ou envisager sa migration vers une autre technologie ?
À ce stade, commencer directement par réécrire l’application est rarement la meilleure approche. Avant de choisir une nouvelle architecture, un framework ou même d’établir un budget, il faut comprendre précisément ce que contient l’existant.
C’est tout l’intérêt d’un audit d’application WinDev avant migration.
À retenir
Un audit avant migration permet de savoir ce qui doit réellement être migré, ce qui peut être conservé, ce qui doit être repensé et ce qui peut être supprimé. Il permet également d’identifier les dépendances techniques et métier qui pourraient complexifier le projet.
L’objectif n’est donc pas simplement d’analyser du code WinDev, mais de sécuriser les décisions techniques, fonctionnelles et budgétaires liées à la migration.
Pourquoi une migration WinDev ne doit pas commencer par le choix d’une nouvelle technologie?
Faut-il migrer vers Java ? .NET ? Python ? PHP ? Une architecture web moderne ? Une application cloud ?
Cette question est importante, mais elle intervient trop tôt.
Avant de déterminer avec quoi reconstruire une application, il faut savoir précisément ce que l’on doit reconstruire.
Une application métier développée depuis plusieurs années contient généralement bien davantage que les fonctionnalités visibles par ses utilisateurs. Des règles métier peuvent être directement intégrées au code, certaines fonctions peuvent dépendre d’autres applications et des traitements automatiques peuvent s’exécuter sans intervention humaine.
L’application peut également communiquer avec une base HFSQL, MariaDB, PostgreSQL ou SQL Server, mais aussi avec un ERP, un logiciel comptable, une API externe, un système de fichiers, un outil documentaire ou différents services internes.
Une migration mal préparée risque donc de découvrir ces dépendances au fur et à mesure du projet. Et c’est précisément ce que l’audit cherche à éviter.
L’audit commence par comprendre l’application telle qu’elle existe réellement
La première étape consiste à dresser une cartographie de l’existant.Il ne s’agit pas uniquement de compter le nombre de fenêtres, de pages ou de lignes de code. Une application WinDev doit être étudiée comme un système complet.
L’analyse porte notamment sur son architecture, ses différents modules, ses bases de données, ses traitements, ses interfaces avec des systèmes tiers et les technologies utilisées autour de WinDev.Cette cartographie permet également de distinguer les composants encore réellement utilisés des fonctionnalités historiques qui sont parfois maintenues dans le code alors qu’elles n’ont plus d’utilité opérationnelle.Cette distinction peut avoir un impact considérable sur le périmètre d’une future migration.
Pourquoi consacrer du temps et du budget à reproduire une fonctionnalité que personne n’utilise plus ?
Retrouver les règles métier cachées dans le code
Les utilisateurs connaissent généralement le résultat attendu, mais pas nécessairement la logique technique permettant de l’obtenir. Une réécriture sans analyse approfondie peut alors produire une application techniquement moderne mais fonctionnellement différente de l’ancienne.
L’audit doit donc permettre d’identifier ces règles, de les documenter et de déterminer lesquelles doivent être reproduites dans la future solution.La migration devient ainsi une occasion de formaliser le patrimoine fonctionnel de l’entreprise, et pas seulement de remplacer une technologie.
Analyser la base de données avant de parler de migration
Certaines tables peuvent ne plus être utilisées. Des colonnes peuvent être devenues obsolètes. Des relations peuvent être gérées directement par l’application plutôt que par des contraintes en base.
Dans certains projets, la migration applicative s’accompagne également d’une migration de base de données, par exemple de HFSQL vers PostgreSQL, MariaDB ou SQL Server. Il devient alors nécessaire d’étudier la structure existante, les volumes, les relations entre données, les contraintes d’intégrité et les éventuelles incohérences avant de définir la stratégie de reprise.
Une migration réussie ne consiste pas simplement à transférer des tables d’un système vers un autre. Il faut garantir que les données restent cohérentes et exploitables par la nouvelle application.
Identifier les dépendances externes
Au fil du temps, elle peut avoir été connectée à différents composants : logiciels comptables, ERP, systèmes de paiement, services web, API partenaires, Active Directory, outils de reporting ou systèmes documentaires.
Certaines intégrations peuvent être clairement identifiées et documentées. D’autres peuvent être beaucoup plus discrètes. Un simple export de fichier déposé automatiquement dans un répertoire partagé peut, par exemple, alimenter un autre système critique de l’entreprise.
Supprimer ou modifier ce mécanisme lors d’une migration peut avoir des conséquences qui ne seront pas immédiatement visibles dans la nouvelle application.
L’audit permet donc de construire une cartographie des flux entrants et sortants afin d’identifier les interactions qui devront être maintenues, remplacées ou modernisées.
Évaluer la qualité et la maintenabilité du code WinDev
Certaines disposent d’une architecture relativement claire et peuvent être analysées rapidement. D’autres ont connu plusieurs générations de développeurs, des évolutions successives et de nombreux correctifs.
La dette technique devient alors un élément important de l’étude.
L’objectif n’est pas de juger la qualité historique du projet, mais de déterminer ce qui peut être réutilisé comme référence et ce qui doit être repensé.
Cette analyse aide notamment à décider si une migration progressive est possible ou si certains composants nécessitent une réécriture complète.
Elle permet aussi d’éviter un piège fréquent : reproduire dans la nouvelle technologie les mêmes contraintes architecturales que dans l’ancienne application.
Changer de technologie sans revoir certains choix historiques revient parfois simplement à déplacer la dette technique.
Faut-il tout réécrire ?
Une migration WinDev peut prendre plusieurs formes.
Dans certains projets, une réécriture complète est pertinente. Dans d’autres, il est préférable de migrer progressivement les modules les plus critiques tout en maintenant temporairement une partie de l’application existante.
Il est également possible de moderniser certaines briques, de remplacer progressivement les interfaces ou d’exposer certaines fonctionnalités existantes via des API afin d’organiser une transition plus progressive.
Le bon scénario dépend de l’architecture existante, des contraintes métier, du niveau de dette technique, des compétences disponibles et des objectifs de l’entreprise.
L’audit permet précisément de comparer ces scénarios avant de prendre une décision engageante.
De l’audit à la feuille de route de migration
L’audit permet de définir le périmètre fonctionnel à conserver, les composants à supprimer ou à repenser, les données à reprendre, les intégrations à maintenir et les principaux risques techniques.
C’est également à ce moment qu’il devient pertinent d’étudier les technologies cibles.
Le choix entre .NET, Java, Python, PHP ou une autre stack ne doit pas uniquement dépendre d’une préférence technique. Il doit tenir compte des caractéristiques de l’application, de son évolution future, de son architecture, des contraintes de sécurité et d’exploitation ainsi que des compétences disponibles pour assurer sa maintenance sur le long terme.
La feuille de route peut ensuite organiser la migration en plusieurs lots afin de limiter les risques et d’éviter une bascule brutale lorsque celle-ci n’est pas nécessaire.
L’audit permet aussi d’obtenir un chiffrage plus fiable
Transformer une contrainte technique en projet de modernisation
Sans audit, l’estimation d’une migration repose essentiellement sur des hypothèses.
Or deux applications WinDev comportant un nombre comparable d’écrans peuvent représenter des charges de migration très différentes.
La complexité peut se trouver dans les traitements métier, les interfaces avec des systèmes tiers, la base de données ou simplement dans le niveau de documentation de l’existant.
Un audit préalable permet donc de construire une estimation à partir d’éléments techniques concrets plutôt que d’un périmètre approximatif.
Pour l’entreprise, cela signifie une meilleure visibilité sur le budget, les délais et les ressources nécessaires.
C’est aussi l’occasion de revoir l’expérience utilisateur, l’architecture applicative, les interfaces avec le système d’information, la sécurité, les performances et les possibilités d’évolution futures.
Certaines fonctionnalités historiques peuvent être simplifiées. D’autres peuvent être automatisées. Des processus auparavant disponibles uniquement depuis une application desktop peuvent devenir accessibles depuis un navigateur ou une interface mobile.
La migration devient alors un véritable projet de modernisation du système d’information.
Mais cette modernisation doit partir d’une compréhension précise de l’existant.
Vous envisagez de migrer une application WinDev ?
L’objectif est d’établir une cartographie de l’existant, d’identifier les dépendances et les risques, d’évaluer les différents scénarios de modernisation et de construire une feuille de route adaptée à votre environnement.
Vous disposez ainsi d’éléments concrets pour décider s’il est préférable de maintenir, moderniser ou migrer votre application, et dans quelles conditions mener le projet.
Vous avez une application WinDev existante et souhaitez étudier sa migration ?
Contactez ETC pour échanger sur votre environnement et organiser un premier cadrage du
Recevez notre newsletter et ne manquez jamais nos conseils !
ETC est une entreprise spécialisée dans les services de développement et de maintenance des solutions WinDev. Nous mettons à votre service notre expertise de plus de 26 ans pour mener à bien vos projets.
Euro Tech Conseil SARL au Capital de : 120 000 €
ADRESSE : 35 Rue de la Grange aux Belles, 75010 Paris
SIREN : 429886542 | Code APE : 6201Z | N° TVA : FR18429886542
N° d’existence pour la formation professionnelle : 11754128275 | Assurances CIC Pro ACAJOU SIGNATURES B1 6526087.