Puis-je utiliser un modèle US et rester conforme au RGPD ?

Souvent oui, mais jamais par défaut : tout se joue dans le détail. Un fournisseur dont le siège est aux États-Unis reste atteignable au titre du CLOUD Act même sur une région EU, car l'exposition suit le contrôle du fournisseur, pas la localisation des données. Pour en faire un usage licite, vous fixez une région EU, signez un accord de traitement, vérifiez la liste des sous-traitants et gérez vous-même la base légale, la durée de conservation et les transferts. Des clés de chiffrement détenues par le client renforcent encore le chemin. Là où le guide deploying-models répond au niveau de l'endroit où cela tourne, voici la réponse au niveau juridiction : région et DPA atténuent l'exposition, ils ne l'effacent pas. Pour les données les plus sensibles, un fournisseur EU-natif ou l'auto-hébergement est le chemin le plus sûr.

Qu'exige l'EU AI Act en 2026 ?

L'essentiel de l'AI Act s'applique à compter du 2 août 2026, avec des exigences qui s'échelonnent selon le niveau de risque. En pratique : classez votre usage de l'IA, assurez la littératie IA dans vos équipes (obligation déjà en vigueur depuis début 2025), et pour les usages à risque plus élevé, ajoutez documentation, gestion du risque, journalisation et supervision humaine. Certaines échéances pour les usages à haut risque sont en cours d'amendement : traitez le 2 août 2026 comme la date d'application large plutôt que comme une falaise unique et figée, et confirmez votre niveau de risque sur le calendrier officiel. Il s'agit d'un éclairage d'ingénierie, pas d'un conseil juridique.

Une région EU me rend-elle conforme ?

Non. Une région EU vous donne une résidence des données, nécessaire mais distincte de la souveraineté et de la conformité. Si l'opérateur a son siège aux États-Unis, le CLOUD Act atteint quand même les données ; en juin 2025, Microsoft France a déclaré sous serment qu'elle ne pouvait garantir une offre hébergée en France contre les autorités américaines. Et une région ne fait rien pour votre base légale, votre DPA ou vos contrôles de sous-traitants. Traitez la région comme un contrôle parmi d'autres, pas comme la ligne d'arrivée.

Quels sont les fournisseurs de modèles EU-natifs ?

Mistral, dont le siège est à Paris, est le plus solide en capacité : il publie des modèles ouverts sous Apache-2.0 et exploite un datacenter français pour l'inférence sous juridiction européenne. LightOn (Paris) cible des modèles privés pour données sensibles, on-prem ou dans un cloud EU dédié. DeepL (Allemagne) est API-only et performant sur les tâches en langues européennes. Le marché évolue vite : vérifiez la juridiction et l'actionnariat actuels d'un fournisseur avant de vous y fier, certains labos européens ont été rachetés par des sociétés non européennes.

L'IA souveraine vaut-elle le compromis de capacité ?

Cela dépend entièrement des données. Monter sur l'échelle achète du contrôle juridictionnel et se paie en plafond de capacité et en coût opérationnel, car le choix frontier le plus large reste aujourd'hui chez les labos américains. Pour des données réglementées, personnelles ou sensibles, l'arbitrage en vaut la peine et est souvent non négociable. Pour un travail à faible enjeu et non sensible, le payer est une taxe que vous vous imposez pour un risque que vous n'aviez pas. La discipline : ajuster le barreau aux données, aussi souverain que les données l'exigent, pas plus.

← Stack

IA souveraine

Pour un acheteur européen, la juridiction qui régit les données est un axe de premier ordre, pas un détail.

Vue d'ensemble

La plupart des conseils de stratégie modèle classent la capacité, puis le coût, puis peut-être la latence. Pour un acheteur européen, et surtout français, il existe un axe antérieur qui prime souvent sur les trois : quelle juridiction régit les données, et ce que le droit européen exige de vous. Ce n'est pas une note de conformité en bas de page, c'est un paramètre de premier ordre dans le choix du modèle. Cette page creuse cet axe. Pour les mécaniques de déploiement (où tourne un modèle et ce qu'il coûte), voir le guide deploying-models ; cette page répond à : quelle juridiction régit les données, et quelles sont les options européennes.

Deux forces structurent cet axe. D'abord l'exposition : le CLOUD Act américain permet aux autorités US de contraindre un fournisseur dont le siège est aux États-Unis à produire les données qu'il contrôle, quel que soit leur emplacement physique, y compris dans un datacenter européen. L'exposition suit le contrôle du fournisseur, pas la localisation des données : une région EU est nécessaire, mais pas toujours suffisante. Ensuite l'obligation : l'essentiel de l'EU AI Act s'applique à compter du 2 août 2026, avec des exigences qui s'échelonnent selon le niveau de risque (classer votre usage de l'IA, assurer la littératie IA, et pour les usages à risque plus élevé : documentation, gestion du risque, supervision humaine). Le RGPD s'applique en parallèle : base légale, accord de traitement, sous-traitants et transferts.

