1. Définir la décision de sortie
Un conseil d’administration n’approuve pas la sortie du TSA simplement parce qu’un contrat atteint sa fin prévue. Il approuve le transfert de la responsabilité opérationnelle d'un prestataire temporaire à une capacité contrôlée par le bénéficiaire. La décision nécessite la preuve que l'entreprise peut continuer à servir ses clients, à collecter des espèces, à respecter les obligations réglementaires, à protéger les données et à produire des informations financières fiables après la fin du service.
Chaque service TSA nécessite donc un résultat défini pour le destinataire. La sortie de paie signifie que les employés sont payés avec précision et à temps à partir du système autorisé du destinataire. La sortie financière signifie que les soldes d’ouverture, les données de base, les interfaces, les contrôles et les rapports sont rapprochés. La sortie de la plate-forme client signifie que les commandes, les droits, la facturation et le support fonctionnent sans dépendance non approuvée à l'égard du fournisseur. Un déploiement technique sans le résultat opérationnel complet est incomplet.
Le conseil d’administration devrait gouverner un portefeuille de décisions de sortie. Les services diffèrent en termes de criticité, d'architecture, de sensibilité des données, de complexité des changements et d'options de secours. Un service de reporting à faible risque peut sortir par un simple transfert. Un service d'identité, de fabrication, de trésorerie ou client étroitement intégré peut nécessiter une double exécution contrôlée, une capacité de récupération indépendante et une fenêtre de basculement approuvée par le conseil d'administration.
L'unité d'approbation doit être suffisamment petite pour exposer les risques et suffisamment grande pour représenter un service complet. Approuver une demande seule peut faire passer à côté du travail manuel, des flux de données et des contrôles. Approuver une fonction entière en même temps peut masquer une dépendance dangereuse parmi de nombreuses activités complètes. Les résultats des services fournissent un niveau intermédiaire pratique pour la gouvernance.
La décision de sortie doit indiquer le service, le propriétaire, la tolérance à l'impact, la preuve d'acceptation, la dépendance résiduelle, les imprévus, la période maximale de retour en arrière et les conséquences financières. Cela crée un dossier qui peut résister à l’examen minutieux des opérations, des audits et des investisseurs.
2. Comprendre ce qu'un TSA fait et ne résout pas
Un TSA attribue des responsabilités temporaires après l’achèvement légal. Il peut préserver l'accès aux personnes, aux systèmes, aux installations, au traitement des données et aux routines opérationnelles pendant que le destinataire construit ou achète des remplacements. Il peut également définir les niveaux de service, la tarification, le contrôle des modifications, la gestion des incidents, la responsabilité et la résiliation.
L'accord ne crée pas la capacité finale du destinataire. Il peut conserver une configuration héritée conçue pour un groupe intégré. Cela peut exclure des projets, des améliorations, de nouveaux marchés, des modifications de sécurité ou des travaux réglementaires. Les niveaux de service peuvent refléter des efforts raisonnables plutôt qu'une norme de service géré commercial. Le personnel du fournisseur peut donner la priorité aux activités retenues lorsque les ressources sont limitées.
Le planning contractuel peut dissimuler des couplages techniques. Un service nommé peut s'appuyer sur plusieurs applications, interfaces, bases de données, licences, comptes et équipes. Un fournisseur peut avoir besoin d'accéder aux données du destinataire après la fermeture apparente du service, car un autre service reste actif. Un système de réception peut techniquement fonctionner alors que son processus de traçage, de rapprochement ou de récupération des données reste incomplet.
Le programme opérationnel doit donc décomposer le TSA en capacités et dépendances. L’expiration des contrats reste une contrainte importante, mais l’état de préparation est prouvé par le modèle opérationnel du bénéficiaire et les preuves testées.
Les deux parties doivent conserver une interprétation unique du calendrier. Des litiges surviennent souvent lorsqu'un destinataire considère une activité comme incluse et que le prestataire la considère comme un travail de projet ou un service omis. Un catalogue contrôlé, un journal de décision et un processus de changement réduisent l'ambiguïté avant qu'elle n'affecte la continuité. Les désaccords commerciaux doivent être intensifiés sans retarder la protection opérationnelle urgente.
3. Créez une carte des services et des dépendances
La référence de sortie doit répertorier chaque service, destinataire, fournisseur, propriétaire de service, processus métier, application, interface, ensemble de données, domaine d'identité, installation, fournisseur, contrôle et juridiction. La carte doit inclure les services fournis dans les deux sens et le soutien informel qui peuvent ne pas apparaître dans le calendrier signé.
La cartographie doit commencer par les services commerciaux importants et les résultats client. La FCA exige que les entreprises concernées identifient les personnes, les processus, la technologie, les installations et les informations nécessaires pour fournir des services commerciaux importants, y compris les tiers concernés. Ses observations de mars 2026 mettent l’accent sur la cartographie dynamique, la gouvernance et les mesures d’impact quantitatives ainsi que sur les tolérances temporelles. [1] Ces principes fournissent une discipline de conception utile même lorsque les parties à la transaction se trouvent en dehors du périmètre de la FCA.
Les dépendances doivent être directionnelles. Une plateforme de facturation peut dépendre des données de base client d'un système, de la tarification d'un autre, des services d'identité du fournisseur et d'une interface bancaire contrôlée par le destinataire. La séquence de sortie doit respecter ces directions. Le retrait de l’identité avant la migration des applications dépendantes peut entraîner un échec immédiat.
Chaque dépendance doit enregistrer la source des preuves et leur fiabilité. Les documents d'architecture peuvent être obsolètes. Les analyses de configuration, les journaux d'accès, la surveillance des interfaces, les enregistrements de contrats et les flux de données rapprochés fournissent des preuves plus solides. Les dépendances inconnues doivent être traitées comme des risques de programme avec des actions de découverte et des propriétaires.
La carte doit également distinguer les dépendances matérielles et logicielles. Une dépendance matérielle empêche le fonctionnement du service, tel que l'authentification ou un flux de données requis. Une dépendance logicielle réduit l'efficacité ou l'assurance, comme un outil de reporting qui peut être remplacé temporairement par un processus manuel contrôlé. Cette distinction soutient les décisions de séquence, de contingence et de financement.
| Champ | Enregistrement requis | Preuve | Quitter l'utilisation | Signal de panne |
|---|---|---|---|---|
| Résultat du service | Résultat client ou contrôle délivré | Schéma des processus et approbation du propriétaire | Définit l'acceptation | Activité répertoriée sans résultat |
| Dépendance | Système, données, personne, fournisseur ou installation | Scanner, enregistrer, contracter ou interviewer | Détermine la séquence | Composant partagé non documenté |
| Tolérance aux chocs | Perturbations et pertes maximales tolérables | Approbation des risques et test de scénarios | Définit les limites de basculement | Étiquette de gravité générique uniquement |
| Capacité à l'état final | Remplacement appartenant au destinataire ou sous contrat | Conception, enregistrement de construction et contrat | Prouve l'indépendance | TSA copié sans refonte |
| Sortir des preuves | Résultat des tests, rapprochements et contrôles | Dossier de preuves signé | Prend en charge l'approbation | Statut du projet utilisé comme preuve |
| Retomber | Restauration, solution de contournement manuelle ou extension | Plan de relance testé | Limite les inconvénients | La date d'expiration est la seule réponse |
Cadre original. Le registre des services doit concilier l'accord signé, la carte opérationnelle et l'inventaire technologique.
4. Concevez d'abord le modèle opérationnel cible
La conception de la sortie doit commencer par le modèle opérationnel requis après le TSA. Le bénéficiaire doit décider quelles capacités il détiendra, externalisera, partagera dans le cadre d'un accord commercial durable ou abandonnera. Cette décision contrôle l'architecture, les personnes, les contrats, les données et les coûts.
Une copie de l'organisation du prestataire peut être excessive ou incomplète. L’entreprise séparée peut avoir des produits, des juridictions, des clients et des obligations de déclaration différents. Elle peut choisir une plateforme cloud au lieu d'un centre de données répliqué, un service de sécurité géré au lieu d'une équipe interne, ou des opérations régionales au lieu d'un hub de groupe. Ces choix modifient à la fois le chemin de migration et l’environnement de contrôle.
Le modèle cible doit identifier les dirigeants responsables, les propriétaires de processus, les propriétaires de systèmes, les propriétaires de données et les propriétaires de contrôle. La responsabilité d'un service ne peut pas incomber à un bureau de projet après sa sortie. L’organisation durable a besoin de budget, de compétences, de droits d’accès et de droits d’escalade.
Le modèle doit inclure les opérations normales, les volumes de pointe, les incidents, la fin du mois, la fin de l'année, les rapports réglementaires et la reprise après sinistre. Un remplacement qui fonctionne pendant une période de test calme peut échouer en fin de trimestre ou lors d'un incident client. La capacité et la résilience font donc partie de la ligne de base de la conception.
L’autorité de conception doit rester liée à la thèse de la transaction. Une séparation destinée à créer une entreprise plus ciblée et plus agile peut être compromise si le destinataire hérite de tous les processus existants. À l’inverse, une simplification agressive peut supprimer des contrôles ou des capacités dont les investisseurs pensaient qu’elles existaient. Les choix opérationnels doivent concilier le dossier financier et la stratégie divulguée.
5. Traduire le contrat en une architecture de sortie
Le TSA doit être converti en une feuille de contrôle service par service. La portée, les exclusions, les volumes, les niveaux de service, les frais, la durée, les droits d'extension, les règles de modification, les obligations en cas d'incident, les droits d'audit, les conditions relatives aux données, les droits de propriété intellectuelle et l'aide à la résiliation doivent être visibles à côté du plan opérationnel.
Les récents accords publics montrent la diversité des structures. Le TSA modifié de Kenvue avec Johnson & Johnson décrit un délai de période de service général de vingt-quatre mois, avec une prolongation définie lorsque les approbations réglementaires retardent la transition. [2] Le TSA Jacobs et Amentum déposé en 2024 comprend des frais administratifs et des horaires de service formels. [3] Western Digital a révélé que le support de transition pour Sandisk couvrait douze domaines fonctionnels pour des périodes allant jusqu'à dix-huit mois, avec des mécanismes d'ajouts, d'extensions, de résiliation, de gouvernance et de résolution des litiges. [4] Ces documents sont des preuves spécifiques à la transaction de la conception contractuelle, et non des références universelles.
La fiche de contrôle doit identifier la date limite de préavis, le prix de la prolongation, la procédure en cas de prestations omises et les conséquences d'une sortie partielle. Un programme qui découvre une exigence de prolongation après la date limite de préavis perd son pouvoir de négociation.
Les obligations au niveau du service nécessitent des définitions mesurables. Des termes tels qu’assistance matériellement cohérente, raisonnable ou cours normal peuvent être des normes contractuelles appropriées mais fournissent des paramètres de programme faibles. Le plan opérationnel doit les traduire en volumes, temps de réponse, objectifs de récupération, conservation des preuves et seuils de remontée d'informations sans impliquer de droits que l'accord n'accorde pas.
Les jalons du contrat et de la construction doivent être liés. La sélection des fournisseurs, le transfert de licence, l'extraction des données, les tests et le basculement doivent être terminés avant l'arrêt contractuel ou une prolongation approuvée. Les équipes juridiques devraient recevoir des preuves de progrès techniques suffisamment tôt pour pouvoir exercer leurs droits.
6. Traitez la séparation des données comme une transaction contrôlée
La séparation des données va bien au-delà du simple déplacement de fichiers. Les parties doivent déterminer quelles données appartiennent au destinataire, ce que le fournisseur peut conserver, ce qui doit être restreint, quels enregistrements sont partagés et comment le contexte historique sera préservé. Le résultat devrait soutenir les opérations, les droits, l’audit, les litiges, la fiscalité, la confidentialité et les obligations réglementaires.
La carte des données doit couvrir la source, le propriétaire, la finalité, la base juridique, la juridiction, la classification, la conservation, la qualité, la lignée, la transformation et la destination. Il doit distinguer les enregistrements structurés, les documents, les messages, les journaux, les modèles, les sauvegardes et les données dérivées. Les tables partagées et les lacs de données nécessitent souvent une séparation au niveau des lignes ou des attributs plutôt qu'une simple copie de base de données.
Le Bureau du commissaire à l'information du Royaume-Uni déclare que le partage de données à la suite d'une fusion ou d'une acquisition devrait faire partie de la diligence raisonnable, que les principes et la documentation en matière de protection des données s'appliquent et que des conseils techniques sont nécessaires lorsque différents systèmes créent des risques de perte, de corruption ou de dégradation. [5] Ces problèmes se posent également lors des scissions, car les responsabilités en matière de contrôle et de traitement changent.
Les preuves de migration doivent inclure les totaux d'extraction, les règles de transformation, les journaux de rejet, les totaux de contrôle, la vérification des échantillons, le rapprochement avec les enregistrements financiers ou opérationnels, la validation de sécurité et l'acceptation du propriétaire de l'entreprise. La suppression ou la conservation par le fournisseur doit être prouvée séparément. Une importation réussie ne prouve pas une séparation complète ou légale.
Les données historiques peuvent créer un compromis difficile entre l’utilité opérationnelle et le fardeau migratoire. Le destinataire peut avoir besoin d'un historique détaillé concernant le service client, la garantie, les performances du modèle, les taxes ou les litiges. Le déplacement de chaque enregistrement peut augmenter les coûts, la confidentialité et les tests. Une solution documentée d’accès aux archives peut convenir lorsque la propriété, l’accès, la conservation, le temps de récupération et l’élimination éventuelle sont clairs.
7. Séparer l'identité et l'accès sans créer d'angle mort
L'identité est une dépendance critique car elle contrôle les utilisateurs, les comptes de service, les accès privilégiés, les applications et les données. Le destinataire a besoin d'une autorité d'identité indépendante, d'un processus entrant-déménageur-quittant, d'une politique d'authentification, d'un contrôle d'accès privilégié et d'une procédure d'accès d'urgence avant la sortie des services dépendants.
L'architecture zéro confiance du NIST supprime la confiance implicite basée sur l'emplacement du réseau ou la propriété des actifs et nécessite une authentification et une autorisation avant l'accès aux ressources de l'entreprise. [6] En cas de séparation, cela signifie que la portée réseau héritée ou les informations d'identification des parents ne doivent pas devenir le modèle d'accès permanent. Les identités des utilisateurs, des appareils, des services et des applications nécessitent des politiques explicites.
La migration d'identité doit distinguer les utilisateurs du personnel, les clients, les fournisseurs, les robots, les interfaces, les bases de données, les certificats, les clés et les clients API. Les comptes de service sont souvent négligés car ils n'apparaissent pas dans les listes d'employés. Les certificats expirés ou les clés non pivotées peuvent provoquer un échec retardé après un basculement apparemment réussi.
Les parties devraient réduire l’accès permanent entre les entreprises à mesure que les services cessent. Les journaux d'accès doivent être surveillés pendant la transition, et l'accès résiduel du fournisseur doit avoir un objectif, une expiration et un propriétaire nommés. L’accès par bris de glace doit être testé et examiné de manière indépendante.
L'accès privilégié nécessite une gouvernance distincte, car les administrateurs peuvent modifier les configurations, extraire des données ou désactiver les contrôles. Le destinataire doit établir son propre coffre-fort à accès privilégié, son propre flux de travail d'approbation, sa journalisation des sessions et son propre processus d'urgence. Les informations d’identification d’administrateur partagées doivent être supprimées. Lorsque le personnel du fournisseur conserve l'accès, l'autorité contractuelle et les autorités techniques doivent se mettre d'accord.
8. Séquencer les applications, l'infrastructure et les interfaces
Les applications doivent être regroupées par service métier et chaîne de dépendances plutôt que migrées sous forme de liste indépendante. Le programme doit identifier les systèmes d'enregistrement, les systèmes d'engagement, d'analyse, d'intégration, d'infrastructure, de surveillance, de sauvegarde et de récupération.
Quatre grands modèles de sortie sont disponibles. Le destinataire peut cloner une instance séparée, migrer vers une plateforme existante, implémenter une nouvelle plateforme ou conserver un service tiers durable. Chaque modèle a des implications différentes en matière de données, de licences, de contrôle et de timing. Un clone peut être rapide mais préserver la dette technique. Une nouvelle plateforme peut améliorer l’état final mais augmenter le risque de mise en œuvre.
Les interfaces nécessitent une discipline particulière. Un système peut réussir des tests autonomes tout en échouant lorsque le timing en amont réel, la qualité des données ou les accusés de réception en aval sont introduits. L'inventaire de l'interface doit inclure la direction, la fréquence, le protocole, le schéma, l'authentification, la gestion des erreurs, le volume et le propriétaire de l'entreprise.
Les décisions en matière d'infrastructure doivent porter sur les réseaux, les comptes cloud, les domaines, les appareils, la surveillance, la planification par lots, le stockage, la sauvegarde et la restauration. Le destinataire doit posséder l'observabilité avant le basculement afin de pouvoir diagnostiquer l'échec sans dépendre du fournisseur.
Le déclassement devrait être planifié parallèlement à la migration. Les interfaces en double, les comptes dormants, les routes réseau temporaires et les environnements abandonnés augmentent les coûts et les risques. Chaque lot de travaux de sortie doit indiquer ce que le prestataire va retirer, ce que le destinataire conservera et comment les deux parties confirmeront qu'aucun dossier ou service requis n'est perdu.

