Migrer une application WinDev vers une technologie moderne

Votre application WinDev tourne en production depuis plusieurs années. Elle couvre plusieurs dizaines de postes, un ou deux processus métier critiques, et repose sur une base HFSQL construite au fil du temps. Un seul développeur, souvent le fondateur du projet ou un prestataire historique, en connaît vraiment la structure interne.

Cette page répond à quatre questions dans l'ordre où elles se posent réellement pour qui envisage de migrer une application WinDev : que garde-t-on, vers quoi, comment, combien. Elle s'adresse aux dirigeants qui recherchent une alternative WinDev fiable, dans une logique de refonte d'application WinDev progressive plutôt que de big-bang.

Le sujet concerne autant la direction générale, qui doit sécuriser la continuité d'activité, que la direction des systèmes d'information, qui doit arbitrer entre maintenance, migration partielle et refonte complète. Les deux angles se rejoignent sur un même besoin : une lecture précise et honnête de l'existant avant toute décision, plutôt qu'une estimation approximative fondée sur le seul nombre de postes.

Pourquoi les applications WinDev arrivent en fin de cycle

Une application WinDev n'atteint pas sa fin de cycle pour une seule raison. Dans les dossiers de migration WinDev que nous observons, quatre causes reviennent, souvent combinées.

• Cause économique : le nouveau modèle de licence de PC SOFT modifierait, selon les annonces publiques de l'éditeur, le coût de possession de l'environnement de développement et d'exécution, ce qui pousse à recalculer le retour sur investissement du maintien en l'état.
• Cause humaine, la plus fréquente dans les dossiers que nous traitons : le développeur historique qui maîtrise l'application n'est pas remplaçable au même niveau de connaissance. Son départ, sa retraite ou sa simple indisponibilité bloque toute évolution.
• Cause technique : compatibilité limitée avec les environnements récents, interfaces vieillissantes, absence d'API pour connecter l'application à d'autres outils métier.
• Cause stratégique : impossible d'ouvrir un canal web ou mobile sans réécriture. L'application reste confinée au poste de travail alors que les usages se sont déplacés.

Ces quatre causes se combinent rarement de façon isolée. Le départ d'un développeur historique révèle souvent, dans le même mouvement, l'absence d'API et l'impossibilité d'ouvrir un canal mobile que la direction commerciale réclamait depuis longtemps sans pouvoir l'obtenir. C'est cette accumulation, plus qu'un déclencheur unique et brutal, qui pousse la majorité des dirigeants à ouvrir un dossier de migration WinDev plutôt qu'à prolonger indéfiniment la maintenance.

Ce qu'on peut reprendre et ce qu'il faut réécrire

Une migration WinDev réussie commence par un tri précis. Certains éléments constituent un actif réel, d'autres doivent être reconstruits presque intégralement.

Le transcodage du code WLangage reste assisté, jamais totalement automatisé. Une revue humaine valide chaque bloc de logique métier avant son intégration dans la nouvelle base de code.

Les états et impressions méritent une attention particulière. Une application WinDev en production accumule souvent des dizaines d'états personnalisés, générés au fil des demandes métier successives, rarement recensés dans une documentation à jour. Les oublier au moment du chiffrage est l'erreur la plus fréquente que nous corrigeons lors d'un audit de code, bien avant les questions de base de données ou d'interface.

Ce tri n'a pas vocation à dévaloriser le travail réalisé sous WinDev. Les règles métier et les paramétrages qui fonctionnent depuis des années représentent un capital réel, que la migration cherche à préserver et à documenter, pas à effacer au profit d'une réécriture intégrale par principe.

Les 4 trajectoires possibles

Quatre trajectoires couvrent la quasi-totalité des dossiers de migration WinDev. Le choix dépend de l'état du parc, de l'urgence business et du budget disponible.

Le critère déterminant n'est presque jamais technique en premier lieu. Il est budgétaire et organisationnel : quel effort l'entreprise peut-elle engager cette année, quelle capacité de conduite du changement les équipes métier peuvent-elles absorber, et quelle urgence pèse réellement sur la continuité d'activité plutôt que sur le confort de l'équipe informatique.

