Réunifier deux DSI après une fusion sous contrainte

6 novembre 2026

Illustration originale — Réunifier deux DSI après une fusion sous contrainte

Le lundi où deux vérités deviennent un risque

Situation illustrative : trois mois après une fusion, le comité exécutif demande au nouveau DSI de ramener les deux organisations IT à une seule. En pratique, chaque DSI dispose de son annuaire, de ses contrats, de son centre de services, de ses règles de cybersécurité et de son portefeuille de projets. Un même incident reçoit deux niveaux de criticité ; deux équipes pensent piloter la reprise ; un fournisseur attend une décision contractuelle tandis qu’une migration présentée comme acquise n’a ni capacité confirmée ni critères de réception communs. Le dirigeant ne doit pas « intégrer plus vite ». Il doit empêcher qu’une simplification administrative ne détruise les protections opérationnelles.

Le vrai problème n’est pas l’organigramme

Réunir deux DSI commence rarement par choisir qui dirigera quelle équipe. Le mécanisme dangereux se situe ailleurs : les responsabilités sont redessinées avant que les dépendances soient comprises. Une application peut appartenir à une entité, dépendre d’un hébergement exploité par l’autre et utiliser un contrat dont le préavis arrive avant la migration prévue. Une politique de sécurité peut être plus exigeante, mais reposer sur un outil que le groupe souhaite abandonner. Un programme ERP peut afficher une date commune tout en mobilisant deux fois la même compétence rare.

Le DSI doit donc dissocier quatre décisions : qui rend le service aujourd’hui, quelle cible sera retenue, quand la bascule devient acceptable et qui assume le risque entre-temps. Les confondre produit des zones grises. Les séparer permet de nommer un responsable pour l’existant sans préjuger de l’architecture finale. La continuité cesse alors d’être une promesse collective pour devenir une obligation pilotable.

Construire une vérité minimale, pas un inventaire parfait

La première étape consiste à rapprocher les commandes, contrats, plannings, applications, infrastructures et initiatives locales. Chaque travail reçoit un identifiant conservant son origine, un sponsor, un responsable opérationnel, une échéance, des dépendances, une charge résiduelle et un résultat attendu. Le PMO ne cherche pas à embellir le portefeuille : il rend visibles les travaux que les deux anciennes DSI comptaient différemment.

Cette base n’a pas besoin d’être exhaustive pour déclencher un arbitrage. Si deux programmes exigent simultanément la même équipe de migration, la contradiction est déjà démontrée. Le DSI peut décider avant de connaître chaque détail, à condition de documenter ce qui est certain, ce qui reste à vérifier et la date à laquelle l’incertitude devient bloquante. Les protections urgentes — sauvegardes, supervision, renouvellements indispensables, traitement des vulnérabilités critiques — continuent pendant l’examen. La perspective d’une cible commune ne suspend jamais le minimum requis dans la voie actuelle.

Autoriser seulement des fusions conditionnelles

Deux projets semblables ne deviennent pas automatiquement un projet unique. Une fusion n’est recevable que si un responsable accepte le résultat commun, si les critères de réception distinguent l’exigence minimale de l’amélioration souhaitée, et si un calendrier intégré tient avec une capacité confirmée par compétence et par date. Les achats vérifient l’effet sur les commandes et préavis ; les responsables des données et de l’architecture contrôlent les dépendances ; le RSSI précise les protections qui ne peuvent attendre la cible.

À défaut d’une seule de ces confirmations, le travail indispensable reste financé et piloté séparément. Cette règle évite le faux gain classique : supprimer un comité, diviser les budgets par deux et annoncer une synergie alors que les contrôles, migrations et obligations de sortie subsistent. Les économies ne sont reconnues qu’après identification du travail réellement supprimé. Jusqu’à cette preuve, elles demeurent une hypothèse, pas une ressource disponible.

Piloter par décisions et seuils de bascule

Le tableau de bord utile ne se limite ni au nombre de projets ni au taux d’avancement déclaré. Il suit la part des services critiques ayant un responsable unique, les dépendances sans propriétaire, les échéances contractuelles non alignées sur le calendrier technique, la capacité confirmée face à la charge engagée, les critères de réception encore contestés et les risques bénéficiant d’une mesure transitoire financée. Pour chaque bascule, il indique aussi la preuve attendue, le décideur et la possibilité réelle de retour arrière.

Le rythme de gouvernance doit conduire à des choix nommés : maintenir, arrêter, ralentir ou fusionner sous conditions. Un arrêt approuvé n’est pas une sortie achevée ; il peut laisser des coûts, des données à reprendre ou un fournisseur à gérer. De même, une fusion peut réduire le nombre de lignes du portefeuille sans libérer une heure. Le DSI demande donc au PMO de suivre les charges résiduelles et les engagements jusqu’à leur extinction vérifiée.

Écarter les raccourcis qui fabriquent la prochaine crise

Trois erreurs reviennent. La première consiste à imposer trop tôt une technologie « groupe » pour envoyer un signal politique. Sans critères de service, de sécurité et de réversibilité, ce choix déplace le risque au lieu de le réduire. La deuxième consiste à nommer des responsables de cible tout en laissant l’exploitation courante à une responsabilité diffuse. La troisième consiste à présenter toute redondance comme un gaspillage : pendant une transition, certaines duplications achètent de la continuité et donnent le temps de tester la reprise.

L’arbitrage final ne porte donc pas sur la vitesse abstraite de l’intégration. Il oppose le coût explicite d’une coexistence temporaire au risque documenté d’une convergence prématurée. Le dirigeant peut retenir une cible moins élégante, prolonger un contrat ou ralentir un programme si cette décision protège une échéance critique et conserve une capacité de retour. À l’inverse, il doit arrêter les travaux dont le bénéfice, le sponsor ou les moyens ne résistent pas à l’examen.

C’est ici que l’approche de DSI EN CRISE trouve sa pertinence : protéger l’activité, établir un diagnostic fiable, rétablir les responsabilités et reprendre la maîtrise des coûts, des fournisseurs et des programmes. Réunifier deux DSI ne consiste pas à proclamer l’unité. Il faut créer les conditions vérifiables dans lesquelles une seule décision, un seul engagement et un seul responsable peuvent enfin remplacer deux vérités concurrentes.