Magazine LLM Opensource · 3 November 2026

NVIDIA Auto Ontology : ce que vaut vraiment la couche sémantique ouverte qui veut brancher les agents SQL sur vos données

Le 1er novembre 2026, NVIDIA a mis sur la table un projet qui ne fait pas de bruit de fans ni de démonstration spectaculaire : une couche sémantique open source censée ancrer les agents text-to-SQL dans une représentation fiable du schéma et des métriques métier. Derrière le nom un peu abstrait d’Auto Ontology se cache un problème très concret que toute équipe data connaît : un LLM qui écrit du SQL plausible mais faux. Décryptage de ce que le projet fait réellement, de ce qu’il ne fait pas, et des cas où il vaut la peine de s’y intéresser dès maintenant.

Auto Ontology : l’ambition de NVIDIA de donner un cerveau sémantique aux agents SQL

Commençons par une mise au point honnête, parce qu’elle conditionne la lecture de tout ce qui suit. La matière dont je dispose pour écrire cet article est mince : une annonce de couverture de MarkTechPost datée du 1er novembre 2026, et rien d’autre de directement vérifiable — pas de dépôt GitHub public analysé, pas de papier arXiv, pas de documentation technique consultée, pas de benchmark indépendant. Les sources officielles NVIDIA que j’ai pu parcourir (page d’accueil, pages pilotes, Wikipedia) ne mentionnent pas le projet. Autrement dit : ce décryptage s’appuie sur la description du projet telle qu’elle circule et sur les principes généraux des couches sémantiques, pas sur une lecture du code. Je le dis d’emblée parce qu’un article sur un outil d’infrastructure data qui prétendrait le contraire serait malhonnête.

Cela posé, le problème que le projet attaque est réel, et il est même devenu l’un des points de friction majeurs de l’année 2026. Depuis deux ans, les agents text-to-SQL se sont répandus dans les entreprises avec la promesse de « parler à sa base de données en langage naturel ». Le résultat, sur le terrain, est souvent décevant : le modèle produit des requêtes syntaxiquement valides, qui s’exécutent sans erreur, et qui répondent à côté. Il hallucine une colonne, confond deux tables aux noms proches, invente une jointure, ou — plus insidieux — interprète correctement le schéma mais pas la métrique métier (« le chiffre d’affaires » n’est pas toujours SUM(amount) : cela dépend des remises, des annulations, des devises, de la période de comptabilisation).

La réponse classique à ce problème est le semantic layer : une couche de définition manuelle, maintenue par des humains, qui dit explicitement « voici les tables, voici les métriques, voici comment elles se calculent, voici les synonymes ». C’est ce que font dbt Semantic Layer, les cubes type Cube.dev ou AtScale, et les vues sémantiques de Snowflake ou Databricks. C’est efficace, mais c’est coûteux : il faut des semaines pour le construire, et une équipe pour le maintenir à jour à mesure que le schéma bouge.

L’ambition d’Auto Ontology, telle que la décrit l’annonce, est de rendre cette couche sémantique générée plutôt que rédigée à la main : construire automatiquement une ontologie à partir des catalogues et du schéma existants, la structurer en graphe de connaissances, et s’en servir comme ancrage pour les agents SQL. C’est une idée qui a du sens, et c’est précisément là qu’il faut regarder de près ce que le projet fait vraiment — parce que « générer automatiquement une ontologie » peut vouloir dire beaucoup de choses, de la simple extraction de métadonnées à une vraie inférence sémantique.

Ce que fait vraiment Auto Ontology : ontologie générée, graphe de connaissances et résolution d’entités

Le cœur du projet, tel qu’il est présenté, s’articule autour de trois briques qu’il faut distinguer soigneusement, parce qu’elles n’ont pas le même degré de difficulté ni la même fiabilité.

Première brique : la génération d’ontologie depuis les catalogues et le schéma. L’idée est d’ingérer ce que l’entreprise possède déjà — le schéma physique des bases (tables, colonnes, types, clés), les métadonnées de catalogue (descriptions de colonnes, propriétaires, tags), et éventuellement les définitions de métriques existantes (dbt, vues sémantiques) — pour en extraire une représentation structurée : quelles entités existent, quelles relations les lient, quels attributs les décrivent. C’est un travail d’extraction et de normalisation, pas de magie : si vos colonnes n’ont pas de description et que vos tables s’appellent tbl_f_032, l’ontologie générée sera pauvre, et aucun modèle ne pourra inventer la sémantique absente.