La réponse prend la forme d'une échelle de souveraineté croissante : API de labo américain (juridiction US), puis région EU d'un hyperscaler américain avec DPA (Bedrock Frankfurt, Vertex Frankfurt, Azure West Europe), puis fournisseur EU-natif (Mistral à Paris, modèles ouverts Apache-2.0 et datacenter français, plus LightOn et DeepL), enfin auto-hébergement open-weight dans votre propre infrastructure européenne. Deux réserves honnêtes. Recourir à un fournisseur européen ne vous rend pas conforme en soi : vous restez responsable du traitement licite. Et la souveraineté est un spectre, un arbitrage face à la capacité et au coût, pas un binaire EU-bien US-mal. Le bon barreau est celui que vos données et votre niveau de risque exigent réellement. Il s'agit d'un éclairage d'ingénierie, pas d'un conseil juridique.

Architecture

Lisez l'échelle du bas vers le haut. Le barreau le plus bas est une API de labo américain : capacité maximale, juridiction US. En montant, le contrôle juridictionnel sur les données augmente (région EU avec DPA, puis fournisseur EU-natif, puis auto-hébergement dans votre propre infrastructure européenne), et le plafond de capacité se resserre, car le choix frontier le plus large reste aujourd'hui chez les labos américains. Aucun barreau n'est universellement juste. Le bon est le plus haut que vos données et votre niveau de risque imposent, et pas plus, pour ne pas payer en capacité ou en coût ce que les données n'exigent pas.

L'échelle de souveraineté : API de labo américain → région EU d'un cloud US + DPA → fournisseur EU-natif → auto-hébergement en Europe. Le contrôle juridictionnel monte à mesure qu'on grimpe ; le plafond de capacité se resserre.

Concepts clés

Souveraineté des données: Le contrôle sur la juridiction qui régit vos données : non pas seulement où elles sont stockées, mais quels tribunaux et quelle loi peuvent en contraindre l'accès. C'est l'axe central de cette page.
Résidence des données: L'endroit où les données se trouvent physiquement (une région EU, un datacenter à Francfort). Nécessaire, mais plus faible que la souveraineté : une résidence en Europe n'empêche pas un opérateur dont le siège est aux États-Unis d'être atteignable au titre de la loi américaine.
CLOUD Act (US): Une loi américaine de 2018 qui permet aux autorités US de contraindre un fournisseur dont le siège est aux États-Unis à produire les données qu'il contrôle, quel que soit le lieu de stockage, y compris des datacenters européens. L'exposition suit le contrôle du fournisseur, pas la localisation des données.
EU AI Act: Le règlement européen sur l'IA. Les obligations s'échelonnent selon le niveau de risque ; l'essentiel s'applique à compter du 2 août 2026, avec documentation, gestion du risque et supervision humaine pour les usages à risque élevé, en sus du RGPD.
RGPD: Le règlement européen sur la protection des données personnelles. Il s'applique indépendamment de l'AI Act : il faut une base légale, un accord de traitement avec chaque sous-traitant, et la maîtrise des sous-traitants ultérieurs et des transferts internationaux.
DPA (accord de traitement): Le contrat imposé par l'article 28 du RGPD entre le responsable de traitement et le sous-traitant (le fournisseur du modèle). Il définit la finalité, les mesures de sécurité, les sous-traitants ultérieurs et les garanties de transfert. Le signer est une condition d'usage licite de tout fournisseur externe.
Sous-traitant ultérieur: Un tiers auquel un fournisseur fait appel pour délivrer son service (hébergement, journalisation, support). Chaque sous-traitant ultérieur est un point de passage de vos données : sa localisation et sa juridiction comptent autant que celles du fournisseur avec lequel vous avez contracté.
Fournisseur EU-natif: Un fournisseur de modèles dont le siège et l'exploitation relèvent de la juridiction européenne, comme Mistral (Paris), LightOn ou DeepL. Cela supprime l'exposition au contrôle américain, mais ne vous décharge pas pour autant de vos obligations RGPD en tant que responsable de traitement.
Cloud souverain: Une infrastructure exploitée sous juridiction et contrôle européens, sur laquelle vous pouvez auto-héberger des modèles open-weight. Le sommet de l'échelle : contrôle juridictionnel maximal, en contrepartie de l'exploitation de la stack par vos propres moyens.

