Summary

  • PREMI3NS is no longer merely an announced future service. S3NS made it generally available on 16 October 2025, and ANSSI qualified the IaaS, PaaS and CaaS service under SecNumCloud 3.2 on 17 December 2025, with the decision listed as valid until 17 December 2028.
  • Its physical geography is concentrated but deliberately partitioned: the standalone u-france-east1 region has three zones, each associated with one of three independent data centres in France. Public product documentation says features that require multiple regions are unavailable.
  • Thales Cloud Sécurisé is the qualified supplier and S3NS is the commercial identity. The company is governed under French law and controlled by Thales; its 2024 accounts recorded a 95% Thales and 5% Google shareholding, while current statutes give five voting board seats to Thales nominees and a non-voting observer position to the other shareholder.
  • The public record strongly supports French control, a live service, a substantial managed-service catalogue and zone-level design. It does not disclose the three facility operators, precise sites, utility feeds, carrier contracts, backbone topology, spare inventories or customer support response commitments.
  • The resulting evidence grade is Medium. S3NS has unusually strong regulatory and operating evidence for a young cloud, but a buyer cannot infer whole-region recovery, usable failover capacity or rapid physical repair from SecNumCloud qualification or a three-zone map alone.

A cloud promise has become an operating service

S3NS should now be assessed as a live infrastructure provider, not as the proposal France first debated in 2022. The sequence matters. The company opened an early-access programme in January 2025, said that more than 50 customers and partners had participated when it closed that programme, moved PREMI3NS into general availability on 16 October 2025, and received a SecNumCloud 3.2 security visa two months later. By April 2026, an S3NS, SAP and Thales announcement said the company served more than 60 customers and offered 30 managed services, with another 30 planned over the following year.

Those milestones settle one question that previously required caution: PREMI3NS is not just design capacity or a future certification target. There is a production service, a qualified scope and a base of organisations using S3NS offerings. The distinction between the offerings remains important. CRYPT3NS, the earlier local-controls product built around standard Google Cloud, was explicitly introduced without a goal of SecNumCloud qualification. PREMI3NS is the separate, dedicated environment that ANSSI qualified. A customer cannot carry assurances from one product name to another merely because both are sold by S3NS.

The ANSSI qualification decision is more precise than a press release. It names the provider as THALES CLOUD SÉCURISÉ and the service as CLOUD DE CONFIANCE S3NS. Its scope covers infrastructure, platform and container services, not software as a service. The agency's current catalogue gives the qualification dates as 17 December 2025 to 17 December 2028. That creates a clear assurance boundary: use the qualified service, in its qualified conditions, and verify that every dependent product actually falls inside that boundary.

The service catalogue is broad enough to create material dependence. The PREMI3NS product page lists virtual machines, Kubernetes, object and block storage, managed relational databases, BigQuery, VPN, interconnection, DNS and security services. These are not peripheral tools. They can hold identity, transaction, analytics, application and backup functions that become hard to disentangle after an organisation standardises its operating model around them.

That is why the physical layer matters now. A roadmap can be judged by plausibility. A production cloud has to be judged by what remains usable when a rack loses power, a zone is isolated, a carrier fails, an update is withheld, a support queue fills or a customer needs to leave.

The supplier is Thales Cloud Sécurisé, not an abstract alliance

The name S3NS describes a partnership and a brand, but the legal supplier is concrete. France's business register identifies THALES CLOUD SECURISE, SIREN 908 211 980, as a French simplified joint-stock company created in 2021. Its current registered office is at 26 rue de Montholon in Paris. The company's updated statutes show capital of €3.3 million as of April 2026.

Control is more informative than the loose description "Thales and Google cloud." The company's 2024 financial statements state that Thales held 95% of the shares and Google 5% at year-end. The 2026 statutes provide for five voting directors proposed by Thales and one non-voting observer appointed by the other shareholder. They also exclude that observer from customer data and sensitive physical and logical security information. In testimony before a French parliamentary inquiry in 2026, Google's public-affairs director described Google as having an observer seat without a vote or veto on the board. The statutes are the more useful evidence because they spell out the structure rather than compressing it into a slogan.

