Le nouveau logiciel fonctionne. Mais est-ce que la migration est vraiment terminée ?
Dans l’épisode précédent, nous avons enfin sorti les chiffres de la migration de NomadBiz de WinDev vers .NET.
Notre estimation initiale dépassait 80 jours ouvrés.
Dans les faits, nous avons consacré environ :
- un peu plus de 5 jours à la réécriture et au contrôle de la reprise ;
- 10 jours aux tests, corrections et allers-retours ;
- 4 jours à l’intégration et aux tests des nouvelles fonctionnalités.
Soit environ 19 jours de travail.
Mais il reste une étape que les chiffres de développement ne racontent pas.
Et probablement l’une des plus importantes :
mettre réellement le nouveau logiciel entre les mains des utilisateurs.
Parce qu’une migration n’est pas terminée lorsqu’une application compile.
Elle n’est même pas terminée lorsque tous les tests automatisés passent.
Elle est terminée lorsque les utilisateurs peuvent travailler avec leurs vraies données, dans leurs vraies conditions, sans perdre d’information et sans avoir besoin de revenir sur l’ancien logiciel.
Et c’est précisément là que commence la dernière grande phase de notre migration de NomadBiz.
Le logiciel fonctionne. Maintenant, il faut migrer la réalité.
Pendant le développement, nous pouvons travailler avec :
- des copies de bases ;
- des données de démonstration ;
- des environnements de test ;
- des scénarios préparés ;
- des utilisateurs fictifs.
C’est indispensable.
Mais ce n’est jamais exactement la réalité.
Une base client utilisée depuis plusieurs mois contient forcément des particularités :
- anciennes données ;
- valeurs atypiques ;
- enregistrements incomplets ;
- situations métier rares ;
- historiques ;
- cas limites ;
- parfois même des incohérences accumulées.
C’est justement pour cela que nous avons commencé notre migration par les données.
Avant même de refaire les écrans, nous avons construit notre outil de conversion HFSQL Classic → SQLite.
Et à ce stade du projet, cet investissement prend tout son sens.
Une migration de données doit être rejouable
C’est probablement l’un des principes les plus importants de notre approche.
Nous ne voulons pas effectuer une migration manuelle une fois, croiser les doigts et espérer que tout soit correct.
Nous voulons pouvoir faire :
HFSQL Classic → SQLite
autant de fois que nécessaire.
Pourquoi ?
Parce que pendant que nous développons et testons la nouvelle version, l’ancienne application continue de vivre.
Des clients sont créés.
Des factures sont émises.
Des règlements sont enregistrés.
Les stocks changent.
Les tournées avancent.
La base utilisée lors de notre premier test de migration n’est donc déjà plus à jour quelques jours plus tard.
La bonne stratégie n’est pas de figer trop tôt les données.
La bonne stratégie est d’avoir une procédure capable d’être relancée.
Tester une première migration… puis recommencer
Nous pouvons donc procéder en plusieurs étapes.
Une première copie de la base est migrée vers SQLite.
Nous testons dessus.
Nous vérifions les écrans.
Nous contrôlons les données.
Nous corrigeons éventuellement notre outil de migration.
Puis nous recommençons.
Au moment de la mise en production, nous pouvons repartir de la dernière base HFSQL disponible et exécuter exactement le même processus.
C’est essentiel.
Parce qu’une migration industrielle doit être :
reproductible, testable et vérifiable.
Pas dépendante d’une série d’opérations manuelles dont personne ne se souviendra précisément six mois plus tard.
“La migration a réussi” ne suffit pas
Supposons que notre outil termine son traitement et affiche :
Migration terminée avec succès.
Est-ce suffisant ?
Non.
Nous devons également vérifier ce qui est réellement arrivé dans SQLite.
Par exemple :
- combien de clients avant ?
- combien après ?
- combien de factures ?
- combien de lignes de facture ?
- combien de règlements ?
- combien d’articles ?
- combien d’écritures de caisse ?
- quels montants cumulés ?
- quelles valeurs de stock ?
Il faut pouvoir comparer les deux côtés.
Avant = Après
Le principe paraît simple.
Si la base WinDev contient :
12 458 clients
nous devons retrouver :
12 458 clients dans SQLite
Si nous avons :
48 217 factures
nous voulons retrouver ces 48 217 factures.
Même chose pour les montants.
Un total TTC calculé sur la base source doit correspondre au total obtenu après migration.
Les contrôles peuvent être techniques :
- nombre de lignes ;
- intégrité des clés ;
- absence d’orphelins ;
- valeurs nulles inattendues.
Mais aussi métier :
- total du chiffre d’affaires ;
- montant des impayés ;
- montant des règlements ;
- valorisation de certains stocks ;
- soldes clients.
C’est exactement le type de contrôle que nous voulons automatiser autant que possible.
Parce que vérifier manuellement une base contenant des milliers de pièces n’est évidemment pas réaliste.
Le vrai risque n’est pas toujours de perdre une ligne
Lorsqu’on pense migration de données, on imagine souvent le scénario le plus évident :
une donnée disparaît.
Mais il existe des problèmes plus subtils.
Une date peut être mal convertie.
Un booléen peut changer de sens.
Une valeur vide peut devenir zéro.
Une chaîne peut être tronquée.
Une règle calculée peut donner un résultat légèrement différent.
Une relation peut être conservée techniquement mais pointer vers la mauvaise donnée.
Et ce sont parfois ces erreurs qui sont les plus dangereuses.
Parce qu’elles ne font pas planter le logiciel.
Tout semble fonctionner.
Simplement, l’information affichée est fausse.
Ne surtout pas supprimer WinDev le jour de la bascule
À ce stade, une tentation pourrait être :
La nouvelle version fonctionne, on désinstalle l’ancienne et on passe à autre chose.
Nous ne le ferons pas.
Une migration réussie doit prévoir une période de sécurité.
L’ancienne version WinDev restera disponible pendant la transition.
Cela ne signifie pas forcément que les utilisateurs devront saisir les informations dans les deux logiciels.
Ce serait probablement la pire solution : deux systèmes qui évoluent en parallèle et des données impossibles à réconcilier ensuite.
En revanche, garder l’ancienne application accessible permet de conserver un point de comparaison.
Et surtout :
un filet de sécurité.
Prévoir le retour arrière avant la mise en production
C’est un sujet que l’on préfère généralement ne pas avoir à utiliser.
Mais il faut le préparer.
Avant chaque migration réelle :
- sauvegarde de la base HFSQL ;
- conservation de la version WinDev utilisée ;
- identification de la version .NET déployée ;
- sauvegarde de la base SQLite générée ;
- procédure documentée de retour arrière.
La question à se poser n’est pas :
“Est-ce que notre mise en production va fonctionner ?”
Nous avons évidemment tout fait pour que ce soit le cas.
La question est :
“Si quelque chose ne va pas, combien de temps nous faut-il pour revenir à une situation stable ?”
C’est une nuance importante.
Une bonne stratégie de déploiement ne repose pas sur l’absence totale de problème.
Elle repose aussi sur la capacité à réagir lorsqu’un problème apparaît.
Les vrais utilisateurs voient ce que nous ne voyons pas
Nous pouvons tester une application pendant des jours.
Il restera toujours une catégorie de testeurs particulièrement efficace :
ceux qui l’utilisent toute la journée pour travailler.
Parce qu’ils ne regardent pas l’application de la même manière que nous.
Un développeur voit :
- une architecture ;
- des composants ;
- des requêtes ;
- des performances ;
- des validations.
Un utilisateur voit :
combien de clics il lui faut pour faire ce qu’il faisait hier.
Et c’est parfois brutalement efficace.
“Avant, j’appuyais sur 1”
Nous en parlions déjà dans les premiers épisodes.
Dans NomadBiz, certains usages ont été conçus avec les utilisateurs.
Il peut s’agir de détails comme :
- un raccourci clavier ;
- l’ordre de tabulation ;
- une information immédiatement visible ;
- la position d’un bouton ;
- une action réalisable sans souris.
Sur le papier, déplacer une information de dix centimètres ne change rien.
Sur le terrain, si un vendeur effectue cette action 80 fois dans la journée, cela peut devenir très pénible.
C’est précisément pour cela que nous avons cherché à conserver certains repères lors de la refonte.
Moderniser ne signifie pas :
tout changer pour que cela fasse moderne.
Une nouvelle interface peut être plus jolie… et moins efficace
C’est un vrai piège lors des refontes.
Nous avons évidemment modernisé l’interface de NomadBiz.
Mais l’objectif n’est pas de gagner un concours de design.
L’objectif est que le logiciel soit plus agréable et plus efficace.
Un magnifique formulaire qui nécessite quatre clics là où l’ancien en demandait un seul est une régression.
Même s’il est plus beau.
C’est donc maintenant aux utilisateurs de confirmer les choix effectués.
Les tests techniques et les tests terrain ne répondent pas aux mêmes questions
Les tests techniques cherchent à répondre à des questions comme :
Le calcul est-il correct ?
La sauvegarde fonctionne-t-elle ?
Les données sont-elles bien enregistrées ?
Cette action provoque-t-elle une erreur ?
Les tests utilisateurs vont répondre à d’autres questions :
Est-ce que je trouve rapidement l’information ?
Est-ce que mon parcours est logique ?
Est-ce que je peux faire ma tournée sans perdre du temps ?
Est-ce que cette nouvelle façon de faire est réellement meilleure ?
Les deux sont indispensables.
La migration ne concerne pas seulement le code et les données
Il y a également toute la partie environnement.
NomadBiz est une application locale.
Nos vendeurs peuvent travailler 100 % hors connexion.
C’est une contrainte structurante depuis le début de notre projet.
Nous avons donc choisi :
- .NET ;
- MAUI Blazor Hybrid ;
- SQLite en local.
Mais une application installée chez des utilisateurs implique aussi de réfléchir à son cycle de vie.
Comment mettre à jour la nouvelle application ?
C’est un sujet qui devient maintenant particulièrement important.
Avec une application locale, il faut prévoir :
- la distribution des nouvelles versions ;
- la détection d’une mise à jour ;
- le téléchargement ;
- l’installation ;
- le redémarrage ;
- la compatibilité avec la base locale ;
- éventuellement la migration du schéma SQLite.
Parce que notre base va continuer d’évoluer.
Ajout d’un champ.
Ajout d’une table.
Modification d’un index.
Nouvelle fonctionnalité.
Chaque nouvelle version peut donc avoir besoin d’une mise à niveau locale de la base.
Version du logiciel et version de la base doivent avancer ensemble
Imaginons :
NomadBiz 1.0
fonctionne avec une certaine structure SQLite.
Puis nous publions :
NomadBiz 1.1
avec une nouvelle fonctionnalité nécessitant une colonne supplémentaire.
Nous devons être capables de savoir :
- quelle version du logiciel est installée ;
- quelle version de la structure de base est présente ;
- quelles migrations doivent être exécutées ;
- dans quel ordre.
Et surtout :
ne jamais rendre la base inutilisable si une mise à jour échoue.
Là encore : sauvegarder avant de modifier
Notre logique restera la même.
Avant une modification importante de la base locale :
sauvegarde.
Puis migration.
Puis validation.
Si tout se passe correctement, l’utilisateur continue.
Sinon, nous devons disposer d’une solution de récupération.
C’est le genre de mécanisme peu visible pour l’utilisateur…
mais qui fait une énorme différence lorsque quelque chose tourne mal.
Et si l’utilisateur reste hors connexion plusieurs semaines ?
C’est également le genre de scénario que notre architecture doit prévoir.
Un utilisateur peut ne pas installer toutes les versions intermédiaires.
Il pourrait par exemple passer :
de la version 1.1 directement à la version 1.5.
Notre système doit alors être capable de déterminer :
1.1 → 1.2
1.2 → 1.3
1.3 → 1.4
1.4 → 1.5
ou de disposer d’un mécanisme équivalent permettant de mettre correctement la base à niveau.
Ce sont exactement ces détails qui permettent à une application métier de rester maintenable sur plusieurs années.
Le déploiement fait partie de la migration
Il serait donc faux de considérer que notre chantier se termine avec :
“Voilà le fichier .exe.”
Une vraie migration comprend aussi :
- l’installation ;
- les mises à jour ;
- la gestion des bases ;
- la récupération en cas d’échec ;
- les logs ;
- le support ;
- la remontée des erreurs.
C’est une partie moins spectaculaire que les captures avant/après.
Mais elle est tout aussi importante.
Que faire si un bug apparaît uniquement chez un utilisateur ?
C’est là que la journalisation devient indispensable.
Lorsqu’un logiciel est installé sur plusieurs machines, il faut pouvoir comprendre ce qu’il s’est passé.
Version utilisée.
Action effectuée.
Erreur rencontrée.
État de la base.
Contexte.
Sans ces informations, le support peut rapidement devenir :
“Chez moi ça fonctionne.”
Et cette phrase n’a jamais réparé aucun logiciel.
La nouvelle architecture doit donc aussi améliorer notre capacité à maintenir NomadBiz
Notre migration ne vise pas simplement un nouvel aspect visuel.
Nous voulons également obtenir une application plus facile à :
- maintenir ;
- diagnostiquer ;
- mettre à jour ;
- tester ;
- faire évoluer.
C’est une partie importante du retour sur investissement d’une migration.
Le bénéfice ne se mesure pas uniquement pendant la phase de réécriture.
Il se mesure pendant les années qui suivent.
Une migration réussie doit devenir invisible
C’est peut-être la meilleure façon de résumer notre objectif pour la mise en production.
Pour nous, cette migration représente :
- plusieurs technologies ;
- des milliers de lignes de code ;
- une nouvelle base ;
- une nouvelle architecture ;
- des semaines de tests ;
- de nouvelles fonctionnalités.
Pour l’utilisateur final, idéalement, cela doit être beaucoup plus simple :
“J’ouvre NomadBiz et je travaille.”
Avec une interface plus agréable.
Des fonctionnalités supplémentaires.
De meilleures performances.
Mais sans se demander constamment :
“Comment je fais maintenant ?”
Quand considérerons-nous réellement la migration comme terminée ?
Pas lorsque la dernière ligne de code sera écrite.
Pas lorsque nous aurons terminé nos tests internes.
Pas même lorsque la première base client sera migrée.
Nous considérerons la migration réussie lorsque :
- les vraies bases auront été converties ;
- les contrôles avant/après seront corrects ;
- les utilisateurs auront validé leurs parcours ;
- les mises à jour fonctionneront ;
- la récupération aura été testée ;
- les incidents éventuels pourront être diagnostiqués ;
- et que l’application sera devenue leur outil quotidien.
C’est seulement à ce moment-là que nous pourrons réellement dire :
NomadBiz a quitté WinDev.
La plus grosse erreur serait de sous-estimer cette dernière étape
L’IA nous a fait gagner énormément de temps sur la production.
Nous l’avons montré dans l’épisode précédent :
plus de 80 jours estimés contre environ 19 jours réellement consacrés à la réécriture, aux tests et aux nouveautés.
Mais certaines étapes ne doivent pas être compressées simplement parce que nous savons aller plus vite.
La bascule réelle en fait partie.
Nous préférons passer davantage de temps à :
- contrôler ;
- sauvegarder ;
- tester ;
- accompagner ;
plutôt que de gagner deux jours de plus et découvrir ensuite un problème sur une base en production.
L’IA change la vitesse. Pas la responsabilité.
C’est finalement un thème qui revient régulièrement dans ce feuilleton.
L’IA peut :
- analyser plus vite ;
- développer plus vite ;
- corriger plus vite ;
- documenter plus vite.
Mais la responsabilité du résultat reste de notre côté.
C’est encore plus vrai au moment de la mise en production.
Quand le logiciel contient les données réelles d’une entreprise et devient son outil de travail quotidien, la vitesse n’est plus le seul critère.
La fiabilité devient prioritaire.
Et pour les migrations de nos clients ?
C’est évidemment une expérience que nous voulons réutiliser.
Lorsque nous migrons un logiciel métier existant, notre travail ne doit pas s’arrêter au développement de la nouvelle version.
Il faut aussi réfléchir à la stratégie de bascule.
Quelques questions deviennent donc incontournables :
- Le logiciel actuel peut-il rester disponible ?
- Comment convertir les données ?
- Peut-on rejouer la migration ?
- Quels contrôles effectuer automatiquement ?
- Combien de temps peut durer l’interruption ?
- Existe-t-il plusieurs bases ou plusieurs sites ?
- Comment déployer la nouvelle application ?
- Comment accompagner les utilisateurs ?
- Quelle procédure de retour arrière prévoir ?
Et ces éléments doivent être réfléchis avant le jour de la mise en production.
Une migration n’est pas un bouton “Convertir”
C’est probablement l’une des idées essentielles de toute cette série.
L’IA rend certaines phases de migration extrêmement rapides.
Mais migrer une application métier ne consiste toujours pas à cliquer sur :
WinDev → .NET
puis attendre quelques minutes.
Une migration réussie reste la combinaison de :
code + données + métier + tests + utilisateurs + déploiement.
L’IA accélère fortement plusieurs éléments de cette équation.
Elle ne les fait pas disparaître.
La suite de NomadBiz
Nous approchons maintenant de cette phase.
La nouvelle application fonctionne.
La base SQLite est en place.
Les nouvelles fonctionnalités sont intégrées.
Les tests ont avancé.
La prochaine étape est donc très concrète :
faire vivre cette nouvelle version dans les mêmes conditions que l’ancienne.
Avec de vraies données.
De vrais utilisateurs.
Et de vraies journées de travail.
C’est finalement le seul test qui compte vraiment.
Prochain épisode : comment maintenir un logiciel .NET installé chez plusieurs utilisateurs ?
Une fois NomadBiz réellement déployé, une nouvelle question arrive immédiatement :
comment faire évoluer proprement une application locale dans le temps ?
Dans le prochain épisode, nous pourrons parler de :
- mises à jour automatiques ;
- versioning ;
- migrations SQLite ;
- sauvegardes ;
- logs ;
- remontée des erreurs ;
- déploiement progressif ;
- gestion des anciennes versions.
Parce qu’une migration ne sert pas simplement à changer de technologie.
Elle doit aussi permettre de repartir sur une base saine pour les prochaines années.
🎬 Épisode 8 : comment maintenir et mettre à jour un logiciel .NET installé chez plusieurs clients sans recréer les problèmes du passé ?