Comment Windev nous a fait économiser 33490 euros !

Migration WinDev vers .NET : comment nous avons réécrit NomadBiz en 19 jours, et ce que cela change économiquement

33 490 € HT par an dans notre simulation de licences.
19 jours pour réécrire NomadBiz, tests et nouvelles fonctionnalités compris.

Ces deux chiffres donnent envie de sortir la calculatrice. Ils méritent surtout d’être expliqués : quel logiciel avons-nous migré ? Que comprennent les 19 jours ? Comment avons-nous valorisé ce travail ? Et dans quelles conditions les redevances évitées peuvent-elles financer une réécriture ?

Chez Dev-Booster, nous avons pris notre propre logiciel de vente itinérante comme cas concret. NomadBiz représentait environ 60 fenêtres, plus de 25 000 lignes de WLangage et une centaine d’utilisateurs. Nous avons réécrit l’application de bureau en .NET et remplacé sa base HFSQL Classic par SQLite.

Voici le détail du projet, des choix techniques et du calcul économique.

Les montants de licences présentés dans cet article constituent une simulation fondée sur 100 sessions facturables à 290 € HT par an et un serveur WEBDEV à 4 490 € HT par an. Leur application dépend des versions utilisées, du contrat, des sessions éventuellement incluses et des conditions commerciales propres à chaque entreprise.

NomadBiz est un logiciel utilisé sur le terrain, avec des contraintes très concrètes. Il accompagne des professionnels dans leur activité de vente : gestion des clients, consultation des articles, préparation des devis, commandes, facturation, règlements et suivi des stocks.

Le logiciel comprend notamment :

• La gestion des devis, commandes, factures et avoirs.
• La gestion de caisse et des différents moyens de règlement.
• Le suivi des articles, des fournisseurs et des stocks.
• Les inventaires et l’utilisation de douchettes pour identifier les produits.
• Les exports comptables et la production de documents.
• Des fonctions de statistiques et de communication commerciale.

Une partie essentielle de son fonctionnement repose sur la possibilité de travailler hors connexion. Pour un professionnel itinérant, une connexion instable ne doit pas empêcher de retrouver un client ou de poursuivre son activité.

NomadBiz dispose également d’un serveur web/API pour la mise à jour des prix des fournisseurs. Ce service complète l’application locale et doit être pris en compte lorsqu’on étudie les dépendances techniques et les coûts d’exploitation.

La réécriture devait donc préserver un ensemble de comportements métier, de données et d’habitudes de travail. Le nombre de fenêtres donne une indication de taille ; il ne décrit pas, à lui seul, cette complexité.

Les 19 jours comprennent davantage que la reprise du code. Voici leur répartition :

Les quatre jours d’évolution ont notamment porté sur les questionnaires, les statistiques, le mailing et les envois en masse.

La moitié du temps a donc été consacrée aux tests et aux corrections. C’est un élément central de ce retour d’expérience : la rapidité de production du code doit s’accompagner d’un travail de validation proportionné à l’importance du logiciel.

Nous disposions aussi d’un avantage déterminant : nous connaissions déjà NomadBiz, ses utilisateurs et ses règles de gestion.

Le développement initial de la première version avait représenté environ 1 500 heures, en intégrant notamment les échanges, la définition du besoin et les formations. La réécriture s’appuyait sur une application existante et sur cette connaissance accumulée.

Ces deux volumes correspondent donc à des périmètres différents. Reprendre une logique déjà définie permet d’avancer plus vite que lors de la conception initiale, pendant laquelle les besoins, les parcours et les choix fonctionnels se construisent progressivement.

Le choix de .NET et de SQLite répond au fonctionnement du logiciel. NomadBiz devait conserver une application de bureau et une base locale adaptée à son usage.

.NET fournit un environnement de développement et d’exécution utilisable pour des logiciels commerciaux sans redevance liée à la plateforme elle-même. Microsoft précise que les langages, compilateurs, bibliothèques et environnements d’exécution qui composent .NET sont gratuits, y compris pour un usage commercial. Cela ne préjuge pas du prix des outils de développement ou des composants tiers éventuellement retenus. Présentation officielle de .NET.

SQLite répond, de son côté, au besoin de stockage local. Sa documentation distingue cet usage de celui d’une base centralisée partagée entre de nombreux clients. Ce choix convient à notre architecture de bureau avec base locale ; une application dans laquelle plusieurs postes accèdent simultanément aux mêmes données peut nécessiter une architecture différente. Usages recommandés de SQLite.

La présence d’une centaine d’utilisateurs dans le parc ne signifie donc pas qu’une centaine de personnes ouvrent le même fichier de base de données.