Quand l'utiliser

Cas adaptés

Quand les données sont personnelles ou sensibles au point que leur lieu de traitement est une contrainte ferme, pas une préférence : santé, finance, juridique, RH, ou tout ce que couvrent des règles sectorielles. La souveraineté pilote alors le choix du modèle avant la capacité.
Pour le secteur public et les marchés publics français ou européens, où un chemin de données EU documenté et une juridiction clairement identifiée sont souvent un critère d'éligibilité, pas un bonus. Le barreau de souveraineté fait partie de la réponse à l'appel d'offres.
Quand vous devez pouvoir démontrer, et pas seulement affirmer, où circulent les données : un fournisseur nommé, un DPA signé, une liste de sous-traitants connue et une région fixée. L'EU AI Act comme le RGPD valorisent un chemin que vous pouvez documenter.
Quand les données ne portent PAS de contrainte de résidence ferme, le bon choix est de rester bas sur l'échelle : une API de labo américain ou une région EU avec DPA, et d'investir la capacité et le budget ainsi dégagés là où le travail l'exige. La souveraineté est un outil pour les cas qui la requièrent, pas une taxe par défaut.

Anti-patterns

Traiter une région EU comme une conformité automatique. Fixer Frankfurt chez un fournisseur dont le siège est aux États-Unis améliore la résidence, mais ne supprime pas l'exposition au CLOUD Act et ne fait rien pour votre base légale ni votre DPA. La région est un contrôle parmi d'autres, pas le bout du chemin.
Croire qu'un fournisseur EU-natif règle la question. Choisir Mistral ou LightOn supprime l'exposition au contrôle américain, mais vous restez responsable de traitement : base légale, durées de conservation, sous-traitants et supervision humaine restent à votre charge.
Payer le prix de la souveraineté maximale alors que les données ne l'exigent pas. Auto-héberger dans un cloud souverain pour des traitements non sensibles et à faible enjeu coûte en capacité et en exploitation pour un risque inexistant. Ajustez le barreau aux données.
Confondre localisation des données et souveraineté des données dans un contrat. Une clause qui promet un stockage en EU mais reste muette sur la juridiction de l'opérateur, les sous-traitants et le traitement des demandes d'accès gouvernementales laisse l'exposition réelle sans réponse.

Exemples de code

Fixer une région EU chez un hyperscaler américain

import boto3

# Claude via AWS Bedrock, pinned to an EU region (Frankfurt).
# Residency is in the EU; the operator is still US-headquartered,
# so a DPA and lawful-basis handling remain your responsibility.
client = boto3.client("bedrock-runtime", region_name="eu-central-1")
# ... invoke_model(...) against an EU endpoint
# Region is necessary, not sufficient: it does not remove CLOUD Act reach.

Barreau 2 de l'échelle : résidence EU chez un opérateur américain. Fixez la région, signez le DPA, documentez le chemin. Cela atténue l'exposition, cela ne l'efface pas.

Appeler un fournisseur européen natif

from mistralai import Mistral

# Mistral (mistral.ai) is operated under EU jurisdiction. Using it
# removes the US-control exposure of rung 1 and rung 2.
client = Mistral(api_key="...")
resp = client.chat.complete(
    model="mistral-large-latest",
    messages=[{"role": "user", "content": "Resume ce dossier."}],
)
print(resp.choices[0].message.content)
# EU jurisdiction, but you are still the controller: DPA, basis, retention.

Barreau 3 : un opérateur dont le siège est en Europe supprime l'exposition au contrôle américain. Cela ne vous décharge pas de vos obligations RGPD de responsable de traitement, qui vous suivent quel que soit le barreau.

