Migration WebDev :
passer à React et à une API ouverte.

Pourquoi remplacer WebDev ?

WebDev permet de produire rapidement des applications web avec le même WLangage que WinDev. C'est sa force, et c'est aussi sa limite : le code serveur, le code navigateur et l'accès aux données sont mêlés dans les mêmes pages, l'application tourne sur un serveur d'application spécifique, et peu de développeurs web connaissent l'outil. Chaque évolution passe par l'atelier de l'éditeur, à la version que vous possédez.

Une architecture web standard sépare deux choses :

• Le front, en React et TypeScript : l'interface qui s'exécute dans le navigateur, rapide, adaptée au mobile, construite avec des composants réutilisables ;
• L'API, en C# avec ASP.NET Core ou en Node.js : le serveur qui applique les règles métier, contrôle les droits et dialogue avec la base de données.

Ce découpage a un avantage immédiat : la même API peut servir le site web, une application mobile et vos échanges avec d'autres logiciels. Vos règles métier sont écrites une seule fois. Angular reste une alternative à React si votre équipe la connaît déjà : le raisonnement est identique.

Équivalence des concepts WebDev → React

Voici comment les briques d'un projet WebDev se retrouvent dans une architecture React + API.

Exemple : une page WebDev reprise en React

Une fiche client classique : l'utilisateur saisit un code, clique sur « Rechercher », et les champs se remplissent. En WebDev, tout se trouve dans le code serveur du bouton, qui lit directement la base et affecte les champs de la page.

// PAGE_FicheClient · clic sur BTN_Rechercher (code serveur)
HLitRecherchePremier(Client, CodeClient, SAI_Code)
SI HTrouve(Client) ALORS
    SAI_Nom = Client.Nom
    SAI_Ville = Client.Ville
    SAI_Encours = Client.Encours
SINON
    Info("Client introuvable")
FIN

Dans la nouvelle architecture, la lecture de la base passe par un point d'entrée de l'API. Il ne renvoie que les informations utiles à l'écran, et seulement à un utilisateur authentifié.

// API ASP.NET Core · GET /api/clients/{code}
app.MapGet("/api/clients/{code}", async (string code, AppDbContext db) =>
{
    var client = await db.Clients
        .Where(c => c.CodeClient == code)
        .Select(c => new ClientDto(c.Nom, c.Ville, c.Encours))
        .FirstOrDefaultAsync();

    return client is null ? Results.NotFound() : Results.Ok(client);
}).RequireAuthorization();

Le composant React s'occupe uniquement de l'affichage : il appelle l'API, puis affiche la fiche ou le message d'erreur.

type Client = { nom: string; ville: string; encours: number };

export function FicheClient() {
  const [code, setCode] = useState('');
  const [client, setClient] = useState<Client | null>(null);
  const [erreur, setErreur] = useState('');

  async function rechercher(e: React.FormEvent) {
    e.preventDefault();
    const res = await fetch(`/api/clients/${encodeURIComponent(code)}`);
    if (res.ok) { setClient(await res.json()); setErreur(''); }
    else { setClient(null); setErreur('Client introuvable'); }
  }

  return (
    <form onSubmit={rechercher}>
      <input value={code} onChange={(e) => setCode(e.target.value)} />
      <button>Rechercher</button>
      {erreur && <p role="alert">{erreur}</p>}
      {client && <FicheResume client={client} />}
    </form>
  );
}

Le comportement est le même pour l'utilisateur. Mais chaque partie peut maintenant évoluer, être testée et être reprise par un autre développeur sans connaître WebDev.

Les pièges d'une migration WebDev

Le passage d'un serveur « avec état » à une API sans état

En mode session, WebDev conserve sur le serveur le contexte de chaque utilisateur : valeurs des champs, fichiers positionnés, variables globales. Beaucoup de pages en dépendent sans le dire. Une API REST ne garde rien entre deux appels : il faut identifier ce que chaque écran suppose déjà chargé, et le transmettre ou le relire explicitement.

Les contrôles qui n'existaient que dans le navigateur

Un contrôle de saisie fait en code navigateur peut être contourné. Dans la nouvelle architecture, chaque règle importante est appliquée par l'API, même si l'interface la vérifie aussi pour le confort de l'utilisateur. C'est un point de sécurité à traiter systématiquement.

Le code navigateur et le code serveur mélangés

Dans un même événement WebDev, une partie du traitement s'exécute dans le navigateur, une autre sur le serveur. Il faut démêler ces deux parties pour savoir ce qui revient à React et ce qui revient à l'API, sans dupliquer la règle métier des deux côtés.

Les adresses des pages et le référencement

Si votre site WebDev est public, ses adresses sont peut-être indexées par les moteurs de recherche. Changer de technologie change les URL. Il faut les inventorier et prévoir des redirections 301 vers les nouvelles pages pour ne pas perdre votre visibilité, et rendre côté serveur les pages qui doivent être référencées.

Les éditions et exports

Les états imprimés, les exports Excel ou PDF générés par WebDev doivent être repris par l'API. On les inventorie dès l'audit : ils sont souvent plus nombreux qu'on ne le pense, et certains ne servent plus.

Notre méthode pour migrer un site WebDev

1. Audit. Inventaire des pages, des traitements serveur et navigateur, des webservices, des éditions et de l'analyse HFSQL. Voir notre audit d'application WinDev et WebDev.
2. Conception de l'API. Les règles métier extraites du WLangage deviennent des points d'entrée REST, documentés et sécurisés.
3. Refonte de l'interface. Les parcours qui fonctionnent sont conservés, l'ergonomie est modernisée, le site devient utilisable sur mobile.
4. Migration progressive. Les modules sont repris par étapes : l'ancien site et le nouveau peuvent cohabiter le temps de la transition.
5. Reprise des données. Si la base HFSQL est aussi remplacée, ses données sont transférées vers PostgreSQL, MySQL / MariaDB ou SQL Server. Voir HFSQL vers PostgreSQL.
6. Mise en ligne et évolutions. Déploiement sur un hébergement standard, redirections, accompagnement des utilisateurs, maintenance.

Le code source vous est livré en totalité et repose sur des technologies open source : pas de redevance éditeur, et vous restez libre de choisir qui fera évoluer votre application demain. Pour l'ensemble de notre démarche, consultez la page migration et refonte WinDev, WebDev et WinDev Mobile.