Accéder à l'API

Pour construire des applications avec des modèles IA, il faut d’abord comprendre le flux de données entre l’entrée utilisateur et la réponse générée — qui parle à qui, dans quel ordre, et où vivent les secrets. Voyons comment cela fonctionne avec AWS Bedrock, sur l’exemple le plus classique qui soit : une application de chat.

Fonctionnement d’une application de chat

Imaginez que vous construisez une application web avec une interface de chat. Un utilisateur tape « Définir l’informatique quantique » et clique sur envoyer. Voici ce qui se passe en coulisses :

1. L’utilisateur soumet son message via l’interface web
2. Votre serveur reçoit la requête contenant ce texte
3. Votre serveur utilise le client Bedrock pour envoyer une requête à AWS Bedrock
4. La requête inclut le message utilisateur et un identifiant de modèle (par ex. Claude Haiku ou Claude Sonnet)
5. Le modèle choisi traite la requête et génère du texte
6. AWS Bedrock renvoie un message assistant contenant la réponse générée
7. Votre serveur transmet cette réponse au navigateur de l’utilisateur

Deux segments, deux responsabilités

Relisez la séquence en la pliant en deux : les étapes 1-2 et 7 relient le navigateur à votre serveur ; les étapes 3-6 relient votre serveur à Bedrock. Cette architecture en deux segments n’est pas un choix esthétique — elle est imposée par la sécurité. Appeler Bedrock exige des identifiants AWS, et ces identifiants ne doivent jamais approcher le code côté client : tout ce qu’un navigateur télécharge est lisible par son utilisateur, requêtes comprises. Des identifiants AWS exposés dans une page web, c’est votre compte — et pas seulement Bedrock — offert au premier curieux. Le serveur intermédiaire est donc la règle absolue : lui seul détient les identifiants, lui seul parle à AWS, et il ne transmet au navigateur que le texte des réponses.

L’identifiant de modèle

L’étape 4 mentionne un détail qui structure tout le développement sur Bedrock : chaque requête nomme explicitement son modèle. Bedrock héberge plusieurs modèles de la famille Claude — et d’autres fournisseurs —, chacun derrière son identifiant. Le choix engage un triple compromis : capacité de raisonnement, latence, coût par token. Une application réelle mélange d’ailleurs souvent les modèles — un modèle rapide pour classifier, un modèle puissant pour rédiger — puisque le choix se fait requête par requête. La prochaine leçon passe en revue la famille Claude et les critères de choix.

Ce que Bedrock change — et ne change pas

Si vous avez déjà utilisé l’API Anthropic directement, le schéma vous est familier ; ce qui change avec Bedrock, c’est le fournisseur d’accès. L’authentification passe par IAM plutôt que par une clé API Anthropic, les modèles s’activent par région dans la console AWS, et la facturation rejoint votre facture AWS. Ce qui ne change pas : Claude lui-même — mêmes capacités, mêmes principes de prompting, même logique de conversation. Tout ce que ce cours enseigne sur la façon de parler au modèle est transposable ; seul le guichet d’entrée est propre à AWS.

Points clés à retenir

• Le flux traverse toujours deux segments : navigateur → votre serveur → Bedrock — jamais de liaison directe
• Les identifiants AWS vivent exclusivement côté serveur : le code client est public par nature
• Chaque requête nomme son modèle : le choix capacité/latence/coût se fait requête par requête
• Bedrock = accès à Claude par l’infrastructure AWS (IAM, régions, facturation) ; le modèle reste identique
• La suite : panorama des modèles Claude, puis configuration de l’accès dans votre compte