Consolider plusieurs ERP : l'étape que personne ne chiffre, et qui décide de tout

Un groupe de quatre sociétés, quatre instances du même ERP, une direction qui veut un chiffre d'affaires consolidé. Sur le papier, c'est quatre connexions et une somme.

Dans les faits, le client Dupont porte le code CLI-0042 en France, C00042 en Belgique, 42-CLIENT en Suisse et IT_42 en Italie. Personne n'a jamais décidé cela : chaque filiale a repris ses conventions au moment de sa mise en service, et le sujet n'a jamais eu à se poser tant que chacune pilotait seule.

C'est cette étape-là, l'alignement des référentiels, qui manque dans la plupart des devis. Et elle représente régulièrement un tiers de la charge du projet.

Trois référentiels à aligner, presque toujours les mêmes

Les tiers

Clients et fournisseurs. Le même groupe est présent dans plusieurs sociétés sous des codes différents, parfois sous des raisons sociales différentes. Un client France peut être fournisseur en Italie.

La question à trancher est : à quel niveau consolide-t-on ? Le siège du groupe, l'entité juridique facturée, ou l'établissement livré ? Les trois réponses sont défendables et donnent trois chiffres différents. Il faut choisir, et le choix appartient à la direction financière, pas à nous.

Les articles

Le même produit porte des références distinctes selon la société, avec parfois des unités différentes : au kilo ici, à la pièce là. Les nomenclatures de familles divergent presque toujours.

Le piège est le regroupement partiel : dix références alignées sur douze donnent un rapport qui a l'air juste et qui sous-estime silencieusement de vingt pour cent sur cette famille.

Le plan comptable

Chaque société a son plan, souvent hérité de son pays. Un compte 706 français n'a pas d'équivalent direct dans un plan belge ou suisse. La consolidation passe par un plan de regroupement : une table de correspondance qui dit quel compte local alimente quelle rubrique consolidée.

Cette table existe rarement au format exploitable. Elle vit dans un classeur maintenu par le contrôle de gestion, avec des exceptions annotées en commentaires.

Ce que nous faisons, dans l'ordre

Nous produisons d'abord la table des écarts. Pour chaque référentiel, la liste des valeurs distinctes par société, et les rapprochements que nous proposons. C'est un livrable, pas une étape interne : le client doit pouvoir le relire.

Nous faisons trancher, par écrit. À quel niveau consolide-t-on les tiers, quelle référence fait foi pour un article, quel compte alimente quelle rubrique. Une personne doit avoir l'autorité de décider, sinon le projet s'arrête à la première divergence, et il y en a toujours une.

Nous matérialisons dans une couche intermédiaire. Les tables de correspondance vivent dans la plateforme, versionnées, avec une date d'effet. Une correspondance qui change en cours d'année ne doit pas réécrire l'historique : le passé garde ses règles, le futur prend les nouvelles.

Nous rapprochons société par société avant de consolider. Le total consolidé ne veut rien dire tant que chaque société ne tombe pas juste isolément. Deux erreurs de signe opposé se compensent parfaitement dans un total, et se voient immédiatement en détail.

Ce que ça coûte, honnêtement

Sur nos projets, l'alignement représente entre un quart et un tiers de la charge quand les sociétés partagent le même ERP, et davantage quand les systèmes diffèrent. C'est plus que l'extraction et plus que la construction des rapports.

C'est aussi la partie qui produit le plus de valeur durable, parce que ces tables de correspondance servent ensuite à tout : au décisionnel bien sûr, mais aussi aux échanges inter-sociétés, aux réconciliations et à la prochaine migration.

Le détail technique qui change l'échelle

Sur du Business Central multi-instances, l'extraction par API atteint vite ses limites : les quotas d'appel sont vite consommés, et un rechargement complet quotidien devient impraticable.

Nous utilisons bc2adls, un composant open source publié par Microsoft, qui exporte les tables de Business Central directement au format Delta dans un lac de données, de façon incrémentale. Les quotas de l'ERP restent disponibles pour ce à quoi ils servent : l'exploitation. La reprise d'historique cesse d'être un problème.

Ce qu'il faut retenir

Si un devis de consolidation multi-ERP ne mentionne ni l'alignement des tiers, ni le plan de regroupement comptable, ni la validation par une personne nommée, ce n'est pas qu'il est optimiste : c'est qu'il chiffre la moitié du projet.

Nous avons mené jusqu'à sept instances de Business Central et sept CRM sur un même modèle. À chaque fois, la difficulté était la même, et elle n'était jamais la connexion.