Effectuer une requête

Place au code : votre première requête API à AWS Bedrock. Elle nécessite trois composants essentiels — un client Bedrock Runtime, un identifiant de modèle, et un message utilisateur — et cette leçon les assemble un par un, jusqu’à la première réponse de Claude dans votre notebook.

Configurer le client Bedrock

Commencez par créer un client avec boto3, le SDK AWS pour Python :

import boto3

client = boto3.client("bedrock-runtime", region_name="us-west-2")

Deux choix se cachent dans cette ligne. Le service demandé est bedrock-runtime — celui qui exécute les requêtes d’inférence — à ne pas confondre avec bedrock, le service de gestion (lister les modèles, gérer les accès). Et la région est explicite : votre requête partira vers les serveurs d’us-west-2. Notez ce que ce code ne contient pas : aucun identifiant. boto3 les récupère automatiquement depuis votre configuration AWS (le fichier de credentials ou les variables d’environnement mis en place à la leçon précédente) — vos secrets ne touchent jamais le code.

Identifiants de modèles et disponibilité régionale

La région choisie a une conséquence directe : tous les modèles ne sont pas disponibles dans toutes les régions AWS. Si vous essayez d’utiliser un modèle qui n’existe pas dans votre région, vous obtiendrez une erreur — et une erreur cryptique, qui parle d’accès ou d’identifiant invalide sans jamais dire clairement « pas ici ». Quand un appel échoue ainsi, le réflexe : vérifier la disponibilité régionale avant de soupçonner votre code.

Profils d’inférence

Les profils d’inférence résolvent élégamment ce problème de géographie : au lieu de cibler un modèle dans une région précise, vous utilisez un identifiant de profil qui route automatiquement vos requêtes vers une région où le modèle est effectivement hébergé. Plus de correspondance modèle/région à suivre manuellement — le profil s’en charge, et répartit au passage la charge entre régions. Pour trouver les identifiants de profils d’inférence, allez dans la console AWS Bedrock, rubrique « Cross-region inference » (inférence inter-régions) : c’est cette forme d’identifiant que nous utiliserons dans tout le cours.

Créer des messages utilisateur

Troisième composant, le message. Les messages utilisateur ont une structure spécifique :

user_message = {
    "role": "user",
    "content": [
        {"text": "Combien font 1+1 ?"}
    ]
}

Le contenu est une liste, et ce n’est pas une lourdeur gratuite : un seul message peut contenir différents types de contenu — du texte, des images, des documents. Chaque élément de la liste est un bloc typé ({"text": ...} pour du texte), et cette structure de blocs portera plus tard la vision, les PDF et les outils sans changer de forme.

Effectuer la requête

Tout est prêt ; appelez l’API avec la méthode converse :

response = client.converse(
    modelId=model_id,
    messages=[user_message]
)

converse est l’API de conversation unifiée de Bedrock — même interface quel que soit le modèle sous-jacent. Elle reçoit l’identifiant du modèle (ou du profil d’inférence) et la liste des messages. Pour extraire le texte généré de la réponse :

response["output"]["message"]["content"][0]["text"]

Le chemin se lit ainsi : dans la sortie, un message assistant complet ; dans ce message, une liste de blocs de contenu ; dans le premier bloc, le texte. La symétrie avec ce que nous avons envoyé n’est pas un hasard — la réponse est un message au même format que les nôtres.

Types de messages

Cette symétrie repose sur deux types de messages :

• Messages utilisateur (role: "user") : contenu que vous envoyez au modèle
• Messages assistant (role: "assistant") : contenu que le modèle a produit

Les deux suivent la même structure — un rôle et une liste de blocs de contenu. Cette uniformité facilite le chaînage des requêtes pour des conversations plus longues : la réponse d’un appel peut rejoindre telle quelle la liste des messages du suivant. C’est précisément le mécanisme de la prochaine leçon, les conversations multi-tours.

Points clés à retenir

• Trois composants : client bedrock-runtime (boto3), identifiant de modèle/profil, messages
• Aucun secret dans le code : boto3 lit les identifiants AWS de votre configuration
• Erreur cryptique sur un modèle ? Vérifiez d’abord sa disponibilité dans votre région
• Les profils d’inférence (« Cross-region inference ») routent automatiquement vers une région qui héberge le modèle
• Messages user et assistant partagent la même structure rôle + blocs — la clé du chaînage des conversations