This does not mean Google is unimportant. The 2024 accounts say S3NS and Google signed the agreement governing technical and commercial relations for the trusted cloud in December 2024. Google supplies the underlying cloud technology and its evolution. S3NS's value proposition is that Thales Cloud Sécurisé controls the dedicated environment, personnel, keys, operations and deployment of updates while acquiring the benefit of Google's software engineering.

That boundary has passed a demanding French qualification. It is still a supplier boundary. If software updates stop, licensing terms change, documentation access narrows or a hardware generation becomes unavailable, legal control of the running environment does not manufacture a replacement technology stack. Conversely, technology dependence does not imply that Google can read customer data or administer PREMI3NS. The meaningful assessment holds both facts at once: S3NS controls the qualified service; Google remains a strategic technology supplier.

The corporate record also gives evidence of build-out. S3NS reported 126 employees at the end of 2024, after adding 51 during the year, including 40 additions to technical teams. Its balance sheet recorded €14.2 million of tangible assets under construction, up from €3.7 million a year earlier. Revenue rose to €4.94 million, while the company reported a €942,293 annual loss. Those figures describe an investment-stage operator before general availability and qualification. They do not prove customer capacity or financial weakness by themselves, but they show that the service depended on substantial construction and staffing before the launch.

One French region contains three physical failure domains

PREMI3NS is physically narrower than the word cloud suggests. The current Cloud de Confiance overview says it is a self-contained cloud universe with one region, u-france-east1. That region has three zones: u-france-east1-a, u-france-east1-b and u-france-east1-c. S3NS's sales material says the region comprises three independent data centres in France. Earlier S3NS material located them in the Paris region and described dedicated rooms close to the three Google France data centres, with physically and logically isolated racks, servers and networks.

This is meaningful physical evidence. It indicates more than three labels applied to one server room. The vendor says the zones map to independent data centres, and its documentation tells customers to treat each zone as a distinct failure domain. Applications distributed across zones can therefore be designed to survive some failures of hardware, power, cooling or networking in one zone.

But a zone is not automatically a complete duplicate of every service. Compute instances and zonal disks remain attached to a zone. Some regional services replicate across zones, while other managed products have their own durability and availability semantics. A customer who launches a virtual machine and attaches a zonal disk has not gained three-site continuity merely by choosing a three-zone region. It has placed two zonal resources in one failure domain.

The burden of architecture stays with the customer. Compute needs at least another instance in another zone, health checks and a traffic-shifting mechanism. Stateful systems need a replication model whose consistency and recovery behaviour match the application. Identity, secrets, logging and deployment controls must also survive the same zone failure. Backups must be restorable when the primary service is impaired, rather than merely existing as another object inside the affected operational boundary.

S3NS does not publish the street addresses or operators of the three facilities in the material linked here. That restraint is understandable for a platform built for sensitive workloads. It also means a buyer cannot independently determine whether the sites share a floodplain, utility substation, fibre corridor, landlord, maintenance contractor or remote-hands supplier from the zone names alone. "Independent data centres" is a useful claim; correlation risk remains a due-diligence question to be answered under confidentiality.

Three zones do not create a second region

The largest architectural constraint is stated plainly in S3NS documentation: Cloud de Confiance currently has one region, and features that require multiple regions are unavailable. That makes the difference between high availability and disaster recovery especially important.

Three zones can protect against a server, rack or site-level event if the application uses them correctly. They do not protect against every event that affects the region as a unit. Regional identity, control-plane, software, routing or operational failures can cross zone boundaries. A severe metropolitan power or fibre event can also create correlated pressure even where the buildings are physically separate. So can a security response that intentionally disables a shared service across the whole environment.

Google's public cloud usually allows a customer to pair regions. PREMI3NS does not currently offer that pattern inside its qualified universe. Its "global" resources are global only within the self-contained S3NS environment and resolve to the single French region; they are not replicas spread across Google's worldwide cloud. This is a necessary consequence of strict jurisdictional and operational separation, but it changes the recovery calculation.

