Claude Fable 5 ne fonctionne pas avec le ZDR : une conservation de 30 jours est obligatoire

Si votre organisation utilise Claude dans le cadre d’un accord de non-conservation des données (ZDR), votre première requête vers claude-fable-5 n’a renvoyé aucune completion. Elle a renvoyé 400 invalid_request_error. Ce n’est pas une panne, mais une règle d’utilisation. Fable 5 est le premier modèle Claude disponible de manière générale qui impose une conservation des données pendant 30 jours. Cette exigence s’applique sur toutes les plateformes : l’API Claude, AWS Bedrock, Google Vertex AI et Microsoft Foundry exigent toutes une activation explicite de la conservation.

Pour les équipes qui considéraient l’absence de conservation comme une propriété acquise de leur stack LLM, ce changement a des conséquences sur l’architecture. Cet article détaille la règle, la raison de cette fenêtre de conservation, sa mise en œuvre sur chaque cloud et ses conséquences pour les produits grand public et les secteurs qui traitent des données sensibles.

TL;DR

• Claude Fable 5 impose la conservation des prompts et des completions pendant 30 jours. Cette exigence s’applique à l’API Claude, AWS Bedrock, Google Vertex AI et Microsoft Foundry (règle en vigueur depuis le 2026-06-09).
• Aucune dérogation n’est possible : les organisations disposant d’un accord de non-conservation des données reçoivent 400 invalid_request_error, et leurs conditions ZDR existantes ne s’appliquent pas.
• Sur Bedrock, Fable 5 exige data_retention_mode: provider_data_share. Sans ce paramètre, le modèle apparaît comme indisponible.
• Les contenus signalés pour violation de l’Usage Policy peuvent être conservés jusqu’à 2 ans, indépendamment de la fenêtre de 30 jours.

Ces informations ont été vérifiées dans la documentation publiée par Anthropic, AWS, Google et Microsoft le 2026-06-12. Les règles peuvent évoluer ; vérifiez les sources primaires indiquées et vos propres contrats. Cet article présente une analyse technique, pas un avis juridique.

Ce que dit exactement la règle

Anthropic classe Claude Fable 5 et Claude Mythos 5 parmi les modèles concernés. Selon la documentation sur la conservation des données de l’API et l’article sur les pratiques de conservation des modèles de classe Mythos (en vigueur depuis le 2026-06-09) :

• Les prompts et les completions 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é en cours ou si la loi impose leur conservation.
• Aucune dérogation n’est possible. La conservation des données conditionne l’utilisation du modèle. Toute requête provenant d’une organisation dont la configuration ne respecte pas cette exigence renvoie 400 invalid_request_error.
• L’accès est volontairement restreint. Des systèmes de sécurité automatisés analysent les données. Seul un petit groupe de personnes autorisées peut examiner les conversations signalées. Elles ne peuvent ni les exporter, ni les copier, ni les télécharger, et chaque accès est enregistré dans des journaux inviolables.
• Les accords ZDR existants ne s’appliquent pas au trafic des modèles concernés, y compris lorsqu’il passe par des plateformes cloud.

Les offres grand public Claude Free/Pro/Max ne changent pas : elles relèvent déjà de leurs propres conditions de conservation. Cette règle vise l’API commerciale, précisément là où se trouvent généralement les engagements de non-conservation.

Pourquoi une fenêtre de 30 jours

L’article sur les modèles concernés donne une justification précise : ces modèles disposent de capacités nettement plus avancées en génie logiciel, workflows agentiques et cybersécurité, et « certaines formes d’abus ne deviennent détectables qu’après de nombreuses requêtes ». Les exemples cités, comme le jailbreaking best-of-N et l’espionnage commandité par un État, correspondent à des attaques où chaque prompt pris isolément paraît anodin. Seule la séquence permet de les identifier. Une séquence supprimée ne peut pas être détectée.

Cette fenêtre n’est pas :

• Une collecte de données d’entraînement. Anthropic affirme que les données conservées ne servent jamais à l’entraînement sans autorisation explicite. Elles servent uniquement à détecter les abus.
• Un principe nouveau, mais son application obligatoire l’est. Une fenêtre d’environ 30 jours pour la détection des abus est la norme du secteur depuis des années : OpenAI conserve les journaux d’abus de l’API jusqu’à 30 jours, avec ZDR sur approbation ; Azure OpenAI conserve les prompts jusqu’à 30 jours, sauf approbation d’un dispositif modifié de surveillance des abus. La nouveauté est que cette fenêtre devient non négociable pour une classe de modèles. Jusqu’ici, chaque fournisseur proposait une option sans conservation.

