Pourquoi les données de R&D ont leur place dans le Lakehouse - et pourquoi les agents en ont besoin

Le contexte

Chez cellcentric, une coentreprise de Daimler Truck et Volvo Group, nous développons et construisons des systèmes de piles à combustible à hydrogène pour les applications lourdes. Notre travail est fortement axé sur la R&D, l'ingénierie et les données. Les questions que se posent nos équipes s'inscrivent rarement dans un seul système source. Elles recoupent la hiérarchie des produits, l'historique de fabrication, les retouches, les données de laboratoire, la télémétrie des tests et les connaissances du domaine.

C'est le défi central de l'AI industrielle dans la R&D. Un agent n'est utile que s'il peut raisonner sur le même contexte gouverné dont un ingénieur a besoin pour faire confiance à une réponse : d'où proviennent les données, ce qu'elles signifient, leur niveau de complétude, les limites à prendre en compte et si l'utilisateur est autorisé à les voir. Transformer cela en un contexte prêt pour l'AI commence par l'ingénierie des données, bien avant la sélection du modèle.

C'est pourquoi nous avons passé les quatre dernières années à bâtir nos fondations de données sur Azure et Databricks. Unity Catalog faisait partie de l'architecture dès le départ. Lakehouse Federation a intégré les sources SQL sur site dans le modèle lakehouse. Delta Sharing nous a aidés à échanger des données au-delà des frontières. Databricks Asset Bundles nous a fourni un parcours de mise en production pour les pipelines et les produits de données. Le résultat est le Data Hub : notre couche de contexte gouvernée pour les données et l'AI, avec une interface utilisateur pour les employés et un serveur MCP pour les agents.

Le Data Hub a commencé comme une plateforme de produits de données. Avec le recul, cette base est précisément la raison pour laquelle il fonctionne si bien en tant que plateforme d'AI.

Le Fuel Cell Passport

Cette base est plus facile à expliquer à travers un produit de données : le Fuel Cell Passport. Il rassemble cinq systèmes sources d'entreprise, dont SAP S/4HANA, deux systèmes MES pour la fabrication et les retouches, une base de données de laboratoire et une plateforme de télémétrie IoT. Il modélise sept niveaux de hiérarchie, du système jusqu'au lot de matières premières, s'actualise quotidiennement et utilise un modèle temporel basé sur les états afin que les équipes puissent répondre à la fois à des questions de configuration à un instant T et à des questions sur l'historique complet des retouches. Des contrôles quotidiens de la qualité des données permettent de vérifier si le produit est suffisamment complet pour soutenir les enquêtes d'ingénierie, de qualité et de fabrication. Le nom reflète les concepts de traçabilité et de cycle de vie d'un passeport produit, mais le Fuel Cell Passport est un produit de données d'ingénierie interne — et non un outil de conformité réglementaire comme le Digital Product Passport (DPP) de l'EU, bien que la même base de traçabilité puisse en soutenir un.

Cela ressemble à une success story classique de lakehouse : intégrer les sources, modéliser le domaine, gouverner l'accès, rendre les données réutilisables. Pour l'AI, le point structurel est le contexte associé : un produit gouverné autour des données modélisées.

Le contexte comme métrique de qualité

Unity Catalog nous fournit la structure gouvernée : tables, colonnes, propriété, lignage, classifications et autorisations. Le Data Hub y ajoute la couche produit. Un produit de données combine la propriété, l'état du cycle de vie, l'attribution du domaine, les actifs gouvernés liés et les entrées de contexte qui expliquent à quoi sert le produit et comment il doit être utilisé.

Cette distinction est essentielle pour l'AI. Les agents ont besoin de plus que de simples métadonnées de schéma, et de plus qu'un simple document. Ils doivent comprendre quelles questions métier un produit de données prend en charge, comment les tables importantes sont liées, quelles sont les limites à prendre en compte et quels actifs environnants doivent être utilisés avec lui. Nous conservons ce contexte enrichi dans la couche produit de données, y compris de longues entrées de catalogue au format markdown rédigées pendant le processus de développement, alors que le contexte du projet est encore frais.

