Actualités des Produits IAInfrastructure des agents

Agent Engine d’Oracle AI Database : exécuter des agents au plus près des données sensibles

L’Agent Engine d’Oracle AI Database intègre un environnement d’exécution pour agents à Oracle AI Database 26ai, afin que les workflows s’exécutent au plus près des données sensibles. Cet article présente les modèles pris en charge (ReAct, séquentiel, parallèle, routeur, orchestrateur, boucle), la mémoire transactionnelle, les contrôles de gouvernance et les effets des agents intégrés à la base de données sur la latence, l’exposition des données et les compromis liés à l’orchestration.

NexusAI Editorial27 oct. 20262.5K vues7 min de lecture

Agent Engine d’Oracle AI Database : exécuter des agents au plus près des données sensibles

Brief IA

L’Agent Engine d’Oracle déplace l’exécution des workflows d’agents à l’intérieur du périmètre de la base de données. Les LLM ne sont sollicités qu’à des étapes définies, tandis que l’état, les résultats intermédiaires et la logique transactionnelle restent dans Oracle AI Database 26ai. Pour les équipes confrontées à des problèmes de latence, de fuite de données et de complexité de l’orchestration, cet environnement natif prend en charge les modèles ReAct, séquentiel, parallèle, routeur, orchestrateur et boucle ; il offre une mémoire intégrée et une traçabilité, et applique des contrats de divulgation. Cette approche change la manière dont les architectes évaluent les architectures combinant RAG et orchestration : moins de sauts réseau, un contrôle des politiques renforcé et des pistes d’audit plus claires, mais aussi de nouveaux compromis opérationnels et liés à la disponibilité des modèles, à évaluer avant de déplacer les agents au cœur du plan de données.

L’Agent Engine d’Oracle AI Database fait évoluer un choix architectural essentiel : au lieu de faire transiter les données sensibles par une couche d’orchestration puis par des plateformes d’agents externes, il exécute l’environnement des agents directement dans Oracle AI Database 26ai. Les workflows déclaratifs, décrits à l’aide de l’Open Agent Specification, s’exécutent ainsi là où se trouvent les données. Pour les équipes techniques, les avantages immédiats sont concrets : moins d’allers-retours réseau, une surface d’attaque réduite pour les résultats intermédiaires sensibles et la possibilité d’assurer la cohérence transactionnelle de l’état du workflow avec les opérations de la base de données.

L’Engine prend en charge un large éventail de modèles de workflow : interactions entre outils et modèles de type ReAct, pipelines séquentiels ou parallèles, architectures d’orchestration et de routage pour gérer les branchements, ainsi que des boucles pour les traitements itératifs. La mémoire intégrée conserve le contexte et l’état des workflows aux côtés des données, tandis que les étapes de validation humaine et les pistes d’audit sont prises en charge nativement. Cette combinaison vise les charges de travail centrées sur les données et sensibles à la latence — vérification de factures, détection des fraudes, contrôles réglementaires — pour lesquelles les résultats intermédiaires sont volumineux ou confidentiels et leur sérialisation répétée vers un orchestrateur externe serait coûteuse ou risquée.

Sur le plan opérationnel, l’Engine fait des LLM une étape d’un processus transactionnel plus vaste, plutôt que la couche d’orchestration à part entière. La logique déterministe (jointures, agrégations, évaluation de règles) reste dans SQL/PLSQL ; les modèles ne sont sollicités que lorsqu’une interprétation, une synthèse ou une génération de contenu est nécessaire. Cette séparation limite l’exposition des données brutes aux modèles : les entrées sont définies et structurées selon un contrat de décision, et les contrôles de politique empêchent les appels aux modèles d’accéder librement aux tables. Pour les entreprises soumises à des exigences réglementaires, c’est un progrès majeur en matière de gouvernance par rapport à l’envoi d’extraits de vastes jeux de données à des LLM externes.

Les compromis sont bien réels. Héberger l’environnement d’exécution dans la base de données réduit la latence et les coûts de transfert, mais concentre les besoins de calcul et la dépendance à la disponibilité dans cet environnement. Une interruption des modèles peut toujours suspendre les workflows, et les équipes doivent prévoir l’isolation des ressources pour éviter les conflits avec les charges de production. L’Open Agent Specification améliore la portabilité, mais les parcours de migration, les risques de dépendance vis-à-vis du fournisseur et l’évolution des compétences nécessaires aux administrateurs de bases de données et aux équipes plateforme exigent une gestion du changement rigoureuse.

Points clés à retenir

Exécuter les agents là où se trouvent les données

L’exécution dans la base de données réduit les échanges réseau et maintient les résultats intermédiaires sous le contrôle des politiques de la base. Elle diminue ainsi la latence et l’exposition des données pour les charges sensibles, comme la vérification de factures et les contrôles de conformité.

Limiter la divulgation au strict nécessaire

Les contrats de décision définissent les informations transmises aux modèles. Associés aux contrôles d’accès et aux audits de la base de données, ils limitent les fuites et facilitent la conformité.

Trouver l’équilibre entre disponibilité et flexibilité

Les agents natifs de la base de données simplifient la gouvernance, mais exigent de planifier l’isolation des ressources, les solutions de repli en cas d’indisponibilité des modèles et la mise à jour des procédures opérationnelles. L’orchestration externe conserve l’avantage de la flexibilité multi-fournisseurs.

Ce qui change : un environnement d’exécution d’agents intégré à la base de données

