Découpler front et back : la première brique d'une migration

Le défaut structurel des applications WinDev anciennes n'est pas leur langage : c'est l'imbrication. La logique métier vit dans le code des fenêtres, mêlée à l'affichage, sans couche de service ni API. Découpler, c'est desserrer cette imbrication avant de migrer quoi que ce soit : le geste qui rend toutes les trajectoires possibles.

Le principe : isoler la logique métier

Concrètement, il s'agit d'extraire les règles métier des fenêtres et de les exposer derrière une API : un contrat stable qui dit « voici comment créer une commande, voici ce qu'elle vérifie, voici ce qu'elle renvoie ». Une fois ce contrat en place, l'interface actuelle devient un client de l'API comme un autre ; le futur front en sera un second ; les intégrations tierces un troisième. La migration cesse d'être un remplacement en bloc et devient un jeu de clients interchangeables autour d'un cœur stable.

Une situation type

Un exemple typique : le calcul du prix d'un devis, avec ses remises conditionnelles et ses règles de TVA, est aujourd'hui écrit directement dans le code de la fenêtre de saisie. Pour l'exposer en API, il faut d'abord l'extraire de l'écran, identifier toutes les variantes utilisées ailleurs dans l'application, souvent recopiées avec de petites différences, et n'en garder qu'une version faisant autorité. Ce travail de clarification, fait une fois pour toutes, profite à l'écran existant autant qu'aux futurs clients de l'API.

Ce qu'on expose en premier

• Les référentiels : articles, tiers, tarifs, paramètres. Faible risque, forte réutilisation, parfaits pour valider la chaîne.
• Les consultations : recherches, historiques, tableaux de bord. Lecture seule, donc sans danger, et immédiatement utiles à un portail ou un outil mobile.
• Les écritures simples ensuite : création de documents, mises à jour de fiches, avec leurs règles de validation.
• Les processus complexes en dernier : facturation, clôtures, calculs réglementaires, une fois la mécanique rodée.

Contrats d'API et versionnement

Une API n'a de valeur que si son contrat est fiable : schémas documentés, comportements d'erreur explicites, et versionnement dès le premier jour pour pouvoir évoluer sans casser les clients existants. C'est aussi une discipline de documentation : chaque règle métier exposée est enfin écrite quelque part, testable, relisible. Beaucoup de nos clients découvrent à cette occasion que l'API-first est d'abord un projet de documentation du savoir métier, la technique n'en étant que le support.

Ce que nous vérifions à ce stade

• La stabilité du contrat proposé face aux cas limites déjà rencontrés en production.
• La cohérence des messages d'erreur, pour qu'un client de l'API sache toujours pourquoi une opération a échoué.
• La compatibilité ascendante d'une nouvelle version du contrat avec les clients déjà connectés.
• La couverture de tests associée à chaque règle métier exposée, avant toute mise en service.

Faire cohabiter ancien client et nouvelle API

Pendant la transition, l'application WinDev existante et la nouvelle API doivent voir les mêmes données. Deux motifs selon l'état du parc : soit l'API lit et écrit directement dans la base migrée que l'application continue d'utiliser, soit une synchronisation relie l'ancienne base HFSQL et la nouvelle le temps du chantier. Dans les deux cas, la règle est la même que pour toute migration progressive : un seul maître par donnée, des conflits traités explicitement, un journal consultable.

Erreurs fréquentes

• Exposer une API sans définir qui, de l'ancien système ou de la nouvelle base, fait référence sur chaque donnée.
• Documenter le contrat après coup plutôt qu'avant la première intégration, ce qui multiplie les allers-retours.
• Négliger la charge de la couche de synchronisation, qui reste un composant à part entière du chantier tant qu'elle est en service.
• Faire évoluer le contrat d'API sans versionnement, ce qui casse les clients existants sans prévenir.

Le bénéfice long terme au-delà de la migration

Le découplage survit à la migration qui l'a motivé. Une fois le métier exposé en API : le front se remplace sans toucher au cœur, les outils tiers (CRM, e-commerce, BI, automatisations) se branchent proprement, le mobile devient un client de plus, et le risque de dépendance à une technologie unique disparaît structurellement : le jour où une brique doit changer, elle change seule. C'est la différence entre remplacer un monolithe par un autre et construire un système qui accepte d'évoluer.

FAQ