Cela a changé notre façon de concevoir la qualité des données. La complétude et la fraîcheur comptent toujours, mais elles ne suffisent plus. Pour des données prêtes pour l'AI, la couverture du contexte est devenue une métrique de qualité de premier ordre.

Dans notre marketplace, chaque produit de données porte un badge de couverture de contexte. Il indique si les descriptions de tables sont présentes et quelle quantité de documentation au niveau des colonnes existe dans les tables associées au produit. Le badge a rendu la métrique visible et exploitable. La couverture a augmenté parce que les ingénieurs pouvaient voir directement l'écart sur l'interface du produit où les données allaient être consommées.

Cette métrique ne prétend pas que chaque ambiguïté sémantique a été résolue. Il s'agit d'un indicateur pratique qui rend le contexte manquant visible suffisamment tôt pour être corrigé. Historiquement, la couverture du contexte s'est améliorée parce que le badge a transformé la documentation d'une tâche de nettoyage après coup en quelque chose que les ingénieurs pouvaient voir, mesurer et améliorer dans le cadre de la livraison.

Aujourd'hui, nous disposons de 27 produits de données publiés, tous dotés d'une riche documentation markdown. Les produits publiés affichent une couverture moyenne de 90 % pour les commentaires de colonnes, la plupart de ces commentaires étant assistés par l'AI lors du travail d'ingénierie des données et révisés par l'ingénieur avant la fusion. L'entrée du catalogue ajoute une autre couche de contexte : un résumé markdown détaillé du flux de travail de développement, des décisions relatives au domaine, des relations entre les tables, des limites et des manières prévues de consommer le produit.

Le changement important est que la documentation s'intègre au flux de travail d'ingénierie, puis devient disponible sous forme de contexte produit structuré pour le prochain humain ou agent qui devra raisonner sur les données.

Une UI pour les humains, un MCP pour les agents

Le Data Hub est la couche qui rend ce substrat consommable. Pour les utilisateurs humains, il s'agit d'une marketplace et d'un espace de travail. Les employés peuvent découvrir des produits de données, voir les propriétaires et l'état du cycle de vie, ouvrir des tableaux de bord et des applications liés, interroger des données gouvernées par Unity Catalog et utiliser une interface de chat pour une exploration en langage naturel. Pour les clients AI, le même contexte est exposé via MCP. Tout agent de codage ou assistant compatible avec MCP peut accéder aux mêmes métadonnées Unity Catalog et au même contexte de produit de données que ceux utilisés par le Data Hub.

Le modèle de gouvernance

L'architecture est délibérément construite autour d'un seul modèle opérationnel. L'identité est transmise de bout en bout. L'accès aux données reste gouverné. Les appels de modèles et d'outils sont observables. Les traces et les évaluations alimentent l'amélioration continue.

Cela ne fonctionne que parce que la gouvernance a été intégrée à la plateforme dès le départ. La propriété de la production, le déploiement et la consommation sont des préoccupations distinctes. Les ingénieurs modifient les pipelines et les définitions de produits via du code révisé et des chemins de déploiement gouvernés. Les consommateurs, y compris les agents, ne reçoivent pas d'identités d'écriture en production. Ils accèdent aux données via le Data Hub, des tableaux de bord, Genie, des outils SQL ou MCP en utilisant l'identité de l'utilisateur authentifié, Unity Catalog prenant la décision finale d'autorisation.

C'est cette distinction qui rend l'accès des agents gouvernable. Un agent peut raisonner sur le même contexte produit qu'un utilisateur voit, et il peut appeler des outils au nom de l'utilisateur, mais il ne peut pas obtenir de droits d'écriture en production ni contourner Unity Catalog avec un identifiant backend partagé. Si l'utilisateur n'a pas accès à une table, à une colonne masquée ou à une vue gouvernée, l'agent est soumis aux mêmes limites. Ce modèle opérationnel nous permet d'autoriser les agents à accéder aux données sans créer un second chemin plus permissif autour de la plateforme.

