Migration WinDev vers .NET ou le Web : les 5 erreurs que nous avons faites (et comment les éviter)
Migrer un logiciel WinDev vers une autre technologie, c'est relativement simple sur le papier. Jusqu'au moment où il faut que tout fonctionne réellement.
Chez Dev-Booster, ça fait plus de 20 ans qu'on travaille avec WinDev.
On a développé des logiciels métier, des applications de gestion, des outils de facturation, de gestion commerciale ou encore de gestion de stocks.
Aujourd'hui, on accompagne aussi des entreprises et des éditeurs qui souhaitent quitter WinDev pour passer sur des technologies comme C#, .NET, React, Next.js ou Symfony.
Avec les outils actuels, et notamment l'IA, certaines étapes vont beaucoup plus vite qu'avant.
Reproduire une interface WinDev en React ou convertir un traitement WLangage en C# peut parfois se faire en quelques minutes.
Mais il y a une différence entre avoir du code qui fonctionne et avoir un logiciel qui fonctionne correctement.
Et ça, on l'a appris sur nos projets.
J'ai récemment demandé à mon équipe de me faire un retour sur les principales difficultés rencontrées lors de nos migrations.
Plusieurs points sont revenus, parfois avec des exemples très concrets.
Voici les cinq erreurs qu'on essaie désormais d'éviter.
1. Vouloir tout migrer d'un seul coup
C'est tentant.
On récupère le code existant, on commence à convertir les fenêtres et on avance aussi vite que possible.
Sauf qu'un logiciel métier, ce n'est pas une succession de fenêtres indépendantes.
Prenons un logiciel de gestion commerciale.
La fiche article est utilisée un peu partout : devis, commandes, factures, stocks, statistiques…
Si on commence à migrer tous ces modules en parallèle, on se retrouve rapidement avec des dépendances dans tous les sens.
Et quand quelque chose ne fonctionne pas, difficile de savoir d'où vient le problème.
C'est notamment un point que Mathieu a soulevé lors de notre échange.
Aujourd'hui, on préfère avancer par blocs fonctionnels cohérents.
On commence par identifier les dépendances, puis on définit un ordre logique.
Par exemple, on va d'abord s'assurer que les articles et les clients fonctionnent correctement avant de s'attaquer aux commandes et à la facturation.
Chaque partie peut être testée et validée avant de passer à la suivante.
C'est parfois moins spectaculaire au démarrage, mais on gagne énormément en maîtrise sur la suite du projet.
2. Oublier les règles métier cachées dans le code
C'est probablement le point qui m'inquiète le plus dans une migration.
Un logiciel WinDev qui a 15 ans contient rarement uniquement les fonctionnalités prévues au départ.
Il a évolué avec l'entreprise.
Des contrôles ont été ajoutés, des exceptions ont été créées, certains traitements ont été modifiés pour répondre à des besoins très particuliers.
Et tout ça n'est pas forcément documenté.
Prenons un exemple simple.
Dans une application de gestion, un client ne doit peut-être pas pouvoir dépasser un certain encours.
Sauf s'il bénéficie d'une autorisation particulière.
Ou uniquement pour certains types de commandes.
Ce genre de règle peut être caché dans un traitement de fenêtre, une procédure ou un événement de champ.
Lorsqu'on migre, il est assez facile de reproduire la fenêtre, les champs et les boutons.
Mais si on oublie une condition métier, le logiciel ne fonctionne plus exactement comme avant.
Le problème, c'est que cette anomalie peut passer complètement inaperçue pendant les premiers tests.
Une interface identique ne garantit pas un fonctionnement identique.
C'est aussi une limite qu'on rencontre parfois avec les outils d'IA : ils peuvent reproduire correctement une partie du code tout en passant à côté de certains contrôles.
On essaie donc de prendre le problème dans l'autre sens.
Avant de migrer un module, on analyse ses traitements pour en extraire les règles métier.
On peut s'aider de l'IA pour les répertorier, mais il faut ensuite les vérifier et les confronter à l'utilisation réelle du logiciel.
C'est un travail moins visible que le développement d'une belle interface.
Mais c'est souvent ce qui fait la différence entre une migration réussie et une application qui multiplie les anomalies.
3. Ne pas tenir compte des particularités de WinDev
Quand on travaille depuis longtemps avec WinDev, on finit par oublier à quel point certains de ses mécanismes sont spécifiques.
Je pense notamment à la gestion des événements.
Dans WinDev, on peut avoir des traitements exécutés à l'initialisation d'une fenêtre, à l'entrée dans un champ, à sa sortie, lors d'une modification ou encore à la sélection d'une ligne.
Et ces traitements sont parfois essentiels au fonctionnement du logiciel.
Nathan nous a notamment remonté des difficultés liées aux sorties de champs et aux événements particuliers.
Prenons un contrôle effectué lorsqu'un utilisateur quitte un champ.
Dans WinDev, on peut vérifier une valeur, afficher un message et empêcher la poursuite de certaines opérations.
Lorsqu'on passe sur une application web, ce fonctionnement n'est pas forcément transposable tel quel.
Il faut réfléchir à la manière de reproduire le comportement attendu avec les événements et les mécanismes du framework utilisé.
Parfois, cela implique aussi de déplacer une partie des contrôles côté serveur.
On ne peut pas se contenter de traduire le code ligne par ligne.
Il faut comprendre pourquoi le traitement existe, à quel moment il doit être exécuté et quelles conséquences il peut avoir sur les autres fonctionnalités.
C'est précisément là que notre expérience de WinDev est utile.
Quelqu'un qui découvre le WLangage peut comprendre le code, mais passer à côté de certaines subtilités du fonctionnement de l'application.
4. Ne pas suffisamment tester ce qui a été développé
C'est un point sur lequel on a aussi dû faire évoluer nos habitudes.
Aujourd'hui, on peut produire une interface complète très rapidement.
Le problème, c'est qu'on peut facilement avoir l'impression qu'une fonctionnalité est terminée parce que l'écran ressemble à ce qu'on attendait.
Mais quand on commence à réellement l'utiliser, c'est parfois une autre histoire.
Un bouton ne déclenche pas le bon traitement.
Un champ n'est pas correctement mis à jour.
Une modification n'est pas enregistrée.
Un calcul ne tient pas compte d'un cas particulier.
Ou une fonctionnalité marche très bien lorsqu'on crée un enregistrement, mais plus du tout lorsqu'on le modifie.
On a donc renforcé notre approche des tests.
Et surtout, on essaie de tester des parcours complets, pas uniquement des fonctionnalités isolées.
Pour une commande client, par exemple, il ne suffit pas de vérifier que la fenêtre s'ouvre.
Il faut sélectionner un client, ajouter des articles, modifier les quantités, appliquer une remise, enregistrer la commande, puis la rouvrir pour vérifier les informations.
Et recommencer avec des cas particuliers.
L'automatisation nous aide beaucoup sur ce sujet.
On utilise notamment des outils capables de naviguer dans les applications pour exécuter des scénarios de tests.
Mais il reste indispensable d'avoir une validation humaine, notamment pour les règles métier.
Car un test automatisé peut parfaitement confirmer qu'une application respecte une règle… alors que cette règle a été mal comprise dès le départ.
5. Négliger les tests après déploiement et la sécurité
C'est une autre difficulté remontée par Nathan.
Une application peut très bien fonctionner dans notre environnement de développement et rencontrer des problèmes une fois déployée.
Une configuration différente, un problème de droits, une connexion à la base de données ou une dépendance manquante peuvent suffire à bloquer une fonctionnalité.
On essaie donc de systématiser des vérifications après chaque déploiement.
Ce sont ce qu'on appelle des smoke tests.
L'idée est assez simple : vérifier rapidement que les fonctions essentielles sont toujours opérationnelles.
Connexion, navigation, consultation, création et modification de données…
Ce n'est pas une campagne de tests complète, mais cela permet de détecter rapidement les problèmes les plus bloquants.
Il y a également un autre sujet à ne surtout pas négliger : la sécurité.
Quand on migre une application WinDev Windows vers une application web, on change parfois complètement son exposition.
Une application historiquement utilisée sur un réseau interne peut désormais être accessible depuis un navigateur, potentiellement depuis Internet.
La gestion des sessions, les droits utilisateurs, les accès aux données et les validations côté serveur deviennent donc des points particulièrement importants.
Nous intégrons aussi des contrôles de sécurité et des analyses de vulnérabilités dans notre démarche.
L'objectif n'est pas simplement que le nouveau logiciel fonctionne comme l'ancien.
Il faut aussi qu'il soit adapté à son nouvel environnement.
Une sixième erreur : vouloir profiter de la migration pour tout refaire
Celle-ci mérite aussi qu'on en parle.
Lorsqu'on reprend un logiciel développé depuis plusieurs années, les utilisateurs ont souvent une liste d'améliorations en tête.
Et c'est parfaitement compréhensible.
Puisqu'on refait la fenêtre des commandes, pourquoi ne pas modifier son fonctionnement ?
Puisqu'on reprend la gestion des articles, pourquoi ne pas ajouter de nouveaux champs ?
Et tant qu'on y est, pourquoi ne pas revoir entièrement la facturation ?
Le problème, c'est qu'on finit par ne plus savoir ce qui relève de la migration et ce qui relève de nouvelles fonctionnalités.
Mathieu a justement insisté sur ce point : il faut bien cadrer ce qu'on reprend de l'existant et ce qu'on souhaite faire évoluer.
Aujourd'hui, on essaie de distinguer clairement les deux.
Une migration peut être une excellente occasion de simplifier certaines choses, mais chaque évolution doit être identifiée et chiffrée.
Cela évite les mauvaises surprises, aussi bien pour le client que pour l'équipe de développement.
Ce que l'IA a changé dans notre manière de migrer
Je ne vais pas dire que l'intelligence artificielle rend les migrations automatiques.
Ce serait faux.
En revanche, elle nous permet d'accélérer plusieurs étapes qui demandaient auparavant beaucoup de temps.
L'analyse de certains traitements WLangage, la génération de premières interfaces, la conversion de portions de code ou encore la préparation des tests sont devenues beaucoup plus rapides.
Et c'est particulièrement intéressant pour les entreprises qui disposent de logiciels importants, avec plusieurs dizaines ou centaines de fenêtres.
Mais il faut garder une chose en tête.
L'IA peut accélérer le développement. Elle ne connaît pas automatiquement les règles métier de votre entreprise.
Et elle ne peut pas garantir, à elle seule, que votre nouvelle application fonctionne exactement comme l'ancienne.
C'est pour cette raison que nous continuons à consacrer beaucoup d'attention à l'analyse, au découpage fonctionnel et aux tests.
L'intérêt est de profiter de cette accélération sans sacrifier la qualité.
Comment nous abordons les migrations aujourd'hui
Avec le recul, je pense que notre plus grand avantage chez Dev-Booster est de connaître les deux côtés.
Nous avons passé plus de 20 ans à développer avec WinDev.
Nous connaissons ses traitements, son fonctionnement événementiel, ses particularités et les problématiques liées à HFSQL.
Et nous travaillons désormais également avec C#, .NET, React, Next.js, Symfony et des bases de données standards comme PostgreSQL ou SQL Server.
Cela nous permet d'aborder les projets avec une bonne compréhension de l'existant, tout en proposant une architecture adaptée aux besoins futurs.
Avant de commencer une migration, nous cherchons donc à comprendre le fonctionnement du logiciel, identifier les dépendances et définir précisément ce qui doit être conservé.
Nous réfléchissons ensuite à la stratégie la plus pertinente.
Parfois, une migration progressive est possible.
Dans d'autres situations, une refonte plus importante est préférable.
Et dans certains cas, il peut même être pertinent de conserver temporairement certaines parties de l'application existante.
Il n'existe pas de méthode universelle.
Un logiciel utilisé par quelques collaborateurs ne présente pas les mêmes contraintes qu'une application commercialisée auprès de plusieurs centaines de clients.
Ce qui compte, c'est de choisir une approche adaptée au projet, à son budget et aux contraintes de l'entreprise.
Vous envisagez de quitter WinDev ?
Si vous utilisez WinDev depuis plusieurs années et que vous réfléchissez à une migration vers .NET ou le Web, le plus important est de commencer par évaluer votre existant.
Combien de fenêtres votre logiciel comporte-t-il ?
Quelles fonctionnalités sont réellement utilisées ?
Quelles sont les dépendances avec HFSQL ?
Et surtout, quelles sont les contraintes métier que vous ne pouvez pas vous permettre de perdre ?
Nous accompagnons les entreprises et les éditeurs dans cette démarche.
Si vous avez un projet de migration, je vous propose d'en discuter pendant 30 minutes pour faire un premier point sur votre application et les possibilités envisageables.