Des données au dialogue : comment S&P Global Energy a rendu son patrimoine de données structurées conversationnel avec les agents Databricks Genie et MCP

L'objectif de S&P Global était d'améliorer fondamentalement la façon dont les clients découvrent et consomment les insights à travers nos produits de données et de recherche. Bien que la recherche et la synthèse basées sur l'AI soient importantes, la valeur commerciale la plus importante provient de la prise de décision plus rapide grâce à un accès en langage naturel à des données fiables, à des analyses multi-produits plus riches et à la capacité de connecter des insights qui existent traditionnellement dans des secteurs d'activité distincts. Les agents AI aident les clients à découvrir des relations, à générer des recherches mais aussi à tirer des informations exploitables d'un ensemble d'informations plus large qu'auparavant.   —Priyanka John, Vice-présidente, S&P Global Energy

Si vous avez déjà essayé de mettre un patrimoine de données structurées vaste et complexe à la disposition d'agents et d'assistants AI, vous vous êtes probablement heurté au même mur que nous : les agents ne valent que par le contexte auquel ils ont accès, et les données d'entreprise vivent rarement dans un seul endroit propre et bien documenté.

Chez S&P Global Energy, nos données couvrent la chimie, le pétrole brut, les produits raffinés, le gaz et l'électricité, le gaz naturel liquéfié (LNG) et plus encore — et chaque matière première est elle-même une riche famille d'ensembles de données. Le LNG seul comprend les spécifications des installations, les cargaisons, les pannes, les fondamentaux de l'offre et de la demande, les netbacks, les prix historiques et prévisionnels, ainsi que les contrats. La chimie englobe la capacité, la production, l'utilisation, le commerce, la demande par utilisation finale et par dérivé, la variation des stocks et les bilans offre-demande au niveau des pays et des régions. Nos autres matières premières suivent des schémas similaires. Ces données résident sur Databricks et plusieurs sources non-Databricks.

Notre objectif était ambitieux mais simple à énoncer : rendre l'ensemble de notre patrimoine de données structurées disponible pour une consommation externe par des agents AI via le Model Context Protocol (MCP) — afin que les agents et assistants de nos clients, ainsi que les nôtres, puissent poser des questions en langage naturel et obtenir des réponses fiables et gouvernées.

Nous avons évalué plusieurs approches. Ce qui a le mieux fonctionné pour nous, et de loin, ce sont les Databricks Genie Agents, exposés sous forme de serveurs MCP managés, assemblés en bundles spécifiques à un domaine avec une couche proxy MCP.

Dans cet article, vous découvrirez :

• Comment nos experts métier (SME) conçoivent des agents Genie ciblés — un par groupe d'ensembles de données au sein de chaque matière première — sans écrire une seule ligne de code d'agent.
• Comment chaque agent Genie devient automatiquement un serveur MCP gouverné, prêt à être connecté à n'importe quel client ou agent compatible MCP.
• Comment nous utilisons un proxy basé sur FastMCP pour composer plusieurs serveurs MCP Genie en points de terminaison composites pour les questions transversales.
• Pourquoi cette architecture a considérablement réduit notre délai de mise sur le marché pour les produits de données basés sur l'AI.

Les agents Genie permettent à nos experts métier de valoriser directement leur connaissance des données sous forme de produit. Ce qui nécessitait auparavant un cycle de développement complet ne prend désormais que quelques jours, et chaque réponse reste dans nos limites de gouvernance. —Priyanka John, Vice-présidente, S&P Global Energy

Le défi : les données structurées sont faciles à stocker, mais difficiles à interroger par la conversation

Les grands modèles de langage sont remarquablement doués pour la conversation et le raisonnement, mais ils ne peuvent pas répondre aux questions sur vos données à moins que vous ne construisiez un pont vers celles-ci. Pour les données d'entreprise structurées, ce pont a historiquement pris l'une des formes suivantes :

