Réécrire NomadBiz était une étape, maintenant il faut pouvoir le maintenir pendant les dix prochaines années
Depuis le début de cette série, nous avons beaucoup parlé de la migration de NomadBiz de WinDev vers .NET, avec tout ce que cela a impliqué : l’analyse de l’application existante, la migration de la base HFSQL Classic vers SQLite, la reconstruction des écrans, l’intégration de nouvelles fonctionnalités et, bien entendu, les nombreux tests nécessaires pour vérifier que nous n’avions rien perdu en chemin.
Dans l’épisode précédent, nous avons également commencé à mettre des chiffres sur ce travail. Là où nous avions initialement estimé le projet à plus de 80 jours, nous sommes finalement arrivés à environ 19 jours entre la réécriture, les tests, les corrections et l’ajout des nouveautés. Le gain est considérable, notamment grâce à l’utilisation de l’IA, mais ce chiffre ne représente finalement qu’une partie du sujet.
Maintenant que la nouvelle version fonctionne, une question devient beaucoup plus importante pour nous : comment faire pour que NomadBiz soit encore facile à maintenir et à faire évoluer dans cinq ou dix ans ?
Ce serait assez dommage d’avoir fait tout ce travail pour quitter WinDev, repartir sur .NET et SQLite, moderniser l’application et améliorer son architecture, pour finalement recréer petit à petit les mêmes contraintes de maintenance quelques années plus tard.
C’est donc une partie beaucoup moins visible de la migration qui commence maintenant, mais probablement l’une des plus importantes pour la suite du produit.
NomadBiz doit continuer à fonctionner sans Internet
NomadBiz reste avant tout un logiciel destiné à des vendeurs itinérants, dont certains peuvent travailler toute une journée sans disposer d’une connexion réseau fiable. Cette contrainte a guidé une grande partie de nos choix techniques depuis le début du projet et explique notamment pourquoi nous sommes partis sur une application .NET MAUI Blazor Hybrid accompagnée d’une base SQLite locale.
Nous ne voulons pas remettre en question ce fonctionnement avec la nouvelle version. Une fois le logiciel installé, l’utilisateur doit pouvoir démarrer son ordinateur, ouvrir NomadBiz et travailler normalement, qu’il soit connecté à Internet ou non.
En revanche, ce fonctionnement local nous oblige à réfléchir sérieusement à la manière dont nous allons installer et surtout mettre à jour l’application à distance.
Avec quelques utilisateurs, il est encore possible d’envoyer un setup et de demander à chacun de lancer manuellement une installation. Dès que le parc grandit, cette méthode devient rapidement chronophage aussi bien pour nous que pour le client. Si, demain, chaque nouvelle version nécessite une prise en main à distance sur plusieurs dizaines de postes, nous aurons modernisé le logiciel sans réellement moderniser son exploitation.
L’objectif est donc que la grande majorité des installations et des mises à jour puissent se dérouler sans intervention de notre part, tout en conservant la possibilité de prendre la main à distance lorsqu’un cas particulier le nécessite.
Comment nous voulons gérer les installations et les mises à jour
Pour une nouvelle installation, nous souhaitons arriver à quelque chose de très simple : l’utilisateur reçoit un lien, lance un installateur et celui-ci prépare automatiquement tout ce dont NomadBiz a besoin pour fonctionner.
Dans le cas d’un client qui utilise encore l’ancienne version WinDev, cette procédure pourra également intégrer notre outil de migration HFSQL Classic vers SQLite. Nous pourrons ainsi partir de sa base actuelle, en effectuer une sauvegarde, générer la nouvelle base SQLite, lancer nos contrôles puis installer la version .NET.
L’utilisateur ne devrait pas avoir à se préoccuper de la mécanique qui se trouve derrière. Ce qui lui importe est de retrouver ses clients, ses articles, ses factures, ses règlements et son historique dans la nouvelle application.
Pour les mises à jour suivantes, nous voulons mettre en place un système intégré directement à NomadBiz. Lorsqu’une connexion Internet sera disponible, l’application pourra vérifier auprès d’un service hébergé chez nous si une nouvelle version existe. Si aucune connexion n’est disponible, cela ne changera absolument rien au fonctionnement du logiciel et l’utilisateur pourra continuer sa journée normalement.
Lorsqu’une version sera disponible, elle pourra être téléchargée puis proposée à l’utilisateur au moment opportun, par exemple à la fermeture de NomadBiz. Nous aimerions arriver à une expérience très simple, avec une notification indiquant qu’une nouvelle version est disponible et la possibilité de choisir entre une installation immédiate ou une installation à la fermeture de l’application.
Derrière cette action apparemment simple, nous pourrons prendre en charge automatiquement la sauvegarde nécessaire, la mise à jour du programme, les éventuelles évolutions de la base SQLite et le redémarrage de NomadBiz.
Si le système fonctionne comme prévu, l’utilisateur ne devrait finalement presque jamais avoir besoin de se demander comment mettre son logiciel à jour.
La base SQLite doit évoluer en même temps que l’application
C’est probablement l’un des sujets les plus importants à prévoir dès maintenant, car la structure de la base de données va forcément continuer à évoluer avec NomadBiz.
Aujourd’hui, nous disposons d’une certaine structure SQLite, mais il suffit qu’une future fonctionnalité nécessite une nouvelle table ou quelques champs supplémentaires pour que la version de l’application et celle de la base deviennent liées.
Nous allons donc versionner le schéma de la base de données de la même manière que l’application.
Prenons un exemple simple : un utilisateur dispose de NomadBiz 1.2 avec une base en version 8, puis ne se connecte pas pendant plusieurs semaines et passe directement à NomadBiz 1.6, qui nécessite une base en version 12. Nous devons être capables de détecter automatiquement la situation et d’appliquer les différentes migrations nécessaires dans le bon ordre, sans supposer que l’utilisateur a forcément installé toutes les versions intermédiaires.
Cette mécanique est particulièrement importante pour notre cas, puisque le fonctionnement hors connexion signifie justement que tous les utilisateurs ne seront pas nécessairement sur la dernière version au même moment.
Chaque évolution de la structure de SQLite devra donc être décrite de manière claire et rejouable, ce qui nous permettra aussi de reproduire beaucoup plus facilement un environnement client en cas de problème.
Avant qu’une migration importante ne touche à la base locale, nous prévoyons également de créer automatiquement une sauvegarde. L’objectif n’est évidemment pas de partir du principe que nos mises à jour vont échouer, mais simplement de ne jamais dépendre de la chance lorsqu’une opération touche aux données d’un client.
Si la mise à jour se déroule correctement, l’utilisateur continue normalement. Si quelque chose se passe mal, nous devons pouvoir revenir rapidement à l’état précédent.
C’est finalement la même philosophie que celle que nous avons appliquée à la migration WinDev vers .NET : nous préférons prévoir le retour arrière avant d’en avoir besoin plutôt que d’essayer de l’inventer dans l’urgence.
Installer à distance ne doit pas vouloir dire prendre la main sur chaque poste
La prise en main à distance restera forcément un outil utile, notamment pour accompagner une première installation complexe, résoudre un problème spécifique ou intervenir sur une machine qui se comporte différemment des autres.
En revanche, nous ne voulons pas qu’elle devienne une étape obligatoire du fonctionnement courant.
Notre objectif serait plutôt de réserver l’intervention humaine aux cas qui en ont réellement besoin, tandis que l’installation standard, les mises à jour et les migrations habituelles seraient automatisées.
Pour le premier déploiement d’un client, nous pourrons par exemple préparer un package qui contient tout le nécessaire pour installer NomadBiz, reprendre automatiquement les paramètres indispensables et déclencher la migration des données. Une fois cette première étape réalisée et validée, les versions suivantes seront gérées par le mécanisme de mise à jour intégré.
Cette approche nous permettra aussi d’accompagner progressivement des parcs plus importants. Installer une application sur deux postes à la main n’est pas réellement un problème ; devoir refaire la même manipulation sur cinquante machines à chaque version en devient un.
Nous voulons aussi savoir quelles versions sont réellement utilisées
Un autre avantage de cette nouvelle architecture sera de pouvoir améliorer notre suivi du parc installé.
Il ne s’agit pas de faire remonter les données commerciales contenues dans NomadBiz. Les bases restent locales et nous n’avons aucun besoin de récupérer les clients, les factures ou le chiffre d’affaires de nos utilisateurs.
En revanche, savoir qu’un poste utilise NomadBiz 1.3 alors que la dernière version est la 1.6, qu’il possède un schéma SQLite ancien ou que sa dernière mise à jour ne s’est pas terminée correctement peut faire gagner beaucoup de temps lorsqu’une demande de support arrive.
Nous souhaitons donc prévoir une remontée technique minimale, qui nous permette de connaître l’état de l’installation sans accéder au contenu métier du logiciel.
Cela permettra notamment d’éviter le classique échange où l’on commence par demander à l’utilisateur quelle version il utilise, puis où l’on découvre après plusieurs minutes que le problème avait déjà été corrigé dans une mise à jour qu’il n’avait jamais installée.
Les logs doivent nous permettre de comprendre ce qui se passe réellement chez le client
La journalisation fait également partie des choses que nous voulons améliorer dans la nouvelle version.
Lorsqu’une application fonctionne sur notre poste de développement mais qu’un utilisateur rencontre un problème que nous n’arrivons pas à reproduire, nous devons disposer d’informations suffisamment précises pour comprendre ce qui s’est produit.
NomadBiz pourra donc conserver localement des informations techniques sur les erreurs rencontrées, la version du programme, la version de la base et l’opération qui était en cours. En cas de demande de support, l’utilisateur pourra nous transmettre ces éléments afin que nous puissions analyser le problème beaucoup plus rapidement.
Cela paraît assez basique, mais c’est typiquement le genre de sujet que l’on repousse facilement lorsqu’on développe une application, avant de perdre beaucoup plus de temps quelques années plus tard lorsque le nombre d’installations augmente.
Nous ne déploierons probablement pas toutes les nouveautés partout immédiatement
La refonte nous donne également l’occasion de revoir notre façon de publier les grosses évolutions.
Pour une correction simple, nous pourrons évidemment mettre rapidement une nouvelle version à disposition. Pour une fonctionnalité métier importante, nous préférerons probablement commencer avec quelques utilisateurs pilotes, récupérer leurs retours dans des conditions réelles puis élargir progressivement le déploiement.
Cela permet de découvrir les problèmes que nos propres tests n’ont pas forcément révélés, sans prendre le risque de mettre toute la base utilisateur dans la même situation.
Nous réfléchissons également à rendre certaines futures fonctionnalités activables indépendamment de la version du logiciel. Cela permettra par exemple d’ouvrir une nouveauté à quelques utilisateurs, de vérifier son comportement et son intérêt, puis de la généraliser lorsqu’elle aura été suffisamment éprouvée.
Si un problème apparaît, nous pourrons aussi la désactiver sans devoir nécessairement revenir sur l’ensemble de la version.
Ce qu’il reste concrètement à construire
La réécriture de NomadBiz est donc loin de se limiter à la nouvelle interface que nous montrons depuis quelques épisodes. Maintenant que le cœur du logiciel fonctionne, nous allons progressivement ajouter toute la mécanique nécessaire pour pouvoir l’exploiter correctement dans le temps.
Nous prévoyons notamment un installateur unique, un système de mise à jour automatique qui fonctionne dès qu’une connexion est disponible, le versioning conjoint de NomadBiz et de son schéma SQLite, la sauvegarde avant les migrations importantes, un mécanisme de retour arrière, des logs techniques plus complets et une vision minimale des versions réellement installées chez nos utilisateurs.
Nous conserverons bien entendu la possibilité d’intervenir à distance lorsqu’un poste présente un cas particulier, mais cette intervention ne doit plus constituer le fonctionnement normal d’une mise à jour.
À terme, la meilleure indication que cette partie du projet fonctionne sera probablement que nos utilisateurs n’en parlent jamais. Ils verront qu’une nouvelle version est disponible, l’installeront et continueront à travailler.
De notre côté, nous saurons que nous avons une sauvegarde, que la base est sur la bonne version et que nous pouvons diagnostiquer ou restaurer la situation si quelque chose se passe mal.
C’est probablement là que se mesurera vraiment la réussite de notre migration
Nous avons beaucoup communiqué sur les 19 jours nécessaires à la réécriture, aux tests et aux nouveautés, parce que le gain par rapport aux plus de 80 jours estimés initialement est forcément spectaculaire.
Pour autant, je pense que le vrai résultat de cette migration se verra davantage dans quelques années.
Si nous pouvons continuer à faire évoluer NomadBiz rapidement, publier une version chez plusieurs dizaines d’utilisateurs sans devoir intervenir sur chaque poste, comprendre facilement un incident et faire évoluer la base sans craindre chaque modification, alors la migration aura réellement apporté quelque chose.
À l’inverse, si nous nous retrouvons dans cinq ans avec un logiciel .NET que personne n’ose modifier parce qu’on ne sait pas ce qu’une mise à jour peut casser, nous aurons simplement déplacé le problème.
C’est aussi une leçon que nous garderons pour les projets de nos clients. Lorsqu’on parle de migration d’une application métier, la technologie cible est évidemment importante, mais ce n’est finalement qu’une partie du sujet. Il faut également réfléchir très tôt à la manière dont la nouvelle application sera installée, mise à jour, diagnostiquée et maintenue dans le temps.
Migrer un logiciel ne devrait pas seulement permettre de sortir d’une technologie devenue contraignante. Le vrai objectif est de retrouver suffisamment de liberté pour continuer à le faire évoluer sereinement pendant les années qui suivent.