Les news du mois

Avant d’entrer dans le dossier, place aux news du mois : ce qui change sans prévenir, les dates à retenir avant novembre, les droits, puis l’ingénierie.

Ce qui change sans prévenir

Les secrets OAuth d’un principal de service s’effacent après 90 jours sans usage. La règle est propre à la plateforme Databricks et s’applique quel que soit le cloud, Azure, AWS ou GCP ; elle vise les secrets OAuth émis par Databricks, pas ceux d’une application Entra ID. Appliquée depuis le 16 septembre, elle frappe ce que personne ne surveille : le traitement trimestriel, le secret de secours rangé pour le jour où. À faire : inventorier les secrets dormants, ou passer à la fédération d’identité.

Sous profil de sécurité de conformité, deux défauts s’ouvrent. Les Apps et Unity Gateway deviennent actifs par défaut. Sous un profil de conformité, un défaut qui s’ouvre mérite une revue, pas une découverte.

Côté Power BI, deux défauts de septembre qui touchent directement le sujet du dossier.

• PBIP passe en GA, et PBIR devient le format par défaut : un rapport historique est converti automatiquement à sa première édition. À cadrer avant que les équipes ne le découvrent dans un dépôt Git.
• Un nouveau réglage, « Allow any person with read-only access to use AI », est activé par défaut. Il ouvre Copilot Power BI, Microsoft 365 Copilot, les agents de données et les serveurs MCP distants à tout lecteur. Autrement dit, la frontière recule aussi chez Microsoft, et par défaut.

Quatre dates avant novembre

Le mois a été dominé par des dates de retrait plus que par des nouveautés. Quatre à mettre dans l’agenda :

• 30 octobre : retrait de Kimi K2.7 comme modèle hébergé.
• 31 octobre : retrait de l’ancien point d’accès MCP de Genie. Le serveur MCP Genie One est GA depuis le 25 septembre, sous system.ai.genie_one_mcp : migrer les clients avant la date.
• 1er novembre : suppression du réglage « partner-powered AI ». Vérifiez ce que votre compte avait désactivé, et ce qui en dépendait.
• 31 janvier 2027 : fin de la gratuité de Genie One et des Genie Agents, déjà signalée dans le #3. Le régime qui suivra n’est toujours pas publié.

Et une préversion à activer maintenant, parce qu’attendre détruit. La rétention des tables système devient configurable (Beta, note du 9 septembre) : un réglage de compte unique, de 30 à 3 650 jours, avec un nouveau défaut à 395 jours. Gratuit pendant la Beta, le stockage au-delà de 395 jours sera facturé à la GA. Le point qui décide : augmenter la rétention ne remonte pas le temps, « does not backfill ». Chaque mois sans l’activer est un mois d’historique d’audit et de facturation perdu.

Les droits : le refus, et l’historique

ABAC sait désormais refuser, et le refus l’emporte sur le propriétaire. Les politiques DENY arrivent en Beta (page du 8 septembre), quatrième type de politique ABAC. Un seul privilège est refusable, MANAGE ACCESS CONTROL, mais le refus passe devant tout octroi, y compris l’octroi implicite du propriétaire, et s’applique aux objets présents comme futurs. Le cas d’usage est clair : empêcher qu’un propriétaire de table ne rouvre lui-même l’accès à ce qu’une politique protège.

Trois réserves, et la première est la plus coûteuse :

• SHOW GRANTS n’affiche pas les DENY, pas plus que les API de permissions. Un inventaire de droits construit sur ces sorties surestime ce que les gens peuvent faire. Il faut lire SHOW EFFECTIVE POLICIES.
• Un DENY conditionné par un tag se lève en retirant le tag. On retrouve la phrase du mois dernier, « tagging is a security boundary ».
• La portée métastore (Beta depuis le 17 septembre) s’applique à tous les catalogues, y compris ceux créés ensuite. Dans un métastore partagé, elle touche donc toutes les divisions.

