s3ns Thales Cloud Securise SAS commercialise une capacité hébergée toujours tributaire des racks, du transit et des fenêtres de réparation

Résumé

• PREMI3NS n'est plus un simple service futur annoncé. S3NS l'a rendu disponible le 16 octobre 2025, et l'ANSSI a qualifié le service IaaS, PaaS et CaaS selon la norme SecNumCloud 3.2 le 17 décembre 2025, la décision étant valide jusqu'au 17 décembre 2028.
• Sa géographie physique est concentrée mais délibérément partitionnée: la région autonomeu-france-east1comporte trois zones, chacune associée à l'un des trois centres de données indépendants en France. La documentation produit publique indique que les fonctionnalités nécessitant plusieurs régions sont indisponibles.
• Thales Cloud Sécurisé est le fournisseur qualifié et S3NS est l'identité commerciale. L'entreprise est régie par le droit français et contrôlée par Thales; ses comptes 2024 font état d'une participation de 95 % pour Thales et de 5 % pour Google, tandis que ses statuts actuels attribuent cinq sièges avec droit de vote au conseil aux représentants de Thales et un poste d'observateur sans droit de vote à l'autre actionnaire.
• Les documents publics confirment clairement le contrôle français, un service opérationnel, un catalogue substantiel de services gérés et une conception par zones. Ils ne divulguent pas les trois exploitants des sites, les emplacements précis, les sources d'énergie, les contrats de transport, la topologie du backbone, les stocks de pièces de rechange ou les engagements de support client.
• Le niveau de preuve qui en résulte est Moyen. S3NS dispose de preuves réglementaires et opérationnelles exceptionnellement solides pour un jeune cloud, mais un acheteur ne peut pas déduire une reprise après sinistre de toute la région, une capacité de basculement utilisable ou une réparation physique rapide uniquement à partir de la qualification SecNumCloud ou d'une carte à trois zones.

Une promesse de cloud devenue un service opérationnel

S3NS doit désormais être évalué comme un fournisseur d'infrastructure opérationnel, et non comme la proposition que la France a débattue pour la première fois en 2022. La chronologie est importante. L'entreprise a ouvert un programme d'accès anticipé en janvier 2025, a déclaré que plus de 50 clients et partenaires y avaient participé à sa clôture, a fait passer PREMI3NS endisponibilité générale le 16 octobre 2025, et a reçu unvisa de sécurité SecNumCloud 3.2deux mois plus tard. En avril 2026, uneannonce de S3NS, SAP et Thalesindiquait que l'entreprise servait plus de 60 clients et proposait 30 services gérés, avec 30 autres prévus pour l'année suivante.

Ces jalons règlent une question qui exigeait auparavant de la prudence: PREMI3NS n'est pas seulement une capacité de conception ou une cible de certification future. Il existe un service de production, un périmètre qualifié et une base d'organisations utilisant les offres S3NS. La distinction entre les offres reste importante. CRYPT3NS, le produit antérieur de contrôles locaux construit autour de Google Cloud standard, a été explicitement présenté sans objectif de qualification SecNumCloud. PREMI3NS est l'environnement dédié et distinct que l'ANSSI a qualifié.

Un client ne peut pas transposer les garanties d'un nom de produit à l'autre simplement parce que les deux sont vendus par S3NS.

Ladécision de qualification de l'ANSSIest plus précise qu'un communiqué de presse. Elle désigne le fournisseur comme THALES CLOUD SÉCURISÉ et le service comme CLOUD DE CONFIANCE S3NS. Son périmètre couvre les services d'infrastructure, de plateforme et de conteneurs, pas les logiciels en tant que service. Lecatalogue actuel de l'agenceindique les dates de qualification du 17 décembre 2025 au 17 décembre 2028. Cela crée une limite d'assurance claire: utilisez le service qualifié, dans ses conditions qualifiées, et vérifiez que chaque produit dépendant entre réellement dans ce périmètre.

Le catalogue de services est suffisamment large pour créer une dépendance importante. Lapage produit PREMI3NSliste les machines virtuelles, Kubernetes, le stockage objet et bloc, les bases de données relationnelles gérées, BigQuery, le VPN, l'interconnexion, le DNS et les services de sécurité. Ce ne sont pas des outils périphériques. Ils peuvent héberger des fonctions d'identité, de transaction, d'analyse, d'application et de sauvegarde qui deviennent difficiles à démêler une fois qu'une organisation a standardisé son modèle opérationnel autour d'eux.

C'est pourquoi la couche physique est importante maintenant. Une feuille de route peut être jugée sur sa plausibilité. Un cloud de production doit être jugé sur ce qui reste utilisable lorsqu'un rack perd l'alimentation, qu'une zone est isolée, qu'un transporteur tombe en panne, qu'une mise à jour est bloquée, qu'une file d'attente de support se remplit ou qu'un client doit partir.

Le fournisseur est Thales Cloud Sécurisé, pas une alliance abstraite

Le nom S3NS décrit un partenariat et une marque, mais le fournisseur légal est concret. Le registre du commerce français identifie THALES CLOUD SECURISE, SIREN 908 211 980, comme une société par actions simplifiée française créée en 2021. Son siège social actuel est situé au 26 rue de Montholon à Paris. Lesstatuts mis à jour de l'entrepriseindiquent un capital de 3,3 millions d'euros en avril 2026.

Le contrôle est plus informatif que la description vague « Thales et Google cloud ». Lesétats financiers 2024de l'entreprise indiquent que Thales détenait 95 % des actions et Google 5 % à la fin de l'exercice. Les statuts de 2026 prévoient cinq administrateurs avec droit de vote proposés par Thales et un observateur sans droit de vote nommé par l'autre actionnaire. Ils excluent également cet observateur de l'accès aux données des clients et aux informations sensibles de sécurité physique et logique. Lors d'une audition devant une commission d'enquête parlementaire française en 2026, le directeur des affaires publiques de Google a décrit Google comme ayant un siège d'observateur sans vote ni veto au conseil. Les statuts sont la preuve la plus utile car ils détaillent la structure plutôt que de la résumer en un slogan.

