LLM et RGPD : arrêtez de faire n’importe quoi avec vos données clients !

Il y a trois ans, choisir un outil de Customer Success prenait des semaines : questionnaire sécurité, DPA, liste des sous-traitants, localisation des serveurs… et votre DPO qui ne lâchait rien. Aujourd’hui, le même DPO découvre qu’un CSM a branché HubSpot, son note-taker et le back-office sur un LLM pour préparer ses QBR. Personne n’a demandé où partaient les transcriptions de réunion. Voici ce qui se passe réellement avec vos données, et comment rester dans les clous sans rater le train de l’IA !

Le paradoxe est assez fascinant. Pour un logiciel classique, on exige l’hébergement en Europe, on épluche les clauses contractuelles types, on demande les certifications. Et c’est normal : vos clients vous confient leurs données, et vos CGV leur font souvent une promesse précise sur la façon dont elles sont traitées.

Mais dès qu’il s’agit d’un LLM, ces réflexes disparaissent. On connecte, on teste, on s’émerveille. Et on fait parfois n'importe quoi ! La puissance de l’outil fait passer la question de l’hébergement au second plan, alors que les données envoyées sont souvent plus sensibles que celles qu’on mettait dans le CRM. Des noms, des emails, des verbatims de clients mécontents, des montants de contrats, des données d'usage, etc.

Et ce n’est pas qu'une impression. Harmonic Security a analysé plus de trois millions de prompts et de fichiers envoyés vers des outils d’IA générative au troisième trimestre 2025, dans des entreprises américaines et britanniques : plus d’un quart des fichiers déposés contenaient des données sensibles (26,4 %, contre 22 % le trimestre précédent). Et encore, il s’agit d’entreprises qui surveillent ces usages.

Prenons Claude comme exemple, parce que c’est l’un des LLM les plus utilisés en B2B et que sa documentation est transparente. Le raisonnement vaut pour les autres.

Ce qui se passe quand vous branchez vos outils sur un LLM

Quand vous connectez HubSpot, votre note-taker ou votre back-office à Claude, vos bases ne déménagent pas. Les données restent chez chaque éditeur, dans la région où votre compte est hébergé. Le LLM ne copie pas votre CRM en entier.

Seulement voilà : tout ce que le LLM lit pour vous répondre entre dans la conversation, et donc passe par l’infrastructure d’Anthropic. Une fiche contact, un historique de deal, une transcription d’appel, un export de tickets. Chaque requête de l’IA vers vos outils ramène des données, et ces données sont traitées chez Anthropic.

Où exactement ? Il faut distinguer deux choses que l’on confond souvent : le traitement et le stockage.

Le traitement (l’inférence), c’est le moment où le modèle lit vos données et génère sa réponse. Depuis le 19 août 2025, Anthropic traite les requêtes de ses clients professionnels (API, Team, Enterprise) dans plusieurs régions : États-Unis, Europe, Asie et Australie. Ce ne sont pas des data centers appartenant à Anthropic, mais les régions de ses fournisseurs cloud (AWS, Google Cloud, Microsoft), déclarés comme sous-traitants. Vos requêtes peuvent donc être traitées en Europe… comme aux États-Unis ou en Asie. Mais vous ne pouvez pas choisir ! Une option permet même de forcer le traitement aux États-Unis, mais aucune ne permet de le forcer en Europe.

Le stockage, c’est l’endroit où vos données restent une fois la réponse générée. Et là, c’est aux États-Unis uniquement. Pas le choix ! Conversations, historique, fichiers chargés (listes de clients, contacts, données contractuelles...), documents générés, slides et dashboards produits : tout est conservé sur des serveurs américains.

Trois zones à distinguer, donc :

• Les plateformes sources (CRM, note-taker, back-office) : elles gardent leurs données, selon leur propre hébergement.
• Le traitement par le modèle : aux États-Unis, en Europe, en Asie ou en Australie, sans que vous puissiez choisir la région depuis claude.ai.
• Ce qui est conservé chez Anthropic : aux États-Unis. L’historique de conversation, les fichiers de travail, les documents, slides et dashboards produits.

Un point important : un back-office branché via un connecteur distant est appelé depuis les serveurs d’Anthropic. Les données qu’il renvoie y transitent, même si votre back-office est hébergé à Paris.

Donc la vraie question n’est pas « où sont mes données ? », mais « quelles données vais-je faire lire au LLM, et pour combien de temps resteront-elles chez lui, aux US ? »

Cas d’usage par cas d’usage : qu’est-ce qui part où ?

Passons aux usages concrets que l’on voit tous les jours dans les équipes CS. Pour chacun : ce qui reste sur vos plateformes, ce qui transite et ce qui est conservé côté LLM.

Notes de synthèse et dashboard 360°

Vous demandez au LLM de croiser HubSpot, vos KPIs d'usage et vos données d'abonnement pour sortir une note de compte ou un dashboard de santé de votre portefeuille.

• Transite : chaque fiche, deal, résumé de réunion et extraction du back-office que le LLM récupère, traités aux États-Unis ou ailleurs, sans que vous le choisissiez.
• Conservé chez Anthropic (US) : la conversation, les fichiers de travail générés pendant l’analyse et le dashboard lui-même, chiffres compris. Si le dashboard relit les données en direct, elles transitent à chaque ouverture.

Avec ou sans PII ? Ce cas se fait très bien sans données personnelles : informations de compte (entreprise, segment, plan), KPI d’usage agrégés, MRR, dates de renouvellement. La sensibilité reste moyenne, car le MRR et les données contractuelles sont des informations business confidentielles. La PII n’entre en jeu que si vous ajoutez les contacts, les échanges ou l’usage par utilisateur nommé.

Criticité : 3/5 🟡 avec des agrégats, 4/5 🟠 si vous ajoutez contacts ou échanges.

Calcul d’un score de santé ou de risque

Pour calculer proprement un score de santé, le LLM récupère les données brutes (usage, tickets, factures, contacts) et lance le calcul dans son espace de travail, lui aussi dans le cloud d’Anthropic, où les fichiers de travail sont stockés aux États-Unis. Ce ne sont pas seulement les scores qui sortent, ce sont toutes les données qui ont servi à les calculer. Si le score est ensuite réécrit dans le CRM, la valeur finale y vit aussi.

Avec ou sans PII ? On peut calculer un score de santé sur des données de compte agrégées (usage par compte, volume de tickets, évolution de la facturation, MRR), en retirant les contacts de l’export. Mais dans la plupart des SaaS B2B, c’est une version dégradée : un score fiable s’appuie aussi sur l’engagement des personnes (adoption par utilisateur, activité du champion et des décideurs, ton des échanges). Sans PII, vous perdez une partie des signaux de risque les plus parlants. C’est un compromis possible, pas l’idéal.

Criticité : 3/5 🟡 pour une version dégradée sur des agrégats, 5/5 🔴 pour un score complet. Bien fait, c’est même le cas qui mobilise le périmètre de données le plus large : CRM, usage nominatif, support, facturation, échanges.

Agents et alertes de risque

Vous programmez un agent qui vérifie chaque matin vos comptes et alerte l’équipe sur Slack quand un client décroche. Chaque exécution est une nouvelle session dans le cloud d’Anthropic : les données sont relues et transférées à chaque passage. L’historique de chaque exécution est conservé chez Anthropic, aux US. Et l’alerte elle-même (nom du client, motif du risque, montant en jeu) est stockée chez Slack ou Google, en plus d’Anthropic.

Avec ou sans PII ? Un agent peut surveiller des indicateurs de compte agrégés et alerter avec le seul nom de l’entreprise, sans PII. Elle devient nécessaire dès que l’alerte vise une personne (départ du champion, contact inactif) ou que l’agent lit des emails et des tickets pour détecter le risque.

Criticité : 3/5 🟡 sur des agrégats, 4/5 🟠 avec des données nominatives. Et gardez en tête que le transfert se répète à chaque exécution.

Comptes rendus de réunion, préparation et slides de QBR

C’est l’un des cas les plus sensibles, et sans doute un des plus courants. Pour rédiger un compte rendu ou préparer une Business Review, le LLM lit les transcriptions d’appels. Or une transcription, c’est le verbatim de votre client : son nom, ses chiffres, ses problèmes internes, les noms de ses collaborateurs, parfois ses critiques sur son propre management. Elle transite intégralement. Le compte rendu et les slides produits dans Claude sont stockés chez Anthropic, aux États-Unis.

Avec ou sans PII ? Des slides de QBR peuvent se préparer sans PII, à partir des KPI du compte et des objectifs du Success Plan. Mais dès que le LLM lit une transcription, des notes de réunion ou accéder à vos emails/agendas, la PII est inévitable : noms, voix, propos tenus.

Criticité : 3/5 🟡 pour des slides construites sur des KPI, 5/5 🔴 dès qu’une transcription entre dans la boucle.

Les autres usages courants en Customer Success

• Synthétiser des emails clients : impossible sans PII, le LLM lit noms, adresses, signatures et contenu des échanges. Criticité : 5/5 🔴.
• Préparer des emails contextualisés à partir de l’historique de la relation : PII nécessaire (destinataire, échanges passés). Une version allégée consiste à ne donner que le contexte du compte et à ajouter vous-même le destinataire. Criticité : 5/5 🔴.
• Exploiter les données du support (sentiment, motifs récurrents) : les tickets contiennent des noms, des emails, parfois même les données des clients de vos clients. Une analyse sur des tickets pseudonymisés ou sur les seules catégories et volumes reste possible. Criticité : 5/5 sur des tickets bruts 🔴, 3/5 🟡 sur des données catégorisées.
• Enrichir des fiches contacts : la PII est l’objet même de la tâche (noms, emails, téléphones, fonctions). Criticité : 5/5 🔴.
• Analyser un export CSV de la base clients pour trouver des motifs de churn : faisable sans PII si l’export ne contient que des données de compte. Le fichier entier est chargé dans l’espace de travail d’Anthropic et stocké aux États-Unis. Criticité : 3/5 🟡 sans contacts, 5/5 avec 🔴.
• Préparer un plan d’onboarding à partir du contrat et des notes de vente : faisable sans PII en retirant les noms des interlocuteurs, mais contrat et notes transitent. Criticité : 3 🟡 à 4/5 🟠.

Les usages critiques à repérer en priorité

Tous ces usages ne se valent pas. La bonne question n’est pas « est-ce sensible ? », mais « ai-je vraiment besoin de données personnelles pour ce cas ? » Échelle utilisée : 1/5 pour des données sans enjeu, 3/5 pour des données business confidentielles (MRR, contrats, usage agrégé), 5/5 pour des données personnelles brutes de vos clients.

En clair : si votre usage implique une transcription, une boîte mail ou un fichier de contacts, vous envoyez de la PII en dehors d'Europe. Et ce n’est pas une option.

Combien de temps vos données restent-elles chez le LLM ?

C’est la question que presque personne ne pose. Et la réponse peut surprendre : sur les offres Team et Enterprise de Claude, les conversations sont conservées tant que personne ne les supprime. Elles restent dans l’historique, sur des serveurs aux États-Unis, avec tout ce qu’elles contiennent, pour que l’utilisateur puisse les retrouver.

Voici les règles publiées par Anthropic pour ses offres professionnelles (page mise à jour le 1er juillet 2026) :

Trois enseignements pour une équipe CS.

D’abord, le plan Team ne permet pas de fixer une durée de conservation : sans suppression manuelle, vos transcriptions et exports clients y restent indéfiniment. Seul l’Enterprise propose une purge automatique. Encore faut-il que l’administrateur l’active.

Ensuite, le pouce levé ou baissé n’est pas anodin. Un CSM qui note une réponse contenant le compte rendu d’un client envoie ce contenu dans une conservation de cinq ans. Il faut le dire aux équipes !

Enfin, ce tableau ne concerne que le LLM. Les alertes Slack, les notes réécrites dans HubSpot ou les documents déposés sur Google Drive suivent les durées de conservation de chaque outil. Une donnée lue une fois par l’IA peut ainsi se retrouver copiée à trois ou quatre endroits.

Team, Enterprise : non, payer plus ne garde pas vos données en Europe

Beaucoup d’équipes pensent qu’en passant sur une offre entreprise, le problème se règle. Plus de garanties, un DPA, des logs d’audit… donc forcément un hébergement européen ? Et bien non !

À ce jour, ni claude.ai (Team et Enterprise compris) ni l’API d’Anthropic ne proposent de résidence des données en Union européenne. Les données des espaces Team et Enterprise sont stockées aux États-Unis, et l’API ne propose que deux zones de traitement, « global » ou « us ». Le plan Enterprise apporte de vrais garde-fous (absence d’entraînement sur vos données par défaut, durées de conservation paramétrables, journaux d’audit), mais il ne change rien à la localisation.

Est-ce que ça va changer ? Rien n’est annoncé. Il existe cependant des signaux. En avril 2026, des offres d’emploi ont révélé qu’Anthropic cherchait à signer des contrats de capacité de data centers en Europe, notamment dans les grands hubs comme Francfort, Paris, Amsterdam, Londres et Dublin ; l’entreprise a refusé de commenter. Côté Microsoft, l’option européenne pour Claude sur Foundry est annoncée « pour 2026 », sans date ferme.

Attention toutefois : des data centers en Europe ne signifient pas automatiquement un choix d’hébergement européen dans claude.ai. Ces capacités peuvent d’abord servir à absorber la demande. Tant qu’aucune option n’est disponible et contractualisée, il faut raisonner avec ce qui existe aujourd’hui.

Et si vos CGV garantissent à vos clients un traitement de leurs données en zone UE, ce qui existe aujourd’hui ne suffit pas.

Et chez les autres LLM ?

Claude n’est pas un cas isolé, mais il est en retard sur ce point. OpenAI, Google et Microsoft proposent déjà une résidence des données en Europe. Seulement voilà : elle est réservée aux offres haut de gamme et elle se configure.

En pratique, la résidence UE reste conditionnelle. Chez OpenAI, elle ne s’applique qu’aux espaces créés dès le départ en région européenne. Chez Google, elle est réservée aux éditions Enterprise Plus et Frontline Plus. Chez Microsoft, un routage flexible peut envoyer le traitement aux États-Unis lors des pics de charge, et les modèles Claude intégrés à Copilot sont exclus de l’EU Data Boundary. Et chez Mistral, il faut choisir l’accès européen, en option payante, pour que le traitement reste en Europe.

Bref, changer de LLM peut régler la question de la localisation, à condition de souscrire la bonne offre et de la configurer correctement. Avec Claude, ce n’est pas possible aujourd’hui.

Les solutions pour utiliser l’IA sans faire sortir vos données d’Europe

La bonne nouvelle, c’est qu’il n’est pas nécessaire de renoncer à l’IA. Il faut simplement la faire tourner au bon endroit.

Passer par un cloud configuré en région européenne

Les modèles Claude sont disponibles chez les grands fournisseurs cloud, qui permettent de choisir une région européenne :

• Google Cloud Vertex AI : Claude est proposé en Belgique, aux Pays-Bas et en multi-région UE, le traitement ayant lieu dans la région à laquelle la requête est envoyée.
• AWS Bedrock : régions de Francfort, d’Irlande, de Paris ou de Stockholm, avec des profils d’inférence UE.

Dans ce cas, c’est Google ou AWS qui devient votre sous-traitant, avec son propre DPA. Ces deux voies sont aujourd’hui les seules confirmées pour une résidence UE avec Claude, à condition de bien verrouiller la configuration régionale.

En pratique, ce n’est pas un simple bouton à activer. Il s’agit d’un accès par API : vous perdez l’interface conversationnelle, ses connecteurs et les skills gérés dans claude.ai, et il faut construire vos propres flux (scripts, pipelines, outils internes). Vos skills maison ne sont pas perdus pour autant : ce sont de simples fichiers d’instructions, réutilisables avec Claude Code ou l’Agent SDK branchés sur la région UE. En revanche, les skills prêts à l’emploi d’Anthropic (Word, PowerPoint, Excel) ne suivent pas. Les points d’accès régionaux coûtent aussi un peu plus cher que les points d’accès globaux. Et il faut verrouiller les détails : profil d’inférence UE plutôt que global, journalisation des prompts désactivée ou stockée en Europe, fichiers sources eux aussi hébergés en région UE.

Une nuance à garder en tête : résidence n’est pas souveraineté. AWS et Google restent des sociétés américaines. Si vos clients attendent une absence totale d’exposition au droit américain, il faudra regarder du côté des offres de cloud souverain ou de modèles hébergés par des acteurs européens.

Choisir des outils métier qui intègrent les LLM dans leur propre infrastructure UE

L’autre voie, plus simple pour une équipe CS, consiste à utiliser un CRM ou une Customer Success Platform qui embarque directement les fonctions d’IA dans son infrastructure européenne. Vous bénéficiez de la synthèse, du scoring et de la détection des risques, sans exporter vos données vers un LLM hébergé aux États-Unis.

C’est le choix que nous avons fait chez Skalin : la plateforme est hébergée sur Google Cloud en Belgique, et les fonctions LLM tournent dans cette même zone UE. C’est d’ailleurs l’une des raisons pour lesquelles un LLM branché sur votre CRM ne remplace pas une Customer Success Platform : la question de la gouvernance des données ne se règle pas en ajoutant un connecteur.

Quelle que soit la voie, la même grille de questions s’applique à tout outil d’IA que vous évaluez :

• Où les données sont-elles traitées, et où sont-elles stockées ?
• Combien de temps sont-elles conservées, et qui peut régler cette durée ?
• Sont-elles utilisées pour entraîner des modèles ?
• Quels sous-traitants interviennent, et dans quels pays ?
• Les données sont-elles anonymisées ou pseudonymisées avant d’être envoyées au modèle ?

Ce sont exactement les questions que vous posiez déjà à vos éditeurs de logiciels. Il suffit de les reposer.

Conclusion

L’IA change réellement la façon de faire du Customer Success. Synthèses en quelques secondes, QBR préparées en dix minutes, risques détectés avant qu’ils ne deviennent du churn : personne n’a envie de rater ce train, et c’est bien normal.

Mais la montée en puissance des LLM ne change rien à une règle simple. Les données de vos clients ne vous appartiennent pas : elles vous sont confiées, et elles ne peuvent pas être envoyées n’importe où, n’importe comment. Surtout si vos CGV leur garantissent un traitement en zone UE. Dans ce cas, brancher une transcription de réunion sur un LLM hébergé aux États-Unis, c’est prendre le risque de ne plus tenir votre engagement contractuel.

Alors avant le prochain test enthousiaste, reprenez vos bons vieux réflexes : cartographiez les usages, repérez ceux qui contiennent de la PII, vérifiez les durées de conservation, et faites tourner l’IA là où vos engagements le permettent. Votre DPO vous remerciera. Vos clients aussi !

Pour aller plus loin :

• Non, Claude ne va pas remplacer votre Customer Success Platform !
• L’Intelligence Artificielle au service du Customer Success
• Agentic AI pour le Customer Success : la prochaine révolution ?
• Data Act et SaaS B2B : ce que les Customer Success Managers doivent savoir
• Quelles différences entre CRM et Customer Success Platform ?