Construire un registre des dépendances exploitable

Le registre commence par la fonction que l’organisation refuse de perdre. Chaque parcours critique est relié aux données, modèles, infrastructures, identités, interfaces, droits et compétences sans lesquels il ne peut pas être exécuté sur une autre cible.

Cette construction évite deux faux positifs : croire qu’un actif exportable suffit alors qu’il dépend d’un service non portable, ou déclarer une dépendance critique sans montrer la fonction qu’elle bloque.

Une ligne utile doit pouvoir être relue plusieurs mois plus tard et conduire au même actif.

• Identifiant — stable dans le dossier et les preuves associées
• Objet — actif, service ou savoir-faire précisément nommé
• Version — état réellement utilisé dans le service observé
• Responsable — personne capable de fournir ou faire évoluer l’objet
• Fonction — parcours critique qui dépend de cet objet
• Preuve — pièce ou test permettant de confirmer l’état déclaré

La séparation évite qu’un export de données soit présenté comme la réversibilité de l’ensemble du service.

• Données — contenu, métadonnées, schémas, référentiels et provenance
• Modèles — artefacts, API, paramètres, prompts, routage et évaluations
• Infrastructure — calcul, stockage, réseau, orchestration et sauvegardes
• Identités — comptes, rôles, secrets, certificats et fédération
• Interfaces — API, événements, formats, quotas et contrats de service
• Droits — contrats, licences, propriété intellectuelle et effacement
• Compétences — procédures et connaissances nécessaires à l’exploitation

Une interface peut être documentée tout en reposant sur une identité gérée par la source. Un modèle peut être remplaçable alors que son jeu d’évaluation ne l’est pas. Le registre conserve donc les relations amont et aval, le sens du flux et la conséquence d’une rupture.

La lecture se fait dans les deux sens : depuis le service vers les actifs pour trouver ce qui manque, puis depuis chaque actif vers les parcours pour mesurer ce qu’une indisponibilité interrompt.

La présence d’un concurrent ne démontre pas qu’un composant est substituable dans le délai requis.

Le fournisseur, le contrat, le modèle, le format d’export et l’équipe changent. Le registre porte une date d’observation, une version, une source et un statut de vérification. Une affirmation ancienne n’est pas automatiquement reconduite.

Le registre est prêt lorsqu’il permet de choisir les actifs à exporter, les parcours à rejouer, les droits à confirmer, les personnes à mobiliser et les dépendances dont la présence après bascule rendrait la sortie irrecevable.