Une exception antérieure reste souvent méconnue : même sous ZDR, Anthropic conserve les résultats des classifieurs de sécurité, et les contenus signalés pour violation de l’Usage Policy peuvent être conservés jusqu’à 2 ans. La non-conservation des données n’a jamais signifié qu’aucune donnée n’était conservée. Elle signifie que le contenu non signalé n’est pas conservé dans le traitement normal.

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

La règle de conservation s’applique partout où le modèle est exécuté, mais chaque plateforme active le consentement différemment. Ces différences déterminent qui traite vos données et où s’appliquent vos contrôles.

AWS Bedrock propose le mécanisme le plus explicite. La conservation des données est un mode configurable (default / provider_data_share / none), résolu selon l’ordre projet → compte → valeur par défaut du modèle. Fable 5 déclare allowed_modes: ["provider_data_share"] : les prompts et les completions sont transmis à Anthropic et conservés jusqu’à 30 jours. Avec 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 ne change pour les modèles antérieurs à Fable 5. Un SCP portant sur la clé de condition bedrock:DataRetentionMode permet d’imposer cette politique à toute l’organisation, afin que personne ne modifie discrètement le compte pour essayer le nouveau modèle. Attention : avec l’inférence interrégionale, la copie conservée réside dans la région de destination. Ce point compte si vous avez pris 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 avec 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. Le traitement général des données suit la politique de gouvernance des données de Vertex AI. Pour les workloads soumis à des contraintes de résidence, les endpoints régionaux et multirégionaux de Vertex déterminent le lieu d’exécution de l’inférence, qui devient aussi le lieu de conservation de la copie.

Microsoft Foundry fonctionne autrement. La documentation de Microsoft sur les données et la confidentialité précise que les modèles Claude sont des services tiers de la marketplace : vous acceptez les conditions d’Anthropic au déploiement, et le sous-traitant des données est Anthropic, pas Microsoft. Les programmes ZDR et de surveillance modifiée des abus d’Azure OpenAI ne couvrent pas les déploiements Claude. Les organisations qui appliquent le ZDR ailleurs isolent généralement les modèles concernés dans un abonnement dédié. La frontière de conservation repose ainsi sur l’architecture plutôt que sur une procédure.

Le principe est le même sur les trois plateformes : la classe de conservation devient un attribut de modèle de premier ordre, lisible par les machines. Elle prend la forme d’un mode, d’un flag ou d’une condition d’utilisation, et non plus d’un simple paragraphe dans un contrat. Votre infrastructure peut désormais imposer votre politique de données, et devrait le faire.

Conséquences pour les déploiements en entreprise

Sans accord ZDR, rien ne change sur le plan technique. Vous étiez probablement déjà soumis à un régime proche de 30 jours, parfois sans le savoir. Il faut désormais le mentionner explicitement dans votre documentation fournisseur.

Avec un accord ZDR, trois options s’offrent à vous :

1. Ne pas utiliser les modèles concernés. Le ZDR reste uniforme, mais vous renoncez au modèle. Cette option convient si vos workloads n’en ont pas besoin. Consultez notre évaluation chiffrée de Fable 5 pour connaître son coût et ses différences.
2. Séparer les workloads par workspace ou projet. Chaque plateforme permet une activation limitée à un périmètre : un workspace dédié dans l’API Claude (Console → Settings → Workspaces → Privacy controls), un projet Bedrock avec provider_data_share, un projet Vertex ou un abonnement Azure distinct. N’y acheminez que les workloads compatibles avec cette conservation.
3. Accepter la conservation dans toute l’organisation. C’est la solution la plus simple à exploiter, mais elle réduit discrètement la garantie de tous les workloads, y compris ceux dont la sensibilité justifiait le ZDR. Cette décision relève du responsable de la protection des données, pas d’une simple modification de configuration.

