Le contrat permet la sortie ; le travail ne le permet pas encore

Le scénario de ce dossier est illustratif et ne correspond pas à un résultat client de CYTIZEN. Anne dirige les achats informatiques d’un groupe qui utilise un service SaaS pour ses contrats et un assistant IA pour leur analyse. La clause de réversibilité paraît satisfaisante : le fournisseur promet de restituer les données. Lors d’un exercice, l’équipe reçoit des fichiers lisibles, mais sans les historiques d’approbation, les liens entre annexes et contrats ni certaines configurations. La restitution existe ; la continuité du travail n’est pas démontrée.

La dépendance fournisseur se mesure donc par la possibilité de poursuivre un service, pas seulement par la durée d’engagement. Un contrat résiliable peut héberger des données difficiles à reprendre. Une application standard peut être entourée d’intégrations spécifiques. Un modèle IA remplaçable peut alimenter un processus qui dépend de ses formats de sortie. La question utile est : que faut-il récupérer, reconstruire et vérifier pour fonctionner avec une autre solution ou dans un mode dégradé ?

Le Data Act est applicable depuis le 12 septembre 2025. Son chapitre VI encadre le changement de fournisseur de services de traitement de données. Le périmètre du service et les obligations applicables doivent être vérifiés ; ce cadre ne remplace pas les essais d’export et de reprise. Data Act — European Commission.

Construire une carte de dépendance utilisable

Anne établit une fiche par service métier, avec les applications, identités, données, interfaces, compétences et fournisseurs nécessaires. Elle repère les dépendances indirectes : une plateforme SaaS hébergée chez un cloud commun à plusieurs autres services, un prestataire de support qui connaît seul les scripts, un fournisseur d’identité dont l’arrêt rend plusieurs outils inaccessibles. Compter les contrats ne permet pas de voir cette concentration. La carte doit montrer les relations qui peuvent interrompre une activité.

La fiche de l’application contractuelle est remplie : finalité, retrouver une version signée et son approbation ; données critiques, documents, métadonnées, liens et historique ; systèmes voisins, CRM, signature électronique et ERP ; compétences, administration fonctionnelle et support d’intégration ; repli, accès contrôlé aux contrats exportés et procédure de validation manuelle. Chaque élément a un propriétaire et une fréquence de vérification. La fiche distingue la possibilité de consulter des documents de celle de continuer à créer et approuver de nouveaux contrats.

La criticité dépend du parcours. Une interruption de l’assistant peut ralentir l’analyse sans empêcher la validation manuelle. Une perte d’accès aux contrats signés peut bloquer le contrôle d’une obligation. Une rupture avec SAP peut empêcher l’usage des bons partenaires commerciaux. Anne hiérarchise ces effets avec les métiers, en tenant compte du temps tolérable et du volume de rattrapage. Elle ne classe pas tous les services cloud comme critiques au même degré.

Faire de l’export un test, pas une promesse

L’équipe choisit un lot représentatif de contrats autorisés : document signé, annexe, historique d’approbation, changement de version et dossier comportant des droits particuliers. Le fournisseur réalise l’export prévu au contrat. Un opérateur différent de l’administrateur habituel le charge dans un environnement de consultation ou une cible de test. Le métier vérifie que les relations et les informations nécessaires restent utilisables. Une archive qui se décompresse correctement n’est pas une preuve suffisante.

Le protocole précise les critères : nombre de dossiers attendu, documents présents, version approuvée identifiable, liens conservés, dates compréhensibles, droits restaurables et résultats de rapprochement. Les données manquantes sont listées au lieu d’être remplacées silencieusement par une extraction manuelle. Une transformation de format peut être acceptable si elle est documentée, reproductible et testée. La sortie doit aussi indiquer ce qui restera chez le fournisseur pendant la conservation imposée ou convenue.

Pour un service IA, Anne ajoute prompts ou consignes versionnés, configurations, corpus, évaluations et corrections humaines lorsque ces éléments sont détenus ou exportables. Elle distingue les actifs de l’entreprise des composants auxquels elle n’a pas de droit d’accès, comme les paramètres d’un modèle propriétaire. Le plan n’exige pas la restitution impossible de ce qui n’a jamais été acheté ; il prévoit comment remplacer le composant et retester le parcours avec les actifs que l’entreprise contrôle.

Chiffrer une sortie plausible

Le coût de sortie inclut extraction, transformation, nettoyage, cible, intégrations, tests, formation, assistance fournisseur et coexistence. Il ajoute les dépenses qui continuent pendant la transition. Le calendrier dépend notamment des fenêtres métier et de la disponibilité des experts ; réduire une durée dans un planning ne crée pas ces compétences. Anne prépare un scénario normal et un scénario d’urgence où le fournisseur coopère peu ou où une application reste indisponible.