L'identité commence dans Azure AD et circule via le Data Hub vers Databricks en utilisant l'échange de jetons OAuth 2.0 — le modèle de transmission de jetons « au nom de » (on-behalf-of) que Databricks décrit dans son architecture de gouvernance des agents. Un utilisateur interrogeant une table via l'UI, un agent appelant un outil SQL et un espace de travail Genie invoqué comme un appel d'outil gouverné fonctionnent tous au sein de la même limite d'autorisation. Si l'utilisateur ne peut pas accéder aux données sous-jacentes, l'agent agissant au nom de cet utilisateur ne le peut pas non plus. C'est ce modèle d'accès qui permet au Data Hub d'être utile sans devenir un système de gouvernance parallèle.

Du côté de l'AI, nous exécutons des agents personnalisés sur Databricks Model Serving, utilisons Claude via les Foundation Model APIs et invoquons des espaces de travail Genie en tant qu'outils gouvernés là où ils sont pertinents. L'architecture MCP est hybride par conception : le MCP géré par Databricks offre un accès gouverné aux fonctionnalités de Databricks telles que les appels d'outils Genie, et notre propre MCP fournit la couche de contexte enrichie — métadonnées Unity Catalog, objets de produits de données et markdown de catalogue — ainsi que les outils spécifiques au métier que les agents appellent par-dessus. Les agents ont besoin des deux.

Observabilité et évaluation

L'observabilité est le point où l'architecture devient opérationnelle. Unity AI Gateway achemine désormais le trafic des modèles de fondation dans notre environnement. Avec une légère modification du modèle-client, les appels de modèle de Data Hub transitent par une couche unique de gouvernance et d'observabilité, avec le suivi de l'utilisation et les tables d'inférence activés. Comme les requêtes et les réponses atterrissent dans des tables Delta de Unity Catalog, elles peuvent être analysées avec les mêmes modèles SQL que nous utilisons déjà pour les données d'entreprise.

Le traçage MLflow nous offre le niveau de visibilité suivant. Nous standardisons les traces sur nos adaptateurs d'agents afin que chaque interaction puisse être inspectée comme un chemin d'exécution structuré : appels de modèle, appels d'outils, étapes intermédiaires et réponses finales. En plus de ces traces, nous exécutons un framework d'évaluation continue avec des scores de correction déterministe et de base SQL, des scores de coût sensibles au cache, et des scores de juge LLM alignés avec des experts du domaine. L'objectif est plus large que le simple test des modifications d'agents. La couche de contexte elle-même doit être évaluée : le markdown peut dériver des pipelines et des définitions de tables, les invites système évoluent, les contrats d'outils changent et les hypothèses du domaine vieillissent. Les traces et les évaluations nous permettent de tester ensemble l'agent, les outils et le contexte sur lequel il s'appuie avant que l'un d'eux n'influence le comportement en production.

Pour la première fois, l'entreprise dispose d'un point d'entrée unique et gouverné permettant aux employés de découvrir les produits de données existants et d'interagir avec eux en langage naturel, sous réserve des mêmes contrôles d'accès que les données sous-jacentes.

Le même modèle, au sein de la boucle de développement

Ce même modèle a également changé notre façon de concevoir.

Notre flux de travail d'ingénierie inclut désormais des agents au sein de la boucle de développement. L'outil de codage exact importe moins que le modèle : un ingénieur travaille dans un environnement de développement assisté par AI connecté aux fonctionnalités de Databricks et à notre propre MCP de couche de contexte. Lorsque l'ingénieur travaille sur un produit de données, l'agent peut inspecter les métadonnées Unity Catalog pertinentes, lire la documentation produit existante, comprendre le contexte du projet environnant et aider à structurer les pipelines, les tests, les descriptions de tables et les entrées de catalogue markdown. L'ingénieur reste responsable de la révision et de la fusion, mais l'agent est présent au moment où le contexte est le plus riche.

Ce timing est crucial. La documentation rédigée après coup est souvent incomplète car le contexte du projet a déjà évolué. La documentation rédigée pendant le développement capture le raisonnement, les définitions et les nuances qui rendront les données utiles plus tard — et, une fois révisée et validée, elle devient le contexte du flux de travail suivant.

