SovereigntyGap.

Lire un Profil — angle DSI

Guide de lecture par persona
Comment un DSI exploite un Profil de souveraineté : continuité d'exploitation, plans de contournement, séquestre.

Lire un Profil — angle DSI#

Lire un Profil quand on porte la continuité d’exploitation devant un CODIR — et qu’on doit tenir cette responsabilité dans la durée.

Ton enjeu#

Un DSI ne lit pas un Profil pour s’informer ; il le lit pour répondre. Répondre à son CODIR si le fournisseur ferme, est racheté, perd ses mainteneurs principaux, change de licence ou voit son hébergeur basculer hors d’une juridiction acceptable. Le Profil est utile parce qu’il rend visible ce que l’argument commercial du fournisseur masque : la chaîne réelle, donc les points de rupture réels. Un commercial vend une fonctionnalité ; un Profil expose la dépendance qui la sous-tend, l’hébergement qui la porte, la gouvernance qui décide de sa trajectoire. C’est cette lisibilité de la chaîne qui distingue un Profil d’une plaquette. Pour un DSI, un document qui n’aide pas à anticiper la rupture est un document qu’il ne lira pas — donc lire un Profil consiste d’abord à vérifier qu’il dit assez sur la rupture pour être utile.

Lecture en 5 minutes#

Cinq champs suffisent à décider si un Profil mérite une lecture approfondie ou si l’on demande au fournisseur de le compléter.

  • Date de mise à jour. Un Profil non daté ou figé depuis plus de dix-huit mois ne décrit plus la chaîne actuelle. Un fournisseur qui ne retouche pas son Profil après une levée de fonds, un changement d’hébergeur ou un rachat de composant fait peser le travail de mise à jour sur l’acheteur.
  • Domaine 4 — hébergement effectif. Pas le siège social du fournisseur : où sont réellement stockées les données, sous quelle juridiction, et avec quelles garanties contractuelles. Un Profil ambigu sur ce point l’est généralement parce que la réponse dérange.
  • Domaine 5 — continuité. Présence ou absence de séquestre, de clause de release-on-trigger, de plan de réversibilité testé. Si le domaine décrit une intention sans dispositif, c’est un domaine vide habillé en domaine plein.
  • Domaine 1 — composants stratégiques. Repérer les briques single-vendor dont la disparition arrêterait le service. Un Profil qui mentionne ces briques sans alternative envisagée annonce sa propre fragilité.
  • Domaine 7 — limites assumées. Un fournisseur sérieux nomme ses limites. Un domaine 7 vide ou réduit à des platitudes (« nous nous engageons à la qualité ») signale un Profil qui n’a pas été écrit pour être utile à un acheteur exigeant.

Lecture approfondie#

Sept domaines, sept éclairages depuis l’angle DSI. Cette section ne réécrit pas les fiches pédagogiques des domaines — elle dit ce qu’un DSI en tire pour décider.

Domaine 1 — Composants stratégiques#

Lire le domaine 1 revient à identifier la liste des briques sur lesquelles le fournisseur lui-même repose. Pour le DSI, c’est la cartographie des ruptures upstream possibles : si l’une d’elles bascule en vendor lock-in dur ou disparaît, le service que vous consommez est touché en cascade.

Domaine 2 — Plans de contingence#

Le domaine 2 dit ce qui se passe si une brique du domaine 1 tombe. Un plan théorique sans test n’est pas un plan ; un plan testé avec un délai de bascule chiffré est une information opérationnelle utilisable dans un PCA.

Domaine 3 — Chaîne d’approvisionnement#

La distribution dit qui d’autre exploite la même brique, et donc combien d’organisations partagent les mêmes points de rupture. Un écosystème fourni est une assurance d’effort de maintenance partagé ; un écosystème mince signale qu’en cas de défaillance, vous serez seul à reconstruire.

Domaine 4 — Hébergement et données#

Le domaine 4 est le terrain où le DSI joue le plus directement. Au-delà de la juridiction effective, il faut lire la chaîne d’hébergement complète : qui héberge qui, quels sous-traitants techniques, quelles obligations extraterritoriales s’appliquent en pratique aux données traitées.

Domaine 5 — Continuité#

Le domaine 5 est le cœur de la lecture DSI. Un séquestre documenté, une clause de release-on-trigger déclenchable sur événements précis, une procédure de réversibilité qui a été exécutée au moins une fois en conditions réelles : ces trois éléments transforment une promesse en mécanisme.

Domaine 6 — Gouvernance et capital#

La gouvernance n’est pas le terrain premier du DSI, mais elle conditionne la continuité : un fournisseur dont le pacte d’actionnaires autorise une cession à toute heure, ou dont le capital est exposé au golden power d’un État tiers, peut basculer sans préavis utile pour vos calendriers de migration.

Domaine 7 — Engagements et limites assumées#

Le domaine 7 est l’épreuve de sincérité du Profil. Le DSI y cherche moins les engagements positifs que les limites nommées : un fournisseur qui écrit « nous ne portons pas le PRA, c’est à l’organisation utilisatrice de le programmer » dit quelque chose d’utilisable. Un fournisseur qui n’écrit que des intentions ne dit rien.

