Rétention 30 jours de Claude Fable 5 : ZDR, HIPAA, COPPA

Si votre organisation utilise Claude dans le cadre d’un accord de zéro rétention de données (ZDR), votre première requête à claude-fable-5 n’a pas renvoyé de complétion. Elle a renvoyé 400 invalid_request_error. Ce n’est pas une panne — c’est une politique. Fable 5 est le premier modèle Claude en disponibilité générale qui ne peut pas être utilisé sans rétention de données de 30 jours, et cette exigence suit le modèle sur chaque plateforme : l’API Claude, AWS Bedrock, Google Vertex AI et Microsoft Foundry la conditionnent chacun à un opt-in de rétention explicite.

Pour les équipes qui considéraient « nous ne conservons pas vos données » comme une propriété établie de leur stack LLM, il s’agit d’un événement architectural. Cet article couvre ce que dit la politique, pourquoi cette fenêtre existe, comment chaque cloud la met en œuvre, et ce que cela change pour les produits grand public et les secteurs traitant des données sensibles.

Les détails de la politique ont été vérifiés par rapport à la documentation publiée d’Anthropic, AWS, Google et Microsoft le 2026-06-12. Les politiques évoluent ; vérifiez auprès des sources primaires liées et de vos propres contrats. Ceci est une vue d’ensemble technique, pas un conseil juridique.

Ce que dit réellement la politique

Anthropic désigne Claude Fable 5 et Claude Mythos 5 comme Covered Models. Conformément à la documentation sur la rétention des données API et à l’article sur les pratiques de rétention des modèles de classe Mythos (en vigueur depuis le 2026-06-09) :

• Les prompts et les complétions sont conservés pendant 30 jours, puis automatiquement supprimés — sauf s’ils sont signalés dans le cadre d’une enquête de sécurité active ou requis par la loi.
• Il n’existe pas d’opt-out. La rétention est une condition d’utilisation du modèle. Une requête provenant d’une organisation dont la configuration de rétention ne satisfait pas à cette exigence renvoie 400 invalid_request_error.
• L’accès est restreint par conception. Des systèmes de sécurité automatisés analysent les données ; seul un petit groupe de personnel approuvé peut examiner les conversations signalées, sans pouvoir les exporter, les copier ou les télécharger, et chaque accès est consigné dans des journaux inviolables.
• Les accords ZDR existants ne s’appliquent pas au trafic des Covered Models — y compris via les plateformes cloud.

Les offres grand public (Claude Free/Pro/Max) ne sont pas concernées — elles fonctionnent déjà selon leurs propres conditions de rétention. Cette politique cible la surface API commerciale, là précisément où les promesses « nous ne conservons jamais rien » ont tendance à exister.

Pourquoi une fenêtre de 30 jours existe

La justification dans l’article sur les Covered Models est précise : ces modèles disposent de capacités considérablement avancées en ingénierie logicielle, en workflows agentiques et en cybersécurité, et « certaines formes d’abus ne deviennent détectables qu’à travers de nombreuses requêtes. » Les exemples cités — jailbreaking best-of-N, espionnage parrainé par des États — sont des schémas d’attaque où chaque prompt semble anodin et seule la séquence est diagnostique. On ne peut pas détecter une séquence qu’on a supprimée.

Deux choses que cette fenêtre n’est pas :

• Pas des données d’entraînement. Anthropic indique que les données conservées ne sont jamais utilisées pour l’entraînement sans autorisation expresse. L’objectif est la détection des abus, point final.
• Pas nouvelle en nature — nouvelle en caractère non négociable. Une fenêtre de surveillance des abus d’environ 30 jours est la norme du secteur depuis des années : OpenAI conserve les journaux d’abus API jusqu’à 30 jours (ZDR sur approbation) ; Azure OpenAI stocke les prompts jusqu’à 30 jours sauf approbation pour une surveillance des abus modifiée. Ce qui a changé, c’est que cette fenêtre est devenue non négociable pour une classe de modèles — auparavant, chaque fournisseur proposait une échappatoire à zéro rétention.

Une mise en garde préexistante qui surprend souvent : même sous ZDR, Anthropic conserve les résultats des classificateurs de sécurité, et le contenu signalé pour violation de la politique d’utilisation peut être conservé jusqu’à 2 ans. La zéro rétention de données n’a jamais signifié zéro donnée — cela signifie zéro rétention du contenu non signalé dans le parcours normal.

