Économie numérique 15.07.2026

Bilan consolidé : trois sites, trois chiffres

4 Min. de lecture

Trois sites, trois instances ERP, trois chiffres. Lorsque le conseil d’administration demande le chiffre d’affaires trimestriel, chaque site fournit un montant différent. La réconciliation ne peut se faire qu’au prix de plusieurs jours de travail manuel en contrôle de gestion. Ce n’est pas de la négligence. C’est une décision d’architecture que personne n’a consciemment prise il y a des années. Qui gère des filiales au-delà des frontières nationales connaît le choix entre souveraineté locale et vision centrale. Cela ne doit pas forcément être l’un ou l’autre.

Les points clés en bref

Le mauvais choix. Imposer une centralisation coûte l’adhésion sur le terrain. Tout laisser en décentralisé coûte la vision groupe.
La troisième voie. Une instance propre à chaque site, des données de référence pilotées de manière centrale. Une gestion des données fédérée plutôt qu’un système unifié.
La décision. Trois éléments la portent : le propriétaire, l’orientation et la règle de conflit pour chaque jeu de données.

En lien :Le piège de la maintenance ERP dans les PME / Quand l’agent comptabilise lui-même la facture fournisseur

Quand chaque filiale cultive sa propre vérité

Ce scénario se répète dans de nombreuses PME en croissance. Un grand client est créé au siège. Trois jours plus tard, la filiale passe commande sous un numéro client différent, un troisième site applique des délais de paiement divergents. Personne n’a sciemment enregistré une erreur. Le système le permet simplement.

Le même phénomène se produit avec les articles, les fournisseurs et les prix. Ce qu’un site considère comme un seul article représente ailleurs dix variantes. Lors de la clôture groupe, ces mondes entrent en collision. L’écart coûte régulièrement plusieurs jours de réconciliation au contrôle de gestion à chaque période. Au final, la question se pose : à qui appartient réellement un jeu de données ?

Centralisé ou décentralisé, les deux ont leur prix

Deux réponses sont d’usage. Tout imposer de manière centralisée garantit un reporting propre, mais les sites perdent leurs spécificités locales et s’enlisent. Chacun fait sa propre chose satisfait tout le monde sur place, mais la maison mère y perd alors le fil. La troisième voie tranchent selon des critères plutôt que par principe.

Critère	Centralisé	Décentralisé	Fédéré
Souveraineté locale	faible	élevée	élevée
Vision groupe	élevée	faible	élevée
Acceptation sur place	faible	élevée	moyenne à élevée
Intégration post-acquisition	lente	quasiment nulle	intégration plus rapide

Gestion des données fédérée, expliquée en une phrase

Chaque succursale travaille dans une instance propre sur un schéma de données indépendant. Les champs locaux, les types de documents propres et les extensions locales restent préservés. Le siège ne définit centralement que les données maîtres partagées : numéros clients centraux, noyaux d’articles ou logiques tarifaires, tandis que la logique de stockage locale reste locale. Trois déterminations soutiennent ce modèle. Qui possède un jeu de données, dans quelle direction il est synchronisé et quelle règle prime en cas de conflit.

Un exemple concret : des clients plutôt qu’une instance uniforme

Un exemple issu de l’espace germanophone est fourni par l’éditeur de logiciels autrichien Multidata. L’approche s’appelle concept de client (Klientenkonzept), mise en œuvre sur la plateforme MD-Premium. Les entreprises créent des instances propres pour les organisations pays ou les succursales, chacune sur son propre schéma de données avec une flexibilité locale. Elles définissent centralement quelles données sont partagées et comment elles sont synchronisées.

Deux nuances gardent l’image juste. Le modèle est une plateforme programmable au sein de son propre entreprise, pas un produit cloud qui résout la question via un hyperscaler. Et le cadre fiscal différent de plusieurs pays est le contexte dans lequel le système rend techniquement possible la représentation des exigences locales. L’évaluation fiscale elle-même reste du ressort des experts sur place.

Les erreurs qui font échouer la fédération

La fédération échoue rarement à cause de la technique. Elle échoue à cause de règles absentes, toujours aux mêmes endroits.

Ce qui casse

Aucun propriétaire par donnée de référence, personne ne tranche en cas de conflit
L’extension locale dévore le schéma central commun
La synchronisation ne s’effectue qu’au démarrage, puis les données divergent

Ce qui fonctionne

Séparation claire entre champs partagés et locaux
Un responsable désigné par domaine de données de référence
Règles de synchronisation fixes avec fréquence, direction et logique de conflit

Quatre questions avant la décision

Ces quatre questions distinguent une architecture propre du chaos des données. Celui qui peut y répondre a déjà fait la moitié du travail.

Qui détient, en cas de conflit, les données de référence des clients, articles et fournisseurs ?
Quels champs doivent être identiques à l’échelle du groupe, et lesquels peuvent varier localement ?
À quelle fréquence et dans quel sens les données partagées sont-elles synchronisées ?
À quelle vitesse peut-on intégrer un site racheté ?

L’autonomie locale et la vision centrale ne sont pas opposées. Elles relèvent d’une décision que l’entreprise doit prendre une fois pour toutes. Celui qui ne définit pas les règles les subit quand même. Dans ce cas, chaque site les rédige à sa manière. Au prochain trimestre, le comité de direction recevra à nouveau trois chiffres différents.

Foire aux questions

Que signifie concrètement une gestion fédérée des données dans un ERP ?

Chaque entité travaille dans sa propre instance avec son propre schéma de données. Les données de référence partagées, comme les numéros de client ou les fiches articles, sont gérées et synchronisées de manière centrale, tandis que les champs locaux restent sous la responsabilité du site.

N’est-ce pas simplement un ERP centralisé avec des filiales ?

Non. Un système centralisé impose un schéma commun à tous. Dans le modèle fédéré, chaque site conserve son propre schéma et ses extensions locales, seule la partie centrale partagée est harmonisée.

Quel est l’erreur la plus fréquente lors de la mise en place ?

Le manque de responsabilité claire. Si personne n’est désigné pour trancher en cas de conflit sur une donnée de référence, les données divergent à nouveau malgré une technique irréprochable.