Un industriel de onze cents personnes au siège achète un ERP taillé pour onze cents personnes. Puis il rachète un distributeur de vingt personnes dans un autre pays et tente de le mettre sur le même système.
Dix-huit mois plus tard, le distributeur utilise mal l'ERP, et la moitié de son vrai travail se passe dans des tableurs dont personne ne parle en réunion.
Le décalage qui en est la cause
Un ERP enterprise encode des hypothèses d'échelle. Séparation des tâches sur plusieurs rôles, chaînes d'approbation formelles, personnel financier dédié, quelqu'un dont le métier est la donnée de référence. Ces hypothèses sont justes au siège — et absurdes dans une filiale où une seule personne fait les achats, la facturation et la réconciliation.
Forcée sur ce système, la petite entité a deux options. Suivre le processus — une personne cliquant à travers des approbations conçues pour quatre, et tout prenant trois fois plus de temps. Ou le contourner — ce qui arrive réellement.
Le coût n'est pas que la licence. C'est une implémentation pour une entité qui n'en utilisera jamais l'essentiel, des formations sur des flux qui ne correspondent pas à sa façon de travailler, et une taxe permanente sur chaque transaction.
Ce que two-tier veut vraiment dire
Le siège garde son système enterprise — Tier 1 — pour les finances consolidées, le reporting groupe, la conformité, et la complexité qui existe réellement au niveau du groupe.
Les filiales font tourner quelque chose de plus léger — Tier 2 — dimensionné sur leur fonctionnement réel. Souvent en cloud, souvent d'un tout autre éditeur, choisi pour l'adéquation plutôt que pour l'uniformité.
Les deux sont reliés par une intégration définie : les résultats des filiales remontent vers le système groupe selon un calendrier, dans un format convenu.
L'idée-clé : l'uniformité du système n'a jamais été le but. L'uniformité des données rapportées, si — et les deux sont séparables.
Fig. — Standardisez le contrat de données, pas le logiciel.
Où ça s'applique
Les acquisitions. Une entreprise fraîchement acquise a un système qui marche et des gens qui le connaissent. La migrer sur l'ERP du groupe, c'est un an de perturbation — précisément quand vous la voulez concentrée sur son activité. Connecter son système au vôtre, c'est des semaines.
L'expansion géographique. Exigences légales locales, règles fiscales et langues sont souvent mieux servies par un produit local que par la configuration du système global pour un marché à quatre salariés.
Les divisions au modèle différent. Un groupe industriel avec une branche services fait tourner deux métiers différents. Imposer un seul modèle de processus aux deux en dégrade au moins un.
La vitesse. Une nouvelle entité peut être opérationnelle sur un système cloud en quelques semaines. Attendre le déploiement de l'ERP groupe peut prendre des trimestres — pendant lesquels l'entité improvise, et l'improvisation devient permanente.
Ce que ça vous coûte
C'est un échange, pas un gain gratuit — et les coûts sont réels.
L'intégration est permanente. La connexion entre les tiers doit être construite et entretenue, et elle casse quand l'un des deux côtés se met à niveau. Quelqu'un en est propriétaire, pour toujours.
La réconciliation revient, en plus petit. Deux systèmes, c'est deux jeux d'enregistrements qui doivent concorder. Mieux que onze tableurs, moins bien qu'un seul système.
La discipline du plan comptable devient critique. Si les filiales définissent leurs comptes librement, la consolidation devient un exercice de correspondances que personne ne peut auditer. Le groupe doit imposer une structure commune même là où il n'impose pas un système commun — c'est la décision de gouvernance la plus importante de toute l'approche.
La visibilité groupe a du retard. Le reporting consolidé en temps réel est plus dur quand les données arrivent en cadence. La plupart des groupes acceptent le quotidien ou l'hebdomadaire — généralement très bien, à condition de le dire explicitement.
Plus d'éditeurs. Plus de contrats, plus de relations, plus de calendriers de mise à niveau, plus de renégociations à des dates différentes. Petit à l'unité, fastidieux en cumul — et ça retombe sur qui gère les fournisseurs, pas sur l'informatique.
La fragmentation des compétences. Personne dans le groupe ne connaît tous les systèmes, donc le support d'un problème de filiale ne peut pas venir du siège. Soit l'entité est autonome, soit vous payez l'éditeur pour le support — et la seconde option se budgète plutôt qu'elle ne se découvre.
La partie politique
Le dossier technique du two-tier est généralement facile. C'est l'organisationnel qui bloque — et les objections méritent d'être nommées.
L'informatique groupe résiste souvent, et pas sans raison : elle est responsable de systèmes qu'elle ne contrôle pas, en support d'un éditeur qu'elle n'a pas choisi. Cette objection se dissout si la gouvernance est réelle — contrat de données défini, liste restreinte approuvée, propriété claire de chaque intégration. Elle se durcit si les filiales font simplement ce qu'elles veulent.
La direction financière s'inquiète de l'audit. Plusieurs systèmes sonne comme un contrôle plus faible, et ça peut l'être. La réponse : le contrôle vit dans les standards de données et le processus de consolidation, pas dans l'uniformité logicielle — et un two-tier bien gouverné avec plan comptable imposé est plus auditable qu'un système unique que la moitié des entités contourne.
La direction des filiales veut généralement cette approche et le dit rarement, parce qu'argumenter contre la standardisation du siège passe pour de la résistance. Demandez-leur directement quel pourcentage de leur travail se fait hors du système groupe ; le chiffre est l'argument.
Le cadrage qui passe : il ne s'agit pas de donner de l'autonomie aux entités. Il s'agit de ne pas payer pour imposer de la complexité à des opérations qui n'en ont pas.
Le faire marcher plutôt qu'échouer
Définissez le contrat de données avant de choisir tout logiciel. Quels chiffres remontent, dans quelle structure, à quel rythme, dans quelle devise, avec quel arrêté. Par écrit. Chaque système de filiale s'évalue alors sur sa capacité à produire cela — le choix subjectif d'éditeur devient une exigence.
Imposez le plan comptable et les standards de données de référence. Identifiants clients et fournisseurs, codes produits, structure des centres de coûts. Les filiales peuvent être libres de leur fonctionnement interne ; elles ne peuvent pas être libres d'étiqueter ce qui se consolide.
Approuvez une liste restreinte plutôt que le libre choix. Deux ou trois options Tier 2 validées, pré-intégrées, qu'une nouvelle entité adopte sans nouvelle évaluation. La liberté totale produit onze éditeurs et onze intégrations.
Convenez du calendrier de clôture entre les tiers. Les filiales doivent savoir quand leurs chiffres sont dus, et le groupe doit savoir ce qui se passe quand l'une manque l'échéance. Sans cela, la consolidation attend chaque mois l'entité la plus lente, et personne ne peut dire à qui la faute.
Automatisez la remontée. Une consolidation manuelle entre tiers réintroduit exactement le travail de réconciliation que vous vouliez supprimer — c'est la façon la plus courante dont cette approche se dégrade en silence.
Et revisitez le découpage à mesure que les entités grandissent. Une filiale qui triple peut réellement dépasser le Tier 2 — la décision se revoit selon un calendrier, elle ne se défend pas par habitude.
Est-ce fait pour vous ?
La question n'est pas la taille de l'entreprise. C'est la variance.
Si chaque entité fonctionne de façon similaire à une échelle similaire, un seul système est plus simple — et simple vaut beaucoup. Si vous avez un gros siège et de petites entités dispersées, si vous acquérez régulièrement, ou si vous opérez dans des juridictions aux exigences réellement différentes, forcer l'uniformité coûte plus qu'elle ne rapporte.
Il y a aussi une dimension de timing. Les groupes qui adoptent le two-tier délibérément, avant le premier déploiement douloureux, conçoivent le contrat de données calmement. Ceux qui l'adoptent après avoir forcé une filiale sur le système groupe et regardé l'échec arrivent au même endroit — un an et beaucoup de bonne volonté plus tard, avec une filiale méfiante envers la prochaine proposition du siège.
Un test utile : demandez à un responsable financier de filiale quel pourcentage de son travail se passe hors du système officiel. Si la réponse est élevée, vous faites déjà tourner deux tiers. La seule question est de savoir si le second est un système supporté — ou un dossier de tableurs que personne au niveau groupe ne peut voir.
Si la réponse honnête était « un dossier de tableurs », notre pratique ERP transforme le second étage en système supporté que le groupe voit vraiment — demandez comment.
