Okta gouverne le contexte de ses agents IA par pull request dans dbt

Chez Okta, l'équipe d'analytics engineering de Pooja Crahen compte environ treize analytics engineers répartis entre la delivery, le go-to-marketgo-to-marketLa stratégie qui définit comment vous lancez un produit : segments cibles, canaux, proposition de valeur et plan d'action coordonné.Voir la définition complète →, le produit et la finance, au sein d'une organisation qui utilise Tableau pour le reporting et Snowflake comme entrepôt central. Ses premiers agents ont été montés vite. Les expériences reposaient sur des semantic views construites directement dans l'interface de Snowflake et branchées sur des agents Snowflake Cortex. Cela fonctionnait, et rapidement, mais ces vues n'avaient aucun lien avec les modèles dbt gouvernés qui portaient la logique métier. Après deux ans de pratique, Crahen a résumé le constat : construire l'agent n'a jamais été la partie difficile. La difficulté, c'est ce que l'agent peut voir et à quoi il peut se fier.

La thèse de cet article découle de ce cas. Le contexte d'un agent (définitions, règles d'usage, filtres obligatoires) doit être gouverné comme du code de production : au même endroit que la logique métier, relu avant fusion, historisé, puis publié dans un format neutre que tout agent peut lire. Tout contexte stocké ailleurs, dans une interface, un prompt systèmeprompt systèmeLes instructions cachées qui définissent le comportement d'un assistant IA avant toute question : son rôle, son ton, ses limites et ses règles.Voir la définition complète → ou la configuration d'un agent, est un risque que personne n'audite. Le paradoxe vaut d'être noté. Okta vend de la gouvernance d'identité pour agents, et son offre traite les agents non humains comme des identités à part entière dans Universal Directory, avec des identifiants à courte durée de vie. L'identité dit ce qu'un agent a le droit de toucher. Elle ne dit rien de ce que l'agent croit comprendre des données. Précision de méthode : le récit détaillé provient du blog de dbt Labs, éditeur de l'outil au centre du dispositif, qui relate une session de Crahen au dbt Summit 2026. Aucun chiffre de précision n'y est publié.

Comment Okta a reconstruit la gouvernance du contexte de ses agents

Trois failles, trois symptômes

L'équipe a d'abord posé un diagnostic. Elle a relevé trois failles : une fragmentation du contexte entre Snowflake et dbt, aucune auditabilité puisque tout vivait dans l'historique de clics de l'interface, et des instructions d'agent écrasées en un seul bloc indifférencié, sans distinction entre ce que l'agent doit toujours savoir et ce qu'il doit aller chercher.

En aval, ces failles produisaient des symptômes concrets. Personne ne savait ce qui existait, faute de catalogue exposant les semantic views hors de Snowflake. Personne ne pouvait se fier à ce qu'il trouvait, faute de référentiel confirmant que c'était à jour. Chaque équipe finissait par redéfinir ses propres indicateurs au lieu de partir d'une base commune.

Pour un responsable de la sécurité des données, la deuxième faille est la plus grave. Quand la règle qui oriente la réponse d'un agent n'a ni auteur identifiable ni date de modification, aucune revue a posteriori n'est possible. Il devient impossible de répondre à la question « qui a changé cette consigne, et quand ? ».

Un cadre de contexte en trois couches, livré par pull request

La réponse a été un cadre de contexte en trois couches, construit entièrement dans dbt et livré par des pull requests classiques.

• Les métadonnées de modèle et de colonne. Le YAML reçoit un nouveau sous-bloc « agent » qui indique à quoi un modèle peut servir sans risque, pour quoi l'éviter, et quels filtres doivent s'appliquer automatiquement. C'est une politique d'usage écrite dans les métadonnées, proche de ce qu'une démarche declassification des données et de contrôle d'accès formalise pour les humains.
• Les documents de contexte. Rédigés en markdown, ils consignent les faits valables pour toute l'entreprise (l'exercice fiscal d'Okta commence le 1er février) et les règles de routage propres à chaque domaine.
• La couche sémantiquecouche sémantiqueUne couche de définitions métier partagée entre données brutes et rapports, pour que chacun calcule revenu, churn ou marge de la même manière.Voir la définition complète →. Les semantic views, sorties de l'interface Snowflake et réécrites dans la spécification de couche sémantique de dbt, deviennent la source gouvernée et relue des faits, dimensions et métriques.

La migration a été outillée plutôt que faite à la main : une skill sur mesure, appelée par une commande slash, extrait le DDL d'une semantic view Snowflake existante et le convertit automatiquement en spécification dbt.

