S3NS : souveraineté des données, dépendance computationnelle

Analyse de la chaîne IA de Thales-Google à l'aune de SecNumCloud

RÉSUMÉ EXÉCUTIF (lecture 5 minutes)

Thèse centrale

S3NS, entité de droit français créée par Thales en partenariat avec Google Cloud et qualifiée SecNumCloud 3.2 fin décembre 2025, représente une avancée réelle et documentée sur deux dimensions : la protection des données hébergées contre les accès extra-européens non autorisés, et le contrôle opérationnel de l'infrastructure par des équipes françaises. Ces acquis sont sérieux et ne doivent pas être minimisés.

Mais la stratégie commerciale de S3NS, qui fait de l'intelligence artificielle sa priorité déclarée pour 2026-2027, soulève un problème analytique distinct et non résolu : les modèles qu'elle entend déployer ont été produits par une chaîne technologique majoritairement conçue et opérée par Google. La qualification SecNumCloud porte sur la protection de la donnée et le contrôle de l'exploitation ; elle ne porte pas sur l'indépendance de la chaîne de production des modèles IA, ni sur la maîtrise de leur évolution. Cette distinction est analytiquement décisive pour tout client institutionnel évaluant sa posture de souveraineté réelle.

Trois niveaux de souveraineté à distinguer

Souveraineté des données : les données hébergées dans PREMI3NS sont physiquement isolées dans des datacenters franciliens, exploités par des équipes sous contrôle Thales, et protégées selon les analyses juridiques commandées par l'ANSSI contre les effets du Cloud Act et de certaines formes de droit extraterritorial américain. C'est le périmètre de la qualification SecNumCloud. Il est réel.

Souveraineté opérationnelle : les équipes d'exploitation sont françaises, les accès sont contrôlés par Thales, les mises à jour logicielles passent par une zone de quarantaine inspectée avant déploiement. C'est également réel dans le périmètre certifié.

Souveraineté computationnelle : la chaîne qui produit les modèles IA déployés, qui en décide l'architecture, les données d'entraînement, les paramètres d'alignement et le rythme d'évolution, n'est pas sous contrôle de S3NS. Sur cette dimension, les sources publiques disponibles à la date de rédaction montrent une dépendance structurelle à Google, dont la profondeur varie selon les modèles concernés.

Faits établis par sources primaires publiques

Hypothèses plausibles non établies par source primaire

Conclusion analytique

La question posée par S3NS n'est pas "vos données sont-elles en sécurité ?" (la réponse est, dans le périmètre qualifié, probablement oui). La question pertinente, sur laquelle la qualification reste silencieuse, est : "qui contrôle, sur les dimensions structurantes, l'intelligence artificielle déployée dans vos processus critiques ?" Dans l'état des sources publiques disponibles, la réponse pointe, pour l'essentiel, vers Google.

Résumé analytique

Depuis l'obtention de la qualification SecNumCloud 3.2 fin décembre 2025, S3NS est présentée par Thales comme la réponse française au dilemme entre performance des hyperscalers et souveraineté numérique. Le PDG de Thales, Patrice Caine, a décrit au S3NS Summit de février 2026 l'ambition de faire du cloud de confiance "le moteur de croissance des entreprises et institutions". La coentreprise revendique environ 60 à 70 clients début 2026, avec EDF et Birdz (filiale de Veolia) cités publiquement parmi ses références ; d'autres clients sectoriels, notamment dans la finance et l'assurance, sont mentionnés dans les communications officielles sans détail nominatif exhaustif.

Le présent article ne conteste pas la réalité de la qualification obtenue ni l'utilité du dispositif pour les organisations souhaitant traiter des données sensibles dans un environnement cloud performant. Il soutient en revanche que le discours commercial de S3NS sur la souveraineté IA dépasse, sur plusieurs dimensions, ce que les sources publiques disponibles permettent d'établir, et que cette asymétrie entre promesse et réalité documentée mérite d'être posée explicitement pour tout décideur institutionnel.

Partie I : Ce que S3NS est et ce qu'elle certifie

1.1 Structure juridique et capitalistique

S3NS est une société de droit français créée en 2022, présentée dans les communications récentes de S3NS et Thales comme entièrement contrôlée par Thales, en partenariat avec Google Cloud. Les formulations publiques antérieures à la qualification SecNumCloud évoquaient une structure majoritairement détenue par Thales, ce qui reflète vraisemblablement une évolution du montage dans le cadre des exigences réglementaires. Cette distinction de formulation n'est pas anodine : le référentiel SecNumCloud exige qu'aucune entité soumise à une législation extraeuropéenne ne puisse influencer la gouvernance ou l'accès aux données du prestataire qualifié. C'est précisément sur ce fondement que l'ANSSI a délivré la qualification.

Vincent Strubel, directeur général de l'ANSSI, a déclaré devant une commission sénatoriale que les montages capitalistiques de S3NS et Bleu sont "conformes, sur le papier, aux exigences du SecNumCloud", ajoutant que les analyses juridiques commandées concluent à une immunité "en principe" vis-à-vis du Cloud Act et du FISA Act. La nuance "en principe" mérite attention : elle indique que cette immunité repose sur des constructions juridiques n'ayant pas encore été testées devant une juridiction américaine ou dans un contexte de demande gouvernementale réelle.

1.2 Le périmètre exact de la qualification

La qualification SecNumCloud 3.2 délivrée à S3NS en décembre 2025 couvre simultanément l'IaaS (Infrastructure as a Service), le PaaS (Platform as a Service) et le CaaS (Containers as a Service). C'est une première dans l'histoire du référentiel. Elle atteste que, dans ce périmètre :

les données hébergées sont protégées contre les accès non autorisés, notamment de la part d'acteurs soumis à des législations extra-européennes ; le prestataire est juridiquement et opérationnellement contrôlé par une entité européenne ; les mises à jour de code provenant du partenaire technologique (Google Cloud) sont inspectées dans une zone de quarantaine avant déploiement ; le personnel d'exploitation est exclusivement français et sous supervision Thales.

