S3NS et Bleu : 100% de code américain, 0% de souveraineté, 40% de surcoût !

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

Thèse centrale

La France a choisi de confier les clés de sa souveraineté numérique à ceux-là mêmes qui la menacent. Les offres S3NS (Thales/Google) et Bleu (Orange/Capgemini/Microsoft), présentées comme la réponse à notre dépendance technologique, en constituent en réalité l'institutionnalisation. Cette stratégie résulte de défaillances de processus identifiables : une asymétrie d'information structurelle entre décideurs politiques et enjeux techniques, un biais de conformité des cabinets de conseil qui recommandent des solutions américaines tout en facturant du « conseil en souveraineté », une ANSSI dont la qualification de sécurité est détournée en caution de souveraineté par le marché, et une chaîne d'audit structurellement incapable d'examiner le code fermé qu'elle prétend qualifier. Le FISA 702 élargi par le RISAA d'avril 2024 [^1] rend ce montage plus dangereux que jamais, les vulnérabilités critiques découvertes dans les produits Dell en 2025-2026 [^5] en exposent la fragilité, et l'ensemble contredit frontalement les recommandations du rapport Draghi sur la compétitivité européenne.

Le constat en neuf points

1. Une dépendance totale à la technologie américaine. S3NS repose à 100% sur Google Cloud Platform. Bleu repose à 100% sur Microsoft Azure et Microsoft 365. Le contrôle capitalistique français ne change rien au contrôle technologique américain : le code source, les mises à jour, les algorithmes de chiffrement, les correctifs de sécurité viennent intégralement de Mountain View et de Redmond.

2. Un surcoût garanti pour une protection illusoire. Le montage « souverain » induit un surcoût estimé entre 20% et 40% par rapport aux offres directes des hyperscalers (estimations sectorielles Markess by Exaegis, confirmées par les déclarations d'Helmut Reisinger, CEO d'Orange Business). En Allemagne, le cloud « souverain » de T-Systems (équivalent de S3NS avec Google) coûte plus de 30% de plus que l'offre native (source : T-Systems, grille tarifaire publique). L'argent ainsi dépensé rémunère des intermédiaires français pour revendre de la technologie américaine, sans créer la moindre capacité industrielle propre.

3. Un risque de coupure assumé par l'ANSSI elle-même. Guillaume Poupard, ancien directeur de l'ANSSI, a déclaré devant le Sénat en mai 2025 : « Si, demain, les fournisseurs de technologies américains décident de ne plus fournir leurs technologies, ces systèmes s'effondreront très rapidement. On parle de jours ou de semaines. » Vincent Strubel, actuel directeur de l'ANSSI, a corroboré cette analyse.

4. Une contradiction flagrante avec le rapport Draghi. Le rapport sur la compétitivité européenne (septembre 2024), commandé par la Commission européenne, appelle à réduire les dépendances technologiques, à développer des solutions européennes de cloud, et à investir 750 à 800 milliards d'euros par an dans l'autonomie stratégique. La France fait exactement l'inverse : elle injecte des milliards dans des structures qui renforcent la domination des hyperscalers américains.

5. Un marché capté à 70% par trois acteurs américains. AWS, Azure et Google Cloud captent ensemble environ 70% du marché français du cloud d'infrastructure, soit environ 9 milliards d'euros en 2024 (sources : Markess by Exaegis ; Synergy Research Group, Q4 2024). En Europe, la part des fournisseurs locaux est passée d'environ un tiers en 2017 à 15% en 2024 (Synergy Research Group, « European Cloud Providers Continue to Lose Ground », 2024). Chaque euro dépensé dans S3NS ou Bleu alimente les revenus de Google et Microsoft via les licences technologiques, accélérant le décrochage européen.

6. Des alternatives européennes ignorées. OVHcloud (993 millions d'euros de chiffre d'affaires en 2024, rapport annuel OVHcloud), Scaleway, 3DS Outscale, Cloud Temple, Numspot : la France dispose d'acteurs capables de construire un véritable écosystème souverain. Ces entreprises, qualifiées ou en cours de qualification SecNumCloud sans dépendance technologique américaine, sont marginalisées dans la commande publique au profit de montages dont les licences alimentent les revenus de la Silicon Valley.

7. Le FISA 702 élargi rend le montage juridique caduc. La loi RISAA d'avril 2024 a étendu la portée de la surveillance américaine à tout prestataire « ayant accès à des équipements » de communication, incluant potentiellement les datacenters et les sous-traitants de la chaîne cloud [^1]. L'EFF qualifie cette extension de « l'une des expansions les plus terrifiantes de la surveillance gouvernementale de l'histoire ». La section 702 expire le 20 avril 2026 [^4], et son périmètre élargi crée un risque juridique structurel que les évaluations de conformité en vigueur ne prennent pas en compte.

8. L'ANSSI ne peut pas auditer du code fermé. Le référentiel SecNumCloud prévoit un « contrôle du code source des fonctionnalités de sécurité ». Mais sur une offre S3NS ou Bleu, l'audit porte uniquement sur la couche opérationnelle française — une fraction du périmètre logiciel total (estimation analytique : environ 15%, le périmètre exact étant couvert par des accords de confidentialité [^2]). Les centaines de millions de lignes de code de Google Cloud Platform ou Microsoft Azure restent une boîte noire que personne ne contrôle. Cette asymétrie d'information biaise l'ensemble du processus de décision.

9. Les vulnérabilités critiques Dell exposent la fragilité de la chaîne d'audit. En 2025-2026, des vulnérabilités critiques ont été découvertes dans les produits Dell (RecoverPoint CVE-2026-22769, score CVSS 10/10, exploité 18 mois par un acteur étatique chinois [^5] ; ControlVault3 « ReVault » affectant 100+ modèles de laptops gouvernementaux). Ces équipements peuplent les datacenters de S3NS et Bleu. Si des identifiants codés en dur dans un fichier de configuration échappent à tous les audits pendant 18 mois, la promesse que Thales détectera une compromission supply-chain dans le code de Google Cloud mérite d'être interrogée.

Le meilleur des mondes numériques : retour sur le S3NS Summit

L'auto-félicitation comme politique industrielle

Le 17 février 2026, au Palais Brongniart, 1 300 participants se sont réunis pour le quatrième S3NS Summit. Patrice Caine, PDG de Thales, a célébré l'obtention, après cinq années d'efforts, de la qualification SecNumCloud 3.2. Le mot « souveraineté » a été prononcé des dizaines de fois. Et personne dans la salle ne semble avoir relevé le paradoxe fondamental de la situation : on célébrait le droit de revendre de la technologie Google dans un emballage tricolore.

La rhétorique est rodée. Cyprien Falque, directeur général de S3NS, explique que « le tout souverain n'existe pas » et qu'il y a « une utilisation maîtrisée de technologies extra-européennes ». Isabelle Fraine, directrice générale de Google Cloud pour la France, assure que c'est Google qui a eu l'idée de confier à Thales l'exploitation d'un cloud Google « selon les termes de l'Europe ». Comme si Google avait un intérêt stratégique à limiter sa propre emprise sur les données européennes.

Ce discours est celui d'une résignation confortable, habillée en pragmatisme. Il repose sur un postulat rarement interrogé : qu'il serait impossible de construire des solutions européennes compétitives. Or les faits montrent le contraire : construire des solutions propres prend du temps, coûte de l'argent, exige du courage politique et de la compétence technique. La facilité d'un partenariat avec le leader technologique mondial a prévalu sur l'investissement dans l'autonomie.

Ce que SecNumCloud garantit, et ce qu'il ne garantit pas