Comparatif

vs Deploying models

Comment cela se relie : les mécaniques de déploiement

Ce guide répond à : où tourne un modèle et ce qu'il coûte sur le spectre API de labo / managé / auto-hébergé. Cette page creuse un axe qu'il n'effleure qu'en surface : quelle juridiction régit les données. Lisez deploying-models pour les mécaniques et l'économie, puis revenez ici pour vous situer sur l'échelle de souveraineté.

vs Choosing a model

Comment cela se relie : le premier filtre non négociable

Le processus de sélection commence par éliminer les candidats sur les non-négociables, avant toute autre chose. Pour un acheteur européen, la souveraineté est souvent le premier de ces filtres : elle écarte des barreaux entiers avant même d'aborder la capacité ou le coût. Cette page creuse ce premier filtre ; choosing-a-model couvre le processus complet autour.

Ressources

FAQ

Puis-je utiliser un modèle US et rester conforme au RGPD ?: Souvent oui, mais jamais par défaut : tout se joue dans le détail. Un fournisseur dont le siège est aux États-Unis reste atteignable au titre du CLOUD Act même sur une région EU, car l'exposition suit le contrôle du fournisseur, pas la localisation des données. Pour en faire un usage licite, vous fixez une région EU, signez un accord de traitement, vérifiez la liste des sous-traitants et gérez vous-même la base légale, la durée de conservation et les transferts. Des clés de chiffrement détenues par le client renforcent encore le chemin. Là où le guide deploying-models répond au niveau de l'endroit où cela tourne, voici la réponse au niveau juridiction : région et DPA atténuent l'exposition, ils ne l'effacent pas. Pour les données les plus sensibles, un fournisseur EU-natif ou l'auto-hébergement est le chemin le plus sûr.
Qu'exige l'EU AI Act en 2026 ?: L'essentiel de l'AI Act s'applique à compter du 2 août 2026, avec des exigences qui s'échelonnent selon le niveau de risque. En pratique : classez votre usage de l'IA, assurez la littératie IA dans vos équipes (obligation déjà en vigueur depuis début 2025), et pour les usages à risque plus élevé, ajoutez documentation, gestion du risque, journalisation et supervision humaine. Certaines échéances pour les usages à haut risque sont en cours d'amendement : traitez le 2 août 2026 comme la date d'application large plutôt que comme une falaise unique et figée, et confirmez votre niveau de risque sur le calendrier officiel. Il s'agit d'un éclairage d'ingénierie, pas d'un conseil juridique.
Une région EU me rend-elle conforme ?: Non. Une région EU vous donne une résidence des données, nécessaire mais distincte de la souveraineté et de la conformité. Si l'opérateur a son siège aux États-Unis, le CLOUD Act atteint quand même les données ; en juin 2025, Microsoft France a déclaré sous serment qu'elle ne pouvait garantir une offre hébergée en France contre les autorités américaines. Et une région ne fait rien pour votre base légale, votre DPA ou vos contrôles de sous-traitants. Traitez la région comme un contrôle parmi d'autres, pas comme la ligne d'arrivée.
Quels sont les fournisseurs de modèles EU-natifs ?: Mistral, dont le siège est à Paris, est le plus solide en capacité : il publie des modèles ouverts sous Apache-2.0 et exploite un datacenter français pour l'inférence sous juridiction européenne. LightOn (Paris) cible des modèles privés pour données sensibles, on-prem ou dans un cloud EU dédié. DeepL (Allemagne) est API-only et performant sur les tâches en langues européennes. Le marché évolue vite : vérifiez la juridiction et l'actionnariat actuels d'un fournisseur avant de vous y fier, certains labos européens ont été rachetés par des sociétés non européennes.
L'IA souveraine vaut-elle le compromis de capacité ?: Cela dépend entièrement des données. Monter sur l'échelle achète du contrôle juridictionnel et se paie en plafond de capacité et en coût opérationnel, car le choix frontier le plus large reste aujourd'hui chez les labos américains. Pour des données réglementées, personnelles ou sensibles, l'arbitrage en vaut la peine et est souvent non négociable. Pour un travail à faible enjeu et non sensible, le payer est une taxe que vous vous imposez pour un risque que vous n'aviez pas. La discipline : ajuster le barreau aux données, aussi souverain que les données l'exigent, pas plus.