Remplacer le logiciel de gestion d'un distributeur, sans arrêter l'activité

Le contexte

Un distributeur de vins et d’épicerie fine gère l’intégralité de son activité commerciale, clients, fournisseurs, catalogue, devis et factures, dans un logiciel arrivé en fin de vie. L’entreprise fonctionne, les commandes partent, mais la dépendance est totale et l’évolution impossible.

Le nom du client n’est pas publié ici, faute d’accord écrit de sa part à ce jour.

Le problème

Le remplacement d’un logiciel de gestion est un exercice délicat, pour une raison simple : ce n’est pas un projet informatique, c’est une opération à cœur ouvert sur l’organisation. Trois risques se cumulent.

Le premier est la perte d’historique. Les références clients, les numérotations de factures et les antériorités commerciales ne se jettent pas. Elles doivent être reprises, et reprises juste.

Le deuxième est la rupture de continuité. Une entreprise ne peut pas arrêter de facturer pendant qu’on change son outil.

Le troisième, le plus insidieux, est le remplacement d’une dépendance par une autre. Livrer un logiciel que personne d’autre ne peut reprendre reproduirait la situation de départ.

Les contraintes

• Continuité de la numérotation. Les numéros de factures doivent s’enchaîner sans rupture avec l’ancien système, pour des raisons comptables et fiscales.
• Durée de vie de dix ans. L’objectif annoncé dès le départ : un système qu’un autre développeur peut reprendre dans plusieurs années.
• Mono-utilisateur aujourd’hui, multi-utilisateurs demain. L’entreprise est petite, mais l’architecture ne doit pas interdire sa croissance.
• Données commerciales réelles. Les exports de reprise contiennent des données clients, qui ne sortent pas de leur périmètre.

Mon intervention

Conception de l’architecture, développement, reprise des données, mise en place de la chaîne de vérification automatisée.

L’architecture

J’ai retenu un monolithe modulaire hexagonal, ce qui est moins un choix de mode qu’un choix de maintenance. Concrètement, chaque domaine du métier, partenaires, catalogue, ventes, achats, stock, documents, vit dans son propre module, et la règle est stricte : les règles métier sont pures, isolées de tout accès aux données, et un module n’en connaît un autre que par sa porte d’entrée déclarée.

L’intérêt est double. Les règles pures se testent sans base de données, donc sans montage lourd. Et l’isolation empêche le glissement qui use les applications de gestion sur la durée, quand un calcul de remise finit par dépendre d’un écran d’affichage.

L’application est conçue API d’abord : l’interface web consomme la même interface programmable qu’un futur portail client ou une application mobile. Il n’existe pas de chemin privilégié réservé à l’écran.

La dernière ligne de défense est posée dans la base elle-même, par des règles de cloisonnement au niveau des lignes. Même en cas de défaut applicatif, la base refuse de servir ce qu’un utilisateur n’a pas le droit de voir.

Les choix techniques

Un contrat unique par donnée, servant simultanément à la validation des entrées, aux types du code et à la documentation de l’interface. La donnée est décrite à un seul endroit, elle ne peut pas diverger entre la validation et l’usage.

Une base relationnelle classique avec des migrations versionnées, appliquées en avant uniquement, et inscrites à un journal. Ce n’est pas la solution la plus moderne, c’est la plus restaurable.

Une reprise des données par processus rejouable plutôt que manuel. Les exports du système source passent par une chaîne de normalisation que l’on peut relancer autant de fois que nécessaire, ce qui permet de corriger et de recommencer au lieu de reprendre à la main.

La sécurité

Chaque accès à l’interface programmable est soumis à une vérification de permission, et chaque écriture laisse une trace d’audit.

La différence est ailleurs : des tests automatisés vérifient que ces règles sont réellement appliquées. Une série de tests lit le code source des routes et échoue si l’une d’entre elles n’est pas protégée, si elle demande une permission inexistante, si une lecture réclame un droit d’écriture, ou si une écriture ne laisse pas de trace. D’autres vérifient les invariants de l’architecture : qu’aucun module n’en contourne un autre, que le stock ne se modifie que par le point de passage prévu, que chaque migration est bien inscrite au journal.

Ces tests ne prouvent pas qu’une fonctionnalité marche. Ils prouvent qu’elle est correctement câblée, un défaut qui ne se voit pas à l’usage et se découvre au pire moment. Chacune de ces protections a été validée en introduisant volontairement le défaut qu’elle vise : un test qui n’a jamais échoué n’a rien prouvé.

Le résultat

Le système est en développement actif depuis 2026, avec une chaîne d’intégration continue qui vérifie types, style, tests et compilation à chaque modification. La reprise des données historiques fonctionne et se rejoue.

Je ne publie pas de chiffres de gain à ce stade : le déploiement complet n’est pas terminé.

Ce que ce projet démontre

Reprendre un système existant sans casser l’activité qui en dépend est un cas courant en PME. Il ne s’agit presque jamais d’écrire du code neuf : il s’agit de comprendre un métier que personne n’a jamais formalisé, de récupérer un historique irremplaçable, et de livrer quelque chose qu’un autre pourra reprendre.

Ce projet montre aussi ma manière de traiter la sécurité dans une application de gestion. Les contrôles d’accès ne sont pas une couche ajoutée à la fin, ils sont vérifiés automatiquement à chaque modification. Pour un dirigeant, la traduction est simple : le jour où quelqu’un ajoute une fonctionnalité en oubliant le contrôle d’accès, la chaîne de vérification le refuse au lieu de le mettre en ligne.