Vincent Strubel, directeur général de l'ANSSI, a eu la franchise de clarifier les choses dans un communiqué du 6 janvier 2026 : « La qualification d'une offre n'est ni une décision arbitraire, ni un choix politique. » Il a précisé que SecNumCloud « n'est pas un label de souveraineté au sens politique du terme, mais un outil de cybersécurité destiné à des usages sensibles, fondé sur une évaluation rigoureuse et standardisée des risques ».

Cette mise au point est honnête. Mais elle révèle précisément le problème. SecNumCloud évalue environ 1 200 exigences de sécurité : cloisonnement, chiffrement, contrôle des accès, auditabilité. C'est un travail rigoureux et nécessaire. Mais ce label ne peut pas, par construction, garantir ce qu'aucune architecture technique ne peut garantir quand la technologie sous-jacente appartient à un tiers soumis au droit d'un État étranger.

Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) permet aux autorités américaines d'exiger la divulgation de données détenues par des entreprises américaines, quel que soit le lieu de stockage. Le FISA (Foreign Intelligence Surveillance Act) autorise la surveillance de communications de personnes non américaines. L'EAR (Export Administration Regulations) permet de restreindre l'exportation de technologies américaines.

L'ANSSI affirme que Google et Microsoft, dans le cadre de S3NS et Bleu, ne sont pas en situation de « possession, custody or control » au sens du CLOUD Act, puisque Thales et Orange/Capgemini opèrent les données. C'est un argument juridique qui n'a jamais été testé devant un tribunal américain. Et l'étude commandée par le ministère néerlandais de la Justice au cabinet Greenberg Traurig conclut exactement l'inverse : le CLOUD Act s'applique aussi quand un fournisseur européen utilise du hardware ou un logiciel américain.

Qui croire ? L'ANSSI française, qui a un intérêt institutionnel à défendre sa qualification, ou un cabinet d'avocats américain spécialisé en droit extraterritorial mandaté par un gouvernement européen ? La question mérite d'être posée, et le fait qu'elle soit si rarement posée dans les cercles décisionnels français révèle une lacune dans le processus d'évaluation des risques.

Partie I : Anatomie d'une dépendance consentie

1.1 S3NS : quand Thales devient revendeur Google

S3NS, prononcé « sens », est une coentreprise détenue majoritairement par Thales (plus de 76%) et minoritairement par Google Cloud (moins de 24%). Elle emploie environ 100 ingénieurs formés par Google. Son siège est à Paris. Ses datacenters sont en Île-de-France, dans des salles séparées mais situées dans les mêmes bâtiments que la région cloud française de Google.

La promesse est la suivante : offrir l'intégralité de Google Cloud Platform dans un environnement « de confiance », opéré par du personnel européen, avec des clés de chiffrement gérées par Thales, et qualifié SecNumCloud. L'offre PREMI3NS, qualifiée en décembre 2025, propose 27 services. La feuille de route prévoit 23 services supplémentaires au second semestre 2026 (dont Vertex AI, Dataproc, Cloud Run) et d'autres en 2027 et au-delà.

Décortiquons cette architecture. Le code source de chaque service Google Cloud est développé, maintenu et mis à jour par les ingénieurs de Google à Mountain View. Ce code passe par un « sas de sécurité piloté par Thales » : les mises à jour sont « réceptionnées, évaluées et validées ». Mais Thales n'a ni la capacité ni le mandat de réécrire le code. Si Google cesse de fournir les mises à jour, le service se dégrade puis s'arrête en « jours ou semaines » selon Guillaume Poupard.

La proposition de valeur de S3NS se résume donc ainsi : payer plus cher pour utiliser Google Cloud avec un intermédiaire français qui gère les clés de chiffrement et qui vérifie que les mises à jour ne contiennent pas de portes dérobées évidentes. C'est un service de conformité réglementaire, pas un acte de souveraineté.

Au S3NS Summit de février 2026, 70 clients ont été annoncés, incluant des OIV comme EDF, Veolia, la Banque de France. Des start-ups sont également séduites. L'Agence du Numérique en Santé figure parmi les premiers clients. Le secteur public, après des réticences initiales, « accélère » selon Cyprien Falque.

Ces organisations sont en train de construire leur infrastructure critique sur un socle technologique qu'un décret présidentiel américain, une décision de l'OFAC, ou une simple rétorsion commerciale dans le cadre d'une guerre tarifaire pourrait rendre inutilisable du jour au lendemain.

1.2 Bleu : Microsoft avec un drapeau français

Bleu, créée par Capgemini et Orange en 2021 dans la foulée du discours de Bruno Le Maire sur le « cloud de confiance », suit un schéma identique. La coentreprise de droit français commercialise Microsoft 365 et Microsoft Azure, hébergés dans des datacenters séparés de ceux de Microsoft, opérés par du personnel français.

Le jalon J1 de la qualification SecNumCloud a été accepté par l'ANSSI en novembre 2025. La qualification complète est attendue au premier semestre 2026. La cible est explicitement le secteur public : OIV, OSE, État, collectivités, hôpitaux.

Dassault Aviation, acteur majeur de l'aéronautique militaire française, a choisi les solutions cloud de Bleu. Le constat mérite d'être posé : un constructeur d'avions de combat a décidé de confier sa collaboration numérique à une plateforme reposant intégralement sur la technologie Microsoft, c'est-à-dire sur la technologie d'un éditeur soumis au droit américain, dans un contexte où la France vend des Rafale en compétition directe avec le F-35 de Lockheed Martin. Le risque d'asymétrie informationnelle au profit d'un concurrent stratégique n'a visiblement pas été jugé rédhibitoire.

Helmut Reisinger, directeur général d'Orange Business Services, a annoncé la couleur dès le départ : la tarification sera « très proche de celle de Microsoft, mais un peu plus élevée ». Il a ajouté que « la souveraineté et la maîtrise de la propriété intellectuelle représentent un avantage compétitif, ce qui a un coût ». Sauf qu'il n'y a ici ni souveraineté réelle ni maîtrise de la propriété intellectuelle : le code de Microsoft 365 et d'Azure reste la propriété exclusive de Microsoft.

Brad Smith, président de Microsoft, a certes promis en 2025 un dispositif d'escrow (mise sous séquestre du code source) pour garantir la continuité de service en cas de rupture. « Nous garantirons à nos partenaires européens les droits légaux nécessaires pour accéder à ce code et l'utiliser si cela s'avère nécessaire », a-t-il écrit. Jean Coumaros, président de Bleu, a confirmé que « le dispositif est en cours de conception ». Un dispositif « en cours de conception » pour un service « en cours de commercialisation » destiné à protéger les données les plus sensibles de la nation : la désinvolture est vertigineuse.

1.3 L'affaire de la CPI : quand la théorie rencontre la réalité

En 2025, les États-Unis ont imposé des sanctions contre le personnel de la Cour pénale internationale (CPI), menaçant « toute personne, institution ou entreprise d'amendes et de peines de prison en cas de soutien financier, matériel ou technologique » au procureur Karim Khan. Ce dernier s'est retrouvé contraint de migrer sa messagerie vers Proton Mail après la coupure de son accès Microsoft.

Microsoft a nié être directement à l'origine de la coupure. Anton Carniaux, directeur des affaires publiques de Microsoft France, a déclaré devant le Sénat que « la coupure en elle-même n'est pas du fait de Microsoft ». L'ambiguïté de cette formulation est révélatrice : que la coupure soit le fait de Microsoft, d'un prestataire intermédiaire intimidé par les sanctions, ou d'un excès de compliance, le résultat est identique. Le procureur général d'une cour internationale n'a plus eu accès à sa messagerie professionnelle parce que Washington l'a décidé.

Cet épisode illustre exactement le risque que S3NS et Bleu prétendent résoudre mais qu'ils ne font que maquiller. La structure juridique française de la coentreprise ne protège en rien contre la décision politique d'un État qui contrôle la technologie. Un décret américain plaçant une entité française sur l'Entity List rendrait illégale la fourniture de mises à jour technologiques à cette entité, quels que soient les montages contractuels interposés.

