Réussir la refonte du système de gestion d'un groupement

La refonte du système de gestion d'un groupement ne se décide presque jamais pour des raisons techniques. Elle se décide parce qu'une campagne de bonifications a pris six semaines au lieu de trois, parce qu'un fournisseur attend le détail d'un montant depuis dix jours, ou parce que la personne qui savait faire tourner la chaîne part en juin. La vétusté logicielle est le terrain, pas la cause.

Le déclencheur n'est presque jamais technique

Les délégués généraux qui nous appellent ne disent pas que leur base est obsolète : ils décrivent un processus qui ne passe plus. C'est une bonne nouvelle pour le projet, car un besoin daté se chiffre et se défend en conseil d'administration, quand une modernisation sans échéance se reporte d'exercice en exercice.

• Un processus annuel — arrêté des ristournes, appels de cotisation, renouvellement du référencement — déborde chaque année un peu plus sur le suivant.
• Le nombre d'adhérents a franchi le seuil au-delà duquel plus personne ne pilote de mémoire ; il se situe le plus souvent autour de cinquante.
• L'éditeur du progiciel historique annonce une fin de maintenance, ou une migration facturée au prix d'un projet neuf.
• Une personne clé s'en va, et la moitié des règles de gestion n'existe que dans sa tête et dans des onglets masqués.
• Une activité nouvelle — marque propre, logistique, adhérents à l'étranger — ne rentre dans aucune structure de données existante.

Ces cinq situations ont une conséquence commune : le projet a une date limite que la direction n'a pas choisie. C'est une contrainte, et c'est ce qui le rend finançable.

Découper par processus plutôt que par module

Le découpage classique reprend l'architecture du logiciel : un socle technique, un référentiel, un module fournisseurs, un module adhérents, puis les états. Cohérent sur le papier, il place en pratique la première mise en service après l'assemblage de tous les morceaux. Nous découpons par processus métier : une chaîne complète, d'un bout à l'autre, mise en production seule.

Ce choix a un coût, et nous préférons l'annoncer : pendant quelques mois, certaines données sont saisies deux fois et le référentiel adhérents se stabilise par itérations. L'alternative revient à payer un an sans rien voir fonctionner, en pariant que le cahier des charges de départ avait raison sur tout.

Le calendrier du groupement n'est pas négociable

Une tête de réseau vit sur un calendrier qu'aucun projet informatique ne déplace. Le plan de lots se construit à partir de ces dates, relevées dès le cadrage avec les personnes que chacune mobilise.

Reprendre dix à quinze ans de données

Un groupement de vingt ans porte un historique que personne n'a jamais nettoyé : adhérents en double, raisons sociales disparues après fusion, familles de produits renommées trois fois, contrats scannés sur un partage réseau. La reprise est le poste le plus systématiquement sous-estimé, et celui qui explique la majorité des dépassements.

1. 1

   Inventaire réel des sources

   Le progiciel historique, les classeurs de campagne, la comptabilité, les contrats scannés et les boîtes mail. La liste constatée est toujours plus longue que la liste annoncée au démarrage.

2. 2

   Trois profondeurs de reprise

   Les données vivantes — adhérents, fournisseurs, contrats en cours — reprises intégralement et nettoyées ; les données de calcul — déclarations, campagnes — reprises sur trois à cinq exercices pour rejouer un arrêté et comparer les croissances ; le reste archivé consultable, sans retraitement.

3. 3

   Réconciliation contradictoire

   Chaque périmètre repris est confronté à une référence externe : totaux comptables par exercice, nombre de contrats actifs, encours par fournisseur. Les écarts sont instruits un par un, jamais absorbés.

4. 4

   Décisions de qualité écrites

   Doublons, SIRET manquants, adhérents radiés puis revenus : chaque règle de nettoyage est décidée avec vous et consignée, parce qu'elle sera contestée un jour.

Nous chiffrons la reprise sur un échantillon réel extrait avant la signature, pas sur une description orale. C'est la seule manière de tenir un forfait sur ce poste.

Ordres de grandeur : durée, séquence et dérive

1. Semaines 1 à 3 : cadrage du premier processus et prototype cliquable. Le livrable est un périmètre écrit, une maquette manipulable et un prix ferme — pas une étude.
2. Semaines 4 à 10 : développement et mise en production du premier processus, par sprints de deux semaines. C'est le moment où un adhérent utilise pour de vrai le nouveau système.
3. Mois 3 à 8 : les processus adjacents, dans l'ordre de leur criticité et des fenêtres disponibles. Chaque lot est cadré avec l'expérience du précédent et reste finançable indépendamment.
4. Mois 8 à 15 : les périmètres périphériques, l'archivage, l'extinction du système historique et la réversibilité — code source, documentation, transfert de compétence.

Pour un groupement de cinquante à quatre-vingts adhérents et une cinquantaine de fournisseurs référencés, le premier processus est en production en six à dix semaines, et la refonte complète s'étale sur neuf à quinze mois. Ce ne sont pas neuf à quinze mois d'attente : c'est un périmètre de plus qui entre en service toutes les six à huit semaines.

Ce qui allonge ces fourchettes n'est presque jamais la technique. Ce sont les règles non écrites à reconstituer, la disponibilité des une ou deux personnes qui les connaissent, et les décisions de gouvernance qu'une refonte oblige à trancher : qui valide un référencement, qui peut corriger une déclaration après clôture, qui voit les montants des autres adhérents.

Comment ces projets ratent

• Le big bang : dix-huit mois de développement, une bascule le temps d'un week-end, et un arrêté annuel à produire trois semaines plus tard sur un système que personne n'a pratiqué.
• Le run en parallèle sans date de fin : l'ancien système reste allumé au cas où, les doubles saisies s'installent, et plus personne ne sait quelle donnée fait foi. La date d'extinction se décide au cadrage, pas à la fin.
• Le progiciel plié de force : six mois de paramétrage pour approcher un barème à tranches que le produit ne sait pas exprimer, puis un développement spécifique quand même, payé une seconde fois.
• Le cahier des charges de quatre-vingts pages écrit avant tout usage : il fige des choix qu'aucun utilisateur n'a éprouvés et devient l'arbitre des litiges, à la place du logiciel.
• La régie sans fin : l'équipe devient une ligne budgétaire mensuelle, sans périmètre opposable ni date de sortie.

Qui écrit ces lignes

MEKANO est un studio de développement lyonnais spécialisé dans les applications de gestion des groupements et réseaux d'entreprises : référencement fournisseurs, déclarations de chiffre d'affaires, calcul des BFA, GED, portail adhérents. Nous travaillons au forfait ferme, par lots, et le code source est livré documenté. La plateforme la plus complète que nous ayons livrée porte l'activité d'un groupement lyonnais de plus de soixante sociétés associées, sur une stack Go, React et PostgreSQL.