Deuxième brique : le graphe de connaissances. C’est là que se joue la valeur ajoutée. Un schéma relationnel classique est une liste plate de tables et de colonnes. Un graphe de connaissances relie ces objets entre eux et aux concepts métier : la table orders est reliée à la métrique « chiffre d’affaires », qui est reliée au synonyme « CA », « revenus », « ventes », qui est reliée à la table refunds par une relation de déduction, etc. Pour un agent text-to-SQL, cette structure change tout : au lieu de devoir deviner, à chaque question, quelles tables pertinentes aller chercher dans un schéma de 400 tables, l’agent peut naviguer dans le graphe depuis le concept mentionné par l’utilisateur vers les objets physiques correspondants. C’est la différence entre chercher une aiguille dans une botte de foin et suivre un fil.

Troisième brique : la résolution d’entités. C’est le mécanisme qui fait le lien entre le vocabulaire de l’utilisateur et les objets du graphe. Quand quelqu’un demande « le CA de la région Nord sur le dernier trimestre », il faut faire correspondre « CA » à la métrique revenue, « région Nord » à une valeur de la colonne region, « dernier trimestre » à une fenêtre temporelle calculée. La résolution d’entités, c’est ce matching — et c’est là que les couches sémantiques manuelles excellent (parce qu’un humain a explicitement écrit les synonymes) et que les approches automatiques peinent (parce que les synonymes métier sont contextuels, parfois ambigus, souvent non documentés).

Ce que cela change concrètement pour un agent text-to-SQL : au lieu de recevoir en prompt un dump de schéma brut et de générer du SQL à partir de là, l’agent reçoit une représentation structurée, filtrée et reliée. Il peut raisonner sur les concepts métier avant de raisonner sur la syntaxe SQL. C’est une amélioration réelle de la qualité des prompts — mais elle ne garantit rien sur la correction finale de la requête, et c’est un point sur lequel il faut être clair.

Garde-fous d’exécution SQL : ce que le projet contrôle (et ce qu’il ne contrôle pas)

L’annonce mentionne des garde-fous d’exécution, et c’est probablement la partie la plus utile en production — mais aussi celle où les attentes doivent être calibrées.

Ce qu’une couche comme celle-ci peut raisonnablement contrôler : la validation syntaxique et schématique de la requête générée (les tables et colonnes référencées existent-elles vraiment ? les types sont-ils compatibles ?), les restrictions de sécurité (lecture seule, pas de DROP, pas de DELETE, pas d’accès aux tables sensibles), les limites de coût (un SELECT * sur une table de 500 millions de lignes sans LIMIT peut faire tomber un entrepôt), et la gestion des erreurs (retenter avec un message d’erreur, ou échouer proprement plutôt que de renvoyer un résultat faux).

Ce qu’elle ne peut pas garantir : la correction sémantique. Une requête peut être parfaitement valide, s’exécuter en 200 ms, et répondre à la mauvaise question. Le garde-fou valide la forme, pas le fond. Il peut vérifier que revenue existe ; il ne peut pas vérifier que l’utilisateur voulait le revenu net de TVA plutôt que le revenu brut, sauf si l’ontologie contient cette distinction — et si l’agent a correctement résolu l’ambiguïté.

Les limites mentionnées dans le cadrage sont réelles et il faut les prendre au sérieux : la dépendance à la qualité de l’ontologie (une ontologie générée à partir de métadonnées pauvres produira des garde-fous pauvres), l’absence probable de couverture fine des jointures complexes (les jointures à plusieurs sauts, les jointures sur des clés composites, les jointures temporelles) et des fenêtres temporelles (les définitions de « trimestre fiscal », « mois glissant », « année à date » sont notoirement casse-têtes et varient d’une entreprise à l’autre). Sur ces points, une couche manuelle reste devant, parce qu’un humain a explicitement tranché les cas ambigus.

Open source ou open core ? Licences, composants et dépendances réelles

