Chatbot IA hébergement souverain France : où vont vos données ?

Où vont vos données quand vous utilisez un chatbot IA ?

Avant de parler de souveraineté, il faut comprendre le flux technique des données. Un chatbot IA moderne n'est pas un logiciel qui tourne en local sur votre serveur. C'est un service qui envoie vos requêtes vers une API distante — celle d'OpenAI, d'Anthropic, de Google ou d'un autre fournisseur de modèle de langage (LLM).

Voici ce qui se passe concrètement lors d'un échange avec un chatbot IA non souverain :

• L'utilisateur tape sa question dans l'interface du chatbot.
• Cette question (le « prompt ») est envoyée, via HTTPS, à l'API du fournisseur LLM.
• Le prompt peut contenir des données personnelles, des extraits de documents internes, des informations clients ou des données de santé — selon ce que l'utilisateur a saisi.
• Le LLM génère une réponse et la renvoie. Le prompt et la réponse sont potentiellement journalisés côté fournisseur pour améliorer les modèles, sauf option contraire explicitement activée.
• L'historique des conversations est stocké sur les serveurs du fournisseur, dont la localisation dépend de son architecture.

Dans le cas d'OpenAI (ChatGPT, API GPT), les données transitent vers des serveurs Microsoft Azure localisés aux États-Unis ou en Europe selon la configuration — mais dans tous les cas, la société mère est américaine et soumise au droit américain. C'est là que le Cloud Act entre en jeu.

Données envoyées au LLM : ce qu'il faut savoir

Une confusion fréquente : confondre les données de l'application chatbot (historique de conversation, base documentaire RAG) avec les données envoyées au LLM à chaque requête. Ce sont deux couches distinctes. Même si la base documentaire est hébergée en France, chaque requête utilisateur qui déclenche un appel au LLM envoie du texte — potentiellement sensible — à l'API externe.

Pour une solution RAG, le contenu récupéré dans la base documentaire est injecté dans le prompt envoyé au LLM. Concrètement : un extrait de votre cahier des charges interne, d'un contrat client ou d'un dossier médical peut se retrouver dans le prompt traité par le modèle chez son fournisseur.

Les trois niveaux de flux de données à auditer

Cloud Act : pourquoi « hébergé en Europe » ne suffit pas

Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act), adopté aux États-Unis en mars 2018, est la loi qui crée le principal point de friction entre les solutions IA américaines et la souveraineté des données européennes.

Son principe : toute entreprise soumise au droit américain — qu'il s'agisse d'OpenAI, de Microsoft, d'Amazon (AWS) ou de Google — est légalement contrainte de fournir les données demandées par un juge fédéral américain, même si ces données sont physiquement stockées en Europe. La localisation géographique du serveur ne protège pas contre une injonction américaine si le fournisseur de services est une société américaine.

Ce n'est pas une hypothèse de juriste : des entreprises françaises dans les secteurs financier, juridique et industriel ont déjà dû gérer des situations où des données hébergées chez des prestataires américains ont été demandées par des autorités américaines, créant un conflit direct avec leurs obligations RGPD de confidentialité.

Le piège de la filiale européenne

Certains fournisseurs américains créent des filiales européennes ou des offres « cloud européen » en réponse aux préoccupations des clients. Microsoft Azure Europe, AWS EU ou Google Cloud EU sont des exemples courants. Mais ces filiales restent des entités d'un groupe américain, soumises au droit américain via leur société mère. Une injonction Cloud Act à la maison mère peut contraindre la filiale européenne à fournir les données.

La distinction à retenir : hébergé en Europe ≠ souverain. Un hébergement vraiment souverain implique que la société qui opère le service soit juridiquement indépendante de tout groupe soumis au droit américain. C'est ce que proposent OVHcloud, Scaleway, Outscale (Dassault) ou Clever Cloud — et c'est le socle sur lequel Heeya a construit son architecture.

Cloud Act et RGPD : une contradiction irréductible