Le voyage dans le temps fonctionne enfin sous ABAC. Jusqu’ici, une requête VERSION AS OF ou TIMESTAMP AS OF sur une table protégée était tout simplement refusée. Depuis le 23 septembre, en Beta, elle passe, et les filtres et masques ABAC s’appliquent à l’historique : la politique d’aujourd’hui protège les données d’hier (DBR 19+, table managée avec catalog commits). Mais la documentation est claire, « Time travel on tables with table-level row filters or column masks isn’t supported. » Sous un filtre posé table par table, l’historique reste inaccessible : un argument de plus pour la politique par tag.

Le partage, lui, laisse partir la donnée entière. Une table sous ABAC peut se partager par OpenSharing si le fournisseur du partage est exclu des politiques, mais le destinataire y accède alors en entier. Et dans un partage de schéma complet, les tables à filtre ou masque sont retirées sans message. La règle à retenir : on partage un objet déjà réduit, on ne compte pas sur la politique pour voyager avec.

Ingénierie et SQL

ai_decide fait entrer un modèle de décision dans le SQL. En Beta depuis le 30 septembre, la fonction pose des questions fermées sur un état décrit en texte et renvoie une probabilité, un choix parmi 1 à 255 étiquettes, ou un score sur 2 à 10 niveaux. Elle arrive dans le sillage du sujet du moment, Jev : un modèle de TypeSafe AI annoncé le 15 septembre, en accès anticipé, qui ne génère pas de texte mais rend des décisions typées avec leur probabilité, en 70 à 500 ms. ai_decide en reprend le schéma, pas le modèle : le sien est sous licence Apache 2.0 et reste dans le périmètre de la plateforme, quand un appel à Jev sort de la passerelle. Deux réserves avant d’en faire un critère métier : les résultats ne sont pas déterministes et un échec ne lève pas d’erreur, et ni la disponibilité régionale en West Europe ni le prix ne sont publiés à ce jour.

MATCH_RECOGNIZE arrive en Beta (DBR 19 et Databricks SQL). La reconnaissance de motifs de lignes en SQL ANSI natif : on nomme des états par une condition, puis on les enchaîne comme une expression régulière. Une restriction à connaître, seul AFTER MATCH SKIP PAST LAST ROW est supporté, donc pas de correspondances qui se chevauchent.

Le dossier : le contexte, nouvel enjeu de la donnée

L’ontologie, c’est le contexte de l’entreprise

Avant de parler de frontière, partons de ce qu’on cherche à transmettre : le contexte de l’entreprise. Pour le transmettre à un nouveau collaborateur, il y a deux façons de faire.

• La première, lui expliquer en détail le fonctionnement de l’entreprise : l’organigramme, qui porte quelle responsabilité, les acronymes, les indicateurs et la façon de les calculer. C’est l’ontologie dictée.
• La seconde, l’emmener en réunion et le laisser comprendre de lui-même. Il observe, il recoupe, il retient ce qui revient souvent. C’est l’ontologie déduite.

Dans le premier cas, il aura une vision juste du fonctionnement de l’entreprise, à condition que l’explication soit à jour.

Dans le second, il apprendra vite et beaucoup, y compris ce que personne n’a jamais écrit, mais il risque de faire des contresens.

Par exemple :

• Croire qu’un département porte une responsabilité alors que c’est un autre qui l’assume.
• Penser que c’est Antoine qui gère la comptabilité, parce que c’est lui qui en parle le plus en réunion, alors que c’est Emmanuelle.

Le contresens est la conséquence logique d’un apprentissage par l’observation : on retient ce qui revient souvent, pas forcément ce qui est vrai.

Et dans la réalité, l’accueil est presque toujours un peu des deux : dicté au sein du service où l’on exerce, déduit dans le reste de l’entreprise.

Votre responsable vous explique en détail comment fonctionne votre équipe ; le reste de l’organisation, vous le comprenez au fil des réunions.

Pourquoi maintenant ?

L’ontologie n’est pas une invention de l’IA générative. OWL, RDF, SPARQL et SHACL sont des standards du W3C qui ont vingt ans, et les projets de knowledge graph d’entreprise des années 2010 les ont largement utilisés avant de s’arrêter. Pas pour une raison technique, pour une raison d’économie : la curation coûte cher, et le consommateur final était humain. Un humain compense, devine laquelle de deux tables voisines est la bonne, ou appelle le collègue qui sait. Le coût était réel, le bénéfice diffus.

