InfrastructureAWS ML Blog · 20 juil. 2026, 20:58· 2 min de lecture

Couchbase construit une architecture IA multi-modèle pour Capella iQ avec Amazon Bedrock

Le fournisseur de bases de données Couchbase a fait évoluer son assistant de développement Capella iQ pour s'appuyer sur Amazon Bedrock et la famille de modèles Claude d'Anthropic, en remplacement d'une architecture d'inférence à modèle unique. Le projet, décrit dans un billet co-écrit avec Tushar Madaan de Couchbase, repose sur une infrastructure déployée sur deux régions AWS, us-east-1 et us-west-2, afin de garantir une haute disponibilité. Un cluster Amazon EKS héberge trois microservices clés dans us-east-1 : cp-api, qui reçoit les requêtes des développeurs et orchestre les appels d'inférence ; cp-internal-api, qui gère la communication interne et la logique de routage des modèles ; et cp-ns, qui gère la configuration au niveau des espaces de noms, notamment les préférences de fournisseur de modèles par client. Un point de terminaison d'interface VPC assure une connectivité privée entre ce cluster et le runtime d'Amazon Bedrock, permettant d'exploiter l'inférence multi-région (Cross-Region Inference, ou CRIS) sur trois régions américaines : us-east-1, us-east-2 et us-west-2.

Cette bascule répond à un besoin très concret de résilience opérationnelle et de flexibilité pour les grandes entreprises clientes de Couchbase. En s'appuyant sur l'inférence multi-région d'Amazon Bedrock, Capella iQ peut absorber des pics de trafic soudains et basculer automatiquement vers une région disponible en cas de dégradation, sans capacité pré-provisionnée et sans logique applicative supplémentaire à gérer côté Couchbase. Autre point important pour les clients entreprise : l'intégralité du trafic d'inférence, prompts et réponses inclus, transite exclusivement par l'infrastructure privée d'AWS et ne passe jamais par l'internet public, ce qui répond aux exigences de sécurité et de résidence des données propres à ce type de clientèle. Concrètement, quand un développeur demande à Capella iQ de générer une requête SQL++, de recommander un index ou de poursuivre une conversation multi-tours, le pod cp-api authentifie la demande, récupère le contexte de session, construit le prompt en intégrant l'historique de conversation, puis transmet l'appel via le point de terminaison VPC vers Bedrock, avant de renvoyer la réponse normalisée au développeur.

Cette évolution s'inscrit dans la tendance plus large des éditeurs de logiciels d'entreprise à adopter des architectures d'inférence agnostiques par rapport au modèle, plutôt que de rester dépendants d'un unique fournisseur de LLM. Face à la croissance de l'adoption de Capella iQ, Couchbase avait besoin d'un système capable de s'adapter aux préférences de déploiement variées de ses clients tout en conservant une infrastructure scalable et robuste. Le choix d'Amazon Bedrock comme couche d'inférence permet à Couchbase de bénéficier directement des capacités de basculement régional et de répartition de charge gérées par AWS, sans avoir à développer cette logique en interne. Cette approche illustre aussi comment les modèles Claude d'Anthropic s'intègrent de plus en plus dans des produits d'infrastructure de données critiques, où la fiabilité, la confidentialité des données et la conformité pèsent autant que la qualité pure des réponses générées.

Dans nos dossiers

AWS Anthropic

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

1AWS ML Blog

Ampersend crée un modèle de paiement à l'usage pour agents IA avec Amazon Bedrock AgentCore Payments

Ampersend, une plateforme de gestion des paiements pour agents IA développée par Edge & Node, a annoncé la mise en production d'une couche de routage pay-per-intelligence construite sur Amazon Bedrock AgentCore Payments. Le système permet à des agents autonomes de sélectionner dynamiquement un modèle de langage adapté à leur tâche, résumé de document, audit de smart contract, analyse de données on-chain, puis de régler la prestation par requête, sans intervention humaine, en s'appuyant sur le protocole ouvert x402. L'infrastructure repose sur un mécanisme en deux sauts : l'agent appelle Ampersend, qui règle ensuite le fournisseur de modèle en aval via son propre SDK. Le tout se pilote depuis un point d'intégration unique, sans abonnement distinct par fournisseur. Jusqu'ici, connecter un agent IA à des services payants réclamait des mois de travail préalable : gestion de portefeuilles cryptographiques, signature des paiements, respect des limites de dépenses, intégration avec la facturation de chaque fournisseur. Ce fardeau infrastructure freinait considérablement le déploiement d'agents en production. AgentCore Payments supprime ce prérequis en offrant une couche de gouvernance clé en main : un Payment Manager définit les règles de dépense et les connexions aux portefeuilles, tandis qu'une Payment Session ouvre un contexte d'exécution borné avant chaque run d'agent. Résultat concret pour les développeurs : ils écrivent la logique métier de l'agent sans s'occuper de la plomberie financière. Pour des plateformes comme Ampersend, c'est la possibilité d'agréger des dizaines de fournisseurs de modèles derrière une interface de paiement unique, sécurisée et auditée nativement. Ce lancement s'inscrit dans une tendance plus large : l'émergence d'une économie machine-to-machine où les agents IA deviennent des acteurs économiques à part entière, capables de consommer des APIs payantes de façon autonome. Le protocole x402, sur lequel repose l'architecture, est conçu pour des transactions programmatiques instantanées, à l'image de ce qu'HTTP fait pour les échanges de données. Amazon, avec Bedrock AgentCore, consolide sa position d'infrastructure sous-jacente pour les stacks agentiques d'entreprise, aux côtés de ses outils d'orchestration existants. Ampersend, de son côté, parie que la fragmentation du marché des modèles, OpenAI, Anthropic, modèles open source, spécialistes verticaux, rendra indispensable ce type de couche d'abstraction de paiement. Les prochaines étapes probables incluent l'extension du catalogue de modèles, des politiques de dépense plus granulaires, et l'intégration avec d'autres protocoles de paiement agentic émergents.

