RGPD et Claude Code : ce qu'on peut envoyer, ce qu'on ne doit pas
Code source, tickets, dumps, secrets. Une grille concrète pour équipes tech et DSI, sans jargon legaliste et sans interdiction magique.
La question n'est pas « Claude Code est-il RGPD ? ». Un outil n'est pas conforme tout seul. La question est : quelles données partent vers quel traitement, sous quel contrat, et qui l'a autorisé.
Sans ça, chaque développeur improvise. C'est la plus mauvaise politique possible.
Trois couches, pas une checkbox
Le contrat. Compte grand public (Claude.ai, Cursor Hobby) : conditions du fournisseur, souvent transfert hors UE, parfois usage pour l'entraînement selon l'offre. Compte Enterprise / API avec zero-retention : autre contrat, autre DPA, autre réalité. Ne mélangez pas les deux dans le même repo.
Le périmètre. Code source interne sans données perso : généralement tenable en enterprise. Extraire un .env, un export CRM, un CSV RH : non. Un ticket Jira qui contient un email client et un IBAN : non. Un stack trace d'auth avec un JWT : non.
Le modèle d'exécution. Agent local qui lit le disque vs chat web où vous collez. Ce n'est pas le même flux. Documentez-le dans la gouvernance d'équipe.
Grille rapide
| Donnée | Compte perso / Hobby | Enterprise + DPA + retention off |
|---|---|---|
| Code applicatif sans PII | À éviter (ombre) | Oui, si politique d'équipe |
| Commentaires avec emails / noms | Non | Non, ou anonymiser avant |
| Dumps SQL, exports clients | Non | Non |
Secrets, clés, .env | Non | Non |
| Spec fonctionnelle anonymisée | Risqué | Oui |
| Logs d'accès, IP, user-id | Non | Non sauf base légale + minimisation |
« Anonymiser » ne veut pas dire remplacer Jean par User1 dans un fichier qui reste réidentifiable. Si vous avez un doute, ne collez pas.
MCP change la surface, pas le principe
Un serveur MCP qui interroge Postgres en lecture, c'est une nouvelle sortie de données vers le LLM. Les mêmes règles s'appliquent : schéma autorisé, pas de tables RH, pas de PII, logs d'accès côté serveur. MCP n'est pas un sésame RGPD. C'est un câble. Vous décidez ce qui circule dans le câble.
Ce que la DSI doit exiger (et c'est raisonnable)
- Liste des outils autorisés, nominative.
- Offre contractuelle (entity, région, retention).
- Interdiction explicite des comptes perso sur le code prod.
- Canal d'incident : « j'ai collé X par erreur » — sans ça, personne ne déclare.
Ce n'est pas de l'obstruction. C'est le minimum pour que Cursor en équipe et Claude Code restent utilisables sans les éteindre au premier audit.
En pratique, lundi
Ouvrez les settings Cursor / Claude Code. Vérifiez le compte. Si c'est un Gmail perso sur le monorepo billing, vous avez un sujet, pas un détail. Ensuite, une page de règles — voir gouvernance IA — et un passage dans le onboarding.
Les sprints Innov intègrent ce cadrage au jour 0 : modèle, données, DSI. Les formations Devcraft le travaillent sur vos repos. Dans les deux cas, on ne « contourne » pas le legal. On lui donne une grille qu'un développeur peut appliquer sans appeler un avocat à chaque tab-complete.
Passer de la lecture à la pratique ?
Innov / Devcraft — cadrer RGPD avant le premier sprint