Agents SchemaSchemaUn schema est le plan formel qui définit comment les données sont structurées, nommées, typées et reliées entre elles au sein d'une base de données, d'un fichier ou d'un message.Voir la définition complète →, la couche neutre lue par Cortex comme par Claude

Les trois couches ont une destination commune. Elles se synchronisent automatiquement dans Agents Schema, un standard de métadonnées ouvert et natif de l'entrepôt, de sorte que tout agent disposant d'un accès SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète →, Cortex ou Claude, lit la même source de vérité. Agents Schema est publié par Fivetran et dbt Labs, deux acteurs commerciaux. Le principe reste simple : il place le contexte dans l'entrepôt lui-même, dans un schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → AGENTS standard, pour que les agents interrogent les métadonnées à côté des données sur lesquelles ils raisonnent. Le dépôt annonce comme sources dbt, Looker, Omni, OSI, Sigma et des skills markdown, et comme destinations Snowflake, Databricks, BigQuery et ClickHouse. Pour Okta, l'intérêt est la portabilité : le contexte ne dépend plus du moteur d'agent du fournisseur d'entrepôt.

Faire entrer les agents eux-mêmes dans le DAG

Crahen a poussé la logique plus loin dans une discussion publique sur le dépôt dbt-core, en juin 2026. Elle y constate que les garanties de gouvernance que dbt apporte aux tables, vues et semantic views ne s'étendent pas encore aux agents. Elle propose de gérer les définitions d'agents comme des artefacts dbt, versionnés dans git, déployés par CI/CD et visibles dans le lignage, avec ref() dans les ressources d'outils pour que les agents apparaissent en aval de leurs semantic views. Le statut reste exploratoire : l'équipe étudie une surcharge de macro locale qui exécute CREATE OR REPLACE AGENT à chaque run dbt.

Quels résultats Okta a-t-il obtenus avec dbt comme source unique ?

Okta n'a publié aucun taux de précision. Le résultat est décrit en termes opérationnels. Selon Crahen, corriger une mauvaise réponse ne demande plus de modifier une configuration d'agent opaque puis de redéployer sur plusieurs cycles. Un analytics engineer fusionne une modification de la couche de contexte dans dbt, et tous les agents qui la lisent en bénéficient immédiatement. Elle affirme que la centième question reçoit une réponse de même qualité que la première.

Il faut lire cette affirmation avec un œil critique. La prochaine étape annoncée par l'équipe porte sur des tests de régression automatisés qui rejouent des requêtes vérifiées contre les agents à chaque changement de contexte, et l'extension du contexte au-delà d'un seul domaine. Autrement dit, la constance des réponses n'est pas encore mesurée de façon systématique, et le périmètre couvre un domaine. Le gain démontré concerne la gouvernance : traçabilité, revue, source unique. Le gain de précision n'est pas démontré.

D'autres cas présentés au même événement donnent des ordres de grandeur. Ils viennent eux aussi du blog de dbt Labs et sont donc à croiser avec des sources indépendantes :

• Data Culture, cabinet de conseil en analytics engineering, est parti de 13 questions de référence, chacune assortie d'une réponse vérifiée. Face aux tables sources brutes, sans documentation, l'agent obtenait 0 % de génération SQL et 0 % de précision. dbt Labs rapporte un résultat final de 94,7 %. Opeyemi Fabiyi, directeur d'analytics engineering de Data Culture, avait d'abord évoqué un passage de 0 % à 92 % par enrichissement du contexte. Il a ensuite montré qu'une partie des « échecs » venait de l'évaluation elle-même : l'équipe a corrigé sa méthode de mesure, sans toucher à l'agent, et la précision est passée dans les 90 %.
• Careem, la super-app des Émirats arabes unis, fait fonctionner plus de 5 000 modèles avec une équipe de data engineering réduite. Chaque modèle généré par IA franchit quatre étapes avant qu'un humain le voie : compilation SQL, tests dbt, orchestration via un DAG Airflow généré automatiquement et intégrité du lignage dans OpenMetadata. Les quatre doivent passer. Les garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → sont structurels (compte de service en lecture seule sur la production, isolation des schémas de développement imposée par macro), et 45 % des nouveaux modèles en production portent l'étiquette « ai-generated ».
• Côté éditeur d'entrepôt, Snowflake revendique environ 85 à 90 % de précision avec semantic views contre environ 40 % sans, d'après une comparaison publiée par Paradime, elle-même éditrice d'outils dbt.

Le point commun de ces trois cas : le contexte et la validation font monter la fiabilité, et aucun ne repose sur un changement de modèle.

Ce que les CDO peuvent transposer du modèle Okta

La grille « toujours, à chercher, jamais sans garde-fou »