Pour un projet partagé entre plusieurs postes ou plusieurs sites, nous étudierions notamment une base client-serveur comme PostgreSQL. Le choix dépend des accès concurrents, du besoin de centralisation et des échanges entre utilisateurs.

SQLite est par ailleurs distribué dans le domaine public. Son moteur ne crée donc pas une redevance par utilisateur comparable à celle retenue dans notre simulation. Conditions d’utilisation de SQLite.

Une réécriture commence par la compréhension de l’existant. Avant de reprendre les écrans, il faut identifier ce qu’ils font réellement.

Dans un logiciel métier, une règle peut se trouver dans une procédure partagée, dans le traitement d’un bouton, dans une requête ou dans une succession de contrôles effectués lors de la validation d’un document.

Pour préparer un chantier comparable, nous recommandons de recenser :

• Les fenêtres et les parcours réellement utilisés.
• Les procédures qui portent les calculs et les règles de gestion.
• Les requêtes et les traitements de données.
• Les documents générés et les exports.
• Les échanges avec les services externes.
• Les périphériques utilisés.
• Les opérations sensibles pour l’activité.
• Les fonctions anciennes à conserver, à faire évoluer ou à retirer après validation.

Cette analyse permet de définir le périmètre de reprise et de préparer les critères de validation.

Prenons une facture : retrouver les mêmes champs à l’écran ne suffit pas. Il faut également retrouver les bons articles, appliquer les remises attendues, calculer les montants, enregistrer les règlements et produire un document cohérent avec les données sauvegardées.

La valeur du logiciel réside dans cet ensemble.

L’IA accélère certaines tâches, tandis que la connaissance métier oriente le chantier. La réécriture de NomadBiz a bénéficié de l’assistance de l’IA.

Sur ce type de projet, elle peut aider à analyser des portions de code, proposer leur réécriture, préparer des structures répétitives ou repérer des différences entre deux traitements.

Son efficacité dépend toutefois du contexte fourni. Une fonction qui applique une exception commerciale doit être comprise avant d’être transformée. Une règle mal expliquée peut donner un code techniquement correct qui produit un résultat inadapté.

Le travail des développeurs consiste donc aussi à organiser les éléments à reprendre, vérifier les propositions et confronter le résultat aux usages du logiciel.

Les dix jours de tests et de corrections de NomadBiz illustrent cette répartition du travail. La production du code représente une étape du projet ; la validation du comportement détermine si la nouvelle application peut prendre le relais.

La reprise des données demande une attention particulière. Passer de HFSQL Classic à SQLite suppose de vérifier comment les informations sont représentées et reliées entre elles.

Un import peut contenir le bon nombre de lignes tout en présentant des anomalies : une référence devenue incohérente, une date mal interprétée, une valeur vide transformée ou un identifiant réattribué.

Pour un logiciel de gestion, les contrôles doivent porter sur plusieurs niveaux.

Les montants méritent notamment une stratégie explicite. Les nombres flottants binaires peuvent représenter certaines valeurs décimales de manière approximative. La documentation SQLite le rappelle : ce sujet concerne le choix de représentation des nombres, au-delà du seul moteur de base de données. Documentation sur les nombres flottants.

Pour une application commerciale, il faut définir la précision utile aux prix, aux quantités et aux calculs intermédiaires, puis vérifier les arrondis attendus. Un montant total correct sur un exemple simple ne garantit pas le résultat sur une facture comprenant plusieurs remises ou des quantités fractionnaires.

Nous recommandons donc de comparer les données et les résultats métier : nombre de documents, totaux représentatifs, soldes clients, quantités en stock et liens entre les enregistrements.

Les tests doivent suivre les parcours des utilisateurs. Tester chaque fenêtre séparément laisse de côté une partie des risques.

Une opération peut fonctionner seule puis produire une anomalie lorsqu’elle est suivie d’un règlement, d’une modification ou d’un export. Pour préparer la validation d’une application comme NomadBiz, il faut construire des scénarios complets.

Ces exemples constituent une base de préparation pour un projet comparable. La recette doit ensuite être adaptée aux fonctions effectivement utilisées et aux particularités de chaque entreprise.

Les cas inhabituels comptent également : document incomplet, référence fournisseur absente, opération interrompue, volume important de données ou fichier d’import incorrect.

Une migration réussie doit permettre de traiter ces situations de façon compréhensible pour l’utilisateur, sans laisser les données dans un état incohérent.

L’API de mise à jour des prix fournisseurs constitue un chantier à part entière. Elle est importante dans le fonctionnement de NomadBiz et dans la comparaison économique.

