Le même assistant commercial peut répondre à un responsable régional et à un dirigeant national sans leur montrer les mêmes données. La difficulté est de maintenir cette différence quand la requête quitte l’interface et devient du SQL, un appel de modèle ou une action d’outil d’agent.
Databricks a généralisé l’autorisation utilisateur d’Apps le 7 octobre 2026, après plus de 18 mois de préversion publique. L’autorisation au nom de l’utilisateur, ou OBO, exécute les requêtes compatibles avec l’identité de la personne connectée, au lieu de tout faire passer par le principal de service de l’application. Les contrôles Unity Catalog existants peuvent suivre cette personne. Cela réduit les politiques dupliquées, sans rendre automatiquement l’application sûre par délégation.
Une seconde voie d’identité passe en production
Databricks Apps exécute applications de données, tableaux de bord, outils opérationnels et agents personnalisés sur une infrastructure serverless. Chaque application déployée reçoit son propre principal de service : une identité non humaine avec les droits accordés à cette instance. L’autorisation applicative reste utile pour configuration commune, télémétrie, maintenance et automatisation.
L’autorisation utilisateur ajoute une voie sans remplacer l’autre. Pour une action compatible d’une personne authentifiée, Databricks transmet un jeton au runtime. L’application appelle ensuite une API approuvée avec les droits de cette personne. Le modèle OAuth 2.0 distingue délégation utilisateur-machine et travail machine-machine.
Pour les données gouvernées, Unity Catalog évalue droits existants, filtres de lignes et masques de colonnes. Les autorisations de l’entrepôt déterminent séparément si la requête peut s’exécuter. Un responsable régional voit un territoire, un dirigeant national davantage, par le même parcours applicatif. Les requêtes suivantes suivent les politiques actualisées du catalogue, non une copie séparée dans l’application.
Cela évite un écart fréquent. Une identité partagée présente un jeu de droits au backend ; les développeurs reconstituent ensuite les résultats de chaque salarié avec rôles, correspondances, middleware ou autre service de politiques. Ces contrôles peuvent fonctionner, mais modifier le catalogue sans la correspondance locale peut exposer des informations ou refuser un accès légitime.
La préversion Apps OBO a commencé le 26 mars 2025, couvrant notamment les tables Unity Catalog et les points de terminaison de modèles. La disponibilité générale signifie une préparation à la production dans les limites documentées, non une prise en charge universelle de chaque cloud, région, espace, profil de conformité ou API en aval. La source cite une extension annoncée fin septembre 2026 aux espaces avec profil de sécurité de conformité ; les clients doivent toujours vérifier leur environnement.
Une application peut lire des instructions communes et enregistrer des métriques avec sa propre identité, puis interroger clients et ventes comme utilisateur actuel. L’authentification établit qui est présent ; l’autorisation définit ses possibilités en aval. Les confondre ferait manquer l’apport principal de la version.
Droits de l’utilisateur et portées de l’application se croisent
Une demande applicative n’accorde pas automatiquement une table ou un entrepôt. La personne doit déjà posséder les droits nécessaires. Les développeurs déclarent aussi des portées d’API limitant les catégories d’opérations réalisées en son nom.
Ce sont deux frontières. Une portée ne crée pas un droit de données ; elle contraint son exercice. Databricks documente sql:restricted-query pour l’analyse SQL en lecture seule : requêtes restreintes comme utilisateur actuel, sans administration générale des entrepôts ou tâches administratives étrangères.
C’est particulièrement important pour les personnes privilégiées. Un dirigeant ou administrateur peut légitimement consulter de nombreuses données sensibles, mais une application restreinte ne devrait pas hériter de toutes ses capacités directes. Les portées limitent les opérations même lorsque les droits personnels sont étendus.
Les administrateurs d’espace fixent un plafond supplémentaire aux portées ajoutées par les développeurs. La liste peut autoriser toutes les API compatibles, certaines portées ou aucune autorisation utilisateur. Selon l’annonce, le réglage initial peut inclure toutes les API. Il s’agit d’un choix de gouvernance, pas de la preuve d’une base restrictive.
Des exceptions importantes existent. Les administrateurs de compte peuvent ajouter des portées exclues par la liste de l’espace. Retirer une portée auparavant admise n’arrête pas immédiatement les applications existantes : elles peuvent continuer à fonctionner. Elles ne peuvent toutefois ensuite démarrer, être déployées ou mises à jour avant le retrait de la portée interdite.
Modifier la liste ne revient donc pas à révoquer instantanément tous les usages en cours. Inventaires des applications, responsables des portées et dépendances métier permettent de comprendre la transition et d’éviter une surprise au prochain déploiement. Une base contrainte avec exceptions documentées vaut mieux que supposer la configuration suffisante pour toute l’application des règles.
Le jeton appartient à la requête, pas à l’agent entier
Le code doit séparer clients utilisateur et applicatif. Les requêtes interactives gouvernées relèvent du parcours utilisateur ; configuration commune et travail sans session, d’un parcours applicatif justement limité. Des dépendances et gestionnaires distincts rendent les erreurs d’identifiants plus visibles qu’un client générique cachant son principal.
Si une route exige l’autorisation utilisateur sans jeton transmis, elle doit rejeter la requête. Un repli silencieux sur le principal de service peut donner une réponse techniquement valide avec des droits totalement différents, plus larges ou plus étroits. L’utilisateur peut ne voir aucun signe du changement.
Les jetons transmis ne doivent jamais être affichés, journalisés ou conservés. Pour les agents personnalisés dans Apps, Databricks demande d’initialiser le client d’espace utilisateur dans le gestionnaire invoke ou stream actif. Le jeton n’existe que pendant la requête, pas au démarrage global de l’application.
Un processus d’agent sert plusieurs personnes. Une identité comme état global risque de perdre ou mélanger les contextes. Un flux peut lire des instructions communes comme application, interroger des finances gouvernées comme utilisateur, puis écrire une télémétrie générale comme application, sans conserver ses identifiants. Chaque transition exige principal et portée explicites.
Les tâches longues ou différées ajoutent une frontière. Qu’une personne lance un travail dépassant la requête n’autorise pas la sauvegarde du jeton transmis. Le travail applicatif nécessite un principal limité. Le travail exigeant le contexte utilisateur doit adopter un autre schéma délégué documenté et compatible plutôt que conserver l’identifiant.
OBO ne traverse pas automatiquement toutes les intégrations externes. Le service suivant doit le prendre en charge et peut nécessiter identifiants, consentement, portées et audit distincts. Les jetons ont une audience et une finalité précises ; Microsoft avertit aussi contre le relais de jetons intermédiaires vers des destinataires imprévus. C’est une délégation bornée, non une représentation illimitée de toute la chaîne.
Ouvrir l’application n’autorise pas ses données
Databricks Apps n’est pas un modèle d’application publique anonyme. Les utilisateurs s’authentifient, et les collaborateurs externes doivent être intégrés par une fédération compatible. La cible naturelle est une population de salariés et partenaires aux identités gérées, pas des visiteurs anonymes illimités.
CAN USE et CAN MANAGE déterminent qui exécute ou administre l’application. Ils ne donnent pas les tables, enregistrements ou entrepôts sous-jacents. Une personne peut ouvrir l’application et recevoir une réponse de données refusée ou limitée. À l’inverse, un droit sur une table ne permet pas forcément d’ouvrir l’application.
Ces contrôles doivent être examinés séparément des droits Unity Catalog. Une réponse SQL correctement déléguée peut être combinée à l’écran avec un fichier demandé par erreur comme application. La plateforme ne garantit pas que les développeurs affectent l’identité voulue à chaque chemin de code.
Les agents accentuent le risque par les questions ouvertes, choix d’outils et requêtes successives. Une injection de prompt dans les contenus récupérés peut encourager divulgation ou action inappropriée. OBO borne les données aux droits actuels, mais identité valide et lecture seule ne prouvent pas que chaque requête respecte l’intention de la personne.
Le consentement ne remplace pas non plus la revue administrative. On peut approuver des portées sans comprendre la combinaison des services et résultats. Traitement des entrées, contraintes d’outils, contrôle des sorties et surveillance restent nécessaires : requêtes inhabituelles, refus répétés, volumes inattendus et changements de comportement.
Les tests uniquement administrateur cachent des défauts car le compte rencontre peu de refus. Des utilisateurs régionaux, plus larges et sans droit sur la table révèlent des résultats différents ; données et rejets doivent être vérifiés. Databricks recommande de recommencer après un changement de gouvernance. Les journaux distinguent actions applicatives et personnelles sans enregistrer de jetons porteurs ou réponses sensibles.
Moins de copies de politiques, plus de dépendance
La délégation ne corrige pas les droits excessifs à la source. Groupes, privilèges de catalogue, accès aux entrepôts, filtres et masques demandent un entretien exact. Une base technique consultable peut conserver modèles de menace, décisions d’autorisation et preuves de revue près de l’implémentation, mais documenter n’est pas faire appliquer.
Databricks se distingue par l’intégration de la délégation à ses données gouvernées, SQL et runtime, pas par son invention. Microsoft documente déjà OBO entre API. L’accès conscient de l’identité de Google insiste sur applications hébergées et contexte ; AWS offre des composants pour systèmes personnalisés. Chaque approche répartit autrement la responsabilité d’intégration.
Si les données sont déjà gouvernées dans Unity Catalog, Databricks peut réduire la traduction des politiques entre sécurité et frameworks applicatifs. En contrepartie, la dépendance aux portées et comportements spécifiques augmente. Les ressources multicloud peuvent toujours exiger une autre couche d’autorisation.
Aucun benchmark indépendant ne prouve le temps de développement gagné ou la fréquence de défauts évités. Des modèles de production pour des utilisateurs réellement différents, des flux mixtes auditables, des portées fines et un consentement clair seraient plus probants que le label GA. Incidents de jetons, prolifération de portées et bogues de repli indiqueraient le contraire.
La version réduit une barrière de production tout en laissant visible le choix central : quelles opérations relèvent de l’application, lesquelles de la personne ? Sa valeur dépend du maintien de cette distinction lorsque SQL, agents, fichiers et services externes deviennent un produit, non du traitement d’un utilisateur connecté comme identifiant sans limites.
Sources et lectures connexes
Annonce GA Databricks; modèle d’autorisation Apps; préversion de mars 2025; guide OBO Microsoft; lecture sur les bases techniques consultables; niveaux de droits Apps; accès conscient de l’identité Google.