← Tous les articles
Analysis

Claude Fable 5 sur Bedrock et le nouveau compromis de conservation des données pendant 30 jours

A cream-background editorial illustration of an AWS-style cloud boundary with a developer terminal inside it, a terracot

Le 9 juin, AWS a lancé Claude Fable 5 sur Amazon Bedrock et a enterré la vraie histoire pour les entreprises dans une seule phrase : avant de pouvoir l’invoquer, vous devez accepter provider_data_share, et dès que vous le faites, vos données sortent de la frontière de données et de sécurité d’AWS (AWS).

Ce n’est pas un petit bouton de configuration. Cela change le contrat que beaucoup d’équipes pensaient acheter en choisissant Bedrock.

Le discours d’Anthropic est assez clair. Fable 5 est la version publique, avec garde-fous, de son nouveau palier de capacités Mythos. Son prix est de 10 $ par million de tokens en entrée et 50 $ par million de tokens en sortie, soit le double du tarif actuel d’Opus 4.8 via API, et Anthropic dit que le modèle est conçu pour l’ingénierie logicielle de longue haleine, le travail de connaissance, la vision et les workflows agentiques (Anthropic, docs de tarification Claude). Mais le prix qui compte le plus pour les entreprises sérieuses n’est pas le prix au token. C’est le prix en gouvernance.

Depuis le 17 juin, il y a une complication de plus : Anthropic indique que l’accès à Fable 5 et Mythos 5 a été suspendu le 12 juin après une directive américaine de contrôle des exportations, tandis que tous les autres modèles Claude restent inchangés (Anthropic). Cette suspension est peut-être temporaire, mais le schéma de gouvernance, lui, ne l’est pas. Voilà à quoi ressemble désormais l’accès aux modèles de pointe : plus de capacités, plus de surveillance, moins de promesses simples sur la confidentialité.

Croquis d’architecture assorti à la couverture montrant trois chemins : une requête Bedrock standard restant à l’intérieur d’une frontière AWS, Claude

Les petites lignes qui changent l’architecture

Le billet de lancement d’AWS indique que Claude Fable 5 est disponible sur Bedrock dans US East, Northern Virginia, et Europe, Stockholm. Il précise aussi qu’au lancement, il n’y a pas d’interface console pour le nouveau réglage de conservation des données. Vous devez appeler la Data Retention API avant d’invoquer le modèle.

Le billet de lancement donne la forme du basculement :

curl -X PUT https://bedrock.us-east-1.amazonaws.com/data-retention \
  -H "Authorization: Bearer <your_bearer_token>" \
  -H "Content-Type: application/json" \
  -d '{ "mode": "provider_data_share" }'

AWS explicite ensuite ce que signifie ce mode : Bedrock peut conserver et partager les données d’inférence avec les fournisseurs de modèles selon leurs exigences ; pour Anthropic Fable 5, ces exigences incluent une conservation de 30 jours des entrées et des sorties, ainsi qu’une éventuelle revue humaine (AWS).

Cela casse le modèle mental de nombreuses équipes plateforme :

RouteAttente par défautRéalité de Fable 5
Bedrock avec la plupart des modèlesEntrées/sorties non stockées par défautPas suffisant pour Fable 5
Bedrock Fable 5Accès hébergé par AWS au modèle AnthropicObligation d’accepter le partage des données fournisseur
Claude API avec ZDRAucune conservation des prompts/sorties pour les API éligiblesFable 5 et Mythos 5 ne sont pas éligibles au ZDR
Anciens modèles ClaudeLes réglages de conservation existants continuent de s’appliquerNon affectés par la politique Covered Model

Les propres docs de détection des abus de Bedrock disent toujours que Bedrock utilise par défaut zéro accès opérateur et zéro conservation des données. Puis elles listent des exceptions. Pour Claude Fable 5, les entrées et sorties sont conservées jusqu’à 30 jours, et son utilisation exige d’accepter le partage du trafic conservé avec Anthropic pour la détection des abus et une possible revue humaine (docs AWS).

