Auto-Ontology : qui a validé le sens du mot actif ?
Définitions métier, droits de l'appelant et stockage des identifiants demandent des vérifications distinctes.
Un tableau de bord demande le nombre de clients actifs. Une équipe compte les achats, une autre les connexions. Deux requêtes SQL valides peuvent produire des réponses différentes. Auto-Ontology, de NVIDIA, propose de placer ces définitions dans une couche que des personnes examinent avant son utilisation par un agent.
Ce billet du 4 novembre repose sur la documentation et le code. Je n'ai installé aucun service ni mesuré la qualité des réponses. La réduction des erreurs annoncée reste une affirmation du projet. Pour un essai, je chercherais une définition qu'un autre analyste peut expliquer et une requête qu'il peut reproduire.
Ce que contient la couche
Le dépôt officiel décrit l'extraction des schémas, le profilage des colonnes et l'échantillonnage des valeurs. Le service propose des termes, des relations entre tables et des attributs SQL. Il conserve le contexte dans Postgres avec des embeddings pgvector. Les échantillons peuvent contenir des valeurs réelles : il faut examiner les destinations des données et la configuration des modèles avant la connexion.
Un terme relie un concept métier aux colonnes. Un attribut SQL définit une expression de mesure, par exemple une marge. Les relations décrivent les jointures. Des personnes corrigent puis certifient le brouillon. Cette certification doit traiter les remboursements, les factures annulées et la date de la période comptable. Une validation sans ces décisions ne suffit pas.
Préparation et couverture de la question
Le guide MCP distingue check_readiness et check_answerable. Le premier vérifie la présence d'une couche compilée et d'une connexion utilisable. Le catalogue peut survivre à sa connexion. Le second évalue si la couche couvre la question ; une définition incorrecte peut malgré tout sembler adaptée.
ask_question exécute le parcours text-to-SQL et renvoie séparément la réponse, le SQL et les lignes. Les lignes sont limitées à 100, avec row_count et truncated pour signaler la limite. Il faut examiner ces champs avant de considérer la liste visible comme complète. Un agrégat demande aussi une vérification des filtres et de l'expression.
Les droits suivent la personne
Le guide d'authentification précise qu'un jeton API agit avec le rôle de son propriétaire. Un script n'obtient pas de nouveaux droits. La durée par défaut est illimitée ; choisissez une expiration et une procédure de révocation. Créer ou révoquer des jetons exige une session connectée.
Le service MCP appelle l'API publique Next.js. La documentation décrit une connexion par utilisateur et une vérification des jetons opaques via UserInfo. Un essai devrait comparer deux comptes synthétiques de droits différents, vérifier un refus puis réessayer après révocation. Cet examen ne confirme pas les mêmes protections pour un backend interne exposé séparément.
Vault est désactivé par défaut
Le guide des connexions exige les quatre variables VAULT_ADDR, VAULT_NAMESPACE, VAULT_ROLE_ID et VAULT_SECRET_ID. Une configuration partielle est ignorée avec un avertissement ; les identifiants sont alors conservés en clair dans Postgres. Le module Vault et le service de connexion confirment ce choix dans le code.
Vérifiez le stockage effectif avec de faux identifiants, sauvegardes comprises. La présence d'une variable ne démontre rien. Ne recopiez jamais les secrets dans le rapport de diagnostic.
Un essai limité
Préparez des factures fictives, dont une annulée et une remboursée, plus un client connecté sans achat. Écrivez les résultats attendus pour deux définitions de l'activité. Conservez le SQL et le terme retenu. Ajoutez une question que les données ne permettent pas de traiter. Ces vérifications sont proposées, elles n'ont pas été exécutées.
La licence Apache-2.0 fixe les conditions de réutilisation. Le dépôt inspecté comprend un commit du 3 novembre modifiant les modèles par défaut. Cela indique une maintenance récente, sans prouver l'aptitude à recevoir des données réelles. Je commencerais par une mesure métier et une base en lecture seule, puis élargirais l'accès après vérification des définitions, des refus et du stockage des identifiants.