Migration WinDev vers le web : la méthode sans big-bang

Votre logiciel métier tourne sous WinDev depuis quinze ou vingt ans. Il encaisse les commandes, calcule les tarifs, pilote l'atelier. La décision de le faire évoluer est prise, ou presque : ce qui paralyse, ce n'est pas le pourquoi, c'est le chantier. On ne peut pas arrêter l'exploitation. Personne d'autre ne connaît le métier. Et tout le monde a en tête une réécriture qui a mal fini. Une migration WinDev vers le web se gagne précisément là : dans une méthode qui n'exige jamais d'arrêter la machine.

Le contexte tient en deux phrases. Depuis le rachat de PC SOFT par Volaris fin 2024, l'écosystème a basculé en abonnement obligatoire, puis une facturation à la session est apparue en juin 2026, au point de valoir à l'éditeur une question au gouvernement publiée au Journal officiel ; nous ne referons pas l'historique ici, il est bien documenté.

La conséquence se mesure : les recherches Google sur « migration windev » ont été multipliées par cinq en juin 2026, passant de 10 à 50 requêtes mensuelles (notre mesure via DataForSEO, juillet 2026). Faites le test : la page de résultats renvoie de la documentation éditeur sur les montées de version et des fils de forum. Pas de méthode de sortie. La voici.

Avant de chiffrer : les cinq prérequis

Un devis de migration établi sans les cinq éléments ci-dessous ne vaut rien, quel que soit le prestataire. Rassemblez-les d'abord.

• Inventaire des modules et de leur usage réel : quels écrans sont ouverts chaque jour, par qui, à quelle fréquence. Les journaux d'exploitation valent mieux que la mémoire collective.
• Volumétrie et qualité des données HFSQL : nombre de tables, de lignes, doublons connus, champs détournés de leur usage d'origine.
• Interfaces avec l'extérieur : imports, exports, EDI, matériel connecté (balances, douchettes, automates). Ce sont elles qui contraignent le calendrier, pas les écrans.
• Utilisateurs pilotes identifiés : deux ou trois personnes qui connaissent les règles métier et acceptent d'essuyer les plâtres des premiers modules.
• Critères de fin de coexistence : à quelles conditions mesurables l'ancienne application aura le droit de s'éteindre.

Ce travail prend quelques semaines et garde sa valeur même si vous différez le projet d'un an : la cartographie reste.

Le big-bang est une faute de gestion, pas un choix technique

Tout réécrire en parallèle, puis basculer d'un coup : sur le papier, c'est propre. Dans les faits, c'est la stratégie au pire historique de l'industrie logicielle. Joel Spolsky l'écrivait dès 2000 dans « Things You Should Never Do, Part I » : la réécriture from scratch est la « single worst strategic mistake », la pire erreur stratégique qu'une entreprise de logiciel puisse commettre. Netscape a passé trois ans à réécrire son navigateur ; le marché ne l'a pas attendu.

L'argument tient en deux points. Pendant une réécriture totale, le produit n'avance plus : chaque demande d'évolution reçoit la même réponse, « ce sera dans la nouvelle version ». Et tout le risque se concentre sur un seul événement, la bascule, en général un week-end, en général sous pression. Si elle échoue, on revient vers un système gelé depuis des mois, face à des utilisateurs qui ont perdu confiance.

Ces fourchettes sont des ordres de grandeur observés sur des reprises de logiciels métier de taille PME, 10 à 100 utilisateurs ; l'inventaire des modules les affine pour votre cas.

Le from scratch garde un domaine de validité : un périmètre réduit, sans exploitation continue à préserver. On a recodé de zéro deux applications interactives d'exposition pour le Centre Pompidou parce qu'elles étaient inutilisables en l'état : rien ne tournait, personne n'attendait de synchronisation. Un logiciel métier utilisé chaque jour par soixante personnes est le cas exactement inverse.

Le strangler fig, expliqué simplement