Cette “exception” est le produit.

Pourquoi Anthropic veut les données

L’argument d’Anthropic n’est pas absurde. L’entreprise dit que les modèles de classe Mythos franchissent des seuils de capacité où les abus ne deviennent visibles qu’à travers de nombreuses requêtes. Un prompt isolé peut sembler inoffensif. Une séquence de prompts peut ressembler à une recherche de jailbreak, à de la distillation, à une activité soutenue par un État ou à de l’extorsion de données. Anthropic cite précisément des attaques multi-requêtes comme le jailbreaking Best-of-N et affirme que la conservation temporaire permet à ses garde-fous de “dézoomer” sur plusieurs requêtes (support Anthropic).

L’entreprise dit aussi que les données conservées ne servent pas à entraîner de nouveaux modèles Claude, et que l’accès humain est limité aux cas signalés de préjudice grave ou aux demandes écrites des clients. Selon Anthropic, les relecteurs utilisent des outils qui empêchent l’export, la copie ou le téléchargement, avec des accès consignés dans des journaux infalsifiables. Après 30 jours, les données sont supprimées sauf si elles sont liées à une enquête de sécurité ou à une obligation légale (support Anthropic).

C’est une conception de sécurité cohérente. C’est aussi une frontière d’entreprise plus faible que “vos prompts et vos sorties ne sont pas conservés.”

Les deux peuvent être vrais. Les développeurs parlent souvent de ce sujet comme si l’un des deux camps devait mentir. Ce n’est pas le bon cadre. Le bon cadre, c’est : le système de sécurité d’Anthropic a besoin d’observabilité, et la gouvernance d’entreprise traite souvent l’observabilité sur des prompts sensibles comme un nouveau sous-traitant, un nouveau stockage de conservation et une nouvelle surface de revue.

Si vous faites tourner un agent de code sur une base de code réglementée, votre “prompt” n’est pas un message de chat. Il peut contenir des fichiers source, des stack traces, des secrets imprimés par accident dans les logs, des dossiers clients intégrés dans des fixtures, des rapports de vulnérabilité, des schémas de base de données, des URL internes, des fragments de politiques IAM et des sorties d’outils issues de serveurs MCP. Une transcription conservée 30 jours n’a rien d’abstrait. C’est une copie temporaire de votre environnement d’ingénierie.

Graphique comparatif compact avec un axe x “palier de capacité du modèle” allant de Sonnet à Opus puis Fable/Mythos, et un axe y “gouvernance

La réaction de la communauté était prévisible, et largement juste

Le fil Hacker News est allé droit au but. La soumission mettait en avant la phrase d’AWS selon laquelle accepter la conservation signifie que les données sortent de la frontière d’AWS, et elle a atteint 426 points et 254 commentaires en quelques jours (Hacker News). Le débat n’était pas “Fable est-il intelligent ?” C’était “à quoi servait Bedrock, sinon à cette frontière ?”

Un commentateur HN a formulé la douleur centrale des entreprises : ces modèles deviennent inutilisables dans les contextes où les contrats limitent les entités pouvant recevoir les données clients. Un autre a dit qu’il y a peu de raisons d’utiliser Bedrock si l’on ne se soucie pas des limites de partage des données. C’est un peu exagéré : Bedrock apporte aussi l’intégration IAM, la facturation, les contrôles de service et les opérations natives AWS. Mais cela capture bien la motivation d’achat de beaucoup d’équipes plateforme IA.

Le même thème est apparu sur r/aws, où le titre du post était direct : “AWS Bedrock exigera le partage des données avec Anthropic pour Mythos et les futurs modèles.” Un commentateur a dit que garder les données à l’intérieur de la frontière de sécurité était “la majeure partie de l’intérêt” de Bedrock pour son organisation ; un autre a qualifié les modèles d’inutilisables pour eux (Reddit r/aws).