L’Agent Engine d’Oracle intègre un environnement d’exécution déclaratif à Oracle AI Database 26ai, afin que les workflows s’exécutent là où résident les données. La base de données n’est plus un simple espace de stockage : elle exécute des outils, conserve l’état des workflows et sollicite les modèles à des étapes définies. Ce changement déplace le centre de contrôle : autorisations, chiffrement, audit, gestion des ressources et garanties transactionnelles s’appliquent à la source, ce qui simplifie l’application des politiques d’entreprise et réduit le nombre de systèmes à synchroniser.

Modèles pris en charge et fonctionnement de l’environnement

Agent Engine met en œuvre plusieurs modèles de workflow au moyen de définitions déclaratives : ReAct (boucles entre outils et modèles), pipelines séquentiels et parallèles, architectures de routage et d’orchestration, ainsi que boucles de traitement. Les workflows peuvent lire et écrire des données via SQL/PLSQL pour les étapes déterministes, et n’appeler des LLM externes que pour les tâches d’interprétation ou de génération. L’état et la mémoire sont stockés dans la base de données, ce qui permet de créer des points de reprise cohérents et de reprendre l’exécution. Des étapes de validation humaine et un contrôle précis de chaque étape permettent aux équipes de limiter les données visibles par les modèles et de définir les cas où une approbation est requise.

Gouvernance, contrats de divulgation et traçabilité

Puisque l’environnement d’exécution se trouve dans la base de données, les mécanismes de gouvernance — contrôle des accès, chiffrement, audit et Deep Data Security — s’appliquent de manière uniforme à l’état des workflows et aux résultats intermédiaires. Agent Engine introduit des contrats de décision qui définissent la représentation minimale autorisée des données sensibles transmises aux modèles. Chaque appel d’outil, sollicitation d’un modèle et chemin de décision est consigné, ce qui facilite les audits, les examens a posteriori et les contrôles de conformité essentiels dans les secteurs réglementés et pour les équipes chargées des risques d’entreprise.

Comparaison avec le RAG et l’orchestration externe

Les architectures RAG classiques et l’orchestration externe répartissent la récupération des données, l’orchestration et l’exécution des modèles entre plusieurs services. Cette modularité facilite le choix des outils, mais multiplie les échanges réseau et les copies de données, tout en alourdissant la synchronisation. Un agent intégré à la base de données réduit ces échanges et maintient les résultats intermédiaires près de leur source, ce qui diminue la latence et le risque de divulgation accidentelle. Les architectures externes offrent toutefois davantage de flexibilité grâce à des services de récupération spécialisés, à un large choix de modèles et à une mise à l’échelle indépendante — des atouts lorsque les équipes ont besoin de combiner différents fournisseurs ou de déployer leurs solutions indépendamment du cloud.

Liste de contrôle pour l’adoption et compromis opérationnels

Les équipes qui évaluent l’Agent Engine d’Oracle doivent tenir compte de plusieurs aspects pratiques : définir des contrats de divulgation pour chaque étape du workflow ; prévoir l’isolation des ressources afin que les agents ne perturbent ni les charges OLTP ni les traitements analytiques ; mettre en place des solutions de repli en cas d’indisponibilité des modèles et définir les modalités de reprise ; actualiser les procédures d’audit et de conformité ; et former les administrateurs de bases de données et les ingénieurs plateforme à la gestion du cycle de vie des agents. Commencez par les charges de travail centrées sur les données et sensibles à la latence, qui tireront le plus parti de l’exécution dans la base, puis élargissez progressivement les responsabilités d’orchestration.

Questions fréquentes

Quels workflows tirent le meilleur parti d’Agent Engine ?

Les workflows centrés sur les données et sensibles à la latence, avec des résultats intermédiaires volumineux ou confidentiels, sont les plus concernés. On peut citer le rapprochement de factures, le triage des fraudes, les contrôles réglementaires et les processus de décision opérationnels. Ces modèles évitent de sérialiser les données à répétition et bénéficient de la cohérence transactionnelle et de l’audit intégré.

Comment Agent Engine limite-t-il l’accès des modèles aux données ?

Les workflows s’appuient sur des contrats de décision et un contrôle précis à chaque étape, afin de fournir aux modèles des entrées structurées et limitées plutôt qu’un accès direct aux tables. Les contrôles d’accès, le chiffrement et les audits de la base continuent de protéger l’état des workflows et les résultats intermédiaires à l’intérieur du périmètre de la base de données.

Dans quels cas vaut-il mieux conserver une orchestration externe ?

Si vous avez besoin de points de terminaison de modèles variés, de portabilité multi-cloud ou de services de récupération spécialisés proposés par des tiers, et que vous pouvez accepter la latence et les contraintes de gouvernance liées aux transferts de données entre services, une architecture d’orchestration externe peut rester préférable — notamment pendant une période de transition hybride.

#Environnement d'exécution d'agent supervisé#Flux de travail des agents en entreprise#Modèles d'orchestration d'agents#Gestion des données sensibles#gouvernance-des-agents-en-entreprise#orchestration d’agents pour entreprises#Persistance de la mémoire pour les agents#Plan de données pour les agents#Flux d’approbation des agents#Gouvernance des agents d’entreprise#Flux de travail RAG#Évaluation et Audit#Agents natifs de base de données#Gouvernance intégrée à la base de données#Environnement d’exécution des agents#Contrats de divulgation#Workflows d’IA transactionnels

Agent Engine d’Oracle AI Database : exécuter des agents au plus près des données sensibles

NexusAI Editorial27 oct. 20262.5K vues7 min de lecture

Brief IA