Ce qui change en 2026, c’est le consommateur. Un agent ne devine pas et ne téléphone pas, il choisit une table et applique une définition. Le contexte qui restait implicite devient la variable qui décide si la réponse est juste. Et pour comprendre où ces agents vont chercher ce contexte, il faut regarder où passe la frontière.

Du dashboard à gold : la frontière a reculé

Dans l’architecture que la plupart de nos clients connaissent, la frontière métier passait par le modèle sémantique. En amont, une affaire d’ingénieurs : bronze, silver, gold, organisés comme cela arrangeait les traitements. En aval, une affaire de métier : espaces de travail par direction, modèles par périmètre, rôles de sécurité dans le rapport. Le domaine métier était une propriété de l’outil de visualisation, pas de la donnée.

Les surfaces conversationnelles lisent gold directement. Un Genie Agent ne passe par aucun modèle Power BI. Il interroge les tables et les metric views qu’on lui attache.

La conséquence n’est pas une préférence d’architecte, elle est mécanique : ce que l’outil de restitution portait, la donnée doit le porter. Le découpage par domaine, les définitions, la sécurité.

La couche gold est donc directement impactée car gold s’organise par domaine. Silver suit dès qu’un domaine publie des entités que d’autres consomment, ou qu’un agent a besoin de finesse. Et enfin, bronze reste organisé par source : c’est la couche de la traçabilité, le métier n’y accède pas.

Structurer par domaine, c’est réorganiser physiquement ? Pas nécessairement, et c’est le point le plus important de cette section. Unity Catalog offre deux leviers distincts, qui ne répondent pas à la même question :

• Le domaine Unity Catalog est un tag gouverné, pas un conteneur. Le rattachement est indépendant de la hiérarchie catalogue/schéma et un asset peut appartenir à plusieurs domaines. C’est le levier de la découverte et du contexte : ce que voit Genie, ce que filtre la page Discover.
• Le catalogue et le schéma restent le levier des droits et de la propriété. Les privilèges sont hiérarchiques, MANAGE se borne à un périmètre.

Les deux se combinent et le modèle de référence de l’Architecture Center le montre bien : le même modèle logique se déploie en un catalogue unique, un catalogue par division ou un catalogue par domaine, par un simple paramètre. La maille physique devient une décision de déploiement, guidée par les droits ; le domaine logique, lui, n’est pas négociable. Si vous ne deviez faire qu’une chose ce trimestre, ce serait de taguer les objets gold (tables, vues, etc.) par domaine, sans rien déplacer.

Ouvrir gold fait monter la sécurité d’un cran

Ouvrir gold aux usages conversationnels fait aussi remonter la sécurité. Bien souvent, du côté d’un Power BI, l’accès aux données se fait via une copie locale et la sécurité se trouve de son côté via des RLS ou OLS (bloquer l’accès à une table du modèle, par exemple).

Un Genie Agent, lui, évalue toujours l’accès avec l’identité de celui qui demande.

Voici un scénario qui peut se produire : une organisation a publié ses rapports Power BI en mode import et n’a donc jamais eu besoin d’une sécurité fine sur ses tables gold. Elle branche un Genie Agent sur le même gold et découvre en une journée que chacun voit tout, parce que rien n’avait jamais été posé sur la donnée. C’est la conséquence de l’évolution de la frontière qui n’a pas été prévue. L’organisation qui porte déjà sa sécurité sur la donnée a fait ce pas, et n’a pas de second modèle de sécurité à maintenir dans son outil de restitution.

La réponse est de porter filtres et masques sur la donnée elle-même, idéalement par tag de domaine avec ABAC, comme le montrent les news du mois : une seule politique couvre toutes les tables taguées, y compris celles créées demain.

Genie Ontology, l’ontologie déduite

« Le piège, c’est de croire qu’un outil va produire cette ontologie à notre place. » La phrase est juste, et c’est pourtant exactement le pari que prend Databricks. Plutôt que d’attendre qu’une ontologie soit construite à l’échelle de l’entreprise, ce qui n’arrive presque jamais, Genie Ontology la déduit. C’est aussi la deuxième raison de structurer par domaine, et à mon sens la plus pressante, parce qu’elle tourne déjà chez vous : elle est activée par défaut depuis le 6 août et ouverte à tous depuis le 13 août.

