« Vos données sont hébergées en Europe » : pourquoi cette phrase ne veut pas dire grand-chose

Tous les fournisseurs d’IA sérieux proposent aujourd’hui une option d’hébergement européen. OpenAI, Anthropic, Google, Microsoft : tous ont ouvert des régions dans l’Union, tous mettent en avant la conformité au RGPD, tous rassurent sur la localisation des données.

Et pourtant, la question de la souveraineté reste entière. Parce que « où sont stockées les données » et « qui peut légalement y accéder » sont deux questions distinctes, et que la seconde ne dépend pas de la géographie des serveurs. Elle dépend du droit auquel est soumise l’entreprise qui les exploite.

Cette distinction n’est pas un débat d’experts. Pour un établissement public, un CHU ou une université qui envoie des données d’apprenants vers un service d’IA, elle détermine ce qu’il est possible de garantir à ses usagers, et ce qu’il faut écrire dans son registre de traitements.

Résidence, hébergement, souveraineté : trois choses différentes

Commençons par démêler le vocabulaire, parce que le marketing l’a soigneusement embrouillé.

La résidence des données désigne l’endroit physique où les données sont stockées. C’est ce que garantit une « région européenne » chez un fournisseur cloud. C’est vérifiable, c’est contractuel, et c’est le minimum.

L’hébergement ajoute la question de qui exploite l’infrastructure. Des données stockées dans un centre de données situé à Francfort mais opéré par une filiale d’un groupe américain ne sont pas dans la même situation juridique que les mêmes données chez un opérateur européen.

La souveraineté pose la question qui compte vraiment : quelle autorité peut contraindre le fournisseur à livrer ces données, indépendamment de leur localisation ?

C’est sur ce troisième point que la géographie cesse d’être pertinente.

Ce que dit le droit, et pourquoi la géographie ne suffit pas

Le Clarifying Lawful Overseas Use of Data Act, adopté aux États-Unis en 2018 et codifié au 18 U.S.C. § 2713, établit un principe simple : un fournisseur de services soumis à la juridiction américaine doit répondre à une réquisition judiciaire portant sur des données qu’il contrôle, quel que soit le lieu où ces données sont stockées.

La localisation du serveur n’est pas un critère. Le critère est le contrôle exercé par une entité soumise au droit américain. Une entreprise américaine qui opère un centre de données en Irlande reste tenue de répondre à une réquisition américaine visant ces données.

S’ajoutent deux dispositifs de renseignement : la section 702 du Foreign Intelligence Surveillance Act, qui autorise la collecte de données de personnes non-américaines auprès de fournisseurs américains, et le décret présidentiel 12333, qui encadre les activités de renseignement extérieur.

Côté européen, la Cour de justice de l’Union européenne a invalidé le Privacy Shield en juillet 2020 dans l’arrêt Schrems II (affaire C-311/18), en jugeant précisément que ces dispositifs de surveillance ne garantissaient pas un niveau de protection équivalent à celui du droit européen. Le chapitre V du RGPD encadre depuis les transferts hors Union, et le Comité européen de la protection des données a publié des recommandations sur les mesures supplémentaires à mettre en œuvre.

Le Data Privacy Framework, adopté en 2023, a rétabli un cadre pour les transferts vers les entreprises américaines certifiées. Il fait l’objet de recours devant la CJUE. Un responsable de traitement prudent ne construit pas son architecture sur un cadre dont la pérennité juridique est contestée, il l’a déjà vu tomber deux fois.

Conclusion pratique : un fournisseur américain proposant un hébergement européen reste soumis au droit américain. Ce n’est pas une opinion sur la qualité de son service, c’est une conséquence de son statut juridique.

Pourquoi c’est plus critique en formation qu’ailleurs

Les données de formation paraissent anodines. Elles ne le sont pas.

Un échange entre un apprenant et un tuteur IA révèle ce qu’il ne comprend pas. Répétée sur un parcours, cette information dessine un profil de difficultés cognitives, de rythme d’apprentissage, parfois de fragilités personnelles. Dans un contexte de formation professionnelle, elle peut toucher à l’évaluation des compétences, donc à la carrière.

Trois secteurs concentrent l’exposition. L’enseignement supérieur traite des données d’étudiants, souvent jeunes, dans un cadre de service public. La santé combine formation continue et données pouvant relever du secret professionnel. La fonction publique est soumise à des exigences de traçabilité que le secteur privé ne connaît pas toujours, et le référentiel SecNumCloud de l’ANSSI, qui exige explicitement l’immunité aux lois extraterritoriales, devient un critère d’achat courant dans les marchés publics.

À cela s’ajoute l’AI Act, pleinement applicable depuis le 2 août 2026, qui superpose ses propres obligations de transparence et de traçabilité à celles du RGPD.

Le cas Mistral : ce qui est vérifiable, et ce qui demande attention