Cela ne signifie pas que Google n'est pas important. Les comptes 2024 indiquent que S3NS et Google ont signé l'accord régissant les relations techniques et commerciales pour le cloud de confiance en décembre 2024. Google fournit la technologie cloud sous-jacente et son évolution. La proposition de valeur de S3NS est que Thales Cloud Sécurisé contrôle l'environnement dédié, le personnel, les clés, les opérations et le déploiement des mises à jour tout en bénéficiant du génie logiciel de Google.

Cette frontière a passé une qualification française exigeante. Cela reste une frontière fournisseur. Si les mises à jour logicielles s'arrêtent, si les conditions de licence changent, si l'accès à la documentation se réduit ou si une génération de matériel devient indisponible, le contrôle juridique de l'environnement d'exécution ne fabrique pas une pile technologique de remplacement. Inversement, la dépendance technologique n'implique pas que Google puisse lire les données des clients ou administrer PREMI3NS.

L'évaluation pertinente retient les deux faits à la fois: S3NS contrôle le service qualifié; Google reste un fournisseur technologique stratégique.

Le dossier de l'entreprise fournit également des preuves de la montée en puissance. S3NS a déclaré 126 employés à la fin 2024, après avoir ajouté 51 personnes au cours de l'année, dont 40 dans les équipes techniques. Son bilan faisait état de 14,2 millions d'euros d'immobilisations corporelles en cours, contre 3,7 millions un an plus tôt. Le chiffre d'affaires a atteint 4,94 millions d'euros, tandis que l'entreprise a enregistré une perte annuelle de 942 293 euros. Ces chiffres décrivent un opérateur en phase d'investissement avant la disponibilité générale et la qualification.

Ils ne prouvent pas la capacité client ni la faiblesse financière à eux seuls, mais ils montrent que le service dépendait d'une construction et d'un recrutement substantiels avant le lancement.

Une région française contient trois domaines de défaillance physiques

PREMI3NS est physiquement plus étroit que ce que le mot cloud suggère. L'aperçu actuel du Cloud de Confianceindique qu'il s'agit d'un univers cloud autonome avec une seule région,u-france-east1. Cette région comporte trois zones:u-france-east1-a,u-france-east1-betu-france-east1-c. Le matériel commercial de S3NS indique que la région comprendtrois centres de données indépendants en France. Des documents antérieurs de S3NS les situaient en région parisienne et décrivaient des salles dédiées proches des trois centres de données Google France, avec des racks, serveurs et réseaux physiquement et logiquement isolés.

Il s'agit d'une preuve physique significative. Cela indique plus que trois étiquettes apposées sur une seule salle de serveurs. Le fournisseur affirme que les zones correspondent à des centres de données indépendants, et sa documentation indique aux clients de considérer chaque zone comme un domaine de défaillance distinct. Les applications réparties entre les zones peuvent donc être conçues pour survivre à certaines pannes de matériel, d'alimentation, de refroidissement ou de réseau dans une zone.

Mais une zone n'est pas automatiquement un duplicata complet de chaque service. Les instances de calcul et les disques zonaux restent attachés à une zone. Certains services régionaux se répliquent entre les zones, tandis que d'autres produits gérés ont leurs propres sémantiques de durabilité et de disponibilité. Un client qui lance une machine virtuelle et attache un disque zonal n'a pas obtenu une continuité sur trois sites simplement en choisissant une région à trois zones. Il a placé deux ressources zonales dans un seul domaine de défaillance.

La charge de l'architecture reste au client. Le calcul nécessite au moins une autre instance dans une autre zone, des contrôles de santé et un mécanisme de basculement du trafic. Les systèmes avec état nécessitent un modèle de réplication dont la cohérence et le comportement de récupération correspondent à l'application. L'identité, les secrets, la journalisation et les contrôles de déploiement doivent également survivre à la même défaillance de zone.

Les sauvegardes doivent pouvoir être restaurées lorsque le service principal est altéré, plutôt que de simplement exister en tant qu'autre objet à l'intérieur de la frontière opérationnelle affectée.

S3NS ne publie pas les adresses ou les exploitants des trois installations dans les documents référencés ici. Cette retenue est compréhensible pour une plateforme conçue pour des charges de travail sensibles. Cela signifie également qu'un acheteur ne peut pas déterminer indépendamment si les sites partagent une zone inondable, un poste électrique, un couloir de fibre, un propriétaire, un contractant de maintenance ou un fournisseur de services à distance à partir des seuls noms de zone.

« Centres de données indépendants » est une affirmation utile; le risque de corrélation reste une question de diligence raisonnable à poser sous confidentialité.

Trois zones ne créent pas une deuxième région

La contrainte architecturale la plus importante est explicitement indiquée dans la documentation S3NS: le Cloud de Confiance n'a actuellement qu'une seule région, etles fonctionnalités qui nécessitent plusieurs régions sont indisponibles. Cela rend la différence entre la haute disponibilité et la reprise après sinistre particulièrement importante.

Trois zones peuvent protéger contre un événement au niveau du serveur, du rack ou du site si l'application les utilise correctement. Elles ne protègent pas contre tous les événements qui affectent la région en tant qu'unité. Les pannes d'identité régionale, du plan de contrôle, du logiciel, du routage ou opérationnelles peuvent traverser les frontières des zones. Un événement grave d'alimentation métropolitain ou de fibre peut également créer une pression corrélée même lorsque les bâtiments sont physiquement séparés. Il en va de même pour une réponse de sécurité qui désactive intentionnellement un service partagé dans tout l'environnement.

Le cloud public de Google permet généralement à un client d'appairer des régions. PREMI3NS n'offre pas actuellement ce modèle dans son univers qualifié. Ses ressources « globales » ne sont globales qu'au sein de l'environnement S3NS autonome et se résolvent vers la seule région française; elles ne sont pas des répliques réparties sur le cloud mondial de Google. C'est une conséquence nécessaire d'une stricte séparation juridictionnelle et opérationnelle, mais cela modifie le calcul de récupération.

Un client qui a besoin de survivre à la perte deu-france-east1a besoin d'un deuxième environnement en dehors de PREMI3NS. Cela pourrait être un parc informatique sur site, un autre fournisseur français ou européen qualifié, un environnement de récupération à froid contrôlé séparément, ou un niveau de service moins sensible avec une frontière de données soigneusement définie. Chaque choix introduit ses propres problèmes: réplication des données, garde des clés, compatibilité logicielle, capacité réseau, accès des opérateurs et statut juridique de la copie de récupération.

Ce n'est pas un argument contre PREMI3NS. Une seule région peut être la bonne frontière pour les données sensibles, en particulier lorsque l'alternative donne à un fournisseur étranger un contrôle opérationnel direct. C'est un argument contre l'assimilation de trois zones à une reprise après sinistre géographique. La décision appartient à l'analyse d'impact sur l'activité: quelles charges de travail peuvent accepter une panne régionale, lesquelles doivent récupérer ailleurs, et combien de données ou de fonctionnalités peuvent être perdues pendant ce déplacement?

La documentation du fournisseur pointe dans la bonne direction en indiquant aux clients de répartir les applications entre les zones. Un contrat mature devrait poursuivre cette réflexion. Il devrait définir si S3NS a un plan de restauration régionale, comment la configuration et les métadonnées des clients sont récupérées après une perte catastrophique, et quelle assistance est disponible pour reconstruire en dehors de la plateforme si la région ne peut pas revenir dans les délais du client.

L'isolation physique modifie qui peut toucher les machines

La revendication technique centrale de S3NS n'est pas simplement que les données sont stockées en France. C'est que l'équipement est isolé et que les personnes qui peuvent l'exploiter sont sous le contrôle de S3NS. L'entreprise décrit des racks, serveurs et équipements réseau dédiés, des contrôles d'accès physiques, de la surveillance et de la détection d'intrusion, ainsi que des identités, racines de confiance, chiffrement et frontières réseau distincts. L'annonce de qualificationindique que seuls les employés de S3NS administrent le service et que la technologie et les mises à jour de Google entrent dans une zone de quarantaine pour analyse et validation avant le déploiement en production.

Ces contrôles répondent à plusieurs risques réels. Un administrateur distant employé par Google ne devrait pas pouvoir entrer dans l'environnement. Une mise à jour logicielle n'est pas censée passer directement du fournisseur de technologie à la production. Le contrôle cryptographique et l'identité de production sont détenus par l'opérateur français. Le service qualifié doit également répondre aux exigences SecNumCloud en matière de sécurité physique, d'administration isolée, de traitement des incidents, de continuité, de sous-traitance et de protection contre le droit extra-européen.

La séparation physique crée cependant un parc opérationnel que S3NS doit entretenir elle-même. Quelqu'un doit réceptionner les serveurs, valider les micrologiciels, câbler les racks, remplacer les disques défaillants, faire tourner les modules de sécurité matériels et coordonner le travail à l'intérieur de la salle informatique. Une réparation qui serait effectuée par la flotte mondiale d'un hyperscaler devient une responsabilité de S3NS ou une activité sous-traitée étroitement contrôlée. L'opérateur a besoin de personnel, de droits d'accès, de pièces de rechange et de contrats fournisseurs suffisants dans les trois sites.

Les documents publics n'indiquent pas le nombre de racks, les générations de serveurs, l'allocation de puissance totale, la marge de refroidissement, les stocks de pièces de rechange ou la couverture des techniciens locaux pour chaque zone. Ils n'identifient pas non plus quels travaux sont effectués par les employés de S3NS et lesquels restent avec les propriétaires des sites ou les sous-traitants spécialisés. SecNumCloud établit que les contrôles ont été évalués dans le périmètre qualifié. Cela ne fournit pas aux clients un planning de capacité ou une garantie de délai de réparation pour chaque composant.

Ce parc opérationnel caché est la substance économique du service. Les clients paient S3NS pour convertir l'équipement, les baux, l'énergie, le transit, les licences, les contrôles de sécurité et la main-d'œuvre spécialisée en services cloud mesurés. La marge entre l'infrastructure installée et la demande des clients détermine si un rack défaillant produit une évacuation de routine ou une pénurie de capacité. Le contrat de pièces détermine si un châssis réseau défaillant revient en heures ou attend une logistique internationale. Aucun de ces résultats n'est visible dans un catalogue de produits.

La souveraineté logicielle a une horloge de maintenance

PREMI3NS est conçu pour empêcher Google d'administrer l'environnement client ou de l'éteindre à distance. Cela ne supprime pas la dépendance à l'égard de l'ingénierie de Google. Les bases de données gérées, l'orchestration, le stockage et les services d'analyse restent des systèmes logiciels complexes qui nécessitent des correctifs de sécurité, des travaux de compatibilité et de facilitation matérielle. La question n'est donc pas seulement de savoir si S3NS peut maintenir le code d'aujourd'hui en fonctionnement après une rupture de fournisseur.

C'est combien de temps il peut fonctionner en toute sécurité pendant que les vulnérabilités, les certificats, les dépendances et les exigences des clients continuent d'évoluer.

Lesexigences SecNumCloud 3.2traitent explicitement de l'autonomie opérationnelle lorsqu'un fournisseur dépend d'un tiers. Le directeur de l'ANSSI a ensuite souligné publiquement que la qualification protège contre l'accès non européen direct et un arrêt spécifique au client, mais ne signifie pas qu'il n'y a pas de dépendance technologique. C'est la bonne distinction. La souveraineté sur l'exploitation n'est pas la même chose que l'indépendance indéfinie de chaque fournisseur.

Google indique que sa conception de Cloud Dédié permet au partenaire local de surveiller, bloquer et annuler les mises à jour, et qu'il peut continuer à fonctionner jusqu'à12 mois après la rupture de la connexion à Google. La même publication Google identifie PREMI3NS comme la mise en œuvre française. Il s'agit d'une affirmation de continuité significative, mais la formulation publique décrit une capacité de conception plutôt qu'une garantie de récupération spécifique au client. Un acheteur devrait établir quels services PREMI3NS sont couverts, ce que « fonctionner » signifie pendant la période, quelles mises à jour de sécurité restent disponibles, et ce qui se passe à la fin de celle-ci.

