NVIDIA Auto Ontology : une couche sémantique pour SQL agentique
NVIDIA Auto Ontology mappe les données en concepts métier pour aider les agents SQL à requêter avec plus de contexte et de contrôle.
NVIDIA pousse Auto Ontology comme une brique de sa fondation de connaissances pour agents d'entreprise. L'objectif : transformer des métadonnées et données brutes en couche sémantique exploitable par des agents qui génèrent du SQL.
Pour une entreprise, l'enjeu n'est pas seulement de produire une requête. Il s'agit de relier cette requête à des définitions métier validées, à des relations de données explicites et à des contrôles de gouvernance.
Ce qui change concrètement
Dans son billet de lancement, NVIDIA présente Auto-Ontology comme une bibliothèque capable de transformer les données brutes d'entreprise en concepts familiers : clients, produits, commandes, puis de cartographier leurs relations. Cette cartographie sert de couche intermédiaire entre les bases de données et les agents IA.
Le dépôt officiel décrit Auto Ontology comme une bibliothèque Python pour construire des couches de raisonnement sémantique et graphées. Elle vise trois besoins très concrets : générer des requêtes de façon déterministe, améliorer la récupération de contexte et rendre les workflows LLM ou agents plus explicables.
Dans le cas du SQL agentique, c'est important. Un agent qui reçoit une question comme « quels clients ont réduit leurs commandes ce trimestre ? » doit savoir ce que l'entreprise appelle un client actif, une commande validée ou un trimestre commercial. Sans couche sémantique, il risque de choisir la mauvaise table, la mauvaise jointure ou une définition différente de celle utilisée par la finance.
Auto Ontology sert donc à créer une couche de sens au-dessus des systèmes de données. Le terme « certifiée » doit être compris ici au sens opérationnel : des définitions métier contrôlées, partageables et gouvernées par l'organisation. La documentation API montre par exemple que l'export du modèle, incluant catalogue et semantic layer en YAML, est réservé aux administrateurs. Elle prévoit aussi une option pour inclure une ontologie Apache Ossie, ainsi qu'une opération d'import avec contrôle d'accès administrateur.
Autre point clé : Auto Ontology expose son contexte aux agents via MCP, CLI et API. MCP permet à un agent compatible d'interroger cette couche de contexte plutôt que de repartir uniquement des noms de colonnes et de tables. La documentation MCP précise que le serveur est un client HTTP de l'API publique Auto Ontology, qu'il ne stocke pas les identifiants de base de données et qu'il hérite des contrôles d'authentification et d'autorisation de la couche Next.js.
Comment l'essayer
Auto Ontology est distribué sous licence Apache License 2.0 sur GitHub. NVIDIA indique que la bibliothèque utilise des endpoints NVIDIA NIM pour l'inférence, soit via le catalogue hébergé integrate.api.nvidia.com, soit via des NIM auto-hébergés.
Pour une pile locale, la documentation de déploiement liste plusieurs prérequis : Docker avec Docker Compose v2, une clé API NVIDIA pour NIM, et les détails de connexion aux bases sources. Les sources citées pour cette pile locale sont Databricks, Postgres, Snowflake et DuckDB.
Pour Kubernetes, la page de déploiement indique que les releases sont publiées dans le catalogue public NGC de NVIDIA, avec les images nvcr.io/nvidia/auto-ontology, nvcr.io/nvidia/auto-ontology-frontend et nvcr.io/nvidia/auto-ontology-mcp, ainsi qu'un chart Helm auto-ontology.
Le prix catalogue d'Auto Ontology n'est pas communiqué dans la documentation officielle. Les artefacts sont disponibles via GitHub public et le catalogue NGC public, mais l'usage de la pile locale requiert une clé API NVIDIA pour NIM. Aucune restriction géographique spécifique à la France ou à l'Europe n'est mentionnée. Il faut donc vérifier les conditions d'accès à NIM et les politiques internes de conformité avant un déploiement.
Un point d'attention concerne MCP : la documentation indique que le serveur peut être lancé avec uvx depuis le dépôt GitHub, sous-répertoire mcp, mais précise aussi que cette installation est « NVIDIA-internal today » et qu'un accès GitHub au dépôt reste nécessaire tant que le paquet n'est pas publié sur PyPI.
Pour qui, et pour quoi faire
Le cas d'usage le plus évident concerne les équipes data qui veulent ouvrir l'analyse SQL à des métiers, sans laisser un agent interroger les entrepôts de données au hasard.
Exemple : une direction commerciale veut demander à un agent IA « liste les comptes stratégiques dont le volume de commandes baisse depuis deux périodes ». Pour répondre correctement, l'agent doit comprendre ce qu'est un compte stratégique, quelles tables portent les commandes, quelles dates font foi, et quelles règles excluent les commandes annulées. Auto Ontology peut aider à modéliser ces concepts, leurs relations et les règles de contexte qui guideront ensuite la génération SQL.
Ce type d'approche peut aussi servir à documenter un patrimoine de données existant. ITPro rapporte que Dell Technologies compte s'appuyer sur NVIDIA Auto-Ontology comme bibliothèque open source pour concevoir et construire des knowledge graphs dans sa nouvelle AI Data Platform. L'article mentionne aussi une « Unified Semantic Layer » destinée à donner un sens métier cohérent aux données structurées et non structurées, avec règles, définitions et glossaire consultable.
Limites et points de vigilance
Auto Ontology ne remplace pas la gouvernance data. Une couche sémantique n'est fiable que si les définitions sont validées, maintenues et alignées entre métiers. Si deux directions utilisent des définitions différentes d'un client actif, l'outil ne tranchera pas seul.
La qualité des métadonnées reste déterminante. Des noms de colonnes ambigus, des modèles incomplets ou des règles métier non documentées limiteront la valeur de la couche générée. Il faut prévoir une revue humaine, surtout avant de connecter un agent à des données sensibles.
La dépendance à NVIDIA NIM doit aussi être intégrée à l'architecture cible. Selon les choix de l'entreprise, l'inférence passera par le service hébergé NVIDIA ou par des NIM auto-hébergés. Ce point a des conséquences sur la sécurité, la conformité, les coûts d'infrastructure et l'exploitation.
Enfin, l'accès aux fonctions d'import, d'export et d'administration doit être strictement contrôlé. La documentation API prévoit des contrôles administrateur, mais leur bon usage dépendra de l'intégration avec les droits internes, les journaux d'audit et les processus de validation.
L'avis NXUS
Auto Ontology répond à un vrai problème des agents en entreprise : leur donner un vocabulaire métier stable avant de leur confier du SQL. C'est une brique intéressante pour les organisations qui ont déjà un entrepôt de données, des règles métier et une équipe capable de maintenir un modèle sémantique.
Le bon réflexe consiste à commencer petit : un domaine, quelques tables critiques, des définitions validées, puis des tests de requêtes agentiques supervisés. Il ne faut pas vendre l'outil comme une garantie automatique de vérité.
Pour réussir, associe data engineers, métiers, sécurité et responsables conformité dès le cadrage. Auto Ontology peut fiabiliser le contexte d'un agent, mais la confiance viendra surtout de la gouvernance autour de cette couche sémantique.
Sources
Source : NVIDIA
Rudy Molinillo
