Sécurité et privacy dans les workflows Claude Opus 4.7 : ce qu'il faut verrouiller

Opus 4.7 est sorti hier 16 avril 2026. Avec l’usage qui passe à l’échelle en entreprise, les questions de sécurité et de privacy deviennent centrales. Qu’est-ce que tu envoies réellement à Anthropic ? Qui y a accès ? Comment verrouiller ? Tour d’horizon des bonnes pratiques.

Ce qui part vers Anthropic

Quand tu appelles l’API Claude, les prompts et leurs réponses transitent par les infrastructures Anthropic. Par défaut, les conversations via l’API ne sont pas utilisées pour entraîner les modèles futurs. Anthropic l’affirme dans sa privacy policy.

Mais “pas utilisées pour l’entraînement” ne veut pas dire “non stockées”. Les conversations sont retenues pendant une durée (variable selon le plan) pour des raisons d’analyse, de sécurité, et de support.

Pour un usage sensible, tu dois savoir :

• Quelle donnée tu envoies (et si tu peux éviter de l’envoyer)
• Quelle est la politique de rétention
• Quel plan commercial couvre le niveau de confidentialité dont tu as besoin

Les données à ne jamais envoyer

Secrets, tokens, credentials. Jamais dans un prompt, même temporairement. Une fuite via un log, un cache, un historique, peut arriver.

Données de santé identifiables (HIPAA). Sauf plan entreprise spécifique avec BAA signé.

Données bancaires complètes. Numéros de carte, CVV, IBAN de clients. Jamais.

Données personnelles sensibles (RGPD). Identifiants clients, données localisées. À anonymiser avant envoi.

Code propriétaire sous NDA strict. Sauf plan qui garantit explicitement la non-rétention.

Les mécanismes de protection

Anonymisation automatique

Pour les workflows qui traitent de la donnée réelle (logs, tickets, emails), mets en place un sanitizer en amont. Il remplace les identifiants, emails, tokens, par des placeholders déterministes avant l’envoi à Claude.

Un simple sed ou regex sur une liste de patterns fait le boulot dans 80 % des cas. Pour les cas complexes, des lib spécialisées (Microsoft Presidio) existent.

Plans entreprise

Anthropic propose des plans entreprise avec engagements renforcés : non-rétention des prompts, chiffrement renforcé, audit logs disponibles, garanties contractuelles.

Pour une équipe qui traite de la donnée sensible, ce plan n’est pas optionnel. Le surcoût est faible comparé aux risques.

Modèles déployés (Bedrock, Vertex)

Pour les cas où même le passage par Anthropic est problématique, tu peux accéder à Claude via AWS Bedrock ou Google Vertex AI. Le modèle tourne dans l’infra du cloud provider, avec les garanties propres à ce provider.

C’est plus cher mais certains domaines (banque, santé) le justifient.

Les audit logs

Pour une gouvernance propre, tracker qui appelle Claude, quand, avec quels paramètres, sur quelle donnée.

Un wrapper maison autour de l’API Claude qui logue chaque appel dans un système d’audit est simple à mettre en place. Il permet de répondre à des questions du type “qui a envoyé quoi vendredi dernier”.

Pour les entreprises régulées, ces logs sont indispensables.

La question des logs applicatifs

Les logs de tes applications transitent parfois par Claude (pour debug, pour analyse). Ces logs contiennent potentiellement des données sensibles.

Bonne pratique : loguer les données sensibles dans un stream séparé qui ne va jamais vers un LLM. Le stream “analyzable par IA” est déjà filtré.

Refactor simple mais à faire explicitement, sinon le risque persiste.

Les dérives classiques en équipe

Un dev qui colle un bout de prod en prompt pour demander un fix. C’est la fuite type. Mettre en place des règles claires (pas de prod dans les prompts) et des outils pour faciliter le respect (sanitizer accessible).

Un prompt système qui contient des secrets d’intégration. Les prompts système sont stockés côté client mais voyagent à chaque appel. Aucun secret dedans.

Le partage de sessions entre utilisateurs. Si plusieurs devs utilisent un même compte Claude, les historiques se mélangent. Comptes individuels obligatoires en entreprise.

L’archivage des conversations pour référence. Les conversations stockées deviennent un asset à sécuriser. Politique de rétention et de purge à définir.

Le cas des prompts système

Les prompts système sont envoyés à chaque appel. Leur contenu voyage autant que les prompts utilisateur.

Règle : aucun secret, aucune donnée propriétaire stratégique dans un prompt système. Le contenu doit être “public si nécessaire”.

Les informations sensibles qu’un agent doit connaître passent via le prompt utilisateur ou via des appels d’outils, pas via le prompt système.

Les nouveautés 4.7 côté sécurité

Pas de changement majeur de la politique Anthropic côté 4.7. Les mêmes mécanismes sont en place.

Cependant, 4.7 est plus disposé à refuser certaines requêtes potentiellement sensibles (code offensif, exploits). C’est un progrès en sécurité globale, même si ça peut être frustrant sur des cas légitimes (red-teaming interne, audit de sécurité).

Pour contourner proprement, utiliser les plans qui permettent de fine-tuner les refus (accessibles en plan enterprise).

La conformité RGPD

Si tu traites des données de résidents européens, plusieurs points de vigilance :

Transfert extra-UE. Les serveurs Anthropic sont en partie aux USA. Un transfert nécessite des garanties contractuelles (SCCs).

Droit d’accès et de suppression. Tu dois pouvoir identifier et supprimer les données d’un utilisateur spécifique. Les conversations Claude contenant ces données doivent être traçables.

Minimisation des données. Envoyer à Claude strictement le minimum nécessaire. Tout ce qui n’est pas requis est une exposition inutile.

Pour la plupart des cas, un anonymisation propre en amont résout ces points.

FAQ

Peut-on déployer Claude en on-premise ? Non. Claude reste un service géré par Anthropic (direct ou via cloud providers). Pas de déploiement offline sur tes serveurs.

Anthropic peut-elle lire mes prompts ? Théoriquement oui, pour des raisons légales ou de sécurité. En pratique, pas de lecture humaine systématique. Les plans enterprise ont des garanties plus fortes.

Les prompts sont-ils chiffrés end-to-end ? Ils sont chiffrés en transit (TLS). Côté Anthropic, ils sont déchiffrés pour être traités. Il n’y a pas d’E2E strict sur un service LLM par définition.

---

Je dirige Linkuma, plateforme de netlinking low cost avec 40 000 sites au catalogue et 15 000 clients. On applique une politique stricte sur les données qui vont vers les LLMs. Retours terrain sur linkuma.com, promos hebdo sur deals.linkuma.com.