Quel que soit le fournisseur, vos propres logs constituent une deuxième surface de conservation. Si votre gateway ou votre stack d’observabilité enregistre les prompts complets, vous appliquez chez vous une durée supérieure à celle du fournisseur. Les garanties du fournisseur ne valent que si la couche qui le précède les respecte. La logique d’audit utilisée pour les promesses liées au cache s’applique aussi ici.

Conséquences pour les produits grand public

Si votre produit s’adresse au grand public et transmet son contenu à un modèle concerné, ce changement affecte vos propres obligations juridiques, avec ou sans accord ZDR. Trois conséquences concrètes :

1. Votre politique de confidentialité doit probablement être mise à jour. La plupart des régimes imposent d’indiquer la durée de conservation, pas seulement la collecte. L’article 13(2)(a) du RGPD exige d’indiquer la durée de conservation, ou ses critères de détermination, au moment de la collecte. En Californie, la CPRA impose que l’avis fourni lors de la collecte précise la durée de conservation pour chaque catégorie de données personnelles. Si votre politique affirme ou laisse entendre que les conversations ne sont conservées nulle part, la copie détenue pendant 30 jours par un sous-traitant la rend inexacte. Mettez à jour la politique, le registre des traitements et l’inventaire des DPA.

2. Vous ne pouvez pas proposer à vos utilisateurs une dérogation dont vous ne disposez pas. La conservation ne prévoit aucune exception. Vous ne pouvez donc pas créer une option qui exclut les prompts d’un utilisateur tout en continuant d’utiliser ce modèle. Le seul levier réel est le routage : une gateway tenant compte du consentement envoie les utilisateurs qui refusent le partage de données vers des modèles compatibles ZDR, et les autres vers le modèle concerné. Une contrainte juridique devient ainsi une règle de routage ordinaire. C’est nettement préférable à une case de préférence sans effet.

3. Le traitement des demandes de suppression doit refléter la réalité. Les obligations d’effacement, notamment l’article 17 du RGPD, la suppression prévue par la CPRA et leurs équivalents, s’étendent aux sous-traitants. Une fenêtre limitée avec suppression automatique sous 30 jours constitue généralement une politique défendable pour un sous-traitant. Votre procédure DSAR doit toutefois l’indiquer, au lieu de promettre une suppression aval immédiate que vous ne pouvez pas exécuter.

La dimension internationale renforce le problème : les mêmes obligations d’information et de gestion des sous-traitants existent dans le RGPD britannique, la LGPD brésilienne et un nombre croissant de lois américaines sur la vie privée. Pour les utilisateurs en Chine, la PIPL ajoute deux contraintes plus strictes : la transmission de données personnelles à un autre sous-traitant exige généralement un consentement distinct, et l’envoi du contenu d’utilisateurs chinois vers un endpoint LLM situé à l’étranger constitue un transfert transfrontalier. Il nécessite un mécanisme reconnu, comme une évaluation de sécurité, un contrat standard ou une certification. Une mise à niveau de modèle qui change qui conserve quelles données, où et pendant combien de temps exige précisément une mise à jour documentaire dans ces cadres réglementaires.

Secteurs traitant des données sensibles : là où les 30 jours posent le plus de problèmes

Pour la plupart des produits, cette fenêtre de conservation est surtout un sujet documentaire. Dans les secteurs où les données sont elles-mêmes réglementées, c’est un problème d’architecture : la copie conservée chez le fournisseur constitue une donnée réglementée au repos, soumise aux règles sectorielles.

Santé (HIPAA)

HIPAA n’impose pas une conservation nulle. Il exige que tout fournisseur détenant des informations de santé protégées le fasse dans le cadre d’un Business Associate Agreement (BAA) et mette en place les garanties appropriées. La copie de vos prompts conservée pendant 30 jours est une PHI au repos chez un business associate. Il faut donc déterminer si votre BAA la couvre. Les deux principaux fournisseurs d’API structurent ce point différemment, et cette différence compte désormais : l’accès à l’API Anthropic compatible HIPAA n’impose explicitement pas le ZDR. Il repose sur une conservation assortie de garanties : chiffrement, contrôles d’accès, journaux d’audit et restrictions fonctionnelles obligatoires. Le BAA de l’API OpenAI couvre les endpoints éligibles au ZDR. Un BAA limité aux endpoints ZDR ne peut donc pas, par définition, couvrir un modèle qui impose la conservation.