Le RGPD interdit le transfert de données personnelles vers des pays tiers sans garanties adéquates. Le Cloud Act oblige à ce transfert sur injonction américaine. Ces deux textes sont en contradiction structurelle. Pour une entreprise française, s'appuyer sur un chatbot IA soumis au Cloud Act pour traiter des données personnelles de clients, d'employés ou de patients, c'est s'exposer à un risque de non-conformité RGPD permanent — même si aucune injonction n'a encore été émise.

Notre guide chatbot IA et conformité RGPD CNIL détaille les obligations précises et les mesures à mettre en place pour rester dans le cadre légal français et européen.

RGPD et chatbot IA : ce que la loi impose réellement

Le RGPD ne dit pas « n'utilisez pas de chatbot IA ». Il pose des principes que tout déploiement de chatbot IA doit respecter. En tant que responsable de traitement, votre entreprise est responsable de ce qui arrive aux données de vos utilisateurs — même si c'est un sous-traitant (le fournisseur du chatbot) qui les traite.

Les obligations fondamentales du responsable de traitement

• Licéité et finalité : les données traitées par le chatbot doivent l'être pour une finalité précise, explicite et légitime. Utiliser un chatbot de support client pour former les modèles IA du fournisseur sans consentement explicite viole ce principe.
• Minimisation : le chatbot ne doit traiter que les données strictement nécessaires. Un chatbot FAQ n'a pas besoin de connaître le numéro de sécurité sociale de l'utilisateur.
• DPA obligatoire : tout fournisseur de chatbot IA est un sous-traitant au sens du RGPD. Un Data Processing Agreement (DPA / accord de traitement des données) est obligatoire. Ce document doit préciser : les catégories de données traitées, la localisation des serveurs, les sous-traitants de rang 2 utilisés, et les mesures de sécurité appliquées.
• Transferts internationaux : tout flux de données hors UE/EEE doit être encadré par un mécanisme adéquat (décision d'adéquation, clauses contractuelles types). Le simple fait d'appeler l'API OpenAI constitue un transfert vers les États-Unis.
• Durées de conservation : l'historique des conversations doit être supprimé selon des durées définies. Le fournisseur doit garantir la suppression effective, y compris des copies de sauvegarde.

La responsabilité partagée : qui répond en cas d'incident ?

En cas de fuite de données via un chatbot IA, la CNIL considère que le responsable de traitement — votre entreprise — reste co-responsable même si l'incident vient du fournisseur. La CNIL a déjà sanctionné des entreprises pour avoir intégré des outils tiers sans avoir vérifié leur conformité RGPD. Avec des amendes pouvant atteindre 4 % du chiffre d'affaires mondial, la question de la souveraineté des données n'est pas une précaution excessive : c'est une exigence légale.

SecNumCloud, HDS et certifications : le socle de la souveraineté

Pour évaluer le niveau de souveraineté réelle d'un hébergeur ou d'une solution SaaS, les certifications existent. Deux sont particulièrement importantes pour les entreprises françaises : SecNumCloud et HDS.

SecNumCloud : la qualification souveraineté de l'ANSSI

SecNumCloud est la qualification délivrée par l'ANSSI (Agence nationale de la sécurité des systèmes d'information) aux fournisseurs de services cloud qui respectent plus de 360 critères de conformité répartis en 14 thèmes. La version 3.2 du référentiel, en vigueur depuis 2024, inclut explicitement des protections contre les lois extra-européennes à portée extraterritoriale — dont le Cloud Act.

Pour obtenir SecNumCloud, un hébergeur doit notamment :

• Localiser l'intégralité des données en France ou dans l'UE.
• Ne pas être soumis à une législation extra-européenne pouvant compromettre la souveraineté des données.
• Garantir que les opérations sont réalisées depuis le territoire européen par des personnels européens.
• Passer un audit technique approfondi par des évaluateurs accrédités ANSSI.

Les hébergeurs SecNumCloud qualifiés en France incluent OVHcloud (offre SecNumCloud), Outscale (Dassault Systèmes) et quelques autres. Ce sont des socles techniques sur lesquels des solutions SaaS souveraines peuvent s'appuyer.

HDS : nécessaire mais insuffisant pour la santé

