Jefferies mise sur Amazon AWS, mais son assistant de trading IA doit encore gagner la confiance des traders

Jefferies a déployé un assistant de trading Amazon AWS qui permet aux traders actions d’interroger des millions de lignes de données sans écrire de code. L’annonce du 23 juillet marque un passage des tableaux de bord figés vers un agent qui interprète les questions, crée du SQL, sélectionne les sources de données et présente les résultats. Le dilemme est tout aussi clair : une plus grande autonomie offre aux traders un accès plus rapide, mais elle augmente aussi le coût de chaque requête inexacte.

Le système utilise Amazon Bedrock, Anthropic Claude, Amazon Bedrock Knowledge Bases, Strands Agents et Model Context Protocol. Il se connecte à des référentiels de transactions, à des fichiers de messages Financial Information Exchange, à des bases de données en mémoire et à des magasins historiques. Jefferies affirme que l’assistant réduit le travail lié aux tableaux de bord tout en donnant aux traders un accès conversationnel à des analyses en temps réel.

Il s’agit d’un pari opérationnel plus ambitieux que l’ajout d’un chatbot à une application existante. Les outils traditionnels de business intelligence maintiennent les analystes et les équipes informatiques au cœur du flux de travail. Jefferies déplace une partie de ce flux vers un logiciel qui décide comment interpréter une question et où l’exécuter. L’affrontement oppose désormais l’analyse fixe, conçue par des spécialistes, à l’analyse gouvernée et pilotée par des agents.

Jefferies a intégré l’assistant de trading au flux de travail du front office

Le changement important ne se limite pas à la recherche conversationnelle. Jefferies a placé un agent IA entre les questions des traders et les données opérationnelles de trading.

Selon l’architecture de l’assistant de trading, les traders accèdent à l’agent via un widget intégré à Global Flow Monitor. Ce système de business intelligence sur site fait déjà partie de l’environnement de travail de Jefferies. L’assistant s’insère donc dans une interface familière, plutôt que de demander aux utilisateurs d’adopter un produit de recherche distinct.

Un trader peut demander une ventilation de l’activité de trading américaine par secteur. Amazon Bedrock appelle un modèle Anthropic Claude afin d’interpréter cette demande et de générer du SQL. Le système identifie la source de données appropriée, exécute la requête et renvoie une visualisation. Les utilisateurs peuvent ensuite poser des questions de suivi, tandis que la session conserve le contexte conversationnel.

Cette conception répond à un goulot d’étranglement précis du front office. Les traders actions doivent examiner le comportement des clients, les exécutions, l’activité de marché et les tendances historiques alors que les marchés évoluent. Or, les informations sous-jacentes peuvent couvrir des millions de lignes et plusieurs systèmes de visualisation. Un trader ayant besoin d’une nouvelle vue dépend souvent d’un expert métier ou d’une équipe informatique pour la créer.

AWS et Jefferies indiquent que ce processus prenait auparavant des jours, voire des semaines. L’assistant de trading vise à condenser la boucle de demande, de développement et d’analyse en une seule conversation. Il n’exige pas que chaque trader comprenne les schémas de bases de données ni qu’il rédige une requête syntaxiquement valide.

L’agent fonctionne également avec plusieurs formes de données. Il peut accéder à des bases de données structurées, à des contenus non structurés, à des messages FIX et à des magasins en mémoire. FIX est un protocole standard utilisé pour échanger des informations de trading électronique. Ses enregistrements de messages contiennent des détails susceptibles d’aider les équipes à examiner les ordres et les exécutions.

Cette étendue compte, car les questions du front office entrent rarement dans une seule base de données bien ordonnée. Un trader peut commencer par les positions actuelles, les comparer à l’activité historique, puis examiner les messages d’exécution. L’assistant expose chaque source comme un outil distinct et laisse le modèle choisir parmi ces outils.

Le lancement ne supprime pas les tableaux de bord. Jefferies continue d’utiliser une interface dédiée et des composants de visualisation déterministes. Il change plutôt qui peut lancer une nouvelle analyse et à quelle vitesse l’organisation peut la produire.

Cette distinction sépare le projet d’un chatbot générique pour le lieu de travail. L’assistant est autorisé à créer et exécuter des requêtes sur des systèmes sensibles. Sa valeur provient de l’action, et non simplement de la synthèse de documents. Cette même capacité crée également le risque central.