La classe de conservation d’un modèle détermine désormais son éligibilité au BAA. Avant d’envoyer des PHI vers un modèle, obtenez une confirmation écrite que votre BAA couvre précisément ce modèle. Tenez aussi compte du changement dans la chaîne de sous-traitance sur les clouds : sur Bedrock, la plateforme est votre business associate ; sur Foundry, Anthropic traite directement les données. Autre point sensible : aucune PHI ne doit apparaître dans les définitions de schéma JSON utilisées 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 délicat : la règle COPPA modifiée de la FTC est entrée en vigueur le June 23, 2025, avec une mise en conformité requise pour la plupart de ses dispositions au April 22, 2026. Le premier modèle imposant une conservation côté fournisseur est arrivé au moment où les opérateurs achevaient la mise en œuvre de leurs nouvelles obligations. Deux d’entre elles interagissent directement avec la fenêtre de 30 jours : une politique écrite et publique de conservation des données est désormais obligatoire (§312.10). Elle doit préciser quelles données relatives aux enfants sont collectées, pourquoi elles le sont et quand elles sont supprimées. La conservation indéfinie est interdite et la durée doit se limiter à ce qui est raisonnablement nécessaire pour atteindre l’objectif de la collecte.

Une fenêtre limitée à 30 jours avec suppression automatique a une forme compatible avec ces exigences. Cependant, le fournisseur conserve les données à des fins de confiance et de sécurité qui lui sont propres, et non pour la finalité ayant motivé votre collecte. Votre politique doit décrire précisément cette relation de sous-traitance. Pour les produits destinés aux enfants qui ont adopté le ZDR afin de réduire la trace de données, la réponse repose là aussi sur le routage, avec des enjeux plus élevés : le trafic des enfants reste sur des modèles compatibles ZDR, ou la fenêtre du modèle concerné doit d’abord être intégrée à votre politique §312.10.

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

La structure se répète : données réglementées, copie conservée chez un fournisseur, règle sectorielle encadrant cette conservation.

• Biométrie (Illinois BIPA) : les opérateurs doivent publier un calendrier écrit de conservation et des règles de destruction des données biométriques. Une copie de prompts contenant des identifiants biométriques, conservée 30 jours par un fournisseur, doit figurer dans ce calendrier.
• Paiements (PCI DSS / GLBA) : PCI DSS interdit de conserver les données d’authentification sensibles après autorisation, quel que soit l’endroit. Des données de carte copiées dans un prompt deviennent des données de carte conservées pendant 30 jours chez un fournisseur. La bonne solution est de les supprimer en amont, pas de produire des documents en aval.
• Éducation (FERPA) : les fournisseurs qui traitent les dossiers des élèves au titre de l’exception applicable aux responsables scolaires doivent rester sous le contrôle direct de l’établissement. Une copie conservée à des fins de sécurité, que l’établissement ne peut ni consulter ni supprimer avant l’échéance, s’accorde difficilement avec cette exigence. Demandez un avis juridique avant d’envoyer du trafic EdTech vers un modèle concerné.
• Services financiers, avec une logique inversée (SEC/FINRA) : les courtiers doivent conserver les communications professionnelles conformément aux règles de tenue des registres. Pour eux, la fenêtre du fournisseur n’est pas le problème. Ils doivent surtout enregistrer leur propre copie conforme. Même question de conservation, effet inverse.

Le point commun est simple : les règles sectorielles encadrent la conservation dans les deux sens. Toute fenêtre côté fournisseur que vous ne contrôlez pas doit être rapprochée des obligations propres à votre secteur.

Checklist de décision

• ✅ Inventoriez les modèles réellement utilisés par votre trafic. La classe de conservation est désormais un attribut propre à chaque modèle, pas à chaque fournisseur.
• ✅ Si vous avez un accord ZDR, prenez une décision explicite : exclure les modèles concernés, séparer les workloads par workspace/projet/abonnement, ou accepter la conservation dans toute l’organisation. Ne laissez pas ce choix se faire implicitement.
• ✅ Imposez cette politique dans l’infrastructure avec des SCP Bedrock, des contrôles de confidentialité au niveau des workspaces ou des projets cloud distincts, plutôt que dans une page de wiki.
• ✅ Pour le B2C, mettez à jour les politiques de confidentialité et les procédures DSAR. Acheminez les utilisateurs qui refusent le partage vers des modèles compatibles ZDR, au lieu de créer des options qui ne peuvent pas fonctionner.
• ✅ Pour les données réglementées, obtenez une confirmation écrite de la couverture de chaque modèle : BAA pour les PHI, politique §312.10 pour les données des enfants, calendrier de conservation pour la biométrie, avant d’envoyer ces données à un modèle qui impose leur conservation.
• ✅ Auditez vos propres logs. La fenêtre de 30 jours du fournisseur ne sert à rien si votre gateway conserve les prompts indéfiniment.