La troisième faille d'Okta, le bloc d'instructions indifférencié, donne une règle de tri applicable partout. Pour chaque élément de contexte, posez trois questions dans cet ordre :

• L'agent doit-il le savoir à chaque question ? Si oui, il va dans un document de contexte court et versionné (calendrier fiscal, périmètre des entités, conventions de devise).
• L'agent doit-il le chercher selon la question ? Si oui, il appartient à lacouche sémantique : métriques, dimensions, jointures autorisées.
• L'agent doit-il s'interdire un usage ou appliquer un filtre sans exception ? Si oui, la règle va dans le bloc agent du modèle concerné, et un contrôle équivalent doit exister dans les droits d'accès.

Au tableau blanc, cela tient en une ligne :pas de pull request, pas de contexte en production.

La troisième catégorie relève directement de la sécurité, et c'est là que le modèle Okta demande une précaution. Un filtre déclaré dans un YAML est une consigne donnée à un système probabiliste. Ce n'est pas un contrôle d'accès. Careem l'a compris en imposant un compte de service en lecture seule : le garde-fou est dans l'infrastructure. Okta, de son côté, vend des mécanismes d'autorisation qui évaluent et appliquent les permissions au niveau de chaque appel d'outil, en temps réel. La métadonnée oriente l'agent, et ce sont les permissions qui protègent la donnée.

Mini-exemple chiffré

Exemple hypothétique, purement arithmétique. Une entreprise fait tourner quatre agents (finance, ventes, produit, support), chacun avec sa propre copie de la définition du revenu récurrent. Quand la définition change, il faut quatre modifications, quatre cycles de redéploiement et quatre occasions de divergence. Avec une source unique publiée dans un schéma partagé, il faut une pull request, relue une fois et lue par les quatre agents. Si chaque domaine dispose d'un jeu de 13 questions de référence comme celui de Data Culture, la suite de régression compte 4 × 13 = 52 requêtes vérifiées, rejouées à chaque modification de contexte. Ce jeu de référence donne aussi l'échelle d'un résultat : sur 13 questions, 12 bonnes réponses font 92,3 %, et une seule erreur coûte près de 8 points.

Où votre contexte diffère de celui d'Okta

Okta partait d'un socle mûr : un entrepôt unique, une logique métier déjà modélisée dans dbt, des engineers rattachés aux domaines qui peuvent relire les changements de contexte. Beaucoup d'organisations n'en sont pas là. Seules 7 % des entreprises jugent leurs données complètement prêtes pour l'IA, selon le Data Readiness Index 2026 de Cloudera et Harvard Business Review Analytic Services (chiffre relayé par dbt Labs). Si vos définitions vivent dans l'outil de BIBITechnologies et processus qui transforment des données brutes en insights actionnables via du reporting, des dashboards et de l'analyse, pour que les équipes décident sur des faits plutôt qu'à l'intuition.Voir la définition complète → ou dans des tableurs, le premier chantier est de les modéliser, avant même de penser aux agents.

Deux autres écarts comptent. Sans propriétaire par domaine, la revue de pull request devient une formalité et la gouvernance n'existe que sur le papier. Le modèle Okta couvre aussi le contexte structuré et ne dit rien des documents, tickets ou fils Slack. Fivetran et dbt Labs proposent pour ce périmètre un Context Layer en bêta privée qui ajoute à la structure de dbt des connaissances non structurées comme la documentation et les fils Slack. C'est un produit commercial, à évaluer comme tel.

Ce qu'il faut faire lundi

• Recenser tous les endroits où vivent aujourd'hui des instructions d'agent (interface d'entrepôt, prompts système, configurations d'outils) et marquer chacun comme versionné ou non.
• Choisir l'agent le plus utilisé, rédiger les dix questions qu'on lui pose le plus et faire valider la réponse attendue par le propriétaire métier.
• Ajouter à un modèle dbt très consulté un bloc d'usage : à utiliser pour, à éviter pour, filtres obligatoires. Le faire relire en pull request.
• Écrire une page de contexte d'entreprise (calendrier fiscal, entités, devises) et la placer dans le même dépôt que les modèles.
• Pour chaque filtre obligatoire déclaré, vérifier qu'une restriction équivalente existe dans les droits de l'entrepôt ou du compte de service de l'agent.
• Interdire, par une règle d'équipe écrite, toute modification de contexte d'agent faite en dehors d'une pull request.

Chez Okta, corriger une mauvaise réponse d'agent revient désormais à fusionner une modification relue, avec un auteur et une date. Si la même correction passe chez vous par un clic dans une interface sans historique, commencez par là, avant de comparer des modèles.