// architecture de migration

Migrer WebDev sans réintroduire une dépendance éditeur

React, Angular, Vue : fuir PC SOFT pour tomber dans le cycle de versions d'un autre éditeur, ce n'est pas une migration — c'est un déménagement. Il existe une stack web moderne, stable et sans propriétaire : htmx + Web Components natifs + un backend Go ou C#. Voici pourquoi elle est la cible naturelle pour les applications issues de WebDev.

Première question : WebDev ou WinDev desktop ?

La réponse détermine toute la stratégie. Ce sont deux migrations différentes, avec des contraintes radicalement opposées.

La suite de cet article concerne WebDev.

Pourquoi pas React, Angular ou Vue ?

La raison de quitter WinDev est précisément d'échapper à la dépendance envers un éditeur. Remplacer PC SOFT par Meta (React), Google (Angular) ou une fondation dont le financement est incertain (Vue) déplace le risque sans l'éliminer. Vos clients l'ont vécu avec WinDev — ils seront sensibles à cet argument.

Le cycle de versions des frameworks JavaScript est réel et documenté : une application Angular 12 non maintenue n'est plus supportée aujourd'hui. Le coût de ces migrations "de framework" est exactement le même type de rente que celle que vos clients fuient chez PC SOFT, juste avec un nom différent dessus.

La stack : htmx + Web Components + Go ou C#

htmx : le modèle serveur, pas le modèle client

htmx est une bibliothèque de 14 Ko — code source lisible, zéro dépendance, zéro build, zéro npm. Son principe : les requêtes partent du navigateur via des attributs HTML, le serveur renvoie directement du HTML, le fragment est injecté dans la page. Pas d'état côté client, pas de binding, pas de Virtual DOM.

<input type="search" name="q"
       hx-get="/clients/liste"
       hx-trigger="input changed delay:300ms"
       hx-target="#resultats"
       placeholder="Rechercher un client…">

<div id="resultats"></div>

Le clic (ou la frappe) appelle votre backend, qui interroge la base et renvoie le fragment HTML tout rendu. Pour un développeur WebDev, c'est le modèle mental le moins dépaysant : la logique métier vit côté serveur, exactement comme avant — sauf que le serveur est votre code, pas une boîte noire PC SOFT.

Web Components : les superchamps du web standard

Pour les quelques éléments qui exigent de l'interactivité locale — tables éditables complexes, plannings, sélecteurs à saisie enrichie — les Web Components natifs sont l'équivalent conceptuel des superchamps WinDev. Un composant encapsulé, réutilisable, défini une fois et utilisable dans toutes vos pages comme n'importe quelle balise HTML. Standard W3C, sans bibliothèque externe.

<!-- utilisation dans n'importe quelle page -->
<table-gestion
  source="/api/commandes"
  colonnes="ref,client,montant,statut"
  editable="statut">
</table-gestion>

htmx couvre 90 % des écrans de gestion (listes, fiches, formulaires CRUD). Les Web Components prennent en charge les quelques composants riches qui nécessitent un état local dans le navigateur. Les deux cohabitent sans conflit, sans npm, sans pipeline de build.

Le backend : Go ou C# selon votre contexte

htmx a besoin d'un serveur qui reçoit les requêtes et renvoie des fragments HTML. Ce rôle est conceptuellement identique à celui du serveur d'application WebDev — sauf que c'est votre code, sans licence par session.

Go produit un exécutable autonome de quelques mégaoctets, sans runtime externe, qui tient des milliers de connexions simultanées sur une petite VM. C# avec ASP.NET Core minimal API suit exactement la même logique, en mode self-contained — si vos clients sont dans une culture Microsoft, c'est la transition la plus naturelle.

Le serveur d'application WebDev avec sa facturation par session disparaît. Il est remplacé par un binaire que vous compilez et que vous déployez où vous voulez : chez le client en service Windows à côté de son SQL Server, sur votre infra cloud, ou les deux.

Ce que cette architecture ne résout pas

Honnêteté oblige : cette stack a des limites à connaître avant de la proposer à un client.

• Les états denses côté client — un planning drag & drop complexe, un éditeur de documents riche ou une carte interactive en temps réel ne sont pas dans le domaine de prédilection de htmx. Ce n'est pas son cas d'usage. Pour ces écrans spécifiques, un composant React ou une bibliothèque dédiée peut coexister sans contaminer le reste de l'application.
• Les applications desktop pur — ports série, impression directe, périphériques USB, accès au système de fichiers local : WebDev ne les utilisait pas, mais si certains modules de votre application WinDev en dépendent, la cible web ne les couvrira pas sans passer par l'API Web (FileSystem Access, Web Serial…) ou une solution desktop distincte.
• Les équipes habituées aux SPAs — si les développeurs de votre client ont dix ans de React, la transition vers le modèle "serveur renvoie du HTML" demande un changement de paradigme réel. Ce n'est pas un obstacle technique, c'est un facteur humain à intégrer dans le chiffrage.

Pourquoi cette stack est cohérente avec la promesse Wxit

La raison pour laquelle vos clients fuient WinDev est fondamentalement une question de contrôle : ils ne veulent plus dépendre d'un éditeur pour accéder à leurs propres applications. Une stack htmx + Web Components + Go/C# est peut-être la réponse la plus honnête à cette attente : elle repose entièrement sur des standards ouverts (W3C, HTTP, SQL) et sur des outils dont le code source vous appartient.

Zéro dépendance à un éditeur de framework. Zéro cycle de montées de version imposées. Zéro licence par session. Un navigateur, un serveur, une base de données — et du code qui vous appartient pour toujours.