Un exemple hypothétique de budget comporte 15 000 euros d’extraction et transformation, 25 000 euros d’intégrations, 20 000 euros de tests et formation, et 10 000 euros de double exploitation. Le total de 70 000 euros n’est ni un prix de marché ni un devis. Il sert à rendre les postes visibles. Si les historiques ne sont pas exportables, leur reconstruction peut modifier fortement le coût et le délai ; ce risque doit apparaître dans la décision contractuelle avant que la migration soit engagée.

La réversibilité se compare au risque, pas à une exigence abstraite d’indépendance totale. Un service peu critique peut justifier une sortie manuelle et un export périodique. Un service indispensable exige une preuve plus robuste et une capacité de repli. Le comité peut accepter une dépendance lorsqu’il en connaît les effets et finance une protection proportionnée. Il ne doit pas appeler « maîtrisée » une dépendance dont il n’a ni testé ni chiffré le remplacement.

Négocier les éléments qui manquent au parcours

Anne vérifie les formats, volumes, délais, conditions d’assistance, prix et responsabilités de l’export. Une clause prévoyant une assistance « selon disponibilité » ne garantit pas les ressources pendant une urgence. Le contrat décrit les éléments restitués et le traitement des erreurs de restitution. Il précise aussi les droits sur les configurations, scripts et documentations spécifiques. Les décisions juridiques, de sécurité et de protection des données sont prises avec les fonctions compétentes.

Les changements d’offre sont surveillés : suppression d’une API, nouvelle tarification, changement de sous-traitant, modification de format ou fin de support. Une notification reçoit un propriétaire et une analyse d’impact. Pour l’IA, un changement de modèle peut modifier le comportement sans changer l’interface ; l’équipe conserve un lot d’évaluation pour comparer les versions. Le responsable métier décide si la différence reste acceptable, et l’exploitant vérifie la compatibilité des interfaces et la charge de support.

Dans le secteur financier, DORA fournit un cadre spécifique de gestion du risque lié aux tiers selon son périmètre. Il ne transforme pas automatiquement toute entreprise cliente d’un SaaS en entité soumise au règlement. Les obligations directes, les engagements contractuels et les bonnes pratiques de continuité doivent être distingués. Le programme organise la preuve et la coordination ; il ne déduit pas une conformité générale d’un export réussi.

Dans la vraie vie : préserver le résultat avant de changer l’outil

Dans l’exercice, Anne découvre qu’une équipe connaît seule la logique d’un connecteur CRM. Le fournisseur pourrait restituer tous les fichiers sans rendre ce savoir disponible. Le comité finance la documentation du flux et un test de reconstruction avant de négocier une nouvelle application. Ce choix paraît moins visible qu’un remplacement, mais il retire une dépendance concrète. Le plan identifie la dernière date à laquelle une sortie peut être engagée sans manquer une fenêtre de renouvellement.

Le métier accepte un mode dégradé : consulter les contrats signés, préparer une validation manuelle et différer certaines analyses automatiques. Il refuse une solution qui conserverait l’IA tout en perdant la preuve d’approbation. Cette hiérarchie guide l’ordre de migration et les tests. Une sortie réussie n’est pas celle qui remplace d’abord le composant le plus moderne ; c’est celle qui maintient les capacités dont l’activité dépend réellement.

Adapter le test à la dépendance dominante

Pour un ERP, vérifier données maîtres, écritures, interfaces et rapprochements avant de parler d’export complet. Pour un QMS, conserver le lien entre enregistrements, versions, signatures ou approbations et preuves nécessaires au processus. Pour un service d’identité, tester les comptes, droits et mécanismes de secours qui conditionnent les autres applications. Pour un assistant documentaire, distinguer le retrait de l’assistant de la perte du référentiel source. Chaque dépendance exige un test spécifique ; un modèle de clause unique ne suffit pas.

La revue périodique porte sur les changements depuis le dernier test. Elle peut rester légère lorsque le service n’a pas évolué, et devenir plus exigeante après une nouvelle intégration, une acquisition ou une extension internationale. Une réversibilité documentée plusieurs années auparavant n’est pas réputée actuelle par défaut.

Sources, méthode et limites

Sources primaires consultées le 4 octobre 2026. Les chiffres et le scénario sont pédagogiques. Les recommandations de sortie doivent être adaptées aux contrats, au contexte métier et aux obligations applicables ; elles ne constituent pas une analyse juridique d’une offre particulière.