Dossier · Audit de réversibilité

Construire un registre des dépendances exploitable

Partir du service à maintenir, identifier les actifs nécessaires à sa reprise et rendre visibles les dépendances de second ordre avant tout test de sortie.

Dans cette page
Point de départ

Inventorier une capacité de service, pas un catalogue fournisseur

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.

Unité du registre

Donner à chaque dépendance une identité vérifiable

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é
Domaines

Séparer sept natures de dépendance

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
Chaîne réelle

Tracer ce qui dépend de la dépendance

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.

Substituabilité

Remplacer une promesse par quatre observations

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

Observations de substituabilité
ObservationQuestion testablePreuve attendue
DisponibilitéUne cible compatible est-elle identifiée ?Cible, version et responsable
PortabilitéLes actifs nécessaires peuvent-ils être transférés ?Export, droits et contrôle d’intégrité
ReconstructionL’environnement peut-il être recréé ?Déploiement rejoué et journaux
AutonomieL’équipe cible sait-elle reprendre ?Exécution observée sans aide imprévue
Version et provenance

Conserver l’état exact auquel chaque affirmation se rapporte

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.

Point de sortie

Préparer un périmètre que le test peut réellement éprouver

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.

Dans ce dossier

Sources primaires

Sources sur lesquelles cette page s’appuie

Dernière revue documentaire : 6 septembre 2026.

Avant de nous écrire

Questions fréquentes

Quelle différence entre inventaire d’actifs et registre des dépendances ?

L’inventaire nomme ce qui existe. Le registre relie chaque actif à une fonction critique, une version, un responsable, une preuve et aux autres éléments dont sa reprise dépend.

Faut-il enregistrer toutes les dépendances du système ?

Le mandat borne le registre aux fonctions et environnements examinés. Les exclusions sont conservées avec leur justification ; elles ne sont pas assimilées à une absence de dépendance.

Comment traiter une API propriétaire non exportable ?

Le registre décrit la fonction fournie, les données échangées, les droits, les alternatives identifiées et l’effet d’une indisponibilité. Le test vérifie ensuite une substitution ou conserve l’impossibilité comme dépendance résiduelle.

Dossier réversibilité

Quelle fonction critique dépend encore d’un actif non identifié ?

Présentez le service et la cible envisagée. Nous vérifions si le périmètre peut devenir un registre testable.

Cadrer le registre