InfrastructureActu

1 source

2AWS ML Blog

« Simplifier l'accès multi-comptes aux modèles Amazon Bedrock avec les habilitations gérées »

Les organisations qui exploitent des dizaines, voire des centaines de comptes AWS font face à un dilemme récurrent pour l'accès aux modèles d'intelligence artificielle sur Amazon Bedrock. AWS distingue trois catégories de modèles : les modèles Amazon comme Nova, les modèles vendus par Amazon tels que ceux de Meta, Mistral ou DeepSeek, accessibles immédiatement avec de simples permissions Bedrock, et les modèles tiers commercialisés via AWS Marketplace, comme Claude d'Anthropic, ceux de Cohere ou de Stability AI, qui exigent un abonnement Marketplace distinct dans chaque compte. Jusqu'ici, les équipes devaient soit accorder largement des permissions Marketplace à tous les comptes de travail, au risque de fragiliser la gouvernance, soit activer manuellement chaque abonnement compte par compte, une charge opérationnelle lourde qui ralentit l'adoption de l'IA à grande échelle. AWS présente désormais les "managed entitlements" pour Bedrock, une fonctionnalité qui permet de souscrire une seule fois depuis un compte central puis de distribuer l'accès aux modèles à travers toute l'organisation, via AWS License Manager, sans qu'aucune permission Marketplace ne soit nécessaire dans les comptes membres. Cette nouveauté change concrètement la donne pour les équipes cloud et sécurité chargées de gouverner l'usage de l'IA générative à l'échelle d'un groupe. Elle s'adresse en priorité aux organisations qui font tourner des charges de travail sur de multiples comptes AWS, qui veulent éviter de diffuser des droits Marketplace à chaque équipe, qui ont négocié des tarifs préférentiels via une offre privée et souhaitent les appliquer uniformément, ou qui ont besoin d'une visibilité centralisée sur qui accède à quels modèles. À l'inverse, les structures qui n'utilisent que des modèles Amazon ou partenaires, qui opèrent sur un compte unique, ou dont les équipes gèrent déjà leurs abonnements de façon autonome n'ont pas vraiment besoin de ce mécanisme. Le bénéfice principal réside dans la réduction du risque de mauvaise configuration et dans l'accélération du déploiement de modèles comme Claude à travers de grandes organisations, tout en gardant un contrôle centralisé. Sur le plan technique, la mise en place suppose qu'AWS Organizations soit configuré avec toutes les fonctionnalités activées, qu'un accès au compte de gestion soit disponible avec les permissions AWS Marketplace et AWS License Manager, et que des rôles liés aux services (service-linked roles) soient créés pour ces deux services. Le concept central repose sur deux notions : la licence, qui représente le droit de l'organisation à utiliser un modèle donné, et les attributions ("grants"), le mécanisme par lequel ce droit est partagé avec des comptes spécifiques. Cette approche s'inscrit dans la suite logique d'autres outils Bedrock comme l'évaluation de modèles ou les garde-fous (guardrails), qui visent tous à concilier autonomie des équipes et gouvernance centralisée des déploiements d'IA en entreprise.

InfrastructureActu

1 source

3AWS ML Blog

« Mise en œuvre de patterns de résilience avec Amazon Bedrock et une passerelle LLM »

