Ce volume établit une chaîne en trois temps : d'abord ce que l'offre commerciale de « cloud souverain » modifie réellement et ce qu'elle laisse inchangé au niveau du plan de contrôle (Chapitre I) ; ensuite, le dispositif contractuel qui protège cette opacité technique et en verrouille la sortie (Chapitre II) ; enfin, une architecture d'autonomie assumée comme proposition — non comme description d'une offre existante — qui répond explicitement aux mécanismes documentés en amont (Chapitre III).

Depuis 2022, une catégorie d'offres commerciales s'est constituée sous l'appellation « cloud souverain » : Bleu (Orange, Capgemini, licence Microsoft), S3NS (Thales, licence Google Cloud), AWS European Sovereign Cloud. Ces offres répondent à un déplacement du critère de souveraineté : de la maîtrise technologique vers la conformité juridictionnelle — localisation des données, nationalité du personnel, forme sociale de droit local. Ce volume examine ce que ce déplacement laisse inchangé.

La démonstration se déploie en trois temps. Les chapitres I et II documentent une RÉALITÉ : le fonctionnement actuel et vérifiable des offres Bleu, S3NS et AWS ESC — opacité du plan de contrôle (chapitre I), verrouillage contractuel qui protège cette opacité (chapitre II). Le chapitre III formule une PROPOSITION distincte de tout constat existant : un design théorique de plan de contrôle réellement autonome, non un état des lieux d'une offre existante. Cette distinction est maintenue de façon étanche tout au long du volume.

Les trois offres examinées dans ce volume — Bleu (Orange, Capgemini, technologie sous licence Microsoft), S3NS (Thales, technologie sous licence Google), AWS European Sovereign Cloud — partagent une même architecture de principe : une entité de droit local, un personnel habilité localement, un datacenter situé sur le territoire concerné, et une couche logicielle d'orchestration — hyperviseur, plan de contrôle, API de gestion — dont l'origine technologique et la maintenance restent rattachées au fournisseur de licence d'origine. Ce chapitre documente cette seconde couche, non la première.

Cette architecture n'est pas dissimulée : elle correspond à un choix industriel assumé, documenté dans les communications commerciales elles-mêmes, qui présentent ces offres comme reposant sur une « technologie éprouvée » du fournisseur d'origine, opérée localement. Le point que ce chapitre documente n'est donc pas l'existence de cette dépendance — publique — mais sa portée exacte : quelles décisions relatives au fonctionnement de la couche d'orchestration restent, par construction contractuelle et technique, hors de portée de l'opérateur local.

La couche d'orchestration n'est pas statique : elle fait l'objet de mises à jour régulières — correctifs de sécurité, évolutions de l'API de gestion, modifications du comportement de l'hyperviseur. Le canal par lequel ces mises à jour sont décidées, testées et déployées constitue le point d'observation central de ce chapitre.

Cette asymétrie ne préjuge pas d'un usage malveillant du canal de mise à jour par le fournisseur ; elle documente une dépendance structurelle indépendante de toute intention. L'opérateur local ne peut pas, à ce stade de l'architecture, apporter la preuve positive de l'absence de capacité de contrôle à distance — il peut seulement constater l'absence d'un mécanisme contractuel ou technique qui la lui garantirait.

L'introduction de ce volume a posé l'ancrage théorique de Grossman & Hart (1986) : un droit de propriété formel sur un actif ne confère de contrôle réel que dans la mesure où son détenteur peut décider des usages non spécifiés par contrat. Les sections I.1 et I.2 permettent à présent d'identifier précisément où se situent, dans le cas du cloud souverain, les droits de contrôle résiduels sur la couche d'orchestration.

Le Chapitre I a établi que le contrôle résiduel sur la couche d'orchestration reste, structurellement, du ressort du fournisseur de licence. Ce chapitre documente le dispositif contractuel qui organise cette dissociation et la rend compatible, sur le papier, avec les exigences réglementaires de réversibilité.

Ce constat rejoint, sous un angle contractuel plutôt que technique, une observation déjà établie dans le Volume VI à propos de la parade réglementaire de l'article 28(8) de DORA : la réversibilité qu'un régulateur peut exiger et obtenir se limite, dans la pratique documentée, à la donnée — jamais à l'exécution. Le présent volume retrouve ce même écart dans un contexte différent : celui de la licence logicielle d'un cloud souverain, et non celui d'une stratégie de sortie multi-cloud.

