Carve-out SI : la checklist que personne n’ose publier (et qui évite le blackout)

Un carve-out ne ressemble jamais à ce qu’il est sur le papier. Sur le papier, c’est une opération juridique et financière, encadrée par un calendrier, une date “Day-1”, des TSA, des périmètres, des dépendances. Dans la réalité, c’est un exercice de survie opérationnelle. Le risque n’est pas de “prendre du retard”, le risque est le blackout : plus d’accès, plus de messagerie, plus d’ERP, plus de réseau, plus de support, plus de capacité à facturer, produire, livrer. Et ce blackout arrive rarement parce qu’une équipe ne savait pas faire. Il arrive parce que les dépendances sont sous-estimées, que l’identité n’est pas traitée comme un sujet vital, et que les contrats et les responsabilités restent flous jusqu’au dernier moment.

La “checklist” dont tout le monde parle en off est précisément ce qui évite l’accident. Elle n’a rien de glamour, mais c’est elle qui protège le business. Elle oblige à regarder l’IT comme un système vivant, pas comme une collection d’applications. Elle impose de penser Day-1, puis Day-100, avec une logique simple : tenir le service tout de suite, puis reprendre la maîtrise ensuite.

Le mensonge le plus dangereux : “on fera ça après le Day-1”

Le carve-out est souvent vendu comme un événement. En réalité, c’est un tunnel. Day-1 n’est pas une fin, c’est un basculement de responsabilité. Ce qui “marche à peu près” le jour J peut devenir un enfer à J+15 si on a repoussé les sujets structurants : identité, IAM, réseau, contrats, support, sécurité, données. Le piège est psychologique : on met l’énergie sur le jalon légal, et on découvre ensuite que l’exploitation quotidienne n’a pas de propriétaire clair.

Day-1 doit être pensé comme une promesse minimale, et Day-100 comme la reprise en main. Si Day-100 n’est pas cadré avant Day-1, l’organisation reste captive des dépendances historiques, des TSA mal négociés, des accès hérités et des coûts qui dérapent.

Identité : le point zéro, et souvent le point de rupture

Si vous voulez savoir où un carve-out casse, regardez l’identité. Active Directory, Azure AD/Entra, messagerie, MFA, comptes à privilèges, groupes, droits applicatifs, fédération, SSO. Quand l’identité n’est pas traitée comme un produit critique, tout le reste devient fragile.

Le Day-1 exige une question brutale : où s’authentifie l’utilisateur le jour J, et avec quelle politique de sécurité ? Si l’identité reste “chez l’ancien”, chaque incident devient un incident politique. Si l’identité est dupliquée sans méthode, les droits explosent et la sécurité s’écroule. Si l’identité est migrée trop vite sans cartographie, les utilisateurs se retrouvent dehors.

Les entreprises qui évitent le blackout posent une règle simple : identité, accès, MFA et comptes admin sont “priorité absolue”, avant même certaines applications. Parce que sans identité, l’IT n’existe plus.

IAM : ce que les équipes découvrent toujours trop tard

L’IAM n’est pas un outil, c’est la logique de contrôle de l’entreprise. Qui a le droit d’accéder à quoi, à quel moment, avec quel niveau de privilège, et selon quelle trace. Un carve-out fait remonter toutes les erreurs accumulées : comptes partagés, droits informels, accès prestataires non maîtrisés, et “exceptions” devenues la norme.

Le risque Day-1 est double : soit on casse des accès critiques, soit on ouvre trop large “pour être sûr”. Dans les deux cas, on paie. On paie en production si on casse, on paie en sécurité si on ouvre.

Une checklist utile impose une cartographie minimale des accès critiques, une séparation nette des comptes à privilèges, une politique MFA, une gestion des prestataires, et un processus d’attribution/retrait aligné avec RH. Sans cela, Day-1 n’est pas un démarrage, c’est une fuite en avant.

Réseau : quand la connectivité devient un contrat implicite

Le réseau est souvent traité comme “ça marche”. Jusqu’au jour où les routes changent, où les VLAN ne sont plus alignés, où les DNS ne répondent plus, où les proxies filtrent au mauvais endroit, où les tunnels inter-sites deviennent des goulots, où la latence casse l’ERP ou la VoIP. Dans un carve-out, le réseau est une dépendance cachée parce qu’il traverse tout : utilisateurs, usines, agences, data centers, cloud, fournisseurs, liens opérateurs.

Le Day-1 réseau doit répondre à des questions très concrètes : quels sites doivent rester connectés, sur quels liens, avec quelle supervision, quel plan de secours, quelles priorités de trafic, quelles règles de filtrage, quel DNS, quels certificats. Si ces réponses ne sont pas écrites, le carve-out bascule en mode “pompiers”. Et les pompiers coûtent cher.

