Une définition métier approuvée a besoin d’un test montrant qu’un agent l’a réellement utilisée. Snowflake a annoncé Business Ontology le 3 novembre, avec un aperçu public présenté comme devant arriver bientôt. Pour les équipes data d’entreprise qui l’évaluent, la question de gouvernance consiste à relier le domaine, l’approbation et la version d’une définition à la réponse produite par un agent, en particulier après la modification de cette définition.
L’annonce produit décrit un espace où définir et approuver des concepts métier, puis les relier aux données et aux calculs qui les mettent en œuvre. Un sens partagé peut réduire les interprétations contradictoires, mais les équipes doivent malgré tout établir quel sens s’appliquait à une tâche précise. L’analyse de Maetra ci-dessous propose un petit test d’acceptation pour cette dépendance. Elle n’affirme pas que Maetra a testé l’aperçu, ni que chaque champ de preuve proposé constitue une fonctionnalité native intégrée à Snowflake.
L’annonce sépare le sens du calcul
Snowflake présente Business Ontology comme un élément de Horizon Context au sein de Horizon Catalog. L’entreprise distingue le sens métier approuvé des calculs dans Semantic Views et du contexte inféré fourni par Cortex Sense. Ses exemples autorisent des différences intentionnelles selon le domaine ou la marque, avec des responsables qui approuvent les définitions pertinentes. Il s’agit de descriptions fournies par l’éditeur au sujet de l’architecture visée, et non de mesures indépendantes de précision.
L’annonce générale de Snowflake place l’ontologie aux côtés des contrôles de Cortex AI Gateway. Ces annonces couvrent des stades de disponibilité différents. L’aperçu public prévu pour Business Ontology ne doit pas être confondu avec la disponibilité générale d’autres capacités de la passerelle.
La couverture de Constellation Research rapporte l’annonce de manière indépendante et souligne la nécessité de désigner des responsables, de maintenir les correspondances et de tester les changements. Elle n’établit pas que le produit garantit des réponses correctes. Les acheteurs doivent confirmer leur accès réel et les comportements effectivement pris en charge avant de bâtir un plan de production dépendant de la capacité annoncée.
Une question sur le chiffre d’affaires peut cacher plusieurs sens autorisés
Prenons le cas hypothétique d’un agent à qui l’on demande d’expliquer le chiffre d’affaires net trimestriel pour une équipe finance régionale. La finance a approuvé une définition qui inclut un traitement particulier des remboursements. Une analyse commerciale utilise un concept différent, approuvé séparément. Les deux définitions peuvent être légitimes dans leurs domaines respectifs.
La tâche est incomplète si elle dit seulement « utilisez le chiffre d’affaires approuvé ». Elle doit préciser la période de reporting, le domaine organisationnel, la définition pertinente et le traitement prévu de l’ambiguïté. Un agent qui remplace le concept de la finance par celui des ventes peut produire une réponse plausible tout en échouant à la tâche financière.
Le même problème peut apparaître après un changement. Une définition peut être approuvée aujourd’hui pour des rapports futurs, alors que le rapport d’hier doit rester interprétable selon sa base d’origine. Mettre à jour une définition partagée sans préserver le contexte de la réponse peut compliquer une comparaison ultérieure. C’est pourquoi Maetra recommande de conserver une référence à la définition utilisée, avec une date d’effet ou une version lorsque l’implémentation le permet.
Cette recommandation concerne le sens métier rattaché à une tâche. Elle n’implique pas que l’approbation de l’ontologie autorise chaque opération en aval. L’envoi externe d’un rapport ou la modification d’un enregistrement financier peuvent exiger des décisions d’accès et de politique distinctes.
Réalisez trois tests d’acceptation avant de vous fier à un terme commun
Utilisez un petit jeu de données connu et des résultats attendus validés par le responsable métier. Limitez le périmètre de chaque test afin qu’un relecteur puisse distinguer la sélection du sens du calcul et de la livraison.
D’abord, testez le domaine visé. Posez la question financière en utilisant une définition approuvée par le responsable pour ce contexte. Conservez le concept sélectionné, les références de données pertinentes, la référence de calcul et le résultat. Si l’agent ne peut pas indiquer quelle définition il a utilisée, consignez cela comme une lacune de preuve.
Ensuite, introduisez un conflit intentionnel. Donnez au test accès à deux définitions légitimes avec des portées différentes. Posez une question ambiguë. Convenez à l’avance si le comportement attendu est une demande de clarification, un choix clairement étiqueté ou un refus de produire un chiffre définitif. Évaluez le résultat par rapport à cette attente au lieu de récompenser une réponse formulée avec assurance.
Enfin, modifiez la définition et répétez la tâche. Dans une configuration de test sûre, mettez à jour le sens approuvé ou son mappage. Vérifiez si une nouvelle réponse utilise la révision visée et si la réponse précédente peut toujours être expliquée. Lorsque les références de version ne sont pas disponibles, conservez un instantané contrôlé et enregistrez cette limite.
Il s’agit de cas d’évaluation suggérés, et non de promesses sur le comportement de l’aperçu. Un résultat concluant démontre la configuration testée sur les données sélectionnées. Il ne justifie pas une affirmation générale sur chaque domaine métier, chaque agent ou chaque mise à jour future.
Inscrivez la dépendance dans l’enregistrement de la tâche
Le propriétaire des données doit pouvoir identifier la définition et sa portée. Le responsable de l’ingénierie doit pouvoir identifier le chemin allant de cette définition au calcul. La personne qui accepte la sortie de l’agent doit pouvoir voir si le résultat respecte les conditions convenues pour la tâche.
Conservez ces références avec la tâche et son résultat observable. Si un mappage change, signalez les tests concernés pour révision au lieu de supposer que l’approbation du libellé couvre l’implémentation. Un calcul correct appliqué au mauvais concept reste une réponse inadaptée.
L’analyse de Maetra sur l’alignement des tâches explique la distinction entre le fait de satisfaire un objectif assigné et celui d’obtenir l’autorisation d’une action. Task Guard couvre l’alignement, les changements de portée et la vérification des effets ; Audit prend en charge un historique vérifiable. Pour un flux analytique donné, utilisez la documentation Task Guard afin de définir le sens et le résultat attendus avant d’évaluer la réponse d’un agent.
Sources
- Snowflake, Business Ontology, 3 novembre 2026. Annonce produit principale ; aperçu public à venir prochainement.
- Snowflake, Annonce Expedition, 3 novembre 2026. Source principale pour l’ensemble des annonces et les précisions sur leur disponibilité.
- Constellation Research, Couverture de Snowflake sur le contexte et la gouvernance, 3 novembre 2026. Reportage et analyse indépendants de l’annonce.