IA locale : la gouvernance avant l’achat de matériel
Benedikt Langer
10 min de lectureQuatre évolutions en deux semaines montrent que l’IA opérée en local va bien au-delà ...
Lire l’article
3 min de lecture
Le Deal-Case chiffre les promesses de bénéfice. L’intégration crée des frictions. Celui qui ne prévoit la période Day-1 à Day-100 qu’en tant que migration IT, démolit souvent en silence la thèse : systèmes en double, propriété floue, promesses client retardées.
Les points clés en bref
- Thèse : L’intégration est le véritable accord. Le jour de la clôture n’est que le coup d’envoi de la phase la plus coûteuse.
- Trois points critiques : propriété des systèmes floue, calendriers de bénéfices sans jalons Stage-Gate et promesses client sans modèle d’exploitation.
- Stage-Gate : Jour‑1 : stabilité, Jour‑30 : droits de décision, Jour‑100 : convergence mesurable des systèmes et des processus – sinon révision de la thèse.
En rapport :M&A-IT-Intégration : les CIOs dans la tension / Le modèle d’exploitation qui survit à la réorganisation
Qu’est-ce que l’intégration post‑fusion ? L’intégration post‑fusion (PMI) est la mise en œuvre contrôlée des systèmes, processus, données et droits de décision après la clôture. Elle vérifie si les promesses de bénéfice du Deal‑Case tiennent dans l’exploitation – avec des jalons Stage‑Gate, la propriété et une convergence mesurable, plutôt qu’un simple état de projet.
La due diligence est souvent plus rapide : l’IA générative synthétise les data rooms et les modèles de synergie sont lancés plus tôt. Le travail d’intégration demeure néanmoins physique. La douleur d’intégration reste physique : personnes, contrats, modèles de données, lignes de base de sécurité. C’est précisément là que le Deal‑Case bascule si le reste optimiste rencontre une réalité opérationnelle.
Où la thèse se brise silencieusement
Trois points de rupture apparaissent dans presque chaque intégration IT post‑fusion. Premièrement le paysage des systèmes : deux ERP, deux magasins d’identité, deux univers de tickets. Deuxièmement les droits de décision : qui arrête une migration quand le client souffre ? Troisièmement l’horloge des bénéfices : la réduction de coûts sans appropriation du processus engendre du travail fantôme.
L’erreur classique consiste à considérer l’intégration comme un simple plan de projet placé après la signature. La thèse nécessite déjà avant la clôture une liste négative : quels systèmes restent doubles, lesquels doivent converger et lesquels des processus clients doivent rester intangibles durant les premiers 100 jours.
Dans les programmes d’intégration, le plus grand destructeur de valeur est souvent la décision retardée à l’interface des deux anciennes organisations. La rapidité sans appropri
Les stage-gates qui protègent le deal-case
Day-1: Identity, accès, processus clients critiques et security-baseline. Pas de big-bang ERP le week-end de closing sans rollback.
Day-30: Decision Rights pour l’intégration: Budget-Stop, Scope-Freeze, Escalation-Owner par domain (Data, Security, Customer, Finance). Sans owners nommés, le comité de pilotage reste un forum de statut.
Day-100: Convergence mesurable: quels systèmes decommissioned, quels processus single-threaded, quels case-effects à effet cash. Ce qui n’est pas mesurable doit être retiré de la thesis. Un report à Q+2 sans update est de l’auto-illusion.
« Les hypothèses du deal sont des hypothèses. L’intégration est le test. Qui ne pilote pas le test n’a fait que signer le deal. »
Ce qui doit déjà être décidé avant le signing
Timeline pilotage de l’intégration
- Pre-Close: Target Operating Model light – Domain-Owner, fenêtres de dual-run, promesses clients qui ne doivent pas être rompues.
- 0-30 jours: Stabilité et Decision Rights avant la feature-roadmap. Kill-switch pour les migrations risquées.
- 30-100 jours: Convergence avec gate-reviews. Thesis-update si le scope ou le timing casse – publiquement dans l’Integration Board.
Contre-position: certains deals exigent délibérément un dual-run, car les contrats clients et la régulation plafonnent le tempo. C’est légitime. Un dual-run sans date de fin et sans cost-owner est en revanche une extension tacite de la thesis – et c’est précisément là que le deal-case brûle de l’intérieur.
Concrètement, cela signifie: chaque ligne de valeur dans le case a besoin d’un integrations-owner avec droit de stop. Le cost-take-out sans process-owner devient une fiction Excel. Les leviers de chiffre d’affaires dans le case sans customer-journey commune et sans base de données restent du communiqué de presse.
La migration de données mérite sa propre negative list. Quelles master data restent duales, lesquelles doivent devenir Single Source of Truth et quels reports peuvent rester incomplets pendant 100 jours? Sans cette clarté, chaque dashboard devient une arme politique.
Security et Identity sont une obligation Day-1. Les accès doubles, les service accounts orphelins et les privilèges flous mangent plus tard plus de budget qu’une phase dual-run prudente. Qui économise ici paie en incidents et audit-findings.
La communication clients fait partie de l’intégration, pas d’un appendice. Quelles promesses de l’annonce du deal sont opérationnellement tenables doit être clair avant le premier sprint commun. Des SLA rompus détruisent le case plus vite que des coûts de licences doublés.
Foire aux questions
Pourquoi le business case d’une transaction échoue-t-il si souvent lors de l’intégration ?
Parce que les promesses de valeur sont modélisées de manière optimiste avant la clôture et gérées sans jalons ni responsabilités après celle-ci. Les frictions résident dans les systèmes et les décisions, pas dans le communiqué de presse.
Quels éléments doivent impérativement figurer sur la liste négative avant la clôture ?
Les systèmes et processus clients qui peuvent ou doivent rester en double pendant les 100 premiers jours. Plus : ce qui ne sera explicitement pas migré. Sans liste négative, le *scope creep* s’installe dans l’exploitation.
Qui doit siéger au comité d’intégration ?
Les responsables de domaine dotés d’un droit de veto : Data, Sécurité, Client, Finance, Tech. Les simples rapporteurs sans mandat décisionnel ne suffisent pas.
Comment gérer le *dual-run* ?
Avec une date de fin, un responsable des coûts et des critères de sortie. Un *dual-run* sans ces trois éléments est une extension déguisée de la thèse d’investissement.
Quand faut-il réviser formellement la thèse d’investissement ?
Dès qu’un jalon n’est pas respecté et que le périmètre ou le calendrier remet en cause les hypothèses du business case. Reporter sans mise à jour, c’est se bercer d’illusions avec Excel.
Plus d’articles du réseau MBF Media
À lire aussi sur Digital Chiefs
Digital ChiefsQuelle commande reste après le déploiement de l’agentDigital ChiefsEngagement en faveur du cloud AI : le rythme de l’investissement devient inconfortableDigital ChiefsContrats RZ rigides affectent l’Energie fluide EnEfGSource de l’image : générée par IA (juillet 2026)