Partie II : Le surcoût de l'illusion

2.1 Payer plus pour moins de souveraineté

Le modèle économique de S3NS et Bleu repose sur une double facturation : les licences technologiques versées à Google et Microsoft, et la marge opérationnelle des coentreprises françaises pour le surcoût lié à l'isolation, au chiffrement additionnel, à la conformité SecNumCloud et à l'exploitation par du personnel français.

En Allemagne, le montage équivalent de T-Systems avec Google induit un surcoût de plus de 30% par rapport aux services natifs de Google Cloud (source : grille tarifaire publique T-Systems Sovereign Cloud, confirmée par les analyses Gartner). Pour Bleu, Helmut Reisinger (CEO Orange Business) a reconnu un surcoût « un peu plus élevé » que les tarifs directs de Microsoft (interview L'Usine Digitale, 2024). Les analystes du secteur (Markess by Exaegis, IDC) estiment le premium entre 20% et 40% selon les services.

Pour un marché français du cloud d'infrastructure estimé à 9 milliards d'euros en 2024 (Markess by Exaegis), si seulement 20% des dépenses étaient réorientées vers ces offres « de confiance » (ce qui est l'objectif affiché pour les données sensibles), cela représenterait environ 1,8 milliard d'euros, dont 360 à 720 millions de surcoût par rapport aux offres natives des hyperscalers, et la quasi-totalité des licences technologiques revenant aux comptes de résultat de Google et Microsoft.

Ce surcoût ne finance pas la moindre ligne de code européen. Il ne finance pas la moindre capacité de calcul propriétaire. Il ne finance pas la moindre alternative à long terme. Il finance le droit de dire « souverain » en parlant de quelque chose qui ne l'est pas.

2.2 L'argent qui manque aux alternatives européennes

Pendant que la France investit dans des montages de revente, ses champions européens survivent avec des moyens limités face aux hyperscalers. OVHcloud a réalisé 993 millions d'euros de chiffre d'affaires en 2024 (rapport annuel OVHcloud FY2024), dont 49% en France. C'est l'équivalent de ce qu'Amazon Web Services génère en moins de trois jours de revenus mondiaux (AWS revenue : 107 milliards USD en 2024, rapport annuel Amazon).

Scaleway, filiale d'Iliad, investit dans le GPU (achat de 1 000 GPU NVIDIA H100 en 2024) et noue des partenariats stratégiques (France Télévisions). 3DS Outscale, filiale de Dassault Systèmes, est qualifiée SecNumCloud. Numspot, lancée par Docaposte, construit une offre souveraine. Cloud Temple est également dans la course.

Ces acteurs ne demandent pas la charité. Ils demandent des conditions de concurrence équitables et une commande publique qui privilégie les solutions véritablement européennes, conformément aux recommandations du rapport Draghi. Au lieu de quoi, l'État français, les collectivités et les OIV sont encouragés par la doctrine « cloud de confiance » à choisir les repackagings franco-américains de Google et Microsoft.

Le rapport Draghi chiffre les besoins d'investissement européens à 750-800 milliards d'euros par an pour combler le retard technologique (rapport Draghi, « The Future of European Competitiveness », septembre 2024, p. 2). La France répond en subventionnant indirectement la R&D de Mountain View et Redmond.

Partie III : La contradiction Draghi

3.1 Ce que dit réellement le rapport Draghi

Le rapport « L'avenir de la compétitivité européenne », remis le 9 septembre 2024 par Mario Draghi à la Commission européenne, est un document de 400 pages qui dresse un diagnostic sans appel. L'écart de PIB entre l'UE et les États-Unis est passé de +4% en faveur de l'Europe en 2002 à -12% en 2023. Le principal moteur de cet écart est le retard dans l'économie numérique.

Sur le cloud, le rapport constate « un retard non rattrapable de l'Europe sur les États-Unis ». Mais il ne conclut pas à la résignation. Il recommande, pour les secteurs publics et les infrastructures critiques, de « favoriser des solutions locales » dans les appels d'offres. Il appelle à « garder un pied dans les domaines où la souveraineté technologique est nécessaire, tels que la sécurité et le cryptage ». Il reconnaît que les partenariats de type S3NS sont « la deuxième meilleure option disponible en Europe en matière de sécurité des données et de souveraineté territoriale ».

Cette formulation est éclairante. La « deuxième meilleure option ». La première, implicitement, est la construction d'un écosystème européen autonome. Mais la France, au lieu de travailler à la première option tout en utilisant la seconde comme transition, a fait de la seconde option sa stratégie définitive. C'est la différence entre utiliser un pansement en attendant de soigner la plaie et se féliciter de la qualité de ses pansements en refusant de voir que la plaie s'aggrave.

3.2 Les 170 recommandations ignorées

Le rapport Draghi formule 170 recommandations. Un an après sa publication, selon le European Policy Innovation Council, seulement 11% d'entre elles ont commencé à être mises en oeuvre. La France n'a engagé aucune politique industrielle structurante pour le cloud européen. Le plan de 1,8 milliard d'euros annoncé par le gouvernement n'a produit aucun hyperscaler français. Il a en revanche facilité l'émergence de S3NS et Bleu, c'est-à-dire de véhicules de commercialisation des technologies américaines.

Le rapport Draghi recommande la création d'un cadre de coordination de la compétitivité au niveau européen, le doublement du budget de recherche et d'innovation (200 milliards d'euros sur 7 ans), la création d'une agence européenne pour les projets technologiques de rupture, et la mise en place de plans nationaux de recherche coordonnés. La France, empêtrée dans ses crises budgétaires successives, n'a pris aucune de ces orientations au sérieux.

Le CNLL (Conseil National du Logiciel Libre) a relevé que le rapport Draghi, malgré son diagnostic, ne va pas assez loin dans ses recommandations sur le logiciel libre et les solutions européennes à 100%. C'est vrai. Mais même les recommandations insuffisantes du rapport ne sont pas appliquées. Le rapport recommande une préférence pour les solutions locales dans les marchés publics sensibles. La doctrine française du « cloud de confiance » fait exactement l'inverse en qualifiant SecNumCloud des offres reposant à 100% sur de la technologie américaine.

Partie IV : Les défaillances systémiques

4.1 Des dirigeants qui ne comprennent pas ce qu'ils achètent

Le problème n'est pas seulement stratégique. Il est intellectuel. Les décideurs qui choisissent S3NS ou Bleu ne comprennent généralement pas ce que signifie dépendre d'un code source étranger. Ils voient « Thales » et pensent « souveraineté ». Ils voient « SecNumCloud » et pensent « protection ». Ils voient « Google Cloud » et pensent « performance ». Le syllogisme leur paraît imparable : performance + souveraineté = S3NS.

Cette équation est fausse parce qu'elle repose sur une confusion entre le contenant (l'infrastructure, le datacenter, les clés de chiffrement) et le contenu (le code, les algorithmes, la logique métier des services cloud). Maîtriser le contenant sans maîtriser le contenu, c'est posséder un coffre-fort dont quelqu'un d'autre contrôle la serrure.

Un DSI d'un grand groupe français qui choisit S3NS parce que c'est « du Google avec Thales » fait exactement le même raisonnement qu'un directeur des achats qui achèterait une voiture dont le moteur, la boîte de vitesses et l'électronique seraient propriété du fabricant étranger, en se félicitant de la nationalité française du concessionnaire. Si le fabricant décide de ne plus fournir les pièces de rechange, la voiture s'arrête. C'est exactement ce qu'a dit Guillaume Poupard devant le Sénat.

4.2 L'ANSSI : gardien du temple ou caution technique ?

L'ANSSI est prise dans une contradiction structurelle. Son rôle est d'évaluer la sécurité technique des offres cloud selon un référentiel objectif. Ce rôle, elle le remplit avec compétence et rigueur. Les 1 200 exigences de SecNumCloud 3.2 constituent un corpus de sécurité exigeant.

Mais en qualifiant SecNumCloud des offres reposant intégralement sur de la technologie américaine, l'ANSSI fournit involontairement une caution qui est interprétée par le marché, par les décideurs politiques et par les médias comme une validation de la souveraineté de ces offres. Le directeur de l'ANSSI a beau répéter que SecNumCloud n'est pas un label de souveraineté, le marché l'utilise comme tel.

Cette ambiguïté est exploitée de manière systématique par les équipes commerciales de S3NS et Bleu. « Qualifié SecNumCloud par l'ANSSI » est l'argument central de vente. Pour les acheteurs publics, cette qualification est souvent la seule condition vérifiée. La distinction entre sécurité technique et souveraineté stratégique est perdue dans la traduction commerciale.

L'ANSSI devrait, au minimum, exiger que toute communication commerciale utilisant la qualification SecNumCloud pour des offres reposant sur de la technologie extra-européenne comporte un avertissement explicite sur les risques de dépendance technologique et sur les limites de la qualification en matière de protection contre les lois extraterritoriales. Ce serait l'équivalent numérique de l'avertissement sanitaire sur les paquets de cigarettes.

4.3 FISA 702 : le biais de conformité des grands cabinets de conseil

Il y a une défaillance d'incitations rarement analysée dans la chaîne de décision cloud : le conflit d'intérêts structurel des grands cabinets de conseil. Deloitte, Accenture, McKinsey vendent aux entreprises et aux administrations françaises des « frameworks de souveraineté cloud » et des « évaluations de maturité souveraine », tout en étant partenaires certifiés de Microsoft, Google et AWS. Ce double positionnement crée une incitation structurelle à recommander les solutions des hyperscalers, dont l'intégration génère davantage de prestations facturables que les alternatives européennes. Ce n'est pas un problème de personnes. C'est un conflit d'intérêts inscrit dans le modèle économique du secteur.

Le cadre juridique américain crée un risque documenté. La section 702 du FISA, prorogée en avril 2024 par la loi RISAA (Reforming Intelligence and Securing America Act, Pub. L. 118-49 [^1]) jusqu'au 20 avril 2026 [^4], autorise les agences de renseignement américaines (NSA, CIA, FBI) à collecter, sans mandat, les communications électroniques de toute personne non américaine située hors des États-Unis. Henri d'Agrain, délégué général du Cigref, rappelle que cette section « autorise les agences de renseignement américaines à collecter sans mandat et de façon massive les données numériques des personnes non américaines ». Le sénateur républicain John Cornyn a reconnu que « 60% du daily brief que recevait le président Biden était composé de renseignements collectés grâce à la section 702 ».

Mais le RISAA est allé plus loin que le simple renouvellement. La loi a élargi la définition de « fournisseur de services de communications électroniques » (ECSP) pour inclure désormais tout prestataire « ayant accès à des équipements qui sont ou pourraient être utilisés pour transmettre ou stocker des communications électroniques ». L'Electronic Frontier Foundation a qualifié cette extension de « l'une des expansions les plus dramatiques et terrifiantes de l'autorité de surveillance gouvernementale de l'histoire ». En pratique, la portée exacte de cette définition élargie fait l'objet d'un débat juridique non tranché (cf. Congressional Research Service, rapport R48592 [^4]). Mais la lecture la plus large couvrirait potentiellement les datacenters, les opérateurs d'hébergement, les fournisseurs de services managés, et même les prestataires ayant un accès physique aux infrastructures. C'est cette incertitude même qui constitue un risque : en matière de protection des données stratégiques, un doute juridique non résolu devrait appeler la prudence.

Le député Philippe Latombe a alerté sur les conséquences directes pour la France : « Sont donc concernées en France Equinix, Data4 et DRT/Interxion, qui sont régies par le droit états-unien. » Si les opérateurs de datacenters eux-mêmes tombent potentiellement sous le coup du FISA élargi, le montage juridique de S3NS et Bleu mérite un examen plus rigoureux que celui dont il fait l'objet dans le débat public. La littérature juridique n'est pas tranchée sur la portée exacte de la définition élargie d'ECSP, et c'est précisément le problème : un risque juridique non tranché devrait appeler la prudence, pas la confiance.

Et pourtant, Deloitte continue de vendre ses prestations de « conseil en souveraineté numérique ». Sur son propre site, le cabinet affirme vouloir « concilier souveraineté, innovation et performance en adoptant des solutions de confiance ». Il propose des « évaluations de maturité souveraine » et des « architectures souveraines et résilientes dans le cloud ». Didier Descombes, associé Deloitte France, parle d'« envisager cette souveraineté du cloud comme un véritable chemin vers la résilience et l'adaptabilité ».

Traduisons en termes d'incitations : ces cabinets facturent des missions de conseil à des organisations publiques et privées pour les aider à migrer vers des solutions dont le risque juridique extraterritorial reste entier. Le conflit d'intérêts est structurel : recommander des solutions souveraines européennes comme OVHcloud ou Scaleway, c'est recommander des écosystèmes qui n'ont pas besoin d'une armée de consultants pour fonctionner. L'incitation économique pousse à la complexité, pas à la souveraineté.

La CJUE a été explicite dans son arrêt Schrems II (2020, C-311/18) : « L'article 702 du FISA ne fait ressortir d'aucune manière l'existence de limitations à l'habilitation qu'il comporte pour la mise en oeuvre des programmes de surveillance aux fins du renseignement extérieur, pas plus que l'existence de garanties pour des personnes non-américaines potentiellement visées par ces programmes. » Cette décision a invalidé le Privacy Shield. Le Data Privacy Framework qui l'a remplacé repose sur un executive order de Biden (EO 14086) qui est révocable par décret présidentiel — un mécanisme juridiquement fragile pour fonder la protection de données stratégiques européennes.

Un cabinet de conseil qui recommande en 2026 de confier les données sensibles d'un OIV français à une plateforme reposant intégralement sur du code Microsoft ou Google le fait dans un contexte juridique documenté. Le FISA 702, le CLOUD Act, l'EAR, l'arrêt Schrems II : toute la documentation est publique, toute la jurisprudence est accessible. L'enjeu n'est pas de juger les intentions mais de constater une défaillance dans la prise en compte du risque : le système d'incitations (partenariats certifiés, volume de prestations d'intégration, conformité perçue) pousse à minimiser un risque juridique que les textes rendent pourtant tangible.

4.4 L'illusion de l'audit sur code fermé : ce que l'ANSSI ne peut pas faire

Venons-en à l'éléphant dans la pièce. Le référentiel SecNumCloud 3.2, dans ses plus de 360 points d'exigences répartis sur 14 thématiques, prévoit un « contrôle du code source des fonctionnalités de sécurité implémentées ». C'est écrit noir sur blanc. Mais cette exigence se heurte à une impossibilité pratique fondamentale quand le code source en question appartient à Google ou Microsoft.

L'ANSSI n'a tout simplement pas la capacité d'auditer en profondeur le code source de Google Cloud Platform ou de Microsoft Azure. Ce code représente des centaines de millions de lignes, développées par des dizaines de milliers d'ingénieurs, mises à jour en continu, et protégées par des accords de propriété intellectuelle draconiens. Le site Next INpact l'a relevé avec une ironie justifiée : « Si vous vous attendiez à voir l'ANSSI imposer des règles en matière de revue du code source ou des mises à jour, [...] l'idée de mettre du gros sel autour du datacenter pour éloigner les services de renseignement étrangers n'a pas non plus été retenue. »

Concrètement, l'audit SecNumCloud de S3NS ou Bleu porte sur la couche opérationnelle française : les procédures de gestion des clés, le cloisonnement des accès, la traçabilité des opérations, les processus de validation des mises à jour. C'est un travail sérieux et nécessaire. Mais le code qui s'exécute effectivement sur les serveurs, le code qui traite les données, le code qui gère les requêtes, le code qui implémente les algorithmes de chiffrement côté serveur, ce code reste une boîte noire. Thales réceptionne les mises à jour de Google dans un « sas de sécurité ». Elle les « évalue et valide ». Mais évaluer et valider un binaire compilé ou même un code source de plusieurs millions de lignes sans en comprendre l'intégralité de la logique interne, c'est comme faire passer un contrôle technique automobile en vérifiant la peinture et les pneus sans ouvrir le capot.

La qualification SecNumCloud exige que les audits soient réalisés par un PASSI (prestataire d'audit de la sécurité des systèmes d'information) qualifié par l'ANSSI. Ces prestataires sont compétents. Mais leur mandat se limite au périmètre du service qualifié, c'est-à-dire à la couche opérée par l'entité française. Le code sous-jacent de Google ou Microsoft n'est pas dans leur périmètre d'évaluation. Personne ne l'audite. L'ANSSI ne l'audite pas. Thales ne l'audite pas. Et les équipes de sécurité de Google ou Microsoft ne rendent pas de comptes à l'ANSSI.

Affirmer qu'un label de sécurité national garantit la fiabilité d'un service dont la grande majorité du code échappe au contrôle du certificateur pose un problème de cohérence. C'est comme si la Direction Générale de l'Armement certifiait un missile dont elle n'a le droit d'examiner que le système de guidage, sans accès au moteur, à la charge, ni à l'électronique de bord.

4.5 Les vulnérabilités critiques Dell : la fragilité de la chaîne d'audit

Si l'on avait encore des doutes sur la capacité des processus d'audit existants à détecter les vulnérabilités enfouies dans du matériel et du logiciel propriétaire, les révélations de 2025-2026 sur les failles Dell viennent les dissiper définitivement.

En février 2026, Mandiant et le Google Threat Intelligence Group (GTIG) ont révélé l'exploitation active, depuis au moins mi-2024, d'une vulnérabilité critique dans Dell RecoverPoint for Virtual Machines (CVE-2026-22769, score CVSS 10.0 sur 10 [^5]). La nature de la faille est révélatrice : des identifiants codés en dur (hardcoded credentials) dans la configuration Apache Tomcat du produit. Un mot de passe administrateur en clair dans un fichier de configuration. Sur un outil de sauvegarde et de reprise d'activité — le dernier rempart des organisations contre les cyberattaques.

Le groupe UNC6201, attribué à la sphère d'influence chinoise (PRC-nexus), a exploité cette faille pendant plus de 18 mois sans que personne ne la détecte. Les attaquants ont déployé successivement les malwares SLAYSTYLE, BRICKSTORM, puis GRIMBOLT (un implant compilé en C# avec Native AOT et compressé UPX pour échapper aux analyses). Ils ont créé des « Ghost NICs » sur les serveurs VMware ESXi pour se déplacer latéralement dans les réseaux sans être repérés. La CISA a ajouté cette vulnérabilité à son catalogue des vulnérabilités activement exploitées.

En parallèle, en août 2025, les chercheurs de Cisco Talos ont découvert les vulnérabilités « ReVault » dans le firmware Dell ControlVault3, affectant plus de 100 modèles de laptops Dell, « massivement utilisés dans les administrations et les entreprises de cybersécurité ». Ces failles permettent de modifier de manière permanente le firmware, créant des compromissions persistantes qui survivent à la réinstallation complète de Windows. En octobre 2025, Dell Storage Manager a révélé trois vulnérabilités supplémentaires (dont CVE-2025-43995, CVSS 9.8) permettant un contournement d'authentification à distance sur les systèmes de stockage d'entreprise. En novembre 2025, une faille critique dans Dell Display and Peripherals Manager (CVE-2025-46430) a mis en danger des millions de postes.

Et ce sont des produits Dell, un fournisseur dont les équipements peuplent les datacenters de S3NS et Bleu, les salles serveurs des OIV, les postes de travail des administrations françaises. Dell, qui passe les mêmes processus de certification et d'audit que tous les sous-traitants de la chaîne cloud. Dell, dont les produits sont déployés après avoir été « évalués » et « validés » par les processus de conformité des grandes organisations.

Si des identifiants codés en dur dans un fichier de configuration peuvent rester exploités pendant 18 mois par un acteur étatique sans qu'aucun audit ne le détecte, que reste-t-il de la promesse que le « sas de sécurité piloté par Thales » détectera une compromission supply-chain dans les centaines de millions de lignes de code de Google Cloud Platform ?

La chaîne de confiance est un concept séduisant sur un PowerPoint. Dans la réalité, elle est aussi solide que son maillon le plus faible. Et l'affaire Dell démontre que les maillons faibles prolifèrent dans du matériel et du logiciel que tout le monde considérait comme « audité » et « certifié ». L'ANSSI qualifie la couche opérationnelle de S3NS. Qui qualifie le firmware Dell des serveurs ? Qui audite le microcode Intel des processeurs ? Qui vérifie l'intégrité des bibliothèques open source intégrées dans les mises à jour de Google ? Personne. Et c'est sur cette base que la France confie les données de la Banque de France et d'EDF.

4.6 Le syndrome Cloudwatt : l'histoire ne sert à rien

En 2012, la France avait déjà tenté de créer un « cloud souverain ». Cloudwatt (porté par Orange et Thales) et Numergy (porté par SFR et Bull) avaient reçu un financement public de 150 millions d'euros (programme d'investissements d'avenir, annonce Arnaud Montebourg/Fleur Pellerin, 2012). Les deux projets se sont soldés par des échecs retentissants. Cloudwatt a été absorbé par Orange avant d'être discrètement enterré. Numergy a été liquidé.

L'échec ne tenait pas à l'idée de souveraineté. Il tenait à l'exécution : sous-investissement chronique, absence de vision produit, incapacité à attirer les talents, et surtout absence de volonté politique de favoriser ces solutions dans la commande publique.

Dix ans plus tard, au lieu de tirer les leçons de cet échec en construisant des solutions véritablement européennes avec les moyens adéquats, la France a choisi une voie encore plus problématique : confier la construction du « cloud souverain » aux mêmes acteurs américains dont elle prétend s'émanciper. C'est comme si, après l'échec d'une politique d'indépendance énergétique, la France avait décidé de confier la gestion de ses centrales nucléaires à ExxonMobil en se félicitant que le badge d'accès soit délivré par EDF.

4.7 Gouvernance numérique : le biais de sélection comme défaillance systémique

Il y a une question de processus que personne n'ose poser publiquement : le système de nomination politique français sélectionne-t-il des profils capables d'engager des stratégies crédibles sur la souveraineté numérique ?

Le portefeuille du numérique a été confié depuis 2017 à des profils dont l'expertise est managériale ou entrepreneuriale, sans expérience en infrastructure, en cryptographie ou en architecture de sécurité. Mounir Mahjoubi (entrepreneur dans l'événementiel), Cédric O (banquier chez Lazard), Marina Ferrari (rapport parlementaire sur le tourisme en stations de ski), Clara Chappaz (ESSEC, MBA Harvard, Vestiaire Collective, Mission French Tech). Ce n'est pas un reproche individuel : c'est un biais de sélection systémique qui produit une asymétrie d'information entre décideurs politiques et enjeux techniques.

Le cas Chappaz illustre cette asymétrie. Nommée secrétaire d'État en septembre 2024 puis ministre déléguée en décembre 2024, elle quitte ses fonctions en octobre 2025. Sa principale mesure en matière de souveraineté cloud : un appel à projets en avril 2025 doté de « plusieurs dizaines de millions d'euros ». Quelques dizaines de millions, quand Amazon investit 73 milliards d'euros par an en R&D (rapport annuel Amazon 2024, « Technology and infrastructure ») et que le rapport Draghi appelle à 800 milliards annuels. Le décalage des ordres de grandeur n'est pas une question de volonté personnelle. C'est le produit d'un système qui ne donne ni les moyens ni la compétence technique à ses décideurs.

Libération a par ailleurs rapporté en juin 2025 que Clara Chappaz détenait 320 000 euros de participations dans des entreprises cotées du numérique — Amazon, Microsoft, Nvidia — alors qu'elle était en charge du portefeuille (Libération, « Chappaz : des intérêts dans les géants du numérique qu'elle est censée réguler », juin 2025). Son entourage a invoqué une gestion en assurance-vie. L'argument est juridiquement recevable. Il illustre néanmoins un problème d'incitations : le système ne prévoit pas de mécanisme de déport contraignant pour les participations sectorielles des ministres du numérique.

À l'inverse, quand un esprit scientifique de premier plan s'approche du sujet, les incitations du système politique le marginalisent. Cédric Villani, médaillé Fields, auteur du rapport sur l'IA en 2018, l'un des rares documents de politique numérique française rédigé par quelqu'un qui comprend la technologie sous-jacente, a progressivement quitté la vie politique. L'incitation systémique favorise les profils de communication sur les profils techniques.

4.8 Le biais de conformité transatlantique : Young Leaders et socialisation des élites

Le phénomène dépasse le biais de sélection individuel. Il relève d'un biais de conformité produit par la socialisation des élites dirigeantes dans des réseaux transatlantiques.

La French-American Foundation, fondée en 1976 « sous les auspices des présidents Ford et Giscard d'Estaing », sélectionne chaque année une vingtaine de jeunes dirigeants français et américains pour des séminaires de cinq jours, alternativement en France et aux États-Unis. Wikipedia la décrit sans ambages comme « un des instruments du soft power américain ». Plus de 600 alumni en sont issus depuis 1981.

La liste des Young Leaders français est un annuaire du pouvoir : Emmanuel Macron (2012), François Hollande (1996), Alain Juppé (1981), Édouard Philippe (2011), Pierre Moscovici (1996), Najat Vallaud-Belkacem (2006), Arnaud Montebourg (2000), Fleur Pellerin (2012), Laurent Wauquiez (2006). Côté américain : Bill Clinton, Hillary Clinton, Antony Blinken. Quatre présidents de la République ou premiers ministres français consécutifs sont passés par ce programme.

L'ironie : Cédric Villani lui-même est un Young Leader (promotion 2012-2013, la même que Macron). Mais contrairement aux profils politiques et financiers qui prospèrent dans ce réseau, le mathématicien s'est heurté à un système dont les incitations ne valorisent pas la rigueur technique quand elle contredit le consensus transatlantique.

Ce réseau ne constitue pas un « complot » au sens conspirationniste du terme. Il n'en a pas besoin. Son efficacité repose sur un mécanisme bien documenté par la sociologie des élites : la socialisation. Quand les décideurs passent leurs années formatrices dans des séminaires dont l'objectif explicite est de « renforcer les liens entre la France et les États-Unis », quand ils tissent des liens personnels avec des homologues américains, quand leur carrière bénéficie de l'appartenance à ce réseau, ils développent un biais de conformité qui les conduit à percevoir la dépendance technologique envers les États-Unis comme un état normal plutôt que comme un risque à gérer. C'est un biais cognitif, pas une instruction.

Dans ce contexte, la politique française de cloud de confiance devient intelligible : les décideurs qui la conçoivent n'ont pas été formés pour percevoir la dépendance technologique américaine comme un problème. Leur formation, leurs réseaux, leurs références intellectuelles les orientent vers une vision du monde où l'alliance technologique américaine est le cadre naturel de la politique française.

C'est ce biais de socialisation qui rend possible l'incohérence de la situation actuelle : un État qui prétend défendre sa souveraineté numérique en la confiant aux entreprises d'un pays dont les lois de surveillance (FISA 702, CLOUD Act, EAR) sont conçues pour accéder aux données des non-Américains. L'incohérence n'est pas un accident. C'est le produit d'un système d'incitations.

4.9 Stuxnet, SolarWinds, Dell : les précédents de compromission supply-chain

Il existe un argument structurel contre la croyance que les mises à jour logicielles peuvent être efficacement contrôlées par un « sas de sécurité » : les États et les acteurs malveillants savent compromettre les chaînes logicielles, et ils le font.

Stuxnet, découvert en 2010, reste la démonstration la plus spectaculaire. Ce ver, développé conjointement par les États-Unis et Israël dans le cadre de l'opération Olympic Games, a été conçu pour saboter les centrifugeuses d'enrichissement d'uranium de la centrale iranienne de Natanz. Le virus s'est propagé via des clés USB, a exploité quatre vulnérabilités zero-day de Windows, puis est resté dormant dans les systèmes Siemens en attendant de trouver sa cible spécifique. Une fois activé, il a modifié les paramètres de rotation des centrifugeuses tout en envoyant des données de fonctionnement normal aux opérateurs. L'ancien directeur de la NSA, Michael Hayden, a déclaré que Stuxnet avait « franchi le Rubicon » de la guerre cybernétique.

La leçon de Stuxnet pour la souveraineté numérique européenne est limpide : un État qui contrôle la technologie peut implanter du code malveillant dormant dans n'importe quel système, et ce code peut rester indétecté pendant des mois ou des années, y compris dans des environnements « isolés » et « audités ». Les ingénieurs iraniens n'ont jamais vu le sabotage arriver, malgré leurs propres contrôles de sécurité.

SolarWinds, en 2020, a confirmé que cette capacité n'était pas un cas isolé. Des hackers (attribués à la Russie) ont compromis une mise à jour du logiciel Orion, utilisé par des milliers d'entreprises et d'agences gouvernementales américaines. Le code malveillant a été distribué automatiquement, via le processus normal de mise à jour, signé avec les certificats légitimes de SolarWinds. Pendant des mois, des gouvernements et des entreprises du Fortune 500 ont exécuté du code compromis en toute confiance parce qu'il portait la signature du fournisseur.

Et en 2024, la compromission XZ Utils (CVE-2024-3094) a démontré que même l'open source n'est pas immunisé : un contributeur malveillant a patiemment infiltré le projet pendant deux ans avant d'insérer une porte dérobée dans une bibliothèque de compression utilisée par la quasi-totalité des distributions Linux.

Transposons ces précédents au cas de S3NS et Bleu. Google Cloud Platform et Microsoft Azure représentent des centaines de millions de lignes de code, compilées et distribuées par des entreprises soumises au droit américain, dans un pays dont les agences de renseignement ont démontré leur capacité et leur volonté d'utiliser les chaînes logicielles comme vecteurs d'attaque. Le « sas de sécurité piloté par Thales » réceptionne les mises à jour de Google. Mais si Stuxnet a pu se cacher dans du code Siemens pendant des mois sous les yeux d'ingénieurs nucléaires, si SolarWinds a pu distribuer du code compromis signé avec ses propres certificats, si un contributeur unique a pu empoisonner XZ Utils pendant deux ans, quel degré de confiance peut-on raisonnablement accorder à la capacité de 100 ingénieurs de Thales à détecter une compromission supply-chain dans le code de Google Cloud ?

On ne parle pas ici de compromissions intentionnelles de Google : on parle d'un risque structurel lié à toute chaîne logicielle opaque et extraterritoriale. La question n'est pas de savoir si Google est de bonne foi. La question est de savoir si un processus d'audit peut garantir l'intégrité de centaines de millions de lignes de code propriétaire face à des menaces étatiques sophistiquées. Les précédents répondent : non.

Partie V : Ce qu'il faudrait faire

5.1 Une politique industrielle digne de ce nom

La France et l'Europe disposent des compétences, des marchés et des capitaux nécessaires pour construire un écosystème cloud souverain. OVHcloud est le premier hébergeur européen. Scaleway investit dans le GPU et l'IA. L'open source européen (Nextcloud, collabora, etc.) offre des alternatives fonctionnelles à Microsoft 365. Le manque n'est pas technique, il est politique.

Un programme structurant supposerait la commande publique massive orientée vers les solutions européennes qualifiées SecNumCloud sans technologie extra-européenne, un fonds d'investissement dédié de 5 milliards d'euros sur 10 ans pour le scaling des acteurs européens du cloud, un programme de formation de 10 000 ingénieurs cloud par an, la création d'un consortium européen de cloud souverain sur le modèle d'Airbus pour l'aéronautique, et une législation européenne imposant la réciprocité d'accès aux marchés publics.

5.2 L'exemple de ce qui marche

L'Europe a démontré sa capacité à construire des champions industriels quand la volonté politique est au rendez-vous. Airbus n'existait pas en 1970 ; c'est aujourd'hui le premier constructeur aéronautique mondial. Ariane Espace a assuré l'accès autonome de l'Europe à l'espace pendant quatre décennies. Le programme Galileo offre un système de navigation satellitaire indépendant du GPS américain.

Dans chacun de ces cas, la réussite a supposé un investissement initial massif, une commande publique orientée, une coopération européenne structurée, et l'acceptation d'un surcoût temporaire par rapport aux solutions américaines existantes. C'est exactement ce qu'il faudrait faire pour le cloud.

L'argument selon lequel « le cloud, c'est différent, les Américains ont trop d'avance » est une prophétie autoréalisatrice. En 1970, Boeing avait aussi trop d'avance sur l'industrie aéronautique européenne. L'avance n'est pas une fatalité quand on décide de la combler.

Partie VI : Le rapport Draghi contre la doctrine française

6.1 Deux visions irréconciliables

Le rapport Draghi porte une vision claire : l'Europe doit reconstruire sa base industrielle numérique pour retrouver sa compétitivité et son autonomie stratégique. Cette reconstruction passe par des investissements massifs, une préférence pour les solutions européennes, et une coordination industrielle inédite. Mario Draghi chiffre le besoin : 750 à 800 milliards d'euros par an, soit 4,4 à 4,7% du PIB européen (rapport Draghi, « The Future of European Competitiveness », Commission européenne, septembre 2024, p. 2).

La doctrine française du « cloud de confiance » porte la vision inverse : puisque le retard est trop important, autant s'accommoder de la domination américaine en y ajoutant une couche de conformité. C'est l'exact équivalent de la position de ceux qui, en 1970, affirmaient qu'il était inutile de construire Airbus puisque Boeing dominait le marché.

Cette divergence n'est pas anecdotique. Elle structure deux trajectoires radicalement différentes pour l'Europe numérique. La trajectoire Draghi suppose l'effort, l'investissement, le risque, mais elle mène potentiellement à l'autonomie. La trajectoire « cloud de confiance » suppose la facilité, le court-termisme, le confort, et elle mène certainement à l'enfermement dans une dépendance croissante.

6.2 Le piège du BABE

Certains commentateurs, comme le Centre for European Policy Studies, préconisent une approche « BABE » : Buy American, Build European. Acheter américain aujourd'hui pour ne pas paralyser les économies, tout en investissant pour construire des alternatives européennes demain.

C'est un raisonnement séduisant mais dangereux. Il suppose que le « Build European » sera effectivement engagé avec des moyens suffisants et une volonté politique soutenue. Or, l'histoire montre exactement l'inverse : le « Buy American » absorbe les budgets, crée des dépendances organisationnelles (formations, certifications, intégrations), et réduit progressivement l'incitation à investir dans des alternatives.

Chaque organisation qui migre vers S3NS ou Bleu forme ses équipes sur Google Cloud ou Azure, intègre les API propriétaires de Google ou Microsoft dans ses applications, et crée des coûts de sortie (switching costs) qui rendent la migration future vers une solution européenne de plus en plus improbable. Le « Build European » est repoussé indéfiniment parce que le « Buy American » crée sa propre inertie.

Conclusion : sortir de l'illusion du meilleur des mondes

Le constat est implacable

La France, à travers une combinaison de biais de sélection dans les nominations, de biais de conformité dans le conseil, de capture par la dépendance de sentier dans la commande publique, et de biais de socialisation transatlantique dans la formation de ses élites, est en train d'institutionnaliser sa dépendance technologique envers les États-Unis. Les offres S3NS et Bleu ne sont pas des solutions de souveraineté. Ce sont des solutions de confort qui permettent aux décideurs de cocher la case « conformité » sans résoudre le problème structurel.

Ces solutions coûteront plus cher que les offres natives des hyperscalers, sans offrir de protection réelle contre l'extraterritorialité du droit américain, que le FISA 702 élargi par le RISAA en avril 2024 a encore renforcée [^1]. Elles reposent sur du code fermé que personne en France n'audite réellement (environ 85% du code échappe au périmètre SecNumCloud), dans un écosystème matériel dont les vulnérabilités Dell de 2025-2026 ont démontré la fragilité systémique [^5]. Elles créeront un verrouillage technologique qui rendra les alternatives européennes de plus en plus difficiles à construire. Et elles contredisent frontalement les recommandations du rapport Draghi.

Le conflit d'intérêts structurel des cabinets de conseil, qui recommandent ces solutions tout en étant partenaires certifiés des hyperscalers, constitue une défaillance d'incitations qui biaise l'ensemble du processus de décision. L'ANSSI, en qualifiant SecNumCloud des offres dont elle ne peut auditer que la couche opérationnelle française, entretient une confusion entre sécurité opérationnelle et souveraineté stratégique. Et le processus d'audit lui-même, comme l'ont démontré les précédents Stuxnet, SolarWinds, XZ Utils et Dell, ne peut structurellement pas garantir l'intégrité de chaînes logicielles opaques et extraterritoriales.

Ce que la France doit à ses citoyens

La souveraineté numérique n'est pas un concept abstrait. C'est la capacité concrète d'un État à garantir que ses données stratégiques, ses infrastructures critiques et ses services essentiels ne peuvent pas être coupés, surveillés ou manipulés par une puissance étrangère. Cette garantie, ni S3NS ni Bleu ne peuvent l'offrir. Seules des solutions fondées sur du code européen, opérées par des entités européennes, et financées par une volonté politique européenne, peuvent y prétendre.

Le choix n'est pas entre Google et le retour au Minitel. Le choix est entre le courage d'investir dans l'avenir et le confort de s'enfermer dans une dépendance dorée. La France a su construire Airbus, Ariane, Galileo, un parc nucléaire de 56 réacteurs. Elle peut construire un cloud souverain. Il suffit de le vouloir, de le financer, et de cesser de présenter de la technologie américaine sous emballage tricolore comme une réponse à la souveraineté numérique.

La vraie question n'est pas technique. Elle est politique. Et la réponse que la France apporte aujourd'hui à cette question n'est pas à la hauteur de ses ambitions affichées.

Encadré épistémique : ce que cet article considère prouvé, probable et spéculatif

PROUVÉ (sources primaires vérifiables) : dépendance technologique à 100% de S3NS/Bleu envers le code US ; RISAA signée le 20 avril 2024 (Pub. L. 118-49) [^1] ; CVE-2026-22769 CVSS 10.0, exploitation confirmée depuis mi-2024 (Mandiant/GTIG) [^5] ; arrêt Schrems II (CJUE C-311/18) ; surcoût de >30% du cloud souverain T-Systems en Allemagne (grille tarifaire publique) ; part de marché d'environ 70% des trois hyperscalers US en France (Synergy Research Group, Q4 2024) ; couverture SecNumCloud limitée à la couche opérationnelle française (audition Strubel, Sénat, mai 2025 [^2]) ; section 702 expire le 20 avril 2026 (CRS R48592 [^4]) ; CA OVHcloud 993 M EUR 2024 (rapport annuel) ; participations Chappaz dans Amazon/Microsoft/Nvidia — 320 000 EUR (Libération, juin 2025) ; Young Leaders : 4 présidents/PM consécutifs (site FAF, listes publiques).

PROBABLE (convergence d'indices concordants, estimation analytique) : le périmètre auditable représente une fraction minoritaire du code total d'une offre S3NS/Bleu — estimation ~15%, le périmètre exact étant couvert par des accords de confidentialité ; le surcoût des offres de confiance se situe entre 20% et 40% (estimations Markess, déclarations Reisinger, le chiffre exact variant par service) ; les compromissions supply-chain de type Stuxnet/SolarWinds constituent un risque transposable aux mises à jour cloud ; le conflit d'intérêts structurel des cabinets de conseil influence leurs recommandations ; le biais de socialisation transatlantique contribue aux décisions de politique numérique.

SPÉCULATIF (hypothèse non démontrée) : existence actuelle de code dormant dans GCP ou Azure ; intention délibérée des autorités US d'exploiter S3NS/Bleu via la chaîne de mises à jour ; lien de causalité direct entre l'appartenance au réseau Young Leaders et les décisions spécifiques de politique cloud.

Annexe méthodologique

Sources

Cette analyse s'appuie sur les auditions de la commission d'enquête sénatoriale sur la commande publique (mai-juin 2025), le rapport Draghi sur la compétitivité européenne (septembre 2024), les communications officielles de l'ANSSI sur SecNumCloud, l'étude du cabinet Greenberg Traurig commandée par le ministère néerlandais de la Justice, les données de marché de Markess by Exaegis, Synergy Research, Omdia, Xerfi, les communications financières d'OVHcloud, et la couverture presse spécialisée (L'Usine Digitale, LeMagIT, Le Monde Informatique, CIO Online, Next INpact).

S'agissant du FISA 702, les sources incluent le texte de la loi RISAA (Reforming Intelligence and Securing America Act, Pub. L. No. 118-49, avril 2024), le rapport du Congressional Research Service (R48592), les analyses de l'Electronic Frontier Foundation, la question écrite du député Aurélien Saintoul au JO (n°482, octobre 2024, réponse décembre 2025), les déclarations d'Henri d'Agrain (Cigref) au LeMagIT, la question écrite du député Philippe Latombe (Journal Officiel, janvier 2024), et l'arrêt Schrems II de la CJUE (C-311/18, juillet 2020).

Pour les vulnérabilités Dell, les sources comprennent le rapport Mandiant/GTIG sur CVE-2026-22769 (février 2026), l'avis Dell DSA-2025-053 sur ControlVault3 (ReVault, août 2025), les recherches Cisco Talos sur les vulnérabilités firmware, l'avis CISA sur l'ajout au catalogue KEV, les avis Dell sur CVE-2025-43995 (Storage Manager, octobre 2025) et CVE-2025-46430 (DDPM, novembre 2025).

S'agissant du parcours de Clara Chappaz, les sources incluent la fiche officielle du gouvernement (info.gouv.fr), sa page Wikipedia, sa déclaration devant la commission d'enquête sénatoriale (10 juin 2025, Vie Publique), l'article de Libération sur ses participations dans des entreprises du numérique (juin 2025), et les articles de L'Usine Digitale et FrenchWeb. Pour le programme Young Leaders, les sources sont le site officiel de la French-American Foundation, la page Wikipedia de la fondation, et les listes publiées de ses alumni.

Pour les précédents de compromissions supply-chain, les sources comprennent Kim Zetter, « Countdown to Zero Day » (Crown Publishing, 2014) et les révélations du Volkskrant (janvier 2024) pour Stuxnet, le rapport FireEye/Mandiant pour SolarWinds (décembre 2020), l'avis CVE-2024-3094 pour la compromission XZ Utils, et le rapport Symantec « W32.Stuxnet Dossier » (2011).

Limites méthodologiques

Les estimations de surcoût des offres S3NS et Bleu sont fondées sur les déclarations des dirigeants et les comparaisons avec le marché allemand. Les tarifications exactes ne sont pas publiques. Les parts de marché européennes sont des estimations consolidées de plusieurs cabinets d'analyse qui utilisent des périmètres légèrement différents.

L'analyse juridique sur l'applicabilité du CLOUD Act aux offres de type S3NS et Bleu fait l'objet d'un débat entre experts. La position de l'ANSSI et celle du cabinet Greenberg Traurig divergent. Ce débat n'a pas été tranché par une décision de justice. L'incertitude juridique est en soi un argument contre la confiance absolue dans ces montages.

L'estimation selon laquelle l'ANSSI n'audite que 15% environ du code d'une offre S3NS/Bleu est une approximation analytique fondée sur la distinction entre la couche opérationnelle française et le code sous-jacent de Google/Microsoft. Le périmètre exact de l'audit SecNumCloud est couvert par des accords de confidentialité. La proportion réelle peut varier selon les services qualifiés.

S'agissant des vulnérabilités Dell, les durées d'exploitation avant détection sont basées sur les rapports Mandiant/GTIG et Cisco Talos. L'extrapolation de ces cas spécifiques à l'ensemble de la chaîne d'approvisionnement matériel est un raisonnement par analogie qui vise à illustrer un risque systémique, non à prouver une compromission spécifique des infrastructures S3NS ou Bleu.

Annexe : données chiffrées clés

Notes de référence

[^1]: Reforming Intelligence and Securing America Act (RISAA), Pub. L. No. 118-49, H.R. 7888, signée le 20 avril 2024. Texte intégral et historique législatif : congress.gov/bill/118th-congress/house-bill/7888

[^2]: Audition ANSSI au Sénat : Vincent Strubel (DG ANSSI) et Guillaume Poupard (ex-DG ANSSI, Docaposte), Commission d'enquête sénatoriale sur la commande publique, 28 mai 2025. Compte rendu intégral : senat.fr/compte-rendu-commissions/20250526/ce_comm_pub.html. Citations clés : Poupard : « Si demain les fournisseurs de technologies américains décident de ne plus fournir, ces systèmes s'effondreront en jours ou semaines ». Strubel : « Même dans un cloud purement français, vous avez de la technologie américaine ».

[^3]: Audition Clara Chappaz au Sénat, Commission d'enquête sénatoriale sur la commande publique, 10 juin 2025. Constat de la commission : « une dépendance, subie ou entretenue, vis-à-vis d'opérateurs extraeuropéens soumis à des législations extraterritoriales ». Source : vie-publique.fr/discours/299225-clara-chappaz-10062025-souverainete-numerique-francaise-et-europeenne

[^4]: Sunset de la Section 702 en avril 2026 : Congressional Research Service, « FISA Section 702 and the 2024 Reforming Intelligence and Securing America Act », rapport R48592. Synthèse complète du périmètre, des réformes RISAA et des considérations pour le renouvellement : congress.gov/crs-product/R48592

[^5]: CVE-2026-22769 (Dell RecoverPoint for Virtual Machines), score CVSS 10.0/10. Vulnérabilité d'identifiants codés en dur, exploitation confirmée depuis mi-2024 par UNC6201 (nexus Chine). Fiche NVD : nvd.nist.gov/vuln/detail/CVE-2026-22769. Rapport d'exploitation : Google GTIG/Mandiant, « UNC6201 Exploiting Dell RecoverPoint Zero-Day », février 2026.