Prendre RDV
Lexique · Frameworks / outils IA

Amazon Bedrock : définition, fonctionnement et exemple

Le service managé d'AWS qui donne accès par API à des modèles de fondation de plusieurs fournisseurs : catalogue, API Converse, bases de connaissances, agents, guardrails, exemple en Python et comparatif.

Par Équipe Blent· Mis à jour le · 14 min de lecture· Niveau intermédiaire

Amazon Bedrock en bref

Type
Service managé d'IA générative (API)
Éditeur
Amazon Web Services
Annonce
Avril 2023, disponibilité générale en septembre 2023
Modèles
Anthropic, Meta, Mistral AI, Amazon Nova, etc.

Définition : Amazon Bedrock

Amazon Bedrock est un service managé d'Amazon Web Services qui donne accès, par une API unique, à des modèles de fondation proposés par plusieurs fournisseurs, parmi lesquels Anthropic, Meta, Mistral AI et Amazon avec sa famille Nova. Il n'y a aucun serveur ni GPU à administrer : AWS héberge l'inférence et facture à l'usage. Autour des modèles, Bedrock ajoute des briques prêtes à l'emploi, comme les bases de connaissances pour le RAG, les agents, les guardrails de sécurité et l'évaluation, le tout intégré aux droits et au réseau du compte AWS. Il sert à construire des applications d'IA générative dans un environnement cloud déjà gouverné.

En une phrase : Amazon Bedrock donne accès aux modèles de plusieurs éditeurs par une seule API AWS, avec RAG, agents et guardrails intégrés.

Dans cette définition

Qu'est-ce qu'Amazon Bedrock ?

Amazon Bedrock est le service d'IA générative managé d'Amazon Web Services. Plutôt que d'héberger soi-même un LLM sur des GPU, on appelle par API un modèle de fondation hébergé par AWS, et on paie à l'usage. Le catalogue regroupe des modèles de plusieurs éditeurs, dont Anthropic, Meta AI, Mistral AI et les modèles Amazon Nova.

AWS a annoncé Bedrock en avril 2023 et l'a rendu disponible à tous en septembre 2023. Le service a depuis dépassé le simple accès à des modèles : il propose des bases de connaissances pour le RAG, des agents, des guardrails, des outils d'évaluation et de personnalisation des modèles, ainsi qu'AgentCore, une couche dédiée à l'exécution d'agents en production.

Bedrock est un produit, pas un modèle ni un éditeur de modèles. Il se distingue de l'API directe d'un laboratoire par son cadre : les accès passent par IAM, le trafic peut rester dans un réseau privé, et la facture est celle du compte AWS. C'est ce qui le rend attractif pour les organisations dont les données sont déjà dans S3 ou ailleurs sur AWS.

À retenir : Bedrock n'est pas un modèle. C'est une porte d'accès managée à des modèles de plusieurs éditeurs, avec les services AWS autour.

Comment fonctionne Amazon Bedrock ?

Utiliser Bedrock revient à choisir un modèle, l'appeler par API, puis à ajouter progressivement les briques de RAG, d'agent et de sécurité.

  1. Choisir un modèle

    On sélectionne un modèle du catalogue selon la qualité, la latence, le coût et la région AWS disponible. Selon le modèle, un accès doit d'abord être activé pour le compte.

  2. Appeler l'API

    Le SDK AWS envoie les messages au service bedrock-runtime. L'API Converse offre un format unique de conversation, ce qui permet de changer de modèle en modifiant un identifiant.

  3. Brancher les données

    Une base de connaissances indexe les documents depuis Amazon S3, les découpe, les vectorise et les stocke dans une base vectorielle, pour alimenter un RAG sans code de pipeline.

  4. Ajouter agents et outils

    Un agent planifie les étapes, appelle des fonctions AWS Lambda ou des API et interroge les bases de connaissances. Le protocole MCP est aussi pris en charge côté outils.

  5. Encadrer et surveiller

    Les guardrails filtrent les entrées et les sorties, les droits IAM restreignent l'accès aux modèles, et CloudWatch et CloudTrail tracent l'usage et les coûts.

Exemple : appeler un modèle avec l'API Converse

Une équipe veut résumer des tickets de support depuis une fonction AWS, avec un modèle qu'elle pourra remplacer plus tard. Le code suivant utilise le SDK Python boto3 et l'API Converse. L'identifiant du modèle est lu dans une variable d'environnement, car il dépend de la région et du modèle activé dans le compte.

python
import os

import boto3

# Client du service d'inférence, dans la région choisie
client = boto3.client("bedrock-runtime", region_name="eu-west-3")