C’est la question qui décidera de l’adoption, et c’est aussi celle sur laquelle je dois être le plus prudent, faute de source primaire. L’annonce qualifie le projet d’« open source », mais il faut distinguer plusieurs choses : le format d’ontologie (probablement ouvert, sinon l’outil n’a aucun intérêt), le générateur d’ontologie (cœur de la valeur, souvent ouvert dans les projets NVIDIA récents), les connecteurs vers les catalogues et bases de données (souvent partiellement ouverts), et le moteur de graphe ou le LLM sous-jacent (souvent propriétaire ou dépendant d’un service).

Les licences probables, au vu des pratiques de l’écosystème NVIDIA en 2026, sont Apache 2.0 ou MIT pour les composants ouverts — mais je ne peux pas l’affirmer pour Auto Ontology sans la documentation. Les dépendances, elles, sont plus prévisibles : un LLM (probablement un modèle NVIDIA NIM, ou un modèle tiers au choix de l’utilisateur), des bases de données supportées (les grands noms du marché, sans doute PostgreSQL, Snowflake, BigQuery, Databricks), et des formats de métadonnées (OpenMetadata, DataHub, dbt — les standards de fait).

L’implication pratique est simple : si le format d’ontologie est ouvert et que les connecteurs couvrent votre stack, vous pouvez adopter sans verrouillage fort. Si le moteur de graphe ou le LLM sont imposés, vous dépendez de NVIDIA pour la partie la plus critique — et c’est un risque à évaluer avant de mettre le projet en production. La bonne question à poser à l’équipe projet : « puis-je exporter mon ontologie et la faire tourner ailleurs ? » Si la réponse est non, ce n’est pas vraiment open source au sens où l’entend une équipe data.

Ingestion et maintenance : le vrai coût caché d’une ontologie vivante

C’est ici que se joue la différence entre une démo séduisante et un outil de production. Une ontologie n’est pas un artefact qu’on génère une fois : c’est un organisme vivant, qui doit suivre les évolutions du schéma et des définitions métier.

Le flux d’adoption réaliste ressemble à ceci : brancher Auto Ontology sur le catalogue existant, générer une ontologie initiale, la valider avec les équipes métier (c’est l’étape que personne ne veut faire et qui prend le plus de temps), puis la maintenir. Le coût de maintenance dépend de trois facteurs : la fréquence des changements de schéma (ajout de colonnes, renommages, nouvelles tables), la fréquence des changements de métriques (une définition de « client actif » qui change au fil des trimestres), et le risque de dérive sémantique (l’ontologie générée s’éloigne progressivement de la réalité métier si personne ne la relit).

Face à cela, les approches manuelles ont un avantage considérable : elles sont explicites et relues. Un dbt Semantic Layer ne génère rien tout seul, mais chaque métrique est écrite, testée, versionnée, et un humain est responsable de sa définition. C’est plus lent à construire, mais plus prévisible à maintenir. L’approche générée d’Auto Ontology promet de réduire le coût initial — mais elle déplace le coût vers la validation et la surveillance, et il n’est pas évident que le total soit plus faible. La vraie question n’est pas « combien coûte la génération ? » mais « combien coûte la confiance dans ce qui est généré ? ».

Un point pratique souvent négligé : la régénération. Si l’ontologie est régénérée à chaque changement de schéma, comment distinguer ce qui a été corrigé à la main (et qu’il faut préserver) de ce qui a été généré (et qu’on peut écraser) ? Sans mécanisme de merge propre, chaque régénération risque de détruire le travail de validation. C’est un problème d’ingénierie classique des couches sémantiques automatiques, et c’est là qu’il faudra regarder le code.

Précision SQL : ce qu’on peut attendre (et ce qu’il faut mesurer soi-même)

Aucun benchmark public vérifié n’est disponible pour Auto Ontology à ce jour — l’annonce ne fournit pas, dans ce que j’ai pu lire, de chiffres sur Spider, BIRD ou d’autres jeux de données text-to-SQL. C’est une lacune importante, et il faut le dire clairement : sans mesure indépendante, on ne peut pas savoir si le projet améliore réellement la précision par rapport à un agent text-to-SQL naïf.

Ce que l’on peut dire, en revanche, c’est ce qu’il faut mesurer soi-même. Les métriques pertinentes sont connues : l’exact match (la requête générée est-elle identique à la requête de référence ? — trop strict, souvent trompeur), l’exécution correcte (la requête produit-elle le bon résultat sur un jeu de données de test ? — la métrique la plus utile), et le taux d’erreur par catégorie (erreurs de schéma, erreurs de jointure, erreurs de métrique, erreurs de filtre temporel). Les biais possibles sont nombreux : un benchmark comme Spider est saturé et ne reflète pas la complexité des schémas d’entreprise ; BIRD est plus réaliste mais encore loin de la variété des métriques métier ; et un benchmark public ne dit rien de votre schéma, de vos définitions, de vos ambiguïtés.