Ce que la qualification ne couvre pas explicitement : la provenance et le cycle de vie des modèles d'IA déployés sur l'infrastructure, la maîtrise de l'architecture des logiciels dont le code source n'est pas entièrement auditable par S3NS, et les risques liés aux formes d'assistance technique confidentielle que le droit américain du renseignement pourrait théoriquement imposer à des entités soumises à sa juridiction. Ce dernier point est développé dans la partie VI.

1.3 Catalogue et trajectoire IA

Au moment de l'obtention de la qualification, l'offre PREMI3NS comptait une trentaine de services qualifiés SecNumCloud. La feuille de route annoncée au S3NS Summit de février 2026 prévoit une vingtaine de services supplémentaires répartis sur l'année, dont Vertex AI Model Garden, annoncé sur PREMI3NS avec un déploiement progressif brique par brique. L'objectif affiché est de couvrir 80% des usages d'ici fin 2026, puis 80 à 90% à mi-2027.

Le directeur produit et marketing de S3NS, Blaise Vignon, a formulé la priorité stratégique sans ambiguïté au S3NS Summit de 2026 : "la cible de l'entreprise est claire : lancer des services d'IA au plus vite." C'est sur ce terrain précis que la tension analytique est la plus forte.

1.4 Les limites déclarées par S3NS elle-même

Le CEO de S3NS, Cyprien Falque, a déclaré qu'il est "impossible de construire une solution où chaque bit et chaque transistor est fabriqué en France" et que "le tout souverain n'existe pas". Cette reconnaissance d'une souveraineté nécessairement partielle est intellectuellement honnête. Elle n'épuise cependant pas la question analytique posée ici, qui n'est pas "peut-on atteindre une souveraineté absolue ?" mais "pour quelles dimensions de la chaîne IA les garanties de S3NS sont-elles substantielles, et pour quelles dimensions sont-elles absentes ou non documentées ?"

Partie II : L'architecture technique des TPU Google et ses implications

2.1 Le TPU : un ASIC conçu en symbiose avec son écosystème logiciel

Un TPU (Tensor Processing Unit) est un circuit intégré à application spécifique (ASIC) conçu par Google pour accélérer les charges de travail d'apprentissage automatique. La première génération a été déployée en interne dès 2015 et présentée publiquement en 2017. En mars 2026, Google en est à la septième génération (Ironwood), disponible dans ses régions cloud.

Ce qui distingue fondamentalement le TPU d'un GPU généraliste, c'est sa co-conception logicielle-matérielle. Le TPU n'est pas un accélérateur générique : il a été architecturé en symbiose avec le compilateur XLA (Accelerated Linear Algebra) et le framework JAX. Les unités de multiplication matricielle (MXU), qui constituent le coeur de calcul du TPU, sont dimensionnées en tableaux systoliques de 128 x 128 accumulateurs sur les générations jusqu'à v5, et 256 x 256 sur les générations récentes. Cette architecture impose des contraintes sur les dimensions des modèles entraînés nativement sur TPU : pour exploiter pleinement les MXU, les dimensions de matrices doivent être des multiples de 128. Les modèles conçus et entraînés dans cet environnement intègrent ces contraintes architecturales dès leur conception.

2.2 XLA et JAX : co-conception optimisée pour TPU, portabilité partielle et dépendance d'origine forte

Le compilateur XLA est un maillon central de l'écosystème propriétaire Google. Tout code destiné à une exécution native sur TPU doit être compilé par XLA : c'est une exigence architecturale documentée. XLA prend un graphe de calcul issu d'un framework d'apprentissage automatique (JAX, TensorFlow, PyTorch via le bridge PyTorch/XLA) et le compile en code machine TPU, en passant par deux représentations intermédiaires : HLO (High Level Optimizer) pour les optimisations génériques, puis LLO (Low Level Optimizer) pour les optimisations spécifiques au matériel, et enfin des paquets VLIW (Very Long Instruction Word) directement adressés au TPU.

Il convient d'être précis sur la portée de cette contrainte. XLA peut également compiler du code pour des cibles GPU ou CPU via ses backends alternatifs ; PyTorch supporte aussi XLA via un bridge. En ce sens, JAX et XLA ne sont pas strictement incompatibles avec des architectures non-TPU. Ce qui est en revanche documenté, c'est que les optimisations les plus profondes de XLA -- notamment la fusion d'opérateurs pour minimiser les accès mémoire et la génération de paquets VLIW -- sont calibrées pour exploiter les caractéristiques spécifiques des TPU. Un modèle conçu et entraîné nativement dans cet écosystème incorpore une dépendance d'origine forte vis-à-vis de l'architecture TPU, même si son déploiement ultérieur sur GPU reste techniquement possible via les backends alternatifs, avec une efficacité potentiellement moindre sur certaines opérations.

JAX, le framework de Google pour le calcul numérique haute performance, est conçu pour une compilation en avance de phase : les fonctions sont tracées une fois pour produire un graphe de calcul statique, puis compilées en binaire TPU. Cette approche favorise les performances sur TPU mais impose des contraintes sur la dynamicité des modèles. Les modèles conçus nativement en JAX intègrent des hypothèses implicites sur les caractéristiques des TPU.

2.3 Gemma 3 : une dépendance à l'écosystème Google documentée par source primaire

Pour Gemma 3, la dépendance à l'écosystème propriétaire Google est établie par une source primaire directe. Le Google Developers Blog de mars 2025, qui constitue la communication officielle de lancement du modèle, précise explicitement que Gemma 3 "a été entraîné sur les TPU de Google en utilisant le framework JAX" et que l'infrastructure ML Pathways a été mobilisée. Les volumes d'entraînement sont indiqués : 2 000 milliards de tokens pour le modèle 1 milliard de paramètres, 4 000 milliards pour le modèle 4 milliards de paramètres, et jusqu'à 14 000 milliards pour le modèle 27 milliards de paramètres. Ces volumes impliquent des pods TPU d'une ampleur considérable.

