‘Sovereign cloud’. Two words spoken with gravitas in committee meetings, yet which mean nothing until they are unpacked. Most executives who use them believe they are buying a flag colour. They are buying a contract, subject to a legal framework, operated by someone. The rest is just window dressing.
Let’s break down the terms. Without pointing fingers, and without the drama.
What the word refers to, first and foremost
The word ‘cloud’ does not come from a poetic metaphor. It comes from a drawing. Since the 1970s and 1980s, network engineers have used a small cloud to represent the part of the infrastructure they do not control: first the telecoms operator’s wide area network (WAN), then the entire Internet. It’s simply a graphical convention, nothing more. What you control, you draw as boxes and cables. What you don’t control, you draw as a cloud. The term has moved from the diagram onto the market, but the original idea remains accurate: the cloud is the part of IT that is beyond your direct control.
Hence a series of preconceptions to dispel. iCloud is not cloud computing: it’s a service for synchronising files between Apple devices. Neither is Google Drive: it’s online storage. ‘Anything that isn’t in our data centres’ isn’t a definition. Nor is ‘hosted in France’. These oversimplifications confuse consumer usage or location with a specific delivery model.
This model was established by NIST in 2011, in publication SP 800-145, and has served as a global benchmark ever since. Five cumulative criteria define cloud computing: on-demand self-service (the customer provisions their own resources without human intervention from the provider), broadband network access (resources are available over the network via standard mechanisms), resource sharing (a single physical infrastructure serves multiple customers, who are unaware of the exact location of their data), rapid elasticity (capacity scales up and down in near real time), and metered service (usage is measured and billed on a pay-as-you-go basis). A service that does not tick all five of these boxes is not ‘the cloud’ in the strict sense: it is dedicated hosting or managed services.
Deloitte sums up the shift with a simple formula: the cloud is the transformation of IT into a public service, modelled on the electricity supply. You don’t generate your own electricity; you draw it from the grid and pay for what your meter records. The cloud applies this logic to computing and storage. It’s worth bearing this perspective in mind: what you’re buying isn’t a machine, it’s a connection.
A cloud isn’t a place; it’s a contract
We tend to imagine the cloud as a place, a cloud, somewhere up above. It’s the opposite of a place. Computing capacity rented on demand, billed on a pay-as-you-go basis, managed by a third party. Three tiers, from the most basic to the most comprehensive. Infrastructure (IaaS): you rent servers and storage. Platform (PaaS): you rent the resources to run your applications without managing the servers. Software (SaaS): you rent the finished application, your email service, your CRM.
At each tier, you delegate more. At each tier, someone else holds the keys to your data. The relevant question isn’t ‘where is my data?’. It’s ‘who can access it, and under what authority?’.
What ‘the cloud’ actually means when we talk about OVH and AWS
The Deloitte chart provides a simple guide. Buying cloud services isn’t about buying a machine; it’s about buying a connection. You don’t own the power station; you plug into a socket and draw the electricity you need. The bill is based on the meter reading: you pay for what you use, no more, no less. The key question comes straight after that. Does everything the market lumps under the term ‘cloud’ really tick all five boxes of the NIST definition, or is it sometimes something else that’s been rebranded to follow the trend?
AWS answers this question most clearly. Launched in 2006, the service has built a global infrastructure that meets all five criteria point by point. Total self-service: a console, APIs, Terraform – you provision resources without speaking to anyone. Universal network access: the resource can be accessed from any connected device. Global pooling: dozens of regions, millions of customers on a shared platform. Elasticity down to the millisecond: you can scale up and down without notice. Billing by the clock tick: the meter records every second, every request and every gigabyte transferred. Built on top of this foundation, hundreds of managed services—all interoperable—transform IT into a utility as transparent as mains electricity. This is the industrialisation of the Deloitte model at scale.
OVH, which became OVHcloud in 2021, tells a different story. The company was founded in 1999 as a dedicated server hosting provider and grew by selling raw computing power at the best price on the market. The model operates across dedicated servers, shared hosting and VPS: you rent a machine or a portion of a machine, you keep it, and you pay a monthly fee. When the market shifted towards the elastic connectivity model, the company simply slapped the word ‘cloud’ onto its existing catalogue.
However, part of this catalogue does not meet all five criteria. A dedicated server lacks elasticity: it is a fixed machine rented on a monthly basis, not a resource that expands and contracts on demand. Some VPS services are not billed on a real-time, pay-as-you-go basis but at a flat rate. Some services do not offer the full self-service capability that defines the model. This is not a value judgement; it is the NIST definition applied to the letter. A significant proportion of these offerings fall under web hosting, not the cloud in the strict sense.
The rebranding to OVHcloud reflects this commercial reality: the word ‘cloud’ is being tacked onto a diverse range of services simply to stay in the current conversation. OVH remains a major player in the market for large-scale, low-cost hosting, and this market has its own legitimacy. But conflating this hosting with industrialised cloud computing distorts the picture, because it places two products on the same level that do not operate according to the same logic.
This difference is by no means accidental: it reflects two industrial contexts that did not have the same resources. AWS is being built in a country with a population of three hundred and thirty million, in a homogeneous domestic market where a service deployed once immediately reaches a vast customer base. Venture capital flows freely there, ready to fund years of losses in order to build a global infrastructure. And the federal government acts as the primary benchmark client, from Pentagon contracts to those of the CIA, which guarantees a massive market and a stamp of credibility. OVH is growing in an environment where none of these three conditions exist: a market fragmented by national languages and legal systems, scarce and risk-averse venture capital, and public procurement that does not automatically favour an emerging local player. It is not a question of talent or ambition; it is a question of structural resources. You cannot build the same thing with the same hands when the ground beneath your feet is not the same.
This initial inequality is itself a dimension of digital sovereignty – and the one most often overlooked. When we talk about a sovereign cloud in France or Europe, the available options are limited by what this industrial context has allowed to be built. A country that does not have its own hyperscaler cannot have the same conversation about sovereignty as a country that does: it lacks the building block. This is why pitting OVH against AWS to draw conclusions about sovereignty leads to flawed reasoning. The two players are not operating on the same footing. Issues of dependency, portability and applicable law do not arise in the same way depending on whether one is looking at a hosting provider born of budgetary constraints or an industrial utility born of a project aimed at power, backed by capital, a market and a state that wanted it.
The consequence becomes apparent as soon as one makes a comparison. When OVH and AWS are pitted against each other from the perspective of ‘cloud sovereignty’, we are often comparing two different things. Issues of reversibility, dependency and applicable law do not arise in the same way depending on whether you are renting a dedicated server or subscribing to an elastic connection. With a dedicated server, reversibility relates primarily to the portability of your data and configuration. With an elastic connection, it depends on the extent to which you rely on proprietary managed services, which is an entirely different issue.
You need to know what you’re talking about before you ask the question. Correctly naming the subject – whether it’s hosting or the cloud – is not merely a matter of vocabulary: it is the prerequisite for asking the right question about control, the one that corresponds to the product you actually have in your hands.
The real issue isn’t the flag, it’s the law
This is the point that marketing glosses over. A service may display a French flag, have servers in France and a team in Paris, yet still be subject to the laws of another country. The US CLOUD Act, passed in 2018, authorises US authorities to demand data held by a company falling under their jurisdiction, wherever that data is physically stored. Location offers no protection. The operator’s legal affiliation does.
A ‘sovereign cloud’ in the strictest sense is a service that no foreign law can reach. It is not just a logo. It is a verifiable characteristic: which jurisdiction the operator falls under, who can compel them to comply, and what happens the day their access is cut off.
The only reliable indicator
In France, there is only one benchmark that counts. The SecNumCloud accreditation, issued by ANSSI. The CNIL states this quite plainly: it is currently the only benchmark it recognises for classifying a cloud as sovereign, because it specifically targets immunity from extraterritorial laws. A qualification, not a certification: a security endorsement, underpinned by the ‘Cloud at the Centre’ state doctrine, and subsequently by the SREN Act, Article 31 of which requires state cloud projects to use a service immune to such laws.
Classification remains the benchmark recognised by the CNIL, but it does not in itself guarantee sovereignty: it is a necessary condition, but not a sufficient one. There are two reasons for this. Firstly, the scope of the certification may not cover all the services actually used: a service may be certified at the infrastructure layer (IaaS) but not at the platform layer (PaaS), and an organisation using both would therefore only have part of its usage covered. Secondly, the certification does not prejudge either day-to-day operational quality or effective reversibility, which can only be verified in the event of an actual exit. AWS has an infrastructure in France, but its standard offering does not currently hold SecNumCloud certification: proof that location alone is not sufficient, and that certification is precisely what a physical presence in the country can never guarantee.
The ecosystem is taking shape rapidly, and is moving in surprising directions. Bleu, led by Capgemini and Orange, is seeking accreditation by encapsulating Microsoft Azure technologies, isolated from the group’s global infrastructure. S3NS, a joint venture between Thales and Google, secured its certification in December 2025, the first to cover both infrastructure and platform in a single package. These offerings, built on the technology of the very giants we were supposedly trying to avoid, have been tailored to comply with the law. Reality is more complex than the public debate suggests. In March 2026, ANSSI and its German counterpart published common sovereignty criteria, a sign that the European level is finally seeking a common foundation, after years of deadlock over the EUCS framework.
Structurally, S3NS and Bleu follow the same model. They are joint ventures between a French player and an American hyperscaler: Capgemini and Orange partnering with Microsoft Azure for Bleu, and Thales partnering with Google Cloud for S3NS. Their role can be summed up in a single sentence: to operate an isolated, SecNumCloud-certified instance of their American partner’s stack. The framework is French, the perimeter is secure, but the code, algorithms and services remain those of Microsoft and Google.
This is the source of the central tension. Compliance with SecNumCloud resolves the legal issue: data does not leave the certified perimeter, and French law applies without interference from foreign legislation. However, technological and industrial dependence remains entirely intact. If Microsoft or Google were to discontinue the underlying technology, terminate the partnership or change its terms and conditions, legal sovereignty would not protect operational continuity. This is not a design flaw in these offerings: it is a structural tension between two interpretations of the word ‘sovereignty’ that we tend to confuse.
The question facing the executive can therefore be formulated precisely. Legal and regulatory sovereignty – SecNumCloud and immunity from extraterritorial laws – addresses a very real category of risk. Industrial sovereignty – control over the stack and the ability to switch providers without having to rewrite everything – addresses another, equally real category. The two are not interchangeable. A SecNumCloud contract reduces legal exposure: it guarantees neither reversibility nor technological independence. Knowing which of the two one is purchasing, and which still needs to be built – that is the decision.
How we’re responding today
A business leader doesn’t need to become a lawyer or an engineer. They simply need to ask four questions and demand written answers. Which jurisdiction does the contract fall under? What data is being transferred, and where? Is the service qualified, and for what exact scope? What happens if the provider goes out of business or is cut off – what is known as reversibility?
Sovereignty is not a logo colour or a shareholder’s nationality. It is a set of properties that must be verified line by line. As long as we talk about flags, we are talking about public relations. The day we talk about applicable law, certification and reversibility, we are finally addressing the issue.
Sources
- ANSSI, SecNumCloud certification and the ‘Cloud at the Centre’ doctrine, cyber.gouv.fr
- CNIL, interview on the sovereign cloud, Le Journal des Entreprises, May 2026
- SecNumCloud Observatory, CyberTaskForce, December 2025
- OVHcloud, history and results for the 2025 financial year
- CLOUD Act (United States, 2018); SREN Act, Article 31