Hébergement souverain de l'IA en France : le guide d'achat et d'architecture 2026 (SecNumCloud, EUCS, CLOUD Act)

En une phrase : « hébergé en France » ne veut pas dire souverain, une certification européenne ne garantit plus l'immunité au CLOUD Act, et la souveraineté d'un système d'IA se joue d'abord là où personne ne regarde — sur l'inférence.

Ce guide s'adresse aux RSSI, DSI, DPO et dirigeants qui doivent choisir où et comment héberger leurs systèmes d'IA. Il ne traite pas la question « ai-je le droit de transférer mes données hors UE » — c'est l'objet de notre guide sur les transferts hors UE et l'IA générative. Il traite la question amont : comment construire une pile d'IA qui ne pose pas ce problème.

« Souverain » est devenu un argument marketing — voici comment le vérifier

En deux ans, « IA souveraine » et « cloud souverain » sont passés du séminaire stratégique au bandeau publicitaire. Presque chaque éditeur promet un hébergement « en France », « européen » ou « souverain ». Le problème : ces mots n'ont pas la même valeur juridique, et certains n'en ont aucune.

Le point de bascule est venu de l'EUCS, le schéma européen de certification de cybersécurité des services cloud. Ses projets successifs contenaient des exigences de souveraineté — notamment une immunité face aux lois extraterritoriales comme le CLOUD Act américain ou le FISA 702. Ces exigences ont été retirées au fil des révisions : le schéma adopté ne couvre plus que des exigences techniques.

La conséquence est contre-intuitive et décisive : un service peut afficher une certification cloud européenne tout en reposant sur un fournisseur soumis au droit américain. La souveraineté a été évacuée du label et, en France, réintroduite ailleurs — dans la commande publique et la doctrine « Cloud au centre ».

Pour un décideur, la leçon tient en une phrase : un logo de conformité ne remplace pas une vérification.

Pourquoi l'IA est un cas de souveraineté à part

Héberger une base de données en France est un problème connu. Héberger un système d'IA en ajoute trois, propres à cette technologie.

Le flux quitte le périmètre sans qu'on le voie. Un chatbot « hébergé en France » peut appeler par API un modèle exécuté aux États-Unis. La couche applicative est française ; l'inférence ne l'est pas. La souveraineté d'un système d'IA se joue au niveau du modèle qui calcule, pas seulement du serveur qui affiche.

Les prompts sont des données métier sensibles. Ce que vos collaborateurs saisissent dans un assistant — extraits de contrats, code, données RH, tableaux financiers — part vers le modèle. Si ce modèle est opéré sous droit étranger, ces contenus deviennent atteignables par une injonction extraterritoriale, indépendamment de la localisation du stockage.

La réversibilité est plus dure. Migrer une base est pénible ; migrer une pile d'IA — modèle affiné, embeddings, base vectorielle, chaîne RAG — l'est davantage. Le coût de sortie devient un facteur de dépendance, donc de non-souveraineté de fait.

D'où la règle de ce guide : on ne décrète pas la souveraineté d'une IA, on l'architecture et on la prouve, couche par couche.

Les trois niveaux de « souverain » — et ce qu'ils valent

Tous les fournisseurs ne parlent pas de la même chose. Distinguez trois niveaux.

Niveau 1 — Localisation (« hébergé en France / en Europe »). Les serveurs sont sur le sol européen. Nécessaire, très insuffisant : la localisation physique ne protège pas contre une injonction visant la maison mère du fournisseur. Un centre de données à Paris opéré par la filiale d'un groupe américain reste, en droit, atteignable.

Niveau 2 — Certification technique (EUCS, ISO 27001, HDS). Le fournisseur respecte un référentiel de sécurité. Utile pour la robustesse, mais — les critères de souveraineté ayant été retirés de l'EUCS — une certification cloud européenne ne garantit pas l'immunité extraterritoriale.

Niveau 3 — Immunité extraterritoriale (qualification SecNumCloud). Le fournisseur est juridiquement et capitalistiquement à l'abri des lois extraterritoriales : contrôle européen du capital, opérations et support depuis l'UE, protection contre les injonctions étrangères. En France, c'est la qualification SecNumCloud de l'ANSSI qui matérialise ce niveau, via les critères d'immunité introduits par le référentiel 3.2.

Retenez la hiérarchie : localisation < certification technique < qualification SecNumCloud. Pour vos données d'IA les plus sensibles, seul le niveau 3 répond à la question.

Le CADA : les quatre niveaux qui vont conditionner l'achat public de cloud

Le 3 juin 2026, la Commission européenne a présenté sa proposition de règlement Cloud and AI Development Act (CADA), pièce centrale du Tech Sovereignty Package. Le texte fait ce que l'EUCS avait renoncé à faire : il réintroduit un critère de souveraineté opposable. Non plus sous forme de label à obtenir, mais sous forme de condition d'accès à certains marchés publics.

L'article 16 institue un cadre unique à l'échelle de l'Union, organisé en quatre niveaux d'assurance, dont les critères figurent à l'annexe II. Un acheteur public ne choisit plus entre des labels nationaux hétérogènes : il détermine un niveau, et achète en conséquence.