Lorsqu’on envisage de sortir ce service de WEBDEV, plusieurs éléments doivent être examinés : le format des échanges, les références utilisées pour identifier les articles, les dates d’application des tarifs et le comportement attendu lorsqu’un prix est absent ou invalide.

La gestion des reprises est également importante. Une connexion peut être interrompue pendant une mise à jour. Le service et l’application doivent alors permettre de déterminer ce qui a été reçu, ce qui a été appliqué et ce qui doit être repris.

Pour un chantier de migration de cette API, nous recommandons notamment de prévoir :

• Un format d’échange défini et documenté.
• Une identification fiable des articles et des fournisseurs.
• Des contrôles sur les données reçues.
• Une gestion explicite des erreurs et des reprises.
• Une protection des accès au service.
• Une traçabilité suffisante pour comprendre un incident.
• Des tests entre l’application locale et le service cible.

Il faut aussi préserver la cohérence des documents existants. Une mise à jour du catalogue ne doit pas modifier des données historiques que les règles métier imposent de conserver.

La cible technique du service peut être étudiée séparément de l’interface de bureau. Ce qui compte pour leur communication est le contrat d’échange : les données envoyées, les réponses attendues et les erreurs possibles.

Dans le calcul économique, le coût de cette migration doit être ajouté au budget si l’on souhaite compter la suppression de la licence serveur parmi les économies.

Le déploiement fait également partie du périmètre à préparer. Une application validée sur les postes de développement doit ensuite être installée dans les conditions réelles d’utilisation.

Selon le parc concerné, cela peut impliquer la reprise des bases locales, la vérification des chemins de fichiers, des droits d’accès, des imprimantes et des périphériques.

Un déroulement progressif permet de commencer sur un périmètre représentatif, de vérifier les retours puis d’étendre le déploiement. Pour chaque lot, il faut savoir quelle version est installée et quelle migration de données a été appliquée.

Les sauvegardes doivent être exploitables et leur restauration vérifiée. SQLite propose notamment une API de sauvegarde adaptée à une base en cours d’utilisation ; copier un fichier sans prendre en compte l’activité de la base ne constitue pas à lui seul une procédure de sauvegarde fiable. Mécanismes de sauvegarde SQLite.

Un retour à une version précédente demande également une préparation : si les utilisateurs ont créé de nouvelles données après la bascule, restaurer une ancienne sauvegarde peut les faire disparaître. Le plan de reprise doit donc préciser comment ces opérations seraient préservées.

Ces interventions doivent être intégrées au chiffrage lorsqu’elles font partie du périmètre demandé.

Le calcul des licences repose sur deux postes distincts. Pour notre exemple, nous retenons 100 sessions effectivement facturables à 290 € HT par an et un serveur WEBDEV à 4 490 € HT par an pour l’API fournisseurs.

Ce total représente environ 2 791 € HT par mois lorsqu’on répartit la dépense annuelle sur douze mois.

À tarifs et périmètre constants, le cumul devient :

Ces montants décrivent les redevances simulées. Ils ne constituent pas des économies nettes déjà réalisées.

Pour appliquer cette méthode à votre entreprise, il faut d’abord déterminer le nombre d’unités réellement facturables. Le nombre d’utilisateurs ne suffit pas à établir le montant d’une facture : les sessions incluses, les conditions de licence, les remises et les engagements éventuels peuvent modifier le résultat.

Le calcul doit également identifier qui supporterait la dépense : l’éditeur, le distributeur ou le client final. Une charge évitée chez un client ne devient pas automatiquement une économie de trésorerie pour l’éditeur, même si elle peut améliorer la compétitivité de son offre.

Nous valorisons les 19 jours sur une base clairement définie. Pour disposer d’un ordre de grandeur comparable, nous retenons 19 journées de 7 heures au tarif actuel de Dev-Booster, soit 59 € HT par heure.

Le calcul est le suivant :

19 × 7 = 133 heures.

133 × 59 € = 7 847 € HT de travail valorisé.

Il s’agit d’une valorisation commerciale du temps retenu pour l’exemple. Elle ne correspond pas à un coût salarial constaté ni à un devis pour une autre application.

La comparaison suppose également que les 19 journées représentent la charge de travail retenue. Lorsqu’un projet mobilise plusieurs personnes en parallèle, il faut additionner leur temps : un délai de réalisation et un nombre de jours de travail ne sont pas interchangeables.

Enfin, les quatre jours de nouvelles fonctionnalités sont inclus dans cette valorisation. L’exemple porte donc sur la réécriture accompagnée de ces évolutions.

Les seules sessions utilisateurs permettent de calculer un premier délai théorique. Dans notre scénario, elles représentent 29 000 € HT par an.

En les comparant aux 7 847 € de travail valorisé :