Pourquoi Amazon AWS pousse les agents au-delà de la recherche interne

Amazon AWS utilise Jefferies pour montrer que les agents d’entreprise peuvent opérer dans des flux de travail réglementés, et pas seulement répondre à des questions à faible enjeu.

Amazon Bedrock fournit un accès géré aux modèles de fondation, tandis que Strands Agents coordonne le raisonnement et les appels d’outils. Un cadre d’agent est un logiciel qui fournit à un modèle des instructions, des outils, l’état de session et une boucle d’exécution. Il transforme une réponse de modèle linguistique en une séquence d’actions.

AWS décrit Strands Agents comme un SDK open source piloté par les modèles. Les développeurs définissent un prompt et une collection d’outils, puis laissent le modèle sélectionné planifier les étapes à suivre. Les équipes peuvent également personnaliser la sélection d’outils, la gestion du contexte, la mémoire et le comportement de déploiement.

Cette approche pilotée par les modèles réduit la quantité de logique de flux de travail que les développeurs doivent coder en dur. Dans une application conventionnelle, les ingénieurs anticipent chaque demande prise en charge et l’associent à une opération prédéfinie. L’agent de Jefferies interprète plutôt l’intention de l’utilisateur à l’exécution et choisit un chemin parmi les outils disponibles.

Amazon Bedrock Knowledge Bases fournit une autre couche. Il stocke des représentations intégrées de métadonnées de bases de données, notamment les schémas, les définitions de colonnes, les relations et les modèles de requêtes. La génération augmentée par récupération, ou RAG, récupère des éléments pertinents avant qu’un modèle produise une réponse. Ici, la récupération donne à Claude le contexte de schéma nécessaire pour créer du SQL.

L’architecture répond à un problème courant de conversion du texte en SQL. Un modèle peut comprendre les mots d’une question tout en ignorant les tables d’une entreprise et ses conventions de nommage internes. La récupération du schéma pertinent réduit les options du modèle et lui donne davantage de chances de cibler les bons champs.

Cette approche fait également d’Amazon AWS le plan de contrôle de plusieurs éléments mobiles. Bedrock fournit l’accès aux modèles, Knowledge Bases gère la récupération et Guardrails applique des politiques de sécurité sélectionnées. Selon AWS, Jefferies peut changer de modèles à mesure que l’application évolue sans reconstruire chaque composant environnant.

Ce choix reflète une compétition plus large dans le cloud. Microsoft Azure et Google Cloud veulent eux aussi que les entreprises développent des agents à proximité de leurs données et systèmes d’identité existants. Le déploiement chez Jefferies offre à AWS un cas de référence impliquant des données opérationnelles, une infrastructure sur site, des contrôles d’accès et une grande institution financière.

Cela ne prouve toutefois pas qu’un cloud ait remporté l’IA pour les services financiers. AWS et Jefferies ont rédigé conjointement ce récit, qui ne fournit pas de benchmarks indépendants. L’étude publiée omet également les coûts de déploiement, les taux d’erreur des modèles, les chiffres d’adoption et les comparaisons avec des plateformes concurrentes.

La conclusion la plus solide est plus limitée. Amazon AWS dispose désormais d’un exemple détaillé d’agent entrant dans un flux de travail à forte valeur, où la rapidité, l’autorisation et l’auditabilité comptent toutes. Cela rend le projet plus significatif qu’un autre assistant documentaire, avant même que son impact commercial puisse être mesuré indépendamment.

Le véritable affrontement oppose l’analyse pilotée par les agents aux tableaux de bord fixes

Jefferies teste si des agents gouvernés peuvent raccourcir les cycles d’analyse sans sacrifier la prévisibilité des tableaux de bord conçus par des spécialistes.

Les tableaux de bord fixes garantissent la cohérence. Les ingénieurs et les analystes définissent la source de données, la logique de transformation, les filtres et le rendu visuel avant que les utilisateurs ne voient le résultat. Le processus peut être lent, mais les réviseurs peuvent examiner le rôle de chaque composant. Les demandes répétées produisent une vue familière.

L’analyse pilotée par les agents modifie cette relation. L’utilisateur décrit un objectif et le système construit une partie du chemin à l’exécution. Il peut sélectionner un magasin, récupérer des informations de schéma, générer du SQL, exécuter la requête et choisir une présentation. Cette flexibilité rend accessibles des questions auparavant non prises en charge, mais elle élargit aussi le nombre de décisions nécessitant un contrôle.

