Déployer un assistant qui « connaît » votre entreprise n'est plus un projet de laboratoire. Mais entre la démo qui impressionne et l'outil qui répond juste sur vos données métier, il y a une méthode : le RAG. On vous explique comment on l'opère sur AWS Bedrock, chez nos clients.
Un modèle brillant, mais amnésique
Un grand modèle de langage a lu énormément de choses — mais rien sur vous. Il ignore vos références produits, vos procédures internes, le contrat signé avec tel client le mois dernier. Posez-lui une question précise sur votre activité et, au mieux, il reste vague ; au pire, il invente avec aplomb.
La tentation est de tout réentraîner. C'est long, coûteux, et obsolète dès la prochaine mise à jour de vos données. Il existe bien plus simple.
Le RAG, en deux minutes
Le RAG (Retrieval-Augmented Generation) ne modifie pas le modèle : il lui glisse les bons extraits de vos documents au moment de répondre. Quatre étapes, à chaque question :
- Indexer — vos documents (PDF, wiki, base de données) sont découpés et transformés en vecteurs dans une base de connaissances.
- Rechercher — la question de l'utilisateur sert à retrouver les passages les plus pertinents.
- Augmenter — ces passages sont ajoutés au prompt envoyé au modèle.
- Générer — le modèle répond en s'appuyant sur ces extraits, et cite ses sources.
ReplaceRemoveLe pipeline RAG : vos données restent la source, le modèle se contente de rédiger.
Pourquoi AWS Bedrock
On aurait pu tout assembler à la main. On a fait le choix d'Amazon Bedrock pour quatre raisons très concrètes :
- Multi-modèles — Claude, Llama, Mistral et d'autres, derrière une seule API. On change de modèle sans réécrire l'application.
- Vos données restent chez vous — l'indexation et la recherche vivent dans votre compte AWS, votre région, votre périmètre.
- Sécurité native — chiffrement, IAM, traçabilité : les mêmes garde-fous que le reste de votre SI.
- Zéro infra à gérer — pas de cluster GPU à maintenir, on paie l'usage.
Vos données ne quittent jamais votre périmètre. C'est le modèle qui vient à elles, pas l'inverse.— le principe qu'on répète à chaque atelier
Un exemple concret
Une base de connaissances branchée sur votre extranet, et la question d'un commercial trouve sa réponse en quelques lignes :
# Interroger vos données métier via Amazon Bedrock (RAG géré)
import boto3
agent = boto3.client("bedrock-agent-runtime")
reponse = agent.retrieve_and_generate(
input={"text": "Délai de livraison pour le client Hager ?"},
retrieveAndGenerateConfiguration={
"type": "KNOWLEDGE_BASE",
"knowledgeBaseConfiguration": {
"knowledgeBaseId": "VOTRE_BASE",
"modelArn": "anthropic.claude-sonnet",
},
},
)
print(reponse["output"]["text"])La réponse arrive sourcée, dans la langue de la question, et sans qu'aucune donnée ne soit sortie de votre compte AWS.
À retenir
- Le RAG évite de réentraîner un modèle : vos données restent maîtres.
- Bedrock gère l'indexation, la recherche et la génération, dans votre périmètre.
- On démarre sur un cas d'usage cadré, pas sur « toute l'entreprise » d'un coup.
Par où commencer
Le bon premier projet est étroit et mesurable : un assistant pour le support, une recherche augmentée dans vos procédures, un copilote pour une équipe. On cadre l'usage, on branche une première base, on mesure — puis on étend.
C'est exactement le genre de cas particulier qu'on adore. Parlons de vos données, on vous dira en une séance ce qui est réaliste.