Le mécanisme de quarantaine apporte son propre compromis. Le filtrage des mises à jour réduit le risque qu'une version compromise ou inadaptée entre dans l'environnement de confiance. Cela peut également créer un décalage de fonctionnalités et une file d'attente lorsque de nombreuses modifications en amont arrivent en même temps. S3NS a besoin d'une profondeur d'ingénierie suffisante pour évaluer, tester, approuver ou rejeter les mises à jour sans laisser des vulnérabilités critiques non résolues.

Les clients ont besoin d'un préavis des différences par rapport au Google Cloud standard afin que les scripts de déploiement et les hypothèses de services gérés ne dérivent pas silencieusement.

La documentation S3NS avertit déjà que le Cloud de Confiance est un produit distinct avec un sous-ensemble de produits Google Cloud et des points de terminaison différents, y compriss3nsapis.frplutôt quegoogleapis.com. C'est une preuve de séparation réelle. C'est aussi une preuve que la migration n'est pas un simple changement de région. Les propriétaires d'applications doivent tester le code, les bibliothèques, les hypothèses d'identité, la disponibilité des services et les procédures opérationnelles par rapport à l'univers S3NS lui-même.

La connectivité commence là où le client entre dans le cloud

Un serveur souverain qui ne peut pas être atteint n'est pas un service. PREMI3NS prend en charge l'accès Internet public, le VPN Cloud et Cloud Interconnect, et ces chemins ont des frontières de défaillance et de confiance différentes. Ladocumentation sur la connectivité réseaudécrit le VPN comme du trafic chiffré sur l'Internet public et Interconnect comme une connectivité dédiée ou partenaire entre un réseau client et le cloud.

Pour un parc de production, la conception de l'accès doit correspondre à la conception des zones. Deux machines virtuelles dans des zones séparées dépendent toujours d'un seul routeur client si les deux sont accessibles par un seul tunnel. Deux circuits d'interconnexion peuvent toujours partager une entrée de bâtiment, un transporteur, un système optique ou un conduit métropolitain. Un schéma résilient nécessite une diversité à chaque point de transfert: routeurs clients, fournisseurs de transport, interconnexions, domaines de bordure S3NS, sessions BGP et une bande passante de basculement suffisante pour transporter la charge critique.

Ladocumentation Partner Interconnectde S3NS illustre ce point. Elle indique qu'une conception à 99,9 % nécessite deux connexions redondantes dans différents domaines de disponibilité de bordure, tandis que son modèle générique à 99,99 % nécessite quatre connexions réparties sur deux zones métropolitaines et deux régions. Étant donné que PREMI3NS n'a actuellement qu'une seule région, ce modèle à deux régions ne peut pas être mis en œuvre entièrement dans l'univers S3NS actuel. Les clients ne doivent pas supposer que l'achat de quatre circuits à l'intérieur de Paris crée la même isolation de défaillance.

Le VPN HA a une topologie différente. S3NS documente une configuration à 99,99 % lorsque les deux interfaces de la passerelle gérée se connectent via des tunnels correspondants au côté pair. Mais la disponibilité de la connexion de bout en bout dépend toujours des passerelles physiques du client, des fournisseurs Internet ou des interconnexions, de la politique de routage et de la charge de travail hébergée. Un chiffre de niveau de service côté cloud ne couvre pas un routeur unique dans le bureau du client.

Le débit fait également partie de la récupération. Une interconnexion dimensionnée pour une réplication de base de données normale peut être trop petite pour réensemencer le stockage après une panne. Un VPN qui transporte confortablement le trafic de gestion peut s'effondrer lorsqu'il devient le seul chemin pour les transactions client. Les exercices de récupération doivent mesurer les taux de transfert dans la topologie dégradée, et non utiliser la vitesse du port comme indicateur.

La couche de transport et de backbone reste opaque

La documentation PREMI3NS indique que son réseau premium transporte le trafic sur le réseau Cloud de Confiance et sélectionne les chemins BGP vers les réseaux de peering ou de transit. Elle permet également aux clients d'apporter des plages IPv4 et IPv6 éligibles, sous réserve de validation de propriété et d'autorisation d'origine de route. Ce sont des capacités de réseau cloud matures. Elles ne révèlent pas les fournisseurs réels ou les routes physiques derrière la bordure S3NS.

Les documents publics liés dans cet article ne nomment pas les transporteurs de transit, les bâtiments d'interconnexion, les points d'échange Internet, les fournisseurs de fibre de backbone ou les relations de serveur de route utilisées par PREMI3NS. Ils ne publient pas d'ASN de plateforme, de liste complète de préfixes de fournisseur ou de carte qu'un client pourrait utiliser pour établir la diversité des chemins. Les adresses exposées par la charge de travail d'un client peuvent également dépendre de savoir si le client utilise l'espace attribué par S3NS, apporte ses propres adresses, entre par un partenaire ou garde le service privé.

L'opacité n'est pas une preuve de fragilité. Les fournisseurs sensibles limitent souvent la divulgation de la topologie, et un réseau virtuel distribué ne peut pas être réduit à une icône de routeur. Cela signifie que l'expression « chemins multiples » nécessite des preuves sous confidentialité. Les acheteurs devraient demander si les trois zones ont des entrées de fibre physiquement séparées, si les liaisons inter-zones partagent des conduits, où aboutissent les interconnexions dédiées, et si deux produits de transporteur nommés empruntent finalement le même réseau de gros.

Ils devraient également demander comment S3NS valide la sécurité du routage. Les préfixes fournis par le client nécessitent des autorisations d'origine de route correctes, des objets de routage précis et un basculement contrôlé. L'espace du fournisseur nécessite sa propre sécurité d'origine et son propre filtrage. Une politique de route erronée peut retirer un service sain d'Internet même si chaque rack reste alimenté.

La frontière s'étend au-delà de S3NS. Une application publique repose sur le DNS, l'émission de certificats, l'enregistrement de domaine, la distribution de contenu, l'identité et les réseaux d'utilisateurs en amont. Certains de ces services peuvent se situer en dehors de PREMI3NS ou en dehors de la France. L'hébergement de la charge de travail principale dans une région qualifiée n'amène pas automatiquement l'ensemble du service dans la même juridiction ou le même domaine de défaillance.

La capacité installée n'est pas la capacité de basculement

S3NSa annoncé 30 services gérés en février 2026et liste des machines virtuelles GPU H100 parmi ses options de calcul. Cela démontre l'étendue, pas la quantité. Les documents publics n'indiquent pas combien de processeurs, GPU, périphériques de stockage ou ports réseau sont installés dans chaque zone, combien sont réservés, ou combien de marge reste après la perte d'une zone.

Cela est important car la capacité cloud est vendue deux fois dans l'imagination du client. La première vente est l'élasticité: les ressources apparaissent à la demande. La seconde est la redondance: une autre zone semble prête lorsque la première tombe en panne. Les deux promesses puisent dans le même inventaire physique. Si de nombreux clients demandent des instances de remplacement pendant un événement zonal, la capacité de réserve peut disparaître rapidement. Un quota qui permet une ressource dans des conditions normales ne garantit pas que le matériel équivalent sera disponible pendant un stress régional.

L'équipement spécialisé resserre la contrainte. Les charges de travail GPU peuvent dépendre d'un accélérateur, d'un pilote et d'une famille de machines particuliers qui ne sont pas uniformément répartis dans toutes les zones. Les bases de données à grande mémoire et le stockage à haut débit ont des limites de placement similaires. Un client peut construire une conception multi-zone nominale qui ne peut pas réellement redémarrer ailleurs avec la même forme.

La mesure correcte est la capacité utilisable après la défaillance choisie, pas la capacité installée avant. Pour les services critiques, les clients ont besoin d'une capacité réservée ou contractuellement prioritaire, d'une confirmation de placement et de preuves périodiques que la zone de secours peut accepter la charge de travail. Ils ont également besoin d'une stratégie de dégradation convenue: des instances plus petites, des analyses réduites, des travaux par lots suspendus ou un service de transaction minimum lorsque la pleine capacité ne peut pas être restaurée.

S3NS a de bonnes raisons de ne pas publier le nombre de machines. Les concurrents et les attaquants apprécieraient l'information, et les chiffres changent rapidement. Une assurance confidentielle peut tout de même donner aux acheteurs ce dont ils ont besoin: des classes de capacité, des limites d'évacuation testées, des délais de livraison pour le matériel rare et les règles de priorité utilisées pendant les conflits. Sans ces preuves, « trois zones » décrit des emplacements, pas la quantité de service disponible après la perte de l'une d'entre elles.

La main-d'œuvre de support fait partie de l'infrastructure

Le programme d'accès anticipé a révélé un détail utile sur le modèle opérationnel de S3NS. L'entreprise a déclaré que les ingénieurs en fiabilité des sites, les équipes de cybersécurité, le personnel des centres de données, le support, les responsables de comptes techniques et les ingénieurs clients y ont tous participé. C'est une preuve crédible d'une organisation conçue pour exploiter plus qu'un portail en libre-service. L'aperçu actuel de la plateforme indique également que S3NS, et non Google Cloud, est responsable de la gestion et du support de l'infrastructure.

Cette responsabilité locale est au cœur de la revendication de souveraineté. Un incident client ne devrait pas nécessiter qu'un administrateur Google entre dans l'environnement. Cela concentre également l'escalade sur S3NS. Si un défaut de base de données gérée nécessite une expertise en amont, S3NS doit reproduire le problème, contrôler les informations qui quittent l'environnement, se coordonner avec Google et renvoyer un correctif sûr. Le client dépend de la qualité de cette couche de traduction.

Les documents publics ne fournissent pas une matrice de support complète avec les définitions de gravité, les délais de réponse initiaux, les objectifs de restauration, les conditions d'escalade téléphonique et la compensation par niveau de service. L'annonce de disponibilité générale indique que des accords de niveau de service contractuels ont accompagné le lancement, mais elle ne les reproduit pas. Les acheteurs ont donc besoin du contrat, pas du langage de lancement.

L'horloge de réparation devrait être décomposée. La détection est le temps jusqu'à ce que S3NS ou le client remarque une panne. La prise en charge est le temps jusqu'à ce que quelqu'un avec autorité l'accepte. Le diagnostic identifie si le problème appartient à la configuration du client, au service géré, au réseau S3NS, à une installation ou à une mise à jour technologique. L'accès est le délai avant qu'un ingénieur puisse entrer dans le site concerné. La réparation comprend les pièces, l'approbation du changement et la validation.

La récupération n'est pas complète tant que l'application, les données et le travail en file d'attente ne sont pas à nouveau utilisables.

Un objectif de restauration mélangé cache ces transitions. Il cache également les tiers. Les services à distance des installations, les techniciens de fibre, les fournisseurs de matériel et les spécialistes Google peuvent tous être impliqués sans exploiter directement l'environnement client. Un client devrait savoir quelle partie peut arrêter l'horloge, quelle partie lui parle pendant un incident majeur, et si le canal de statut reste joignable si l'identité ou la console S3NS est altérée.

Un accord de niveau de service ne construit pas une application résiliente

S3NS a décrit la disponibilité générale comme apportant des accords de niveau de service formels et une préparation à la production. C'est une preuve commerciale nécessaire. Un SLA reste une promesse limitée autour d'une métrique de service définie. Il ne peut pas rendre une machine virtuelle zonale régionale, ajouter une deuxième région PREMI3NS ou réparer une architecture client qui fait passer chaque route par une seule passerelle.

La différence devient nette lors d'un incident composé. Supposons qu'une zone perde l'alimentation, que l'application bascule et que la base de données survivante atteigne une limite de connexion imposée par le client. Le service d'infrastructure peut satisfaire sa mesure de disponibilité tandis que l'application est indisponible. Si le client n'a pas distribué l'identité, les secrets ou la surveillance, le fournisseur peut restaurer l'infrastructure avant que l'entreprise ne puisse restaurer le service.

