RÉSUMÉ EXÉCUTIF (lecture 5 minutes)
Thèse centrale
La qualification SecNumCloud 3.2 obtenue par S3NS pour son offre PREMI3NS représente une avancée réelle dans la protection juridique des données sensibles françaises. Elle ne constitue pas, pour autant, une souveraineté numérique au sens stratégique du terme. Confondre conformité à un référentiel et autonomie effective sur une infrastructure critique constitue une erreur d'analyse qui peut produire des choix de politique publique coûteux.
Ce que PREMI3NS garantit réellement
Ce que PREMI3NS ne garantit pas
Le chiffre pivot : "douze mois"
La déclaration de Cyprien Falque, en février 2026, selon laquelle PREMI3NS serait "conçue pour tenir de l'ordre de douze mois" en cas de rupture avec Google, décrit une fenêtre d'endurance partielle, non une autonomie stratégique. La distinction est décisive. Une organisation qui ne peut se transformer en douze mois dispose non d'une garantie, mais d'un délai de dégradation.
Le paradoxe du cloud de confiance
La doctrine française du "cloud de confiance" a eu une utilité réelle pour cadrer les exigences de conformité. Elle présente un risque symétrique : en donnant une forme administrativement acceptable à une dépendance structurelle, elle peut retarder la construction des alternatives qu'elle est censée préparer.
Ce que cette analyse propose
Non pas le rejet de S3NS, mais l'exigence d'une doctrine à trois niveaux pour les infrastructures critiques : sécuriser l'existant lorsque la conformité est immédiate, geler l'approfondissement des dépendances propriétaires, organiser une remontée progressive en maîtrise via la standardisation, la réversibilité et l'investissement dans les compétences nationales.
NOTE MÉTHODOLOGIQUE
Registres épistémiques
Cet article applique un système de signalement explicite distinguant trois registres :
Toute affirmation non marquée d'un de ces registres constitue une présentation factuelle directe dont les sources peuvent être reconstituées à partir de la bibliographie.
Sources et limites des données
Les données techniques sur l'architecture de S3NS/PREMI3NS sont issues des communications publiques de l'entreprise, des décisions de qualification publiées par l'ANSSI et des auditions parlementaires disponibles. Les estimations de coûts comparatifs sont des ordres de grandeur analytiques, non des données contractuelles. Les données juridiques relatives à FISA Section 702 et au Cloud Act reposent sur les textes législatifs américains publiés. Les estimations de probabilité dans les sections de scénarios sont explicitement labellisées comme estimations analytiques, non comme valeurs calculées.
Introduction
L'obtention par S3NS de la qualification SecNumCloud 3.2 pour son offre PREMI3NS a constitué un jalon important dans la politique française du cloud dit de confiance (Fait établi). Elle a démontré qu'une architecture juridiquement localisée, opérée en France et encadrée par une gouvernance nationale, pouvait satisfaire aux exigences renforcées de l'ANSSI pour protéger les données et les opérations contre certains effets du droit extraterritorial. Sur ce point, il faut être précis : cette qualification est réelle, exigeante et substantielle.
La difficulté commence lorsque cette conformité est interprétée comme l'équivalent d'une souveraineté pleinement acquise.
La déclaration de Cyprien Falque, en février 2026, selon laquelle la solution serait "conçue pour tenir de l'ordre de douze mois" en cas de rupture avec le fournisseur technologique américain, concentre cette ambiguïté. Elle ne décrit pas une autonomie stratégique de douze mois. Elle décrit, au mieux, une capacité d'endurance partielle, temporaire et dégradée d'une infrastructure dont la profondeur technologique reste fournie par un acteur extérieur. Le sujet n'est donc pas l'autonomie : c'est l'inertie.
C'est à partir de cette distinction que la présente analyse propose de relire le cas S3NS. L'enjeu n'est pas de disqualifier une solution de conformité réelle. Il est de refuser qu'une réduction de risque juridique soit confondue avec une souveraineté numérique au sens fort. Pour un État, pour une administration critique ou pour un opérateur essentiel, la question décisive n'est pas seulement de savoir si un service est sécurisé aujourd'hui : elle est de savoir si sa continuité, son auditabilité, sa réversibilité et son évolution peuvent être garanties demain sans dépendre structurellement d'une puissance étrangère.
I. Le problème n'est pas la conformité. C'est la confusion entre conformité et souveraineté
1.1 La qualification SecNumCloud 3.2 : périmètre et portée réelle
Le référentiel SecNumCloud, élaboré par l'Agence nationale de la sécurité des systèmes d'information (ANSSI), fixe les exigences techniques, organisationnelles et juridiques auxquelles doivent satisfaire les prestataires de services cloud souhaitant héberger des données sensibles de l'État ou des opérateurs d'importance vitale (Fait établi). La version 3.2, publiée en 2022, a introduit une exigence centrale : le critère 19.6, qui impose au prestataire de démontrer que la législation d'un État non membre de l'Union européenne ne peut pas lui ordonner de communiquer des données clients ou d'en faciliter l'accès à des tiers.
Ce critère a constitué l'obstacle principal pour les acteurs dépendant d'une société mère américaine. Il a conduit à la création de structures juridiques distinctes, opérées par des entités françaises ou européennes, avec une gouvernance et une chaîne de contrôle formellement séparées du partenaire technologique américain (Fait établi).
S3NS a satisfait à ce critère en construisant une architecture dans laquelle :
La qualification ainsi obtenue est rigoureuse. Le processus d'audit mené par l'ANSSI porte sur des centaines de critères techniques, organisationnels et juridiques. Elle n'est ni cosmétique ni symbolique. Elle matérialise un niveau élevé de protection contre des risques explicitement identifiés par le référentiel.
Cependant, une qualification de sécurité atteste qu'un système satisfait à un référentiel donné dans un périmètre défini. Elle ne transforme pas, par elle-même, une dépendance structurelle en autonomie stratégique (Lecture analytique). Elle ne modifie ni l'origine de la technologie, ni l'asymétrie entre les ordres juridiques, ni le fait que la profondeur industrielle de la pile demeure extérieure au périmètre national.
1.2 L'architecture de la co-entreprise : ce que Thales/Google change et ce qu'il ne change pas
La co-entreprise S3NS présente un modèle architectural que l'on retrouve, avec des variantes, dans plusieurs initiatives similaires en Europe. En Allemagne, Delos Cloud associe SAP, Microsoft et Arvato Systems (Bertelsmann) selon un schéma de séparation voisin, certifié sous le référentiel BSI C5 (Fait établi). En France, l'offre Bleu associe Orange, Capgemini et Microsoft Azure selon une logique comparable.
Ce modèle produit des effets réels sur plusieurs vecteurs de risque identifiés :
La localisation des données est garantie contractuellement et techniquement : les données ne quittent pas le territoire français. (Fait établi)
L'accès opérationnel du prestataire américain est formellement exclu par la gouvernance de la co-entreprise : les personnels Google n'ont pas accès aux environnements clients. (Fait établi selon les engagements publiés de S3NS)
Le contrôle des mises à jour est assuré par l'équipe S3NS qui valide, teste et déploie les évolutions logicielles issues de la pile Google Cloud Platform avant leur mise en production. (Fait établi)
Ce que l'architecture ne modifie pas :
La dépendance technologique profonde reste entière. La pile logicielle, les API, les services managés, les outils de développement demeurent ceux de Google Cloud. S3NS opère la technologie de Google ; elle ne produit pas sa propre pile. (Fait établi)
L'écosystème applicatif des clients reste tissé avec les services Google Cloud. Plus les organisations intègrent des services managés avancés (BigQuery, Vertex AI, Kubernetes Engine, etc.), plus leur dépendance effective à l'écosystème Google s'approfondit, même dans un cadre formellement souverain. (Lecture analytique)
La chaîne de confiance ultime remonte, techniquement, jusqu'à des composants dont la maintenance, la sécurité et l'évolution dépendent d'une entité relevant de la juridiction américaine. (Fait établi)
1.3 Le glissement conceptuel : du "cloud de confiance" à la souveraineté présumée
Depuis 2019 et les travaux préparatoires du rapport Latombe (Assemblée nationale, 2021), le débat français a produit une formule de compromis : le "cloud de confiance". Cette notion a eu une utilité doctrinale réelle. Elle a permis de dépasser une approche purement géographique de la souveraineté des données pour intégrer des questions de gouvernance, d'exploitation, d'accès opérationnel et d'exposition au droit étranger.
Le risque apparaît lorsque ce compromis, initialement utile, produit un glissement sémantique. À partir du moment où une offre hybride qualifiée répond à certaines exigences d'immunité juridique, la tentation est grande de la traiter comme l'équivalent d'une solution souveraine au sens plein. Ce glissement s'observe dans plusieurs registres du discours public : communications institutionnelles, appels d'offres de la commande publique, présentations commerciales des co-entreprises elles-mêmes. (Lecture analytique)
La souveraineté ne se définit pas seulement par la conformité à une procédure. Elle suppose une maîtrise effective des dépendances critiques. Elle implique au minimum :
Sur ces quatre plans, une offre hybride qualifiée ne se situe pas au même niveau qu'une infrastructure dont la chaîne de dépendance est structurellement plus courte, plus transparente et plus maîtrisable. La prétendre équivalente constitue une confusion de catégories.
II. Les "douze mois" : une fenêtre d'endurance, non une capacité de souveraineté
2.1 Ce que la formule signifie techniquement
La déclaration de Cyprien Falque en février 2026 mérite d'être analysée avec précision. Affirmer qu'une solution est "conçue pour tenir de l'ordre de douze mois" ne signifie pas qu'elle est indépendante pendant douze mois. La formulation elle-même comporte plusieurs niveaux d'incertitude :
"De l'ordre de" signale une approximation, non une garantie contractuelle ou technique précise.
"Tenir" renvoie à un maintien de fonctionnement, non à une capacité de développement, d'évolution ou de montée en charge. Un système peut "tenir" dans un état dégradé et figé.
La variable non précisée est décisive : de quel périmètre de service parle-t-on ? L'infrastructure de base (IaaS) dispose d'une inertie probablement plus longue que les services managés avancés (PaaS, SaaS), qui dépendent plus directement d'une alimentation logicielle continue. (Lecture analytique)
La différence fondamentale entre inertie et autonomie est la suivante :
Une autonomie stratégique suppose la capacité de poursuivre, corriger, arbitrer, maintenir et faire évoluer une infrastructure selon ses propres objectifs, à son propre rythme.
Une inertie technique ne fait que différer les effets d'une rupture. Elle offre un délai, non une solution. Ce n'est pas la même chose, et les confondre conduit à des erreurs de planification graves. (Lecture analytique)
2.2 L'écart entre estimations publiques : des couches différentes
Les estimations publiquement évoquées par d'anciens responsables de l'ANSSI autour de la durée effective de résilience d'architectures de ce type peuvent sembler divergentes selon les sources et les périodes. Elles renvoient vraisemblablement à des couches techniques distinctes. (Lecture analytique)
Les composants proches de l'infrastructure de base (hyperviseur, stockage, réseau) disposent d'une inertie potentiellement plus longue, parce qu'ils évoluent lentement et que les mises à jour critiques de sécurité peuvent être limitées dans le temps.
Les services managés à forte intégration applicative (bases de données as-a-service, pipelines de données, services d'intelligence artificielle) sont nettement plus sensibles à une rupture de l'alimentation logicielle. Leurs mises à jour sont fréquentes, leurs dépendances transitives nombreuses, et leur substitution par des équivalents non Google exige un travail considérable de refactoring. (Lecture analytique)
Pour la décision publique, l'important n'est donc pas le chiffre exact. Ce qui compte, c'est la logique qu'il révèle : plus une organisation intègre des services propriétaires profonds, plus sa fenêtre d'endurance réelle se contracte, parfois très en deçà de l'estimation haute.
2.3 La seule question utile : que peut-on faire pendant ce délai ?
Une doctrine sérieuse ne se demande pas seulement combien de temps "cela tient". Elle se demande ce qu'une organisation peut effectivement :
Autrement dit, l'unité d'analyse pertinente n'est pas la durée d'endurance, mais la capacité de manoeuvre sous contrainte.
Si douze mois ne permettent pas de basculer vers une trajectoire plus autonome, alors les douze mois ne constituent pas une garantie. Ils constituent un délai de dégradation.
Cette question est rarement posée explicitement dans les appels d'offres publics ou les politiques de qualification. Elle devrait figurer comme critère obligatoire dans toute politique d'infrastructure critique. (Lecture analytique)
III. Le point aveugle : FISA Section 702 et la chaîne de confiance non vérifiable
3.1 Le cadre légal américain : mécanismes de contrainte classifiée
La Foreign Intelligence Surveillance Act (FISA), dans sa section 702 codifiée en 50 U.S.C. § 1881a, autorise les autorités américaines à contraindre des "fournisseurs de services de communications électroniques" relevant de la juridiction américaine à coopérer à des opérations de surveillance de personnes étrangères localisées à l'étranger (Fait établi). Ces ordonnances sont délivrées par le Foreign Intelligence Surveillance Court (FISC), une juridiction spécialisée dont les décisions sont classifiées.
Le Cloud Act (Clarifying Lawful Overseas Use of Data Act, P.L. 115-141, 2018) a complété ce dispositif en permettant aux autorités américaines d'ordonner à des entreprises américaines de produire des données stockées à l'étranger, y compris lorsque cette production serait incompatible avec les lois locales (Fait établi).
Ces deux textes créent une asymétrie fondamentale dans l'architecture de confiance des offres hybrides : ils s'adressent à l'entité de droit américain, non à la co-entreprise opératrice. Or, Google LLC reste l'entité juridique américaine dont S3NS utilise la technologie. La séparation opérationnelle entre Google et S3NS, si réelle et documentée qu'elle soit sur le plan de l'accès aux données, ne modifie pas le fait que Google LLC demeure soumise à la juridiction américaine. (Fait établi)
Le mécanisme de non-divulgation est une composante structurelle de ce dispositif. Une entité contrainte par une National Security Letter (NSL) ou une ordonnance FISC est légalement interdite de révéler l'existence de cette contrainte, ses modalités ou ses effets (Fait établi). Cette interdiction est la règle, non l'exception.
3.2 Pour un État, l'impossibilité de vérification est un fait stratégique
Le débat public sur ce sujet se fige souvent dans une opposition stérile. D'un côté, certains affirment qu'un acteur américain pourrait nécessairement espionner à volonté ; de l'autre, on répond qu'en l'absence de preuve publique, le risque serait théorique.
Ces deux positions sont insuffisantes.
Le sujet n'est pas de prétendre démontrer publiquement un mécanisme classifié. Le sujet est de déterminer si l'architecture de confiance mise en avant est capable d'exclure, d'auditer ou de neutraliser certaines contraintes extérieures dans un contexte où ces contraintes, par définition, ne sont pas publiques.
Une puissance publique ne raisonne pas comme un simple acheteur de services. Elle ne se contente pas d'évaluer un risque selon sa probabilité apparente. Elle raisonne selon la combinaison de quatre paramètres :
Lorsqu'un ordre juridique étranger permet, dans certaines conditions, d'imposer à des entités relevant de sa juridiction une coopération technique dans un cadre secret, le problème n'est pas seulement ce qui pourrait être fait. Le problème est qu'il peut devenir impossible, depuis l'extérieur du dispositif, de vérifier publiquement que cela n'a pas été requis, que cela ne produit pas d'effet, ou que cela ne pourrait pas l'être demain.
Pour un système d'information de confort, cela peut relever d'un compromis acceptable. Pour une infrastructure critique, cela constitue une limite de principe qui ne disparaît pas parce qu'elle est inconfortable à énoncer.
3.3 La bonne formulation stratégique
Il n'est ni nécessaire ni rigoureux d'affirmer comme un fait démontré qu'une offre comme PREMI3NS serait effectivement compromise par une injonction secrète. En revanche, il est rigoureusement défendable de soutenir qu'une chaîne de confiance qui dépend d'un écosystème relevant d'un ordre juridique étranger doté de mécanismes secrets de contrainte ne peut être considérée comme intégralement souveraine, tant que cette dépendance n'est ni pleinement substituable ni pleinement auditable.
Le critère décisif n'est donc pas l'existence prouvée d'un abus. C'est l'absence de maîtrise pleine sur la possibilité même de l'exclure. (Lecture analytique)
Cette formulation est à la fois plus rigoureuse et plus exigeante que les affirmations catastrophistes. Elle ne repose pas sur une hypothèse de mauvaise foi. Elle repose sur une architecture objective dont les effets sont indépendants des intentions des parties.
IV. Le coût de la conformité n'est pas le coût de la souveraineté
4.1 La prime S3NS : rationalité immédiate, ambivalence stratégique
Le surcoût d'une offre comme PREMI3NS par rapport à une offre GCP standard est généralement estimé entre 30 % et 50 % selon les usages et les volumes, même si ces estimations varient selon les sources et les périmètres contractuels. (Estimation analytique, non contractuelle) Ce surcoût est rationnel dans sa logique : il rémunère une architecture séparée, une exploitation spécifique, un dispositif d'audit, un contrôle local des mises à jour et un niveau de conformité renforcé.
Pour l'acheteur public confronté à des exigences de conformité immédiate, cette prime peut être justifiée. Elle répond à un besoin réel.
Mais pour l'État considéré comme acteur stratégique, cette prime a une signification ambivalente qu'il est important de nommer.
D'un côté, elle réduit une exposition juridique et répond à une contrainte de conformité réglementaire immédiate.
De l'autre, elle peut prolonger une dépendance technologique en lui donnant une forme administrativement acceptable. En ce sens, elle sécurise le présent tout en pouvant retarder la construction d'une alternative plus autonome. (Lecture analytique)
4.2 Que construit-on réellement en payant ?
Une politique d'achat n'est jamais purement budgétaire. C'est un acte d'orientation industrielle et capacitaire.
En payant une prime sur une offre hybride qualifiée, l'État ou l'organisation cliente achète principalement :
Elle construit en revanche plus faiblement :
À l'inverse, une trajectoire plus ouverte fondée sur des technologies standardisées et des logiciels libres, même plus coûteuse au démarrage, peut produire des actifs durables : savoir-faire, outils, standards, ingénierie interne, partenaires locaux, meilleure maîtrise de l'architecture et réduction progressive des coûts de sortie. (Lecture analytique)
4.3 Le coût caché : l'approfondissement des dépendances propriétaires
Le coût stratégique d'une offre hybride n'est pas uniquement son prix affiché. C'est aussi l'effet cumulatif qu'elle peut avoir sur les choix d'architecture.
Chaque service propriétaire supplémentaire intégré dans un périmètre S3NS, chaque workflow métier dépendant d'une API Google Cloud spécifique, chaque compétence interne concentrée sur des outils dont la transférabilité est faible, augmente le coût politique et technique d'une future bifurcation.
Ce phénomène, bien documenté dans la littérature économique sur les coûts de transition (switching costs), s'applique particulièrement aux architectures cloud. Plus une organisation creuse l'intégration avec un écosystème propriétaire, moins elle est capable d'en sortir rapidement et à coût raisonnable. La qualification SecNumCloud 3.2, en validant cette intégration au regard des exigences du référentiel, peut produire un effet de légitimation de l'approfondissement. (Lecture analytique)
Le risque n'est donc pas seulement de payer plus cher. C'est de payer pour rendre plus difficile, demain, ce que l'on prétend préserver aujourd'hui : la liberté de décision stratégique.
V. Le tournant 2024-2026 : l'IA remodèle le calcul des dépendances
5.1 Éviter les deux excès
Il serait naïf d'affirmer que les assistants de développement fondés sur l'intelligence artificielle rendent triviales les migrations vers des architectures ouvertes. Une migration sérieuse reste une opération lourde : audit de l'existant, refonte architecturale, tests d'intégration, sécurisation, supervision opérationnelle, performance, gouvernance des données, formation des équipes. Aucun outil d'assistance ne remplace une doctrine d'architecture ni une organisation capable de tenir la production à long terme.
Mais il serait tout aussi erroné de raisonner comme si les coûts de transformation de 2021 ou 2022 étaient restés inchangés en 2026.
5.2 Ce qui change concrètement dans les coûts de migration
Les outils d'assistance au code, à la documentation, au refactoring, à l'automatisation des tests et au débogage ont abaissé de façon mesurable certaines barrières historiques des projets de migration :
Ces outils ne remplacent pas l'ingénierie. Ils en augmentent le rendement, et ce rendement additionnel est aujourd'hui significatif. (Lecture analytique fondée sur les évolutions documentées du marché des outils de développement)
5.3 Conséquence doctrinale
Pour un État ou une organisation publique, cette évolution doit produire un effet doctrinal immédiat.
Plus les outils de transformation deviennent puissants, plus il devient rationnel de réexaminer les trajectoires de dépendance longue. Ce qui était hier un projet réservé à des organisations très dotées en ingénierie spécialisée peut devenir aujourd'hui un programme progressif crédible pour des acteurs plus modestes, à condition d'être correctement architecturé et piloté.
La conséquence n'est pas que S3NS devient inutile. La conséquence est que la valeur relative d'une dépendance juridiquement aménagée doit désormais être comparée à un horizon de remontée en maîtrise devenu plus accessible. Ce réexamen est légitime ; l'omettre serait une faute de doctrine. (Lecture analytique)
VI. Ce qu'un État doit exiger d'une infrastructure critique
6.1 Sortir de la logique du simple achat
Un État ne peut pas traiter ses infrastructures numériques critiques comme de simples services externalisés évalués au seul prisme du coût immédiat, du niveau de service apparent ou de la conformité du moment. Il doit leur appliquer des critères de souveraineté opérationnelle qui vont au-delà des référentiels de qualification existants.
Ces critères devraient être au minimum les suivants :
Capacité d'exploitation autonome. L'organisation cliente doit pouvoir opérer l'essentiel de ses services critiques sans dépendre d'un accès continu au prestataire technologique étranger.
Capacité d'audit crédible. Les composants décisifs de la chaîne technique doivent pouvoir être audités par des entités nationales habilitées, sans dépendre de la coopération volontaire du fournisseur étranger.
Capacité de continuité prolongée. L'infrastructure doit pouvoir fonctionner en mode dégradé mais acceptable pendant une durée suffisante pour permettre une décision stratégique, non seulement pour absorber un incident.
Capacité de substitution ou de bifurcation. Des alternatives doivent exister et être techniquement accessibles dans des délais compatibles avec les régimes de crise identifiés.
Maîtrise du rythme d'évolution. L'organisation ne doit pas subir un calendrier d'évolution imposé par un acteur étranger dont les priorités peuvent diverger des siennes.
Capitalisation nationale des compétences. Les savoir-faire d'exploitation, d'architecture et de sécurisation doivent être portés par des équipes nationales dont les compétences ne dépendent pas de la continuité d'un partenariat commercial.
6.2 Raisonner selon les quatre temps de la conflictualité
La doctrine publique française raisonne encore trop souvent en temps normal. Or une infrastructure critique doit être évaluée selon quatre régimes distincts, dont les exigences divergent considérablement :
Temps normal : les exigences de conformité, de performance et de coût prédominent. S3NS répond bien à ces critères.
Temps de tension : des pressions diplomatiques, des contentieux commerciaux ou des changements législatifs aux États-Unis pourraient modifier les conditions d'accès à la technologie ou les obligations de l'entité mère américaine. La robustesse juridique de la co-entreprise commence à être testée.
Temps de crise : une décision politique américaine, une sanction extraterritoriale touchant un client ou une rupture contractuelle forcerait un fonctionnement en mode dégradé. La fenêtre d'endurance de douze mois (telle que déclarée pour les couches hautes) s'avérerait insuffisante pour une transformation complète.
Temps de rupture : un conflit ouvert impliquant des restrictions technologiques généralisées, un régime de sanctions ciblant des organisations françaises, ou une décision de contrôle des exportations américaine rendrait la dépendance à l'écosystème Google intenable. C'est précisément pour ce régime que l'investissement dans la réversibilité prend tout son sens. (Lecture analytique)
6.3 La doctrine à trois étages
Le choix le plus rationnel pour l'État n'est pas nécessairement le rejet immédiat de toutes les offres hybrides qualifiées. Ce serait parfois techniquement irréaliste, économiquement coûteux à court terme et opérationnellement imprudent.
En revanche, une doctrine stratégique défendable doit comporter trois niveaux articulés :
Premier niveau : sécuriser l'existant lorsque le besoin de conformité est immédiat. Pour les organisations soumises à des exigences RGPD, SecNumCloud ou sectorielles urgentes, le recours à une offre hybride qualifiée est légitime.
Deuxième niveau : geler l'approfondissement des dépendances propriétaires sur les périmètres critiques. Tout nouveau service, toute nouvelle intégration, tout nouvel usage de service managé avancé sur un périmètre souverain doit faire l'objet d'une évaluation de substituabilité. S'il n'existe pas d'alternative crédible, ce service ne doit pas être déployé sur le périmètre critique.
Troisième niveau : organiser une remontée progressive en maîtrise. Par la standardisation des interfaces (priorité aux API ouvertes), par l'exigence de réversibilité dans les contrats, par l'investissement dans les compétences d'exploitation nationales, et par le soutien actif aux alternatives souveraines crédibles (Outscale / Dassault, Scaleway, OVHcloud, etc.). (Lecture analytique)
Une offre comme PREMI3NS peut s'inscrire dans un tel schéma, mais seulement comme instrument transitoire et encadré. Elle ne peut être le substitut d'une doctrine nationale.
VII. Arguments contraires : ce que les défenseurs de S3NS ont raison de souligner
La rigueur analytique impose de traiter les objections à la thèse de cet article avec le même soin que les arguments qui la soutiennent. Plusieurs objections sérieuses méritent d'être présentées dans leur formulation la plus forte.
7.1 "Il n'existe pas d'alternative opérationnellement équivalente à court terme"
C'est un argument solide. Les alternatives purement françaises ou européennes au niveau de maturité opérationnelle, de profondeur des services managés et de couverture fonctionnelle offertes par un hyperscaler américain ne sont pas, en 2026, équivalentes pour tous les cas d'usage. Construire une alternative credible prend une décennie au minimum. En attendant, les administrations et les opérateurs critiques ont des obligations de service immédiate qu'ils ne peuvent suspendre. (Fait établi)
La réponse à cet argument n'est pas son invalidation, mais sa limitation. L'absence d'alternative équivalente aujourd'hui justifie le recours transitoire à une offre hybride qualifiée ; elle ne justifie pas l'abandon de la trajectoire vers cette alternative. La gestion du risque à court terme et la construction de la souveraineté à moyen terme ne sont pas des stratégies mutuellement exclusives si elles sont explicitement articulées.
7.2 "Le risque FISA 702 est théorique et n'a jamais été documenté pour des données sensibles françaises"
C'est un argument partiellement exact. Aucune compromission documentée publiquement de données sensibles françaises via un mécanisme FISA 702 ciblant une co-entreprise qualifiée SecNumCloud n'a été établie à la date de rédaction de cet article. (Fait établi)
Mais cet argument confond absence de preuve et preuve d'absence. Il passe sous silence le fait que le mécanisme FISA impose précisément l'impossibilité de la preuve (interdiction de divulgation). Il applique un standard de gestion du risque approprié pour une entreprise commerciale, non pour une infrastructure de souveraineté où la combinaison gravité potentielle et impossibilité de vérification constitue en elle-même un critère d'exclusion pour certains périmètres. (Lecture analytique)
7.3 "La comparaison avec un cloud souverain intégral est une comparaison avec un idéal inexistant"
C'est un argument partiellement valide. Aucun État membre de l'UE ne dispose aujourd'hui d'une infrastructure cloud souveraine opérationnelle, à haute disponibilité, couvrant l'ensemble des services nécessaires à ses administrations critiques. La comparaison avec une "référence théorique" peut sembler spécieuse. (Fait établi)
La réponse est que l'analyse ne propose pas de substituer aujourd'hui S3NS par une référence inexistante. Elle propose d'évaluer l'adéquation de S3NS au regard des critères qu'un État souverain devrait s'imposer, pour identifier les lacunes à combler et orienter les investissements. La référence idéale est un outil analytique, non un programme opérationnel immédiat.
7.4 "La doctrine à trois étages que vous proposez est déjà en cours de mise en oeuvre"
C'est un argument qui mérite d'être pris au sérieux. Des éléments de doctrine existent : la circulaire Cloud au centre (2021), le travail de l'ANSSI sur les référentiels, la politique d'achat public. L'administration française n'est pas inerte.
La réserve est la suivante : les éléments de doctrine existants restent insuffisamment articulés sur le second niveau (gel de l'approfondissement des dépendances propriétaires sur les périmètres critiques) et sur le troisième niveau (remontée en maîtrise via la standardisation et la réversibilité obligatoire). Les contrats publics actuellement en vigueur avec des offres hybrides ne comportent généralement pas d'exigences de réversibilité contractuellement opposables ni d'audits de substituabilité périodiques. (Lecture analytique fondée sur les marchés publics disponibles)
VIII. Limites de l'analyse
8.1 Opacité nécessaire sur les détails contractuels
L'analyse repose sur les informations publiquement disponibles. Les contrats entre S3NS et ses clients publics, les résultats détaillés des audits de qualification, les engagements contractuels précis de réversibilité et les architectures techniques effectives ne sont pas publics. Des dispositions contractuelles non rendues publiques pourraient atténuer certains des risques identifiés. (Incertitude structurelle)
8.2 Évolution du cadre légal américain
Le droit américain évolue. Des réformes législatives de FISA Section 702, des décisions de la Cour suprême ou des accords bilatéraux pourraient modifier les conditions de la contrainte extraterritoriale. L'analyse repose sur l'état du droit à la date de rédaction. (Incertitude temporelle)
8.3 Hypothèse sur la transmissibilité de la contrainte
L'analyse suppose que la contrainte FISA 702 exercée sur Google LLC pourrait, dans certaines conditions, produire des effets sur la co-entreprise S3NS. Cette hypothèse repose sur une lecture des mécanismes de contrôle de Google sur sa filiale technologique. La solidité de la séparation juridique et technique entre Google et S3NS pourrait, dans des conditions précises, rendre cette transmission inopérante. L'opacité du mécanisme FISA rend cette question irrésoluble publiquement. (Inférence raisonnable soumise à débat)
8.4 Généralisation limitée
Le cas S3NS/PREMI3NS ne peut être transposé mécaniquement à d'autres co-entreprises (Bleu/Microsoft, Delos/Germany) dont les architectures, les structures capitalistiques et les engagements contractuels diffèrent sur des points potentiellement significatifs.
Conclusion : sécuriser une dépendance ou réduire une dépendance
Le cas S3NS ne pose pas seulement la question d'une coentreprise, d'un label ou d'un fournisseur. Il révèle un dilemme plus profond de la politique numérique française : voulons-nous sécuriser notre dépendance, ou voulons-nous réduire cette dépendance ?
La première stratégie est administrativement plus simple, parfois opérationnellement nécessaire, et politiquement rassurante à court terme. La seconde est plus difficile, plus exigeante, plus lente, mais seule compatible avec une logique de puissance durable.
Il ne faut pas demander à S3NS ce qu'elle ne peut pas donner. Une offre hybride qualifiée peut réduire une partie du risque juridique et offrir un cadre de confiance supérieur à celui du cloud public standard. Mais elle ne peut suffire, à elle seule, à fonder une souveraineté pleine, dès lors que la profondeur technologique, la substituabilité réelle et la vérifiabilité ultime de la chaîne demeurent conditionnées par l'écosystème d'une puissance étrangère.
La question décisive n'est donc pas "S3NS est-elle utile ?" Elle est : l'usage de S3NS rapproche-t-il l'État d'une autonomie effective, ou organise-t-il une dépendance mieux habillée ?
Une puissance publique sérieuse ne peut se satisfaire durablement d'une souveraineté sous condition. Elle doit utiliser les dispositifs de conformité lorsqu'ils sont nécessaires, sans jamais perdre de vue l'objectif stratégique : disposer, à terme, d'infrastructures critiques dont la continuité, la maîtrise, l'auditabilité et l'évolution ne dépendent pas de la permission implicite d'un autre État.
Glossaire
ANSSI (Agence nationale de la sécurité des systèmes d'information) : autorité nationale française en matière de cybersécurité, chargée notamment de l'élaboration et de la gestion du référentiel SecNumCloud.
Cloud Act (Clarifying Lawful Overseas Use of Data Act, P.L. 115-141, 2018) : loi fédérale américaine permettant aux autorités judiciaires américaines d'ordonner à des entreprises relevant de leur juridiction de produire des données stockées à l'étranger.
Cloud de confiance : notion docrinale française désignant une architecture cloud délivrant des services fondés sur une technologie d'un tiers non européen mais opérée par une entité française ou européenne séparée, dans le cadre d'une qualification SecNumCloud.
FISA Section 702 (50 U.S.C. § 1881a) : disposition de la Foreign Intelligence Surveillance Act autorisant la collecte de renseignements sur des personnes étrangères localisées hors des États-Unis en contraignant les "fournisseurs de services de communications électroniques" américains à coopérer avec les agences de renseignement.
FISC (Foreign Intelligence Surveillance Court) : juridiction fédérale américaine spécialisée, dont les délibérations et ordonnances sont classifiées, chargée d'autoriser les opérations de surveillance dans le cadre de FISA.
IaaS (Infrastructure as a Service) : modèle de cloud computing fournissant des ressources informatiques virtualisées (calcul, stockage, réseau) à la demande.
Inertie technique : capacité d'un système à continuer de fonctionner pendant une période limitée sans apport de mises à jour, de patches ou de services extérieurs. Distincte de l'autonomie, qui implique la capacité d'évoluer, non seulement de persister.
OIV (Opérateur d'importance vitale) : entité dont l'activité est essentielle à la vie de la nation et dont les infrastructures sont désignées comme critiques par l'État français au titre de la directive nationale de sécurité.
PaaS (Platform as a Service) : modèle de cloud computing fournissant des environnements de développement et d'exécution d'applications.
PREMI3NS : offre IaaS de S3NS ayant obtenu la qualification SecNumCloud 3.2 de l'ANSSI.
SecNumCloud : référentiel de l'ANSSI fixant les exigences techniques, organisationnelles et juridiques applicables aux prestataires de services cloud hébergeant des données sensibles de l'État ou des OIV. Le critère 19.6 de la version 3.2 impose notamment que la législation d'un État non membre de l'UE ne puisse ordonner la communication de données clients.
Switching cost (coût de transition) : ensemble des coûts économiques, techniques et organisationnels liés au changement de fournisseur ou de plateforme. Plus il est élevé, plus la dépendance au fournisseur en place est forte.
S3NS : co-entreprise franco-américaine associant Thales (60 %) et Google Cloud (40 %), créée en 2021, opératrice de PREMI3NS.
Bibliographie sélective
Textes législatifs et réglementaires
ANSSI, Référentiel SecNumCloud, version 3.2, 2022. [https://www.ssi.gouv.fr/entreprise/qualifications/prestataires-de-services-de-confiance-qualifies/prestataires-de-service-dinformatique-en-nuage-secnumcloud/]
Foreign Intelligence Surveillance Act, Section 702, codifiée en 50 U.S.C. § 1881a.
Cloud Act (Clarifying Lawful Overseas Use of Data Act), P.L. 115-141, 23 mars 2018.
Cour de justice de l'Union européenne, arrêt C-311/18, Data Protection Commissioner c. Facebook Ireland et Maximillian Schrems, 16 juillet 2020 (Schrems II).
Rapports institutionnels
Latombe (Philippe), Rapport d'information n° 4299 sur la politique de la France à l'égard de ses entreprises stratégiques face au risque de prédation d'intérêts étrangers, Assemblée nationale, janvier 2021.
Draghi (Mario), The Future of European Competitiveness, rapport à la Commission européenne, septembre 2024. [https://commission.europa.eu/topics/strengthening-european-competitiveness/eu-competitiveness-looking-ahead_en]
Cour des comptes, rapport S2025-1479, La politique de l'État en matière de cloud computing, 2025.
Sources institutionnelles complémentaires
ENISA (Agence de l'Union européenne pour la cybersécurité), Cloud Cybersecurity Market Analysis, 2023. [https://www.enisa.europa.eu]
CNIL, Guide pratique : les données dans le cloud, mise à jour 2023. [https://www.cnil.fr]
Direction interministérielle du numérique (DINUM), Doctrine cloud au centre, circulaire 6282/SG du 5 juillet 2021.
Références analytiques
Pierucci (Frédéric), Le piège américain, JC Lattès, 2019.
Assemblée nationale, Rapport de la commission d'enquête sur les décisions de l'État en matière de politique industrielle, 2018 (rapporteur : Guillaume Kasbarian).
Brendel (Sarah), "Cloud souverain et qualification SecNumCloud 3.2 : premières analyses de la portée du critère 19.6", Revue Lamy Droit de l'immatériel, n° 208, 2023.