Pour les modèles Gemini accessibles via Vertex AI, la situation est différente en termes de sources disponibles. Selon des analyses techniques secondaires (notamment une étude d'IntuitionLabs de décembre 2025), les générations récentes de Gemini auraient été entraînées principalement sur des pods TPU v5e et v6e. Cette information est plausible au regard de la stratégie publiquement déclarée de Google de réduire sa dépendance à Nvidia pour ses propres charges de travail, mais elle n'est pas confirmée par une communication primaire officielle de Google accessible publiquement à la date de rédaction. Elle doit être traitée comme une hypothèse plausible, non comme un fait établi.

Ce qui est établi dans tous les cas : les modèles accessibles via Vertex AI sur PREMI3NS ont été produits par des équipes Google, sur une infrastructure Google, avec des outils Google, selon des décisions de Google sur l'architecture, les données d'entraînement et les paramètres d'alignement.

Partie III : La limite de la souveraineté computationnelle

3.1 Ce que S3NS contrôle effectivement et ce qui lui échappe

S3NS dispose dans ses datacenters d'Ile-de-France d'équipements GPU Nvidia H100. Ces puces peuvent exécuter des modèles d'IA, y compris Gemma. L'inférence se déroule donc physiquement dans un environnement dont l'exploitation est contrôlée par des équipes françaises relevant de Thales. Sur ce plan, la qualification SecNumCloud est justifiée.

Mais le modèle qui s'exécute sur le H100 a été produit par une chaîne que S3NS ne contrôle pas, ne peut pas reproduire dans son périmètre, et pour laquelle elle n'est pas en mesure de substituer un acteur alternatif à court terme. La question analytiquement pertinente n'est donc pas "l'inférence se déroule-t-elle en France ?" mais "qui décide, sur les dimensions structurantes, de ce que le modèle sait, comment il raisonne, et quand il évolue ?"

Dans l'état des sources publiques disponibles, la réponse à cette question pointe, pour l'essentiel, vers Google. Cette formulation appelle une nuance : pour les modèles open-weight comme Gemma, une fois les poids publiés, Google ne contrôle plus l'intégralité des usages ni de l'évolution communautaire du modèle. Mais pour les dimensions institutionnellement pertinentes pour un OIV ou une administration, soit l'architecture de référence, les données d'entraînement, les décisions d'alignement (RLHF, RLMF) et le rythme de publication des nouvelles versions, Google reste le décideur principal.

3.2 Facteurs de risque technique lors du déploiement sur GPU d'un modèle conçu pour TPU

La question de la performance d'un modèle entraîné sur TPU lorsqu'il est déployé sur un GPU H100 est analytiquement légitime mais ne dispose pas, à ce stade, de réponse empiriquement documentée dans le domaine public pour l'environnement spécifique de S3NS. Ce qui suit présente les facteurs de risque identifiables à partir de la documentation architecturale publique, explicitement qualifiés d'hypothèses en l'absence de benchmarks comparatifs publiés.

Un premier facteur de risque potentiel est lié aux contraintes de dimensionnement. Les architectures TPU imposent, pour l'utilisation optimale des unités MXU, des tailles de matrices en multiples de 128. Les modèles dimensionnés nativement pour les TPU peuvent nécessiter, lorsqu'ils sont exécutés sur un GPU Nvidia dont les Tensor Core ont des contraintes d'alignement différentes, des opérations de rembourrage (padding) automatique des tenseurs. L'impact réel de ce phénomène sur les modèles Gemma déployés sur H100 n'est pas documenté publiquement ; il pourrait être marginal ou significatif selon les dimensions effectives du modèle.

Un second facteur concerne les formats numériques. Les TPU ont été conçus autour du format bfloat16. Les GPU Nvidia récents supportent ce format, et les bibliothèques CUDA/cuDNN ont progressé dans ce domaine. Il est plausible que cet écart soit aujourd'hui réduit dans la pratique, mais aucune mesure comparative publique pour les modèles Gemma dans un environnement analogue à S3NS ne permet de le confirmer.

Un troisième point a parfois été avancé dans la littérature spécialisée : l'idée que les patterns de parallélisme utilisés lors de l'entraînement sur pods TPU pourraient s'encoder indirectement dans les poids du modèle. Cette affirmation est contestée dans les travaux de recherche sur l'entraînement distribué, qui tendent à soutenir que les poids convergés sont, à variance statistique près, indépendants de la topologie d'interconnexion utilisée pendant l'entraînement. Ce point doit être considéré comme une hypothèse sans support empirique suffisant, et non comme un facteur de risque établi.

Note méthodologique : Les valeurs ci-dessus sont des estimations analytiques construites à partir de la documentation architecturale publique, en l'absence de benchmarks comparatifs publiés pour l'environnement S3NS. Le facteur "encodage topologie dans les poids" est explicitement contesté dans la littérature technique et doit être considéré comme non établi. S3NS pourrait avoir mis en oeuvre des optimisations spécifiques qui atténuent certains de ces facteurs.

3.3 L'absence de capacité d'entraînement autonome

Rien dans les sources publiques disponibles n'indique que S3NS dispose d'une capacité d'entraînement de modèles de frontière comparable à celle de Google. Les communications publiques de Google indiquent que ses modèles récents mobilisent des pods de plusieurs milliers de TPU interconnectés via un fabric propriétaire (ICI puis DCN). L'entraînement de modèles de la taille des Gemini récents, estimés à plusieurs centaines de milliards de paramètres, implique une infrastructure de calcul distribuée d'une ampleur que S3NS, dans son périmètre qualifié actuel, ne peut raisonnablement pas répliquer.

La conséquence de cette asymétrie est structurelle : S3NS dépend de Google pour chaque nouvelle génération de modèles. Elle peut choisir de ne pas mettre à jour les modèles déployés, au prix d'une obsolescence croissante dans un secteur où les générations se succèdent à rythme accéléré. Ou elle peut intégrer les nouvelles versions en acceptant que chaque modèle déployé dans son environnement certifié soit intégralement produit, calibré et aligné par une entité américaine.

Partie IV : SecNumCloud, qualification réelle et limites du périmètre certifié

4.1 Ce que certifie SecNumCloud, et ce qu'il ne certifie pas

SecNumCloud est un référentiel de cybersécurité, non un label de souveraineté technologique intégrale. La nuance est analytiquement fondamentale. Il certifie que le prestataire qualifié offre une protection des données contre les accès non autorisés, notamment vis-à-vis d'acteurs soumis à des législations extraeuropéennes, et que la gouvernance et l'exploitation sont sous contrôle d'une entité européenne.

Il ne certifie pas que le code logiciel utilisé est entièrement auditable par le prestataire, que les modèles IA déployés sont produits par une chaîne indépendante, que les mises à jour de modèles n'introduisent pas de comportements non désirés indétectables lors de l'inspection de la zone de quarantaine, ou que les fournisseurs technologiques tiers dont le code est intégré ne sont pas soumis à des contraintes légales américaines qui dépassent le périmètre du Cloud Act.

La qualification est sérieuse et utile. Elle résout un problème réel pour des organisations ayant besoin de traiter des données sensibles dans un environnement cloud performant. Mais son périmètre ne couvre pas toutes les dimensions d'une souveraineté IA institutionnelle.

4.2 La distinction analytique entre trois niveaux de souveraineté

Il convient de distinguer trois dimensions que le discours commercial de S3NS tend parfois à amalgamer.

La souveraineté des données désigne la capacité à garantir que les informations traitées ne sont pas accessibles à des acteurs non autorisés, notamment étrangers. C'est ce que SecNumCloud certifie dans son périmètre, et c'est réel.

La souveraineté opérationnelle désigne le contrôle sur les équipes d'exploitation, les processus d'accès, et les mises à jour logicielles. C'est également couvert par la qualification dans son périmètre, et c'est réel.

La souveraineté computationnelle, en revanche, désigne la maîtrise de la chaîne qui produit les capacités cognitives artificielles : conception architecturale des modèles, données d'entraînement, paramètres d'alignement (RLHF, RLMF), infrastructure d'entraînement, et rythme d'évolution des versions. Sur cette dimension, S3NS ne dispose d'aucun levier sur les modèles Google qu'elle déploie, et aucun mécanisme de la qualification SecNumCloud ne vise à y remédier. Ce n'est pas une critique du référentiel : ce n'est tout simplement pas son objet.

4.3 Le précédent Gaia-X et le risque de glissement sémantique

S3NS n'est pas le premier dispositif institutionnel européen où la tension entre ambition de souveraineté et dépendance technologique américaine structurelle s'est manifestée. Gaia-X, l'initiative franco-allemande de cloud souverain lancée en 2019, a progressivement intégré les hyperscalers américains (AWS, Azure, Google Cloud, Salesforce, Palantir) qu'elle était censée contrebalancer, conduisant à une critique généralisée d'une initiative de souveraineté "évidée de l'intérieur".

Le cas S3NS est structurellement différent : la dépendance technologique à Google est assumée et incorporée ab initio, non le résultat d'un glissement progressif. La contrainte juridique (isolation et gouvernance française) est documentée. Le problème analytique réside dans l'usage du mot "souverain" appliqué à des capacités IA dont la substance cognitive est entièrement produite par une entité américaine, sans que cette nuance soit systématiquement explicitée dans les communications commerciales.

Partie V : Ce que S3NS peut faire et ce qui reste hors portée

5.1 L'accès aux modèles de frontière : une limite pratique non formellement documentée

Dans l'état du catalogue public de S3NS connu à la date de rédaction, les modèles de frontière de Google (Gemini Pro, Ultra et générations équivalentes) ne figurent pas dans le périmètre de PREMI3NS. L'accès à ces modèles passe, selon les informations publiques disponibles, par les API Google Cloud standard, ce qui implique que les requêtes transitent par l'infrastructure de Google, hors périmètre SecNumCloud. En l'absence de déclaration primaire explicite de Google excluant formellement ces modèles d'un déploiement sur infrastructure tierce, cette lecture repose sur l'état du catalogue observé, non sur une interdiction contractuelle documentée.

La logique commerciale et stratégique de Google suggère que cette limitation est structurelle : les modèles de frontière constituent l'actif le plus stratégique de l'entreprise, et aucune incitation commerciale n'existe à en distribuer le contrôle à des tiers. La promesse de performance IA de S3NS est donc, dans l'état actuel, plafonnée par les modèles que Google accepte de rendre disponibles pour un déploiement sur infrastructure tierce.

5.2 Fine-tuning vs entraînement : une asymétrie fondamentale

S3NS peut proposer du fine-tuning de modèles Gemma sur ses GPU H100 dans l'environnement SecNumCloud. C'est une capacité réelle et utile. Mais le fine-tuning diffère structurellement de l'entraînement : il consiste à adapter les dernières couches d'un modèle pré-entraîné à un cas d'usage spécifique, en partant de poids initiaux intégralement produits par Google sur ses TPU propriétaires. L'adaptation est réelle ; la dépendance vis-à-vis de la base du modèle reste entière.

L'analogie pertinente est celle d'un atelier de personnalisation automobile qui peut modifier la carrosserie, la peinture et les équipements intérieurs d'un véhicule, mais dont le groupe motopropulseur, l'électronique de gestion moteur et les systèmes d'aide à la conduite sont intégralement fabriqués, mis à jour et contrôlés par le constructeur d'origine, qui en conserve les secrets de fabrication.

5.3 La tension entre rythme d'innovation et délai de qualification

Un aspect peu discuté de la qualification SecNumCloud dans le contexte de l'IA est la tension entre le rythme d'évolution des modèles et le délai de qualification des mises à jour. Dans le modèle S3NS, les mises à jour logicielles de Google Cloud passent par une zone de quarantaine et font l'objet d'une inspection avant déploiement. Ce processus prend "de l'ordre du mois" selon les propres déclarations de S3NS.

Dans l'écosystème Google, les modèles Gemma ont connu plusieurs générations majeures (Gemma 1, 2, 3) en moins de deux ans, et les mises à jour intermédiaires sont fréquentes. Un délai structurel d'un mois entre la publication d'une mise à jour et son déploiement dans PREMI3NS conduit à un écart permanent avec l'état de l'art. Si S3NS accélère les mises à jour pour rester compétitive, elle réduit le temps d'inspection dans la zone de quarantaine. Si elle ralentit, elle dégrade la compétitivité de son offre IA.

Note : Ces courbes illustrent une dynamique structurelle, non une mesure de performance. L'amplitude réelle du décalage dépend des délais effectifs d'inspection et du rythme de publication de Google, qui ne sont pas connus avec précision.

Partie VI : Limite résiduelle - le risque d'assistance technique confidentielle sous droit américain du renseignement

6.1 Ce que l'immunité Cloud Act ne résout pas

L'ANSSI a conclu, sur la base d'analyses juridiques commandées, que S3NS est "en principe" immune au Cloud Act américain de 2018. Cette immunité repose sur la structure juridique de S3NS : une société de droit français contrôlée par Thales, sans lien de subordination directe à Google susceptible de fonder une compétence juridictionnelle américaine sur les données hébergées.

Cette analyse est sérieuse et mérite d'être créditée. Mais le Cloud Act n'est pas l'unique vecteur d'extraterritorialité américaine dans le domaine numérique. La Section 702 du Foreign Intelligence Surveillance Act (FISA), réauthorisée en 2024, constitue un cadre juridique distinct avec une logique et des mécanismes différents.

Deux éléments de contexte renforcent la pertinence analytique de ce point sans en constituer la preuve. D'une part, les révélations d'Edward Snowden en juin 2013 ont documenté, via le programme PRISM opérant sous autorité FISA, que des obligations de coopération technique ont historiquement été imposées à des fournisseurs américains, dont Google figurait explicitement dans les documents déclassifiés, sous des formes que ces entreprises n'étaient pas en droit de divulguer. D'autre part, Google LLC est devenu en 2025 un contractant direct du Département de la Défense américain, avec un contrat de 200 millions de dollars signé avec le CDAO du DoD en juillet 2025 et le déploiement de Gemini for Government sur les postes du Pentagone en décembre 2025 (sources : Google Cloud Blog et communiqués DoD). Ces précédents ne prouvent rien quant à S3NS ; ils montrent que les obligations de coopération technique sous droit américain ont existé historiquement et que Google entretient désormais des relations contractuelles directes avec le DoD, ce qui renforce l'intérêt d'une analyse de risque résiduelle plutôt que de supposer que le seul Cloud Act épuise le sujet.

6.2 La Section 702 du FISA : un cadre distinct et plus complexe

La Section 702 du FISA autorise, sous supervision de la Foreign Intelligence Surveillance Court (FISC), la collecte par les agences de renseignement américaines de communications de personnes étrangères se trouvant hors des États-Unis, avec l'assistance contrainte de "fournisseurs de services de communication électronique" soumis au droit américain. Ce cadre inclut une obligation d'assistance technique et une clause de confidentialité qui peut interdire au fournisseur contraint de divulguer l'existence même de la demande.

Deux dimensions de ce cadre méritent une attention particulière dans le contexte S3NS. La première est la définition des "fournisseurs de services de communication électronique" susceptibles d'être soumis à des demandes au titre de la Section 702. Google LLC, en tant qu'entité américaine, entre dans cette catégorie. La question analytiquement pertinente est de savoir si et dans quelle mesure la séparation juridique entre Google LLC et S3NS, conçue pour l'immunité au Cloud Act, suffit à isoler S3NS des obligations qui pourraient découler d'une demande FISA visant des composants logiciels ou des canaux de communication que Google LLC continue d'exploiter dans le cadre du partenariat.

La seconde dimension est l'auditabilité. Dans l'hypothèse théorique où une autorité américaine pourrait exiger d'un fournisseur soumis au droit américain une assistance technique confidentielle, y compris sous une forme non publiquement auditable, cela créerait un angle mort de confiance qu'aucun client européen ne pourrait vérifier par lui-même, même dans un environnement SecNumCloud. Ce scénario relève de l'analyse de risque institutionnelle et non de la preuve publique d'une pratique documentée dans le cas S3NS. Il n'existe aucune information publique indiquant qu'une telle demande ait été formulée ou exécutée dans ce contexte. Le risque décrit ici porte sur l'existence possible d'une assistance technique contrainte et confidentielle ; il ne constitue pas l'affirmation qu'un code malveillant ou espion aurait été introduit dans les systèmes de S3NS. Le scénario décrit ici ne concerne pas spécifiquement Google ; il s'applique théoriquement à toute entreprise américaine soumise au FISA.

6.3 Portée et limites de ce scénario de risque

Ce scénario de contrainte est présenté ici pour trois raisons analytiques, non comme une accusation.

Premièrement, il est structurellement inhérent à tout partenariat avec une entité américaine, quelle que soit la rigueur du montage juridique européen : tant que des composants logiciels ou des canaux de communication transitent par des entités soumises au droit américain, la question de l'assistance technique confidentielle est théoriquement posée.

Deuxièmement, la zone de quarantaine de S3NS permet l'inspection des mises à jour applicatives. Elle ne permet pas, par construction, de détecter des modifications introduites à l'invitation d'une autorité étrangère dans un code source que Google ne publierait pas publiquement.

Troisièmement, ce risque n'invalide pas la qualification SecNumCloud, qui vise des objectifs différents et dans un cadre différent. Il indique simplement que la qualification ne constitue pas une garantie absolue contre toutes les formes d'influence potentielle liées au partenariat avec une entité américaine.

Partie VII : L'alternative partielle et ses conditions de réalisation

7.1 Mistral AI : une trajectoire substantiellement moins dépendante

S3NS a annoncé un partenariat avec Mistral AI pour l'intégration de ses modèles dans l'offre PREMI3NS. Cette direction mérite attention car elle représente une trajectoire analytiquement différente. Mistral AI entraîne ses modèles principalement sur des GPU Nvidia, non sur des TPU Google. Ses modèles peuvent en principe être déployés sur des GPU H100, c'est-à-dire le matériel que S3NS possède dans ses datacenters d'Ile-de-France.

Pour ce périmètre, un déploiement de modèles Mistral dans l'environnement SecNumCloud de S3NS constituerait une offre IA dont la chaîne de production est substantiellement moins dépendante de Google : les poids du modèle auraient été produits par une entité française, sur une infrastructure GPU non propriétaire de Google, avec des frameworks publics (PyTorch principalement). La souveraineté computationnelle serait significativement plus robuste sur cette dimension.

Les limites de cette trajectoire sont d'ordre commercial et de maturité de catalogue. Mistral n'offre pas à ce stade la profondeur de services intégrés que Google propose via Vertex AI (outils de données, orchestration, BigQuery). Le déploiement de Mistral dans PREMI3NS nécessite une intégration technique spécifique à l'environnement qualifié, représentant un investissement non négligeable.

7.2 Les modèles open-weight : une souveraineté intermédiaire avec dépendance Nvidia résiduelle

La catégorie des modèles open-weight (dont les poids sont publics) offre une voie de souveraineté intermédiaire. Llama (Meta), Mistral, Falcon et d'autres peuvent être déployés et affinés sur des GPU Nvidia, éliminant la dépendance à l'écosystème TPU/JAX de Google.

Cependant, cette trajectoire conserve une dépendance résiduelle au silicium Nvidia, entreprise américaine soumise aux réglementations d'export control américaines. Les GPU H100 de S3NS sont des composants produits à Santa Clara, distribués via une chaîne d'approvisionnement soumise aux règles du Bureau of Industry and Security (BIS). Dans un scénario de tension maximale entre les États-Unis et l'Union européenne, Nvidia pourrait être soumis à des restrictions d'export ou de maintenance qui affecteraient l'accès aux mises à jour de pilotes ou aux renouvellements de matériel.

Cette dépendance est d'un niveau de risque différent de la dépendance aux modèles Google, car elle porte sur du matériel générique et substituable à moyen terme, non sur l'intelligence cognitive des systèmes. Mais elle mérite d'être documentée dans une analyse de risque complète.

Partie VIII : Objections et réponses

8.1 L'argument de la souveraineté partielle acceptable

L'argument principal avancé par la direction de S3NS est le suivant : la souveraineté absolue est impossible dans l'économie numérique mondiale, et toute politique de souveraineté intégrale conduirait à l'immobilisme. Cyprien Falque l'a formulé sans ambiguïté : "le tout souverain n'existe pas."

Cet argument est formellement exact. Aucune économie développée ne maîtrise l'intégralité de sa chaîne technologique. Les CPU des serveurs S3NS sont vraisemblablement américains. Les commutateurs réseau probablement aussi. La fonderie qui a fabriqué ces composants est vraisemblablement taïwanaise (TSMC). Une exigence de souveraineté intégrale serait irréalisable et paralysante.

La réfutation pertinente de cet argument n'est pas "il faudrait une souveraineté absolue" mais "toutes les dépendances technologiques ne sont pas équivalentes en termes de risque stratégique". Une dépendance à une fonderie pour des composants génériques (CPU, mémoire RAM) est quantitativement différente d'une dépendance à un acteur unique pour les modèles IA déployés dans des fonctions décisionnelles critiques. Le premier type de dépendance est substituable ; le second implique que l'intelligence cognitive des systèmes d'un OIV est produite, alignée et mise à jour par une entité étrangère sans possibilité de contrôle indépendant.

8.2 L'argument de la gestion des risques extraterritoriaux

S3NS et l'ANSSI soutiennent que la qualification garantit une protection "vis-à-vis du droit extraeuropéen", et que les analyses juridiques commandées concluent à une immunité "en principe" vis-à-vis du Cloud Act et du FISA Act. Cette affirmation mérite crédit sur le périmètre qu'elle vise : les données hébergées.

Elle doit cependant être complétée par deux nuances. D'une part, la phrase "en principe" du directeur général de l'ANSSI indique une protection qui n'a pas été testée en conditions réelles devant une juridiction américaine. D'autre part, le périmètre de l'immunité revendiquée porte sur des cadres juridiques stabilisés (Cloud Act, FISA Act dans ses applications connues), non nécessairement sur les évolutions réglementaires plus récentes du droit américain du renseignement numérique, dont l'application extraterritoriale reste à préciser pour des montages comme celui de S3NS.

8.3 L'argument de la pragmatique industrielle

Un troisième argument est celui de la décision raisonnable en l'absence d'alternative comparable : en l'état, le choix entre S3NS (dépendance partielle, données protégées) et une solution non qualifiée (dépendance totale, données non protégées) penche raisonnablement en faveur de S3NS pour les usages de traitement de données sensibles.

Ce raisonnement est juste pour les usages de stockage, de traitement de données et de calcul générique. Il mérite une différenciation pour les usages IA dans des fonctions décisionnelles critiques. Sur ce segment, la décision d'utiliser S3NS doit s'accompagner d'une documentation explicite des dépendances résiduelles dans les analyses de risque institutionnelles, et non d'une référence à la qualification SecNumCloud comme garantie de souveraineté globale.

Partie IX : Scénarios prospectifs

9.1 Scénario dominant : Consolidation de la dépendance Google

Dans ce scénario, S3NS consolide son déploiement commercial avec Vertex AI comme colonne vertébrale de son offre IA. Les modèles Gemma et les services Google deviennent la référence de facto pour les OIV et administrations qui utilisent PREMI3NS. La dépendance à l'écosystème Google est acceptée comme contrepartie de la performance et de la richesse du catalogue, sans que les limites de souveraineté computationnelle soient explicitement documentées dans les politiques de risque des clients.

Ce scénario est le plus probable à court terme parce qu'il correspond à la dynamique de minimisation de l'effort : S3NS offre une solution disponible, qualifiée et commercialement soutenue. L'inertie institutionnelle tend à favoriser les solutions disponibles sur les solutions idéalement souveraines.

9.2 Scénario alternatif : Recomposition vers les modèles non Google

Dans ce scénario, la combinaison d'une prise de conscience des limites de la souveraineté IA Google, d'une montée en puissance de Mistral AI et d'une évolution de la doctrine réglementaire conduit S3NS à construire une offre IA à deux vitesses : des modèles non Google pour les usages critiques nécessitant une traçabilité de la chaîne d'entraînement, des services Google pour les usages moins sensibles.

Ce scénario est plausible à moyen terme (5-8 ans) si Mistral AI maintient un niveau de performance compétitif et si le régulateur européen développe une doctrine explicite sur la souveraineté des modèles, distincte de la souveraineté des données.

9.3 Scénario de rupture : Émergence d'un silicium IA européen

Dans ce scénario, les investissements dans le silicium IA européen (Chips Act, projets IPCEI, fonds souverains) aboutissent à l'émergence d'un accélérateur IA compétitif d'ici 2030-2035, permettant l'entraînement de modèles de frontière sur infrastructure indépendante des États-Unis.

Ce scénario est le moins probable à l'horizon de la présente analyse, non parce qu'il est techniquement impossible, mais parce que les délais de développement du silicium IA de frontière sont longs (7-10 ans) et que les investissements européens restent insuffisants comparativement aux volumes américains et chinois dans ce segment spécifique.

Partie X : Recommandations analytiques

10.1 Pour les décideurs publics et les OIV

Il est recommandé une différenciation explicite, dans les doctrines d'achat et les analyses de risque, entre les usages cloud pour le stockage et le traitement de données sensibles (domaine où S3NS offre des garanties réelles et certifiées) et les usages IA pour des fonctions décisionnelles critiques (domaine où la qualification SecNumCloud ne couvre pas la souveraineté de la chaîne de production des modèles).

Pour les fonctions IA critiques, les cahiers des charges devraient intégrer des exigences explicites sur la traçabilité de la chaîne d'entraînement des modèles, l'accessibilité et la pérennité des poids, la capacité de fine-tuning dans l'environnement qualifié, et les garanties contractuelles sur la continuité de service en cas d'évolution des relations géopolitiques.

10.2 Pour S3NS et Thales

La coentreprise gagnerait en crédibilité institutionnelle à distinguer explicitement, dans ses communications commerciales, les services pour lesquels la souveraineté est substantielle et certifiée (stockage, calcul générique, bases de données) et les services IA pour lesquels la dépendance à Google reste structurelle dans l'état actuel. Cette transparence renforcerait la confiance des clients institutionnels qui doivent défendre leurs choix d'achat devant des auditeurs et des commissions parlementaires.

Le partenariat avec Mistral AI mérite d'être développé en priorité pour le segment des applications critiques. La combinaison d'un modèle entraîné par une entité française sur infrastructure GPU, d'un hébergement en datacenter qualifié SecNumCloud et d'un fine-tuning souverain dans PREMI3NS constituerait une offre IA substantiellement plus défendable sur la dimension de la souveraineté computationnelle.

10.3 Pour le régulateur

La doctrine "cloud au centre" et le référentiel SecNumCloud ont été conçus autour de la problématique des données, antérieurement à l'émergence de l'IA générative comme composant d'infrastructure. Une mise à jour du cadre réglementaire est analytiquement nécessaire pour traiter la souveraineté des modèles IA comme une dimension distincte et complémentaire.

Cela pourrait prendre la forme d'un référentiel complémentaire pour les "Systèmes IA de Confiance" évaluant la traçabilité de la chaîne d'entraînement, les garanties sur les paramètres d'alignement, et les mécanismes de continuité de service indépendants de décisions unilatérales du fournisseur du modèle.

Limites analytiques et méthodologiques

La présente analyse repose sur des sources publiques et des raisonnements d'ingénierie documentés, mais comporte plusieurs limites explicites.

Premièrement, S3NS n'a pas publié de benchmarks comparatifs entre les performances des modèles Gemma déployés sur ses GPU H100 et les mêmes modèles sur infrastructure TPU Google. Les facteurs de risque présentés dans la section 3.2 sont des hypothèses analytiques construites à partir de la documentation architecturale publique. Certains peuvent être atténués par des optimisations non documentées de S3NS, et le facteur lié à l'encodage de la topologie d'interconnexion dans les poids est explicitement contesté dans la littérature technique.

Deuxièmement, les informations sur l'infrastructure d'entraînement des modèles Gemini récents reposent sur des analyses secondaires, non sur des communications primaires officielles de Google. Ces éléments sont traités dans cet article comme des hypothèses plausibles.

Troisièmement, le scénario de contrainte FISA Section 702 décrit dans la partie VI est présenté comme un risque théorique relevant de l'analyse de risque institutionnelle. Il ne constitue pas la description d'une pratique documentée dans le cas S3NS, et aucune information publique ne permet d'affirmer qu'une telle contrainte ait été exercée ou exécutée.

Quatrièmement, les scénarios géopolitiques mobilisés (tensions USA-UE, modification unilatérale des conditions d'accès aux modèles) sont des scénarios de stress à faible probabilité à court terme. Ils ne constituent pas des prédictions mais des variables de robustesse à intégrer dans les analyses de résilience institutionnelle.

Cinquièmement, les probabilités assignées aux scénarios prospectifs et les scores de souveraineté présentés dans les visualisations sont des estimations à haute incertitude. Leur valeur est illustrative de la logique des dynamiques en jeu, non prédictive ou normative.

Encadré méthodologique : faits établis, hypothèses plausibles, scénarios de stress

Faits établis par source primaire publique

Ce qui relève des faits documentés dans les sources primaires publiques consultées lors de la rédaction du présent article :

Gemma 3 a été entraîné sur les TPU de Google en utilisant le framework JAX et l'infrastructure ML Pathways. (Source : Google Developers Blog, mars 2025)

S3NS a obtenu la qualification SecNumCloud 3.2 en décembre 2025, couvrant simultanément IaaS, PaaS et CaaS. (Source : ANSSI, communiqué de qualification)

L'ANSSI a déclaré les montages S3NS et Bleu "conformes, sur le papier, aux exigences du SecNumCloud", avec une immunité au Cloud Act analysée comme "en principe" valide. (Source : audition sénatoriale de Vincent Strubel, directeur de l'ANSSI)

S3NS revendique environ 60 à 70 clients début 2026, avec EDF et Birdz cités publiquement. (Source : S3NS Summit, février 2026)

Vertex AI Model Garden est annoncé sur PREMI3NS avec un déploiement progressif en 2026. (Source : S3NS Summit, février 2026)

La Section 702 du FISA autorise la collecte de communications étrangères avec assistance contrainte et clause de confidentialité pour les fournisseurs de services de communication électronique soumis au droit américain. (Source : texte législatif américain, version réauthorisée 2024)

Hypothèses plausibles, non établies par source primaire

Ce qui relève d'hypothèses cohérentes avec les données disponibles mais non confirmées par source primaire :

Les générations récentes de Gemini ont probablement été entraînées principalement sur des pods TPU v5e/v6e, avec une réduction du recours aux GPU Nvidia, en cohérence avec la stratégie publiquement déclarée de Google de réduire sa dépendance à Nvidia. Cette affirmation repose sur des analyses secondaires, non sur une communication officielle de Google.

Le déploiement de modèles conçus nativement pour TPU sur GPU H100 peut introduire des inadéquations d'optimisation liées aux contraintes de dimensionnement MXU. L'impact réel sur les modèles Gemma dans l'environnement S3NS n'est pas documenté publiquement.

Les modèles de frontière Gemini ne sont pas disponibles pour un déploiement autonome dans PREMI3NS. Cette lecture repose sur l'état du catalogue connu, non sur une interdiction contractuelle documentée.

Scénarios de stress à faible probabilité à court terme

Ce qui relève de scénarios de contrainte théoriques intégrés pour des raisons de robustesse analytique, non de prédiction :

Un gouvernement américain pourrait, dans un contexte de tension géopolitique extrême, mobiliser des instruments légaux (export controls, FISA Section 702) pour contraindre des entités américaines partenaires de S3NS à des comportements modifiant de facto les garanties offertes aux clients européens.

Google pourrait modifier unilatéralement les conditions d'accès aux modèles déployés dans PREMI3NS, conduisant à une obsolescence rapide de l'offre IA ou à un dilemme entre sécurité et compétitivité pour S3NS.

La chaîne d'approvisionnement en GPU Nvidia pourrait être affectée par des restrictions d'export control américaines, impactant la capacité de renouvellement du parc d'accélérateurs de S3NS.

Annexe : Glossaire technique

ASIC (Application-Specific Integrated Circuit) : Circuit intégré conçu pour une application spécifique. Les TPU sont des ASIC spécialisés pour le calcul matriciel des réseaux de neurones.

bfloat16 : Format numérique à virgule flottante sur 16 bits développé par Google. Il conserve la même plage dynamique que le float32 tout en réduisant la précision de la mantisse, ce qui convient aux besoins de l'apprentissage automatique.

Fine-tuning : Adaptation d'un modèle pré-entraîné à un cas d'usage spécifique via un entraînement complémentaire sur un jeu de données ciblé. Distinct de l'entraînement from scratch.

ICI (Inter-Chip Interconnect) : Fabric d'interconnexion propriétaire de Google reliant les TPU au sein d'un pod, offrant des caractéristiques de bande passante et de latence supérieures à NVLink pour les topologies de très grande échelle.

JAX : Framework de calcul numérique haute performance développé par Google, conçu pour une compilation vers XLA et optimisé pour les TPU. Utilisé documentairement pour l'entraînement de Gemma 3 ; son utilisation pour Gemini est plausible mais non confirmée par source primaire.

ML Pathways : Infrastructure d'entraînement à grande échelle de Google permettant l'utilisation distribuée de ressources TPU à travers plusieurs datacenters. Mentionnée dans la model card officielle de Gemma 3.

MXU (Matrix Multiply Unit) : Unité de multiplication matricielle au coeur de chaque TPU. Composée d'un tableau systolique de 128x128 accumulateurs (ou 256x256 sur les générations récentes). Les modèles conçus pour TPU sont dimensionnés pour maximiser l'utilisation de ces unités.

SecNumCloud : Référentiel de qualification de l'ANSSI certifiant la sécurité des services cloud et la protection contre les accès extra-européens non autorisés. Ne constitue pas un label de souveraineté de la chaîne de production des modèles IA.

Section 702 FISA : Disposition du Foreign Intelligence Surveillance Act autorisant la collecte de communications de personnes étrangères hors États-Unis avec assistance contrainte de fournisseurs de services de communication électronique soumis au droit américain. Inclut une clause de confidentialité qui peut interdire la divulgation de l'existence d'une demande.

TPU (Tensor Processing Unit) : ASIC développé par Google pour les charges de travail d'apprentissage automatique. Disponible en sept générations (v1 à Ironwood v7). Accessible uniquement en interne chez Google ou via Google Cloud.

XLA (Accelerated Linear Algebra) : Compilateur développé par Google pour optimiser et compiler les graphes de calcul d'apprentissage automatique vers TPU, GPU et CPU. Obligatoire pour toute exécution sur TPU.

Sources principales mobilisées : Google Developers Blog, "Introducing Gemma 3" (mars 2025) ; Google Cloud TPU documentation (docs.cloud.google.com/tpu) ; IntuitionLabs, "Google TPUs Architecture and Performance" (décembre 2025) ; Usine Digitale, couverture S3NS 2024-2026 ; Usine Nouvelle, "S3NS Summit 2026" (février 2026) ; LeMagIT, "S3NS annonce l'obtention de sa qualification SecNumCloud" (décembre 2025) ; Google Cloud Blog, "Gemma model available in Vertex AI" (2024) ; JAX AI Stack documentation (docs.cloud.google.com/tpu/docs/jax-ai-stack) ; Foreign Intelligence Surveillance Act Section 702, version réauthorisée 2024.