Données : l’angle mort qui transforme un carve-out en crise juridique

On parle beaucoup d’applications, moins des données. Pourtant, les données sont souvent le vrai périmètre. Qu’est-ce qui part, qu’est-ce qui reste, qu’est-ce qui est partagé, qu’est-ce qui est copié, qu’est-ce qui doit être anonymisé, qu’est-ce qui relève de contraintes légales. Un carve-out mal géré peut créer des fuites de données, des violations contractuelles, ou une incapacité à produire des états financiers.

Le Day-1 impose un minimum : identifier les données critiques, définir qui en est responsable, mettre en place des règles de transfert, de rétention, de sauvegarde, et de preuve. Le Day-100 impose la maîtrise : reprise en main des référentiels, gouvernance des flux, nettoyage des duplications, et sécurisation du data management. Sans cette trajectoire, on continue à “bricoler” des extractions, des partages, des fichiers, et le risque s’accumule.

Contrats : le piège qui explose quand tout “fonctionne”

Même quand la technique tient, le carve-out peut exploser sur les contrats. Licences logiciels, support éditeurs, infogérance, opérateurs, maintenance, hébergement, SOC, outils de sécurité, prestataires applicatifs, contrats locaux par site. Beaucoup de ces contrats ne sont pas transférables, ou pas dans les mêmes conditions. Certains sont mutualisés, donc le prix “unitaire” n’existe pas. D’autres ont des clauses de sortie, des engagements de volumes, des délais de préavis.

Le Day-1 exige une vérité simple : qui est responsable de quoi, qui paie quoi, et qui appelle qui en cas d’incident. Si cela n’est pas écrit, l’incident devient une dispute contractuelle. Le Day-100 exige une renégociation structurée : sortir des TSA quand c’est possible, sécuriser les licences, reconstruire un modèle de support et de maintenance, et reprendre la main sur les coûts.

Un carve-out réussi est aussi une opération d’achats et de juridique. Ignorer cette dimension, c’est s’exposer à une continuité “technique” mais une dépendance “financière” incontrôlée.

Support : le jour où les utilisateurs découvrent que “personne ne sait”

Le support est l’endroit où la vérité se manifeste. Le jour du carve-out, l’utilisateur ne veut pas une architecture, il veut travailler. Si le support n’a pas une base de connaissance, une chaîne d’escalade, des responsabilités, des accès, et une capacité à diagnostiquer, l’entreprise s’effondre en bruit : tickets, appels, frustrations, contournements.

Day-1 support, c’est un dispositif de guerre : ITSM opérationnel, catalogue minimal, procédures de crise, supervision, accès aux consoles, astreintes, escalades, et communication. Day-100 support, c’est l’industrialisation : processus stabilisés, KPI utiles, base de connaissance vivante, et responsabilités claires entre interne et fournisseurs.

Le carve-out qui évite le blackout traite le support comme un produit, pas comme une conséquence.

Day-1 / Day-100 : la méthode qui sépare les carve-outs maîtrisés des carve-outs subis

La distinction Day-1 / Day-100 est un outil de pilotage, pas un slogan. Day-1 doit définir le service minimum viable : identité, connectivité, accès aux applications critiques, sécurité de base, support et supervision. Day-100 doit définir la reprise de maîtrise : sortie des dépendances, fin des TSA inutiles, standardisation, sécurisation, contrats stabilisés, gouvernance et operating model.

Quand Day-100 n’existe pas, le carve-out reste un “entre-deux” permanent. Et un entre-deux permanent est toujours plus cher, plus risqué, plus fatigant.

CTA : pilotage carve-out / carve-in pour éviter le blackout

Un carve-out SI ne se pilote pas uniquement avec un planning. Il se pilote avec une cartographie des dépendances, une gouvernance de décision, une trajectoire Day-1 / Day-100, et une capacité à faire travailler ensemble IT, métiers, achats, juridique, finance, et fournisseurs sans dilution des responsabilités. La checklist qui “n’ose pas être publiée” est justement celle qui protège le business : identité, IAM, réseau, data, contrats, support, sécurité, et ownership clair.

Je suis DSI de transition spécialisé en pilotage carve-out / carve-in. J’interviens pour sécuriser le Day-1, structurer le Day-100, reprendre la maîtrise des dépendances et des TSA, clarifier les responsabilités, et tenir la continuité opérationnelle sans blackout. Je suis disponible pour une nouvelle mission.