A customer with a requirement to survive loss of u-france-east1 needs a second environment outside PREMI3NS. That might be an on-premises estate, another qualified French or European provider, a separately controlled cold recovery environment, or a less sensitive service tier with a carefully defined data boundary. Each choice introduces its own problems: data replication, key custody, software compatibility, network capacity, operator access and the legal status of the recovery copy.

This is not an argument against PREMI3NS. A single region can be the right boundary for sensitive data, particularly when the alternative gives a foreign supplier direct operational control. It is an argument against mistaking three zones for geographic disaster recovery. The decision belongs in the business impact analysis: which workloads can accept a regional outage, which must recover elsewhere, and how much data or functionality may be lost during that move?

The provider's own documentation points in the right direction by telling customers to distribute applications across zones. A mature contract should continue the thought. It should define whether S3NS has a regional restoration plan, how configuration and customer metadata are recovered after a catastrophic loss, and what assistance is available to rebuild outside the platform if the region cannot return within the customer's deadline.

Physical isolation changes who can touch the machines

S3NS's core engineering claim is not simply that data are stored in France. It is that the equipment is isolated and the people who can operate it are under S3NS control. The company describes dedicated racks, servers and network equipment, physical access controls, surveillance and intrusion detection, alongside separate identities, roots of trust, encryption and network boundaries. The qualification announcement says only S3NS employees administer the service and that Google technology and updates enter a quarantine area for analysis and validation before production deployment.

Those controls address several real risks. A remote administrator employed by Google should not be able to enter the environment. A software update is not supposed to flow straight from the technology supplier into production. Cryptographic control and production identity sit with the French operator. The qualified service must also meet SecNumCloud requirements for physical security, isolated administration, incident handling, continuity, subcontracting and protection against non-European law.

Physical separation, however, creates an operating estate that S3NS must maintain itself. Someone has to receive servers, validate firmware, cable racks, replace failed drives, rotate hardware security modules and coordinate work inside the data hall. A repair that would be performed by a hyperscaler's global fleet becomes an S3NS responsibility or a tightly controlled subcontracted activity. The operator needs sufficient staff, access rights, spares and supplier agreements in all three sites.

Public documents do not state the number of racks, server generations, aggregate power allocation, cooling headroom, spare-part holdings or local technician coverage for each zone. Nor do they identify which facility work is performed by S3NS employees and which remains with landlords or specialist contractors. SecNumCloud establishes that the controls were assessed within the qualified scope. It does not provide customers with a capacity schedule or a repair-time guarantee for every component.

That hidden operational estate is the economic substance of the service. Customers pay for S3NS to convert equipment, leases, power, transit, licences, security controls and specialist labour into metered cloud services. The margin between installed infrastructure and customer demand determines whether a failed rack produces a routine evacuation or a capacity shortage. The parts contract determines whether a failed network chassis returns in hours or waits for international logistics. Neither result is visible in a product catalogue.

Software sovereignty has a maintenance clock

PREMI3NS is designed to stop Google from administering the customer environment or switching it off remotely. That is different from eliminating dependence on Google engineering. Managed databases, orchestration, storage and analytics services remain complex software systems that require security fixes, compatibility work and hardware enablement. The question is therefore not only whether S3NS can keep today's code running after a supplier break. It is how long it can run safely while vulnerabilities, certificates, dependencies and customer requirements continue to change.

The SecNumCloud 3.2 requirements explicitly address operational autonomy where a provider depends on a third party. ANSSI's director later stressed publicly that qualification protects against direct non-European access and a customer-specific shutdown, but does not mean there is no technological dependence. That is the right distinction. Sovereignty over operation is not the same as indefinite independence from every supplier.

Google says its Dedicated Cloud design lets the local partner monitor, block and reverse updates, and that it can continue operating for up to 12 months after a connection to Google is severed. The same Google publication identifies PREMI3NS as the French implementation. This is a significant continuity claim, but the public wording describes design capability rather than a customer-specific recovery guarantee. A buyer should establish which PREMI3NS services are covered, what "operate" means during the period, which security updates remain available, and what happens at the end of it.

