Sovereign cloud: control matters more than location

Sovereign cloud has become a label before being a reality. In public debate as in tenders, the sovereignty of an infrastructure too often comes down to one question: where are the servers? Location is a real criterion: it determines jurisdictions, latencies, jobs. But it is far from the decisive one. A data centre set up on national territory, operated by teams you do not control, on technologies you do not understand, with contracts you cannot leave, is sovereign in address only.

The useful question lies elsewhere: what does the organisation, or the state, really control of its infrastructure? Five criteria make it possible to answer, and to build a cloud pathway that deserves the word.

Architecture: understanding what you depend on

The first control is intellectual. An organisation must be able to describe its own architecture: which services, on which layers, with which technical dependencies. Architectures based on open standards and substitutable components can be understood and taken over; proprietary stacks, where each layer is known only to its supplier, create a dependency that no location makes up for. The practical criterion: can the organisation, with its own teams or a third party of its choosing, audit its infrastructure and explain each of its levels?

Contracts: knowing what you have signed

Sovereignty is often lost at signature. Three areas deserve attention. The applicable law, first: which jurisdictions can compel the supplier, and thus access the data or suspend the service: the nationality of the operator matters here as much as the location of the machines. The terms of change, next: can prices, service levels and features change unilaterally? The terms of exit, finally: notice period, migration assistance, the fate of the data and the backups. A cloud contract is negotiated with the day you will want to leave in mind.

Data: classify before migrating

Not all data calls for the same regime. Sorting is the first act of sovereignty: which data is critical to the institution's continuity, which is sensitive by nature, which is ordinary? From this classification follows the map of acceptable hosting: what can go to a hyperscaler under encryption, what requires a qualified environment, what will not leave the organisation's own infrastructure. One technical principle protects more than many clauses: encryption whose keys stay with the client. Whoever holds the keys holds the data; everything else is declarative.

Access: knowing who administers

An infrastructure is governed by those who hold its administration access. Who can create, modify, delete, copy? Privileged accounts held by the supplier or the integrator, without client supervision, transfer real control, whatever the official ownership. The rule: critical access belongs to the organisation, is logged, is reviewed periodically; and the organisation knows, at any moment, who can do what on what.

Reversibility: prove it, do not stipulate it

Everything above is verified in a single test: can you leave? Reversibility stipulated in the contract is worth something only if it is technically practicable: data exportable in real volumes and open formats, an architecture redeployable elsewhere, a migration cost and duration estimated and bearable. Serious organisations test their reversibility as one tests a contingency plan: periodically, in realistic conditions, before needing it. An exit that has never been rehearsed does not exist.

A pathway, not a dogma

These five criteria condemn no choice a priori: neither the hyperscalers, whose services are sometimes without equivalent, nor the regional operators, nor infrastructure owned outright, which has its own illusions of control when operating skills are lacking. They make it possible to compose: to each workload its environment, according to the criticality of the data and the availability of skills, for an infrastructure the teams cannot operate is never sovereign, wherever it is placed.

This is the final shift this article proposes: to stop asking “where are the servers?”, and to ask instead: “what do we understand, what do we control, and can we leave?”. The day these three answers are solid, location becomes what it should always have been: one parameter among others of a controlled infrastructure, and not the alibi of a dependency repainted in national colours.