Conduire une séparation informatique après une cession

6 novembre 2026

Une cession vient d’être signée. Situation illustrative : le vendeur doit encore fournir la messagerie, l’ERP, le réseau et le support à l’entité cédée pendant quelques mois. Le contrat prévoit une sortie, mais l’inventaire technique est incomplet, les administrateurs travaillent pour les deux sociétés et certaines interfaces n’ont pas de propriétaire identifié. Le dirigeant demande une date ferme. Le DSI, lui, sait qu’une séparation trop lente prolonge la dépendance, tandis qu’une bascule précipitée peut arrêter la facturation ou ouvrir des accès indus. Son rôle n’est pas de promettre l’indépendance abstraite : il doit rendre chaque dépendance visible, décidée et testable.

Séparer une entreprise, pas seulement des serveurs

Le mécanisme du problème tient aux liens invisibles. Une application peut être transférable, mais dépendre d’un annuaire conservé par le vendeur. Un poste peut fonctionner, tout en utilisant une licence groupe ou une sauvegarde inaccessible après la sortie. Une interface ERP peut transporter des données utiles aux deux parties sans que personne sache qui corrigera son prochain échec. La séparation informatique est donc un programme de continuité opérationnelle, de contrôle des accès et de désenchevêtrement contractuel. Le DSI doit partir des activités critiques — prendre une commande, produire, livrer, facturer, payer — puis remonter vers les applications, infrastructures, données, prestataires et personnes qui les rendent possibles. Commencer par l’architecture cible produirait une vision séduisante, mais possiblement déconnectée du prochain incident.

Transformer le TSA en instrument de pilotage

L’accord de services transitoires, lorsqu’il existe, ne doit pas devenir un refuge. Il faut traduire chaque service partagé en fiche exploitable : périmètre, responsable, utilisateurs concernés, niveau de service convenu, coût, préavis, condition de sortie, données à restituer et preuve attendue. Le dirigeant arbitre alors sur des objets concrets. Faut-il prolonger la paie mutualisée, au prix d’une dépendance supplémentaire, ou basculer avec un dispositif manuel temporaire ? Doit-on reconstruire une interface complexe ou accepter un échange de fichiers contrôlé pendant une période bornée ? Le bon compromis n’est pas toujours la cible la plus élégante. C’est celui qui protège l’activité tout en réduisant une dépendance mesurable, sans transformer une solution provisoire en dette permanente et sans supposer des compétences qui n’ont pas été démontrées.

Construire le plan en cinq décisions

Première décision : nommer un responsable de séparation capable d’arbitrer entre métiers, IT, finance, achats et sécurité. Deuxième décision : établir un registre unique des dépendances, avec un niveau de confiance et une source pour chaque information. Troisième décision : classer les éléments entre transfert, remplacement, maintien temporaire et abandon. Quatrième décision : ordonnancer les vagues selon les dépendances réelles, et non selon la visibilité politique des applications. Cinquième décision : définir pour chaque bascule des critères d’entrée, un test métier, un responsable de validation et un retour arrière praticable. Le DSI ne cherche pas à tout savoir avant d’agir. Il distingue ce qui est vérifié, probable ou inconnu, puis concentre les experts sur les inconnues susceptibles de bloquer une date, d’interrompre une opération critique ou de compromettre la maîtrise des accès.

Traiter l’identité et les données comme deux chantiers directeurs

La séparation des identités commande souvent le reste. Qui peut encore se connecter à quoi après la cession ? Quels comptes techniques utilisent des secrets communs ? Quels administrateurs interviennent dans les deux environnements ? Le RSSI doit imposer une matrice simple : identité, ressource, droit, propriétaire, date de révocation et preuve de contrôle. En parallèle, les données exigent une décision de propriété, de copie, de conservation, de suppression et de traçabilité adaptée au contexte contractuel. Il ne suffit pas d’extraire une base : il faut vérifier sa complétude, ses formats, ses pièces jointes, ses historiques et sa capacité à être restaurée puis exploitée. Les définitions applicables restent celles des contrats et dispositifs concernés ; le projet ne doit ni improviser une règle juridique ni confondre possibilité technique et droit d’usage.

Piloter par preuves plutôt que par pourcentages

Un avancement global à 80 % ne dit pas si l’entreprise pourra facturer lundi. Le comité de direction a besoin d’indicateurs reliés aux risques : dépendances critiques sans propriétaire, services transitoires sans scénario de sortie, comptes privilégiés non revus, applications sans test métier réussi, données non réconciliées, contrats sans décision, bascules sans retour arrière éprouvé. À chaque revue, le DSI présente aussi l’âge des blocages, la décision attendue et son responsable. Une tendance compte davantage qu’un chiffre isolé : les inconnues critiques diminuent-elles ? Les réserves de recette se ferment-elles ? Les accès croisés disparaissent-ils réellement ? Les coûts et délais restent des hypothèses tant que leur base n’est pas confirmée. Ils doivent être recalculés quand le périmètre, la contrainte ou la gravité du risque change.

Refuser les raccourcis qui fabriquent le prochain incident

Trois erreurs reviennent. La première consiste à confondre copie technique et autonomie opérationnelle : un système livré sans support, supervision ni compétence reste dépendant. La deuxième est de repousser la sécurité à la fin, alors que comptes partagés, tunnels temporaires et privilèges d’urgence prolifèrent précisément pendant la transition. La troisième est d’annoncer une date unique sans expliciter les conditions qui la rendent tenable. À l’approche de la sortie, l’arbitrage final doit opposer des scénarios complets : sortir à la date prévue avec des mesures compensatoires bornées, prolonger certains services en assumant coût et dépendance, ou décaler une vague critique pour protéger l’activité. Le dirigeant choisit ; le DSI documente conséquences, limites et réversibilité. Cette discipline rejoint l’approche de DSI EN CRISE : protéger l’exploitation, établir un diagnostic fiable et rétablir des responsabilités explicites avant de prétendre maîtriser programmes, fournisseurs et coûts. Une séparation réussie n’est pas celle qui ferme le plus vite tous les liens, mais celle qui ne laisse aucun lien critique sans propriétaire, échéance ni preuve de sortie.