Blog · Architecture

WLangage vers TypeScript ou C# : pourquoi traduire ligne à ligne ne suffit pas

Publié le 27 octobre 2026 · Version longue d’un post de la page LinkedIn de WinExit

Dans une application WINDEV®, le code de clic d’un bouton mélange tout : l’interface, la règle métier et l’accès aux données. Le traduire tel quel dans un autre langage reproduit le problème. La migration est l’occasion de séparer les couches.

Avant : tout est dans le bouton

Voici le code de clic d’un bouton « Valider » dans une fenêtre de saisie de commande. Exemple simplifié, écrit par notre équipe, mais représentatif de ce que l’on trouve dans les projets de quinze ou vingt ans.

WLangage : BTN_Valider, code de clic

// Interface, règles métier et accès HFSQL® au même endroit
SI SAI_Quantité = 0 ALORS
    Erreur("Quantité obligatoire") ; RETOUR      // interface
FIN
HLitRecherchePremier(CLIENT, IDClient, COMBO_Client)   // données
SI CLIENT.Encours + SAI_Montant > CLIENT.Plafond ALORS  // règle
    Info("Plafond dépassé") ; RETOUR             // interface
FIN
SI CLIENT.Catégorie = "GC" ALORS
    COMMANDE.Remise = 5                          // règle
FIN
HAjoute(COMMANDE)                                // données
TableAffiche(TABLE_Commandes)                    // interface

Trois règles métier (quantité obligatoire, plafond d’encours, remise grand compte) sont enfouies dans un événement d’interface. Elles ne sont écrites nulle part ailleurs. Si la même commande peut être saisie depuis une autre fenêtre, les règles y sont recopiées, avec le risque qu’une copie diverge.

Ce que donnerait une traduction ligne à ligne

Un outil de conversion mécanique produirait un gestionnaire de clic en TypeScript ou en C# qui fait exactement la même chose : lire la base, tester, afficher, écrire. Le code compile, mais rien n’a changé :

les règles restent impossibles à tester sans ouvrir l’écran ;
une API, une application mobile ou un traitement batch ne peuvent pas les réutiliser ;
changer de base de données oblige à reprendre chaque fenêtre.

Après : une architecture découplée

Interface : React
<CommandeForm onSubmit={creerCommande} />
L’écran affiche, contrôle la saisie et appelle l’API. Il ne connaît ni les règles ni la base.
API REST, en JSON
Le contrat entre l’écran et le serveur, que d’autres clients peuvent utiliser.
Règles métier : Node.js ou C# / .NET
verifierPlafond(client, montant) · calculerRemise(client)
Des fonctions nommées, testables une à une.
Données : PostgreSQL ou MySQL, en SQL standard
INSERT INTO commande (client_id, remise) …

TypeScript : les règles métier, sans écran ni base

export function verifierPlafond(client: Client, montant: number): void {
  if (client.encours + montant > client.plafond) {
    throw new RegleMetier('Plafond dépassé');
  }
}

export function calculerRemise(client: Client): number {
  return client.categorie === 'GC' ? 5 : 0;
}

TypeScript : le service appelé par l’API

export async function creerCommande(cmd: NouvelleCommande): Promise<Commande> {
  if (cmd.quantite <= 0) throw new RegleMetier('Quantité obligatoire');
  const client = await clients.lire(cmd.clientId);
  verifierPlafond(client, cmd.montant);
  return commandes.ajouter({ ...cmd, remise: calculerRemise(client) });
}

Le même découpage s’écrit en C# avec ASP.NET Core : voir notre page vers C# / .NET, ou vers React / Node.js.

Ce que ça change pour vous

Des règles testées. Chaque règle a ses tests automatisés, tirés du carnet de recette.
Des règles réutilisables. Le portail client, l’application mobile ou l’échange avec un partenaire appellent la même API.
Une base remplaçable. Garder HFSQL ou passer à PostgreSQL ne touche que la couche de données : voir Sortir de HFSQL.
Des écrans familiers. Par défaut, les écrans reprennent la disposition, les libellés et l’enchaînement actuels : vos équipes retrouvent leurs repères.

L’IA pour accélérer, des développeurs seniors pour relire

Séparer les couches demande de comprendre ce que fait chaque ligne. L’IA traduit et propose le découpage ; nos développeurs seniors valident l’architecture, relisent chaque module et contrôlent les règles critiques.

Pour juger sur pièce, commencez petit : une preuve de concept sur une ou deux vues, de 2 000 à 3 000 € HT, déduite de la migration si vous la validez sous 30 jours.

Estimer ma migration en 2 minutes Demander mon devis gratuit

Autres articles : Migrer sans tout casser · Rester en WINDEV 2025 : un sursis · Le carnet de recette · Éditeurs : la redevance et votre marge. Tous nos articles sont sur le blog ; les versions courtes, sur LinkedIn.