Migrer WebDev et WinDev Mobile : sites, applications SaaS et applications terrain
WebDev et WinDev Mobile partagent le WLangage avec WinDev, mais leurs migrations posent des questions propres : référencement, sessions et serveur d'application payant d'un côté ; hors ligne, synchronisation et terminaux de l'autre. Voici ce qui change par rapport à une application desktop. La méthode générale reste celle de notre guide de la migration WinDev.
WebDev : ce qui est spécifique
Le serveur d'application et son coût
Une application WebDev s'exécute sur le serveur d'application WEBDEV. D'après une vidéo de PC SOFT analysée par Louis Planquart le 30 juillet 2026, PC SOFT facture ce serveur selon le nombre de cœurs, la quantité de mémoire et le nombre de serveurs, là où les applications WinDev passent à la session1. Conséquence directe : ajouter un serveur pour la haute disponibilité, ou de la mémoire pour absorber un pic de trafic, modifie la facture. Dans sa simulation du 14 septembre 2026, Dev-Booster retient un serveur WEBDEV à 4 490 € HT par an, à côté de 100 sessions à 290 €, soit 33 490 € HT par an2. Sur une stack web ouverte, vous dimensionnez les serveurs sur le trafic, sans clause de licence à relire.
Le référencement
Pour un site public construit en WebDev, la migration est un projet SEO autant qu'un projet technique :
- inventorier toutes les URL indexées et leur trafic ;
- établir un plan de redirections 301 exhaustif, testé avant la bascule ;
- reprendre les balises (title, meta, données structurées) et le contenu ;
- choisir un rendu côté serveur ou statique pour les pages publiques ;
- surveiller l'indexation et les erreurs pendant plusieurs semaines après la bascule.
Les sessions et l'état
Les applications WebDev s'appuient souvent sur un état de session côté serveur, des contextes de page et des variables globales. Une architecture moderne préfère des API sans état, avec une authentification par jeton et un état explicite. La rétro-documentation sert d'abord à cela : identifier ce qui est stocké en session, et pourquoi, avant de dessiner la nouvelle API.
La trajectoire SaaS pour les éditeurs
Beaucoup d'éditeurs ont construit en WebDev un portail client ou une version web de leur logiciel. La migration est l'occasion de passer à une architecture SaaS multi-tenant : les nouveaux clients signent sur la nouvelle plateforme pendant que le parc existant migre par vagues. Notre cible privilégiée : Java/Spring et Angular sur Google Cloud, avec PostgreSQL sur Cloud SQL ou AlloyDB.
Pour l'ordre de grandeur, Smartshift écrit, sur une page mise à jour le 24 juillet 2026 : « un chantier ciblé (sortir la base, basculer un site WebDev) se compte en semaines ; la migration d'une application de gestion se compte en mois, par briques »3. Un portail WebDev isolé relève du premier cas. Dès que le site porte la logique du logiciel de gestion, comptez en mois.
WinDev Mobile : ce qui est spécifique
Le hors ligne et la synchronisation
Les applications WinDev Mobile servent souvent sur le terrain : tournées, inventaires, prise de commande, interventions. Elles doivent fonctionner sans réseau, parfois toute une journée. La base locale et la synchronisation avec le serveur sont le cœur du sujet :
- quelles données embarquer sur le terminal, et avec quelle fraîcheur ;
- comment résoudre les conflits quand deux terminaux modifient la même donnée ;
- comment reprendre une synchronisation interrompue sans doublon.
Le retour d'expérience de Dev-Booster sur NomadBiz, un logiciel de vente itinérante2, illustre l'enjeu : l'application devait continuer à fonctionner à 100 % hors connexion, ce qui a conduit l'équipe à une base locale SQLite, avec .NET MAUI / Blazor Hybrid pour cible4. Notre cible par défaut est Flutter (voir plus bas). La question que Dev-Booster a dû trancher, quelles données vivent sur le terminal et comment elles reviennent au serveur, se pose à l'identique quelle que soit la cible.
Les terminaux et les périphériques
Terminaux durcis, douchettes, imprimantes mobiles, lecteurs de cartes : l'inventaire matériel se fait dès l'audit du patrimoine. Il conditionne la cible et le calendrier de renouvellement du parc.
Flutter, notre cible par défaut
Pour le mobile terrain, nous recommandons Flutter : une seule base de code pour Android, iOS et, si besoin, le desktop ; une gestion du hors ligne appuyée sur une base locale ; un écosystème de plugins pour les périphériques courants. Nous avons décrit ailleurs ce que Dart et Flutter apportent aux agents locaux sur mobile, un sujet voisin de celui du terrain sans réseau. Le back-end, lui, rejoint l'architecture du reste du SI (Java/Spring ou .NET, PostgreSQL) ; la matrice complète figure dans notre comparatif des stacks cibles.
Ce qui ne change pas
La méthode reste celle de WinDev : extraction des règles avant toute réécriture, spécifications validées, réécriture par agents module par module, golden master inversé, bascule progressive. Pour le mobile, le golden master inclut des scénarios de synchronisation ; pour le web, il inclut les parcours complets et les redirections. Les données rejoignent PostgreSQL dans les deux cas. Le détail des six étapes est dans notre méthode Software Factory 10x.
Questions fréquentes
Peut-on migrer WebDev sans perdre son référencement ?
Oui, avec un plan de redirections exhaustif, une reprise des balises et un suivi de l'indexation après bascule.
Faut-il réécrire le back-end et l'application mobile ensemble ?
Pas forcément. On peut exposer une API sur la nouvelle base, puis migrer l'application mobile ensuite.
Flutter gère-t-il les douchettes et imprimantes mobiles ?
Les périphériques courants disposent de plugins ; les terminaux spécifiques demandent parfois un développement natif ciblé, à identifier dès l'audit.
Une PWA peut-elle remplacer une application WinDev Mobile ?
Pour des usages connectés et légers, oui. Pour un hors ligne prolongé et des périphériques, une application Flutter est plus sûre.
Passer à l'action
Le choix de la cible web ou mobile se fait avec la matrice de notre comparatif des stacks cibles. Pour la vue d'ensemble, lisez notre guide de la migration WinDev. Le Diagnostic 10x, trente minutes et un rapport en dix points, est le point d'entrée ; l'audit de votre patrimoine WebDev ou WinDev Mobile vient ensuite, comme première étape de la méthode.
Sources
- Louis Planquart, PC SOFT confirms its session fee (analyse d'une vidéo de PC SOFT) — louisplanquart.fr, 30 juillet 2026.
- Dev-Booster, Comment Windev nous a fait économiser 33490 euros ! — dev-booster.com, 14 septembre 2026.
- Smartshift, Migration PC SOFT : quitter WinDev — smartshift.fr, page mise à jour le 24 juillet 2026.
- Dev-Booster, Feuilleton de l'été, épisode 3 — dev-booster.com, 14 août 2026.
Votre site WebDev ou votre application terrain WinDev Mobile a une trajectoire de sortie : parlons-en
Échanger avec SFEIRArticles similaires
Migration WinDev : réécrire vos applications PC SOFT avec l'IA, sans big bang
Une migration WinDev se joue sur deux chantiers : retrouver les règles métier enfouies dans vingt ans de fenêtres, puis prouver que la nouvelle application fait la même chose que l'ancienne. Méthode SFEIR en six étapes, stack cible, ordres de grandeur et grille rester, geler ou migrer.
WinDev vers Java, .NET, TypeScript ou Flutter : comment choisir sa stack cible
Nous sommes sous Windows, donc .NET : le réflexe tombe parfois juste, mais il saute l'examen. SI existant, desktop imposé, mobile terrain, trajectoire SaaS, volumétrie : notre grille pour choisir entre Java/Spring + Angular, .NET, TypeScript et Flutter, avec PostgreSQL comme socle commun.
Migrer WinDev avec la Software Factory 10x : la méthode SFEIR en six étapes, de l'audit à la bascule
Six étapes, un livrable vérifiable au bout de chacune, trois gates tenues par des humains et l'exécution confiée aux agents Claude Code : comment SFEIR mène une migration WinDev sur son SDLC à onze phases, de l'audit du patrimoine à la bascule.
HFSQL vers PostgreSQL : migrer les données d'une application WinDev sans perte
Migrer une base HFSQL vers PostgreSQL sans perte : transposer le schéma, déclarer les clés que le code gardait implicites, nettoyer avant de migrer, répéter les migrations à blanc jusqu'à deux rapports de conformité sans écart, faire tourner WinDev sur PostgreSQL, puis basculer.