Économie numérique 15.07.2026

Deux systèmes ERP après une acquisition : que faire ?

4 Min. de lecture

Le contrat est signé, le consultant est déjà dans le train du retour. Commence alors la partie dont il est le moins question dans l’acte d’achat. L’entreprise rachetée doit continuer à livrer, tandis que la maison mère veut mettre de l’ordre. Sur l’écran du directeur général, deux systèmes ERP tournent en parallèle, sans rien savoir l’un de l’autre. La première décision à prendre n’est pas une question informatique. C’est un test pour savoir si l’acheteur a compris ce qu’il vient d’acquérir. La réponse la plus dangereuse est celle qui semble la plus propre.

Les points clés en bref

Le réflexe coûteux. Migrer immédiatement l’entreprise rachetée vers son propre système semble propre. Souvent, cela détruit précisément ce pour quoi elle a été achetée.
Trois voies. Maintenir en l’état, interfacer ou migrer. La migration pure relève de l’exception, pas de la règle.
Le vrai goulot d’étranglement. L’intégration se décide auprès des personnes clés de l’entreprise rachetée, pas dans la salle des serveurs.

En lien :Racheter plutôt que créer / Année M&A 2026 : opportunités et risques à la sortie

Le réflexe qui détruit la valeur d’achat

La plupart des PME agissent par instinct après la clôture et optent pour la migration. La filiale passe sur l’ERP maison, un seul système, une seule série de chiffres, tout est propre. C’est précisément là que réside l’erreur. Une entreprise rachetée l’a souvent été parce qu’elle sait faire quelque chose que la maison mère ne maîtrise pas. Ce quelque chose ne figure rarement dans une présentation, mais dans des processus rodés et une logique spécifique qu’aucun manuel ne décrit. Qui les efface paie deux fois le prix d’achat.

Trois voies, trois conséquences

Il existe trois options. L’essentiel n’est pas de choisir celle qui semble la plus propre, mais celle dont les conséquences soutiennent l’opération.

Voie	Risque principal	Quand cela reste pertinent
Maintenir en l’état	fige deux mondes, coûte en rapidité et en argent	durée de détention courte, séparation claire
Interfacer	nécessite une responsabilité claire sur les données de référence	processus hétérogènes, filiale dépendante de l’IT locale
Migrer	perte des processus rodés et des collaborateurs	processus fusionnables sans perte

Dans la plupart des rachats de PME, maintenir en l’état avec une date de fin fixe ou interfacer s’avère le choix le moins destructeur. Uniformiser donne une impression de contrôle, et c’est précisément pour cette raison que c’est l’erreur la plus fréquente.

Quatre questions avant de choisir votre ERP

Ces quatre questions peuvent être tranchées autour de la table de la cuisine, bien avant que l’informatique ne rédige sa recommandation.

Combien de temps l’entreprise rachetée doit-elle rester autonome ?
À quel point ses processus diffèrent-ils de ceux de la maison mère ?
Quelle part de son chiffre d’affaires dépend de fonctions que votre ERP actuel ne couvre pas ?
Dans quel délai le premier bilan consolidé doit-il être établi ?

Le goulot d’étranglement ne se trouve pas dans la salle des serveurs

Le directeur informatique de la filiale est assis dans son bureau le premier matin suivant la clôture de l’acquisition, attendant un appel du siège. Si personne ne se manifeste, dès la deuxième semaine, il défend ses processus au lieu de les ouvrir. Les particularités locales résident dans les esprits, pas dans la documentation. Le rythme ne se décide pas dans le planning du projet, mais au moment où les personnes clés de la filiale recommencent à parler librement. Une uniformisation trop rapide les pousse à quitter l’entreprise, une intégration trop lente brûle de l’argent en doublons.

À quoi ressemble concrètement l’intégration

Ceux qui optent pour la voie médiane intègrent la filiale en tant qu’entité distincte et ne pilotent centralement que les données de référence partagées. Une solution consiste à adopter un concept ERP multi-entités. Multidata, par exemple, travaille avec des clients séparés au sein d’une structure commune : la filiale conserve sa gestion des commandes et ne transmet à la maison mère que les données de référence partagées. D’autres groupes résolvent ce point via deux instances reliées par un middleware, ou laissent la filiale fonctionner de manière totalement indépendante pendant une période définie.

Cette approche fonctionne si les processus de la filiale doivent rester autonomes. Elle échoue si, au final, tout doit être uniformisé. Dans ce cas, l’intégration n’est qu’un détour coûteux vers la migration.

Les écueils les plus fréquents

Trois schémas se répètent. La migration est menée comme un pur projet informatique, sans responsable dédié aux processus. Les données de référence sont reportées *sine die* et entrent en conflit lors du premier bilan consolidé. Enfin, les équipes rachetées n’ont aucune nouvelle pendant des semaines, jusqu’à ce que l’incertitude se transforme en résistance. Aucun de ces échecs n’est technique. Contrôler après une acquisition est légitime. Mais un contrôle qui détruit la raison même du rachat n’est pas une intégration.

Foire aux questions

Faut-il toujours migrer l’entreprise rachetée vers notre système ?

Non. La migration n’est qu’une option parmi trois et convient en cas de forte similarité des processus. Lorsqu’ils sont très différents, elle détruit souvent la valeur pour laquelle l’acquisition a été réalisée. Dans ce cas, le maintien en l’état ou l’intégration partagée sont des choix plus judicieux.

Quel est le vrai coût d’un fonctionnement en parallèle ?

Bien plus que le double des licences. Les coûts élevés proviennent de la double maintenance des données de référence, des erreurs aux interfaces et de la question de savoir quel système fait foi en cas de doute. Pour un maintien en parallèle, une date de fin claire est indispensable.

Le sujet ERP doit-il être abordé dès la due diligence ?

Absolument. Dans de nombreuses acquisitions, l’informatique n’a pas voix au chapitre lors de la due diligence : on audite les bilans, pas la compatibilité des systèmes. Anticiper cette question permet de connaître l’effort d’intégration avant la clôture, et non après.