Volume 1 - Piloter les M&A avec un decision system
Pourquoi le decision system opérationnel - plus que la seule exécution - détermine la capacité d’une opération de M&A à préserver et créer de la valeur.
Résumé
Toute transaction M&A repose sur une thèse économique : une vision de la valeur actuelle de l’entreprise, de la valeur qu’un nouvel actionnaire ou un nouvel ensemble pourrait créer et des changements nécessaires pour y parvenir. La signature ne valide pas cette thèse ; elle la formalise. C’est ensuite, dans les décisions sur le périmètre, le modèle opérationnel, les applications, les données, les équipes, les fournisseurs, les contrats et les accords de services transitoires (Transition Services Agreements, TSA), que la thèse est progressivement confirmée, précisée, ou fragilisée.
Le point central de cette Perspective est simple : une opération de M&A complexe n’est pas seulement un programme d’exécution. C’est un « decision system » (système de décision) sous incertitude. Les activités réalisent le travail. Les décisions déterminent le travail à réaliser, dans quel ordre, avec quelles contraintes et les options que l’entreprise conserve pour la suite.
Cette distinction est particulièrement visible dans les carve-outs IT : une migration techniquement parfaite peut pourtant détruire de la valeur si elle implémente un périmètre mal défini, prolonge inutilement un TSA, duplique une plateforme ou enferme la future entreprise dans un modèle qu’elle n’a jamais réellement choisi.
La distinction qui change la lecture de l’exécution
Les activités mobilisent des ressources. Les décisions façonnent les résultats.
Dans ce document, nous distinguons volontairement les activités opérationnelles des décisions opérationnelles.
Les activités opérationnelles sont les travaux nécessaires à l’exécution : migrer une application, transférer une équipe, négocier un contrat, configurer un environnement, basculer des données, préparer le Day 1, premier jour d’exploitation après le closing. Leur finalité est la mise en œuvre.
Les décisions opérationnelles déterminent ce qui doit être mis en œuvre, à quel moment, dans quel ordre et sous quelles contraintes. Elles fixent les frontières de séparation ou d’intégration, le degré d’autonomie recherché, la durée acceptable des TSA, les plateformes cibles, la répartition des compétences, les modèles fournisseurs et les options stratégiques à préserver.
La qualité d’exécution reste indispensable. Mais une exécution irréprochable ne suffit pas à corriger les conséquences d’une décision mal fondée. Accélérer une mauvaise décision ne fait qu’atteindre plus vite un mauvais résultat.
Repenser l'exécution : du plan de projet au decision system
Les transactions M&A sont souvent représentées comme une séquence : stratégie, due diligence, signing, closing, Day 1, séparation ou intégration, puis transformation. Cette chronologie permet de fixer les jalons, de coordonner les travaux et de suivre leur avancement. Elle est utile pour piloter un programme, mais ne dit pas à elle seule si les choix mis en œuvre préservent la valeur attendue de la transaction.
Un programme peut tenir ses jalons tout en répliquant une capacité devenue inutile, en prolongeant une dépendance coûteuse ou en engageant une solution qui réduit les options futures. Le planning indique si le travail prévu est réalisé. Pour comprendre la performance, il faut aussi examiner pourquoi ce travail a été choisi et si les hypothèses qui le justifient restent valables. Les découvertes de terrain peuvent alors appeler une révision de la trajectoire et pas seulement une mise à jour des tâches.
En pratique, la connaissance opérationnelle s’enrichit en continu. Des dépendances invisibles pendant la due diligence apparaissent ; les discussions fournisseurs déplacent l’équation économique, les choix d’architecture modifient le Target Operating Model, les contraintes de données, cybersécurité ou d'identité redéfinissent ce qui est faisable. Chaque découverte devrait donc modifier les décisions suivantes, et parfois remettre en cause une hypothèse initiale.
Dans cette perspective, le decision system désigne la manière dont une transaction relie ses hypothèses de valeur aux arbitrages opérationnels, puis les réévalue à partir des faits. Son apport réside dans la lecture conjointe des dépendances, du coût total, de l’autonomie recherchée et des options futures que chaque décision peut ouvrir ou fermer.
Le decision system et ses cinq composantes en interaction
Ces cinq briques interagissent, elles ne sont pas les étapes d’une séquence figée. Le TOM oriente les décisions, mais une dépendance découverte ou une contrainte contractuelle peut conduire à le réviser. L’apprentissage enrichit le paysage opérationnel et invite à revalider les décisions, voire les hypothèses de valeur initiales.
Quatre problèmes du terrain et leurs équivalents IT
Les quatre mécanismes suivants rendent cette interaction visible dans les carve-outs IT.
1
Les frontières réelles dépassent le périmètre juridique
Problème : le “scope” transactionnel n’est pas le scope opérationnel. Une application est bien dans le périmètre à séparer, mais son authentification, ses flux batch, son monitoring et plusieurs comptes de service restent dépendants de services corporate partagés. Découverte tard, cette dépendance transforme une migration simple en mini-programme de désenchevêtrement.
Arbitrage à trancher : pour chaque service partagé, faut-il le séparer, le répliquer, le remplacer ou le maintenir temporairement sous TSA ? Le choix porte sur la frontière de service et le degré d’autonomie, avec leurs conséquences sur le coût, le risque et le calendrier.
2
Le modèle opérationnel gouverne les choix de solution
Problème : un choix IT “pragmatique” peut figer un Target Operating Model non décidé. Pour sécuriser le Day 1, l’équipe reproduit le modèle existant de support, de tooling ou d’hébergement. Le choix paraît technique et temporaire ; il devient ensuite le modèle de référence, avec les mêmes couches, coûts et interfaces que l’organisation voulait pourtant simplifier.
Arbitrage à trancher : faut-il reproduire le modèle de support et d’hébergement existant pour la transition, ou construire directement le modèle cible ? Si une solution transitoire est retenue, quelles capacités conservera-t-on ensuite en interne, auprès de partenaires ou en services mutualisés ?
3
L’équation économique réelle se révèle à mesure que les dépendances apparaissent
Problème : le coût réel de séparation n’est pas contenu dans le seul inventaire applicatif. Un portefeuille semble “migrable” sur la base du nombre d’applications. Puis apparaissent les droits de licences non transférables, les engagements contractuels minimaux, les coûts de reconfiguration, les environnements non documentés et les besoins de run parallèle. L’équation buy/build/migrate change.
Arbitrage à trancher : les coûts de licences, de reconfiguration et de fonctionnement parallèle une fois connus, faut-il maintenir la migration prévue, revoir les solutions et services retenus ou réduire le périmètre ? Le choix doit être comparé à partir du coût total et des besoins de la future entreprise.
4
Les décisions précoces peuvent fermer les options futures
Problème : le Day 1 pousse à décider vite ; certaines décisions deviennent pourtant difficiles à inverser. Un engagement fournisseur long terme, une plateforme choisie pour éviter un risque immédiat ou une migration à l’identique, sans refonte du fonctionnement existant, peuvent réduire la liberté de transformer, d’intégrer une acquisition future ou de changer de modèle de sourcing.
Arbitrage à trancher : faut-il engager dès maintenant la solution cible et le contrat long terme, ou retenir une solution transitoire pour attendre une information déterminante ? Le choix met en balance le coût d’attente, le risque de continuité et les options que l’engagement fermerait.
Ce qui change quand le decision system est bien piloté
Exemple positif - maîtriser les coûts de licences lors d’une séparation
Situation : la thèse M&A prévoit une autonomie rapide et une base de coûts soutenable, sans intégrer pleinement les coûts de transition. Or plusieurs milliers d’utilisateurs dépendent encore de la suite bureautique et collaborative du groupe vendeur, couverte par un accord-cadre unique. Il faut préserver leur accès pendant la séparation, puis les transférer vers un environnement autonome.
Sans decision system : une bascule immédiate oblige à acheter trop tôt les nouvelles licences. Prolonger le dispositif historique retarde l’autonomie. Les équipes IT, achats et transaction risquent de piloter séparément migration, contrats et coûts, créant un double paiement de licences – anciennes licences du vendeur et nouvelles licences de l’entité séparée - mal maîtrisé.
Avec un decision system : les deux parties confrontent la thèse initiale à la réalité opérationnelle : calendrier des vagues de migration, licences réellement utilisées, échéances de renégociation de l’accord-cadre et conditions de continuité transitoire, sous réserve des droits de l’éditeur. Elles retiennent une migration progressive : acheter les nouvelles licences au rythme des transferts et réduire les besoins historiques lorsque le contrat le permet. Le vendeur peut réaffecter certaines licences libérées et préparer l’ajustement de son périmètre. L’entité séparée peut négocier son futur contrat avec l’appui des achats groupe avant la séparation. Un troisième chevauchement contractuel supplémentaire peut apparaître ponctuellement après la séparation, mais le principal enjeu reste le double run.
Impact : une sortie plus sûre et plus prévisible, un double paiement limité aux périodes réellement nécessaires, et une autonomie construite progressivement sans prolonger le TSA par défaut.
Le coût de transition, initialement sous-estimé, devient un arbitrage de valeur partagé : limiter les licences payées en parallèle, préserver la continuité et atteindre un coût récurrent cohérent avec la thèse M&A. Le cap reste l’autonomie et seules des variations matérielles de calendrier, de droits contractuels ou de prix justifient de revoir le séquencement.
Scénarios illustratifs de l’effet économique
Les ordres de grandeur ci-dessous illustrent des mécanismes possibles. Ils ne constituent ni des benchmarks ni des résultats observés sur une transaction.
| Levier | Bénéfice | Conditions de réalisation |
| Réduction du coût de coexistence | Un équivalent de 16% de la dépense annuelle de run évité en coût de transition | Décalage des achats de licences au fil des vagues, sous réserve de facturation proportionnelle. |
| Négocier le contrat autonome avec l’appui du groupe et avant la séparation | 5 à 10% d’un budget annuel indicatif | Travail conjoint avec les achats groupe, à aligner avec le calendrier contractuel du contrat groupe et le calendrier de migration |
| Réaffectation des licences vendeur | A déterminer en fonction de l’environnement du vendeur | Dépend des droits de réaffectation et des dates de révision de l’accord-cadre ; aucune économie immédiate garantie. |
Ce qui est en jeu
Les décisions opérationnelles déconnectées échouent rarement de façon spectaculaire. Elles accumulent plutôt des frictions : solutions transitoires qui deviennent permanentes, TSA qui dépassent leur finalité, architectures qui limitent la transformation, contrats qui réduisent la flexibilité, coûts d’autonomie sous-estimés et synergies qui se matérialisent plus tard.
À l’inverse, lorsqu’une organisation relie en continu intention stratégique, compréhension opérationnelle, Target Operating Model, décisions et apprentissage, la continuité devient un socle de transformation plutôt qu’une contrainte subie. Le système ne cherche pas à éliminer l’incertitude ; il cherche à améliorer la qualité des décisions à mesure que l’incertitude se réduit.
Relier les décisions à la valeur de la transaction
Une transaction complexe est un système de décision sous incertitude, pas seulement un programme de delivery.
Cette lecture change la question centrale. Au lieu de demander uniquement “sommes-nous on track ?”, elle conduit à demander : “les décisions que nous prenons aujourd’hui restent-elles cohérentes avec la thèse M&A, avec ce que l’exécution nous apprend et avec les options que nous voulons conserver demain ?”.
Le decision system devient ainsi le lien vivant entre la thèse transactionnelle et la réalité opérationnelle. Il convertit des hypothèses en choix explicites, confronte ces choix aux faits, puis réinjecte l’apprentissage dans les décisions suivantes.
La perspective proposée porte sur la cohérence entre des décisions interdépendantes : préserver la continuité aujourd’hui, construire l’autonomie et éviter que des choix transitoires ne ferment inutilement les options de transformation de demain.
Une série pour observer les M&A à travers le Digital
Chaque volume traite de questions qui concernent la transaction dans son ensemble, tout en les examinant volontairement sous l’angle du Digital. Notre expérience montre que le Digital concentre de nombreuses dépendances opérationnelles et décisions transverses. Il constitue donc un point d’observation particulièrement pertinent pour comprendre, au delà du seul Digital, l’économie opérationnelle des M&A.
- Volume 1 - Piloter les M&A avec un decision system
- Volume 2 - Définir le périmètre opérationnel réel
- Volume 3 - Choisir pour le Day 1 sans figer le modèle de demain
- Volume 4 - Construire le sourcing IT de la future entreprise
- Volume 5 - Repenser la sortie des TSA de la continuité à l’autonomie
À propos de l’auteur
Michaël Izsak travaille chez Timspirit, à l’articulation de la stratégie, de la finance, des opérations et de la technologie. Cette série s’appuie sur son expérience des carve-outs et des transformations IT, avec l’objectif de partager des enseignements pratiques du terrain.