La certification HDS (Hébergeur de Données de Santé) est obligatoire pour toute organisation qui héberge des données de santé à caractère personnel en France. Elle garantit des mesures de sécurité techniques élevées. Mais elle ne couvre pas les aspects de souveraineté juridique.

Un hébergeur peut être certifié HDS et soumis au Cloud Act si sa société mère est américaine. Pour les établissements de santé, les mutuelles ou les acteurs de la medtech, la règle est donc : HDS + hébergeur non soumis au droit américain. Les deux certifications se complètent sans se substituer.

Le label "Cloud de confiance"

La France a créé le label « Cloud de confiance » pour les offres qui combinent une technologie reconnue (parfois américaine, sous licence) exploitée par une entité française indépendante juridiquement. S3NS (filiale de Thales pour Google Cloud) et Bleu (filiale pour Microsoft Azure) sont les deux projets emblématiques. Cette approche est un compromis pragmatique, mais certains juristes maintiennent que la dépendance technologique crée toujours un risque résiduel.

Chiffrement, anonymisation, localisation : les mesures qui protègent

Au-delà des certifications, des mesures techniques concrètes permettent de réduire les risques liés à l'utilisation d'un chatbot IA, même quand le modèle LLM utilisé est externe.

Chiffrement de bout en bout

Toutes les données en transit (entre l'utilisateur et l'application, entre l'application et le LLM) doivent être chiffrées via TLS 1.2 minimum, idéalement TLS 1.3. Les données au repos (base documentaire, historique des conversations) doivent être chiffrées avec des clés maîtrisées par le client (BYOK — Bring Your Own Key), de sorte que même l'hébergeur ne puisse pas lire le contenu des fichiers en clair.

Anonymisation et pseudonymisation des prompts

Une technique puissante pour les secteurs sensibles : anonymiser ou pseudonymiser les données avant qu'elles ne soient envoyées au LLM externe. Par exemple, avant d'envoyer un extrait de contrat au modèle pour analyse, un prétraitement remplace automatiquement les noms propres, numéros de contrat et données d'identification par des tokens génériques. Le LLM traite le texte anonymisé, et la réponse est re-contextualisée côté application. Cette approche permet d'utiliser des LLMs puissants tout en ne leur envoyant jamais de données personnelles identifiables.

Localisation des données et des vecteurs

Pour les solutions RAG, la base de connaissances vectorisée (les documents que le chatbot consulte pour répondre) doit être hébergée sur un serveur souverain. Heeya utilise une base vectorielle (Qdrant) hébergée en Europe, ce qui signifie que vos documents internes ne quittent jamais le territoire européen — seul le contenu pertinent, sélectionné et éventuellement anonymisé, est injecté dans le prompt envoyé au LLM. Si vous gérez des dossiers d'appels d'offres, notre article sur la base de connaissances pour appels d'offres illustre comment structurer ces documents sensibles dans un environnement souverain.

Durées de rétention et droit à l'oubli

Le RGPD impose des durées de conservation limitées. Un chatbot IA conforme doit permettre de paramétrer la durée de rétention des conversations (30, 90, 365 jours par exemple) et de déclencher la suppression effective — y compris des sauvegardes — sur demande de l'utilisateur (droit à l'effacement). Cette fonctionnalité doit être opérationnelle, pas seulement promise dans les CGU.

Notre page expertise RAG détaille comment nous architecturons ces couches de sécurité et de conformité dans les déploiements de chatbots IA pour nos clients. Pour un tour d'horizon complet des menaces et contre-mesures, notre guide sur la sécurité des données d'un chatbot IA en entreprise couvre les vecteurs d'attaque, le chiffrement et les bonnes pratiques de configuration.

Santé, juridique, secteur public : exigences spécifiques

Certains secteurs font face à des contraintes réglementaires supplémentaires qui rendent la question de l'hébergement souverain encore plus critique. Voici les points d'attention par secteur.

Secteur de la santé