Il y avait aussi un second fil, plus méfiant : si les fournisseurs conservent les prompts pendant 30 jours, qu’est-ce qui les empêche de les utiliser pour l’entraînement ? La réponse factuelle est qu’Anthropic dit ne pas utiliser ces données pour entraîner de nouveaux modèles Claude ni à des fins autres que la sécurité (Anthropic). La réponse pratique est que les entreprises réglementées ne construisent pas leurs contrôles sur des vibes fournisseur. Elles les construisent sur des clauses exécutoires, des droits d’audit, des diagrammes de flux de données, des calendriers de conservation et des procédures d’incident.

C’est la pièce qui manque dans beaucoup d’arguments de forum. “Ils disent pas d’entraînement” est pertinent. Ce n’est pas suffisant.

L’ancienne promesse de Bedrock n’a pas disparu, elle est devenue spécifique à chaque modèle

La plus grosse erreur qu’une équipe entreprise puisse faire maintenant est de traiter “Bedrock” comme une posture de confidentialité unique.

Pour les anciens modèles et beaucoup de routes Bedrock, l’ancienne posture existe toujours. AWS dit que Bedrock ne stocke pas les entrées ou sorties des modèles par défaut et utilise zéro accès opérateur par défaut (docs AWS). Anthropic dit que les autres modèles Claude continuent de fonctionner selon les accords existants et les réglages de conservation configurés (support Anthropic).

Fable 5 déplace l’unité de gouvernance de “fournisseur” ou “plateforme” vers “classe de modèle.”

Cela signifie que votre passerelle IA doit comprendre les ID de modèles comme des objets de politique. global.anthropic.claude-fable-5 ne devrait pas se trouver dans le même panier d’allowlist que Sonnet, Haiku ou Opus. Il lui faut une étiquette de risque distincte, des règles de routage distinctes, une journalisation distincte, et probablement un circuit d’approbation distinct.

Une politique d’entreprise saine ressemble désormais à ceci :

  • Orienter par défaut les développeurs vers des modèles non-Covered Models pour les tâches ordinaires de code et de support.
  • Placer les modèles de classe Fable/Mythos derrière une approbation explicite par projet.
  • Bloquer les prompts contenant des données réglementées, des secrets, des identifiants clients, des résultats financiers non publiés ou du matériel soumis au contrôle des exportations.
  • Exiger un repo en clean room ou un jeu de fixtures synthétiques pour les exécutions d’agents de code avec Fable.
  • Journaliser chaque invocation avec l’ID du modèle, le mode de conservation, la classification des données, le responsable métier et le ticket.
  • Ajouter un kill switch capable de désactiver les Covered Models à l’échelle de l’organisation sans attendre que chaque équipe mette son code à jour.

C’est du travail de gouvernance ennuyeux. C’est aussi ce qui permet aux entreprises d’utiliser des modèles puissants sans faire semblant qu’une transcription de code conservée est inoffensive.

Diagramme de flux de politique pour une passerelle IA d’entreprise : la requête développeur entre dans un classificateur, bifurque selon la classification des données et

Le vrai compromis : capacités maintenant, frontières nettes plus tard

Ma position : AWS et Anthropic ont eu raison de rendre explicite le compromis de conservation, mais Fable 5 ne devrait pas être activé par défaut dans des environnements d’ingénierie sérieux.

La transparence est une bonne chose. L’adéquation produit est plus étroite que ne le laisse entendre le battage du lancement.

Si vous construisez un prototype, migrez une base de code open source, analysez des documents publics ou travaillez dans un bac à sable approuvé par une red team, le compromis de Fable 5 peut être raisonnable une fois l’accès rétabli. Le modèle est cher, mais la vraie question est de savoir s’il termine une longue tâche avec moins de cycles humains. Anthropic affirme que Fable 5 prend davantage l’avantage sur les travaux longs et complexes, et les premiers retours clients évoquent des migrations ambitieuses et des exécutions de code agentiques (Anthropic).