L'alternative porte un nom : le pattern strangler fig, décrit par Martin Fowler. La métaphore vient du figuier étrangleur, une plante qui germe dans les branches d'un arbre hôte, grandit en s'appuyant sur lui, puis vit de ses propres racines ; l'arbre d'origine finit par disparaître, la silhouette du figuier demeure. Appliqué au logiciel : la nouvelle application pousse module par module autour de l'ancienne, qui continue de fonctionner et s'éteint quand plus rien ne repose sur elle.

Fowler insiste sur un point que les équipes sous-estiment : il faut accepter de construire une architecture de transition, du code de synchronisation destiné à être jeté en fin de projet. Ce n'est pas du gaspillage. C'est le prix de la réduction du risque, et il reste inférieur au coût d'un big-bang raté.

Pendant la coexistence, l'architecture ressemble à ceci :

flowchart TB
    U1["Utilisateurs des modules basculés"]
    U2["Utilisateurs des modules restants"]
    subgraph web["Nouvelle application web"]
        FRONT["Front web"]
        API["API métier en TypeScript"]
        PG[("PostgreSQL")]
    end
    subgraph legacy["Application WinDev existante"]
        WD["Modules WLangage restants"]
        HF[("Base HFSQL")]
    end
    SYNC["Synchronisation des données<br>pendant toute la coexistence"]
    U1 --> FRONT
    FRONT --> API
    API --> PG
    U2 --> WD
    WD --> HF
    HF <--> SYNC
    SYNC <--> PG

Les utilisateurs des modules migrés travaillent dans le navigateur. Les autres restent sur l'application WinDev, sans rien changer à leurs habitudes. La synchronisation maintient HFSQL et PostgreSQL cohérents, dans les deux sens si nécessaire, le temps que dure la transition.

La migration WinDev, étape par étape

1. Auditer l'existant, IA en première lecture

Un logiciel métier de 15 à 25 ans contient des milliers de règles écrites nulle part ailleurs que dans le code WLangage et dans la structure de la base. L'audit les fait remonter : lecture du code assistée par IA pour inventorier fenêtres, procédures, dépendances et règles de gestion, relecture humaine, puis validation avec les utilisateurs clés. Livrable : une cartographie des modules croisée avec leur usage réel, et un plan de migration ordonnancé.

2. Les données d'abord

Les données survivront à toutes les applications ; on les migre donc avant de reconstruire le moindre écran. Schéma PostgreSQL cible, scripts de reprise depuis HFSQL, puis exécutions à blanc répétées : contrôles de volumétrie, sommes de contrôle sur les montants, vérification des liaisons entre tables. L'historique complet est conservé, y compris ce qui semble mort ; c'est souvent lui qu'un contrôle fiscal ou un litige viendra chercher.

3. Reconstruire module par module

Les écrans les plus utilisés d'abord : le gain se voit vite et les utilisateurs pilotes donnent un retour dense. Chaque module reconstruit embarque ses tests de non-régression, qui comparent les sorties de l'ancienne et de la nouvelle application sur des données réelles, pas sur des jeux d'essai. Pendant ce temps, le reste tourne sous WinDev, données synchronisées.

4. Basculer progressivement

Les utilisateurs passent quand leur module est prêt, pas quand tout est prêt. Une équipe bascule, on observe, on corrige, la suivante bascule. Aucun week-end à haut risque. L'ancienne application s'éteint quand les mesures d'usage montrent que plus personne ne s'en sert ; ce critère a été fixé dans les prérequis, il ne se renégocie pas au ressenti en fin de projet. Cette discipline de bascule réversible vaut au-delà des logiciels métier : c'est la même que nous détaillons pour une migration e-commerce.

5. Développer en continu ensuite

Sur une stack web standard, les mises en production deviennent petites, fréquentes et réversibles. Plus de version majeure à racheter tous les trois ans : le logiciel redevient un actif qui évolue au rythme du métier.

Le piège des reprises de code hérité

Sur les reprises de legacy, le point bloquant n'est jamais la syntaxe du langage. Le scénario se répète assez pour qu'on puisse l'écrire à l'avance.

Le symptôme : le chiffrage d'un module central dérape. Typiquement la tarification : quarante branches conditionnelles, des cas particuliers imbriqués, et une équipe qui conclut « ce code est illisible, on simplifiera en réécrivant ».

