The idea arrived quickly once the jurisdictional problem became undeniable. If the difficulty with American cloud providers was that their home government could compel them, the answer was a European provider under European control, running European infrastructure, beyond the reach of foreign legal process. France went furthest. The Andromède project, conceived in 2009 and pushed forward under the Sarkozy government with a stated ambition around €285 million, was intended to create a national cloud champion. When the founding partners could not agree, the state split the project in two: Cloudwatt, formed with Orange and Thales and established in September 2012 under chief executive Patrick Starck, and Numergy, formed with SFR and Bull, with public money divided between them.[1][2] Both failed commercially. Numergy went into safeguard proceedings in 2015, was bought back by SFR, and had disappeared by 2017. Cloudwatt was absorbed into Orange Business Services. Neither ever achieved the scale that would have made it a genuine alternative.[2] The demand behind them was entirely real and it has never gone away. Understanding why the first generation failed is the most useful thing a buyer evaluating sovereign cloud today can do.
Each date links to a French government or Orange announcement. This is a selective chronology, not a claim about market performance.
Why the National Champions Lost
The reasons were structural rather than incidental, and every one of them still applies. Cloud economics reward scale brutally. Hyperscale platforms amortise data centre construction, hardware procurement, networking and engineering over enormous volume. A national provider serving one country's market starts at a permanent cost disadvantage that no amount of public subsidy changes, because subsidy funds construction rather than unit economics. The gap was capability, not just price. By the time the sovereign projects launched, the global platforms were shipping managed databases, queuing, analytics, identity and dozens of other services, at a pace a national provider could not match. Buyers were not comparing storage prices; they were comparing what they could build. Nobody wanted an inferior product for a reason they could not price. A CIO choosing infrastructure weighs cost, capability, reliability and roadmap against a sovereignty benefit that is contingent, hard to quantify and may never materialise. Absent a regulatory requirement, the commercial case loses. Being built by committee is not a market position. Both French ventures were joint undertakings between telecoms operators, a defence group, a hardware manufacturer and the state. Governance of that kind is not conducive to rapid product iteration against the fastest-moving companies in the industry. Sovereignty was asserted rather than architected. A locally owned provider using foreign-manufactured hardware, foreign hypervisors and foreign software has reduced one category of exposure and left several others in place. The claim rested on corporate nationality alone, which turned out to be a thinner guarantee than it sounded.
The Legitimate Case, Which Also Existed
It would be wrong to dismiss the whole idea because the first attempts failed as businesses. Some data genuinely should not sit with a provider subject to foreign compulsion. Classified government information. National critical infrastructure. Certain categories of health and biometric data. Defence-related industrial information. For these, the marginal cost of a domestic provider is not the relevant consideration — the requirement is categorical. The error was scope. Sovereign cloud was marketed as a general-purpose alternative when its honest addressable market was a narrow set of workloads where the requirement is legal or political rather than commercial. Positioned as a niche with guaranteed demand, some of these ventures might have survived. Positioned as a national champion competing with hyperscalers, none could. That lesson has been learned. The successful current model is not a standalone national provider but a sovereign operating arrangement layered onto a global platform: a locally incorporated operator controlling access, local personnel with exclusive administrative rights, customer-held encryption keys, and contractual and technical structures designed so the foreign parent cannot obtain plaintext. The capability comes from the hyperscaler; the control comes from the operating model.
Practical Guidance for Evaluating Sovereign Cloud
- Identify which workloads actually require it. Usually a small fraction. Classify by legal requirement and consequence of foreign disclosure, not by general discomfort. Applying sovereignty requirements to everything is how programmes become unaffordable and get abandoned entirely.
- Interrogate what "sovereign" means in the specific offer. Local ownership, local staff, local keys, local support, or simply local data centres? These are very different levels of protection and the marketing rarely distinguishes them.
- Follow the administrative access. Who can technically reach the data — which engineers, in which country, under which employment entity, with which emergency override? This is the operative question and it is answerable.
- Check the technology supply chain. Hardware origin, hypervisor, management software and firmware update paths all extend the dependency map beyond the provider's nationality.
- Insist on customer-managed keys where it matters. Key custody is the control that survives every legal and ownership argument. If the provider can decrypt, all other assurances are procedural.
- Assess the provider's survival odds. The first generation disappeared within five years, taking migration costs and continuity with it. Financial backing, customer base and exit provisions are as important as the sovereignty claim.
- Price the capability gap, not just the invoice. Slower feature availability, fewer managed services and a smaller skills market are real costs that appear later as engineering effort.
- Plan for reversibility. Data export, standard formats and avoidance of proprietary lock-in matter more with smaller providers, precisely because the probability of needing to move is higher.
The Regional Version
Gulf states arrived at the same conclusion later and with more infrastructure leverage. Regional data protection regimes, sectoral rules in banking and healthcare, and national cloud policies have produced localisation requirements comparable to those debated in Europe in 2011 — with the difference that the major platforms now operate regional infrastructure, and that governments in the UAE and Saudi Arabia have negotiated operating arrangements rather than attempting to build competing national providers from scratch. That is the right reading of the 2011 experience. The objective was never a domestic company; it was control over who can compel disclosure and who can technically read the data. Those can be obtained from a global platform under the right structure, and they cannot be obtained from a domestic provider that simply asserts nationality.
The AI Repetition
The pattern is repeating with models. Governments and enterprises are asking where inference runs, who operates it, which jurisdiction governs the operator, and whether prompts and outputs can be compelled or retained for training. The responses look familiar: national AI initiatives, sovereign model programmes, in-country inference commitments. Some will be genuinely necessary. Most will encounter the same economics that killed the sovereign cloud ventures — the capability gap between a well-funded national effort and a global frontier lab is large and widening, and buyers will not accept a materially worse model for a benefit they cannot price. The workable answer will be the same as it was for infrastructure. Not a domestic alternative to everything, but controlled operating arrangements for the narrow set of workloads that genuinely require them, with clear-eyed honesty about which those are.
Common Questions
What was the Andromède sovereign cloud project?
A French state-backed initiative conceived in 2009 to create a national cloud provider, with an ambition of around €285 million. It was split into two ventures — Cloudwatt, with Orange and Thales, and Numergy, with SFR and Bull — after the original partners could not agree.
Why did the first sovereign cloud providers fail?
Because cloud economics reward enormous scale, the capability gap against hyperscale platforms widened rather than closed, governance by consortium slowed product development, and buyers would not accept a weaker platform for a benefit they could not quantify.
Is sovereign cloud a bad idea?
No, but its honest market is narrow. Classified government data, critical infrastructure and certain health and defence categories have categorical requirements. Applying the same standard to all workloads makes programmes unaffordable.
What does a credible sovereignty arrangement look like today?
A locally incorporated operator with exclusive administrative access, vetted local personnel, customer-held encryption keys and technical structures that prevent a foreign parent from obtaining plaintext — layered onto a capable global platform rather than replacing it.
Sovereign Cloud Evaluation — Outpace works out which of your workloads genuinely need sovereign hosting and which sovereignty claims hold up when you follow the administrative access.