Les crédits de service sont également limités. Ils ajustent une facture après une panne admissible. Ils ne remboursent pas les services publics perdus, les travaux médicaux retardés, les transactions financières manquées ou la main-d'œuvre de migration d'urgence. Pour les systèmes sensibles, le langage contractuel utile couvre la communication d'incident, l'intégrité des données, l'assistance, la préservation des preuves, les priorités de récupération et le support de résiliation, pas seulement un pourcentage de disponibilité mensuel.

Les exclusions de maintenance nécessitent une attention égale. Un fournisseur exploitant une chaîne d'approvisionnement logicielle en quarantaine doit patcher et mettre à niveau. Les clients doivent savoir quel préavis s'applique, si les zones sont maintenues séquentiellement, ce qui se passe lorsqu'un changement d'urgence ne peut pas attendre, et si un rollback est techniquement possible. Ils devraient concevoir des applications pour tolérer le comportement de maintenance que le contrat permet.

Le canal de statut est une autre dépendance. La documentation S3NS renvoie les clients à un tableau de bord de santé du service Cloud de Confiance, mais un canal d'incident majeur utile doit fonctionner en dehors de la console et du plan d'identité défaillants. Les contacts nommés, les chemins de notification indépendants et une cadence pour les mises à jour sont une capacité opérationnelle: ils déterminent la rapidité avec laquelle les clients peuvent choisir entre attendre, basculer et invoquer un plan de récupération régionale.

SecNumCloud est une assurance forte, pas une assurance universelle

La qualification SecNumCloud est la preuve publique la plus solide soutenant PREMI3NS. Le cadre de l'ANSSI couvre bien plus que l'emplacement des données. Ses exigences incluent la sécurité physique, le contrôle d'accès, l'administration isolée, la journalisation, la gestion des vulnérabilités, la cryptographie, la continuité, la gestion des fournisseurs, la réversibilité et la protection contre le droit extra-européen. LaFAQ sur la qualificationde l'agence explique que les données des clients, les annuaires d'administration, les annuaires d'utilisateurs, les journaux, les autorités racines et les sauvegardes doivent respecter des contrôles territoriaux, et que l'autonomie opérationnelle continue est évaluée.

La décision indique également que S3NS satisfait la recommandation R9 de la doctrine du cloud de l'État français et offre une protection contre le droit extra-européen. C'est un résultat important pour les organismes publics et les organisations réglementées. Ladoctrine du Cloud au Centreen France oriente les charges de travail étatiques particulièrement sensibles vers des clouds commerciaux qualifiés protégés contre l'accès non autorisé par les autorités de pays tiers.

La qualification ne signifie pas que chaque utilisation de S3NS est automatiquement conforme ou résiliente. La décision de l'ANSSI conditionne l'utilisation aux recommandations du cadre. Les clients configurent toujours les identités, les réseaux, le stockage, le chiffrement, la journalisation et les applications. Ils peuvent créer une base de données à zone unique, exposer un service non sécurisé ou copier des données vers un système externe non qualifié.

Le visa ne couvre pas non plus chaque produit vendu sous le nom S3NS. Il couvre le service Cloud de Confiance nommé en tant qu'IaaS, PaaS et CaaS. CRYPT3NS a été explicitement commercialisé comme un tremplin qui ne visait pas la qualification SecNumCloud. Les applications SaaS partenaires exécutées sur PREMI3NS nécessitent leur propre analyse de périmètre. Un substrat qualifié ne qualifie pas automatiquement le logiciel et les pratiques opérationnelles au-dessus.

Enfin, le visa a des dates. Il est valable trois ans et dépend de la conformité continue. Les changements juridiques, organisationnels ou techniques importants doivent être gérés dans le cadre des obligations de qualification. Les achats doivent enregistrer le numéro de décision, le périmètre, l'expiration et toute condition ultérieure plutôt que d'utiliser « SecNumCloud » comme un badge intemporel.

Les annonces clients montrent la demande, pas la récupération testée

S3NS a nommé des clients dans les secteurs de l'assurance, de la santé, de la finance, de l'industrie et des services. Son annonce de qualification citait MGEN, Matmut, AGPM, Thales, Birdz, Qonto, BConnect et Club Med. Lecas MGENest particulièrement important car l'assureur a décrit une plateforme destinée à accueillir jusqu'à six millions de personnes. Une annonce d'avril 2026 indiquait que SAP RISE Private Cloud Edition serait déployé sur PREMI3NS pour Thales au second semestre 2026, couvrant des domaines d'activité principaux, notamment les finances, la chaîne d'approvisionnement, la fabrication et les achats.

Ces noms soutiennent la conclusion que S3NS sert ou prépare des charges de travail réelles. Ils indiquent également qui supporte les conséquences d'une défaillance: assurés, usagers des services de santé, employés, fournisseurs, équipes financières et opérations industrielles. Cette conséquence augmente la valeur d'un fort contrôle français tout en accroissant le besoin de récupération pratique.

Une annonce client n'est pas un historique d'incidents. Elle indique rarement quelles charges de travail sont déjà en production, combien de données elles contiennent, si elles couvrent les trois zones, quel temps de récupération a été démontré ou si une sortie régionale a été exercée. « Choisi par » peut décrire un contrat, un programme de migration, un test d'adoption précoce ou un parc de production. Chacun a un poids probatoire différent.

L'utilisation correcte de ces annonces est donc modeste. Elles valident la traction du marché et montrent que des organisations exigeantes ont effectué leurs propres évaluations. Elles ne transfèrent pas l'assurance non divulguée de ces organisations à un autre acheteur. Un nouveau client doit tester sa propre application, son réseau, ses données et sa chaîne de support.

S3NS est également elle-même cliente de fournisseurs. Les propriétaires de centres de données, les services publics, les transporteurs, les fabricants de serveurs, les distributeurs de composants et Google se trouvent derrière le service même lorsqu'ils ne peuvent pas l'administrer. Le modèle de confiance est plus fort lorsque chaque dépendance est restreinte, remplaçable et testée. Il est plus faible lorsque le client traite le contrat S3NS comme le nœud final de la chaîne.

La localité des données nécessite une carte de chaque copie

PREMI3NS offre une proposition claire de localisation principale: les données et les charges de travail restent en France dans un environnement S3NS dédié. Cela est plus fort que de supposer l'emplacement à partir d'une adresse de facturation ou d'un résultat de géolocalisation IP. L'architecture conserve également l'identité de production, le contrôle des clés, l'administration et le support sous l'autorité de l'opérateur français.