# Identifiant du modèle activé dans le compte (variable d'environnement)
model_id = os.environ["BEDROCK_MODEL_ID"]

ticket = "Bonjour, ma commande n'est jamais arrivée et personne ne répond à mes mails."

response = client.converse(
    modelId=model_id,
    system=[{"text": "Tu résumes les tickets de support en une phrase."}],
    messages=[{"role": "user", "content": [{"text": ticket}]}],
    inferenceConfig={"maxTokens": 200, "temperature": 0.2},
    # Optionnel : applique un guardrail créé au préalable
    # guardrailConfig={"guardrailIdentifier": "<id>", "guardrailVersion": "1"},
)

print(response["output"]["message"]["content"][0]["text"])
print(response["usage"])  # tokens en entrée et en sortie, base de la facturation

Le format des messages est identique d'un modèle à l'autre : pour passer d'un modèle à un autre, on change BEDROCK_MODEL_ID, sous réserve que le modèle ait été activé. Le champ usage renvoie le nombre de tokens consommés, utile pour suivre les coûts. L'appel s'authentifie avec les droits IAM de l'environnement d'exécution, sans clé d'API à gérer dans le code.

Les briques autour des modèles

Au-delà de l'appel direct, Bedrock regroupe des services que l'on active selon le besoin.

  • Bases de connaissances : elles ingèrent des documents (S3, sites web, autres sources), les découpent, calculent leurs embeddings et les rangent dans une base vectorielle. On peut ensuite récupérer des passages ou générer une réponse sourcée.
  • Agents : un agent reçoit un objectif, planifie des étapes, appelle des outils (fonctions Lambda, API) et peut interroger une base de connaissances. Pour décider entre un simple RAG et un agent, voir notre comparatif RAG vs Agents.
  • Guardrails : ils filtrent les contenus indésirables, masquent les données personnelles et détectent certaines tentatives de détournement, en entrée comme en sortie. Ils s'appliquent à un modèle quelconque du catalogue. Le principe est détaillé dans Guardrails : sécuriser les agents IA.
  • Personnalisation et évaluation : certains modèles peuvent être adaptés par fine-tuning, et des outils comparent les modèles ou jugent la qualité des réponses.

AgentCore

AgentCore est la brique conçue pour exécuter des agents en production, quel que soit le framework ou le modèle utilisé : exécution isolée, mémoire, identité, passerelle d'outils et observabilité. Il se positionne à côté de Bedrock Agents, qui reste l'option la plus intégrée et la moins configurable.

Les principaux cas d'usage d'Amazon Bedrock

Bedrock convient aux équipes dont l'infrastructure et les données sont déjà sur AWS et qui veulent des modèles sans les héberger.

  • Assistant interne

    Répondre aux questions des équipes à partir de la documentation de l'entreprise.

  • Support client

    Résumer les échanges et proposer des réponses dans un centre de contact.

  • Traitement de documents

    Extraire et classer des informations dans des contrats, factures ou rapports.

  • Génération de code

    Assister les développeurs avec des modèles de code derrière une API gouvernée.

  • Agents métier

    Automatiser des tâches en enchaînant appels de modèle et actions sur des API.

  • Recherche sémantique

    Interroger un corpus par le sens avec les modèles d'embedding du catalogue.

Quels sont les avantages d'Amazon Bedrock ?

L'intérêt de Bedrock est d'abord organisationnel : des modèles variés dans le cadre de sécurité et de facturation d'AWS.

  • Un seul accès, une seule facture et une seule API pour des modèles de plusieurs éditeurs.
  • Aucune infrastructure d'inférence à dimensionner, à mettre à jour ou à superviser.
  • Intégration native à IAM, au réseau privé, au chiffrement et à la journalisation d'AWS.
  • Briques prêtes à l'emploi pour le RAG, les agents et les guardrails.
  • Changement de modèle facilité par l'API Converse, sans réécrire l'application.
  • Les données envoyées ne servent pas à entraîner les modèles des fournisseurs, selon la documentation AWS.

Quelles sont les limites d'Amazon Bedrock ?

Le confort du service managé s'accompagne d'une dépendance à AWS, et le catalogue n'est pas identique dans toutes les régions.

  • Le catalogue, les quotas et les fonctionnalités varient selon la région AWS.
  • Les nouveaux modèles d'un éditeur arrivent parfois plus tard que sur son API d'origine.
  • Les briques managées (bases de connaissances, agents) offrent moins de contrôle qu'un pipeline codé à la main.
  • Le coût se maîtrise mal sans suivi des tokens, du cache et des capacités réservées.
  • Le code qui utilise les fonctions propres à Bedrock se porte difficilement vers un autre cloud.
  • Les modèles ne sont pas hébergés chez vous : ce service ne répond pas à une exigence de déploiement sur site.