Même exigence, trois clouds, trois mécanismes

La rétention s’applique partout où le modèle s’exécute, mais chaque plateforme configure l’opt-in différemment — et ces différences déterminent qui traite vos données et où se situent vos contrôles.

AWS Bedrock est le plus explicite. La rétention des données est un mode configurable (default / provider_data_share / none), résolu selon la hiérarchie projet → compte → valeur par défaut du modèle. Fable 5 déclare allowed_modes: ["provider_data_share"] : les prompts et les complétions sont partagés avec Anthropic et conservés jusqu’à 30 jours. Sous tout autre mode :

{
  "id": "anthropic.claude-fable-5",
  "status": "unavailable",
  "status_reason": "This model is not available under data retention mode 'default'.",
  "data_retention": {
    "mode": "default",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

Rien n’a changé pour les modèles antérieurs à Fable 5, et une SCP sur la clé de condition bedrock:DataRetentionMode peut imposer votre posture à l’échelle de l’organisation — personne ne peut discrètement basculer le compte pour tester le nouveau modèle. À noter : avec l’inférence inter-régions, la copie conservée réside dans la région de destination, ce qui importe si vous avez des engagements de résidence des données.

Google Vertex AI conditionne l’accès au modèle à un paramètre de partage de données Anthropic au niveau du projet (setPublisherModelConfig avec dataSharingEnabledProvider: "anthropic") ainsi qu’à l’acceptation des conditions dans Model Garden, conformément à la documentation Fable 5 de Google. La gestion générale des données suit la politique de gouvernance des données de Vertex AI ; pour les charges de travail sensibles à la résidence, les points de terminaison régionaux et multi-régions de Vertex contrôlent où s’exécute l’inférence — ce qui inclut désormais l’emplacement de la copie conservée.

Microsoft Foundry est structurellement différent. La documentation sur les données et la confidentialité de Microsoft est explicite : les modèles Claude sont des services tiers de la marketplace — vous acceptez les conditions d’Anthropic au déploiement, et Anthropic — et non Microsoft — est le responsable du traitement des données. Les programmes ZDR et de surveillance des abus modifiée d’Azure OpenAI ne s’étendent pas aux déploiements Claude. Les organisations ayant des postures ZDR ailleurs isolent généralement l’utilisation des Covered Models dans un abonnement dédié, rendant la frontière de rétention structurelle plutôt que procédurale.

Le schéma commun aux trois plateformes : la classe de rétention est devenue un attribut de modèle de premier ordre, lisible par les machines — un mode, un indicateur, une porte de conditions — plutôt qu’un paragraphe dans un contrat. Votre infrastructure peut désormais appliquer votre posture en matière de données, et elle devrait le faire.

Ce que cela signifie pour les déploiements en entreprise

Sans accord ZDR, rien ne change mécaniquement — vous étiez déjà dans une posture de type 30 jours, peut-être sans le réaliser. Le travail consiste à la rendre explicite dans votre documentation fournisseur.

Avec un accord ZDR, vous avez trois options :

1. Exclure les Covered Models. Le ZDR reste uniforme ; vous renoncez au modèle. Viable si vos charges de travail n’en ont pas besoin — consultez notre évaluation mesurée de Fable 5 pour comprendre ce que cela coûte et en quoi il diffère.
2. Séparer par espace de travail ou par projet. Chaque plateforme prend en charge un opt-in délimité : un espace de travail Claude API dédié (Console → Paramètres → Espaces de travail → Contrôles de confidentialité), un projet Bedrock avec provider_data_share, un projet Vertex ou un abonnement Azure séparé. N’y acheminez que les charges de travail tolérantes à la rétention.
3. Accepter la rétention à l’échelle de l’organisation. La solution la plus simple à opérer, mais elle dégrade silencieusement la garantie pour toutes les charges de travail — y compris celles dont la sensibilité justifiait le ZDR. C’est une décision pour votre responsable de la protection des données, pas un simple changement de configuration.

Quel que soit le fournisseur : votre propre journalisation constitue une deuxième surface de rétention. Si votre passerelle ou votre stack d’observabilité journalise les prompts complets, vous opérez une fenêtre plus longue que celle de votre fournisseur, sous votre propre toit. Les garanties des fournisseurs n’ont de sens qu’à la hauteur de la couche qui les précède — la même logique d’audit que nous avons appliquée aux affirmations de cache s’applique ici.

Ce que cela signifie pour les produits destinés aux consommateurs

Si vous servez des consommateurs et routez leur contenu via un Covered Model, le changement se répercute sur votre propre surface juridique — qu’il existe ou non un accord ZDR. Trois conséquences concrètes :

1. Votre politique de confidentialité nécessite probablement une mise à jour. La plupart des régimes exigent de divulguer la durée de conservation, pas seulement la collecte : l’article 13(2)(a) du RGPD impose la période de conservation (ou les critères) au moment de la collecte ; le CPRA californien exige que l’avis au moment de la collecte précise la conservation par catégorie de données personnelles. Si votre politique indique — ou laisse entendre — que les données de conversation ne sont conservées nulle part, une copie détenue par un sous-traitant pendant 30 jours la rend inexacte. Mettez à jour la politique, les registres de traitement et l’inventaire des DPA.

2. Vous ne pouvez pas offrir aux utilisateurs une option de refus que vous ne détenez pas vous-même. La conservation ne prévoit aucun mécanisme d’exception, il n’existe donc aucune bascule que vous puissiez construire pour exempter les prompts d’un utilisateur tout en continuant à utiliser ce modèle. Le levier que vous détenez réellement est le routage : une passerelle tenant compte du consentement envoie les utilisateurs qui refusent le partage de données vers des modèles éligibles au ZDR, et tous les autres vers le Covered Model — une contrainte juridique transformée en règle de routage ordinaire. C’est bien préférable à une case de préférence qui ne fait rien.

3. Les demandes de suppression nécessitent une plomberie précise. Les obligations d’effacement (art. 17 du RGPD, suppression au titre du CPRA, et leurs équivalents) s’étendent aux sous-traitants. Une fenêtre bornée avec suppression automatique sous 30 jours constitue généralement une posture défendable pour un sous-traitant — mais votre procédure DSAR devrait l’indiquer explicitement, plutôt que de promettre une suppression immédiate en aval que vous ne pouvez pas exécuter.

La dimension mondiale amplifie cela : la même logique de divulgation et de sous-traitance apparaît dans le UK GDPR, le LGPD brésilien, et la famille croissante de lois américaines sur la vie privée au niveau des États. Pour les utilisateurs en Chine, la PIPL ajoute deux contraintes plus strictes — la transmission de données personnelles à un autre sous-traitant nécessite généralement un consentement séparé, et le routage du contenu d’utilisateurs chinois vers un endpoint LLM à l’étranger constitue un transfert transfrontalier nécessitant un mécanisme reconnu (évaluation de sécurité, contrat standard ou certification). Une mise à niveau de modèle qui modifie qui conserve quoi, où et pendant combien de temps est exactement le type de changement que ces cadres réglementaires s’attendent à ce que vous re-documentiez.

Industries à données sensibles : là où les 30 jours font le plus mal

Pour la plupart des produits, la fenêtre de rétention du fournisseur est un problème de documentation. Pour les industries dont les données sont elles-mêmes réglementées, c’est un problème d’architecture : la copie conservée est une donnée réglementée au repos chez un prestataire, et les règles sectorielles régissent précisément cela.

Santé (HIPAA)

La HIPAA n’exige pas une rétention zéro — elle exige que tout prestataire détenant des informations de santé protégées le fasse dans le cadre d’un Business Associate Agreement (BAA) assorti de garanties appropriées. La copie de 30 jours de vos prompts constitue des PHI au repos chez un business associate ; la question est de savoir si votre BAA la couvre. Les deux principaux fournisseurs d’API structurent cela différemment, et la différence compte désormais : l’accès API HIPAA-ready d’Anthropic n’exige explicitement pas le ZDR — il repose sur une rétention avec garanties (chiffrement, contrôles d’accès, journalisation des audits, restrictions de fonctionnalités imposées). Le BAA API d’OpenAI couvre les endpoints éligibles à la rétention zéro des données — et un BAA limité aux endpoints ZDR ne peut structurellement pas couvrir un modèle qui impose une rétention.

La classe de rétention d’un modèle est désormais une question d’éligibilité au BAA. Confirmez par écrit que votre BAA couvre le modèle spécifique avant d’y acheminer des PHI — et n’oubliez pas que la chaîne change selon les clouds : sur Bedrock, la plateforme est votre business associate ; sur Foundry, Anthropic traite les données directement. Un point délicat : les PHI ne doivent jamais apparaître dans les définitions de schéma JSON pour les sorties structurées — les schémas mis en cache ne bénéficient pas des mêmes protections que le contenu des messages.

Produits destinés aux enfants (COPPA)

Le calendrier est maladroit : la règle COPPA amendée de la FTC est entrée en vigueur le 23 juin 2025, avec une mise en conformité sur la plupart des dispositions due au 22 avril 2026 — le premier modèle avec rétention obligatoire côté fournisseur est arrivé juste au moment où les opérateurs finissaient d’implémenter les nouvelles obligations de rétention. Deux d’entre elles interagissent directement avec la fenêtre de 30 jours : une politique de rétention des données écrite et publique est désormais obligatoire (§312.10) — quelles données d’enfants sont collectées, pourquoi, et quand elles sont supprimées — et la rétention indéfinie est interdite, la rétention étant limitée à ce qui est raisonnablement nécessaire à la finalité de collecte.

Une fenêtre bornée de 30 jours avec suppression automatique a la forme compatible — mais le fournisseur conserve pour ses propres finalités de confiance et de sécurité, et non pour la finalité pour laquelle vous avez collecté les données de l’enfant, et votre notice doit décrire avec précision la relation avec le sous-traitant. Pour les produits destinés aux enfants qui ont adopté le ZDR spécifiquement pour minimiser la trace de données, la réponse de routage s’applique avec des enjeux plus élevés : le trafic des enfants reste sur des modèles éligibles au ZDR, ou la fenêtre du Covered Model entre dans votre politique §312.10 en premier.

Le même schéma, dans d’autres secteurs

Une fois que vous voyez la structure — données réglementées, copie conservée chez un prestataire, règle sectorielle régissant la rétention — elle se répète :

• Données biométriques (Illinois BIPA) : les opérateurs ont besoin d’un calendrier de rétention écrit et accessible au public ainsi que de directives de destruction pour les données biométriques. La copie de 30 jours d’un fournisseur de prompts contenant des identifiants biométriques appartient à ce calendrier.
• Paiements (PCI DSS / GLBA) : PCI DSS interdit le stockage de données d’authentification sensibles après autorisation — où que ce soit. Les données de carte collées dans un prompt deviennent des données de carte conservées chez un fournisseur pendant 30 jours. La réponse propre est la rédaction en amont, pas la paperasse en aval.
• Éducation (FERPA) : les prestataires traitant des dossiers d’étudiants dans le cadre de l’exception school-official doivent rester sous le contrôle direct de l’établissement. Une copie de rétention à des fins de sécurité à laquelle l’établissement ne peut pas accéder ni supprimer prématurément s’accorde mal avec cette norme — une question à soumettre à un conseiller juridique avant que le trafic EdTech n’atteigne un Covered Model.
• Services financiers — l’inversion (SEC/FINRA) : les courtiers-négociants doivent conserver les communications professionnelles en vertu des règles books-and-records. Pour eux, la fenêtre du fournisseur n’est pas le problème ; capturer leur propre copie conforme l’est. Même question de rétention, signe opposé.

Le fil conducteur : les règles sectorielles régissent la rétention dans les deux sens, et une fenêtre côté fournisseur que vous ne contrôlez pas doit être cartographiée dans la direction que pointe votre secteur.

Une liste de contrôle décisionnelle

• ✅ Inventoriez les modèles que votre trafic touche réellement. La classe de rétention est désormais un attribut par modèle, pas par fournisseur.
• ✅ Si vous avez le ZDR : décidez délibérément — ignorez les Covered Models, segmentez par workspace/projet/abonnement, ou acceptez la rétention à l’échelle de l’organisation. Ne laissez pas cela se produire implicitement.
• ✅ Appliquez la posture dans l’infrastructure — SCPs Bedrock, contrôles de confidentialité des workspaces, projets cloud séparés — pas dans une page wiki.
• ✅ B2C : mettez à jour les notices de confidentialité et les playbooks DSAR ; acheminez les utilisateurs non consentants vers des modèles éligibles au ZDR plutôt que de construire des mécanismes d’opt-out qui ne peuvent pas fonctionner.
• ✅ Données réglementées : confirmez la couverture par modèle, par écrit — BAA pour les PHI, politique §312.10 pour les données d’enfants, calendriers de rétention pour les données biométriques — avant d’acheminer ces données vers un modèle à rétention obligatoire.
• ✅ Auditez votre propre journalisation. La fenêtre de 30 jours d’un fournisseur est sans importance si votre gateway journalise les prompts indéfiniment.

En résumé

La fenêtre de 30 jours associée à Fable 5 n’est pas une collecte de données — il s’agit d’une surveillance des abus délimitée et à finalité limitée, cohérente avec ce que la plupart du secteur fait déjà par défaut, rendue obligatoire pour une classe de modèles parce que la détection des abus inter-requêtes ne fonctionne pas sur des données supprimées. Pour la plupart des équipes, l’impact technique est nul et l’impact sur la gouvernance se résume à un paragraphe dans un audit fournisseur.

Mais pour les organisations dont la position de conformité supposait une rétention zéro — BAA à périmètre ZDR, mentions de confidentialité indiquant qu’aucune donnée n’est conservée, produits destinés aux enfants construits sur la minimisation des données — Fable 5 est le moment où cette hypothèse a cessé d’être uniforme entre les modèles. La solution n’est pas d’éviter le modèle. C’est de faire de la classe de rétention un paramètre explicite, par modèle, dans les décisions de routage, au même titre que le prix et la fenêtre de contexte.

FAQ

Puis-je utiliser Claude Fable 5 dans le cadre d’un accord de rétention zéro des données ? Non. Fable 5 et Mythos 5 sont des Covered Models exigeant une rétention de 30 jours ; les organisations ZDR reçoivent une erreur 400 invalid_request_error à moins d’activer la rétention de 30 jours pour un espace de travail et d’y acheminer le trafic Fable 5.

Le passage par AWS Bedrock, Vertex AI ou Microsoft Foundry permet-il d’éviter cette exigence ? Non. Chaque plateforme conditionne l’accès au modèle à sa propre acceptation de la rétention : provider_data_share sur Bedrock, partage de données Anthropic et conditions du Model Garden sur Vertex, conditions d’Anthropic au déploiement sur Foundry (où Anthropic, et non Microsoft, est le sous-traitant des données). Les arrangements ZDR existants ne sont transférables sur aucune d’entre elles.

Mes utilisateurs finaux peuvent-ils refuser la rétention ? Non — il n’existe aucun mécanisme d’opt-out. Le levier dont vous disposez est le routage : dirigez les utilisateurs qui refusent le partage de données vers des modèles éligibles au ZDR. N’intégrez pas un bouton de préférence qui ne change rien.

Les données conservées sont-elles utilisées pour entraîner des modèles ? Anthropic déclare que les données conservées ne sont jamais utilisées pour l’entraînement sans autorisation expresse. L’objectif est la revue de confiance et de sécurité : un filtrage automatisé, avec des conversations signalées consultables uniquement par du personnel approuvé qui ne peut pas exporter les données, sous des journaux d’accès infalsifiables.

La rétention de 30 jours modifie-t-elle le fonctionnement du prompt caching ? Non. Les entrées de cache suivent leurs propres TTL courts (5 minutes ou 1 heure) et le contrat de mise en cache sur Fable 5 est inchangé — voir notre évaluation mesurée. La fenêtre de 30 jours est une rétention séparée et parallèle à des fins de revue de sécurité.

Sources

• Anthropic — API and data retention
• Anthropic — Covered Models
• Anthropic — Data retention practices for Mythos-class models
• AWS — Amazon Bedrock data retention
• Google Cloud — Claude Fable 5 (partner models)
• Google Cloud — Vertex AI data governance
• Microsoft — Claude in Foundry: data, privacy, and security
• OpenAI — Enterprise privacy
• OpenAI — BAA for API services
• FTC — COPPA Rule amendments (press release)
• Federal Register — Children’s Online Privacy Protection Rule

Tous vérifiés le 2026-06-12. Les politiques évoluent — vérifiez les documents actuels et vos propres contrats. Ceci ne constitue pas un conseil juridique.

← Retour au blog