Si vous travaillez sur le moteur de transactions d’une banque, un pipeline de dossiers médicaux, le dépôt d’un sous-traitant gouvernemental, une conception de puce non publiée, des exports de support client ou un incident de production impliquant des secrets, la réponse par défaut devrait être non. Pas “non pour toujours.” Non jusqu’à ce que le juridique, la sécurité et le propriétaire des données acceptent le nouveau sous-traitant et le nouveau chemin de conservation.

C’est ici que les équipes doivent arrêter d’externaliser leur jugement vers la confiance dans une marque cloud. Bedrock n’est pas une enveloppe magique de confidentialité. C’est une plateforme avec des exceptions spécifiques aux modèles. L’exception est maintenant attachée au modèle de pointe que tout le monde veut essayer.

La suspension du 12 juin par Anthropic rend cela encore plus clair. Le même modèle qui exigeait une conservation de sécurité de 30 jours a été retiré parce que le gouvernement américain invoquait des préoccupations de sécurité nationale autour d’un jailbreak possible, une affirmation qu’Anthropic conteste (Anthropic). Cette séquence devrait calmer toutes les réunions de roadmap. Les modèles de pointe ne sont plus seulement des dépendances. Ce sont des surfaces de politique volatiles.

Ce que les équipes développeurs devraient faire cette semaine

Commencez par l’inventaire. Cherchez les ID de modèles Fable et Mythos dans votre code, vos notebooks, Terraform et vos docs internes. Puis appliquez la politique au niveau de la passerelle plutôt que de faire confiance à chaque point d’appel SDK.

Si vous utilisez Bedrock, vérifiez si provider_data_share a été activé et qui peut modifier ce réglage. Traitez-le comme un contrôle d’exfiltration de données en production, pas comme une préférence de modèle. Si votre organisation a des engagements contractuels ZDR, partez du principe que Fable 5 est hors du chemin approuvé jusqu’à avis contraire du juridique.

Pour les agents de code, créez un espace de travail “frontier-safe” : pas de secrets, pas de données clients, pas de logs d’incidents privés, pas de datasets propriétaires sauf approbation explicite. Donnez au modèle un paquet de tâches étroit, pas tout votre monorepo plus un export Slack plus une console de base de données.

Pour les achats, mettez à jour le questionnaire. Posez ces questions aux fournisseurs de modèles et aux plateformes cloud, classe de modèle par classe de modèle :

  • Les prompts et sorties sont-ils conservés ? Pendant combien de temps ?
  • Qui les stocke, le fournisseur cloud ou le fournisseur de modèle ?
  • Des humains peuvent-ils les examiner ? Sous quels déclencheurs ?
  • Sont-ils utilisés pour l’entraînement, l’ajustement sécurité, l’évaluation de classificateurs ou la détection des abus ?
  • Quels journaux d’audit le client peut-il voir ?
  • Que se passe-t-il en cas de legal hold, d’enquête de sécurité ou d’ordre gouvernemental ?
  • Le client peut-il désactiver le modèle à l’échelle de l’organisation ?

Le lancement de Fable 5 n’a pas rendu Bedrock mauvais. Il a rendu obsolète la gouvernance Bedrock paresseuse.

Voilà la leçon utile. L’avenir aura davantage de modèles comme celui-ci : très capables, chers, surveillés et entourés de conditions spéciales. Les gagnants ne seront pas les équipes qui les interdisent tous ni celles qui les activent tous aveuglément. Les gagnants seront les équipes qui routent le travail selon sa sensibilité, prouvent où les données sont allées et réservent les capacités de pointe aux tâches qui valent le coût de gouvernance.

Les lecteurs qui veulent essayer Claude Fable 5 eux-mêmes peuvent l’utiliser via Claude Fable 5 sur OneHop, un endpoint compatible direct facturé environ 30 % sous le prix catalogue. Les nouveaux comptes peuvent commencer avec 10 $ offerts, sans carte bancaire.

À lire aussi : Bien démarrer avec Claude Fable 5.