Les clients doivent néanmoins cartographier chaque catégorie d'information. Les données principales, les répliques, les sauvegardes, les instantanés, les journaux, les pièces jointes de support, les enregistrements de facturation, la télémétrie, les clés et les métadonnées d'identité ne partagent pas nécessairement le même cycle de vie. SecNumCloud impose des exigences territoriales au sein du service qualifié, mais un client peut envoyer des journaux vers une plateforme externe, ouvrir un cas de support contenant des données sensibles ou répliquer une base de données dans une autre juridiction.

La conception à région unique rend le placement des sauvegardes particulièrement important. Une sauvegarde copiée sur trois zones peut survivre à une défaillance de périphérique ou de site, mais elle reste à l'intérieur deu-france-east1. Une copie en dehors de la région améliore la reprise après sinistre mais peut quitter la frontière qualifiée exacte que l'organisation a choisie. Certaines charges de travail peuvent justifier un stockage à froid chiffré chez un autre fournisseur qualifié; d'autres peuvent être légalement ou opérationnellement tenues de rester dans l'environnement S3NS. La réponse dépend des données et de l'objectif de récupération.

La gestion des clés doit suivre la même carte. Une copie de récupération est inutile si ses clés sont piégées dans la région défaillante. Une clé copiée ailleurs peut créer un nouveau chemin d'accès qui compromet le contrôle d'origine. La conception de la récupération nécessite donc une disponibilité indépendante pour les clés, les identités, la configuration et les personnes autorisées à les utiliser, avec des contrôles au moins aussi délibérés que ceux autour des données.

La localité modifie également la latence et la zone de service. Les trois centres de données sont en France, les descriptions antérieures de S3NS les plaçant en région parisienne. Les utilisateurs européens peuvent bénéficier d'une bonne latence, mais une région française n'est pas automatiquement proche de chaque succursale, usine ou territoire d'outre-mer. Le réseau d'accès et la conception de l'application déterminent les performances ressenties. Une organisation multinationale doit également décider si tous les utilisateurs et données appartiennent à la juridiction française ou si PREMI3NS ne doit contenir que le sous-ensemble sensible.

La migration est le mécanisme ultime de récupération

S3NS promeut la continuité avec la technologie Google Cloud, ce qui peut réduire l'effort de migration pour les clients utilisant déjà des API et des services gérés familiers. Cela ne rend pas les plateformes identiques. L'univers dédié a des points de terminaison différents, un ensemble de services plus restreint, une seule région et des contrôles opérationnels dictés par la qualification. La migration vers PREMI3NS est un programme d'ingénierie planifié; la migration hors de celui-ci en sera un également.

Un guide de migration S3NS note que le temps de transfert dépend du volume de données et de la bande passante réseau. Cette simple déclaration devient sévère lors d'une panne. Déplacer 500 téraoctets sur un chemin fournissant un débit soutenu de 5 gigabits par seconde prend plus de neuf jours avant les frais généraux de protocole, les nouvelles tentatives, la validation et le basculement d'application. Si le service source est dégradé, le débit réel peut être beaucoup plus faible. Si la destination utilise une base de données gérée différente, la conversion peut dominer la copie.

Les règles françaises et européennes renforcent la position du client. L'article 28 de laloi française SRENexige que les services cloud prennent en charge l'interopérabilité sécurisée, la portabilité des données exportables et des actifs numériques, ainsi que les interfaces et informations nécessaires pour l'effectuer. Larecommandation d'Arcep de 2025se concentre sur la transparence du changement et les interfaces stables. Le Règlement européen sur les données impose des obligations de changement et supprime progressivement les frais de changement.

La portabilité juridique ne garantit pas l'équivalence opérationnelle. Les données exportables peuvent exclure la propriété intellectuelle du fournisseur. Une application Kubernetes peut se déplacer plus facilement qu'une charge de travail construite autour de BigQuery, du comportement de Cloud SQL, de l'identité du fournisseur et de la surveillance propriétaire. Même lorsque les enregistrements s'exportent correctement, les politiques, les files d'attente, l'historique des événements, l'état cryptographique et les tableaux de bord opérationnels peuvent ne pas l'être.

Les clients devraient donc maintenir un petit déploiement de récupération complet ailleurs. Il devrait restaurer des données réelles, recréer l'identité et la mise en réseau, et prouver que l'entreprise peut fonctionner à un niveau minimum défini. L'exercice devrait enregistrer la vitesse de transfert, les échecs de conversion, les métadonnées manquantes et les personnes requises. Un plan de sortie qui n'existe que sous forme de langage contractuel n'est pas une capacité de réserve.

Les chemins de défaillance crédibles sont ordinaires

S3NS attire l'attention en raison de questions géopolitiques et juridiques, mais les pannes les plus probables sont des événements d'infrastructure familiers. Un composant d'alimentation tombe en panne. Un périphérique de stockage produit des erreurs. Une fibre est coupée. Une route BGP est retirée. Un certificat expire. Une mise à jour de service géré modifie le comportement. Un ticket de support est mal classé. Le paiement ou l'état du compte d'un client interrompt l'accès. Une migration dure plus longtemps que sa fenêtre approuvée.

Une défaillance de rack ou de serveur devrait être contenue par la redondance locale, mais seulement si le service et le placement client la prennent en charge. Une défaillance de zone devrait être contenue par une architecture multi-zone et une capacité de survie adéquate. Une défaillance régionale n'a pas de deuxième région PREMI3NS et invoque donc la conception de récupération externe du client. Une défaillance en amont ou d'interconnexion invoque des chemins réseau diversifiés. Une interruption de l'approvisionnement logiciel invoque l'autonomie et la stratégie de mise à jour de S3NS.

Un litige contractuel ou de facturation invoque la continuité administrative et les droits d'exportation.