7 847 € ÷ 29 000 € × 12 = environ 3,2 mois.

Autrement dit, un peu plus de trois mois de redevances utilisateurs représenteraient le montant de cette valorisation.

Ce calcul suppose que les redevances concernées puissent effectivement être supprimées et ne tient pas compte d’un éventuel écart de coûts d’exploitation. Il répartit aussi une dépense annuelle sur douze mois : les dates d’échéance des contrats déterminent le calendrier réel des effets sur la trésorerie.

Nous conservons volontairement les 4 490 € du serveur en dehors de ce premier calcul. Pour les ajouter aux économies, il faudrait disposer du budget complet de migration de l’API et des éventuelles différences de coûts d’hébergement et de maintenance.

Le calcul global devrait alors utiliser :

Budget complet de migration ÷ économies annuelles nettes attendues × 12.

Le budget complet comprend les interventions nécessaires à la sortie effective du périmètre considéré. Les économies nettes correspondent aux charges supprimées, diminuées des éventuels surcoûts récurrents de la solution cible.

Même un budget de migration plus élevé mérite d’être comparé aux charges récurrentes. Le résultat de NomadBiz ne doit pas devenir une estimation automatique pour tous les logiciels.

Pour illustrer cette sensibilité, conservons uniquement l’hypothèse de 29 000 € de redevances utilisateurs annuelles supprimées et faisons varier le budget initial.

Ces budgets ne sont pas des devis Dev-Booster. Le tableau montre l’effet du montant initial sur le délai de retour, avec les mêmes hypothèses d’économie annuelle et sans variation des coûts d’exploitation.

Il permet aussi d’éviter de concentrer toute la discussion sur les 19 jours. Un projet plus long peut conserver un intérêt économique, selon le parc, les licences applicables et la durée pendant laquelle le logiciel doit continuer à être utilisé.

La comparaison complète doit intégrer les dépenses qui continuent d’exister. Une application réécrite demande toujours de la maintenance, des mises à jour, des sauvegardes et de l’assistance.

Selon le projet, il peut également rester des coûts liés aux outils de développement, aux composants graphiques, à la génération de documents, à l’hébergement ou aux services externes.

Pour établir un budget réaliste, il faut donc comparer les deux situations avec les mêmes catégories de dépenses :

Cette analyse peut aussi faire apparaître une coexistence temporaire entre l’ancienne application et la nouvelle. Son coût doit être anticipé lorsque le déploiement est progressif.

La taille du code ne suffit pas à déterminer le prix d’une migration. Deux applications de 25 000 lignes peuvent demander des efforts très différents.

Une application bien connue, avec des parcours clairement identifiés et peu de dépendances externes, se chiffre différemment d’un logiciel dont les règles sont dispersées et dont les interfaces sont peu documentées.

Les facteurs à examiner comprennent notamment la complexité des calculs, la qualité des données, les documents à produire, les matériels à piloter, les échanges externes et les contraintes de déploiement.

Le niveau de transformation demandé compte également. Conserver des parcours familiers limite certains changements pour les utilisateurs. Repenser entièrement l’ergonomie et les processus ajoute un chantier de conception au travail de réécriture.

Pour certains logiciels, une migration complète est adaptée. Pour d’autres, il est plus pertinent de commencer par un service, une base de données ou un module, puis de poursuivre progressivement.

Chaque étape doit alors produire un résultat exploitable et réduire une dépendance identifiée.

Le cas NomadBiz donne une méthode pour ouvrir la discussion. Nous disposons d’un périmètre concret, d’un temps de travail identifié et d’un scénario économique explicite.

La réécriture de l’application a représenté 19 jours, comprenant dix jours de tests et quatre jours d’évolution. Dans notre hypothèse de tarification, les sessions utilisateurs représenteraient 29 000 € HT par an, auxquels s’ajouteraient 4 490 € pour le serveur WEBDEV de l’API fournisseurs.

La décision de migration peut ensuite être prise à partir de données propres à chaque entreprise : les licences réellement applicables, les fonctions à préserver, le coût complet de reprise et la durée d’exploitation envisagée.

Chez Dev-Booster, nous accompagnons les entreprises dans l’analyse de leurs applications WinDev, la reprise de leurs données et leur migration vers une architecture adaptée à leurs usages.

Pour préparer votre projet, vous pouvez utiliser notre outil d’estimation de migration WinDev. Il fournit une première base de discussion, à compléter par l’étude des sources, des données et des interfaces.

Vous disposez déjà d’une application, d’un schéma de base ou d’une description de votre parc ? Nous pouvons partir de ces éléments pour définir le périmètre de reprise et construire une comparaison économique adaptée à votre situation.

14/09/2026 - 15:15