aws-samples/generative-ai-use-cases : ce que le dépôt AWS déploie réellement

Le problème : passer d'une démo Bedrock à une application

Un appel à l'API Bedrock tient en quelques lignes. Une application interne qui tient devant un comité de direction demande autre chose : une interface web, une authentification, une gestion des conversations, un stockage, des rôles, et un moyen de masquer les fonctions inutiles. GenU existe pour combler cet écart. Le dépôt se présente comme une implémentation applicative avec des cas d'usage métier pour utiliser l'IA générative en entreprise. Le public visé est donc interne à l'entreprise : équipes plateforme, architectes cloud, développeurs qui doivent livrer un portail IA sur un compte AWS existant, sans repartir de zéro. Le README liste douze cas d'usage par défaut : Chat, Text Generation, Summarization, Meeting Minutes, Writing, Translation, Web Content Extraction, Image Generation, Video Generation, Video Analysis, Diagram Generation et Voice Chat. Tous ne sont pas équivalents en complexité. Le chat et la traduction reposent sur un appel de modèle. Voice Chat suppose une gestion audio bidirectionnelle, avec interruption possible pendant que le modèle parle, ce qui implique une couche temps réel que le README ne détaille pas.

Ce que le dépôt déploie concrètement

Les sujets du dépôt donnent la pile : TypeScript, React, Lambda, Bedrock, SageMaker, rag. Le README confirme Bedrock et SageMaker comme fournisseurs de modèles, et cite parmi les modèles Claude, Nova, Llama 3, Mistral, Command R et DeepSeek-R1. Le front est donc une application React, et la logique côté serveur s'exécute dans des fonctions Lambda, ce qui correspond au schéma classique d'un déploiement AWS CDK. Le README ne décrit pas l'arborescence du CDK, seulement un renvoi vers docs/en/DEPLOY_OPTION.md pour les options complètes. C'est un choix cohérent pour un dépôt d'exemples : le README vend les cas d'usage, la documentation de déploiement porte la configuration. Conséquence pratique : toute décision d'architecture (région, modèle activé, mode d'authentification) se prend en lisant DEPLOY_OPTION.md, pas le README. Un lecteur qui s'arrête à la page d'accueil n'aura aucune idée du coût réel d'exploitation.

RAG : deux chemins, deux niveaux de contrôle

Le RAG de GenU accepte deux sources d'information : Amazon Kendra et Knowledge Base. La différence n'est pas cosmétique. Avec Kendra, le README indique qu'on peut réutiliser un bucket S3 ou un index Kendra créés manuellement. C'est le chemin pour une entreprise qui a déjà un index Kendra en production et veut simplement brancher une interface par-dessus. Avec Knowledge Base, on obtient des fonctions RAG avancées listées dans la documentation : Advanced Parsing, Chunk Strategy Selection, Query Decomposition et Reranking. Ces options se configurent par des clés documentées dans DEPLOY_OPTION.md, par exemple Enabling Advanced Parsing ou Changing Chunking Strategy. Le compromis est clair : Kendra réutilise l'existant mais fige la qualité de recherche sur ce qui est déjà indexé ; Knowledge Base donne la main sur le découpage et le reranking, au prix d'une étape d'ingestion à construire et à surveiller. Le README ne donne aucun chiffre de qualité pour l'une ou l'autre voie, et il n'y a pas de raison d'en inventer.

Mise en route : ce que le dépôt demande

Le README ne fournit pas de bloc de commandes d'installation dans l'extrait disponible. Il renvoie à la documentation en ligne et à docs/en/DEPLOY_OPTION.md pour le déploiement. Les seuls éléments de configuration nommés dans le matériel fourni sont les options de DEPLOY_OPTION.md : masquage de cas d'usage spécifiques via Hiding Specific Use Cases, activation du RAG Chat avec Knowledge Base, activation de Advanced Parsing, changement de stratégie de découpage, activation de Query Decomposition et du Reranking, et réutilisation d'un index Kendra existant via Using an Existing Amazon Kendra Index. Le dépôt fournit une documentation en anglais, japonais et coréen depuis la version 4, ce qui est un signal sur la cible réelle du projet. Autrement dit : pour connaître les commandes exactes d'installation, il faut ouvrir la documentation, pas le README. Un article qui prétendrait citer un npm install ou un cdk deploy précis à partir de ce seul matériel serait en train d'inventer.

