Assistant IA trading Jefferies : l'architecture décortiquée
Une salle de marché produit des milliers de lignes de données par seconde : positions, exécutions, cours, flux FIX. Un trader qui veut vérifier une exposition ou un P&L n'a pas le temps d'ouvrir un ticket auprès de l'IT ni d'attendre qu'un analyste construise un nouveau dashboard. Jefferies, banque d'investissement américaine, a documenté sur le blog technique d'AWS le 10 juin 2026 la façon dont elle a répondu à ce problème avec un assistant conversationnel baptisé Trade Assistant.
Le problème : des données massives, des décisions en une seconde
Le goulot d'étranglement entre traders, experts métier et IT
Avant ce projet, une question métier un peu spécifique — « quelle est mon exposition nette sur tel secteur cet après-midi » — passait souvent par un aller-retour avec une équipe data ou par l'écriture manuelle d'une requête SQL. Ce circuit fonctionne, mais il coûte du temps sur un métier où la fenêtre de décision se compte en secondes.
Pourquoi les dashboards custom ne suffisent plus
Les tableaux de bord préconstruits couvrent les questions récurrentes, pas les questions ad hoc. Chaque nouveau croisement de données qui sort du périmètre prévu nécessite soit un développement spécifique, soit un contournement manuel. C'est ce chaînon que Jefferies a voulu remplacer par une interface en langage naturel.
Ce que fait le trade assistant de Jefferies
Interface conversationnelle embarquée dans le BI maison (GFM)
L'assistant n'est pas une application isolée. Il est intégré directement dans l'outil de business intelligence interne de Jefferies, désigné GFM dans la publication AWS du 10 juin 2026. L'utilisateur pose sa question dans la même interface qu'il utilise déjà pour consulter ses tableaux de bord habituels, sans changer d'outil ni apprendre une nouvelle syntaxe.
Du langage naturel au SQL exécuté sur les sources de trading
La question en langage naturel est traduite en requête SQL, exécutée sur les systèmes de trading, puis le résultat est reformaté en réponse lisible. C'est un usage classique de text-to-SQL, mais appliqué à un contexte à fort enjeu réglementaire et à des sources de données hétérogènes et en temps réel.
L'architecture en clair : Strands, Bedrock, MCP
Le rôle de l'agent d'orchestration Strands
Strands Agents est le kit de développement open source utilisé pour construire l'agent qui orchestre la conversation. Un agent, dans ce contexte, désigne un système qui décompose une requête en étapes, appelle des outils externes, et combine les résultats avant de répondre. Strands gère cette boucle : comprendre l'intention, choisir quelle source interroger, formuler la requête, vérifier le résultat.
RAG sur les métadonnées via Bedrock Knowledge Bases et Titan Embeddings
Pour que l'agent sache quelles tables et colonnes existent sans les injecter en dur dans chaque requête, Jefferies s'appuie sur Amazon Bedrock Knowledge Bases : les schémas de données et leurs métadonnées sont vectorisés puis retrouvés par similarité au moment de la question. C'est une architecture de génération augmentée par récupération (RAG) appliquée non pas à des documents mais à des schémas de bases de données — une variante moins courante que le RAG documentaire classique, mais qui suit le même principe : aller chercher le contexte pertinent avant de générer la réponse.
MCP pour connecter les sources hétérogènes (in-memory, SQL, FIX)
Le Model Context Protocol (MCP) est le standard, popularisé par Anthropic et documenté par AWS le 20 mai 2026, qui permet à un agent d'appeler des outils et des sources de données via une interface unifiée plutôt que par des connecteurs sur mesure pour chacune. Jefferies l'utilise pour relier l'agent à des stores en mémoire, des bases SQL et des flux FIX — le protocole d'échange standard des ordres de marché. Cette couche évite de reconstruire une intégration ad hoc à chaque nouvelle source de données à brancher.
Sécurité et conformité : les garde-fous non négociables
Entitlements au niveau ligne et filtrage PII
Dans une banque, deux traders posant la même question ne doivent pas forcément voir la même réponse : les droits d'accès dépendent du desk, du mandat, de la réglementation applicable. Jefferies applique des entitlements au niveau ligne (row-level), c'est-à-dire un filtrage des données visibles selon l'identité de l'utilisateur, avant même que la réponse ne soit générée. Un filtrage des informations personnelles s'ajoute en sortie.
Bedrock Guardrails, journalisation et pistes d'audit
Amazon Bedrock Guardrails, la fonctionnalité de garde-fou du service, permet de bloquer certains sujets, filtrer des contenus jugés inappropriés et détecter des informations sensibles au niveau du modèle lui-même, en complément des contrôles applicatifs. La documentation AWS insiste sur la journalisation des interactions, condition de base pour toute piste d'audit dans un environnement régulé comme une salle de marché.
Ce que ça ne fait pas : les limites à garder en tête
Fiabilité du text-to-SQL et risque d'hallucination
Aucune publication, ni celle d'AWS ni celle de Jefferies, n'affirme un taux de précision du text-to-SQL. C'est cohérent avec ce que l'on observe ailleurs sur cette technique : un modèle de langage peut générer une requête syntaxiquement correcte mais sémantiquement fausse — mauvaise jointure, filtre oublié, agrégation erronée — sans le signaler. Sur des données de trading, une erreur silencieuse de ce type a un coût direct. Le déploiement décrit repose donc nécessairement sur des contrôles humains et des garde-fous applicatifs, pas sur une confiance aveugle dans la sortie du modèle.
Dépendance au stack AWS et coûts non communiqués
L'architecture décrite est entièrement construite sur des services Amazon : Bedrock pour les modèles et le RAG, Strands comme SDK d'orchestration. Reproduire ce schéma implique soit d'être déjà sur AWS, soit d'accepter cette dépendance. Ni AWS ni Jefferies ne communiquent de chiffres sur le coût d'exploitation, la latence moyenne des requêtes ou le volume de questions traitées quotidiennement. Toute estimation de retour sur investissement resterait donc une spéculation non fondée sur la source disponible.
Par où commencer si vous visez un cas similaire
Trois étapes concrètes avant de lancer un projet comparable, hors secteur bancaire ou dans une PME avec des besoins analytiques similaires.
Cartographier vos schémas de données et vos règles d'accès existantes : un agent text-to-SQL ne corrige pas une gouvernance des données absente, il l'expose.
Tester le text-to-SQL sur un périmètre restreint et non critique, avec un humain qui valide chaque requête générée pendant plusieurs semaines avant toute automatisation complète.
Choisir la brique d'orchestration (Strands Agents, ou un framework équivalent) et le protocole de connexion aux sources (MCP ou une API interne) en fonction de l'infrastructure cloud déjà en place, plutôt que l'inverse.
Sources
Building Trade Assistant: How Jefferies optimized front-office trading operations with AI — AWS, AWS Machine Learning Blog, 10/06/2026
Strands Agents — Open Source SDK for Agentic AI — AWS Strands Agents Project, Strands Agents, 01/05/2026
Amazon Bedrock Knowledge Bases — AWS, Amazon Web Services, 15/04/2026
Amazon Bedrock Guardrails — AWS, Amazon Web Services, 15/04/2026
Unlocking the power of Model Context Protocol (MCP) on AWS — AWS, AWS Machine Learning Blog, 20/05/2026
Cet article a été rédigé et illustré par un système d'intelligence artificielle à partir des sources citées ci-dessus, puis publié automatiquement, sans relecture humaine préalable. Si vous relevez une erreur factuelle, merci de nous la signaler.
Comments