Le guide vous a donné la méthode. Reste la question qui, dans la vraie vie, arrête une adoption en équipe avant même qu'elle commence, et qui n'a rien de technique : où part notre code ?
Je la reçois à chaque mission, en général sous la forme d'un message du DPO ou du RSSI transféré par un lead dev un peu embêté. Et je constate que presque personne n'a la réponse, parce que la documentation existe mais qu'elle est en anglais, éclatée sur six pages, et qu'elle mélange des régimes contractuels très différents.
Ce document rassemble ce qu'il faut pour répondre. Il dit ce qui part, ce qui reste, ce qui est contractuellement garanti, ce qui ne l'est pas, et ce qu'il faut régler avant de déployer sur une équipe. Il dit aussi, franchement, là où la réponse est inconfortable.
Ce qui quitte réellement votre machine
Commençons par le concret, parce que la peur se nourrit du flou. Claude Code s'exécute chez vous : le code reste sur votre disque, et l'agent n'envoie que ce qu'il lit et ce qu'il produit, chiffré en transit. Il n'expédie pas votre dépôt, il expédie les fichiers qu'il a ouverts pour la tâche en cours. C'est une nuance qui change tout, et c'est aussi la raison pour laquelle l'architecture du chapitre 4 est accessoirement une mesure de confidentialité : un module bien délimité, c'est moins de code lu, donc moins de code transmis.
Autour de ce flux principal, quatre canaux secondaires méritent d'être connus, parce que ce sont eux qui surprennent.
- 01 · Les métriquesLatence, fiabilité, usage. La documentation est explicite : elles n'incluent jamais votre code, vos prompts ni vos chemins de fichiers. Désactivables.
- 02 · Les rapports d'erreurMessages et traces d'exception internes à l'outil, avec expurgation des secrets, chemins et adresses connus avant l'envoi. Désactivables, et déjà inactifs par défaut chez un fournisseur cloud.
- 03 · La vérification de domaineAvant d'aller chercher une page web, l'outil envoie le nom d'hôte, et lui seul, pour le confronter à une liste de blocage. Ni l'URL complète, ni le contenu.
- 04 · Le retour produitEt c'est le seul qui doit vous faire lever un sourcil : /feedback, /bug et /share envoient la conversation, code compris. Retenue cinq ans. Rien ne part sans votre action, mais un développeur peut le déclencher sans mesurer ce qu'il transmet.
Tout cela se coupe. Une variable d'environnement suffit à éteindre l'ensemble du trafic non essentiel, et les réglages se versionnent dans le projet comme le reste.
❯ # Tout le trafic non essentiel, en une variable ❯ export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 ❯ # Ou au détail, si vous voulez garder les métriques ❯ export DISABLE_TELEMETRY=1 ❯ export DISABLE_ERROR_REPORTING=1 ❯ export DISABLE_FEEDBACK_COMMAND=1 Réglages posables dans settings.json, donc versionnés et imposables à toute une équipe.
Reste un point que personne ne pense à regarder, et qui est pourtant le plus exposé de tous : vos transcriptions de session sont écrites en clair sur votre disque, sous ~/.claude/projects/, et conservées trente jours par défaut. Vous pouvez raccourcir ce délai. Sur un poste chiffré c'est acceptable ; sur un portable partagé ou mal chiffré, c'est la vraie fuite, et elle n'a rien à voir avec Anthropic.
Dans la plupart des équipes que j'audite, le risque le plus concret n'est pas ce qui part chez l'éditeur. C'est ce qui traîne sur le disque du développeur.
Entraînement : la ligne qui sépare tout
Voici la question qu'on me pose en premier, et la réponse tient à un mot : sous quel contrat êtes-vous ?
Sous conditions commerciales, ce qui recouvre les offres Team et Enterprise, l'API, et les déploiements chez un fournisseur cloud, Anthropic n'entraîne pas ses modèles sur le code et les prompts envoyés à Claude Code. Le seul cas contraire est un programme partenaire auquel un administrateur doit adhérer explicitement, et qui n'existe pas chez les fournisseurs cloud.
Sous conditions grand public, c'est-à-dire les formules Free, Pro et Max, l'utilisateur a le choix, et ce choix a des conséquences : réglage activé, les données peuvent servir à améliorer les modèles et sont conservées cinq ans ; réglage désactivé, elles sont conservées trente jours.
D'où le seul vrai risque de confidentialité que je rencontre en équipe, et il est humain : le développeur qui travaille sur le code de l'entreprise avec son abonnement personnel.
Ce développeur ne fait rien de malveillant. Il a payé son abonnement, il l'aime bien, il l'utilise partout, et personne ne lui a dit que ça changeait quoi que ce soit. Mais son code professionnel transite alors sous un contrat qui n'est pas celui de l'entreprise, avec des réglages qu'il maîtrise seul. Aucune clause négociée ne s'y applique. C'est le premier point que je vérifie en audit, et il se règle en une ligne de configuration : voyez le réglage n°1 plus bas.
Le compte qui convient
Ce qui expose
- Un abonnement personnel Pro ou Max utilisé sur le dépôt de l'entreprise
- Le réglage d'amélioration des modèles laissé au jugement de chacun
- Un /feedback envoyé depuis un projet client, avec le code dedans
- Des transcriptions en clair qui s'accumulent sur un portable non chiffré
Ce qui protège
- Un compte d'équipe ou d'entreprise, sous conditions commerciales
- La connexion épinglée sur l'organisation, impossible à contourner en local
- Le trafic non essentiel coupé par réglage géré, pas par discipline
- Une durée de conservation locale réduite et des postes chiffrés
La colonne de gauche n'est pas une faute professionnelle, c'est un défaut d'information. Elle se corrige par la configuration, jamais par le rappel à l'ordre : une règle qui dépend de la vigilance de quinze personnes n'est pas une règle, c'est un vœu.
Combien de temps vos données sont conservées
Les durées dépendent du même clivage contractuel, et il vaut mieux les connaître avant qu'on vous les demande.
| Régime | Durée de conservation |
|---|---|
| Commercial (Team, Enterprise, API) | 30 jours par défaut |
| Commercial avec zéro rétention | Pas de conservation côté serveur au-delà du contrôle d'abus |
| Grand public, amélioration des modèles activée | 5 ans |
| Grand public, amélioration désactivée | 30 jours |
| Retour envoyé via /feedback, /bug ou /share | 5 ans, quel que soit le régime |
| Transcriptions locales sur votre disque | 30 jours par défaut, réglable |
Un mot sur la zéro rétention, car c'est le point où j'ai vu le plus de malentendus commerciaux. Elle existe, elle est sérieuse, et elle signifie que vos entrées et sorties ne sont pas conservées côté serveur. Mais elle n'est pas incluse d'office dans l'offre Enterprise : elle s'active organisation par organisation, après vérification d'éligibilité par votre interlocuteur commercial. Si votre DPO l'a inscrite comme condition, faites-la écrire dans le contrat, ne la supposez pas acquise parce que vous avez souscrit l'offre haute.
Le RGPD, concrètement
Le cadre est classique et sans surprise pour qui a déjà contractualisé un outil SaaS américain : vous êtes responsable de traitement, l'éditeur est sous-traitant, et il vous faut donc l'accord de traitement des données signé, qui encadre les transferts hors Union européenne par les clauses contractuelles types. Côté assurance, le centre de confiance d'Anthropic met à disposition les certifications et la liste des sous-traitants ultérieurs, dont le rapport SOC 2 de type 2 et la certification ISO 27001. C'est là qu'il faut aller chercher les pièces, et non dans un article de blog, celui-ci compris.
Mais la question réellement structurante n'est pas celle-là, et c'est celle que les équipes oublient.
La résidence des données en Europe : le point inconfortable
Il faut le dire nettement, parce que c'est l'information la plus utile de ce document et celle qu'aucun guide français ne donne. Au 3 août 2026, l'API de première partie d'Anthropic n'offre pas de résidence des données en Europe : le traitement a lieu aux États-Unis, encadré par les clauses contractuelles types. Si votre analyse d'impact ou votre secteur exige que les données ne quittent pas l'Union, l'offre directe ne répond pas au besoin, quel que soit le plan souscrit.
La réponse existe, mais elle passe par un hyperscaler.
| Voie | Ce qu'elle permet en Europe |
|---|---|
| Amazon Bedrock | Régions européennes disponibles, dont Paris, Francfort, Irlande et Stockholm |
| Google Cloud (Agent Platform, ex-Vertex AI) | Points de terminaison régionaux, dont des régions européennes |
| Microsoft Foundry | Annoncé, à vérifier au moment où vous lisez : ne le tenez pas pour acquis |
| API Anthropic directe | Traitement aux États-Unis, encadré par clauses contractuelles types |
Ce détour a un coût qu'il faut assumer devant votre équipe : en passant par un fournisseur cloud, vous perdez l'accès intégré à Claude sur le web, la facturation par siège, et vous héritez de la configuration d'accès de votre cloud. En échange, vous gagnez la région, la traçabilité par les journaux d'audit du fournisseur, et une facturation qui rentre dans un budget cloud existant. Pour beaucoup d'entreprises françaises, ce dernier point règle à lui seul la discussion avec la direction financière.
Choisir son mode de déploiement
Le choix se fait par la contrainte, jamais par la fiche produit. Voici comment je le tranche en atelier, en une question.
| Votre contrainte dominante | La voie qui y répond |
|---|---|
| Aucune contrainte forte, on veut avancer vite | Claude for Teams : facturation centralisée, administration, Claude web inclus |
| Sécurité et conformité structurées, plus de dix développeurs | Claude for Enterprise : authentification unique, rôles, API de conformité, réglages gérés |
| Les données doivent rester en Europe | Bedrock ou Google Cloud, dans une région européenne |
| L'infrastructure est déjà chez un hyperscaler | Le fournisseur que vous utilisez déjà, pour la facturation et les accès |
| Traçabilité centralisée, budgets par équipe | Une passerelle interne devant le fournisseur |
| Tout le trafic sortant doit passer par le proxy maison | Configuration proxy standard, compatible avec toutes les voies |
| Un développeur seul qui évalue | Un compte individuel, mais jamais sur du code client |
Les six réglages que je pose chez un client
Voici la configuration que j'installe systématiquement quand j'accompagne une équipe. Elle tient en une demi-journée et transforme un usage individuel toléré en déploiement défendable.
- Épingler l'organisation de connexionLe réglage n°1, celui qui règle le problème du compte personnel. Les clés forceLoginMethod et forceLoginOrgUUID, posées en réglages gérés, imposent que la session s'authentifie dans votre organisation : une connexion d'un autre compte s'arrête au démarrage. Attention, les sessions ouvertes chez un fournisseur cloud ne sont pas concernées et se restreignent par les accès du cloud.
- Couper le trafic non essentielMétriques, rapports d'erreur et surtout la commande de retour produit, qui est le seul canal capable d'expédier du code. Sur un projet sous secret industriel ou sous données de santé, ce n'est pas une option.
- Verrouiller les permissions par réglages gérésLes autorisations décidées par la sécurité ne doivent pas être contournables par une configuration locale. C'est le même principe que le hook du chapitre 9, à l'échelle de l'organisation : ce qui ne doit pas dépendre de la bonne volonté ne doit pas être une consigne.
- Déployer un CLAUDE.md d'organisationUn fichier au niveau système porte les règles valables partout : les dossiers interdits, les données qu'on ne copie jamais en local, la politique de secrets. Le chapitre 3 vous a appris à l'écrire pour un projet ; ici, il vaut pour toute la maison.
- Épingler les versions de modèleChez un fournisseur cloud, sans épinglage, les alias de modèle retombent sur une valeur par défaut qui peut retarder d'une génération ou ne pas être activée sur votre compte. L'épinglage vous rend la maîtrise de la date de bascule.
- Brancher l'observabilitéLes métriques exportées vers votre collecteur donnent la consommation par équipe et la matière d'audit. C'est aussi ce qui rend mesurable le chapitre 10 : sans compteur partagé, la discussion sur les coûts reste une affaire d'opinions.
Ce que ce document ne dit pas
Trois limites, énoncées franchement, parce qu'un document de conformité qui se prétend exhaustif est un document dangereux.
Il ne remplace pas votre analyse d'impact : ce qui compte, ce n'est pas l'outil, c'est ce que vous lui donnez à traiter, et cela dépend de votre métier. Il ne remplace pas la lecture du contrat que vous signez, dont les versions évoluent. Et il vieillit : les politiques de rétention, les régions disponibles et les offres bougent de trimestre en trimestre, ce qui est d'ailleurs la raison d'être du changelog de ce guide.
Les trois sources à rouvrir avant de signer sont la page officielle d'usage des données, le centre de confiance pour les certifications et la liste des sous-traitants ultérieurs, et l'accord de traitement des données dans sa version en vigueur. Si un point de ce document contredit l'une d'elles, ce sont elles qui ont raison, et j'aimerais qu'on me le signale.
Questions fréquentes sur la confidentialité et le RGPD
Claude Code est-il conforme au RGPD ?
La question est mal posée : la conformité ne s'obtient pas d'un outil, elle se construit par un traitement. Le cadre est disponible, à savoir un accord de traitement des données positionnant Anthropic comme sous-traitant, des clauses contractuelles types pour les transferts hors Union européenne, un rapport SOC 2 de type 2 et une certification ISO 27001 accessibles depuis le centre de confiance. Ce qui reste à votre charge : signer cet accord, déterminer si vous confiez des données personnelles à l'outil (le code seul n'en contient généralement pas, contrairement aux jeux de test et aux journaux applicatifs), et mener votre analyse d'impact. Au 3 août 2026, sachez que l'API directe traite les données aux États-Unis ; si votre analyse exige une localisation européenne, il faut passer par Amazon Bedrock ou Google Cloud dans une région de l'Union.
Anthropic entraîne-t-il ses modèles sur mon code ?
Sous conditions commerciales, à savoir les offres Team et Enterprise, l'API et les déploiements chez un fournisseur cloud, non : Anthropic n'entraîne pas ses modèles génératifs sur le code et les prompts envoyés à Claude Code, sauf adhésion explicite d'un administrateur à un programme partenaire dédié. Sous conditions grand public (Free, Pro, Max), l'utilisateur choisit, et si le réglage d'amélioration des modèles est activé, ses données peuvent être utilisées et sont conservées cinq ans. C'est pourquoi laisser un développeur travailler sur le code de l'entreprise avec son abonnement personnel est le vrai risque à traiter, et il se règle par configuration.
Combien de temps mes données sont-elles conservées ?
Sous conditions commerciales, trente jours par défaut. Une option de zéro rétention existe pour les comptes éligibles : elle n'est pas incluse d'office dans l'offre Enterprise et s'active organisation par organisation, faites-la donc écrire au contrat. Sous conditions grand public, trente jours si l'amélioration des modèles est désactivée, cinq ans si elle est activée. Deux exceptions à connaître : ce que vous envoyez via les commandes de retour produit est conservé cinq ans quel que soit votre régime, et vos transcriptions de session restent en clair sur votre disque pendant trente jours par défaut.
Peut-on héberger Claude en Europe ?
Pas via l'API de première partie d'Anthropic, qui traitait les données aux États-Unis au 3 août 2026. La voie européenne passe par un hyperscaler : Amazon Bedrock propose des régions européennes dont Paris, Francfort, Irlande et Stockholm, et Google Cloud offre des points de terminaison régionaux incluant l'Europe. Microsoft Foundry a annoncé le support européen, à vérifier au moment de votre décision. Le prix de ce détour est la perte de l'accès intégré à Claude sur le web et de la facturation par siège ; le bénéfice est la région, les journaux d'audit de votre cloud et une facturation qui rentre dans un budget existant.
Un développeur peut-il utiliser son abonnement personnel sur le code de son entreprise ?
Techniquement oui, et c'est précisément le problème : son travail transite alors sous des conditions grand public, avec un réglage d'entraînement qu'il contrôle seul, et aucune des clauses négociées par son employeur ne s'applique. Ce n'est pas une faute du développeur, c'est un défaut de configuration. La parade tient en deux clés de réglages gérés, forceLoginMethod et forceLoginOrgUUID, qui imposent l'authentification dans l'organisation de l'entreprise et interrompent le démarrage sinon.
Qu'est-ce que le zéro rétention de données ?
C'est un régime contractuel dans lequel vos entrées et sorties ne sont pas conservées côté serveur au-delà de ce qu'exige le contrôle des abus. Il s'adresse aux comptes qualifiés et n'est pas compris par défaut dans l'offre Enterprise : votre interlocuteur commercial l'active pour votre organisation après vérification d'éligibilité. Effet de bord utile à connaître : les organisations sous zéro rétention ne voient pas les sollicitations de retour produit, ce canal étant justement celui qui transmettrait du code.
La suiteVous avez de quoi répondre à votre DSI, et de quoi cadrer un déploiement qui tienne devant un DPO. Si vous voulez que quelqu'un pose ces six réglages avec vous, et forme l'équipe à la méthode des treize chapitres sur votre propre code plutôt que sur des exemples jouets, c'est exactement ce que je fais.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
J'accompagne les équipes de développement qui adoptent Claude : audit de pratique, formation sur votre code, et mise en place de l'outillage, réglages de sécurité et de conformité compris.
Discutons de votre équipe