The quarantine mechanism brings its own trade-off. Screening updates reduces the risk of a compromised or unsuitable release entering the trusted environment. It can also create feature lag and a queue when many upstream changes arrive at once. S3NS needs enough engineering depth to assess, test, approve or reject updates without leaving critical vulnerabilities unresolved. Customers need notice of differences from standard Google Cloud so that deployment scripts and managed-service assumptions do not drift silently.

S3NS documentation already warns that Cloud de Confiance is a separate product with a subset of Google Cloud products and different endpoints, including s3nsapis.fr rather than googleapis.com. That is evidence of real separation. It is also evidence that migration is not a simple region switch. Application owners must test code, libraries, identity assumptions, service availability and operational procedures against the S3NS universe itself.

Connectivity begins where the customer enters the cloud

A sovereign server that cannot be reached is not a service. PREMI3NS supports public internet access, Cloud VPN and Cloud Interconnect, and those paths have different failure and trust boundaries. The network-connectivity documentation describes VPN as encrypted traffic over the public internet and Interconnect as dedicated or partner connectivity between a customer network and the cloud.

For a production estate, the access design should match the zone design. Two virtual machines in separate zones still depend on one customer router if both are reached through one tunnel. Two interconnect circuits can still share a building entrance, carrier, optical system or metropolitan duct. A resilient diagram needs diversity at every handoff: customer routers, carrier providers, cross-connects, S3NS edge domains, BGP sessions and enough failover bandwidth to carry the critical load.

S3NS's Partner Interconnect documentation illustrates the point. It says a 99.9% design needs two redundant attachments in different edge availability domains, while its generic 99.99% pattern requires four attachments split across two metropolitan areas and two regions. Because PREMI3NS currently has only one region, that two-region pattern cannot be implemented entirely inside the present S3NS universe. Customers should not assume that purchasing four circuits inside Paris creates the same failure isolation.

HA VPN has a different topology. S3NS documents a 99.99% configuration when both interfaces of the managed gateway connect through matching tunnels to the peer side. But the availability of the end-to-end connection still depends on the customer's physical gateways, internet providers or interconnects, routing policy and hosted workload. A cloud-side service-level figure does not cover a single router in the customer's office.

Throughput is also part of recovery. An interconnect sized for normal database replication may be too small to reseed storage after a failure. A VPN that carries management traffic comfortably may collapse when it becomes the only path for customer transactions. Recovery exercises should measure transfer rates under the degraded topology, not use port speed as a proxy.

The carrier and backbone layer remains opaque

PREMI3NS documentation says its premium network carries traffic on the Cloud de Confiance network and selects BGP paths to peering or transit networks. It also lets customers bring eligible IPv4 and IPv6 ranges, subject to ownership validation and route-origin authorisation. These are mature cloud networking capabilities. They do not reveal the actual suppliers or physical routes behind the S3NS edge.

The public material linked in this article does not name the transit carriers, interconnection buildings, internet exchanges, backbone fibre providers or route-server relationships used by PREMI3NS. It does not publish a platform ASN, a complete provider prefix list or a map that a customer could use to establish path diversity. The addresses exposed by a customer's workload may also depend on whether the customer uses S3NS-assigned space, brings its own addresses, enters through a partner or keeps service private.

Opacity is not proof of fragility. Sensitive providers often limit topology disclosure, and a distributed virtual network cannot be reduced to one router icon. It does mean that the phrase "multiple paths" needs evidence under non-disclosure. Buyers should ask whether the three zones have physically separate fibre entrances, whether inter-zone links share ducts, where dedicated interconnects terminate, and whether two named carrier products ultimately ride the same wholesale network.

They should also ask how S3NS validates routing security. Customer-provided prefixes require correct route-origin authorisations, accurate routing objects and a controlled cutover. Provider space needs its own origin security and filtering. A mistaken route policy can withdraw a healthy service from the internet even while every rack remains powered.

The boundary extends beyond S3NS. A public application relies on DNS, certificate issuance, domain registration, content distribution, identity and upstream user networks. Some of those services may sit outside PREMI3NS or outside France. Hosting the core workload in a qualified region does not automatically bring the whole service into the same jurisdiction or failure domain.

Installed capacity is not failover capacity

S3NS advertised 30 managed services in February 2026 and lists H100 GPU virtual machines among its compute options. That demonstrates breadth, not quantity. Public documents do not state how many processors, GPUs, storage devices or network ports are installed in each zone, how much is reserved, or how much headroom remains after a zone loss.

This matters because cloud capacity is sold twice in the customer's imagination. The first sale is elasticity: resources appear on demand. The second is redundancy: another zone appears ready when the first fails. Both promises draw on the same physical inventory. If many customers request replacement instances during a zonal event, spare capacity can disappear quickly. A quota that permits a resource in normal conditions does not guarantee that equivalent hardware will be available during regional stress.

Specialised equipment tightens the constraint. GPU workloads may depend on a particular accelerator, driver and machine family that is not evenly stocked across all zones. Large-memory databases and high-throughput storage have similar placement limits. A customer can build a nominal multi-zone design that cannot actually restart elsewhere with the same shape.

The correct measure is usable capacity after the chosen failure, not installed capacity before it. For critical services, customers need reserved or contractually prioritised capacity, placement confirmation and periodic evidence that the standby zone can accept the workload. They also need an agreed degradation strategy: smaller instances, reduced analytics, paused batch work or a minimum transaction service when full capacity cannot be restored.

S3NS has good reasons not to publish fleet counts. Competitors and attackers would value the information, and counts change rapidly. Confidential assurance can still give buyers what they need: capacity classes, tested evacuation limits, lead times for uncommon hardware and the priority rules used during contention. Without that evidence, "three zones" describes locations, not the amount of service available after one is lost.

Support labour is part of the infrastructure

The early-access programme exposed a useful detail about S3NS's operating model. The company said site reliability engineers, cybersecurity teams, data-centre staff, support, technical account managers and customer engineers all participated. That is credible evidence of an organisation built to operate more than a self-service portal. The current platform overview also states that S3NS, not Google Cloud, is responsible for infrastructure management and support.

This local responsibility is central to the sovereignty claim. A customer incident should not require a Google administrator to enter the environment. It also concentrates escalation on S3NS. If a managed database defect requires upstream expertise, S3NS has to reproduce the issue, control what information leaves the environment, coordinate with Google and return a safe fix. The customer depends on the quality of that translation layer.

Public material does not provide a complete support matrix with severity definitions, initial-response times, restoration targets, telephone escalation conditions and compensation by service tier. The general-availability announcement says contractual service-level agreements accompanied launch, but it does not reproduce them. Buyers therefore need the contract, not the launch language.

The repair clock should be decomposed. Detection is the time until S3NS or the customer notices a fault. Ownership is the time until someone with authority accepts it. Diagnosis identifies whether the problem belongs to the customer's configuration, the managed service, the S3NS network, a facility or a technology update. Access is the delay before an engineer can enter the relevant site. Repair includes parts, change approval and validation. Recovery is not complete until the application, data and queued work are usable again.

One blended restoration target hides these transitions. It also hides third parties. Facility remote hands, fibre technicians, hardware vendors and Google specialists may all be involved without operating the customer environment directly. A customer should know which party can stop the clock, which party speaks to it during a major incident, and whether the status channel remains reachable if identity or the S3NS console is impaired.

A service-level agreement does not build a resilient application

S3NS described general availability as bringing formal service-level agreements and production readiness. That is necessary commercial evidence. An SLA is still a bounded promise around a defined service metric. It cannot make a zonal virtual machine regional, add a second PREMI3NS region or repair a customer architecture that sends every route through one gateway.

The difference becomes sharp during a compound incident. Suppose a zone loses power, the application fails over, and the surviving database reaches a customer-imposed connection limit. The infrastructure service may meet its availability measure while the application is unavailable. If the customer has not distributed identity, secrets or monitoring, the provider may restore infrastructure before the business can restore service.

Service credits are similarly limited. They adjust an invoice after a qualifying failure. They do not reimburse lost public services, delayed medical work, missed financial transactions or emergency migration labour. For sensitive systems, the useful contract language covers incident communication, data integrity, assistance, evidence preservation, recovery priorities and termination support, not only a monthly uptime percentage.

Maintenance exclusions need equal attention. A provider operating a quarantined software supply has to patch and upgrade. Customers need to know how much notice applies, whether zones are maintained sequentially, what happens when an emergency change cannot wait, and whether a rollback is technically possible. They should design applications to tolerate the maintenance behaviour that the contract permits.

The status channel is another dependency. S3NS documentation refers customers to a Cloud de Confiance service-health dashboard, but a useful major-incident channel must work outside the failing console and identity plane. Named contacts, independent notification paths and a cadence for updates are operational capacity: they determine how quickly customers can choose between waiting, failing over and invoking a regional recovery plan.

SecNumCloud is strong assurance, not universal insurance

The SecNumCloud qualification is the strongest public evidence supporting PREMI3NS. ANSSI's framework covers far more than data location. Its requirements include physical security, access control, isolated administration, logging, vulnerability management, cryptography, continuity, supplier management, reversibility and protection from non-European law. The agency's qualification FAQ explains that customer data, administration directories, user directories, logs, root authorities and backups must meet territorial controls, and that continuous operating autonomy is assessed.

The decision also states that S3NS satisfies recommendation R9 of France's state cloud doctrine and offers protection against extra-European law. That is a consequential result for public bodies and regulated organisations. France's Cloud at the Centre doctrine directs particularly sensitive state workloads toward qualified commercial clouds that are protected from unauthorised access by third-country authorities.

Qualification does not mean every use of S3NS is automatically compliant or resilient. The ANSSI decision conditions use on the recommendations in the framework. Customers still configure identities, networks, storage, encryption, logging and applications. They can create a single-zone database, expose an unsafe service or copy data to an unqualified external system.

Nor does the visa cover every product sold under the S3NS name. It covers the named Cloud de Confiance service as IaaS, PaaS and CaaS. CRYPT3NS was explicitly marketed as a stepping stone that did not seek SecNumCloud qualification. Partner SaaS applications running on PREMI3NS require their own scope analysis. A qualified substrate does not automatically qualify the software and operating practices above it.

Finally, the visa has dates. It runs for three years and depends on continued compliance. Material legal, organisational or technical changes have to be managed within the qualification obligations. Procurement should record the decision number, scope, expiry and any later conditions rather than using "SecNumCloud" as a timeless badge.

Customer announcements show demand, not tested recovery

S3NS has named customers in insurance, health, finance, industry and services. Its qualification announcement cited MGEN, Matmut, AGPM, Thales, Birdz, Qonto, BConnect and Club Med. The MGEN case is especially material because the insurer described a platform intended to accommodate up to six million people. An April 2026 announcement said SAP RISE Private Cloud Edition would be deployed on PREMI3NS for Thales in the second half of 2026, covering core business areas including finance, supply chain, manufacturing and procurement.

These names support the conclusion that S3NS is serving or preparing real workloads. They also indicate who bears the consequences of failure: policyholders, health-service users, employees, suppliers, finance teams and industrial operations. That consequence raises the value of strong French control while increasing the need for practical recovery.

A customer announcement is not an incident history. It rarely states which workloads are already in production, how much data they hold, whether they span all three zones, what recovery time was demonstrated or whether a regional exit was exercised. "Chosen by" can describe a contract, migration programme, early-adopter test or production estate. Each has a different evidentiary weight.

The right use of such announcements is therefore modest. They validate market traction and show that demanding organisations have carried out their own evaluations. They do not transfer those organisations' undisclosed assurance to another buyer. A new customer must test its own application, network, data and support chain.

S3NS itself is also a customer of suppliers. Data-centre landlords, utilities, carriers, server manufacturers, component distributors and Google sit behind the service even where they cannot administer it. The trust model is stronger when each dependency is constrained, replaceable and tested. It is weaker when the customer treats the S3NS contract as the final node in the chain.

Data locality needs a map of every copy

PREMI3NS offers a clear primary-location proposition: data and workloads stay in France in a dedicated S3NS environment. That is stronger than assuming location from a billing address or an IP geolocation result. The architecture also keeps production identity, key control, administration and support under the French operator's authority.

Customers still need to map each category of information. Primary data, replicas, backups, snapshots, logs, support attachments, billing records, telemetry, keys and identity metadata do not necessarily share the same lifecycle. SecNumCloud imposes territorial requirements within the qualified service, but a customer can send logs to an external platform, open a support case containing sensitive data or replicate a database into another jurisdiction.

The single-region design makes backup placement particularly important. A backup copied across three zones can survive a device or site failure, but it remains inside u-france-east1. A copy outside the region improves disaster recovery but may leave the exact qualified boundary the organisation selected. Some workloads may justify encrypted cold storage at another qualified provider; others may be legally or operationally required to stay in the S3NS environment. The answer depends on the data and the recovery objective.

Key management must follow the same map. A recovery copy is useless if its keys are trapped in the failed region. A key copied elsewhere can create a new access path that undermines the original control. Recovery design therefore needs independent availability for keys, identities, configuration and the people authorised to use them, with controls at least as deliberate as those around the data.

Locality also changes latency and service area. The three data centres are in France, with earlier S3NS descriptions placing them in the Paris region. European users may receive good latency, but a French region is not automatically close to every branch, factory or overseas territory. The access network and application design determine experienced performance. A multinational organisation also has to decide whether all users and data belong in the French jurisdiction or whether PREMI3NS should hold only the sensitive subset.

Migration is the final recovery mechanism

S3NS promotes continuity with Google Cloud technology, and that can reduce migration effort for customers already using familiar APIs and managed services. It does not make the platforms identical. The dedicated universe has different endpoints, a narrower service set, one region and qualification-driven operational controls. Migration into PREMI3NS is a planned engineering programme; migration out will be one too.

An S3NS migration guide notes that transfer time depends on data volume and network bandwidth. That simple statement becomes severe during an outage. Moving 500 terabytes over a path delivering a sustained 5 gigabits per second takes more than nine days before protocol overhead, retries, validation and application cutover. If the source service is degraded, actual throughput may be much lower. If the destination uses a different managed database, conversion can dominate copying.

French and European rules are strengthening the customer's position. Article 28 of the French SREN law requires cloud services to support secure interoperability, portability of exportable data and digital assets, and the interfaces and information needed to perform it. Arcep's 2025 recommendation focuses on switching transparency and stable interfaces. The EU Data Act applies switching obligations and phases out switching charges.

Legal portability does not guarantee operational equivalence. Exportable data may exclude provider intellectual property. A Kubernetes application may move more readily than a workload built around BigQuery, Cloud SQL behaviour, provider identity and proprietary monitoring. Even where records export cleanly, policies, queues, event history, cryptographic state and operational dashboards may not.

Customers should therefore maintain a small but complete recovery deployment elsewhere. It should restore real data, recreate identity and networking, and prove that the business can operate at a defined minimum level. The exercise should record transfer speed, conversion failures, missing metadata and the people required. An exit plan that exists only as contract language is not spare capacity.

The credible failure paths are ordinary

S3NS attracts attention because of geopolitical and legal questions, but the most probable failures are familiar infrastructure events. A power component fails. A storage device produces errors. A fibre is cut. A BGP route is withdrawn. A certificate expires. A managed-service update changes behaviour. A support ticket is misclassified. A customer's payment or account state interrupts access. A migration runs longer than its approved window.

A rack or server failure should be contained by local redundancy, but only if the service and customer placement support it. A zone failure should be contained by multi-zone architecture and adequate surviving capacity. A regional failure has no second PREMI3NS region and therefore invokes the customer's external recovery design. An upstream or interconnect failure invokes diverse network paths. A software-supply interruption invokes S3NS's autonomy and update strategy. A contract or billing dispute invokes administrative continuity and export rights.