Pour beaucoup de nos flux de travail de R&D et de développement de processus, ce qui prenait auparavant des semaines d'intégration de données multi-systèmes, de définition de KPI et de structuration de pipelines est désormais livré en quelques jours. L'amélioration se traduit moins par un chiffre d'automatisation unique que par un délai plus court entre la demande d'investigation et le produit de données utilisable : moins de transferts manuels entre experts du domaine et ingénieurs de données, moins d'intégrations répétées de systèmes sources, un accord plus rapide sur les définitions de KPI et une révision plus précoce des nuances pendant que le contexte est encore frais. Certaines catégories, en particulier les investigations multi-sources complexes qui exigent un examen approfondi du domaine, représentent toujours un travail conséquent, mais nettement plus rapide. L'avantage durable est cumulatif : chaque produit ajoute un contexte métier révisé à la plateforme, de sorte que l'investigation suivante commence avec une plus grande partie du domaine déjà expliquée.

Databricks transforme désormais certaines parties de ce modèle en produits. Le CLI de codage de Unity AI Gateway, ucode, achemine les outils de codage via AI Gateway et connecte les serveurs MCP au flux de travail du développeur. Genie Code apporte le codage agentique et le travail sur les données directement dans les interfaces Databricks.

Les prochaines étapes

Pour nous, la prochaine étape consiste à sensibiliser les agents au contexte opérationnel entourant les données ainsi qu'aux tables elles-mêmes. Dans une investigation de qualité ou de fabrication, un agent devrait être capable de récupérer une tendance, d'inspecter les contrôles de qualité des données associés au produit et d'intégrer les journaux d'alarmes des machines associés sur la même période. La réponse peut alors comporter la nuance qu'un ingénieur attendrait : la tendance va dans ce sens, mais cette partie nécessite de la prudence car l'exhaustivité a été signalée et le contexte de fonctionnement était anormal.

La même idée s'applique aux tâches récurrentes. Aujourd'hui, les connaissances sur les processus sont dispersées dans des runbooks, des pages wiki, des invites locales, des scripts, des conventions d'équipe et des habitudes non documentées. Un Skills Marketplace offre à ces connaissances le même traitement de plateforme qu'aux produits de données : propriété, révision, gestion des versions, état du cycle de vie et un espace central où les agents trouvent la méthode de travail approuvée. Dans ce contexte, une compétence regroupe les instructions, les outils approuvés, les modèles, les garde-fous et les contrôles d'évaluation qui indiquent à un agent comment une tâche récurrente doit être exécutée dans notre environnement. Concrètement, elle résiderait dans le marketplace aux côtés des produits de données qu'elle touche, serait versionnée et révisée comme du code, et serait appelée par son nom afin que l'agent suive à chaque fois le même chemin approuvé. Une compétence pourrait structurer un Databricks Asset Bundle spécifique au domaine dans un dépôt distant, ou guider un ingénieur dans l'enregistrement d'un appareil IoT et la transformation de journaux de machines complexes en un pipeline bronze.

C'est la direction générale pour le Data Hub : tirer la même leçon des fondations du lakehouse, gouverner d'abord le contexte, et l'appliquer à la fois aux données interrogées par les agents et au travail qu'ils aident à accomplir.

Ce qu'il faut retenir

C'est pourquoi les données de R&D ont leur place dans le lakehouse. L'AI industrielle a besoin d'un contexte gouverné : les données, la signification, les autorisations, les traces et la boucle de rétroaction au sein d'une seule architecture.

Pour cellcentric, rendre l'AI industrielle pratique signifie donner aux agents ce contexte en s'appuyant sur une fondation lakehouse éprouvée. Unity Catalog, les produits de données, l'identité, l'observabilité et les flux de travail des agents fonctionnent ensemble pour permettre aux humains et aux agents de raisonner sur les données de R&D en toute sécurité. Pour nous, c'est bien plus qu'une simple bonne pratique. C'est ainsi que nous façonnons la prochaine génération d'ingénierie axée sur les données.

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