Ce que l’IA fait vraiment bien dans une migration… et là où il faut la surveiller
Depuis le début de notre feuilleton, nous partageons les coulisses de la migration de NomadBiz, notre logiciel de gestion commerciale itinérante, de WinDev vers .NET.
NomadBiz est pourtant un logiciel récent, créé en 2025 à partir d’échanges avec des vendeurs indépendants et de leurs besoins réels sur le terrain.
Aujourd’hui, il représente :
- plus de 25 000 lignes de WLanguage ;
- environ 60 fenêtres ;
- plus de 1 500 heures de développement ;
- une base HFSQL Classic ;
- un fonctionnement totalement hors connexion ;
- des fonctions de gestion clients, tournées, devis, factures, caisse, stocks, règlements…
- et un fonctionnement pensé autour des exigences liées à la NF525.
Nous avons décidé de profiter de sa migration vers .NET MAUI / Blazor Hybrid et SQLite pour remettre à plat une partie de l’application et préparer son utilisation future sur Windows, tablettes et smartphones.
Et depuis le début de cette migration, nous utilisons l’IA comme véritable copilote de développement.
Après plusieurs semaines de travail, nous avons maintenant suffisamment de recul pour commencer à répondre à une question que l’on nous pose régulièrement :
Est-ce que l’IA est réellement capable de migrer une application métier ?
Notre réponse aujourd’hui serait :
Oui… mais certainement pas toute seule.
Là où l’IA nous fait gagner énormément de temps
Commençons par le plus spectaculaire.
Sur certaines tâches, l’apport de l’IA est impressionnant.
Nous ne parlons pas seulement de générer quelques lignes de C# ou de créer un composant Blazor.
Nous l’utilisons sur une grande partie du processus de migration.
1. Lire ce qu’un humain ne lirait probablement jamais complètement
Dans un épisode précédent, nous expliquions avoir généré depuis WinDev un dossier technique de plus de 3 000 pages.
Il contient notamment :
- le code WLanguage ;
- les fenêtres ;
- les champs ;
- les procédures ;
- les classes ;
- les états ;
- les différents traitements ;
- des captures des interfaces.
Demander à un développeur de lire intégralement 3 000 pages avant de commencer une migration serait difficilement réaliste.
Avec une IA, ce volume devient exploitable.
Elle peut nous aider à retrouver une procédure, identifier les différents traitements liés à une fenêtre ou rechercher où une règle métier particulière intervient dans l'application.
Cela ne veut pas dire qu'elle comprend automatiquement parfaitement le métier.
Mais elle devient un formidable outil d'exploration de l'existant.
2. Reprendre les tâches répétitives
Une migration contient énormément de travail qui n'est pas forcément complexe intellectuellement… mais qui demande beaucoup de temps.
Prenons une fiche client.
Il faut reprendre :
- les champs ;
- les labels ;
- les types ;
- les listes ;
- les valeurs par défaut ;
- les règles de validation ;
- la disposition ;
- les actions ;
- les comportements associés.
Faire cela manuellement pour plusieurs dizaines de fenêtres prend énormément de temps.
L’IA, elle, peut reprendre méthodiquement cette structure et générer une première version extrêmement rapidement.
Notre rôle devient alors davantage :
contrôler ce qu’elle a produit plutôt que tout retaper manuellement.
Et ce changement est loin d'être anecdotique.
3. Retrouver les règles métier cachées dans le code
C'est probablement l'une des parties les plus importantes d'une migration.
Les applications métiers développées pendant plusieurs années contiennent rarement toutes leurs règles dans une documentation fonctionnelle parfaitement tenue à jour.
Une partie du métier se trouve directement dans le code.
Par exemple :
- un calcul effectué lors de l'ouverture d'une fenêtre ;
- un traitement spécifique avant validation d'une facture ;
- un comportement différent selon le statut d'un client ;
- une condition cachée dans une procédure globale ;
- une valeur automatiquement recalculée lors d'une modification.
Lorsqu'on reconstruit une application, oublier une de ces règles peut produire un logiciel qui semble parfaitement fonctionner… mais dont le comportement métier est faux.
L’IA nous aide énormément à rechercher ces règles dans les milliers de lignes de code existantes.
4. Générer rapidement les nouvelles structures
Une fois le besoin compris, elle devient également extrêmement rapide pour créer :
- des services ;
- des composants Blazor ;
- des modèles ;
- des accès aux données ;
- des pages ;
- des formulaires ;
- des validations ;
- des requêtes ;
- des tests ;
- du code répétitif.
Dans notre cas, elle nous a permis d'obtenir très rapidement les premières versions fonctionnelles de plusieurs écrans.
Nous parlons bien d'écrans connectés à la base SQLite, pas simplement de maquettes.
Ce qui demandait auparavant de nombreuses heures de développement mécanique peut parfois être réalisé en quelques minutes ou quelques dizaines de minutes.
5. Comparer l'ancien et le nouveau
Nous disposons des captures des anciennes fenêtres WinDev et de la documentation associée.
Cela permet également de travailler avec l'IA en mode comparaison :
Voilà l'écran d'origine. Voilà le nouvel écran. Qu'est-ce qui manque ?
C'est particulièrement intéressant lors de la phase de contrôle.
Un champ disparu.
Un bouton oublié.
Une colonne manquante.
Un comportement différent.
Cela ne remplace toujours pas la validation humaine, mais cela fournit un premier niveau de contrôle extrêmement utile.
Mais l’IA oublie aussi des choses
C'est probablement le premier point qu'il faut comprendre lorsque l'on travaille sérieusement avec une IA sur un projet important.
Elle peut oublier.
Même lorsqu'une information était présente dans la documentation.
Même lorsqu'on lui a expliqué une règle précédemment.
Même lorsqu'elle avait correctement réalisé quelque chose sur une autre fenêtre.
Dans une migration de cette taille, cela peut se traduire très concrètement par :
- un champ qui n'a pas été repris ;
- un traitement oublié ;
- une règle métier non implémentée ;
- un bouton absent ;
- un cas particulier ignoré ;
- une information présente dans l'ancienne application mais pas dans la nouvelle.
C'est notamment pour cette raison que nous ne considérons jamais une fenêtre comme terminée simplement parce qu'elle fonctionne visuellement.
Nous devons vérifier qu'elle reprend réellement tout ce qui doit l'être.
Parfois, il faut lui expliquer plusieurs fois la même chose
C'est un autre phénomène assez intéressant.
On peut expliquer une règle à l'IA.
Elle la comprend.
Elle l'applique parfaitement.
Puis quelques écrans plus tard…
elle revient sur une logique proche de celle qu'elle utilisait auparavant.
Cela signifie qu'un projet assisté par IA nécessite tout de même une véritable discipline.
Il faut formaliser les décisions importantes.
Par exemple :
Nous avons choisi SQLite pour conserver un fonctionnement totalement hors connexion.
Cette décision ne doit pas être rediscutée à chaque nouvelle fonctionnalité.
De la même façon :
Nous voulons conserver certains raccourcis clavier.
Nous ne voulons plus utiliser telle ancienne règle métier.
Cette fonctionnalité doit fonctionner sur tablette demain.
Ces décisions doivent devenir des références permanentes du projet.
Sinon, l'IA peut proposer une solution parfaitement logique techniquement… mais contraire à une décision prise trois jours auparavant.
Le problème n'est pas toujours l'IA : parfois, c'est notre prompt
C'est un point que l'on oublie facilement.
Lorsque quelque chose se passe mal avec une IA, le réflexe est parfois de penser :
Elle a fait n'importe quoi.
Mais la vraie question devrait souvent être :
Qu'est-ce qu'on lui a exactement demandé ?
Un prompt trop vague peut avoir des conséquences importantes.
Prenons une demande très simple :
Reprends cette fenêtre et améliore son fonctionnement.
Que signifie exactement « améliorer » ?
Pour nous, cela peut signifier simplifier l'interface.
Pour l'IA, cela peut signifier restructurer complètement le code.
Ou modifier une règle.
Ou remplacer un composant.
Ou supprimer quelque chose qu'elle considère comme inutile.
Et c'est ainsi qu'on peut casser une fonctionnalité qui fonctionnait parfaitement quelques minutes auparavant.
Avec l'IA, on peut créer une régression très rapidement
Il y a une phrase que nous pourrions presque inscrire au-dessus de notre écran :
Plus l'outil est rapide, plus le contrôle doit être rigoureux.
Avec un développeur, modifier profondément plusieurs fichiers prend du temps.
Avec une IA, une demande mal cadrée peut déclencher en quelques secondes ou quelques minutes :
- plusieurs modifications ;
- un refactoring ;
- la création de nouveaux fichiers ;
- la suppression d'une ancienne logique ;
- le changement de plusieurs composants.
C'est extrêmement puissant.
Mais cela signifie également que l'on peut casser énormément de choses… très efficacement.
Une règle importante dans notre workflow est donc devenue :
une correction ne doit pas seulement être testée sur ce qu'elle est censée corriger.
Nous devons aussi nous demander :
qu'est-ce que cette modification aurait pu casser ailleurs ?
Du code qui fonctionne peut être complètement faux
C'est probablement le risque le plus important sur une application métier.
L'IA peut produire un code :
- propre ;
- compilable ;
- rapide ;
- bien structuré ;
- agréable à lire ;
- parfaitement fonctionnel techniquement.
Et pourtant complètement faux.
Pourquoi ?
Parce qu'une application métier n'est pas seulement une somme de règles informatiques.
Elle contient des années de décisions fonctionnelles.
Prenons un exemple volontairement simple.
Une IA peut très bien comprendre qu'un champ Montant doit être calculé ainsi :
Quantité × Prix
Le code sera parfaitement correct.
Mais peut-être que dans notre métier, il faut prendre en compte :
- une remise client ;
- une remise article ;
- une quantité offerte ;
- un prix spécifique ;
- une condition tarifaire ;
- un arrondi particulier.
Sans cette connaissance métier, le résultat peut être techniquement irréprochable et fonctionnellement faux.
C'est précisément là que l'humain reste indispensable
Depuis le début de la migration, notre manière de travailler avec l'IA a évolué.
Au départ, il est tentant de lui dire :
« Voilà l'ancienne fenêtre. Refais-la en .NET. »
Aujourd'hui, nous préférons travailler différemment.
Notre méthode de travail avec l’IA
Étape 1 — Vérifier ce qu'elle a compris
Avant de lui demander de développer, nous pouvons lui demander de reformuler le fonctionnement.
Par exemple :
Explique-moi ce que fait cette fenêtre.
Ou :
Liste-moi les règles métier que tu as identifiées.
C'est une étape extrêmement importante.
Si son interprétation est mauvaise avant même d'écrire la première ligne de code, il vaut mieux le découvrir immédiatement.
Étape 2 — La laisser nous questionner
C'est une approche que nous avons déjà beaucoup utilisée sur NomadBiz.
Nous demandons à l'IA :
Quelles questions dois-tu nous poser avant de reconstruire cette fonctionnalité ?
Et parfois, les questions sont extrêmement pertinentes.
Cette fenêtre est-elle encore utilisée ?
Ce traitement doit-il être conservé ?
Ce comportement est-il volontaire ou historique ?
Cette règle s'applique-t-elle encore aujourd'hui ?
Cette donnée doit-elle toujours être modifiable ?
Ce type d'échange permet de faire apparaître des décisions qui auraient autrement été prises implicitement.
Étape 3 — Lui demander son approche avant le code
Nous ne voulons pas nécessairement qu'elle commence immédiatement à développer.
Nous pouvons d'abord lui demander :
Comment proposes-tu de reconstruire cette fonctionnalité ?
Elle explique alors son approche :
- composants ;
- services ;
- tables ;
- flux ;
- traitements ;
- validations.
Nous pouvons ensuite challenger cette solution.
C'est beaucoup moins coûteux de corriger une architecture avant qu'elle soit développée.
Étape 4 — Arbitrer nous-mêmes
C'est la partie qui ne doit pas être déléguée.
L'IA peut proposer.
Elle peut argumenter.
Elle peut comparer plusieurs solutions.
Mais nous devons décider.
Par exemple, dans NomadBiz :
Pourquoi SQLite ?
Parce que nos utilisateurs doivent pouvoir travailler toute la journée hors connexion.
Pourquoi .NET MAUI / Blazor Hybrid ?
Parce que nous voulons conserver une application locale tout en préparant l'utilisation sur d'autres supports.
Ces choix répondent au terrain.
Pas simplement à une préférence technique.
Étape 5 — La laisser développer
Une fois le cadre défini, c'est ici que l'IA devient extrêmement puissante.
Elle peut produire rapidement une grande partie du code nécessaire.
Et contrairement à une génération faite sans préparation, elle travaille à partir d'une décision déjà validée.
Étape 6 — Vérifier ce qu'elle a réellement repris
Après le développement :
qu'est-ce qui a réellement été implémenté ?
Nous pouvons confronter :
- la documentation WinDev ;
- l'ancienne capture ;
- l'ancien code ;
- la nouvelle interface ;
- le nouveau code.
Cette étape permet de détecter les oublis.
Étape 7 — Tester sur de vraies données
C'est indispensable.
Les données de démonstration ne permettent pas toujours de découvrir les cas réels accumulés pendant la vie d'un logiciel.
NomadBiz possède des bases clients qui ont vécu.
Et les cas particuliers se trouvent justement dans ces données réelles.
La migration doit donc être confrontée au terrain.
Étape 8 — Vérifier que la correction n'a rien cassé ailleurs
Enfin, après chaque modification importante :
quelles sont les conséquences indirectes ?
Ce contrôle devient encore plus important avec une IA capable de modifier rapidement plusieurs parties du projet.
Le métier du développeur évolue
C'est probablement ce que nous trouvons le plus intéressant dans cette expérience.
Utiliser massivement l'IA ne signifie pas que le développeur devient inutile.
Mais son travail change.
Nous passons moins de temps à écrire mécaniquement :
- des formulaires ;
- des propriétés ;
- des accès simples aux données ;
- du code répétitif ;
- certaines structures d'écran.
Et davantage de temps à :
- réfléchir ;
- analyser ;
- expliquer ;
- concevoir ;
- challenger ;
- contrôler ;
- tester ;
- comprendre le métier.
Pour nous, ce changement est plutôt positif.
La vraie valeur n'est pas d'écrire 50 champs
Créer techniquement un formulaire client avec 50 champs n'est pas la partie la plus complexe d'un logiciel métier.
La vraie question est :
Pourquoi ces 50 champs existent-ils ?
Lesquels sont indispensables ?
Lesquels ne servent plus ?
Lesquels doivent être calculés ?
Lesquels doivent apparaître uniquement dans certaines conditions ?
Quels champs manquent aujourd'hui ?
Quelles informations pourraient éviter trois clics à l'utilisateur ?
Voilà où se trouve la valeur.
Et c'est précisément pour cette raison que nous pensons que l'IA devient un formidable outil de développement…
à condition de ne pas lui confier seule les décisions métier.
L'IA ne remplace pas la compréhension du logiciel
C'est probablement la conclusion de cet épisode.
L'IA ne supprime pas le besoin de comprendre une application.
Elle déplace le travail.
Moins de temps passé à produire mécaniquement du code.
Plus de temps consacré à comprendre ce qui doit réellement être construit.
Et finalement, dans une migration, c'est exactement ce que nous recherchons.
Parce que notre objectif avec NomadBiz n'est pas de convertir automatiquement 25 000 lignes de WLanguage en 25 000 lignes de C#.
Notre objectif est de conserver les années de connaissance métier accumulées dans l'application…
tout en reconstruisant une solution :
- plus moderne ;
- plus maintenable ;
- plus ouverte ;
- compatible avec davantage de supports ;
- et mieux adaptée aux besoins futurs de ses utilisateurs.
Est-ce que nous referions une migration de cette façon ?
Aujourd'hui : oui.
Sans hésitation.
L'IA nous permet déjà d'aller beaucoup plus vite sur certaines phases.
Mais nous ne lui ferions certainement pas confiance les yeux fermés.
La bonne approche n'est donc pas :
« L'IA va migrer mon application. »
Nous préférons :
« L'IA va nous aider à migrer notre application beaucoup plus vite, pendant que nous conservons la maîtrise de l'architecture, du métier et de la qualité. »
La nuance est importante.
Et elle est probablement essentielle pour réussir ce type de projet.
Prochain épisode : combien de temps gagnons-nous réellement ?
Depuis le début de ce feuilleton, nous parlons beaucoup de vitesse.
Mais jusqu'ici, nous avons surtout donné des impressions.
Dans le prochain épisode, nous allons essayer d'être plus concrets.
Combien de temps l'IA nous fait-elle réellement gagner sur la migration de NomadBiz ?
Combien aurait coûté la reconstruction de certains écrans avec une méthode traditionnelle ?
Combien de temps avons-nous réellement passé avec l'IA ?
Et surtout :
est-ce que le gain observé sur les premières fenêtres peut être extrapolé à l'ensemble de l'application ?
Pour l'épisode 6, nous allons commencer à sortir les chiffres.
Vous avez vous aussi une application WinDev ou un logiciel métier historique à faire évoluer ?
Chez Dev-Booster, nous travaillons quotidiennement sur les technologies WinDev, .NET et sur les problématiques de migration et de modernisation d'applications métiers.
L'objectif n'est pas forcément de tout réécrire.
La première étape consiste souvent à comprendre l'existant, mesurer la complexité réelle et identifier ce qui mérite d'être conservé, amélioré ou supprimé.