Le second volet du dispositif contractuel porte sur le support technique. Dans un modèle de support à plusieurs niveaux, le premier niveau (constatation de l'incident) et le second (diagnostic et actions correctives standard) peuvent être assurés par l'opérateur local. Le troisième niveau — intervention sur le code source ou l'architecture profonde du produit — requiert un accès et une compétence que l'opérateur local ne détient structurellement pas, puisqu'il n'est ni l'auteur ni le mainteneur de la couche d'orchestration.

Les deux mécanismes documentés dans ce chapitre — écart de périmètre entre réversibilité des données et réversibilité de l'exécution (II.1), verrouillage du support de niveau 3 (II.2) — se combinent : le premier organise la dépendance persistante de la couche d'orchestration malgré la conformité réglementaire ; le second en renchérit le coût de sortie effectif. Le Chapitre III propose une architecture qui répond explicitement à ces deux mécanismes.

Le Chapitre I a localisé le contrôle résiduel sur la couche d'orchestration du côté du fournisseur de licence, quand bien même la propriété de l'infrastructure physique restait locale. Une architecture d'autonomie doit donc agir sur la couche d'orchestration elle-même, non sur les couches qui l'entourent.

Cette reconfiguration répond directement au mécanisme documenté en I.3 : la dissociation entre propriété de l'actif et contrôle résiduel de son fonctionnement logiciel. Si l'opérateur local compile lui-même le plan de contrôle à partir d'un code qu'il peut lire, modifier et auditer, la propriété formelle de l'infrastructure et le contrôle résiduel de son fonctionnement se retrouvent réunis dans une même main — ce qui n'était le cas dans aucune des trois offres examinées aux Chapitres I et II.

Le Chapitre I a documenté, par le mécanisme de Stiglitz, une asymétrie d'information reposant sur le canal des mises à jour : le fournisseur de licence connaît le contenu et le calendrier des évolutions de la couche d'orchestration avant l'opérateur local, et détermine seul ce calendrier. Une architecture d'autonomie doit rompre ce canal, non le négocier.

Les sections III.1 et III.2 réunifient le contrôle et rompent le canal de mise à jour privilégié. Ce gain a un coût, que ce chapitre énonce explicitement plutôt que de le passer sous silence — conformément à la Déclaration d'Asymétrie de ce volume, qui exige de distinguer une proposition d'une réalité et d'en assumer le prix.

La souveraineté ne se mesure pas à la nationalité du personnel qui exploite l'infrastructure, mais à la main qui décide, en dernier ressort, de ce que fait la machine.

Cette annexe ne reproduit pas le verbatim intégral des échanges qui ont produit ce volume. Elle en résume le déroulement, chapitre par chapitre, en retenant les moments qui ont concrètement changé le texte : le choix de l'axe de démonstration, le refus motivé du premier jet du Chapitre I, l'injection matricielle qui l'a corrigé, et l'audit global explicitement distinct des audits par chapitre qui a produit le dernier enrichissement du volume.

Trois sujets candidats ont été soumis pour le Volume VII, dont le cloud souverain marketing a été retenu pour son actualité et l'absence de chevauchement avec les six volumes déjà produits. Restait à choisir le mécanisme de démonstration central entre deux axes : l'opacité de l'hyperviseur/orchestrateur (prolongement du Volume II) et l'asymétrie contractuelle des licences logicielles.

Le premier jet du Chapitre I a été refusé pour un motif précis : l'armature théorique (Grossman & Hart, Stiglitz) était validée, mais la démonstration restait générale — un encadré signalait un doute sur la répartition des responsabilités entre les trois offres nommées sans jamais nommer techniquement le mécanisme d'aucune d'entre elles.

Le Chapitre II a été validé dès son premier jet, sans réserve ni retouche — seul chapitre du volume à ne pas avoir nécessité de second tour à ce stade. Son mécanisme central, l'écart entre la réversibilité des données exigée par le critère 19.4 de SecNumCloud et l'absence d'exigence équivalente sur la portabilité de la couche d'orchestration, a été jugé immédiatement solide, de même que l'illustration nommée du verrouillage du support de niveau 3 chez S3NS.

Le Chapitre III a exigé une bascule doctrinale explicite : aucune des trois offres nommées aux Chapitres I et II ne devait plus apparaître, le texte devant se lire entièrement comme une proposition théorique et non plus comme la description d'une réalité existante. Un contrôle automatisé a confirmé l'absence totale de ces mentions avant soumission à l'audit.

Chaque chapitre de ce volume a été validé isolément avant qu'un audit distinct, portant explicitement sur l'œuvre complète, ne soit demandé — chaîne de résolution bout en bout entre Réalité et Proposition, cohérence des ancrages théoriques cumulés, portée de la thèse générale à l'échelle du volume entier plutôt qu'à celle d'un seul chapitre.

Onze pages de corps de volume ont nécessité un cadrage initial, un refus et une injection matricielle sur le Chapitre I, une validation directe du Chapitre II, une bascule doctrinale et une reconstruction de format sur le Chapitre III et sa Clôture, puis un audit global ayant produit deux enrichissements qu'aucun des audits précédents n'avait identifiés.