> Attention à la numérotation. Les quatre niveaux d'assurance du CADA ne sont pas les trois niveaux de la section précédente. Les nôtres décrivent ce que vaut une promesse commerciale ; ceux du CADA forment une échelle réglementaire d'achat public. Repère : le niveau d'assurance 1 recouvre notre niveau 1 (localisation), et les niveaux d'assurance 3 et 4 recouvrent ce que SecNumCloud matérialise déjà en France.

Niveau d'assurance 1 — Traitement et stockage des données dans une infrastructure située dans l'Union.

Niveau d'assurance 2 — Indépendance démontrée à l'égard d'un pays tiers, et transparence sur la chaîne d'approvisionnement logicielle.

Niveau d'assurance 3 — Détention et contrôle européens du fournisseur, avec des critères portant notamment sur le personnel. La Commission peut y reconnaître des fournisseurs de pays tiers, sous conditions.

Niveau d'assurance 4 — Transparence et contrôle complets sur la chaîne d'approvisionnement logicielle, sans ingérence d'un pays tiers — et sans dérogation possible.

Le niveau 4 est exactement le critère d'imperméabilité aux lois extraterritoriales que l'EUCS avait abandonné en 2024. Il revient par la porte de l'achat public.

Deux articles décrivent la mécanique concrète.

L'article 29 impose aux États membres et aux institutions de l'Union une analyse de risque périodique, destinée à identifier les activités publiques qui touchent à la préservation de l'ordre public, et à déterminer le niveau d'assurance requis pour chacune.

L'article 30(2) prévoit que les organismes publics dont les activités ne sont pas identifiées comme relevant de l'ordre public utilisent des services cloud reconnus au niveau d'assurance 1. Le niveau 1 devient donc le plancher de tout achat public de cloud.

Quatre précisions, parce qu'elles changent la portée du texte.

D'abord, le champ — plus large qu'il n'y paraît. Le cadre vise les autorités exerçant des responsabilités en matière d'ordre public, de sécurité nationale, de sécurité intérieure, de gestion des frontières extérieures, de défense, de justice et d'application de la loi. Mais il vise aussi les entités relevant des annexes I et II de la directive NIS 2 — énergie, transports, santé, eau, infrastructures numériques. Ce n'est pas toute la commande publique européenne ; ce n'est pas non plus le seul régalien.

Ensuite, la soupape. L'article 30(4) permet d'écarter l'obligation de niveau supérieur lorsqu'aucun service adéquat n'existe, ou lorsque le coût serait disproportionné. C'est cette disposition qui déterminera si le texte mord réellement.

Puis, le statut. Le CADA est une proposition de règlement, pas un texte en vigueur. Il doit encore passer par la procédure législative ordinaire. Le calendrier réaliste d'application se compte en années, pas en mois.

Enfin, la conséquence opérationnelle — la seule qui compte pour une DSI aujourd'hui. Avant de pouvoir acheter au bon niveau, une administration doit être capable de dire quels systèmes elle exploite, lesquels reposent sur un service cloud externe, et lesquels touchent à l'ordre public. C'est un travail d'inventaire et de classement, pas un travail d'achat. Les organisations qui ne tiennent pas ce registre aujourd'hui découvriront le sujet au moment où l'article 29 leur demandera de produire l'analyse.

Dernière révision de cette section : 19 août 2026.

SecNumCloud : ce que c'est, ce que ça vous impose

La qualification SecNumCloud est délivrée par l'ANSSI. Elle atteste qu'une offre cloud satisfait des exigences de sécurité et de protection contre le droit extraterritorial. Depuis la doctrine « Cloud au centre » — circulaire de 2021, renforcée en 2023 et reprise dans la loi SREN du 21 mai 2024 — l'hébergement des données sensibles des administrations sur une offre qualifiée est obligatoire. Ce qui était une norme du secteur public devient le standard de référence que les acheteurs privés exigent à leur tour.

À l'été 2026, une dizaine d'offres sont qualifiées, parmi lesquelles des acteurs comme Outscale, OVHcloud, Oodrive, Cloud Temple, Worldline, Orange Business et S3NS. La liste évolue, et la seule source qui fait foi est le catalogue officiel de l'ANSSI sur cyber.gouv.fr. Ne vous fiez jamais à la mention « SecNumCloud » sur une plaquette : vérifiez le périmètre exact qualifié — une offre peut l'être pour un service et pas pour un autre — et la date de validité.

Côté achat, cela impose une règle simple : pour tout traitement d'IA portant sur des données sensibles, exiger un hébergement qualifié, ou une justification écrite de l'écart avec ses mesures compensatoires. C'est exactement l'arbitrage que votre registre des usages d'IA doit tracer.

Les trois pièges de la « souveraineté washing »

Piège 1 — « Certifié européen ». Une certification atteste d'un niveau de cybersécurité, pas d'une immunité au CLOUD Act. Question à poser : « Votre offre est-elle qualifiée SecNumCloud, ou seulement certifiée EUCS / ISO 27001 ? »

