7 min de lecture

L’intégration informatique après une acquisition est l’un des domaines où les effets annoncés d’une opération se perdent le plus souvent dans la pratique. Le marché mondial des services d’intégration post-fusion devrait atteindre 9,82 milliards de dollars en 2026, porté par un flux régulier d’opérations et la répétition d’un constat : les enjeux IT ne peuvent pas être traités en marge pendant les cent premiers jours. Pour les DSI, le rôle dans un contexte de fusion-acquisition diffère de celui du quotidien. Il exige des décisions différentes, une communication adaptée et une gestion distincte des risques d’erreurs.

À lire aussiDispersion SaaS : consolider son portefeuille en 2026  /  NIS2 devient opérationnelle : trois décisions clés pour les organes de direction en avril 2026

Pourquoi les intégrations IT post-fusions & acquisitions échouent plus souvent que prévu en 2026

Le constat issu de la pratique de Deloitte est sans appel : dans les transactions incluant des objectifs explicites d’économies IT, les entreprises parviennent rarement à réaliser plus de la moitié des économies prévues au cours de la première année suivant la clôture. Les raisons typiques ne résident pas dans la technologie elle-même, mais dans les hypothèses formulées au moment de la signature de l’accord – des hypothèses que le DSI en charge de l’intégration ne peut vérifier que plusieurs mois plus tard. Parmi celles-ci figurent des déclarations non vérifiées sur le portefeuille de contrats de la cible, une sous-estimation des enjeux liés à l’identité et aux accès, ou encore un contexte insuffisamment approfondi lors de la due diligence.

Le deuxième facteur majeur est d’ordre culturel. Deux organisations IT, chacune avec ses propres processus, outils et modes de décision, doivent fusionner en une seule équipe. Sur le papier, cela semble simple, mais dans les faits, cela se grippe souvent au cours des six premiers mois. Soit parce que l’équipe acquise se perçoit comme perdante, soit parce que le DSI en charge de l’intégration ne parvient pas à trouver le juste équilibre entre pragmatisme et leadership technique. La méthodologie Bain qualifie ce domaine de *value realization* et souligne le lien direct entre le comportement des dirigeants et les résultats financiers concrets après douze mois.

Les trois échéances de l’intégration informatique

Les DSI qui ont déjà mené plusieurs intégrations travaillent avec trois échéances distinctes. La première est le Jour 1. L’entreprise acquise doit être opérationnelle dès le lendemain de la clôture de la transaction. La communication par e-mail, l’accès aux fichiers, les systèmes financiers et la communication avec les clients doivent fonctionner, même si l’intégration proprement dite des systèmes n’a pas encore eu lieu. Le Jour 1, c’est la stabilité, pas la consolidation.

La deuxième échéance est le plan des 100 jours. C’est ici que les grandes orientations sont fixées : quelles plateformes seront achetées, lesquelles seront résiliées, lesquelles seront migrées. Qui occupera quel rôle dans le nouvel organigramme. Quels sites seront rattachés à quelle région cloud. Ces décisions ne sont pas techniques, elles sont organisationnelles et stratégiques. Un DSI qui ne travaille qu’au niveau des détails pendant les 100 premiers jours se retrouvera, au sixième mois, avec une équipe qui ne sait plus où elle va.

La troisième échéance est l’objectif à 18 mois pour la consolidation proprement dite. C’est à ce moment-là que se déroulent les migrations, les résiliations de contrats et le nettoyage de l’architecture. Ce bloc ressemble le plus à un projet classique de transformation informatique, à ceci près qu’il se déroule sous la pression des rapports d’économies annuelles adressés au DAF et au conseil d’administration. Une erreur fréquente consiste à mélanger ces trois échéances. Celui qui tente de consolider dès le Jour 1 met en péril l’exploitation. Celui qui cherche à atteindre l’objectif des 18 mois dans le cadre du plan des 100 jours surcharge son équipe.

La priorité accordée à l’identité et aux accès est l’un des points que les DSI expérimentés en intégration placent systématiquement en tête de liste. Sans un modèle d’identité solide, il n’y a pas de séparation claire des données, pas de pistes d’audit fiables et pas de situation de correction robuste. Celui qui repousse la fusion des tenants Microsoft ou la consolidation Okta au deuxième mois se retrouvera, six mois plus tard, avec des constats dans chaque revue de sécurité. De plus, une architecture d’identité non résolue bloque pratiquement toutes les décisions ultérieures, car les autorisations, les flux de données et les protocoles d’audit en dépendent.

Ce qui devrait être plus souvent vérifié lors de la due diligence

La phase de due diligence avant la signature représente la fenêtre durant laquelle le DSI de l’acquéreur obtient un aperçu de l’IT cible. Le processus classique de due diligence informatique examine les inventaires d’infrastructure, les coûts du cloud, les applications clés et les risques majeurs. Pourtant, trois éléments manquent souvent en 2026 : la prolifération des SaaS, la réalité des niveaux de service et la flexibilité de résiliation.

Le premier point concerne la sous-estimation du portefeuille SaaS. De nombreuses cibles déclarent cinquante à soixante-dix applications officielles. Un audit rigoureux de la gestion des SaaS en révèle souvent le double. Cet écart n’est généralement pas dû à une mauvaise intention, mais simplement à l’angle mort typique que les entreprises ont elles-mêmes avec leurs propres outils. Qui ne clarifie pas ce point lors de la due diligence hérite de la surprise.

Le deuxième point porte sur la réalité derrière les SLA (accords de niveau de service). Les chiffres indiqués dans les contrats reflètent les engagements du fournisseur. La réalité opérationnelle montre si ces engagements sont tenus. Une cible avec une configuration cloud apparemment exemplaire peut, à y regarder de plus près, avoir des SLA contractuels régulièrement non respectés en pratique, sans que des conséquences n’aient été tirées. La phase de due diligence devrait donc examiner les historiques d’incidents, les taux d’échec des changements et les valeurs réelles de disponibilité, et non se contenter des textes contractuels.