Each path affects a different population. An isolated analytics service may delay internal reporting. Identity failure can prevent every application from starting even while compute remains healthy. Loss of a health platform can affect care administration and patient access. Loss of an industrial ERP can block purchasing, manufacturing and shipment. The dependency should be ranked by business function, not by the apparent importance of the cloud resource name.

Compound failures deserve particular attention. A zone outage during maintenance leaves less spare capacity. A cyber incident can disable automation while increasing demand for manual support. A regional network problem can slow the very backup transfer intended for recovery. A supplier dispute can coincide with an urgent security vulnerability. Resilience is the ability to operate through those combinations, not the presence of three boxes on an architecture diagram.

S3NS has built unusually strong control around a French cloud based on non-French technology. That achievement removes some failure paths, especially direct foreign administration and customer-specific remote shutdown by the technology supplier. It does not remove physics, software ageing, human error or customer concentration.

Evidence a buyer should obtain before committing a critical workload

The first evidence should describe placement. S3NS can confirm, under appropriate confidentiality, that the selected services use all three data centres, which components remain zonal, which are regional, and which control-plane dependencies cross the zones. The customer can then map every compute, storage, identity, key, logging and deployment component to a failure domain.

The second evidence should describe surviving capacity. For each critical machine and managed service, the customer needs to know whether equivalent capacity is reserved or likely to be available after one zone is lost. Specialised processors, large memory shapes, storage performance and public addresses should be included. A successful exercise in which workloads restart in another zone is more valuable than an availability adjective.

The third evidence should describe physical and network diversity without exposing sensitive details publicly. Independent facility and utility risk, separate entrances, inter-zone paths, carrier ownership, interconnect termination and failover bandwidth can be validated in a controlled assurance setting. The answer should identify shared dependencies, not merely count contracts.

The fourth evidence should describe repair and escalation. The customer should know who answers at every hour, when S3NS site staff become involved, which repairs depend on facility or hardware suppliers, what parts are held locally and how an issue reaches Google without exposing customer data. Major-incident communications should have an out-of-band route.

The fifth evidence should be a regional recovery exercise. Because there is one PREMI3NS region, the customer should restore a representative service outside it, including data, keys, identity, configuration and network entry. The measured result should be compared with the business recovery objective. Any step that assumes the source console remains available should be tested again without that assumption.

Finally, the contract should align with the technical result. Qualification scope, service levels, maintenance, incident assistance, data location, subcontractors, software-supply continuity, portability, deletion and termination support should all describe the same service the engineers tested. A contract cannot create capacity, but it can make responsibility and evidence available before a failure.

The evidence grade is Medium

S3NS has crossed the threshold from plausible project to evidenced operator. PREMI3NS is generally available, has a named legal supplier, employs a substantial French team, runs a documented standalone region, exposes a broad managed-service catalogue, has public customer programmes and holds a current SecNumCloud 3.2 qualification for IaaS, PaaS and CaaS. Those are stronger signals than a marketing map, dormant company record or unverified cloud label.

The downgrade from Strong reflects what remains unavailable in public. The three data-centre operators and exact sites are not named. Utility, carrier, backbone and cross-connect diversity are not described. There are no public fleet counts, zone evacuation limits, spare-part schedules or complete customer support response terms. Most importantly, PREMI3NS has one region. Its three zones improve availability but do not provide in-platform recovery from loss of the region.

The fair conclusion is therefore neither "French control solves everything" nor "Google technology makes sovereignty meaningless." ANSSI has established that Thales Cloud Sécurisé controls the qualified environment and protects it from non-European legal access under the stated conditions. The platform still depends on Google technology, French data-centre infrastructure, electricity, fibre, hardware supply and S3NS personnel. These dependencies can be managed because they are identifiable; they cannot be managed by pretending they disappeared.

For a buyer, S3NS's most valuable feature may be the clarity of its boundary. The service is one French, autonomous cloud region with three physical zones, operated by a Thales-controlled French company using Google cloud technology under a qualified control model. Build across the zones. Prove capacity in the surviving sites. Obtain confidential evidence of physical and route diversity. Keep a tested recovery environment beyond the region. Then the sovereignty promise becomes an operating capability rather than a badge attached to someone else's racks.