Refonte du système de gestion d'un groupement de 60 sociétés

Cette page décrit la refonte du système de gestion d'un groupement de 60 sociétés : un groupement lyonnais de plus de 60 sociétés associées et d'une cinquantaine de fournisseurs référencés, dans la réfrigération, la climatisation et l'équipement de cuisines professionnelles. Son site et son application de gestion reposaient sur un framework propriétaire monolithique devenu un frein. Nous l'avons remplacé par lots, au forfait, sans arrêter l'activité du groupement.

Le point de départ : un socle immobile

Le groupement est une structure de taille moyenne à l'échelle française, mais il porte les mêmes processus qu'une tête de réseau bien plus grosse : instruire des candidatures d'associés, négocier et renouveler des contrats de référencement annuels avec une cinquantaine de fournisseurs, collecter les déclarations de chiffre d'affaires, calculer les bonifications de fin d'année et conserver les pièces contractuelles qui justifient l'ensemble.

Le site public et l'application de gestion partageaient un même socle : un framework propriétaire monolithique, choisi des années plus tôt et devenu la contrainte principale. Le problème n'était pas la panne — le système fonctionnait tous les jours — mais l'immobilité. Chaque évolution coûtait plus cher que la précédente, les compétences sur ce socle se raréfiaient, et le périmètre fonctionnel s'était figé le jour où le framework avait cessé d'évoluer.

C'est la situation classique d'une structure fédérative sans DSI : le système n'est ni assez cassé pour créer une urgence, ni assez souple pour accompagner le groupement. Alors on contourne — et les contournements finissent par constituer le véritable système d'information.

Ce qui bloquait, processus par processus

Aucun de ces processus n'était absent avant la refonte. Tous existaient — simplement, ils vivaient en dehors de l'outil censé les porter.

Comment le projet a été découpé et séquencé

Une refonte complète se vend facilement en un seul bloc et se livre très mal ainsi. Le projet a été découpé en lots ordonnés par dépendance métier, pas par confort technique : chaque lot devait être utilisable en production avant que le suivant ne commence, et chaque sprint se terminait par une démonstration.

1. 1

   Cadrage et modèle de données

   Ateliers pour écrire les règles telles qu'elles étaient réellement appliquées : statuts d'associé, cycle de vie d'un référencement, périmètre des déclarations, mécanique des barèmes. Livrable : un modèle de données et un périmètre chiffré au forfait, avant la première ligne de code.

2. 2

   Portail et socle d'identité

   Premier lot mis en service : comptes associés et fournisseurs, rôles et droits, données de référence. Sans lui, aucun des processus suivants n'a d'endroit où vivre.

3. 3

   Référencement et gestion documentaire

   Workflows de candidature puis de référencement annuel, avec la GED en regard : contrats, avenants et pièces rattachés au fournisseur et à la campagne, avec recherche dans le contenu.

4. 4

   Déclarations de chiffre d'affaires

   Module de collecte mis en service avant le moteur de calcul, délibérément : il fallait une campagne propre pour donner au moteur une assiette fiable.

5. 5

   Moteur de calcul des BFA

   Dernier lot fonctionnel, celui qui consomme tout le reste. Recette menée en confrontant le moteur à une campagne déjà arrêtée, puis en instruisant chaque écart jusqu'à ce qu'il soit expliqué ou corrigé.

Ce qui a été livré

• Un portail associés et fournisseurs, où chaque partie prenante ne voit que son périmètre.
• Les workflows de référencement : candidature, instruction, contrat annuel, avenants, renouvellement.
• Un module de déclarations de chiffre d'affaires, avec suivi de l'avancement de la campagne.
• Un moteur de calcul des bonifications de fin d'année portant les barèmes réels du groupement.
• Une GED avec recherche dans le contenu des contrats, et pas seulement dans les noms de fichiers.

Les conditions font partie du résultat : forfait ferme, sprints de deux semaines avec démonstration, équipe projet dédiée — chef de projet, développeur senior back-end, développeur front-end — code source remis, et maintenance contractuelle en rythme de croisière. MEKANO est un studio lyonnais qui ne développe que ce type d'applications de gestion pour groupements, coopératives et réseaux d'adhérents : c'est cette spécialisation qui rend un forfait tenable sur un périmètre aussi large.

Les décisions techniques, et ce qui les justifie

La plateforme tourne sur Go, React et PostgreSQL. Aucun de ces choix n'a été fait par préférence esthétique : chacun répond à une contrainte concrète du métier de ce groupement.

Un dernier critère a pesé autant que les autres : la durée de vie. La plateforme précédente n'est pas morte de ses fonctionnalités, elle est morte de son socle. Tout ce qui dépendait d'un éditeur unique a été écarté au profit de trois technologies largement diffusées, pour lesquelles le groupement peut recruter, faire auditer son code ou changer de prestataire.

Ce qui a été difficile

Trois choses, et aucune des trois n'était un problème de développement.

La reprise des données

Les données d'un système vieillissant ne sont pas fausses, elles sont ambiguës : un même fournisseur en plusieurs exemplaires parce que la raison sociale a changé, des contrats sans date de fin, des déclarations rattachées à l'année civile pour les uns et à un exercice décalé pour les autres. La reprise a demandé des arbitrages, pas du code, avec les personnes qui connaissaient l'histoire de chaque cas. C'est le poste qui a le plus consommé de temps côté groupement : il faut le budgéter dès le cadrage.

Les règles que personne n'avait écrites

Le cahier des charges décrivait les barèmes. La pratique en contenait davantage : une exception accordée de longue date à un fournisseur historique, un prorata appliqué de tête depuis des années, une règle d'arrondi jamais formalisée. Elles apparaissent toutes au même moment — quand le moteur est confronté à une campagne déjà arrêtée et que les montants ne tombent pas juste. Les instruire une par une est fastidieux et non négociable : c'est là que se gagne la confiance des associés.

L'adoption, côté fournisseurs surtout

Les associés adoptent vite un portail qui leur simplifie une obligation. Les fournisseurs n'ont aucune raison structurelle de changer d'habitude : déclarer dans un espace dédié leur demande un effort que le mail ne leur demandait pas. La bascule s'est faite en accompagnant la première campagne, en gardant un canal de secours pour les retardataires, et en acceptant qu'une part se fasse encore à l'ancienne. Prévoir ce délai évite de le prendre pour un échec.

Ce que le groupement en retire aujourd'hui

Nous ne publierons pas de pourcentage de gain de temps : l'avant n'a pas été mesuré dans des conditions qui rendraient la comparaison honnête. Ce qui est constatable est d'une autre nature.

• Un montant de bonification se justifie auprès d'un fournisseur depuis la plateforme, sans reconstitution manuelle.
• Une campagne de déclarations a un avancement lisible pendant qu'elle se déroule, et non après coup.
• Un contrat se retrouve par son contenu — une clause, un taux, un nom — et non par le souvenir du nom de fichier.
• Une évolution fonctionnelle se chiffre et se livre dans un sprint, au lieu de buter sur les limites du socle.
• Le code source est chez le groupement, qui peut faire auditer sa plateforme ou changer de prestataire.

La refonte n'a pas supprimé le travail, elle l'a déplacé. Le temps passé à reconstituer, relancer et ressaisir sert maintenant à contrôler, instruire et négocier. C'est un déplacement moins spectaculaire qu'un pourcentage, mais c'est celui qu'un délégué général constate en premier.