Le protocole d’évaluation réaliste que je recommanderais : constituer un jeu de 100 à 200 questions métier réelles, avec leurs requêtes de référence validées par un analyste, couvrant les cas simples, les jointures à deux ou trois tables, les métriques calculées, et les fenêtres temporelles. Faire tourner l’agent avec et sans Auto Ontology, comparer les taux d’exécution correcte, et regarder où les erreurs se produisent. C’est le seul chiffre qui compte pour votre entreprise — et il vaut mieux le produire avant de déployer que de le découvrir en production.

Auto Ontology face à dbt Semantic Layer, cubes et vues sémantiques : le match

La comparaison est instructive, à condition de ne pas la réduire à « automatique contre manuel ». Chaque approche a ses forces.

Ce que le tableau ne dit pas : les couches manuelles ne sont pas seulement « plus de travail », elles sont aussi plus fiables parce qu’elles forcent une décision humaine sur chaque ambiguïté. Une ontologie générée peut produire une réponse plausible sans jamais avoir tranché si « revenu » inclut les remises. C’est un avantage de la lenteur, et il ne faut pas le sous-estimer.

Faut-il l’adopter maintenant ? Verdict nuancé et signaux à surveiller

Ma réponse, en l’état de l’information disponible, est un « oui, mais » conditionnel.

Adopter dès maintenant si : vous avez un POC text-to-SQL en cours et que vous cherchez à améliorer la qualité des prompts sans construire une couche sémantique manuelle complète ; vos données sont stables (schéma qui bouge peu, métadonnées déjà documentées) ; votre équipe data engineering est à l’aise avec l’idée de valider et de maintenir une ontologie générée ; et vous êtes prêt à mesurer vous-même la précision SQL sur vos propres requêtes. Dans ce cadre, le projet vaut l’expérimentation — le coût d’entrée est faible, et le graphe de connaissances est une idée solide.

Attendre si : vous êtes en production critique avec des exigences de gouvernance fortes ; votre schéma est très mouvant (régénérations fréquentes, risque de dérive) ; vous n’avez pas d’équipe pour valider l’ontologie ; ou vous avez besoin de garanties contractuelles sur les licences et le support. Dans ces cas, une couche manuelle (dbt Semantic Layer, vues sémantiques) reste plus prévisible, même si elle coûte plus cher à construire.

Les signaux à surveiller dans les prochains mois : la publication de la documentation officielle et de la licence réelle, l’activité du dépôt GitHub (commits, issues, contributions externes), les benchmarks indépendants sur Spider/BIRD ou sur des jeux d’entreprise, et les intégrations avec les catalogues (OpenMetadata, DataHub, dbt). Si le projet tient ses promesses sur la génération d’ontologie et que la communauté s’en empare, il pourrait devenir une brique standard des agents d’entreprise — au même titre que les couches sémantiques manuelles qu’il ne remplace pas, mais qu’il complète.

Ce que cela change pour l’écosystème, en fin de compte, c’est moins l’outil lui-même que le signal : NVIDIA considère la couche sémantique comme un composant d’infrastructure pour les agents, pas comme un détail d’implémentation. C’est une reconnaissance que le text-to-SQL ne se résoudra pas par un meilleur modèle seul, mais par une meilleure représentation des données. Et ça, c’est un progrès dont toute l’industrie profitera — quel que soit le sort d’Auto Ontology.

Sources

• NVIDIA Releases Auto Ontology: An Open Semantic Layer That Grounds AI Agent SQL — MarkTechPost, 1er novembre 2026
• NVIDIA Releases Nemotron 3.5 Transcribe: An Open 30B MoE Model for 40-Language Transcription — MarkTechPost, 28 octobre 2026
• Page d’accueil NVIDIA (en-us)
• NVIDIA — Wikipédia
• Open Source LLM Comparison Table (2026) — ComputingForGeeks
• Best Open Source LLMs — Thunder Compute

Article recherché et rédigé automatiquement · Magazine Electrosens