Qui décide désormais ? Quel outil devient la référence ? Quel processus s’applique ? Quelle équipe garde la main sur tel client ? Que fait-on des habitudes qui fonctionnaient dans chacune des deux entreprises ?
Ces sujets paraissent souvent secondaires au moment de la signature mais deviennent rapidement déterminants.
Pour un DG ou un DAF d’ETI, rapprocher les systèmes d’information demande d’abord de préciser ce que les deux entreprises doivent pouvoir faire ensemble. Un reporting commun, une offre commune et un outil unique ne représentent pas le même chantier.
Quel fonctionnement commun attend-on réellement ?
Une acquisition ne crée pas de valeur au moment où elle est annoncée, elle en crée (ou non) lorsque deux organisations commencent réellement à fonctionner ensemble.
C’est là que les différences de culture, de rythme, de gouvernance et de responsabilité deviennent visibles.
Le véritable sujet n’est pas de réunir deux entreprises. C’est de faire émerger une organisation capable de décider comme une seule.
C’était le point de mon post du 21 octobre. Appliqué au SI, il conduit à regarder le fonctionnement attendu avant de choisir les logiciels à conserver.
La Banque de développement du Canada distingue plusieurs degrés d’intégration dans son guide du 28 avril 2026. Certaines activités peuvent rester séparées pour des raisons stratégiques, géographiques ou juridiques. D’autres nécessitent des fonctions partagées ou un rapprochement plus profond. Il s’agit d’un cadre de conseil, pas d’un calendrier applicable à toute acquisition.
Pour préparer la discussion, trois formulations peuvent aider : ce qui doit devenir commun pour obtenir le bénéfice attendu ; ce qui doit échanger des informations ; ce qui peut conserver son fonctionnement propre. Une même application peut répondre à plusieurs de ces besoins. Le choix se précise donc par usage, avec les personnes qui le connaissent.
Ce qu’une intégration en cours rend visible
Le rapprochement d’ERGO et d’ADB Gjensidige dans les pays baltes permet de distinguer les étapes. ERGO a annoncé la finalisation de l’acquisition le 2 janvier 2026. Son communiqué du 3 novembre indique que la fusion juridique a pris effet le 1er novembre, avec maintien des contrats clients existants. Ces dates ne prouvent ni l’achèvement de chaque migration informatique, ni la réalisation de toutes les synergies.
Entre ces deux étapes, Kristaps Spundins décrit le travail d’intégration dans l’entretien Innovantage publié le 15 octobre. Il précise y être responsable de la transformation chez ERGO et de l’intégration IT, après avoir été directeur informatique adjoint.
Deux observations éclairent la décision. D’abord, la simplification du paysage informatique était une stratégie déjà engagée, dans laquelle s’inscrit l’intégration. Les choix de conservation ou de consolidation suivent cette direction. Ensuite, les jalons dépendent les uns des autres. Un changement sur l’un oblige à revoir les suivants.
Il insiste aussi sur les collaborateurs qui connaissent les contrats, les produits et les relations clients. Acquérir un portefeuille ne suffit pas à conserver cette connaissance. Le témoignage vient de l’assurance, dans trois pays ; il ne décrit pas une ETI industrielle française. Il invite néanmoins à ajouter une question au plan technique : qui sait encore expliquer comment l’activité fonctionne lorsque les systèmes changent ?
Un scénario : vendre ensemble, sans désorganiser le service
Prenons un exemple illustratif, sans lien avec un client X-PM.
Une ETI qui fabrique des équipements acquiert une entreprise de maintenance. L’objectif est de proposer un service sur le parc déjà installé. Les deux sociétés ont des logiciels de gestion différents. L’entreprise acquise dispose en plus d’un outil de planification des interventions, adapté aux qualifications des techniciens et aux engagements pris auprès des clients.
Le DG souhaite une offre commune. Le DAF veut suivre son chiffre d’affaires et sa marge. La DSI doit déterminer les données nécessaires et les échanges possibles. Pour les équipes de maintenance, la priorité reste de planifier les interventions sans perdre les engagements existants.
Trois options méritent d’être examinées.
Tout basculer dans l’outil du groupe. Cette option peut simplifier la cible future. Mais le groupe doit d’abord vérifier que son outil couvre les contraintes de maintenance, identifier les adaptations et faire essayer le parcours aux utilisateurs. Sans cette vérification, la date de migration repose sur une capacité supposée.
Conserver les outils et organiser les échanges utiles. Cette option permet de travailler sur l’offre commune sans attendre le remplacement de chaque application. Elle laisse cependant des échanges à maintenir, des erreurs à traiter et plusieurs environnements à administrer. Ces tâches doivent avoir un coût estimé et un responsable.
Maintenir les activités autonomes. Cette option protège les fonctionnements existants. Elle limite aussi le bénéfice attendu si personne ne peut rapprocher un équipement installé, son client et son contrat de maintenance. L’autonomie doit rester compatible avec le motif de l’acquisition.
Dans ce scénario, la décision pourrait être de conserver provisoirement la planification des interventions, de définir une référence commune pour les clients et les équipements, puis de tester les échanges nécessaires à l’offre. La DSI et les responsables métier en vérifient la faisabilité ; le DG tranche les désaccords entre les activités et accepte, avec le DAF, le coût de coexistence. Ce choix ne suppose pas d’ouvrir tous les accès entre les deux entreprises.
Le test peut suivre un dossier de bout en bout : retrouver un équipement, vérifier le contrat applicable, établir l’offre, planifier l’intervention, facturer puis rapprocher le résultat dans le reporting. À chaque étape, une équipe indique quelle donnée fait foi et qui traite une anomalie. Le DAF vérifie notamment que la marge est calculée avec des règles comparables. La direction commerciale et les opérations confirment qui porte l’engagement envers le client.
Si ce parcours révèle que les contrats ne peuvent pas être rapprochés automatiquement, l’équipe précise le traitement nécessaire et sa charge. La direction peut alors limiter le périmètre initial à une famille d’équipements ou revoir le calendrier. Elle décide sur un fonctionnement observé.
Une fiche pour rendre l’arbitrage explicite
La fiche suivante reprend ce scénario. Elle peut être adaptée avec la DSI, la finance et les responsables des deux activités. Les choix présentés sont des hypothèses de travail.
| Usage attendu | Choix à examiner | Vérification avant décision | Responsabilité à préciser |
|---|---|---|---|
| Identifier le parc chez un même client | Référence commune, avec correspondance vers les anciens identifiants | Un équipement et son contrat sont retrouvés sans ambiguïté | Responsable des données clients et équipements |
| Planifier les interventions | Conserver provisoirement l’outil de maintenance | Qualifications, disponibilité et engagements restent pris en compte | Direction des opérations, avec la DSI pour le maintien de l’outil |
| Suivre le résultat de l’offre commune | Rapprocher les données selon des règles partagées | Chiffre d’affaires et coûts sont rapprochés sur un dossier test | DAF, avec les responsables des données sources |
| Retirer une ancienne application | Décider après vérification de ses usages restants | Dépendances, accès aux historiques et solution de remplacement sont traités | DSI et propriétaire métier de l’application |
Sur petit écran, faites défiler le tableau horizontalement.
Pour chaque ligne, il reste à inscrire les coûts ponctuels, les coûts récurrents, le temps demandé aux équipes, la prochaine date d’examen et la condition qui permet de changer de solution. « Provisoire » devient alors une décision suivie.
Relier deux environnements a aussi un coût
La coexistence n’est pas seulement une idée de calendrier. Microsoft décrit un scénario d’acquisition dans sa documentation Entra, mise à jour le 31 juillet 2026 : les salariés de la société acquise peuvent accéder à des applications partagées tout en gardant leurs comptes dans leur environnement d’origine.
Mais les administrateurs doivent coordonner les politiques de sécurité, suivre les écarts de configuration et gérer des contraintes de droits et de licences. Ce scénario concerne Microsoft Entra et Microsoft 365 ; il ne démontre pas que n’importe quels logiciels peuvent être reliés simplement.
Avant la réalisation d’une acquisition, les échanges et les travaux autorisés doivent par ailleurs être cadrés avec les conseils compétents. Une cible commune sur le papier ne suffit pas à autoriser le partage de données ou l’ouverture d’accès.
Qui peut tenir ce rapprochement ?
Dans le scénario, le responsable du rapprochement fait travailler ensemble les deux activités, la finance et la DSI. Il prépare les arbitrages du DG avec les personnes qui connaissent les exceptions métier. Si un renfort est nécessaire, la fiche de mission peut préciser le fonctionnement attendu et la transmission aux équipes.
De mon expérience, je ne suis pas certain, même si c’est le point dont on parle le plus, que la réussite d’une intégration soit les résultats financiers… mais bien la manière dont les équipes prennent leurs décisions.
C’est le questionnement que je formulais le 21 octobre. Dans votre rapprochement, les équipes savent-elles déjà ce qu’elles doivent décider ensemble, avant de savoir dans quel outil elles travailleront ?