Les données de santé sont des données « sensibles » au sens du RGPD (article 9), soumises à des obligations renforcées. Tout chatbot IA qui traite des données de santé — même indirectement, si un patient décrit ses symptômes — doit s'appuyer sur un hébergeur certifié HDS. L'hébergeur doit être référencé sur la liste officielle des HDS publiée par l'ANS (Agence du Numérique en Santé).

Pour les établissements hospitaliers publics, le référentiel Cyber pour les établissements de santé de l'ANSSI ajoute des exigences supplémentaires. Le déploiement d'un chatbot IA en milieu hospitalier sans audit de sécurité préalable est une prise de risque réglementaire et opérationnelle majeure.

Secteur juridique et cabinets d'avocats

Le secret professionnel de l'avocat est protégé par la loi. Envoyer le contenu d'un dossier client dans l'API d'un LLM américain — même pour une analyse documentaire — peut constituer une violation du secret professionnel. L'Usine Digitale a documenté des situations où des avocats, en utilisant ChatGPT pour analyser des pièces, ont involontairement exposé des informations protégées.

Les solutions IA souveraines pour le juridique existent en France : elles s'appuient sur des LLMs hébergés en Europe (Mistral, ou des modèles open-source déployés sur infrastructure souveraine) et garantissent l'absence de journalisation des requêtes à des fins d'entraînement.

Secteur public et collectivités

Les collectivités territoriales qui déploient des chatbots IA — pour la relation citoyenne, les RH internes ou la gestion documentaire — doivent respecter la circulaire du Premier ministre sur les données sensibles de l'État. La règle générale : toute donnée relevant d'un traitement pour le compte de l'État ou d'une collectivité doit être hébergée sur infrastructure souveraine, a minima qualifiée SecNumCloud.

Le secteur public bénéficie d'offres spécifiques : Tchap IA (via DINUM), les offres Scaleway pour les collectivités, ou des déploiements on-premise de modèles open-source sur infrastructure propre.

Pour comparer les solutions françaises et américaines sur ces critères de conformité, notre article comparatif chatbot IA français vs américains 2026 analyse les principales plateformes selon les critères de souveraineté, RGPD et performance.

Comment choisir une solution souveraine : la checklist DPO

Voici les questions concrètes à poser à tout fournisseur de chatbot IA avant de signer un contrat, particulièrement si votre secteur traite des données sensibles.

Questions sur l'hébergement et la localisation

• Où sont physiquement localisés les serveurs qui hébergent l'application et les données ?
• L'hébergeur est-il une société de droit européen, sans groupe mère soumis au droit américain ?
• L'hébergeur dispose-t-il d'une certification SecNumCloud, ISO 27001 ou HDS selon votre secteur ?
• Où sont stockés les vecteurs de la base RAG ? Sur le même hébergeur souverain ?

Questions sur le LLM utilisé

• Quel modèle LLM est utilisé pour générer les réponses ?
• Ce LLM est-il accessible via une API soumise au droit américain (OpenAI, Anthropic, Google) ?
• Les prompts envoyés au LLM sont-ils journalisés par le fournisseur du modèle ? Pour quelle durée ?
• Existe-t-il une option LLM européen (Mistral, Luminous/Aleph Alpha) ou on-premise ?
• Une anonymisation des données est-elle opérée avant envoi au LLM ?

Questions contractuelles et RGPD

• Un DPA (Data Processing Agreement) est-il fourni et signable avant tout accès aux données ?
• La liste des sous-traitants de rang 2 est-elle disponible et à jour ?
• Quelles sont les durées de rétention des conversations ? La suppression est-elle techniquement garantie ?
• Le fournisseur s'engage-t-il à ne jamais utiliser vos données pour entraîner ses modèles ?
• Quelle est la procédure de notification en cas de violation de données (délai, contenu, canal) ?

Une solution qui répond positivement à l'ensemble de ces questions existe : c'est la définition opérationnelle d'un chatbot IA souverain. C'est le standard que Heeya s'est fixé pour ses clients en France. Si vous évaluez un projet concret, notre article sur le délai de mise en place d'un chatbot IA vous donnera une estimation réaliste des étapes, y compris les audits de conformité.

FAQ — Chatbot IA et hébergement souverain en France