Chaque chemin affecte une population différente. Un service d'analyse isolé peut retarder les rapports internes. Une défaillance d'identité peut empêcher chaque application de démarrer même si le calcul reste sain. La perte d'une plateforme de santé peut affecter l'administration des soins et l'accès des patients. La perte d'un ERP industriel peut bloquer les achats, la fabrication et l'expédition. La dépendance doit être classée par fonction métier, et non par l'importance apparente du nom de la ressource cloud.

Les pannes composées méritent une attention particulière. Une panne de zone pendant la maintenance laisse moins de capacité de réserve. Un incident cyber peut désactiver l'automatisation tout en augmentant la demande de support manuel. Un problème de réseau régional peut ralentir le transfert de sauvegarde même prévu pour la récupération. Un litige avec un fournisseur peut coïncider avec une vulnérabilité de sécurité urgente. La résilience est la capacité de fonctionner à travers ces combinaisons, pas la présence de trois boîtes sur un diagramme d'architecture.

S3NS a construit un contrôle exceptionnellement fort autour d'un cloud français basé sur une technologie non française. Cette réalisation supprime certains chemins de défaillance, en particulier l'administration étrangère directe et l'arrêt à distance spécifique au client par le fournisseur de technologie. Elle ne supprime pas la physique, le vieillissement logiciel, l'erreur humaine ou la concentration des clients.

Les preuves qu'un acheteur devrait obtenir avant d'engager une charge de travail critique

La première preuve devrait décrire le placement. S3NS peut confirmer, sous confidentialité appropriée, que les services sélectionnés utilisent les trois centres de données, quels composants restent zonaux, lesquels sont régionaux et quelles dépendances du plan de contrôle traversent les zones. Le client peut alors cartographier chaque composant de calcul, de stockage, d'identité, de clé, de journalisation et de déploiement vers un domaine de défaillance.

La deuxième preuve devrait décrire la capacité de survie. Pour chaque machine critique et service géré, le client doit savoir si une capacité équivalente est réservée ou susceptible d'être disponible après la perte d'une zone. Les processeurs spécialisés, les formes de grande mémoire, les performances de stockage et les adresses publiques doivent être inclus. Un exercice réussi où les charges de travail redémarrent dans une autre zone a plus de valeur qu'un adjectif de disponibilité.

La troisième preuve devrait décrire la diversité physique et réseau sans exposer de détails sensibles publiquement. Le risque indépendant des installations et des services publics, les entrées séparées, les chemins inter-zones, la propriété des transporteurs, la terminaison d'interconnexion et la bande passante de basculement peuvent être validés dans un cadre d'assurance contrôlé. La réponse devrait identifier les dépendances partagées, et pas seulement compter les contrats.

La quatrième preuve devrait décrire la réparation et l'escalade. Le client devrait savoir qui répond à toute heure, quand le personnel de site S3NS est impliqué, quelles réparations dépendent des fournisseurs d'installation ou de matériel, quelles pièces sont détenues localement et comment un problème atteint Google sans exposer les données du client. Les communications d'incident majeur devraient avoir une voie hors bande.

La cinquième preuve devrait être un exercice de récupération régionale. Comme il n'y a qu'une seule région PREMI3NS, le client devrait restaurer un service représentatif en dehors de celle-ci, y compris les données, les clés, l'identité, la configuration et l'entrée réseau. Le résultat mesuré devrait être comparé à l'objectif de récupération de l'entreprise. Toute étape qui suppose que la console source reste disponible devrait être testée à nouveau sans cette hypothèse.

Enfin, le contrat devrait s'aligner sur le résultat technique. Le périmètre de qualification, les niveaux de service, la maintenance, l'assistance en cas d'incident, l'emplacement des données, les sous-traitants, la continuité de l'approvisionnement logiciel, la portabilité, la suppression et le support de résiliation devraient tous décrire le même service que celui testé par les ingénieurs. Un contrat ne peut pas créer de capacité, mais il peut rendre la responsabilité et les preuves disponibles avant une défaillance.

Le niveau de preuve est Moyen

S3NS a franchi le seuil du projet plausible à l'opérateur attesté. PREMI3NS est généralement disponible, a un fournisseur légal nommé, emploie une équipe française substantielle, exploite une région autonome documentée, expose un large catalogue de services gérés, a des programmes clients publics et détient une qualification SecNumCloud 3.2 actuelle pour l'IaaS, le PaaS et le CaaS. Ce sont des signaux plus forts qu'une carte marketing, un dossier d'entreprise dormant ou une étiquette cloud non vérifiée.

La rétrogradation par rapport à Fort reflète ce qui reste indisponible en public. Les trois exploitants de centres de données et les sites exacts ne sont pas nommés. La diversité des services publics, des transporteurs, du backbone et des interconnexions n'est pas décrite. Il n'y a pas de comptage public de la flotte, de limites d'évacuation de zone, de calendriers de pièces de rechange ou de conditions complètes de réponse du support client. Plus important encore, PREMI3NS a une seule région. Ses trois zones améliorent la disponibilité mais ne fournissent pas de récupération interne en cas de perte de la région.

La conclusion juste n'est donc ni « le contrôle français résout tout » ni « la technologie Google rend la souveraineté sans signification ». L'ANSSI a établi que Thales Cloud Sécurisé contrôle l'environnement qualifié et le protège contre l'accès juridique non européen dans les conditions énoncées. La plateforme dépend toujours de la technologie Google, de l'infrastructure des centres de données français, de l'électricité, de la fibre, de l'approvisionnement matériel et du personnel de S3NS. Ces dépendances peuvent être gérées parce qu'elles sont identifiables; elles ne peuvent pas être gérées en prétendant qu'elles ont disparu.

Pour un acheteur, la caractéristique la plus précieuse de S3NS pourrait être la clarté de sa frontière. Le service est une région cloud autonome française avec trois zones physiques, exploitée par une entreprise française contrôlée par Thales utilisant la technologie Google Cloud dans le cadre d'un modèle de contrôle qualifié. Construisez à travers les zones. Prouvez la capacité dans les sites survivants. Obtenez des preuves confidentielles de diversité physique et de routage. Gardez un environnement de récupération testé au-delà de la région.

Alors la promesse de souveraineté devient une capacité opérationnelle plutôt qu'un badge attaché aux racks de quelqu'un d'autre.