1. Des pipelines text-to-SQL conçus à la main — puissants, mais fragiles. Chaque modification de schéma, chaque nom de colonne ambigu, chaque définition de métrique spécifique à un domaine (« Qu'est-ce qui compte comme un jour de panne ? ») devient une tâche d'ingénierie.
2. Des API personnalisées par cas d'usage — chaque nouveau modèle de question nécessite un nouveau point de terminaison, un nouveau sprint, une nouvelle version.
3. L'exportation de données vers des outils AI externes — ce qui duplique les données, nuit à leur fraîcheur et sort de votre périmètre de gouvernance.

Chacune de ces approches partage le même problème : les personnes qui comprennent le mieux les données — nos SME et nos analystes — ne sont pas celles qui construisent la couche d'accès. Chaque insight devait passer par un backlog d'ingénierie. Notre délai de mise sur le marché pour une nouvelle expérience de données conversationnelle se mesurait en mois.

Nous avions besoin d'une approche où les experts métier pouvaient concevoir et publier directement un accès conversationnel aux données, où l'ingénierie pouvait standardiser la connexion des agents, et où la gouvernance restait centralisée. C'est exactement ce que les agents Genie associés au MCP nous ont apporté.

L'architecture : les agents Genie comme couche sémantique, le MCP comme contrat

Notre architecture comporte trois couches, et chaque couche est détenue par les personnes les plus qualifiées pour s'en occuper. Le diagramme ci-dessus montre le flux de bout en bout — y compris ce qui se trouve à l'intérieur du réseau de S&P Global Energy et ce qui se trouve dans l'environnement client externe.

Couche 1 : les SME conçoivent un agent Genie par groupe d'ensembles de données

C'est là que la magie opère, et notamment, cela ne nécessite aucun code.

Nos SME commencent par sélectionner les tables pertinentes pour un domaine d'activité :

• Si les tables résident déjà dans Databricks, ils les utilisent directement via Unity Catalog.
• Si les données résident dans une source non-Databricks, ils les importent via des connecteurs Lakehouse Federation — pas de mouvement de données, pas de pipelines dupliqués. Les tables fédérées apparaissent aux côtés des tables natives et héritent de la même gouvernance.

Ils regroupent ensuite les tables associées et créent un agent Genie par groupe d'ensembles de données — et non un seul agent géant par matière première. Chaque sous-catégorie d'une matière première devient son propre agent Genie ciblé. Au sein du LNG, par exemple :

• Agent Genie LNG Assets & Contracts — actifs, opérateurs, prévisions de capacité et contrats à long terme
• Agent Genie LNG Cargo  — suivi des cargaisons, affrètements, origines/destinations et conditions commerciales
• Agent Genie LNG Tenders  — appels d'offres avec émetteurs, volumes et fenêtres de livraison
• Agent Genie LNG Outages — pannes et événements de maintenance avec impact sur la capacité
• Agent Genie LNG Supply & Demand — fondamentaux avec répartitions régionales et historique des scénarios
• Agent Genie LNG Netbacks — netbacks à partir des prix des hubs, du fret, de l'évaporation (boil-off) et des pertes
• Agent Genie LNG Prices — courbes de prix historiques et prévisionnelles

Toutes les autres matières premières suivent le même schéma avec leurs propres sous-catégories. La chimie, par exemple, dispose d'agents Genie au niveau du groupe pour la capacité, la production, l'utilisation des capacités, le commerce, la demande par utilisation finale et par dérivé, la variation des stocks et les bilans offre-demande au niveau des pays et des régions ; le pétrole brut, les produits raffinés ainsi que le gaz et l'électricité sont organisés de manière similaire. Le résultat est une flotte de petits agents Genie aux contours bien définis, plutôt qu'une poignée d'outils AI déconnectés et tentaculaires.

Au sein de chaque agent, les SME ajoutent le contexte qui permet au text-to-SQL de fonctionner réellement dans le monde réel : des descriptions de tables et de colonnes, des exemples de requêtes, des actifs de confiance pour les métriques à enjeux élevés et des définitions métier (par exemple, « le stockage flottant est défini comme des cargaisons en attente pendant 3 jours ou plus dans des navires naviguant en dessous d'une vitesse seuil »). C'est l'étape que les solutions text-to-SQL génériques ignorent — et c'est l'étape qui détermine si les utilisateurs font confiance aux réponses.

L'enseignement clé au niveau de l'organisation : la curation est devenue une activité métier, et non une activité d'ingénierie. La personne qui sait ce que signifie « stockage flottant » dans le contexte du LNG est celle qui l'enseigne à un Genie.

Couche 2 : chaque agent Genie est automatiquement un serveur MCP

C'est là que Databricks a fait le plus gros du travail pour nous. Chaque agent Genie est exposé par défaut comme un serveur MCP géré par Databricks, au niveau d'un point de terminaison de la forme :

https://<workspace-hostname>/api/2.0/mcp/genie/{genie_space_id}

Il n'y a rien à déployer ni à héberger. Chaque serveur expose une interface d'outils restreinte et claire — essentiellement deux outils par agent :

1. Un outil de requête (genie_query_space) — l'agent lui soumet une question en langage naturel.
2. Un outil de réponse (genie_poll_response) — l'agent effectue des requêtes régulières (polling) avec le même identifiant de conversation et de message pour récupérer la réponse complète dès qu'elle est prête, y compris le SQL généré et le jeu de résultats.

Ce modèle à deux outils de type « poser une question puis interroger » s'avère parfaitement adapté aux charges de travail agentiques : les questions s'exécutent de manière asynchrone sur un SQL warehouse, et l'agent interroge l'API avec l'identifiant de conversation et de message renvoyé par l'outil de requête jusqu'à ce que la réponse soit prête.

Tout aussi important, ces serveurs gérés sont gouvernés par Unity Catalog. Un agent Genie — ou l'utilisateur qui l'utilise — ne peut accéder qu'aux agents et aux tables sous-jacentes qu'il est autorisé à voir. L'authentification est gérée par la plateforme. Nous n'avons pas eu à créer de couche de sécurité autour de notre accès à l'IA ; nous avons hérité de celle que nous avions déjà.

Couche 3 : composer des agents Genie de groupe en bundles de matières premières avec un proxy FastMCP

Un agent Genie par groupe de jeux de données permet à chaque agent de rester ciblé et précis. Mais les questions métier réelles traversent régulièrement les groupes : « Comment les récentes pannes à Sabine Pass ont-elles affecté les primes de cargaison vers l'Asie ? » touche à la fois les agents Genie Outages et Cargo, et les questions multi-produits comme « Comment les prix du naphta affectent-ils les marges de production de produits chimiques ? » font appel aux agents Genie Refined Products et Chemicals.

Plutôt que de créer un seul agent géant (ce qui dégrade la qualité des réponses) ou de forcer chaque client à configurer une douzaine de serveurs distincts, nous avons utilisé les capacités de proxy et de composition de FastMCP pour créer des points de terminaison MCP composites — généralement un par matière première, en montant les serveurs MCP Genie de niveau groupe de cette matière première derrière un seul serveur avec des outils dotés d'un espace de noms. Les composites de niveau supérieur peuvent regrouper plusieurs matières premières de la même manière :

from fastmcp import FastMCP

# Each group-level Genie Agent is a managed MCP server on Databricks 
cargo = FastMCP.as_proxy(genie_mcp_config(“lng_cargo_agent_id”), name=“cargo”) 
outages = FastMCP.as_proxy(genie_mcp_config(“lng_outages_agent_id”), name=“outages”) 
netbacks = FastMCP.as_proxy(genie_mcp_config(“lng_netbacks_agent_id”), name=“netbacks”) 

# Compose the group Genies into one commodity bundle 
lng = FastMCP(name=“lng-composite”) 
lng.mount(cargo, prefix=“cargo”)
lng.mount(outages, prefix=“outages”)
lng.mount(netbacks, prefix=“netbacks”) 

# The same pattern repeats for Chemicals, Crude Oil, Refined Products, Coal …

(Extrait illustratif — à adapter à votre version de FastMCP et à votre configuration d'authentification.)

Résultat : un agent se connecte à un seul point de terminaison composite par matière première et voit un ensemble d'outils de groupe sélectionnés — cargo_genie_query_agent, outages_genie_query_agent, netbacks_genie_query_agent, etc., chacun étant associé à son pendant genie_poll_response. L'LLM de l'agent décide vers quel groupe Genie orienter une question, ou distribue une question multi-groupes vers plusieurs d'entre eux, puis synthétise les résultats.

Cela nous a permis de bénéficier du meilleur des deux mondes : des agents Genie de niveau groupe précis et très ciblés à la base, et un accès conversationnel large à l'échelle des matières premières et de l'ensemble du patrimoine de données au sommet.

Ce qui a changé pour l'entreprise

Pour nos parties prenantes métier, les détails techniques ci-dessus se traduisent par quelques résultats très concrets.

Le time-to-market s'est effondré. Auparavant, la mise en place d'une nouvelle expérience de données conversationnelle impliquait un cycle de développement complet : spécifications, conception de l'API, ingénierie text-to-SQL, tests, déploiement. Avec cette architecture, le lancement d'un nouveau groupe de jeux de données — ou d'une matière première entière — signifie qu'un SME crée et organise les agents Genie correspondants — le point de terminaison MCP existe dès que l'agent est créé.

Les SME sont devenus des éditeurs, et non plus des demandeurs. Les experts du domaine qui comprennent les cargaisons de LNG ou les équilibres offre-demande de produits chimiques ne créent plus de tickets pour exposer leurs données ; ils préparent un agent Genie et celui-ci est opérationnel. L'effort d'ingénierie est passé de la création de couches d'accès sur mesure à la maintenance d'une couche de proxy légère et réutilisable.

La gouvernance est intégrée par défaut. Chaque question posée par un agent passe par les autorisations de Unity Catalog, sur des tables gouvernées (natives ou fédérées), avec une auditabilité totale. Rendre les données disponibles pour l'IA ne signifiait pas les rendre disponibles en dehors de nos contrôles.

Un seul modèle d'intégration, de nombreux consommateurs — à l'intérieur comme à l'extérieur de l'entreprise. Comme MCP est un standard ouvert, les mêmes points de terminaison composites servent nos agents internes, nos expériences d'IA destinées aux clients et, surtout, nos clients externes, qui peuvent connecter leurs propres agents et assistants compatibles MCP directement aux données gouvernées de S&P Global Energy. Nous avons construit le pont une fois ; chaque client MCP, interne ou externe, peut l'emprunter.

La qualité des réponses est mesurable et le reste. Dans un domaine où les données de tarification, d'approvisionnement et de contrats guident des décisions réelles, les utilisateurs doivent pouvoir faire confiance à chaque réponse et calcul. Les benchmarks d'agent Genie offrent à nos SME un moyen intégré de définir des questions de test qui reflètent la façon dont les utilisateurs posent réellement leurs questions (y compris plusieurs formulations d'une même question) et d'évaluer automatiquement la précision de l'agent par rapport à des réponses vérifiées. Tout aussi important, les benchmarks peuvent être réexécutés après toute modification des instructions, des données ou de la logique métier, de sorte que la précision soit maintenue dans le temps. Le résultat est une boucle de qualité continue et efficace : organiser, évaluer, améliorer et réévaluer pour garantir que nos agents restent précis à mesure que nos données et les questions de nos clients évoluent.

Leçons apprises et bonnes pratiques

Quelques enseignements pratiques de notre parcours, pour les équipes qui envisagent une voie similaire :

1. Gardez les agents Genie ciblés et bien organisés. La qualité des réponses est maximale lorsqu'un agent couvre un domaine de données spécifique avec des instructions claires et des exemples de requêtes. Résistez à la tentation de créer un agent par matière première — ou pire, un agent unique pour tout régir. Rassemblez plutôt plusieurs domaines de données au niveau de la couche MCP.
2. Utilisez Lakehouse Federation avant de créer des pipelines. Pour les sources non-Databricks, la fédération nous a permis d'accéder au mode « conversationnel » sans un seul nouveau travail ETL. Vous pouvez toujours matérialiser les chemins d'accès fréquents plus tard.
3. Investissez dans la couche sémantique. Les descriptions de colonnes, les définitions métier et les exemples de requêtes fiables sont ce qui sépare une démo d'un produit. C'est du temps bien investi pour les SME.
4. Nommez clairement vos outils composites avec des espaces de noms. Lorsqu'un agent voit des outils provenant de nombreux Genies de groupe, des préfixes comme cargo_ et outages_ aident l'LLM à orienter correctement les questions.
5. Mesurez la confiance, pas seulement la latence. Nous avons suivi la fréquence à laquelle les SME étaient d'accord avec le SQL généré par Genie lors de la phase de préparation — c'est le meilleur indicateur avancé de l'adoption de l'expérience par les utilisateurs métier.

Conclusion

Notre objectif était de rendre l'ensemble de notre patrimoine de données structurées — couvrant le LNG, les produits chimiques, le pétrole brut, les produits raffinés, le gaz et l'électricité, etc. — disponible pour les agents d'IA : de manière sécurisée, précise et rapide. Avec les agents Genie de Databricks comme couche sémantique préparée par les SME, les serveurs MCP gérés comme contrat d'intégration sans déploiement, et un proxy FastMCP pour la composition multi-domaines, c'est exactement ce que nous avons accompli :

• Rapidité : Les nouveaux domaines de données conversationnels sont mis en ligne en quelques jours, et non plus en cycles de développement — ce qui accélère considérablement notre time-to-market.
• Précision : Des agents spécifiques au domaine et supervisés par des experts métier fournissent des réponses auxquelles les utilisateurs métier font réellement confiance.
• Gouvernance : Unity Catalog sécurise chaque question, aussi bien sur les données natives que fédérées, sans aucune pile de sécurité parallèle à maintenir.
• Ouverture : Une passerelle au standard MCP sert tous les agents actuels et futurs, qu'ils soient internes ou externes.

Le changement le plus profond est cependant d'ordre organisationnel : les personnes qui comprennent les données sont désormais celles qui en publient l'accès. C'est cela, plus que n'importe quelle technologie, qui a transformé nos données structurées d'un élément que les utilisateurs interrogent en un élément avec lequel ils peuvent simplement dialoguer.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original