La limite structurelle : un dépôt d'exemples, pas un produit

Le nom du dépôt commence par aws-samples, et cela change la lecture. Un dépôt d'exemples AWS vise à démontrer des patterns, pas à garantir une compatibilité ascendante sur plusieurs années. Les versions publiées le confirment : v5.3.0 en octobre 2025, v5.4.0 en janvier 2026, v5.5.0 en juillet 2026. Trois versions majeures en neuf mois environ, avec des sauts de version mineure qui peuvent inclure des changements de configuration. Pour une équipe qui déploie GenU en production, cela signifie qu'une mise à jour n'est pas un simple redémarrage : il faut relire DEPLOY_OPTION.md à chaque saut de version mineure, parce que des clés de configuration peuvent disparaître ou changer de nom. Le cas où GenU est le mauvais outil est celui d'une entreprise qui veut un portail IA avec un SLA contractuel, un support éditeur et une politique de compatibilité. GenU ne promet rien de tel. Il est également mal adapté si vous n'êtes pas sur AWS : toute la logique repose sur Bedrock, SageMaker, Lambda et Kendra.

L'alternative : construire son propre portail sur l'API Bedrock

L'alternative la plus directe n'est pas un autre framework, c'est d'écrire soi-même une application React mince au-dessus de l'API Bedrock, avec sa propre couche Lambda. La différence d'approche est nette. GenU apporte une douzaine de cas d'usage déjà câblés, une documentation d'options et une maintenance suivie par AWS Samples. En échange, vous héritez de son modèle de données, de ses conventions de configuration et de son rythme de versions. Une application maison n'apporte aucun cas d'usage prêt, mais elle vous laisse choisir votre schéma d'authentification, votre format de stockage des conversations et votre stratégie de déploiement sans dépendre d'un DEPLOY_OPTION.md qui évolue. Pour une équipe qui n'a besoin que du chat et du RAG, le coût d'écriture d'une interface minimale peut être inférieur au coût d'adaptation de GenU à chaque version. Pour une équipe qui veut montrer douze cas d'usage en deux semaines, l'arbitrage s'inverse.

Licence MIT-0 et coût de maintenance

Le dépôt est publié sous MIT-0. Cette licence supprime l'obligation d'attribution : vous pouvez réutiliser le code dans un produit interne ou commercial sans conserver de mention de copyright. C'est plus permissif que MIT classique, et cela retire une bonne partie du travail juridique habituel. Cela ne règle pas les questions de conformité liées aux modèles eux-mêmes, qui dépendent des conditions d'utilisation de Bedrock et de SageMaker, distinctes de la licence du code. Sur la maintenance, le matériel disponible ne permet pas d'estimer un coût en heures. Ce qui est vérifiable, c'est la fréquence des versions et l'existence d'une documentation de déploiement séparée : deux signaux qu'une montée de version demande une relecture, pas un simple merge. Le point à vérifier en premier reste la disponibilité régionale des modèles et des fonctions RAG que vous comptez activer.

Conclusion éditoriale

GenU convient aux équipes déjà sur AWS qui veulent une base TypeScript déployable et des cas d'usage prêts à montrer, pas à un produit à maintenir sur plusieurs années. Avant d'adopter, vérifiez dans DEPLOY_OPTION.md quelles options de RAG et de modèles sont réellement supportées par votre région, et confirmez le périmètre de la licence MIT-0 auprès de votre service juridique.

Sources officielles

1. aws-samples/generative-ai-use-cases on GitHub
2. License: MIT-0
3. Project website
4. README
5. Releases