Elle combine deux blocs, que la documentation nomme précisément :

• Unity Catalog semantics, le contexte modélisé : ce que vous définissez, gouvernez et certifiez à travers des fonctionnalités comme les metric views, les UC domains et UC Pages.
• Inferred context, le contexte déduit : une cartographie de fragments que Genie extrait automatiquement et maintient depuis vos assets existants et de leur usage incluant les metric views, dashboards, requêtes SQL et Genie Agents. Les notebooks, absents de la documentation, figuraient parmi les sources dans l’annonce de juin et apparaissent dans les démonstrations de l’éditeur.

Chaque fragment déduit reçoit un score d’autorité, en fonction de sa provenance, de sa fréquence d’utilisation et de sa fraîcheur, filtré par les droits Unity Catalog. Puis Genie « ranks the most relevant snippets, resolves conflicts, and answers ».

Databricks recommande de documenter les notebooks en cellules Markdown précisément parce qu’ils servent de contexte. Tout ce qui existe nourrit l’ontologie, y compris ce qui est faux. Le dashboard abandonné depuis deux ans, la requête jetable d’un stagiaire, le notebook d’analyse qui joint mal deux tables et dont la jointure devient un conseil pour tous, les deux définitions concurrentes du chiffre d’affaires qui circulent entre deux directions : ce n’est plus du code mort, ce sont des signaux d’apprentissage. Et le score d’autorité monte avec l’usage, si bien qu’une table sollicitée dans le cadre de nombreuses jointures parce qu’elle est ancienne et mal découpée l’emporte sur une table propre et récente. La démonstration même de l’éditeur en donne l’illustration la plus parlante, une table nommée adoption2026_vActuallyFinal que le graphe reconnaît comme faisant foi parce que tout le monde s’en sert. Une présence centrale ne constitue pas forcément la justesse : c’est le contresens du nouvel arrivant. Et l’exemple d’Antoine n’est pas qu’une image : dans les démonstrations de l’éditeur, le graphe désigne déjà des « experts » par domaine, des personnes nommées, déduites de ce qu’elles produisent et de l’usage qui en est fait. Celui qui publie beaucoup monte, l’experte qui répond à l’oral n’apparaît pas.

Vous entendrez en conférence le nom OntoRank ; la documentation parle de score d’autorité.

Genie Ontology va donc fonctionner dès le début et il s’agira d’un projet empirique pour améliorer la véracité et la précision de ces résultats. Néanmoins, des actions sont à mener de front pour apporter un maximum de qualité lorsque c’est possible : modélisez la tête, ce qui ne peut pas être faux, et laissez la déduction couvrir le reste.

Genie déduit ce que vous n’avez pas déclaré. Ce que vous déclarez, il le tient pour vrai. La question est donc : que voulez-vous qu’il tienne pour vrai ?

OntoBricks, l’ontologie dictée

Quand on veut imposer une ontologie plutôt que la laisser se déduire, l’éditeur propose une autre voie. Le schéma ci-dessous met les deux côte à côte.

À gauche, Genie Ontology, l’ontologie déduite. Elle répond à la question « qu’est-ce que ça veut dire, maintenant, sur tout ce qu’on a ». Vivante, alimentée par le travail ordinaire, mais elle classe sans raisonner, et ne fournit pas de référence reproductible.

À droite, OntoBricks, l’ontologie dictée. C’est un projet Databricks Labs qui transforme des tables Unity Catalog en graphe de connaissances. On y conçoit son ontologie, ou on importe un référentiel sectoriel comme FIBO pour la finance ou HL7 FHIR pour la santé, aux standards du W3C ; un moteur raisonne et valide la donnée selon des règles déclarées. Il répond à une autre question : « qu’est-ce qui est prouvablement vrai dans ce domaine ». Versionnée, reproductible, donc qualifiable dans un processus validé.

Deux précisions avant de le recommander. Dictée ne veut pas dire écrite à la main : OntoBricks embarque lui aussi un assistant IA qui peut proposer le design de l’ontologie et générer les correspondances. La différence n’est pas l’absence d’IA, c’est que rien n’entre sans qu’un curateur l’ait validé, et que le résultat se rejoue. Et c’est un projet Labs, en version 0.8.0, « not formally supported by Databricks with Service Level Agreements », sous licence Databricks. À piloter, pas encore à industrialiser.