Jefferies n’a pas confié chaque étape au modèle linguistique. L’architecture publiée place le modèle dans une chaîne contrainte. L’authentification intervient avant l’accès. Un exécuteur de requêtes lance le SQL. Des filtres sont insérés pour faire respecter les droits au niveau des lignes, qui restreignent les enregistrements selon les autorisations de l’utilisateur.

Le modèle ne génère pas non plus les graphiques seul. Jefferies indique utiliser Claude pour la compréhension du langage et la génération de requêtes, tandis qu’un moteur de visualisation dédié crée les graphiques. Cette séparation limite la possibilité pour le modèle d’inventer des libellés, des valeurs ou des relations visuelles après le renvoi des résultats par la base de données.

Cette conception hybride constitue la décision technique la plus importante du projet. Elle confie le travail probabiliste au modèle et conserve certains travaux déterministes dans un logiciel conventionnel. Le modèle peut interpréter une demande ambiguë, mais les systèmes existants contrôlent toujours l’authentification, l’exécution, l’accès et le rendu.

Model Context Protocol soutient cette séparation. MCP est une interface ouverte qui relie les applications d’IA à des données et outils externes. Sa spécification d’autorisation définit comment des serveurs protégés peuvent participer à des flux d’autorisation standardisés.

Jefferies expose chaque source de données comme un outil MCP distinct. Une grille en mémoire peut constituer un outil, tandis qu’un magasin historique ou un référentiel FIX peut en constituer un autre. L’agent évalue les outils et en sélectionne un selon la requête.

Cette structure offre une forme pratique de modularité. Les équipes peuvent ajouter une source en créant un autre outil plutôt qu’en reconstruisant le flux de travail central de l’agent. Chaque connecteur peut encapsuler une logique propre à la source, ce qui rend aussi les tests et la maintenance plus ciblés.

Le compromis est que la modularité ne produit pas automatiquement de la fiabilité. Le modèle peut toujours sélectionner le mauvais outil, récupérer un contexte de schéma trompeur ou créer une requête valide qui répond à la mauvaise question métier. La correction SQL n’est pas la même chose que la correction analytique.

Une question telle que « Quels clients ont changé de comportement aujourd’hui ? » contient des choix implicites. Le système doit déterminer une fenêtre de comparaison, choisir une mesure du comportement, gérer une activité incomplète et décider ce qui constitue un changement significatif. Une requête peut s’exécuter parfaitement tout en intégrant des hypothèses que le trader n’avait pas prévues.

Les tableaux de bord fixes rendent nombre de ces hypothèses visibles grâce à des définitions établies. L’analyse pilotée par les agents doit les faire émerger au cours de la conversation ou les encoder dans des modèles de requêtes contrôlés. Sinon, la rapidité peut masquer l’ambiguïté au lieu de la résoudre.

C’est pourquoi le projet doit être évalué comme une interface de décision gouvernée, et non comme un benchmark de chatbot. Le langage naturel n’est que le point d’entrée. Le travail le plus difficile consiste à contrôler ce qui se passe après qu’un trader a appuyé sur Entrée.

Les garde-fous d’Amazon AWS réduisent les risques, mais ne vérifient pas l’analyse

Les contrôles de l’assistant peuvent restreindre l’accès et filtrer le contenu, mais ils ne peuvent pas garantir que chaque requête générée reflète l’intention du trader.

Le récit d’AWS identifie plusieurs couches de sécurité. Amazon Bedrock Guardrails gère la modération de contenu et le filtrage des informations personnelles identifiables. Jefferies applique également des droits au niveau des lignes et enregistre les conversations à des fins de piste d’audit.

Ces contrôles répondent à différents modes de défaillance. L’authentification détermine si un utilisateur peut entrer dans le système. Les droits d’accès déterminent quelles lignes de données cette personne peut récupérer. La modération filtre le contenu sélectionné, tandis que la journalisation préserve des éléments de preuve pour les enquêtes et les contrôles de conformité.

Les filtres d’informations sensibles d’Amazon peuvent bloquer ou masquer les informations personnelles détectées dans les prompts et les réponses du modèle. AWS décrit cette fonctionnalité comme probabiliste et dépendante du contexte. Sa documentation avertit également que le masquage ne couvre pas tous les emplacements où des informations peuvent apparaître.