Cadre original. La séquence de sortie doit suivre les résultats du service et les dépendances directionnelles.
9. Intégrer la cybersécurité dans le périmètre de séparation
La séparation modifie la surface d'attaque. De nouveaux domaines, réseaux, comptes cloud, connexions à distance, transferts de données et fournisseurs sont introduits alors que les équipes sont sous pression de livraison. Les exceptions temporaires peuvent devenir des vulnérabilités persistantes si elles ne sont pas enregistrées et fermées.
Le NIST CSF 2.0 organise les résultats en matière de cyber-risques autour de la gouvernance, de l'identification, de la protection, de la détection, de la réponse et du rétablissement. [7] Le cadre est utile pour évaluer à la fois l'état de transition et l'état final du bénéficiaire. L'inventaire des actifs, le contrôle d'accès, la sécurité des données, la sécurité de la plateforme, la surveillance, la réponse aux incidents et la récupération doivent être testés dans le cadre du programme de séparation.
Les objectifs de performance intersectoriels de CISA identifient une base de pratiques prioritaires pour les organisations et les infrastructures critiques, y compris la protection des identités, les sauvegardes et autres contrôles à fort impact. [8] Un programme actif devrait sélectionner des contrôles adaptés au secteur, à la menace et aux obligations réglementaires plutôt que de considérer une liste de contrôle générique comme suffisante.
Le destinataire a besoin de sa propre commande d'incident, de ses listes de contacts, de sa journalisation, de sa détection, de sa gestion des vulnérabilités, de sa sauvegarde et de sa restauration. Le fournisseur et le destinataire ont également besoin d'un protocole d'incident commun pendant que le TSA reste actif. Le protocole devrait établir les droits de décision, la préservation des preuves, les communications entre les régulateurs et les clients, les coûts et l'examen post-incident.
Les obligations des entreprises publiques peuvent raccourcir la fenêtre de décision. Les cyber-règles 2023 de la SEC exigent la divulgation d'un incident important généralement dans les quatre jours ouvrables suivant la détermination de l'importance relative, ainsi que des informations annuelles sur la gestion, la stratégie et la gouvernance des cyber-risques. [12] La gouvernance de la séparation devrait transmettre rapidement les faits aux équipes juridiques et de divulgation sans permettre aux considérations de divulgation d'interférer avec le confinement et le rétablissement.
10. Connectez la sortie à la confidentialité, aux enregistrements et à la conservation légale
Les données personnelles, les informations confidentielles, les dossiers juridiques et la propriété intellectuelle nécessitent un traitement explicite. L'accord de séparation, le TSA, les conditions de traitement des données et la législation locale doivent s'aligner sur les rôles du contrôleur et du sous-traitant, les instructions, les sous-traitants ultérieurs, les emplacements, les avis d'incident, la conservation, l'audit et la suppression.
L’équipe chargée des données ne doit pas supposer que tous les enregistrements historiques peuvent être copiés. La limitation de la finalité, la confidentialité, les restrictions contractuelles, le secret bancaire, les informations sanitaires et les contrôles à l’exportation peuvent limiter le transfert. Certains documents peuvent nécessiter une expurgation, une ségrégation, une pseudonymisation ou un accès contrôlé.
Les données de conservation légale et d’enquête nécessitent une continuité. Les parties doivent préserver la possibilité de recherche, la chaîne de traçabilité et la propriété responsable. La suppression des copies du fournisseur avant de confirmer que le destinataire est complet peut nuire à ses obligations ; la conservation indéfinie crée une exposition à la vie privée et à la confidentialité.
Les preuves de sortie doivent inclure un enregistrement de transfert de données, les exceptions non résolues, le calendrier de conservation, le certificat de suppression du fournisseur le cas échéant et l'approbation du propriétaire de l'entreprise. Ces dossiers doivent rester accessibles après la clôture du programme.
11. Reconstruire les capacités financières et de contrôle
La séparation financière affecte les fiches clients et fournisseurs, le plan comptable, les comptes bancaires, la trésorerie, la fiscalité, la paie, les immobilisations, la consolidation, la planification, le reporting et le contrôle interne. La migration technique doit être conciliée avec les soldes d’ouverture et les populations de transactions.
Le bénéficiaire a besoin d'un calendrier serré et d'une matrice de contrôle pour les premières périodes de reporting indépendantes. Les interfaces entre les systèmes opérationnels et financiers doivent être testées avec des volumes, des devises, des taxes, des événements limites, des crédits et des exceptions représentatifs. Les solutions manuelles doivent avoir des propriétaires, des limites de capacité et des contrôles de révision.
IFRS 5 impose une présentation séparée de certains actifs et passifs classés comme destinés à la vente et des résultats des activités abandonnées. [9] Le reporting applicable dépendra de la transaction et de la juridiction, mais le plan de séparation opérationnelle doit prendre en charge le périmètre comptable et la traçabilité des informations.
Les tests de contrôle doivent couvrir l'accès, la séparation des tâches, les modifications des données de base, l'approbation du journal, les rapprochements, les revenus, les achats, la paie, la trésorerie et le reporting. Un test de technologie propre sans réconciliation financière ne peut pas soutenir la sortie du secteur financier.
12. Protéger la continuité opérationnelle
La continuité opérationnelle doit s’exprimer à travers les résultats des services et les tolérances aux impacts. Un objectif de rétablissement basé sur le temps est utile, mais il peut ne pas prendre en compte les retards de transactions, les préjudices causés aux clients, la sécurité, l'intégrité du marché, les pertes financières ou les délais réglementaires.
La FCA distingue la tolérance aux impacts du temps de récupération et encourage des mesures supplémentaires telles que les catégories de clients, les valeurs des transactions, les volumes et les pertes estimées. [10] Un programme de séparation peut appliquer la même logique pour définir une panne maximale, un nombre maximal de transactions non rapprochées, une perte de données maximale, un retard client maximal et une durée maximale de traitement manuel.
Les tests de scénarios doivent être rigoureux mais plausibles. Les exemples incluent l'échec du chargement des données, la panne d'identité, l'interface corrompue, l'expert du fournisseur indisponible, le retard du fournisseur, le cyber-incident lors du basculement, l'échec de fin de mois et la restauration après un traitement partiel. Les tests doivent inclure les décideurs et les communications, et pas seulement les équipes techniques.
Les preuves de continuité doivent montrer que le destinataire peut rester dans les tolérances approuvées, récupérer le service et traiter le retard. Un système restauré après six heures peut toujours créer un préjudice inacceptable si trois jours sont nécessaires pour rapprocher les transactions manquées.
| Domaine des preuves | Preuve minimale | Mesure quantitative | Propriétaire responsable | Bloqueur de sortie |
|---|---|---|---|---|
| Processus | Scénario de bout en bout terminé | Taux de réussite et réduction du retard | Propriétaire de services aux entreprises | L’étape critique manque de capacité |
| Données | Totaux de population et de contrôle rapprochés | exhaustivité, exactitude et enregistrements rejetés | Propriétaire des données | Écart important inexpliqué |
| Technologie | Capacité, surveillance et récupération testées | Disponibilité, latence, récupération et perte de données | Propriétaire de la technologie | La récupération dépasse la tolérance |
| Contrôle | Contrôles clés opérés avec des preuves | Exceptions et clôture de mesures correctives | Propriétaire du contrôle | Le contrôle financier ou réglementaire échoue |
| Personnes | Rôles pourvus et accès approuvés | Couverture, formation et réponse en cas d'escalade | Cadre fonctionnel | Dépendance unique et totale |
| Fournisseur | Contrat, assistance et droits de résiliation actifs | Niveaux de service et obligations non résolues | Propriétaire commercial | Consentement requis ou licence absente |
Cadre original. Les preuves doivent être proportionnées au caractère critique du service et à la compétence.
13. Sécuriser les droits de fournisseur et de licence
Le destinataire peut construire une plate-forme techniquement solide mais ne pas être en mesure de l'exploiter car les contrats, licences ou consentements restent chez le fournisseur. La diligence des fournisseurs doit identifier la cessibilité, les conditions de changement de contrôle, les mesures des utilisateurs, les droits territoriaux, les engagements minimum, les droits d'audit, les conditions relatives aux données, le support et la résiliation.
Les nouveaux contrats doivent être en vigueur avant le basculement et doivent couvrir la mise en œuvre ainsi que le service en régime permanent. Un fournisseur peut accepter le support de production mais exclure les défauts de migration. Le destinataire doit comprendre si le fournisseur ou le vendeur possède des connaissances en configuration et si la documentation peut être transférée.
La concentration commerciale peut changer pendant la séparation. Un prestataire qui ne représentait auparavant qu'une petite partie des dépenses du groupe peut devenir essentiel pour le bénéficiaire. Les plans de diligence financière, de résilience, de sécurité, de sous-traitance et de résiliation doivent être recalibrés en fonction de la dépendance du bénéficiaire. La signature du contrat ne doit pas remplacer l’intégration et les tests opérationnels.
Les métriques de licence doivent être testées par rapport au modèle cible. Les utilisateurs, processeurs, transactions, revenus, appareils, environnements et affiliés nommés peuvent générer des coûts différents. Les environnements parallèles pendant la migration peuvent nécessiter des licences temporaires qui n'apparaissent pas dans le budget final.
Les risques de sortie et de concentration des fournisseurs doivent être évalués. DORA exige que les entités financières utilisant des services TIC pour des fonctions critiques ou importantes maintiennent des plans de sortie complets, documentés, testés et périodiquement révisés qui permettent une sortie sans interruption de leurs activités, sans entrave à la réglementation ou sans préjudice de la continuité et de la qualité des services. [11] Ce principe s'applique directement aux prestataires de remplacement sélectionnés lors d'une scission.
14. Transférer les connaissances et le pouvoir de décision
La prestation de services dépend de connaissances tacites, de la gestion des exceptions et de l’autorité décisionnelle. La documentation à elle seule permet rarement de comprendre pourquoi un processus s'écarte, quel client a besoin d'un traitement spécial ou comment un système vieillissant est récupéré.
Le programme doit identifier les rôles critiques, les experts nommés, les droits de décision, les cycles récurrents, les défauts connus, les contacts avec les fournisseurs et les voies d'escalade. Le transfert de connaissances doit recourir à l’observation, au fonctionnement en binôme, à l’observation inversée et à l’exécution dirigée par le destinataire. La participation à une séance de formation est une preuve faible ; un service réussi dirigé par le bénéficiaire dans des conditions réalistes est plus fort.
Des dispositions de rétention peuvent être nécessaires pour le personnel prestataire et bénéficiaire. Leur objectif, leur durée, leur étape et leur coût doivent être explicites. Le recours à une seule personne devrait déclencher un plan de succession ou de soutien externe.
Le pouvoir de décision devrait être transféré avant le départ de la personne qui l’a historiquement exercé. Le destinataire a besoin de politiques approuvées, de pouvoirs délégués, de mandats bancaires, de rôles système et de nominations réglementaires. Une équipe compétente sans autorité ne peut pas fonctionner de manière indépendante.
15. Définir les tests de sortie avant la fin de la construction
Les tests d'acceptation doivent être conçus tôt car ils façonnent l'architecture et les preuves. Le propriétaire du service doit définir ce qui doit être vrai pour la sortie, les données requises, le scénario, la tolérance et l'approbateur.
Les tests doivent progresser des composants aux interfaces, aux processus de bout en bout, aux performances, à la sécurité, à la récupération et à la répétition opérationnelle. Les données représentatives de type production doivent être utilisées légalement et en toute sécurité. Les environnements de test doivent refléter suffisamment fidèlement les volumes, la configuration et les dépendances pour étayer la conclusion.
Les défauts nécessitent une gravité, un propriétaire, une date cible et des preuves de nouveau test. Une renonciation doit indiquer le risque résiduel, la durée, le contrôle compensatoire et l'approbation. Les défauts de haute gravité ne doivent pas disparaître dans un taux de réussite moyen.
L'ensemble de preuves final doit inclure la traçabilité des exigences, les résultats, les rapprochements, les défauts, les dérogations, la capacité, la résilience, l'approbation d'accès, les procédures opérationnelles, la formation, la préparation des fournisseurs et l'acceptation du propriétaire de l'entreprise. Le pourcentage d’achèvement du projet ne constitue pas une preuve d’acceptation.
16. Basculement et restauration de l'ingénieur
Le basculement convertit les capacités testées en responsabilité réelle. Le runbook doit spécifier la séquence, les critères d'entrée, le gel des données, l'extraction, la migration, la validation, l'activation de l'interface, les contrôles commerciaux, les communications, les points de décision, la restauration et la structure de commande.
Chaque étape nécessite un opérateur nommé, une durée prévue, des preuves et la dernière heure d'achèvement en toute sécurité. Les dépendances doivent être visibles sur un seul plan intégré. Les équipes doivent répéter le runbook et mesurer la durée réelle plutôt que de se fier à des estimations.
Le retour en arrière doit être techniquement et opérationnellement possible. Si les transactions sont traitées dans le nouvel environnement, le retour au fournisseur peut nécessiter une synchronisation des données et des décisions comptables. Le point de restauration peut donc survenir avant la fin du test commercial complet. Le conseil d'administration doit comprendre quand la décision devient irréversible.
La stabilisation après le basculement devrait inclure une surveillance améliorée, un rapprochement quotidien, un triage des problèmes, la présence des fournisseurs et une couverture des décisions de haut niveau. La sortie est terminée une fois que le service fonctionne de manière fiable et que la dépendance du fournisseur est supprimée ou formellement limitée.

Scénario original. Le nombre de services et le calendrier sont totalement hypothétiques.
17. Gouverner le portefeuille de sortie
La gouvernance doit combiner les perspectives transactionnelles, commerciales, technologiques, de risque et financières. Le conseil d'administration ou le comité de transaction délégué approuve l'appétit pour le risque, le financement, les dérogations importantes, les extensions et la sortie définitive des services critiques.
Un comité directeur exécutif devrait examiner la carte intégrée des dépendances, les jalons, les coûts, les risques et les décisions. Les propriétaires de services doivent approuver les exigences et les preuves. Un bureau de gestion des séparations doit assurer le contrôle de la configuration, le calendrier, les dépendances entre les flux de travail et les rapports.
Le défi indépendant est précieux pour les services matériels. L'audit interne, les risques, la cybersécurité, la confidentialité, le contrôle financier ou des spécialistes externes peuvent vérifier si les preuves soutiennent l'état de préparation revendiqué. L’indépendance doit être proportionnée et ne doit pas supprimer la responsabilité de la direction.
Les rapports doivent montrer les résultats et non l’activité. Les mesures utiles incluent les services abandonnés, les dépendances critiques fermées, les tests réussis dans les limites de tolérance, les défauts graves non résolus, le rapprochement des données, la préparation des fournisseurs, l'exposition aux extensions, les liquidités dépensées et l'accès résiduel du fournisseur.
La gouvernance doit contrôler les changements de base. La portée, l’architecture, la date de basculement et les critères d’acceptation peuvent changer à mesure que les faits émergent. Chaque changement important doit enregistrer la raison, le coût, le risque, la dépendance et l'approbateur. Cela évite qu'une réduction tardive du périmètre soit signalée au fur et à mesure de l'avancement de la livraison et préserve une explication vérifiable du résultat final.
18. Modèle économique et incitations du TSA
La tarification TSA peut utiliser le recouvrement des coûts, le coût majoré, des frais fixes, des taux unitaires ou d'autres mécanismes négociés. Le destinataire doit comparer les frais temporaires avec le coût de remplacement et de sortie. Des frais TSA faibles peuvent réduire l’urgence même lorsque le prestataire supporte des risques et des coûts irréversibles croissants.
Les coûts supportés par le prestataire peuvent devenir bloqués à mesure que le nombre de bénéficiaires diminue. Les licences, infrastructures et équipes partagées ne peuvent pas être réduites en fonction des tarifs. Le fournisseur a donc besoin d'un plan de suppression de ressources lié aux sorties de service.
La tarification de l’extension doit tenir compte des efforts et des risques supplémentaires sans créer de structure coercitive. Les augmentations automatiques de prix peuvent motiver la sortie, mais elles peuvent également encourager un basculement prématuré si la gouvernance de la préparation est faible. L’approbation de l’extension doit rester une décision explicite en matière de risque et de valeur.
Le modèle économique devrait inclure les frais TSA, les dépenses de construction, les coûts de double exécution, les coûts de résiliation, les coûts des fournisseurs bloqués, les retards, les imprévus et les inconvénients opérationnels. La présentation du EBITDA et le financement en espèces doivent rester séparés.
19. Financer la sortie et protéger les liquidités
Les dépenses liées à la cessation de service sont souvent anticipées tandis que les prestations arrivent plus tard. Le bénéficiaire peut payer en même temps les frais TSA, les fournisseurs de mise en œuvre, les nouvelles licences, l'infrastructure dupliquée, la rétention et le fonds de roulement.
Le plan de financement doit cartographier les liquidités engagées et prévues par mois, devise et entité juridique. Il doit inclure les impôts, les dépôts, les paiements anticipés, les dépenses en capital, les dépenses de fonctionnement et les imprévus. Les engagements contractuels doivent être distingués des estimations de la direction.
Une défaillance opérationnelle peut créer une pression sur les liquidités en raison de retards de facturation, de pertes de ventes, d'indemnisation des clients, de mesures correctives, d'assistance d'urgence et de conséquences réglementaires. Le scénario grave mais plausible devrait être financé, et non simplement décrit.
Les barrières de liquidité devraient utiliser des seuils minimaux de liquidités et de marge. Si l’inconvénient dépasse le plancher approuvé, la direction doit redimensionner la portée, ajouter des financements, séquencer différemment ou négocier une extension limitée.
20. Appliquer le cadre à une séparation hypothétique
Considérons un groupe industriel et technologique hypothétique qui sépare une activité de services numériques réalisant USD 1.25 billion de chiffre d'affaires annuel. À la réalisation de l'opération, le prestataire fournit quarante-deux services TSA couvrant la technologie, la finance, les ressources humaines, les achats, les installations, le juridique, les données et les opérations. Douze services soutiennent des résultats critiques pour les clients ou les contrôles.
L'enveloppe contractuelle est de dix-huit mois. La direction vise la sortie de trente-cinq services d'ici le douzième mois, laissant sept services délimités pour la période finale. Les frais TSA annualisés d’ouverture s’élèvent à USD 74 million. Le coût final du service récurrent supposé est de USD 69 million après refonte et approvisionnement.
Le budget de séparation unique est USD 128 million : USD 52 million pour les applications et les données, USD 24 million pour l'infrastructure et la cybersécurité, USD 18 million pour le modèle opérationnel et les travaux de contrôle, USD 14 million pour le transfert de personnes et de connaissances, USD 12 million pour la double exécution et le basculement, et USD 8 million pour les imprévus.
Le programme identifie cinq chaînes de dépendance à haut risque : l'identité, la facturation client, les droits aux produits, la clôture financière et la surveillance des services. Chaque chaîne reçoit une tolérance d'impact, un test de bout en bout, une solution de repli et un propriétaire exécutif. Toutes les valeurs, timings et résultats dans ce cas sont des hypothèses créées uniquement pour démontrer la méthode.
| Article | Cas d’ouverture ou de base | Mois 12 | État final | Utilisation de la décision |
|---|---|---|---|---|
| Services TSA restants | 42 | 7 | 0 | Burndown des dépendances |
| Services critiques restants | 12 | 3 | 0 | Attention du conseil d'administration |
| Frais TSA annualisés | 74 | 16 | 0 | Gains temporaires et liquidités |
| Coût de remplacement annualisé | 0 | 58 | 69 | Base de coûts durable |
| Indemnité de séparation cumulée | 0 | 111 | 128 | Exigence de financement |
| Coût échoué annualisé du fournisseur | 39 | 17 | 6 | Programme de suppression de ressources |
| Défauts graves non résolus | 19 | 3 | 0 | Porte de préparation |
Scénario original. Tous les montants sont supposés en USD millions et ne constituent ni une prévision ni une référence de marché.
21. Testez l’inconvénient hypothétique
Le scénario de base suppose un basculement contrôlé le week-end pour la facturation et l'identité des clients au dixième mois. Le service reste dans une tolérance d'accès client de quatre heures et une tolérance de recouvrement de facturation de douze heures. Les rapprochements sont complétés avant le prochain dossier de collecte.
Le cas grave mais plausible suppose une erreur de configuration d’identité, une restauration retardée et une interface de facturation sortante corrompue. L'accès des clients est bloqué pendant dix-huit heures, la facturation est retardée de cinq jours et des mesures correctives d'urgence sont nécessaires. L'effet de trésorerie supposé est de USD 31 million avant recouvrement : USD 17 million de recouvrements retardés, USD 6 million de revenus perdus ou crédités, USD 5 million de correction et USD 3 million d'autres coûts de fonds de roulement et de communication.
Le scénario n'attribue pas de probabilité. Il teste si les contrôles, le repli, les communications et la liquidité peuvent absorber un événement défini. La direction peut choisir une séquence à moindre risque, une répétition supplémentaire ou une prolongation limitée si les preuves ne soutiennent pas le basculement initial.
La décision doit comparer le coût du retard avec l’exposition à l’échec. Une prolongation de trois mois estimée à USD 6 million de frais TSA supplémentaires et à USD 4 million de coût de double exécution peut être rationnelle si elle clôture une exposition de liquidité USD 31 million crédible et protège les clients. La comparaison reste spécifique à l'entreprise.

Scénario original. Toutes les valeurs sont supposées être des millions de USD et excluent la pondération de probabilité.
22. Utilisez une carte thermique des risques et des portes de décision
Le risque doit combiner les conséquences et la faiblesse des preuves. Un service à conséquences élevées dont la récupération n’a pas été prouvée nécessite des travaux supplémentaires même si la date de mise en œuvre est dans les délais. La taille des bulles peut représenter l’exposition aux liquidités, la population de clients ou une autre mesure importante.
Le conseil d’administration ne devrait approuver l’entrée dans le basculement final que lorsque les dépendances critiques sont connues, que les défauts graves sont résolus ou explicitement acceptés, que les tolérances d’impact sont respectées, que la liquidité reste supérieure au seuil et que le retour en arrière est viable. Un service rouge ne doit pas être compensé par de nombreux services verts.
Les violations de portes doivent conduire à des réponses définies : remédier, réordonner, réduire la portée, ajouter du financement, étendre un service ou modifier le modèle opérationnel. La réponse doit être choisie avant les pics de pression commerciale.
Après la sortie, le programme doit vérifier la suppression de l'accès du fournisseur, la disposition des données, la libération des ressources, le coût d'exécution réel et les performances stables du service. Cette porte de fermeture empêche les résidus opérationnels et financiers de survivre au programme formel.

Cadre original. La position et la taille de la bulle sont hypothétiques et doivent être remplacées par des preuves de transaction.
| Grille | Preuve requise | Décision principale | Signal de panne | Réponse de la direction |
|---|---|---|---|---|
| Gel de l'architecture | Carte des services et des dépendances, modèle cible et contrats | Approuver l’itinéraire et la séquence de sortie | La dépendance critique reste inconnue | Étendre la découverte et la reséquence |
| Construire la préparation | Capacité configurée, droits des fournisseurs, propriété du personnel | Autoriser les tests intégrés | Licence, rôle ou contrôle requis absent | Corriger avant de tester |
| Préparation au basculement | Tests de bout en bout, rapprochement, recouvrement et liquidité | Autoriser le basculement en direct | Tolérance violée ou restauration non prouvée | Retarder, réduire la portée ou prolonger le TSA |
| Stabilisation | Performance du service, clôture des problèmes et opération de contrôle | Mettre fin au soutien accru | Incident grave persistant ou retard | Conserver la structure de commandement et le financement |
| Résiliation du TSA | Indépendance du bénéficiaire et preuve de libération du prestataire | Mettre fin au service et à l'accès | Dépendance opérationnelle résiduelle | Approuver le support limité avec la date de sortie |
| Clôture du programme | Disposition des données, taux d'exécution des coûts et preuves des coûts échoués | Responsabilité étroite du programme | Les économies ou l'accès n'existent que sur papier | Maintenir la propriété et le reporting |
Cadre original. Les seuils doivent refléter l’entreprise, le secteur, les juridictions et l’appétit pour le risque approuvé.
23. Exécuter une feuille de route par étapes
La première phase établit la gouvernance, l'inventaire des services, les tolérances d'impact, les délais contractuels et la découverte. Le programme rapproche les plannings signés avec le support réel et identifie les chaînes de dépendance critiques.
La deuxième phase définit le modèle opérationnel cible, l'architecture, le périmètre des données, la stratégie des fournisseurs, l'organisation et l'environnement de contrôle. Il convertit chaque service en un lot de travaux financé avec preuve d'acceptation.
La troisième phase crée et configure la fonctionnalité. Les données sont nettoyées et répétées, les interfaces sont établies, les identités sont préparées, les contrats entrent en vigueur et les procédures opérationnelles sont rédigées. Les tests des composants commencent tôt.
La phase quatre effectue des tests intégrés, de performances, de sécurité, de récupération et de fonctionnement. Les équipes destinataires dirigent le service, les défauts sont résolus et le runbook de basculement est répété. Le conseil reçoit un dossier de préparation spécifique au service.
La phase cinq démarre par vagues contrôlées, stabilise le service, rapproche les données et ferme les accès résiduels. Le fournisseur libère des ressources lorsque les preuves le permettent. Le coût réel, les performances et les incidents sont comparés au cas approuvé.
La feuille de route doit rester dynamique. Une dépendance nouvellement découverte peut changer de séquence sans changer l'objectif final. La qualité de la gouvernance est démontrée par des changements opportuns fondés sur des données probantes plutôt que par le respect d’une date obsolète.
24. Conclusion
La sortie du TSA est un transfert d'exploitation soutenu par un contrat. Le bénéficiaire doit contrôler les personnes, les processus, la technologie, les informations, les fournisseurs, les contrôles et le financement requis pour fournir chaque service. Le fournisseur doit être en mesure de supprimer l'accès, l'infrastructure et les ressources sans nuire à son activité conservée.
Les programmes les plus solides sont conçus à partir du résultat final du service. Ils cartographient les dépendances, définissent les tolérances d'impact, construisent des preuves d'acceptation mesurables, répètent des scénarios sévères et préservent une solution de repli viable. Ils traitent les données, l’identité, les finances, la cybersécurité et les droits des fournisseurs comme des exigences opérationnelles plutôt que comme des annexes techniques.
Ils maintiennent également une discipline commerciale tout au long de la livraison. Chaque extension, renonciation et changement de périmètre est évalué par rapport à la continuité du client, aux obligations légales, au financement et au dossier de transaction. Les performances réelles après le basculement sont mesurées par rapport à la conception approuvée, ce qui permet à la direction de corriger les lacunes en matière de coûts, de capacité ou de contrôle avant qu'elles ne soient intégrées dans la nouvelle organisation.
Le cas hypothétique montre comment une enveloppe contractuelle de dix-huit mois peut soutenir un objectif de gestion de douze mois tout en préservant une période finale maîtrisée. Cela montre également qu’un problème de basculement peut consommer des liquidités importantes même lorsque le service sous-jacent est finalement rétabli. Ces valeurs sont des hypothèses et non des prévisions.
La confiance du conseil d’administration dépend des preuves au niveau du service. Un programme peut signaler un taux d'achèvement élevé alors qu'une dépendance critique reste dangereuse. La sortie devrait avoir lieu lorsque le destinataire peut opérer dans les limites des tolérances approuvées, que le fournisseur peut mettre fin à ses obligations proprement et que les deux parties comprennent le risque financier et opérationnel résiduel.
Sources
- Financial Conduct Authority, Operational résilience: insights and observations one year on, publié le 27 mars 2026, consulté le 16 septembre 2026. Lire la source principale
- Securities and Exchange Commission des États-Unis, Johnson & Johnson and Kenvue Form of Transition Services Agreement, pièce 10.10, déposée en 2024, consultée le 16 septembre 2026. Lire la source principale
- Securities and Exchange Commission des États-Unis, Jacobs Solutions and Amentum Transition Services Agreement, pièce 10.2, datée du 27 septembre 2024, consulté le 16 septembre 2026. Lire la source principale
- Securities and Exchange Commission des États-Unis, Western Digital Form 8-K concernant l'accord de séparation et de transition de Sandisk, déposé le 21 février 2025, consulté le 16 septembre 2026. Lire la source principale
- Bureau du commissaire à l'information, Due diligence lors du partage de données suite à des fusions et acquisitions, consulté le 16 septembre 2026. Lire la source principale
- National Institute of Standards and Technology, Special Publication 800-207 Zero Trust Architecture, publiée en août 2020, consultée le 16 septembre 2026. Lire la source principale
- National Institute of Standards and Technology, Cybersecurity Framework 2.0, publié en février 2024, consulté le 16 septembre 2026. Lire la source principale
- Agence de cybersécurité et de sécurité des infrastructures, Objectifs de performance intersectoriels en matière de cybersécurité, consulté le 16 septembre 2026. Lire la source principale
- IFRS Foundation, IFRS 5 Actifs non courants détenus en vue de la vente et activités abandonnées, consulté le 16 septembre 2026. Lire la source principale
- Financial Conduct Authority, Résilience opérationnelle : informations et observations pour les entreprises, publié le 28 mai 2024, consulté le 16 septembre 2026. Lire la source principale
- Union européenne, Règlement UE 2022/2554 sur la résilience opérationnelle numérique pour le secteur financier, article 28, Journal officiel du 27 décembre 2022, consulté le 16 septembre 2026. Lire la source principale
- Securities and Exchange Commission des États-Unis, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, version 33-11216, en vigueur le 5 septembre 2023, consulté le 16 septembre 2026. Lire la source principale

