This volume builds a chain in three stages: first, what the commercial offer of "sovereign cloud" actually changes and what it leaves untouched at the level of the control plane (Chapter I); then, the contractual device that protects this technical opacity and locks in the exit (Chapter II); finally, an architecture of assumed autonomy — presented as a proposal, not as a description of an existing offering — that answers explicitly the mechanisms documented upstream (Chapter III).

Since 2022, a category of commercial offerings has emerged under the label "sovereign cloud": Bleu (Orange, Capgemini, Microsoft license), S3NS (Thales, Google Cloud license), AWS European Sovereign Cloud. These offerings reflect a shift in the criterion of sovereignty: from technological control to jurisdictional compliance — data location, nationality of staff, local legal form. This volume examines what this shift leaves unchanged.

The demonstration unfolds in three stages. Chapters I and II document a REALITY: the current, verifiable operation of the Bleu, S3NS and AWS ESC offerings — opacity of the control plane (Chapter I), contractual lock-in that protects this opacity (Chapter II). Chapter III formulates a PROPOSAL distinct from any existing observation: a theoretical design of a genuinely autonomous control plane, not a survey of an existing offering. This distinction is maintained watertight throughout the volume.

The three offerings examined in this volume — Bleu (Orange, Capgemini, technology under Microsoft license), S3NS (Thales, technology under Google license), AWS European Sovereign Cloud — share the same architectural principle: a local legal entity, locally cleared staff, a datacenter located in the relevant territory, and a software orchestration layer — hypervisor, control plane, management API — whose technological origin and maintenance remain tied to the original license provider. This chapter documents this second layer, not the first.

This architecture is not concealed: it corresponds to an assumed industrial choice, documented in the commercial communications themselves, which present these offerings as resting on "proven technology" from the original provider, operated locally. What this chapter documents is therefore not the existence of this dependency — public — but its exact scope: which decisions about the operation of the orchestration layer remain, by contractual and technical construction, out of reach of the local operator.

The orchestration layer is not static: it is subject to regular updates — security patches, evolutions of the management API, changes to hypervisor behavior. The channel through which these updates are decided, tested and deployed is the central observation point of this chapter.

The introduction to this volume set out the theoretical anchor of Grossman & Hart (1986): formal ownership of an asset confers real control only to the extent that its holder can decide on uses not specified by contract. Sections I.1 and I.2 now allow us to identify precisely where, in the case of sovereign cloud, the residual control rights over the orchestration layer actually sit.

Chapter I established that residual control over the orchestration layer remains, structurally, in the hands of the license provider. This chapter documents the contractual device that organizes this dissociation and makes it compatible, on paper, with regulatory reversibility requirements.

This observation echoes, from a contractual rather than a technical angle, an observation already established in Volume VI regarding the regulatory workaround of DORA Article 28(8): the reversibility a regulator can require and obtain, in documented practice, is limited to the data — never to execution. This volume finds the same gap in a different context: that of a sovereign cloud's software license, not that of a multi-cloud exit strategy.

The second part of the contractual device concerns technical support. In a multi-tier support model, the first tier (incident detection) and the second (standard diagnosis and corrective action) can be handled by the local operator. The third tier — intervention on the product's source code or deep architecture — requires access and expertise the local operator structurally does not hold, since it is neither the author nor the maintainer of the orchestration layer.

The two mechanisms documented in this chapter — the gap between data reversibility and execution reversibility (II.1), locking down tier-3 support (II.2) — combine: the first organizes the persistent dependency of the orchestration layer despite regulatory compliance; the second raises the effective cost of exiting it. Chapter III proposes an architecture that explicitly answers both mechanisms.

Chapter I located residual control over the orchestration layer on the side of the license provider, even where ownership of the physical infrastructure remained local. An architecture of autonomy must therefore act on the orchestration layer itself, not on the layers surrounding it.

This reconfiguration answers directly the mechanism documented in I.3: the dissociation between asset ownership and residual control of its software operation. If the local operator compiles its own control plane from code it can read, modify and audit, formal ownership of the infrastructure and residual control of its operation are reunited in the same hands — which was not the case in any of the three offerings examined in Chapters I and II.

Chapter I documented, through Stiglitz's mechanism, an information asymmetry resting on the update channel: the license provider knows the content and schedule of orchestration-layer changes before the local operator, and determines that schedule alone. An architecture of autonomy must break this channel, not negotiate it.

Sections III.1 and III.2 reunify control and break the privileged update channel. This gain has a cost, which this chapter states explicitly rather than passing over in silence — in keeping with this volume's Declaration of Asymmetry, which requires distinguishing a proposal from a reality and owning its price.

Sovereignty is not measured by the nationality of the staff operating the infrastructure, but by the hand that decides, in the last resort, what the machine does.

This appendix does not reproduce the full verbatim of the exchanges that produced this volume. It summarizes the process, chapter by chapter, keeping the moments that concretely changed the text: the choice of demonstration axis, the reasoned refusal of the first draft of Chapter I, the corrective injection that fixed it, and the global audit — explicitly distinct from the per-chapter audits — that produced the volume's last enrichment.

Three candidate topics were submitted for Volume VII, of which sovereign cloud marketing was selected for its topicality and lack of overlap with the six volumes already produced. What remained was choosing the central demonstration mechanism between two axes: hypervisor/orchestrator opacity (an extension of Volume II) and the contractual asymmetry of software licenses.

The first draft of Chapter I was refused for a precise reason: the theoretical armature (Grossman & Hart, Stiglitz) was validated, but the demonstration remained general — a callout flagged a doubt about the distribution of responsibilities across the three named offerings without ever technically naming the mechanism of any of them.

Chapter II was validated on its very first draft, without reservation or revision — the only chapter in this volume not to require a second round at this stage. Its central mechanism, the gap between the data reversibility required by SecNumCloud criterion 19.4 and the absence of an equivalent requirement on orchestration-layer portability, was judged immediately solid, as was the named illustration of tier-3 support lock-in at S3NS.

Chapter III required an explicit doctrinal shift: none of the three named offerings from Chapters I and II were to appear again, the text having to read entirely as a theoretical proposal rather than a description of an existing reality. An automated check confirmed the total absence of these mentions before submission to audit.

Each chapter of this volume was validated in isolation before a distinct audit, explicitly covering the complete work, was requested — an end-to-end chain of resolution between Reality and Proposal, coherence of the cumulative theoretical anchors, the scope of the general thesis at the scale of the whole volume rather than a single chapter.

Eleven pages of volume body required an initial framing, a refusal and a corrective injection on Chapter I, a direct validation of Chapter II, a doctrinal shift and a format rebuild on Chapter III and its Closing, then a global audit that produced two enrichments no prior audit had identified.