Par exemple, la documentation indique que le masquage des informations personnelles identifiables s’applique aux entrées et sorties du modèle, mais pas automatiquement au contenu d’origine des journaux d’invocation du modèle. Les résultats de trace des garde-fous peuvent également contenir la valeur correspondante. Les entreprises ont donc besoin de contrôles de journalisation et de politiques de protection des données distincts.

Les appels d’outils introduisent une autre frontière. AWS note que le filtre d’informations sensibles ne détecte pas les informations personnelles identifiables présentes dans les paramètres de sortie d’utilisation d’outils via les API prises en charge. Un agent peut être protégé au niveau conversationnel tout en laissant un connecteur ou une trace exposer des éléments sensibles.

Ces limites ne signifient pas que les contrôles sont inefficaces. Elles montrent pourquoi un garde-fou doit être considéré comme une couche parmi d’autres, plutôt que comme un système complet de conformité. L’utilisation par Jefferies de droits d’accès, d’interception des requêtes et de journalisation d’audit reconnaît cette distinction.

L’incertitude plus importante concerne l’erreur analytique. Un filtre de contenu peut détecter certaines catégories interdites, mais il ne sait pas si « l’activité client d’aujourd’hui » utilise le bon fuseau horaire ou le bon indice de référence. La sécurité au niveau des lignes peut empêcher les accès non autorisés, mais elle ne peut pas déterminer si la table sélectionnée répond à la question métier.

Les hallucinations prennent également plusieurs formes dans ce contexte. Le modèle peut inventer une colonne qui n’existe pas, ce que l’exécution devrait rejeter. Il peut générer du SQL valide sur la mauvaise colonne, ce qui est plus difficile à détecter. Il pourrait aussi renvoyer un résultat exact accompagné d’une interprétation en langage naturel exagérée.

Jefferies indique que sa Knowledge Base récupère des détails de schéma et des modèles de requêtes afin d’améliorer la précision du SQL. Cela devrait réduire certaines erreurs structurelles, mais l’entreprise n’a pas publié de taux de précision. L’annonce ne fournit pas non plus d’informations sur la fréquence à laquelle les requêtes nécessitent une correction ou une escalade humaine.

Aucun indicateur de latence n’est non plus communiqué. AWS indique que Jefferies a choisi des bases de données en mémoire parce que les traders ont besoin d’informations en une fraction de seconde. Toutefois, les informations publiques ne quantifient pas le temps de réponse pour les requêtes simples, les flux de travail multi-sources ou les périodes de forte demande.

L’adoption reste une autre question ouverte. Jefferies affirme que les utilisateurs se sont comportés de manière inattendue et ont modifié leurs habitudes au fil du temps. Cette observation a conduit l’équipe à investir dans l’observabilité et les boucles de retour, mais l’entreprise n’a pas révélé combien de traders utilisent l’assistant.

Le comportement des utilisateurs peut révéler des faiblesses que les tests contrôlés ne détectent pas. Les traders peuvent utiliser des raccourcis, omettre des hypothèses, poser plusieurs questions à la fois ou interpréter un graphique soigné comme plus certain qu’il ne l’est. L’interface doit aider les utilisateurs à reconnaître lorsqu’un résultat exige une validation.

C’est là qu’une base de connaissances technique consultable peut soutenir la gouvernance au-delà de la simple récupération d’informations. Les équipes ont besoin de dossiers accessibles sur les schémas, les modèles de requêtes approuvés, les responsabilités, les résultats d’évaluation et les décisions liées aux incidents. Ces éléments aident les examinateurs à comprendre pourquoi un agent a suivi un chemin particulier.

La réglementation financière ajoute une autre raison de faire preuve de prudence. Un assistant d’analyse des transactions n’est pas automatiquement un système de recommandation destiné aux particuliers. Pourtant, les régulateurs ont souligné que l’utilisation de l’IA ne supprime pas les obligations existantes en matière de conduite. La SEC a déclaré que les professionnels de l’investissement restent responsables de la défense des intérêts de leurs clients lorsque des algorithmes influencent les conseils ou recommandations.

La SEC a ensuite retiré ses règles proposées sur l’analytique prédictive en juin 2025. L’avis de retrait indiquait que toute action future exigerait une nouvelle proposition. Ce retrait a réduit une incertitude réglementaire précise, mais il n’a pas supprimé les obligations existantes en matière de tenue de registres, de supervision, de confidentialité ou de conduite sur les marchés.

