Accéder à l'API
Sur cette page
Avant d’écrire du code, il faut comprendre le trajet d’un message entre l’utilisateur et Claude : qui parle à qui, dans quel ordre, et où vivent les secrets. Puis préparer votre compte AWS pour que la première requête passe.
Le trajet d’un message
Imaginez une application web avec une interface de chat. Un utilisateur tape « Définis l’informatique quantique » et clique sur Envoyer. Voici ce qui se passe :
- L’utilisateur soumet son message dans l’interface web.
- Votre serveur reçoit la requête qui contient ce texte.
- Votre serveur envoie une requête à Bedrock avec son client boto3.
- Cette requête contient le message de l’utilisateur et l’identifiant d’un modèle, par exemple Claude Haiku ou Claude Sonnet.
- Le modèle choisi traite la requête et génère du texte.
- Bedrock renvoie un message
assistantqui contient la réponse. - Votre serveur transmet cette réponse au navigateur de l’utilisateur.
Deux segments, deux responsabilités
Les étapes 1, 2 et 7 relient le navigateur à votre serveur ; les étapes 3 à 6 relient votre serveur à Bedrock. Ce découpage est imposé par la sécurité. Appeler Bedrock exige des identifiants AWS, et ces identifiants ne doivent jamais se trouver dans le code exécuté par le navigateur : tout ce qu’un navigateur télécharge est lisible par son utilisateur. Des identifiants AWS exposés dans une page web peuvent ouvrir bien plus que Bedrock. Votre serveur est donc le seul à détenir les identifiants et à parler à AWS, et il ne renvoie au navigateur que le texte des réponses.
Les identifiants de votre code
boto3 cherche ses identifiants dans un ordre fixe : arguments du client, variables d’environnement, fichiers de configuration de l’AWS CLI, puis rôle de la machine quand le code tourne sur AWS. Sur votre poste, trois voies courantes :
| Voie | Mise en place | Remarque |
|---|---|---|
| IAM Identity Center (SSO) | aws configure sso, puis aws sso login | Identifiants temporaires, la voie recommandée en entreprise |
| Clé d’accès d’un utilisateur IAM | aws configure | Identifiants permanents : à limiter et à faire tourner |
| Clé d’API Bedrock | Variable d’environnement AWS_BEARER_TOKEN_BEDROCK | Clé courte (12 heures au plus) pour la production ; clé longue réservée à l’exploration selon AWS |
En production sur AWS (EC2, Lambda, ECS), on n’utilise aucune clé : le rôle IAM attaché à la ressource fournit des identifiants temporaires. Dans tous les cas, l’identité doit avoir le droit bedrock:InvokeModel, qu’exige l’API Converse, et bedrock:InvokeModelWithResponseStream pour le streaming.
L’accès aux modèles
L’ancienne page d’activation des modèles, région par région, n’est plus un passage obligé. Selon la documentation AWS au 5 novembre 2026, l’accès à beaucoup de modèles est ouvert par défaut, à quelques conditions :
- Abonnement automatique. Au premier appel d’un modèle tiers, Bedrock lance en arrière-plan l’abonnement AWS Marketplace correspondant. Pendant cette mise en place, jusqu’à 15 minutes, les appels peuvent déjà réussir.
- Permissions Marketplace. Pour que cet abonnement aboutisse, l’identité qui fait le premier appel a besoin de
aws-marketplace:Subscribe,aws-marketplace:Unsubscribeetaws-marketplace:ViewSubscriptions. Il faut aussi un moyen de paiement valide sur le compte. - Formulaire d’Anthropic. Pour les modèles Claude appelés par
bedrock-runtime, comme dans ce cours, Anthropic demande une fois par compte (ou une fois pour toute l’organisation AWS) une description de votre cas d’usage, le formulaire « First Time Use ». Il se remplit depuis le catalogue de modèles de la console Bedrock. Un développeur sans site d’entreprise peut indiquer un portfolio ou un profil GitHub. - Critères propres à chaque modèle. La documentation d’Anthropic classe Claude Fable 5.1, Fable 5, Opus 4.8, Opus 4.7, Sonnet 5 et Haiku 4.5 parmi les modèles ouverts à tous les clients de Bedrock. Pour les autres, dont Haiku 5.5, les critères d’accès se lisent dans la console.
Si une condition manque, l’abonnement échoue et les appels suivants renvoient AccessDeniedException. Après correction, comptez jusqu’à 2 minutes avant que l’accès ne s’ouvre.
Ce que Bedrock change, et ce qu’il ne change pas
Si vous avez déjà utilisé l’API Claude directe, le schéma est familier : seul le guichet change. L’authentification passe par IAM plutôt que par une clé Anthropic, la consommation arrive sur la facture AWS, et chaque modèle se nomme par un identifiant propre à Bedrock. Claude lui-même ne change pas : mêmes capacités, mêmes principes de prompting, même logique de conversation.
À vous de jouer
Vérifiez votre accès. Lancez aws sts get-caller-identity pour confirmer l’identité utilisée. Dans la console Bedrock, ouvrez le catalogue de modèles, sélectionnez Claude Haiku 5.5 et vérifiez s’il vous reste un formulaire ou une condition d’accès à remplir.
Cartographiez les secrets. Dessinez l’architecture d’une application de chat que vous pourriez construire et placez-y chaque secret : où vit l’identité AWS, qui peut la lire, et ce qui transite vers le navigateur.
Sources officielles : Accessing the API (Claude Academy) · Access Amazon Bedrock foundation models, API keys et API Converse (documentation AWS) · Credentials (documentation boto3) · Claude in Amazon Bedrock (documentation Claude)
Points clés à retenir
- Le trajet passe toujours par votre serveur : navigateur, serveur, Bedrock, jamais de liaison directe.
- Les identifiants AWS restent côté serveur ; en production sur AWS, un rôle IAM les fournit.
- L’API Converse exige le droit
bedrock:InvokeModel(etbedrock:InvokeModelWithResponseStreampour le streaming). - L’accès aux modèles s’ouvre par défaut, sous conditions : permissions Marketplace, moyen de paiement, formulaire d’Anthropic une fois par compte.
- Bedrock change le guichet d’accès, pas Claude.