Amazon Bedrock vs Google Cloud Vertex AI et Azure AI Foundry : quelles différences ?

Les trois grands clouds proposent désormais un service managé qui regroupe plusieurs modèles de fondation. Les écarts tiennent surtout à l'écosystème de chacun.

CritèreAmazon BedrockGoogle Cloud Vertex AIAzure AI Foundry
CloudAWSGoogle CloudMicrosoft Azure
Modèles pharesClaude, Llama, Mistral, NovaGemini, et modèles tiersModèles d'OpenAI, et modèles tiers
API unifiéeConverseAPI Gemini et API ouvertesAPI Azure OpenAI et API d'inférence
RAG managéKnowledge BasesVertex AI Search et RAG EngineAzure AI Search
AgentsAgents, AgentCoreAgent BuilderFoundry Agent Service
Garde-fousGuardrailsFiltres de sécuritéContent Safety
IntégrationS3, IAM, LambdaBigQuery, IAMEntra ID, Microsoft 365

Les noms et le périmètre exact de ces offres évoluent vite : il faut vérifier la documentation de chaque fournisseur avant de décider. Le critère déterminant reste souvent l'emplacement des données : déplacer un entrepôt entier pour accéder à un modèle coûte plus cher que de changer de modèle.

Ce n'est pas un choix binaire. Rien n'empêche d'utiliser un modèle via Bedrock pour sa gouvernance AWS et un autre via une API directe, à condition de garder une couche d'abstraction fine entre l'application et le modèle.

Mise en production : points de vigilance

Quelques réflexes évitent les mauvaises surprises. Vérifier le catalogue et les quotas dans la région visée avant l'architecture. Limiter les droits IAM aux seuls modèles utilisés. Mesurer les tokens par fonctionnalité pour piloter les coûts, comme le décrit FinOps des LLM : API vs self-hosting. Enfin, garder les documents sources et le pipeline de vectorisation maîtrisés dans votre système, pour pouvoir changer de service sans tout reconstruire.

Quand utiliser Amazon Bedrock ?

Le critère principal est l'ancrage de l'organisation dans AWS, plus que la qualité des modèles, que l'on retrouve ailleurs.

Pertinent si

L'environnement est déjà sur AWS

  • Les données et les applications résident dans S3, Lambda ou d'autres services AWS.
  • La sécurité exige IAM, un réseau privé et une traçabilité centralisée.
  • L'équipe veut comparer plusieurs modèles sans multiplier les contrats.
  • Aucune équipe n'est disponible pour exploiter des GPU.
Moins adapté si

Le besoin dépasse le service managé

  • Les modèles doivent tourner sur votre propre infrastructure ou sur site.
  • Le projet vise plusieurs clouds sans dépendance à un fournisseur.
  • Vous voulez un contrôle fin du serveur d'inférence et de ses optimisations.
  • Le volume est stable et élevé, et l'auto-hébergement revient moins cher.

Technologies et outils associés à Amazon Bedrock

Bedrock se combine avec les services AWS de stockage et de calcul, avec les frameworks d'orchestration et avec les offres concurrentes des autres clouds.

Les concepts à connaître autour d'Amazon Bedrock

Ces notions aident à comprendre ce que Bedrock expose et comment ses briques s'articulent.

Ressources pour approfondir Amazon Bedrock

Trois articles du blog Blent pour passer de la définition à la mise en œuvre d'un RAG, d'agents et de garde-fous.

Questions fréquentes

Questions fréquentes

Non. Bedrock se facture à l'usage, le plus souvent selon le nombre de tokens en entrée et en sortie, avec un tarif propre à chaque modèle. Une capacité réservée est possible pour un trafic régulier. Les guardrails et les bases de connaissances ont leur propre tarification, à simuler avant le lancement.

Expertise

À propos de l'auteur

Équipe Blent

Les ingénieurs et mentors Blent conçoivent, évaluent et mettent en production des applications LLM, et forment chaque année des centaines de professionnels à l'IA générative.

Sources et méthodologie

  • Documentation officielle Amazon Bedrock (API Converse, bases de connaissances, agents, guardrails)
  • Annonce d'Amazon Bedrock par AWS, avril 2023, et disponibilité générale en septembre 2023
  • Document history du guide utilisateur Amazon Bedrock, AWS
  • Retours d'expérience des projets et formations Blent
Lexique

Explorer le lexique

Voir toutes les définitions