À noter : côté Microsoft aussi, l’ontologie passe sur le devant de la scène. À la FabCon de Barcelone, fin septembre, Microsoft a présenté une nouvelle expérience de création d’ontologie dans Fabric IQ, en preview : un agent propose entités, relations et règles à partir des modèles sémantiques et des données OneLake, et l’humain relit avant d’appliquer. C’est donc une offre dictée, en attendant peut-être une approche déduite comme celle de Genie. Un point d’attention pour les clients qui restituent dans Power BI : les métriques de l’ontologie Fabric viennent des mesures DAX, celles de Genie des metric views, et aucune ne lit l’autre. Il faudra décider où vit la définition d’un indicateur.

Faut-il choisir ? Non, et l’argument est économique plutôt que doctrinal : imposer 100 % de la sémantique par la curation humaine, c’est en rater l’essentiel faute de capacité, et les gens contournent ce qui manque. D’où le motif de composition qui me sert d’architecture cible : le déduit découvre les candidats depuis l’usage réel, le curateur formalise ceux qui comptent, et l’enjeu décide de la source. Le réglementaire, le litigieux, ce qui engage une signature va à droite ; la longue traîne peut vivre à gauche. Une documentation qui dirait « le modèle a utilisé une ontologie » sans préciser laquelle laisse un trou qu’un auditeur trouvera avant vous.

Et l’on retrouve le nouvel arrivant, à qui l’on dicte le fonctionnement de son service et qui déduit le reste de l’entreprise. C’est exactement la ligne de partage qui tient pour l’ontologie, et c’est ce qui relie les deux moitiés de ce dossier : le domaine est le périmètre de la dictée.

Chaque domaine déclare ce qu’il possède, ses indicateurs, ses termes, ses actifs de référence ; pour tout ce qui n’appartient à aucun domaine curé, Genie déduit. Plus vos domaines sont nombreux et tenus, plus la part dictée grandit, et moins Antoine passe pour le comptable.

Le domaine est la maille qui dure

Dernier point, et c’est celui sur lequel je serai le plus catégorique : le projet n’est pas la bonne maille.

C’est pourtant le réflexe naturel. On lance un projet, on crée un schéma, on donne des droits à l’équipe projet, on documente dans l’espace du projet. Sauf qu’un projet a une date de fin et un domaine n’en a pas. À la clôture, la table gold reste et les usages restent, mais le propriétaire s’est dissous avec l’équipe : plus personne ne valide les définitions, ne répond des accès, ni ne décide si l’objet doit vivre. Avec une ontologie qui apprend de l’usage, le problème change de nature : l’actif orphelin continue d’être cité, avec l’autorité de la machine.

C’est l’une des quatre erreurs types que documente un retour d’expérience Data Mesh publié cet été par un MVP Databricks, aux côtés des tables gold recréées par chaque équipe, de la logique métier dupliquée et de l’absence de documentation. Quatre erreurs, et une grille d’audit toute faite.

La règle tient en une phrase : la responsabilité s’attache à ce qui dure. Le projet livre, le domaine possède.

Le modèle d’organisation qui va avec est un compromis réaliste, loin du Data Mesh doctrinaire : l’équipe centrale garde l’ingestion, bronze, la plateforme, les standards et la sécurité ; les équipes de domaine possèdent la logique métier et publient leurs produits de données en silver et gold. Les data engineers ne disparaissent pas, ils construisent la plateforme qui rend les autres autonomes. Et la documentation de Unity Catalog prévoit justement, par domaine et sous-domaine, un propriétaire technique et un propriétaire métier.

Par où commencer

Sans réorganiser l’entreprise, parce que c’est la vraie question qu’on me pose. Le guide de l’éditeur et le playbook de déploiement de Genie One publié le 28 septembre convergent sur la même démarche, et je la reprends à mon compte :