Le troisième point concerne la flexibilité de résiliation. Les contrats à long terme avec des délais de résiliation stricts deviennent coûteux lors de l’intégration, car ils limitent les options de consolidation. Une cible avec cinq contrats de sept ans sur différentes plateformes cloud et SaaS coûtera trente pour cent plus cher à intégrer qu’une cible avec des contrats flexibles. Cette réalité des coûts doit être mise en lumière lors des négociations du prix d’achat, et non découverte seulement lors de l’audit post-clôture.

Contexte DACH : Dans les pays germanophones (Allemagne, Autriche, Suisse), la due diligence informatique est souvent menée par des cabinets spécialisés ou des équipes internes dédiées, avec une attention particulière portée aux risques opérationnels et aux coûts cachés, conformément aux normes strictes de gouvernance d’entreprise en vigueur dans la région.

Comment les DSI redéfinissent leur rôle dans le contexte des fusions-acquisitions

Le rôle du DSI (directeur des systèmes d’information) dans un processus de fusion-acquisition (M&A) diffère de celui qu’il occupe en temps normal. En régime de croisière, le DSI pilote l’organisation informatique, tandis que dans un processus M&A, il fait partie d’une équipe dédiée à l’opération, qui inclut également les directions financière, juridique, des ressources humaines et souvent la stratégie. Les décisions sont prises dans des délais très serrés, souvent avec des informations incomplètes. Leurs conséquences n’apparaissent que des années plus tard. Ceux qui n’ont jamais vécu ce rythme risquent d’appliquer des schémas propres au fonctionnement habituel dans un environnement où ils ne sont pas adaptés.

L’erreur d’adaptation la plus fréquente dans un contexte M&A consiste à vouloir résoudre les problèmes avec des méthodes qui fonctionnent en régime de croisière. Une analyse approfondie des besoins, trois mois d’évaluation, quatre mois de mise en œuvre – cela semble propre, mais dans un contexte d’intégration, dix mois sans progrès visible équivalent à un échec face au conseil d’administration et au conseil de surveillance. Les DSI expérimentés en intégration travaillent avec des cycles plus courts et plus rapides, et acceptent que la moitié des décisions devront être ajustées ultérieurement. Le coût de la correction est moindre que celui de la lenteur. Pour beaucoup de DSI, cela représente un changement de paradigme par rapport aux schémas appris dans leur organisation d’origine.

Un aspect souvent sous-estimé au cours des six premiers mois est la communication. Deux équipes, chacune avec son propre langage, ses outils et sa culture, doivent ne faire plus qu’une. Cela nécessite des réunions régulières communes, une clarification claire des rôles et une décision consciente quant aux pratiques à adopter et à abandonner. Traiter l’équipe de la cible comme un simple fournisseur entraîne la perte des talents clés au cours des douze premiers mois. Les coûts indirects liés à la rotation du personnel dépassent régulièrement les économies IT supposées.

Un point qui prendra davantage d’importance dans les discussions avec les conseils de surveillance d’ici 2026 est la souveraineté des données dans le cadre d’opérations transfrontalières. Lorsqu’une entreprise allemande acquiert une cible américaine, ou inversement, la question se pose de savoir où les données sont physiquement stockées et quelles juridictions peuvent y accéder. Le RGPD (Règlement général sur la protection des données), le CLOUD Act américain et des réglementations sectorielles comme DORA (Digital Operational Resilience Act) ou NIS2 (directive européenne sur la sécurité des réseaux et des systèmes d’information) se croisent dans ce domaine. La réponse est rarement purement technique, mais plutôt une décision conjointe entre le DSI, le DAF, les services juridiques et la direction générale.

Le travail sur les contrats au cours de la première semaine suivant la clôture constitue un autre bloc sous-estimé. Chaque contrat avec un tiers lié à la cible doit être examiné : reste-t-il valable après le changement de propriétaire ? Existe-t-il des clauses de changement de contrôle déclenchant une renégociation ? Des révisions tarifaires sont-elles prévues à la date de transition ? Ce travail de détail permet d’éviter de mauvaises surprises coûteuses au troisième mois, lorsque des coûts supplémentaires apparaissent, non provisionnés dans le modèle de l’opération. Les DSI expérimentés en intégration collaborent, au cours des trente premiers jours, avec une petite équipe juridique dédiée exclusivement à ces contrats.

Un dernier aspect souvent négligé au quotidien est la documentation de l’intégration elle-même. Chaque décision, chaque étape de migration et chaque point en suspens doit être consigné de manière traçable. Cela facilite non seulement les audits ultérieurs, mais aussi le travail de l’équipe lorsque, deux ans plus tard, quelqu’un s’interroge sur les raisons d’une décision architecturale particulière. La documentation de l’intégration sert d’assurance contre l’oubli institutionnel. Dans les opérations marquées par une forte rotation du personnel au cours des dix-huit premiers mois, elle préserve le contexte que les individus ne peuvent plus transmettre.

Un point souvent négligé, mais crucial en Allemagne, est l’implication du comité d’entreprise. Toute consolidation IT entraînant des changements de processus ou d’outils pour les employés nécessite une consultation ou une codécision. Découvrir cela seulement au sixième mois retarde le déploiement de plusieurs semaines. Une intégration précoce dans le plan des 100 jours permet d’éviter ces frictions et renforce en même temps l’acceptation au sein de l’équipe cible.

Questions fréquentes

Plus d’articles du réseau média MBF

Source de l’image d’en-tête : Pexels / Khwanchai Phanthong (px:4175028)