Passer vos applications WinDev en mode web / SaaS

Passer une application WinDev en web ne consiste pas à « webiser » des fenêtres : c'est un changement de modèle. Un seul déploiement au lieu de dizaines de postes à maintenir, des utilisateurs qui accèdent au service depuis n'importe où, et pour un éditeur, un modèle économique d'abonnement. Cette page décrit l'architecture cible et les décisions à prendre dans l'ordre.

Desktop ou web : trancher pour de bon

La question mérite d'être fermée en début de projet, car elle conditionne tout : l'équipe, la stack, le budget. Le web s'impose quand l'accès distant est une demande réelle (clients, multi-sites, télétravail), quand le déploiement sur postes est devenu un fardeau, ou quand le modèle commercial évolue vers l'abonnement. Le desktop garde l'avantage pour la saisie intensive au clavier, les périphériques locaux exigeants et les environnements sans réseau fiable.

Le critère du poste de travail est souvent décisif : si vos utilisateurs sont assis devant la même machine toute la journée, le desktop reste défendable. S'ils se déplacent, changent de poste ou travaillent chez vos clients, le web gagne presque toujours.

Dans quels cas éviter le passage au SaaS

Le web n'est pas une évidence pour toutes les applications de gestion. Trois cas où le desktop reste préférable : une saisie intensive au clavier par une équipe formée, sur un poste fixe, où le confort d'un client lourd dépasse celui d'un navigateur ; un besoin fort d'intégration à du matériel local (périphérique de mesure, imprimante spécialisée, lecteur physique) que le web gère moins nativement ; un contexte réseau réellement instable, où le hors-ligne complet serait la norme plutôt que l'exception. Dans ces cas, une modernisation en desktop (.NET) apporte le même bénéfice de sortie de WinDev sans les coûts d'une reconstruction web complète.

Rien n'empêche non plus une trajectoire mixte : un cœur métier desktop pour les usages intensifs, et une couche web limitée à la consultation ou à un portail client restreint. Cette voie intermédiaire évite de reconstruire l'intégralité de l'interface tout en ouvrant l'accès là où il apporte une vraie valeur.

Le bon réflexe, dans tous les cas, est de trancher module par module plutôt qu'au niveau de l'application entière : un même parc combine souvent un cœur de production qui reste desktop et des fonctions périphériques (reporting, consultation, portail partenaire) qui gagnent à passer en web sans attendre le reste.

Architecture cible d'une application métier web

L'architecture standard tient en trois couches indépendantes : une base de données relationnelle (PostgreSQL le plus souvent), une API qui porte l'intégralité des règles métier, et un front web qui ne fait qu'afficher et saisir. Cette séparation, absente du modèle WinDev où la logique vit dans les fenêtres, est précisément ce qui rend l'application durable : chaque couche évolue et se teste séparément.

• La base : schéma normalisé issu de la migration HFSQL, sauvegardes et réplication gérées par des outils standards.
• L'API : le cœur de l'investissement, elle documente enfin vos règles métier et ouvre l'intégration à d'autres outils.
• Le front : React, Vue ou équivalent, remplaçable sans toucher au métier.
• L'authentification : gestion centralisée des comptes, rôles et permissions, avec SSO possible.

Multi-tenant et gestion des droits

Pour un éditeur, la question centrale du SaaS est le multi-tenant : servir tous les clients depuis une même plateforme au lieu d'une installation par client. Deux grands modèles existent : une base par client (isolation maximale, exploitation plus lourde) ou une base partagée avec cloisonnement par identifiant de tenant (exploitation simple, rigueur absolue exigée dans le code). Le choix dépend de vos contraintes réglementaires, de la sensibilité des données et de votre volume de clients.

Bonne nouvelle pour les parcs WinDev existants : la décentralisation actuelle (une base HFSQL par client) se transpose naturellement vers le modèle une-base-par-tenant, puis peut converger vers la base partagée par vagues, client par client, de façon réversible.

Le cas du mode déconnecté

C'est l'objection la plus fréquente au web, et elle mérite une réponse précise plutôt qu'un revers de main. Les applications web modernes savent fonctionner en mode dégradé (PWA, cache local, files de synchronisation), mais ce confort a un coût de développement réel. La bonne pratique : identifier les deux ou trois parcours qui doivent réellement survivre à une coupure réseau, et ne traiter le hors-ligne que pour eux. Traiter toute l'application en mode déconnecté revient à construire deux applications.

Impact sur votre modèle économique

Pour un éditeur, le passage au SaaS change la nature du revenu : de la licence vendue une fois à l'abonnement récurrent. La transition se pilote : les nouveaux clients signent sur la plateforme web, le parc installé migre par vagues, et pendant la transition les deux modèles coexistent. C'est aussi le moment de reprendre la main sur votre exposition aux conditions de licence de vos propres outils de développement : une plateforme web construite sur des technologies ouvertes ne dépend plus d'un éditeur unique.

Ce chantier se chiffre sur pièces : nombre de modules, complexité du métier, exigences d'intégration. L'audit de cinq jours en donne une première trajectoire budgétée.