Amazon Web Services a publié un article technique détaillant cinq patterns de résilience pour les déploiements d'inférence de grands modèles de langage (LLM) sur Amazon Bedrock, conçus pour accompagner les charges de travail d'IA générative qui passent de la phase expérimentale à la production à grande échelle. Le premier de ces patterns repose sur l'inférence cross-Region (CRIS) d'Amazon Bedrock, une fonctionnalité native qui redirige automatiquement les requêtes depuis une région source vers la région de destination optimale, en tenant compte en temps réel de la disponibilité, de la latence et de la demande. Les patterns suivants montent en complexité jusqu'à une orchestration multi-modèles via une passerelle LLM (LLM gateway), permettant de combiner plusieurs fournisseurs et modèles selon les besoins. Un dépôt GitHub accompagne l'article avec des exemples de code pour chaque pattern, afin que les développeurs puissent les tester directement dans leur propre environnement AWS. Cette approche progressive répond à des problèmes concrets rencontrés par les équipes qui exploitent des applications IA en production: l'épuisement soudain des quotas lors de pics de trafic imprévus, les effets de "voisin bruyant" dans les environnements multi-tenants, ou encore le besoin de répartir géographiquement l'inférence pour maximiser la disponibilité. Au-delà de la simple continuité de service, ces patterns ouvrent aussi la voie à une optimisation des coûts grâce à un routage intelligent des requêtes, et donnent aux équipes la liberté de basculer entre plusieurs modèles ou fournisseurs selon les contraintes de performance ou de budget. Pour des entreprises qui dépendent désormais de l'IA générative dans leurs produits, ces garanties de résilience deviennent aussi critiques que celles déjà appliquées aux architectures cloud traditionnelles. AWS rappelle que les bonnes pratiques classiques de résilience, comme la stabilité statique ou les mécanismes de backoff et de nouvelles tentatives, restent valables, mais que l'IA générative introduit des contraintes inédites: disponibilité fluctuante des modèles, quotas qui évoluent rapidement, limites de tokens variables selon les fournisseurs, et nécessité de maintenir une cohérence de comportement face aux nouvelles versions de modèles publiées régulièrement. L'article structure sa réflexion autour de quatre dimensions clés, la disponibilité, le temps de réponse, le coût et le débit, en précisant que ce premier volet se concentre sur la disponibilité via le basculement, la répartition géographique et l'isolation des quotas. AWS annonce que de prochains articles approfondiront l'optimisation du temps de réponse et le routage sensible aux coûts, signe que la firme entend documenter une stratégie complète de résilience pour les architectures d'inférence LLM en production.

InfrastructureActu

1 source

4AWS ML Blog

Construire des systèmes multi-agents LangGraph serverless et scalables sur AWS avec Amazon Bedrock AgentCore

Amazon Web Services a présenté une architecture de référence pour déployer des systèmes multi-agents d'IA générative à grande échelle sur AWS, en combinant LangGraph, AWS Lambda, AWS Step Functions et les deux nouveaux services Amazon Bedrock AgentCore Memory et AgentCore Observability. L'approche repose sur une infrastructure entièrement serverless : les agents LangGraph sont packagés dans des conteneurs Docker exécutés sur Lambda, ce qui permet une montée en charge automatique sans gestion d'infrastructure. Pour illustrer le concept, AWS décrit un système concret de révision de campagnes marketing orchestrant trois agents spécialisés en parallèle, un agent "persona reviewer" qui évalue la résonance du contenu auprès de différents profils démographiques, un agent "validator" qui vérifie la conformité juridique et les chartes de marque, et un agent "finalizer" qui synthétise les retours en recommandations actionnables. Une interface React permet aux utilisateurs de télécharger leurs documents et de consulter les résultats en temps réel. Ce type d'architecture répond à un problème concret que rencontrent les entreprises en production : les agents IA performants en démo s'effondrent souvent sous la charge réelle, perdent le contexte entre les sessions et restent des boîtes noires difficiles à déboguer. AgentCore Memory résout la question de la mémoire en offrant à la fois un contexte conversationnel à court terme et une base de connaissances persistante entre sessions. AgentCore Observability capture quant à lui chaque invocation avec ses entrées et sorties LLM, la latence, et les métriques de chaîne d'outils sur l'ensemble des composants distribués. Pour les équipes en charge de systèmes critiques, c'est un changement de paradigme : il devient possible d'auditer exactement comment un agent a raisonné, quelle décision il a prise à quelle étape, et pourquoi. Cette publication s'inscrit dans une accélération visible chez AWS pour proposer une pile complète d'IA agentique cloud-native, face à la concurrence de Google (Vertex AI Agents) et Microsoft (Azure AI Foundry). LangGraph, développé par LangChain, s'impose progressivement comme standard de facto pour l'orchestration d'agents grâce à son modèle d'exécution en graphe orienté qui rend le flux de contrôle déterministe, parallélisable et conditionnel. L'intégration native avec Lambda et Step Functions est particulièrement stratégique pour les charges de travail "bursty" typiques des agents IA, où la demande est imprévisible et les coûts d'une infrastructure dédiée permanente seraient prohibitifs. La prochaine étape logique pour AWS sera d'étendre ces patterns à des workflows plus complexes impliquant des boucles de feedback humain et des agents à longue durée de vie, un segment encore largement inexploré en production.

InfrastructureActu

1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic