Moderniser une application WinDev legacy sans la réécrire
En bref
- Moderniser une application WinDev legacy ne signifie pas nécessairement la réécrire entièrement.
- Dans la majorité des cas, une approche progressive permet d'améliorer la sécurité, la maintenabilité et l'évolutivité sans interrompre la production. Ce guide explique comment identifier les priorités de modernisation, quelles briques faire évoluer en premier, quelles erreurs éviter, et comment construire une trajectoire réaliste pour une application WinDev existante.
- Approche pragmatique pour faire évoluer l'existant sans big bang
1. Qu’appelle-t-on vraiment une application WinDev “legacy” ?
Une application WinDev est souvent qualifiée de legacy non pas à cause de WinDev lui-même, mais à cause de son contexte d’évolution.
On parle généralement de legacy lorsque :
- l’application est en production depuis plusieurs années
- elle supporte des processus métiers critiques
- plusieurs développeurs se sont succédé
- la documentation est partielle ou obsolète
- certaines décisions techniques ne sont plus maîtrisées.
👉 Point clé :
Une application WinDev legacy fonctionne souvent très bien mais, dans certains cas, devient difficile à faire évoluer proprement.
2. Pourquoi la réécriture complète est presque toujours une mauvaise idée
La tentation classique est de dire : “On repart de zéro.”
Dans la pratique, une réécriture complète entraîne souvent :
- des délais très longs
- des dérives budgétaires
- une perte de connaissance métier implicite
- une régression fonctionnelle à la livraison.
Dans plus de 70 % des projets WinDev, une réécriture complète introduit plus de risques qu’elle n’en supprime.
La modernisation doit viser la réduction du risque, pas sa concentration.
3. Principe fondamental : moderniser par couches
La bonne approche consiste à découpler les sujets et à moderniser par couches indépendantes.
Ordre recommandé :
- Sécurité
- Architecture
- Données
- Déploiement
- Code applicatif
👉 Ce point est essentiel : on ne commence presque jamais par “refactorer tout le code”.
4. Sécuriser l’existant avant de le faire évoluer
Avant toute évolution fonctionnelle, il faut sécuriser l’existant.
Priorités fréquentes :
- chiffrement des bases de données
- sécurisation des connexions (TLS, mTLS si possible)
- suppression des mots de passe en dur
- durcissement réseau
- sauvegardes chiffrées et testées.
👉 Une application WinDev sécurisée est plus simple à faire évoluer, car elle réduit les risques opérationnels.
5. Découpler sans casser : APIs et services
L’un des leviers les plus efficaces est le découplage progressif.
Approche recommandée :
- conserver WinDev comme coeur applicatif
- extraire certaines fonctionnalités sous forme de services (API REST)
- faire communiquer WinDev avec ces services.
Exemples typiques :
- génération de documents
- traitements lourds
- intégration IA
- accès à des systèmes tiers.
WinDev peut rester le poste de pilotage tout en déléguant les responsabilités techniques lourdes.
6. Moderniser la base de données sans changer l’application
La base de données est souvent un excellent point d’entrée.
Actions possibles sans impacter WinDev :
- migration vers une version MariaDB plus récente
- ajout de chiffrement au repos
- activation du TLS côté serveur
- mise en place de rôles SQL clairs
- amélioration des sauvegardes et de la supervision.
👉 Le code WinDev peut rester quasi inchangé, tout en bénéficiant d’un socle beaucoup plus robuste.
7. Rendre le code WinDev plus maintenable (sans tout refondre)
Une fois le socle sécurisé, on peut améliorer le code par petites touches.
Bonnes pratiques efficaces :
- isoler les accès base dans des procédures dédiées
- réduire les dépendances globales
- documenter les zones sensibles
- introduire des conventions claires
- nettoyer progressivement les modules les plus utilisés.
👉 Objectif :
améliorer la lisibilité et la prédictibilité, pas atteindre la perfection.
8. Gérer les environnements proprement (dev / recette / prod)
Les applications WinDev legacy souffrent souvent d’un mauvais cloisonnement.
Modernisation minimale recommandée :
- paramètres externalisés (fichiers de config, tables dédiées)
- certificats et secrets distincts par environnement
- procédures de déploiement documentées
- restauration de base testée régulièrement.
👉 Ce travail est peu visible, mais fondamental.
9. Indicateurs de réussite d’une modernisation WinDev
Une modernisation réussie se mesure par :
- moins d’incidents en production
- des mises en production plus fréquentes
- une meilleure compréhension du système
- une capacité accrue à intégrer de nouvelles briques (IA, web, sécurité).
👉 Si le métier ne voit aucune rupture, c’est bon signe.
10. Erreurs fréquentes à éviter absolument
- vouloir tout moderniser en une seule phase
- introduire trop de nouvelles technologies
- casser l’existant sans filet de sécurité
- négliger la sécurité “parce que c’est interne”
- sous-estimer la valeur de la connaissance métier existante.
👉 Rappel important :
La modernisation est un marathon, pas un sprint.
Conclusion
Moderniser une application WinDev legacy ne consiste pas à la remplacer, mais à la faire évoluer intelligemment.
Une approche progressive permet :
- de réduire les risques
- de sécuriser l’existant
- d’ouvrir la voie à de nouvelles fonctionnalités
- de préserver l’investissement métier.
Chez EloNeva, cette approche pragmatique permet d’accompagner des applications WinDev critiques vers des architectures plus modernes, sans rupture pour les utilisateurs.