bedrock-chat : une plateforme de chat générative qui reste dans votre compte AWS
AWS-native chatbot using Bedrock
En bref
- De quoi s’agit-il ?
- aws-samples/bedrock-chat déploie via CDK un chat Bedrock multi-utilisateurs avec bots RAG, bot store et agents. Voici ce que le dépôt documente réellement, où le modèle multi-tenant change les choses, et pourquoi la migration V2 vers V3 est le vrai point de vigilance.
- À qui s’adresse-t-il ?
- À adopter si vous voulez un chat Bedrock multi-utilisateurs dans votre propre compte AWS, avec Cognito pour l'authentification et des bots RAG partageables. À éviter si vous cherchez un chat mono-utilisateur léger ou si vous dépendez encore de bots V2 : la migration doit être traitée comme un chantier, pas comme une mise à jour.
- Puis-je l’utiliser commercialement ?
- Oui. MIT-0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement TypeScript, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème concret : donner un chat Bedrock à une organisation
Un chat branché sur Amazon Bedrock, c'est quelques dizaines de lignes de code. Le rendre utilisable par une organisation entière, c'est un autre travail : authentification, permissions par utilisateur, historique de conversation persistant, base de connaissances par équipe, partage de bots entre collègues, publication d'un bot sous forme d'API. bedrock-chat prend en charge cette couche applicative. Le README le présente comme une plateforme générative multilingue propulsée par Amazon Bedrock, avec chat, bots personnalisés dotés de connaissances (RAG), partage via un bot store et automatisation de tâches par agents. Le public visé est donc l'équipe qui a déjà choisi Bedrock et qui veut éviter de réécrire un front React, une API FastAPI, une pile Cognito et une couche de vectorisation. Le dépôt est publié par aws-samples, ce qui indique un exemple de référence AWS plutôt qu'un produit éditeur. La licence MIT-0 va dans le même sens : réutilisation large, y compris commerciale, sans obligation d'attribution. C'est un point à connaître avant d'en faire la base d'un service interne.
Ce que le déploiement crée dans le compte
Le déploiement passe par AWS CDK, comme l'indique le badge de workflow cdk.yml et la commande décrite dans le README. La pile s'appelle BedrockChatStack et expose ses sorties dans CloudFormation, notamment AuthUserPoolIdxxxx pour l'identifiant du user pool Cognito. Autour de ce user pool gravitent DynamoDB pour l'état applicatif, Step Functions pour l'ingestion des embeddings, et OpenSearch Serverless comme magasin vectoriel par défaut. Le README précise que si vous voulez utiliser les bots et créer des knowledge bases, il faut déployer dans une région où OpenSearch Serverless et les Ingestion APIs sont disponibles. La liste donnée en août 2025 couvre us-east-1, us-east-2, us-west-1, us-west-2, ap-south-1, ap-northeast-1, ap-northeast-2, ap-southeast-1, ap-southeast-2, ca-central-1, eu-central-1, eu-west-1, eu-west-2, eu-south-2, eu-north-1 et sa-east-1. Le paramètre bedrock-region se choisit séparément, dans une région où Bedrock est disponible. Cette dissociation entre région de déploiement et région Bedrock est une contrainte réelle : elle détermine quels modèles vous pourrez réellement appeler. Le README indique aussi qu'il faut activer l'accès aux modèles dans Bedrock Model access avant de déployer, étape manuelle qui bloque le déploiement si elle est oubliée.
Le mode multi-tenant des Knowledge Bases, ou comment contourner un quota
C'est le détail d'architecture le plus intéressant du dépôt. Le README énonce que, par défaut, Amazon Bedrock Knowledge Bases limite à 100 le nombre de knowledge bases créables dans un seul compte AWS. Pour contourner cette limite, bedrock-chat propose un mode multi-tenant : une knowledge base aux paramètres communs est partagée entre plusieurs bots, et les fichiers téléversés par chaque bot sont filtrés au moyen du Bot ID attaché comme métadonnée. Le filtrage par métadonnée fait donc office de cloison entre locataires. Les nouveaux bots ont ce mode activé par défaut. Pour migrer un bot existant, il faut changer ses paramètres de connaissances vers l'option décrite dans le README, à savoir créer un tenant dans une knowledge base partagée. Pour une migration en masse, le README donne deux commandes : une requête DynamoDB via aws dynamodb execute-statement qui met à jour BedrockKnowledgeBase.type à shared et SyncStatus à QUEUED pour un couple PK et SK donné, puis un appel aws stepfunctions start-execution sur EmbeddingStateMachineArn pour relancer l'ingestion. Le fait que la migration doive être répétée bot par bot, puis suivie d'une exécution de state machine, montre bien que le mode shared n'est pas un simple commutateur global.
Mise en route : les commandes du README
La procédure documentée tient en quelques lignes, exécutées depuis CloudShell dans la région cible. On clone le dépôt, on entre dans le répertoire, on rend le script exécutable et on le lance : git clone https://github.com/aws-samples/bedrock-chat.git, puis cd bedrock-chat, chmod +x bin.sh, ./bin.sh. Le script pose ensuite des questions, dont une sur le fait d'être un nouvel utilisateur ou de venir de la v3. Le README mentionne des paramètres optionnels pour fixer la version à déployer ou appliquer des politiques de sécurité, sans détailler leur nom dans l'extrait fourni. Deux réglages gouvernent l'accès. D'une part, la création de bots personnalisés est réservée aux membres du groupe Cognito CreatingBotAllowed, configurable via la console Cognito ou aws cli, l'identifiant du user pool se lisant dans CloudFormation puis BedrockChatStack, sortie AuthUserPoolIdxxxx. D'autre part, la publication d'un bot en API autonome est décrite dans docs/PUBLISH_API.md. Le README signale aussi qu'un bot peut importer une Knowledge Base Bedrock existante, ce qui évite de re-vectoriser un corpus déjà en place.
La migration V2 vers V3 n'est pas une mise à jour ordinaire
Le README place cet avertissement en tête de document, en encadré : la V3 est sortie, et il faut lire attentivement le guide de migration docs/migration/V2_TO_V3.md. La phrase qui suit est sans ambiguïté, les bots de la V2 deviennent inutilisables sans précaution. Autrement dit, une équipe qui a construit des bots en production sur la V2 doit traiter ce passage comme un projet de migration, avec reprise des données et vérification fonctionnelle, et non comme un changement de version mineur. Le rythme des publications observé dans les métadonnées suggère par ailleurs une base de code active : v3.17.0 en juin 2026, v3.16.0 en avril 2026, v3.15.6 la veille de cette dernière. Cela implique de suivre les notes de version avant de mettre à jour une instance en service, en particulier autour des changements de schéma DynamoDB visibles dans les commandes de migration multi-tenant. La branche par défaut est v3, ce qui signifie que cloner sans préciser de branche donne la version majeure actuelle, pas une branche stable distincte.
Les limites que le dépôt ne masque pas
Trois points méritent d'être posés franchement. Le premier est le coût d'exploitation : la pile combine Cognito, DynamoDB, Step Functions, OpenSearch Serverless et Bedrock. OpenSearch Serverless facture à l'heure de capacité provisionnée, et le README ne fournit aucun chiffrage. Une instance laissée allumée pour une démonstration interne coûte donc en continu, indépendamment du trafic. Le deuxième est la dépendance régionale : hors des régions listées, la création de knowledge bases n'est pas possible, et le choix de bedrock-region conditionne les modèles accessibles. Une organisation contrainte par la résidence des données dans une région non listée devra se passer des bots RAG. Le troisième est le périmètre même du projet : c'est un exemple AWS, pas un logiciel avec support. Le README renvoie vers un atelier et une feuille de route publique, mais rien n'indique d'engagement de maintenance. Enfin, la gouvernance des bots repose sur un groupe Cognito unique, CreatingBotAllowed, ce qui donne un contrôle binaire : soit un utilisateur peut créer des bots, soit il ne peut pas. Le README montre une capture d'écran intitulée fine_grained_permission, mais le texte ne décrit pas de modèle de permissions plus fin, et je ne peux pas confirmer depuis ce matériel ce que cette interface permet exactement.
Face à quoi comparer
L'alternative la plus directe n'est pas un autre chatbot mais une brique d'infrastructure : Amazon Bedrock Agents, ou plus largement les Knowledge Bases Bedrock appelées directement depuis votre propre application. La différence d'approche est nette. Avec bedrock-chat, vous récupérez une application complète et opinionated : interface React, API FastAPI, authentification Cognito, stockage de l'historique, bot store, publication d'API par bot. Vous adoptez ses choix, notamment OpenSearch Serverless comme magasin vectoriel par défaut et la structure de tables DynamoDB visible dans les commandes de migration. Avec un assemblage maison autour des API Bedrock, vous gardez la main sur le magasin vectoriel, les permissions et le schéma de données, mais vous écrivez le front, l'authentification et la persistance. Pour une équipe qui veut un chat interne fonctionnel rapidement et qui accepte la pile imposée, bedrock-chat fait gagner du temps. Pour une équipe qui a déjà une couche d'authentification maison et un magasin vectoriel standardisé, l'intégration de cette pile créera plus de travail qu'elle n'en économise. Le point de bascule est simple : si vous avez besoin de permissions par bot plus fines que le groupe CreatingBotAllowed, vous devrez les ajouter vous-même.
Licence et coût de maintenance
La licence est MIT-0, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un produit commercial, sans obligation d'attribution. Pour une équipe qui craint les licences copyleft, c'est un point favorable. Cela signifie aussi qu'aucune contrepartie n'est exigée en retour, et donc qu'aucun canal de support n'est garanti. Le coût de maintenance se lit dans les commandes du README : les migrations impliquent des écritures DynamoDB ciblées et des exécutions Step Functions, donc un travail de suivi à chaque changement de schéma. Les publications de version observées sur les métadonnées, trois entre avril et juin 2026, suggèrent des mises à jour fréquentes à évaluer avant de les appliquer en production. Le paramètre de version du script bin.sh permet de figer un déploiement, ce qui est la bonne pratique si vous n'avez pas de fenêtre de test. La feuille de route publique, accessible via le label roadmap sur les issues, donne une idée des chantiers en cours, mais je ne peux pas en décrire le contenu à partir du matériel fourni.
Conclusion éditoriale
À adopter si vous voulez un chat Bedrock multi-utilisateurs dans votre propre compte AWS, avec Cognito pour l'authentification et des bots RAG partageables. À éviter si vous cherchez un chat mono-utilisateur léger ou si vous dépendez encore de bots V2 : la migration doit être traitée comme un chantier, pas comme une mise à jour. Avant de déployer, vérifiez deux choses concrètement : que votre région figure dans la liste des régions supportées pour OpenSearch Serverless et les Ingestion APIs, et que le quota de Knowledge Bases de votre compte tient, sinon passez en mode shared. Vérifiez ensuite le groupe Cognito CreatingBotAllowed, sans quoi personne ne pourra créer de bot personnalisé.
Notes de la communauté