Faut-il quitter WinDev ? Les quatre questions qui décident

La question revient dès qu'un nouveau DSI arrive ou qu'un prestataire externe est consulté. La réponse dépend rarement de la technologie elle-même, et presque toujours de quatre facteurs mesurables.

Question 1 : la version est-elle encore supportée ?

L'éditeur PC SOFT publie une version majeure par an et assure le support des versions récentes. Une application sur une version hors support pose trois problèmes : plus de correctifs de sécurité, compatibilité incertaine avec les systèmes d'exploitation récents, et difficulté croissante à trouver de l'aide.

Si vous êtes hors support, la première décision n'est pas de migrer vers une autre technologie : c'est de faire une montée de version. Elle coûte une fraction d'une migration et traite le risque immédiat.

Question 2 : l'application est-elle documentée ?

Pas au sens d'un manuel utilisateur : au sens d'une cartographie des analyses, des traitements, des états et des dépendances, qu'un développeur extérieur peut lire pour reprendre le projet.

Si elle ne l'est pas, ce n'est pas une raison de migrer. C'est une raison de faire un audit de reprise, qui coûte quelques milliers d'euros et qui, accessoirement, est aussi le prérequis de toute migration sérieuse. Migrer une application qu'on ne comprend pas est le meilleur moyen de reproduire ses défauts en pire.

Question 3 : plus d'une personne sait-elle la faire évoluer ?

C'est le vrai risque, et il est indépendant du langage. Une application Java maintenue par une seule personne présente exactement le même risque de continuité qu'une application WinDev dans la même situation.

Le fait que le vivier de développeurs WinDev soit en diminution rend ce risque plus difficile à traiter par le recrutement, ce qui est un argument réel — mais il se traite par un contrat de maintenance avec deux interlocuteurs, pas nécessairement par une migration à plusieurs centaines de milliers d'euros.

Question 4 : l'application répond-elle encore au besoin ?

Si le métier a changé au point que l'application ne couvre plus que la moitié des cas, si les utilisateurs maintiennent des tableurs parallèles pour compenser, si chaque évolution demandée est refusée pour cause de complexité : là, la question de la refonte devient légitime.

Mais notez que ce critère est fonctionnel, pas technique. Il justifierait une refonte même si l'application était écrite dans la technologie la plus moderne.

Le verdict

Si les quatre réponses sont bonnes, migrer revient à dépenser un budget important sans contrepartie fonctionnelle. C'est une décision que nous avons vu prendre, et regretter.

Si deux réponses ou plus sont mauvaises, la migration mérite d'être chiffrée — module par module, avec les deux systèmes en parallèle, jamais en un seul basculement.

Le cas intermédiaire, qui est le plus fréquent

L'application fonctionne mais n'arrive pas à s'intégrer au reste du système d'information. Dans ce cas, la réponse n'est ni maintenir ni migrer : c'est ouvrir. Exposer une API REST sur l'existant permet de brancher un portail moderne, une application mobile ou un outil décisionnel, pour une fraction du coût d'une réécriture — et sans toucher au cœur métier qui, lui, fonctionne depuis quinze ans.