Signaux d’alerte#

Six signaux qui doivent déclencher une demande de complément avant signature ou renouvellement. Aucun ne suffit à disqualifier seul ; leur cumul, en revanche, indique un Profil qui ne soutient pas une décision d’achat sérieuse.

  • Aucun plan de contournement testé. Le domaine 2 est vide ou décrit en théorie, sans délai chiffré ni mention de répétition. Conséquence : votre PCA reposera sur un test que personne n’aura conduit.
  • Hébergement extra-européen non documenté. Le domaine 4 reste évasif sur la juridiction effective des données, ou mélange siège social et localisation des serveurs. Conséquence : exposition imprévisible à des obligations extraterritoriales que vous découvrirez sur incident.
  • Dépendance unique non substituable. Une brique single-vendor est mentionnée au domaine 1, mais aucune alternative n’est envisagée au domaine 2. Conséquence : la disparition du composant amont arrête votre exploitation sans préavis utilisable.
  • Absence de séquestre, de release-on-trigger ou de clause de réversibilité. Le domaine 5 décrit une intention sans dispositif. Conséquence : aucun mécanisme contractuel ne se déclenche le jour où le fournisseur ferme.
  • Domaine 7 vide ou réduit à des platitudes. Le fournisseur ne nomme aucune limite, n’assume aucun engagement précis. Conséquence : vous ne savez pas ce qu’il refuse de porter, donc ce que vous devez porter à sa place.
  • Profil non daté ou figé depuis plus de dix-huit mois. La chaîne décrite n’est plus la chaîne actuelle. Pour les contextes documentés par le dossier — voir notamment famille 1 — bascules de licence — un Profil non révisé après un événement structurant équivaut à une déclaration trompeuse.

Comment agir#

Lire un Profil ne suffit pas — il faut le rattacher à la décision. Quatre gestes propres au DSI rendent la lecture opérationnelle.

D’abord, intégrer le Profil dans la cartographie SI : chaque fournisseur stratégique est rattaché à son Profil, daté, archivé. Le Profil devient une pièce documentaire du dossier d’application, au même titre que la fiche d’architecture.

Ensuite, programmer les migrations identifiées par les contre-plans du domaine 2. Un plan de contournement non programmé est un plan qui s’évanouit ; un plan inscrit au schéma directeur SI sur un horizon nommé est un plan qui survit aux changements d’équipe.

Puis, exiger la mise à jour annuelle du Profil dans les contrats de support et joindre le document aux fiches PCA/PRA des applications critiques. La mise à jour devient une obligation contractuelle, pas une politesse.

Enfin, conditionner les renouvellements à un Profil complet. Un fournisseur qui refuse de compléter son domaine 5 ou son domaine 7 avant renouvellement vous dit quelque chose : son Profil ne tient pas la lecture qu’on en fait. Le DSI peut s’engager symétriquement côté organisation utilisatrice, par exemple via user-001-audit-dependencies, pour rendre la démarche réciproque. Le périmètre du dispositif lui-même est documenté dans les limites assumées.

Préparer votre propre déclaration#

Votre organisation est aussi, à un autre titre, un fournisseur. Vous offrez des systèmes d’information à vos métiers internes — eux dépendent de vous comme vous dépendez de vos fournisseurs externes. Le manifeste demande aux fournisseurs un domaine 7 qui nomme leurs limites ; un DSI peut publier sa propre déclaration d’engagements pour rendre lisible la chaîne qu’il pilote, et la rattacher à la philosophie complète du dispositif. Le panier ci-dessous propose les engagements et domaines pertinents pour ce persona.

Préparer votre déclaration — angle DSI

Le manifeste demande aux fournisseurs un domaine 7. Vous pouvez aussi le publier.

Engagements suggérés

  • Conduire un audit interne de notre exposition aux dépendances technologiques single-vendor

    Examiner systématiquement vos technologies pour identifier celles dont la trajectoire dépend d'un seul éditeur.

    Voir la fiche →
  • Documenter publiquement la juridiction de gouvernance des principaux composants de notre chaîne d'approvisionnement

    Publier sur votre site une documentation lisible des composants de votre chaîne d'approvisionnement avec leur juridiction.

    Voir la fiche →
  • Exiger des Profils de souveraineté de toute la chaîne dans nos appels d'offres à enjeu

    Transformer la prise en compte du Profil en exigence formelle pour les appels d'offres et processus d'achat à enjeu.

    Voir la fiche →

Domaines du Profil pertinents

  • Engagements et limites assumés

    Déclarer honnêtement ce que vous garantissez et ce que vous ne pouvez pas garantir

    Voir la fiche →
  • Hébergement et données

    Préciser où vivent réellement les données et qui peut y accéder

    Voir la fiche →
  • Composants tiers stratégiques

    Lister les briques sans lesquelles votre solution ne fonctionne pas

    Voir la fiche →

0 engagements, 0 domaines dans ma déclaration

Continuer dans le générateur →