Ces quatre trajectoires ne s'excluent pas : beaucoup de projets démarrent par la première pour lever l'urgence, puis avancent vers la troisième ou la quatrième au rythme du métier. Le choix se construit après l'audit de code, pas avant.

Les trajectoires 1 et 3 se combinent d'ailleurs fréquemment : sortir de HFSQL en premier lieu simplifie ensuite chaque module migré dans le cadre d'une trajectoire progressive, puisque la nouvelle base est déjà en place avant même de toucher à l'interface. Cet enchaînement réduit le risque perçu par les équipes, qui voient un premier résultat concret avant de s'engager sur la suite.

Migration progressive : le pattern de cohabitation

La crainte la plus fréquente face à une migration WinDev n'est pas le coût, c'est l'arrêt d'activité. Le pattern de cohabitation répond directement à cette objection.

Concrètement, l'ancienne application WinDev et la nouvelle plateforme fonctionnent en parallèle, module par module. Un module migré, la facturation par exemple, tourne dans la nouvelle technologie pendant que le reste de l'application continue de s'exécuter sous WinDev. Les deux systèmes partagent la même base de données ou se synchronisent par un mécanisme d'échange défini au démarrage du chantier, selon la trajectoire retenue.

Cette synchronisation garantit que les utilisateurs qui travaillent encore sur l'ancien module voient les mêmes données que ceux déjà passés sur le nouveau. Aucune double saisie, aucune divergence entre deux bases qui vivraient leur vie séparément.

Le retour arrière reste possible tant que l'ancien module n'est pas désactivé. Si un module migré présente un défaut bloquant en production, l'équipe réoriente temporairement les utilisateurs vers l'ancienne version le temps de la correction. Cette réversibilité, plus que la vitesse d'exécution du projet, est ce qui rassure les directions générales avant de lancer un chantier de cette ampleur.

Chaque module migré passe par une phase de recette en parallèle avant la bascule définitive des utilisateurs. Les deux versions tournent simultanément sur un périmètre restreint, avec un groupe d'utilisateurs pilotes qui valide le comportement métier avant l'ouverture au reste des équipes. Cette étape, souvent sous-estimée dans les plannings, conditionne la confiance des équipes terrain dans la suite du projet.

Coût et délai par taille de parc

Le chiffrage d'une migration WinDev dépend de trois facteurs, avant même de parler de taille de parc.

• Le volume de code WLangage à transcoder ou réécrire, qui dépend du nombre d'écrans et de traitements, pas seulement du nombre de postes.
• L'état de la base HFSQL : nombre de tables, présence de bases décentralisées par agence ou par site, qualité des données existantes.
• La trajectoire retenue : sortir de HFSQL seule coûte nettement moins cher qu'une refonte complète, pour un même parc.

L'audit de code gratuit se déroule sur 5 jours ouvrés : lecture du code WLangage existant, inventaire des écrans et des états, évaluation de la base HFSQL, puis restitution d'une trajectoire argumentée avec une fourchette de durée. Aucun engagement n'est requis pour en bénéficier.

Ces durées restent indicatives : seul un audit de code permet un chiffrage fiable. L'audit gratuit de 5 jours produit une estimation détaillée, poste par poste, avant tout engagement.

Et si vous ne migriez pas ?

Migrer n'est pas systématiquement la bonne décision. Trois situations nous amènent à déconseiller un chantier de migration WinDev.

• Le parc est amorti et stable : aucune évolution fonctionnelle prévue, l'application remplit son rôle sans tension, le développeur historique reste disponible.
• Le parc compte moins de 15 postes : le retour sur investissement d'une migration complète est rarement atteint sur un périmètre aussi restreint.
• L'application est en fin de vie métier à horizon 2 ans : un changement d'organisation, de métier ou de système d'information global rend la migration inutile avant son terme.

Ces trois situations partagent un point commun : le coût d'une migration WinDev dépasserait la valeur qu'elle créerait à court terme. Le rôle d'un partenaire sérieux est de le dire clairement lors de l'audit, plutôt que de vendre un chantier qui ne se justifie pas encore.

Dans ces trois cas, un audit de code sert surtout à documenter l'existant et à sécuriser la transition qui suivra, pas à préparer une migration immédiate.

FAQ