Le diagnostic : chacune de ces branches est une règle métier vivante. Une remise négociée avec une famille de clients, un arrondi imposé par une réglementation sectorielle, un cas qui ne se déclenche qu'en février. Spolsky décrit ce mécanisme : le vieux code qui semble difforme est du code corrigé, et chaque correction a coûté des semaines d'exploitation réelle. Supprimer ces branches revient à réintroduire les bugs qu'elles corrigeaient.

Le fix : inventaire exhaustif des branches par lecture assistée par IA, quelques jours pour un module central. Puis un atelier de tri avec les utilisateurs clés : règle vivante, règle morte, règle inconnue. Chaque « inconnue » est investiguée avant réécriture. Compter deux à trois semaines pour un module de tarification dense, tests de non-régression compris. C'est long. C'est toujours plus court que trois mois de factures fausses.

Le WLangage n'est pas le problème, le silo l'est

La panique ambiante mélange deux sujets. WinDev n'a pas volé son succès : l'outil a donné à des milliers de PME françaises un logiciel métier sur mesure à une époque où c'était hors de portée, et le WLangage se transpose bien. Des conditions, des calculs, des workflows : tout cela s'exprime en TypeScript sans perte.

Ce qui coûte cher dans une migration, c'est de retrouver la logique quand elle n'est documentée nulle part. Ni spécification, ni tests, parfois plus aucun développeur d'origine : un silo. C'est là que l'IA a changé l'équation économique de ces migrations. Lire des centaines de milliers de lignes de code legacy, en tirer une documentation de l'existant, proposer des cas de tests de non-régression : ce travail coûtait des mois d'ingénieur il y a cinq ans. Ce coût a chuté. Le travail de validation humaine, lui, reste entier, et c'est tant mieux : c'est lui qui protège le métier.

Questions fréquentes sur la migration WinDev

Q: Peut-on convertir automatiquement du WLangage en TypeScript ?

A: Non, pas pour un logiciel métier complet. Des outils de transpilation existent, mais ils reproduisent la structure de l'ancien code sans la documenter ni la tester. L'IA accélère la lecture et la documentation de l'existant ; la logique est ensuite réécrite, puis validée par des tests de non-régression comparant les sorties des deux applications.

Q: Combien de temps dure une migration WinDev vers le web ?

A: Ordre de grandeur pour un logiciel métier de PME : un premier module en production en 2 à 4 mois, une coexistence totale de 12 à 24 mois selon le nombre de modules et d'interfaces externes. Le calendrier précis sort de l'audit initial.

Q: Faut-il arrêter l'exploitation pendant la migration ?

A: Non. Le pattern strangler fig repose sur la coexistence : l'application WinDev continue de tourner pour les modules non migrés, les données restent synchronisées entre HFSQL et PostgreSQL, et l'extinction se fait module par module.

Q: Que devient la base HFSQL ?

A: Elle est migrée vers PostgreSQL, historique complet inclus, via des scripts rejoués à blanc avant toute bascule réelle. PostgreSQL est un standard ouvert : sauvegardes, réplication et compétences disponibles ne dépendent plus d'un éditeur unique.

Q: Rester sur WinDev est-il encore une option ?

A: Oui. Un parc stable, des coûts maîtrisés et une maintenance qui suit peuvent justifier de rester ; migrer par peur pure serait une erreur. Ce qui ne se défend plus en 2026, c'est l'absence de plan B chiffré.

Par où commencer

Pas par un devis de réécriture globale. Par l'audit : quatre à six semaines pour cartographier les modules, mesurer leur usage réel, évaluer la base HFSQL et poser un plan de migration WinDev ordonnancé, premier module candidat inclus. Ce livrable garde sa valeur même si vous décidez d'attendre : il transforme une inquiétude diffuse en décision chiffrée.

L'agence Platane (https://platane.io) conçoit des applications métier web en TypeScript et PostgreSQL, hébergées en France, et pratique la lecture assistée par IA sur les reprises de code hérité. Trente minutes suffisent en général pour qualifier votre situation : prenez rendez-vous ou écrivez à bonjour@platane.io.