• Un domaine, un indicateur. L’exemple donné est le revenu récurrent annuel, choisi là où les équipes réconcilient déjà des chiffres à la main. Le critère de choix n’est pas la valeur, c’est la disponibilité d’une vérité terrain : vous savez déjà à quoi ressemble la bonne réponse.
• Le gold de ce domaine tagué, ses tables décrites, ses indicateurs en metric views, ses termes en Pages, ses actifs de référence certifiés. Le playbook compte une à deux semaines pour cette phase.
• Un jeu de 25 à 50 questions à réponse connue, rejoué après chaque changement. C’est le livrable que l’éditeur laisse explicitement à votre charge : pour Genie One et l’ontologie, « your team should define and own the question set, ground truth, source validation, manual review process, and acceptance thresholds ». Commencez par les questions dont deux directions n’ont pas la même réponse : ce sont les seules qui font avancer la gouvernance.
• Un pilote de quatre à six semaines avec cinq à dix utilisateurs, avant d’étendre à deux ou trois domaines.

Deux facilités aident à démarrer proprement : un domaine se prépare en brouillon, visible des seuls curateurs, ce qui permet de faire relire une cartographie complète avant de l’exposer ; et le rattachement par tag est scriptable, là où l’interface traite un actif à la fois, donc c’est la seule voie tenable au-delà de quelques dizaines d’objets.

Une réserve pour finir, parce qu’elle conditionne le calendrier : les domaines sont en Public Preview, les Pages en Beta, l’ontologie en Public Preview. Une Public Preview Databricks est utilisable en production, mais un plan de transformation qui repose dessus doit le dire, et les Pages n’ont pas encore de versionnage. Le travail de fond, lui, ne dépend d’aucune préversion : des définitions partagées, des propriétaires nommés, des descriptions justes et des actifs morts retirés paient de toute façon.

L’outil du mois : Genie Ontology Readiness

Un numéro consacré à la préparation méritait un outil de diagnostic. Genie Ontology Readiness est une application Databricks publiée par l’équipe Field Engineering de l’éditeur, dans le dépôt databricks-solutions. Elle évalue la maturité d’un espace de travail pour Genie Ontology et rend un score de 0 à 100 avec un stade de maturité, réparti sur sept piliers : Unity Catalog, métadonnées, relations, metric views, Genie Agents, domaines et adoption. Chaque pilier se déplie sur les signaux mesurés et les manques relevés.

Trois points pour en juger l’usage :

• Elle ne lit que des métadonnées, jamais le contenu des tables : information_schema, les tables système d’accès et de requêtes pour l’adoption, et l’API des modèles de fondation pour proposer un plan.
• Elle s’installe en bundle, avec un databricks bundle deploy puis un script de post-déploiement, et s’exécute sous l’identité du lecteur avec repli sur le principal de service de l’application, qui demande BROWSE sur les catalogues évalués et SELECT sur les tables système.
• Les sept piliers recoupent presque exactement les sujets de ce dossier, ce qui en fait un bon point de départ d’atelier : on arrive avec une image du patrimoine, pas avec un questionnaire.

À savoir : c’est un exemple de Field Engineering, « not an official Databricks product », sans SLA ni engagement de maintenance, sous licence Databricks. Le score est un indicateur de conversation, pas une note opposable, et le repli sur le principal de service mérite d’être cadré avec votre RSSI avant l’installation.

Pour conclure

Pendant quinze ans, la frontière métier passait par un outil, et cet outil portait sans le dire le découpage, les définitions et la sécurité. Elle passe désormais par la donnée. La façon la plus simple de mesurer le chemin qui reste tient en trois questions : vos tables gold sont-elles taguées par domaine, vos indicateurs litigieux ont-ils une définition déclarée et un responsable, et savez-vous ce que Genie Ontology a déjà déduit chez vous ? Si les trois réponses ne viennent pas en une réunion, l’ontologie a déjà commencé à trancher à votre place.

Rien de tout cela n’est spectaculaire. Taguer, décrire, certifier, retirer ce qui est mort : des chantiers que l’on ne finançait pas parce qu’ils ressemblaient à du ménage. Ils sont devenus le réglage de la justesse de vos réponses.

Vous vous demandez où passe la frontière dans votre organisation, et ce que l’ontologie a déjà appris de votre patrimoine ? Échangeons pour l’évaluer sur un premier domaine.

À bientôt.

Donatien Tessier, Head of Data, I-Shane | Databricks Champion