☀️ FEUILLETON DE L’ÉTÉ — Épisode 3

HFSQL Classic → SQLite : pourquoi nous avons commencé par les données

Après avoir analysé plus de 3 000 pages de documentation WinDev et défini ce que nous voulions réellement conserver dans NomadBiz, nous aurions pu commencer directement par refaire les écrans.

Nous avons préféré commencer par ce qui est probablement le plus précieux dans un logiciel métier : les données.

NomadBiz fonctionne aujourd’hui avec une base HFSQL Classic. Pour la nouvelle version en .NET MAUI / Blazor Hybrid, nous avons choisi SQLite.

Pourquoi ?
Parce que NomadBiz doit continuer à fonctionner 100 % hors connexion.
Nos utilisateurs travaillent sur le terrain, parfois toute une journée sans réseau. Il nous fallait donc une base locale, légère, fiable et sans serveur à administrer.

Mais migrer une base ne consiste pas à faire un simple copier/coller.
Il faut reprendre et contrôler :
→ les types de données
→ les clés et index
→ les relations
→ les champs calculés
→ les contraintes
→ et évidemment toutes les données existantes
Autre règle importante :
La migration doit être reproductible.

Nous devons pouvoir prendre une base HFSQL d’un client, lancer notre outil, générer sa nouvelle base, contrôler le résultat… puis rejouer la même opération le jour de la bascule.

C’est un sujet sur lequel nous travaillons déjà beaucoup chez Dev-Booster.
Nous avons développé notre propre outil permettant de migrer HFSQL Classic / HFSQL vers :
→ PostgreSQL
→ MySQL
→ MariaDB
→ Firebird
→ SQL Server

Pour NomadBiz, nous avons repris cette logique pour SQLite.
Mais une migration est aussi le moment idéal pour se challenger.

L’objectif n’est pas forcément de reproduire la base historique à l’identique.
C’est l’occasion de vérifier :
→ les index inutiles ou manquants
→ les champs devenus obsolètes
→ les types mal adaptés
→ les relations à simplifier
→ les requêtes coûteuses
→ les données redondantes
→ les règles métier qui seraient mieux côté applicatif

Ne pas profiter d’une migration pour revoir son modèle de données, c’est parfois simplement déplacer sa dette technique d’une base vers une autre.
Notre objectif est donc double :
✅ ne perdre aucune donnée
✅ repartir sur une structure plus propre et mieux adaptée
Une interface ratée se corrige.
Une donnée mal convertie, beaucoup moins.

🎬 Prochain épisode :
Comment reconstruire les premiers écrans WinDev en .NET sans simplement refaire la même application ?
#WinDev #HFSQL #SQLite #PostgreSQL #MySQL #MariaDB #Firebird #SQLServer #dotNET #MigrationLogicielle #DevBooster

14/08/2026 - 09:46