Piège 2 — « Partenaire d'un acteur français ». Certaines offres associent un fournisseur américain à un partenaire français. L'hébergement peut être local et la gouvernance opérationnelle française, mais le lien capitalistique ou technologique avec la maison mère peut rouvrir l'exposition. Question : « Qui contrôle le capital, et la technologie sous-jacente est-elle sous licence d'un tiers non-UE ? »

Piège 3 — « Données chiffrées, donc protégées ». Le chiffrement protège si vous détenez les clés. Si le fournisseur les gère, l'injonction peut porter sur le fournisseur et ses clés. Question : « Qui détient et opère les clés ? »

Face à un discours « souverain », l'acheteur averti ne regarde pas le logo : il regarde le capital, la juridiction du support, et le contrôle des clés.

Architecture : les cinq couches à souverainiser

Couche 1 — Le stockage. Où résident les données au repos ? Localisation UE et chiffrement avec des clés que vous maîtrisez. C'est le socle, pas la fin.

Couche 2 — L'inférence. La couche la plus souvent négligée. Le modèle s'exécute-t-il sur une infrastructure souveraine, ou appelez-vous l'API d'un fournisseur soumis au droit étranger ? Un système n'est pas souverain si son inférence ne l'est pas.

Couche 3 — Les données d'augmentation. Documents indexés, embeddings, base vectorielle : ce sont des données métier. Elles doivent vivre dans le même périmètre que le stockage.

Couche 4 — La télémétrie et les journaux. Traces et métriques d'usage partent souvent vers des outils tiers hébergés hors UE. C'est une fuite silencieuse. Vérifiez la destination de l'observabilité.

Couche 5 — L'administration et le support. Depuis quel pays le fournisseur administre-t-il l'infrastructure et accède-t-il aux données pour le support ? Un support opéré depuis un pays tiers rouvre l'exposition, même avec des serveurs en France.

Une pile est souveraine quand les cinq couches le sont. Un seul maillon non-UE suffit à casser la chaîne.

La méthode d'achat en six étapes

1. Classifier le besoin. Toutes les données d'IA ne se valent pas : usages sur données publiques ou anonymisées, données personnelles ou confidentielles, données sensibles et secret des affaires. Cette classification s'appuie sur votre registre des usages d'IA.

2. Cartographier les flux réels. Pour chaque système, tracez le chemin : saisie → stockage → inférence → augmentation → journaux → support, en notant la juridiction de chaque étape. C'est ici que se révèlent les « France en façade ».

3. Fixer le niveau exigé par catégorie. Écrivez la règle : données sensibles = SecNumCloud ; données confidentielles = UE, clés maîtrisées, immunité démontrée ; données publiques = UE souhaitée. Cette matrice devient votre grille de sélection.

4. Interroger le marché. Intégrez au cahier des charges les questions qui tranchent : périmètre SecNumCloud exact, contrôle capitalistique, juridiction du support, gestion des clés, localisation de l'inférence, réversibilité. Exigez des preuves, pas des déclarations.

5. Contractualiser. Traduisez les exigences en clauses opposables. Sans clause, la promesse commerciale ne protège pas.

6. Prouver dans la durée. La souveraineté n'est pas acquise à la signature : un fournisseur peut être racheté, un flux ajouté, un sous-traitant changé. Reliez chaque système à un inventaire vivant qui trace, en continu, où vivent réellement les données.

Les cinq clauses qui font la différence

Souveraineté n'est pas isolement

Une erreur fréquente oppose « souverain » et « performant ». L'écosystème français et européen offre des briques crédibles : des modèles ouverts compétitifs, des infrastructures GPU de niveau production, et un signal marché fort du côté de la commande publique européenne. La souveraineté n'impose plus de sacrifier la performance ; elle impose de choisir en connaissance de cause et de prouver ses choix.

Le bon niveau d'ambition n'est pas « tout souverainiser d'un coup », mais souverainiser en fonction du risque : SecNumCloud pour le sensible, UE et clés maîtrisées pour le confidentiel, traçabilité continue pour tout le reste.

Conclusion : la souveraineté est une preuve, pas une promesse

« IA souveraine » ne veut rien dire tant que vous ne pouvez pas répondre, système par système : où vivent les données ? où s'exécute le modèle ? qui peut y accéder, sous quel droit ? comment le prouver ?

Le retrait des critères de souveraineté du schéma EUCS a rendu cette vigilance indispensable : le label ne suffit plus, la vérification s'impose. La bonne nouvelle, c'est qu'elle est méthodique. Classez vos usages, cartographiez vos flux, fixez le niveau exigé par catégorie, contractualisez — et maintenez un inventaire vivant qui prouve la souveraineté dans la durée.

Contenu informatif, ne constitue pas un conseil juridique. La couche datée — statut du schéma EUCS, liste des prestataires qualifiés, et surtout l'avancement de la proposition CADA, encore en négociation — doit être revérifiée à chaque évolution : catalogue officiel de l'ANSSI (cyber.gouv.fr) pour les qualifications, procédure législative ordinaire pour le CADA. Dernière révision : 19 août 2026.