L’architecture de Jefferies semble conçue en tenant compte de ces réalités. Pourtant, le contenu publié reste une étude de cas soutenue par un fournisseur, et non un audit. Des preuves indépendantes concernant la précision, les faux refus, la prévention des requêtes non autorisées et les incidents opérationnels offriraient un test plus clair.

L’impact commercial dépend de bien plus que de réponses plus rapides

Jefferies affirme que l’assistant a amélioré l’efficacité, mais les éléments publics ne montrent pas encore comment ces gains affectent les performances de trading ou les coûts technologiques.

AWS rapporte que le système a réduit le travail manuel lié aux données dans les opérations mondiales de vente et de trading. Selon les entreprises, les traders peuvent consacrer davantage de temps aux relations clients et aux décisions stratégiques. Les équipes technologiques consacrent également moins d’efforts à la création de tableaux de bord répétitifs.

Ces avantages sont plausibles, car l’assistant cible une file de demandes mesurable. Chaque tableau de bord personnalisé mobilise un travail de recueil des besoins, une expertise des données, du temps de développement, des tests et de la maintenance. Si un trader peut répondre à une question ponctuelle grâce à une génération SQL gouvernée, certaines demandes n’ont jamais besoin d’entrer dans cette file.

Le système peut également raccourcir l’analyse exploratoire. Un trader peut commencer par une vue générale d’un secteur, puis approfondir le résultat par des questions de suivi. Le contexte de session conservé réduit le besoin de reformuler les filtres et les comparaisons à chaque tour.

Toutefois, l’efficacité ne peut pas être mesurée uniquement par le nombre de tableaux de bord évités. Jefferies doit également prendre en compte l’utilisation des modèles, l’infrastructure de récupération, l’évaluation, la supervision, les revues d’accès et la réponse aux incidents. Les requêtes générées peuvent faire gagner du temps de développement tout en créant de nouvelles tâches de supervision.

Le calcul de la valeur dépend de la qualité des requêtes. Un résultat rapide nécessitant des corrections répétées ne surpasse pas nécessairement un tableau de bord fiable. Un résultat techniquement exact que les traders utilisent rarement génère peu de valeur opérationnelle. Le système doit améliorer l’ensemble du parcours, de la question à la décision défendable.

Jefferies doit également distinguer plusieurs types d’utilisation. Certaines questions sont routinières et répétables, ce qui en fait de bons candidats pour des rapports établis. D’autres sont exploratoires et bénéficient d’une interface conversationnelle. Le meilleur modèle opérationnel préservera probablement les deux voies.

L’annonce ne fournit pas de métriques financières. Elle ne divulgue ni les dépenses de développement, ni les coûts d’exploitation, ni les effets sur les revenus, ni les changements en matière de rétention des clients, ni les heures économisées. Elle n’indique pas non plus si les traders prennent de meilleures décisions après avoir utilisé l’assistant.

Cette omission devrait tempérer l’expression « avantage concurrentiel ». Un accès plus rapide peut créer un avantage, mais seulement si les concurrents ne peuvent pas le reproduire rapidement ou si Jefferies l’intègre plus efficacement. Les composants sous-jacents sont accessibles à d’autres clients d’Amazon AWS, et MCP réduit certaines barrières d’intégration.

L’avantage propriétaire de Jefferies réside donc moins dans le modèle que dans ses données, ses modèles de requêtes, la conception de ses flux de travail, ses contrôles et son adoption. Les concurrents peuvent concéder sous licence des modèles fondamentaux similaires. Ils ne peuvent pas copier instantanément les données historiques de l’institution, ses définitions internes, ses structures d’autorisation ou les habitudes de son front office.

Ce schéma s’applique au-delà du secteur bancaire. Les entreprises se concentrent souvent sur le choix d’un modèle, alors que la différenciation opérationnelle provient d’un contexte fiable et d’actions contrôlées. Le modèle fournit un raisonnement général, tandis que l’organisation apporte les informations et les limites qui rendent le système utile.

Le cas Jefferies montre aussi pourquoi l’architecture applicative compte après l’amélioration de la qualité des modèles. Bedrock permet à l’équipe de changer de modèles au fil du temps. MCP isole les connecteurs de données. Knowledge Bases organise le contexte des schémas. Les services déterministes conservent le contrôle sur l’accès et le rendu.

Ces choix réduisent la dépendance à une version donnée d’un modèle. Ils n’éliminent pas la dépendance à Amazon AWS, puisque Bedrock, Knowledge Bases, Guardrails et les futures fonctionnalités AgentCore font partie de la pile prévue. Jefferies gagne en flexibilité de modèle tout en concentrant davantage l’orchestration au sein d’une seule plateforme cloud.

Cette concentration implique des compromis familiers en entreprise. Une plateforme partagée peut simplifier les revues de sécurité et les opérations. Elle peut aussi rendre de futures migrations plus coûteuses si le comportement de l’application devient étroitement lié à des services propriétaires.

L’importance commerciale du projet dépendra finalement de résultats reproductibles. Jefferies a besoin de preuves que les traders obtiennent plus vite des réponses fiables, que l’informatique reçoit moins de demandes à faible valeur et que les équipes de contrôle peuvent reconstituer les actions des agents. Sans ces mesures, l’assistant reste une architecture impressionnante avec un dossier commercial incomplet.

Ce qu’il faut surveiller alors que Jefferies étend l’assistant de trading

Le prochain test consistera à déterminer si Jefferies peut étendre l’assistant à plusieurs desks tout en préservant la précision, la latence et des décisions d’accès traçables.

Le premier signal est le déploiement mondial prévu sur des produits et desks supplémentaires. Les différentes activités de trading utilisent des terminologies, des structures de données, des mesures de risque et des horizons temporels distincts. Un système ajusté aux flux de travail sur actions nécessitera de nouveaux outils, un nouveau contexte de schéma et de nouvelles évaluations à mesure que son périmètre s’étend.

Une expansion réussie renforcerait l’argument en faveur d’une architecture d’agent réutilisable. Des exceptions persistantes ou des reconstructions propres à chaque desk suggéreraient que les flux de travail financiers restent plus difficiles à généraliser que ne le laisse entendre la conception modulaire. Jefferies devrait à terme divulguer les niveaux d’adoption et la part des requêtes achevées sans intervention de spécialistes.

Le deuxième signal est l’amélioration de l’auditabilité. Jefferies prévoit de renforcer ses capacités d’audit avec des outils de génération de code utilisant le traitement du langage naturel. La question importante est de savoir si les examinateurs peuvent reconstituer le contexte récupéré, le SQL généré, l’outil sélectionné, les filtres d’accès injectés, les données renvoyées et la présentation finale.

Les journaux de conversation ne suffisent pas s’ils omettent les décisions intermédiaires. Une piste d’audit défendable doit relier les mots de l’utilisateur à chaque action conséquente du système. Elle doit également conserver les versions du modèle et des prompts, car des demandes identiques peuvent se comporter différemment après une mise à jour.

Le troisième signal est l’ajout prévu de fonctionnalités Amazon Bedrock AgentCore. Cette extension testera si une plateforme d’agents AWS plus complète améliore l’observabilité et le contrôle sans introduire une complexité inutile. Elle révélera aussi à quel point l’implémentation de Jefferies devient couplée aux services d’Amazon.

Les lecteurs ne devraient pas attendre une métrique unique de succès. La précision, les taux de correction, la latence, l’adoption par les utilisateurs, les tests d’accès non autorisé et la demande de tableaux de bord décrivent tous différentes dimensions du résultat. Jefferies a publié l’architecture, mais les preuves opérationnelles détermineront si le projet devient un modèle de déploiement d’agents dans un environnement réglementé.

Pour les développeurs, la leçon consiste à encadrer l’autonomie autour de systèmes vérifiés. Pour les acheteurs en entreprise, elle consiste à exiger des mesures qui distinguent les démonstrations séduisantes des flux de travail fiables. Pour les travailleurs du savoir, elle consiste à considérer l’accès conversationnel comme une nouvelle interface vers des données gouvernées, et non comme un remplacement du jugement.

Amazon AWS et Jefferies ont fait évoluer le débat au-delà de la capacité d’un agent à générer du SQL. La vraie question est de savoir s’il peut produire une analyse utile de manière répétée tandis que les marchés évoluent et que les obligations de conformité restent fixes. Surveillez le déploiement, la piste d’audit et les données d’erreur avant de considérer cette question comme tranchée.