Conclusion

La fenêtre de 30 jours associée à Fable 5 n’est pas une collecte opportuniste de données. Il s’agit d’un dispositif limité dans le temps et dans sa finalité, destiné à détecter les abus. Il correspond à la pratique par défaut d’une grande partie du secteur et devient obligatoire pour une classe de modèles parce que la détection d’abus sur plusieurs requêtes ne fonctionne pas avec des données déjà supprimées. Pour la plupart des équipes, l’impact technique est nul et l’impact de gouvernance se limite à un paragraphe dans l’évaluation du fournisseur.

Mais pour les organisations dont la conformité reposait sur l’absence de conservation, comme les BAA limités au ZDR, les politiques de confidentialité affirmant qu’aucune donnée ne persiste ou les produits pour enfants fondés sur la minimisation des données, Fable 5 met fin à l’idée qu’une même politique s’applique à tous les modèles. La solution n’est pas nécessairement d’éviter le modèle. Il faut intégrer explicitement la classe de conservation de chaque modèle aux 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 non-conservation des données ? Non. Fable 5 et Mythos 5 sont des modèles concernés qui imposent une conservation de 30 jours. Les organisations en ZDR reçoivent 400 invalid_request_error, sauf si elles activent la conservation de 30 jours pour un workspace et y acheminent le trafic de 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 à son propre mécanisme de conservation : provider_data_share sur Bedrock, partage de données avec Anthropic et acceptation des conditions de Model Garden sur Vertex, conditions d’Anthropic acceptées au déploiement sur Foundry, où le sous-traitant est Anthropic et non Microsoft. Les accords ZDR existants ne s’appliquent sur aucune de ces plateformes.

Mes utilisateurs finaux peuvent-ils refuser la conservation ? Non, aucun mécanisme de dérogation n’existe. Votre seul levier est le routage : envoyez les utilisateurs qui refusent le partage de données vers des modèles compatibles ZDR. Ne déployez pas une option qui ne change rien.

Les données conservées servent-elles à entraîner les modèles ? Anthropic affirme que les données conservées ne servent jamais à l’entraînement sans autorisation explicite. Elles servent aux contrôles de confiance et de sécurité : analyse automatisée, puis examen éventuel des conversations signalées par des personnes autorisées qui ne peuvent pas exporter les données, avec des accès enregistrés dans des journaux inviolables.

La conservation de 30 jours modifie-t-elle le fonctionnement du prompt cache ? Non. Les entrées de cache suivent leurs propres TTL courts, de 5 minutes ou 1 heure, et le contrat de cache de Fable 5 ne change pas. Consultez notre évaluation chiffrée. La fenêtre de 30 jours correspond à une conservation distincte et parallèle, destinée aux contrôles de sécurité.

Pour aller plus loin : le guide complet du prompt cache explique les mécanismes de cache qui interagissent avec les règles de conservation, et la page des tarifs des plateformes indique le prix catalogue de chaque modèle chez son fournisseur.

Sources

• Anthropic — API et conservation des données
• Anthropic — Modèles concernés
• Anthropic — Pratiques de conservation des données pour les modèles de classe Mythos
• AWS — Conservation des données dans Amazon Bedrock
• Google Cloud — Claude Fable 5 (modèles partenaires)
• Google Cloud — Gouvernance des données de Vertex AI
• Microsoft — Claude dans Foundry : données, confidentialité et sécurité
• OpenAI — Confidentialité pour les entreprises
• OpenAI — BAA pour les services API
• FTC — Modifications de la règle COPPA (communiqué de presse)
• Federal Register — Règle relative à la protection de la vie privée des enfants en ligne

Toutes les sources ont été vérifiées le 2026-06-12. Les règles peuvent évoluer : consultez les documents à jour et vos propres contrats. Ceci ne constitue pas un avis juridique.

← Retour au blog