Mistral AI est une société française, soumise au droit français et européen. Elle n’est pas dans le champ du CLOUD Act. C’est une différence de nature, pas de degré.

Sa documentation est explicite sur l’hébergement : « By default, your data is hosted in the European Union ». Elle l’est tout autant sur les limites, et c’est à porter à son crédit : « Depending on the feature you use, your data can be temporarily transferred outside of the European Union, to the locations listed in the Subprocessors tab of our Trust Center ». Les transferts hors Union sont encadrés par des garanties conformes à l’article 46 du RGPD.

Autrement dit, Mistral ne prétend pas qu’aucune donnée ne quitte jamais l’Europe. Elle documente ses sous-traitants et publie la liste. Pour un DPO, c’est exploitable. C’est même la seule posture qui permette de remplir correctement un registre de traitements.

Deux points de vigilance, en revanche.

Passer par une marketplace change tout. Consommer un modèle Mistral via AWS Bedrock ou Azure AI ne vous place pas sous le régime décrit ci-dessus. La résidence des données suit alors la région du fournisseur cloud, et c’est ce fournisseur, américain, qui devient votre sous-traitant. Le modèle est français, le traitement ne l’est pas.

Tous les modèles Mistral ne sont pas à poids ouverts. L’entreprise publie effectivement plusieurs modèles sous licence ouverte, ce qui autorise un déploiement entièrement interne. Mais ses modèles commerciaux les plus performants ne le sont pas. Affirmer « Mistral est open-weight » sans préciser lequel serait inexact.

Notre architecture, dite précisément

Nous préférons décrire notre chaîne de traitement plutôt que d’agiter des labels.

L’infrastructure applicative de PimenkoAI est hébergée chez Scaleway, opérateur français, filiale du groupe Iliad. Scaleway est certifié HDS pour l’hébergement de données de santé. Sur SecNumCloud, soyons exacts : Scaleway est engagé dans le processus de qualification auprès de l’ANSSI, et figure à ce titre sur la liste publique des prestataires en cours de qualification. La qualification n’est pas obtenue à ce jour. Nous le disons parce que la liste de l’ANSSI est publique et que vous la consulterez.

L’inférence est assurée par l’API de Mistral, société française. Le traitement des messages ne s’effectue donc pas sur notre infrastructure Scaleway mais chez Mistral, dans les conditions décrites plus haut. Nous préférons l’écrire noir sur blanc plutôt que de juxtaposer deux noms français et de laisser imaginer une chaîne intégrée.

L’identité des apprenants ne sort jamais de Moodle. Un identifiant pseudonymisé est substitué avant tout appel externe. Ce qui transite se limite au message, au contexte de cours et à cet identifiant.

Scaleway propose désormais une offre de modèles en tant que service, qui permettrait de réaliser l’inférence sur infrastructure française. C’est la direction que nous souhaitons prendre, et elle suppose d’atteindre un volume que nous n’avons pas encore. Nous le mentionnons comme une trajectoire assumée, pas comme une caractéristique actuelle du produit.

Les trois questions à poser à n’importe quel fournisseur

De quel droit relève l’entité qui traite les données ? Pas où sont les serveurs. Quelle est la nationalité juridique de la société, et quelle est celle de sa maison mère. Une filiale européenne d’un groupe américain reste dans le périmètre du CLOUD Act.

Quelle est la liste des sous-traitants, et est-elle publique ? Un fournisseur qui documente ses sous-traitants et notifie leurs évolutions vous permet de tenir votre registre. Un fournisseur qui reste vague vous met en défaut de conformité, sans que vous le sachiez.

Que se passe-t-il si le cadre de transfert tombe ? Le Privacy Shield a été invalidé, le Safe Harbor avant lui. Un fournisseur dont l’architecture dépend entièrement de la validité du Data Privacy Framework vous expose à un risque de rupture. Demandez le plan de repli.

Ces questions n’appellent pas de réponse parfaite. Elles appellent une réponse précise. Un fournisseur capable de décrire exactement ce qui sort, vers qui, sous quel régime juridique et avec quelles garanties vous permet de décider en connaissance de cause. C’est tout ce qu’un DPO demande.

Voir l’architecture de traitement de PimenkoAI en détail →

Références

• 18 U.S.C. § 2713, Clarifying Lawful Overseas Use of Data Act (2018)
• CJUE, arrêt du 16 juillet 2020, Data Protection Commissioner c. Facebook Ireland et Maximillian Schrems, C-311/18
• Règlement (UE) 2016/679 (RGPD), chapitre V, articles 44 à 50
• Règlement (UE) 2024/1689 établissant des règles harmonisées concernant l’intelligence artificielle
• ANSSI, référentiel SecNumCloud v3.2, et liste publique des prestataires qualifiés et en cours de qualification, cyber.gouv.fr
• Mistral AI, documentation « Where is my data hosted? », help.mistral.ai