Databricks Unity Gateway CLI place le choix des agents de code derrière un plan de contrôle unique

Databricks a lancé Unity Gateway CLI après que quatre grandes familles de modèles ont évolué en six mois, faisant de la sélection d’agents de code une cible mouvante pour les entreprises. Databricks Unity Gateway CLI offre aux administrateurs un itinéraire unique et gouverné pour les modèles, outils, compétences, usages et dépenses. Les développeurs peuvent toujours ouvrir leur agent préféré avec des commandes telles que ug claude ou ug codex.

Cette combinaison crée la véritable tension. Databricks ne demande pas aux organisations d’ingénierie de se standardiser sur un seul agent de code. L’entreprise souhaite qu’elles se standardisent sur la passerelle située sous chaque agent, puis modifient les modèles et les politiques sans reconstruire l’environnement de chaque développeur.

La principale alternative consiste en une administration directe, propre à chaque fournisseur. OpenAI, Anthropic, Google et d’autres fournisseurs peuvent gouverner leurs propres produits, souvent avec des contrôles conçus autour de leurs environnements natifs. Databricks parie que les entreprises accorderont davantage de valeur à un plan de contrôle partagé qu’à l’intégration plus étroite de piles distinctes par fournisseur.

Databricks Unity Gateway CLI centralise la configuration des agents

La version transforme la configuration des agents de code, qui relevait de chaque développeur, en infrastructure publiée de manière centralisée.

Les administrateurs configurent dans Unity Gateway les agents approuvés, les modèles par défaut, les serveurs Model Context Protocol, les compétences réutilisables, le comportement de routage et les politiques de dépenses. MCP est une norme qui permet à un agent d’IA d’appeler des outils externes et de récupérer des données contextuelles via une interface cohérente.

Après la publication d’une configuration par un administrateur, la CLI la récupère et l’applique lorsqu’un développeur démarre un agent. Databricks indique qu’une organisation peut également verrouiller certains paramètres et distribuer la CLI via son système de gestion des appareils.

L’interface initiale reste volontairement réduite. Un développeur peut saisir ug claude, ug codex, ug gemini, ug opencode, ug copilot ou ug pi. La CLI authentifie alors l’utilisateur, connecte le programme choisi à Unity Gateway, applique la configuration de l’organisation et ouvre l’interface de terminal familière de l’agent.

Cursor occupe une position plus restreinte. Le dépôt CLI open source indique que Unity Gateway configure les serveurs MCP pour Cursor Agent, mais que les modèles de Cursor continuent de fonctionner via le compte Cursor du développeur. Cette distinction est importante, car la prise en charge d’une interface d’agent ne garantit pas un routage identique des modèles pour tous les clients.

La synchronisation de configuration constitue le changement le plus important. Si un administrateur modifie un modèle par défaut, ce nouveau choix apparaît lorsque les développeurs lancent ensuite l’agent concerné via ug. L’entreprise décrit aussi des déploiements par cohortes, qui permettent aux équipes de plateforme de tester un nouveau modèle auprès d’un groupe limité avant un déploiement plus large.

Cette conception sépare le harnais d’agent du modèle qui le sous-tend. Un harnais d’agent est le logiciel qui planifie le travail, invoque des outils, modifie des fichiers et gère une session de code. Le modèle de langage fournit le raisonnement et la génération, mais le harnais environnant façonne la manière dont ces capacités atteignent un dépôt.

Une équipe peut ainsi conserver Claude Code comme interface tout en modifiant la configuration de modèle autorisée par sa passerelle. Un autre groupe peut continuer à utiliser Codex tout en recevant les mêmes outils MCP approuvés et les mêmes règles de dépenses.

L’approche répond à une charge opérationnelle réelle. Chaque agent possède généralement ses propres fichiers de configuration, conventions d’authentification, format d’enregistrement des outils et variables d’environnement. Prendre en charge plusieurs agents peut multiplier les scripts d’installation et exposer les développeurs à des politiques incohérentes.

Databricks gère désormais les fichiers des clients pris en charge et stocke un enregistrement local de la configuration appliquée. La documentation de son dépôt indique que l’outil sauvegarde les fichiers avant de les modifier et propose ug revert pour restaurer ces sauvegardes. Une commande ug doctor peut diagnostiquer les problèmes d’installation, tandis que ug status affiche les espaces de travail, modèles, compétences et fichiers générés configurés.

Le résultat n’est pas un nouvel agent de code. Il s’agit d’une couche de déploiement qui fait fonctionner plusieurs agents comme des clients d’un même service d’entreprise. Ce changement prépare le débat central de la version : une passerelle partagée face à des plans de contrôle distincts selon les fournisseurs.

La croissance des agents de code met les équipes de plateforme sous pression

La pression immédiate pèse sur les équipes de plateforme, de sécurité et de finance, qui doivent gouverner des outils adoptés par les développeurs plus vite que les politiques d’entreprise ne peuvent suivre.

Databricks a présenté la CLI le 24 septembre 2026. Son annonce de lancement cite GPT-6, Claude Opus 5.5, Gemini 3.8 et Grok 4.7 comme sorties au cours des six mois précédents. Elle mentionne également des modèles à poids ouverts, notamment Kimi K3, GLM-5 et DeepSeek V4.1.

L’entreprise estime qu’un nouveau modèle de pointe apparaît désormais environ tous les cinq jours. Cette estimation reflète la caractérisation de Databricks, et non une mesure sectorielle standardisée. Néanmoins, ce rythme de publication explique pourquoi une configuration d’entreprise fixe peut rapidement vieillir.

La qualité du modèle n’est qu’une variable. Un modèle plus petit peut effectuer des modifications courantes à moindre coût, tandis qu’un modèle plus capable peut mieux réussir une migration à l’échelle d’un dépôt. La disponibilité, la latence, la gestion du contexte, l’utilisation des outils et les exigences régionales peuvent également modifier le choix approprié.

Sans couche partagée, les entreprises font face à deux options inconfortables. Elles peuvent se standardiser sur un fournisseur et accepter qu’un autre modèle puisse devenir meilleur pour une tâche donnée. Ou elles peuvent prendre en charge plusieurs agents et fournisseurs, puis reproduire les politiques d’identité, de budget, de journalisation et d’outils dans chacun d’eux.

La seconde voie préserve le choix, mais accroît la surface d’administration. Un développeur peut utiliser un identifiant pour un agent, un autre jeton pour un service MCP et une clé distincte pour un fournisseur de modèles. Les enregistrements d’usage peuvent finir dans différentes consoles, avec des méthodes d’attribution qui ne concordent pas.

Unity Gateway cherche à regrouper ces chemins. Selon la documentation de gouvernance de l’entreprise, les requêtes de modèles et de MCP peuvent traverser une couche commune qui applique autorisations, limites de débit, politiques de service et enregistrement d’usage. Unity Catalog fournit le modèle d’accès sous-jacent.

Cette architecture permet aux administrateurs d’accorder l’accès aux modèles à des utilisateurs ou groupes nommés, plutôt que de distribuer des secrets de fournisseurs. L’agent s’authentifie avec des identifiants Databricks et la passerelle fournit les identifiants de fournisseur stockés lorsqu’elle transfère une requête approuvée.

Databricks documente des limites de requêtes par minute et de jetons par minute au niveau du service de modèle. Ces limites peuvent s’appliquer globalement ou par utilisateur. Une table système d’usage enregistre le demandeur, le service, le statut de réponse et d’autres données opérationnelles pour le trafic qui atteint la passerelle.

Cela est particulièrement pertinent lorsque les agents de code peuvent appeler des outils. Une réponse de modèle consomme des jetons, mais une session d’agent peut également rechercher dans des dépôts, interroger des bases de données, invoquer des fonctions internes ou contacter des services externes. L’accès aux outils crée un problème de politique plus large que le seul accès aux modèles.

L’enregistrement centralisé de MCP donne aux équipes de plateforme un ensemble d’outils sélectionnés. Au lieu de demander à chaque développeur de coller des définitions de serveur dans plusieurs fichiers de configuration locaux, les administrateurs peuvent publier des services approuvés et les rendre disponibles dans les agents compatibles.

Les équipes ont toujours besoin d’une documentation interne précise concernant les dépôts, API et procédures opérationnelles. Une base de connaissances d’ingénierie consultable peut fournir ce contexte, tandis que la passerelle gouverne la manière dont un agent accède aux outils approuvés.

La pression est à la fois à court terme et structurelle. Les équipes de plateforme ont besoin d’un moyen immédiat d’intégrer le dernier agent sans dupliquer les contrôles. À plus long terme, elles doivent aussi empêcher leur modèle de gouvernance de devenir dépendant du cycle de publication d’un seul fournisseur de modèles.

C’est pourquoi le produit cible les organisations où les préférences des développeurs sont hétérogènes. Si chaque ingénieur utilise le même fournisseur et le même modèle, une couche administrative supplémentaire peut offrir un bénéfice limité. L’argument devient plus solide lorsque différentes équipes insistent sur différents harnais, mais que la sécurité exige toujours un itinéraire unique et responsable.

Une passerelle unique concurrence désormais les plans de contrôle distincts des fournisseurs

Databricks parie que la portabilité centralisée compte davantage que la gestion de chaque agent de code dans l’environnement d’entreprise natif de son fournisseur.

Les plans de contrôle natifs des fournisseurs disposent d’un avantage évident. Leurs administrateurs peuvent gouverner des fonctionnalités propres au produit, notamment les environnements d’exécution, les connexions aux dépôts, les modes d’approbation, les paramètres de rétention et la télémétrie spécialisée.

OpenAI, par exemple, décrit les contrôles d’espace de travail, le sandboxing, les exigences de politique et la télémétrie sensible aux agents dans sa présentation de l’exécution sécurisée de Codex. Ces contrôles concernent le comportement de l’agent complet, et pas seulement la manière dont son trafic de modèles et d’outils atteint une passerelle.

Anthropic et d’autres fournisseurs d’agents suivent le même schéma général. Chacun peut optimiser la gestion autour de son propre harnais, de sa famille de modèles, de son système d’autorisations et de son rythme de mise à jour. Cette intégration verticale peut simplifier le support lorsqu’une entreprise s’engage sur un produit unique.

Unity Gateway propose un modèle horizontal. La passerelle devient la limite de politique stable, tandis que les interfaces d’agents et les modèles par défaut peuvent évoluer. Elle n’a pas besoin de remplacer chaque protection native pour créer de la valeur. Il lui faut qu’une part suffisante du trafic traverse ses contrôles pour que l’identité, les coûts et la politique d’outils centralisés deviennent significatifs.

La distinction est plus facile à voir lorsqu’une entreprise souhaite changer de modèle. Dans un déploiement spécifique à un fournisseur, les équipes peuvent devoir mettre à jour la configuration locale, provisionner de nouveaux identifiants, modifier les listes d’autorisation et recréer les rapports d’usage. Le travail précis dépend de l’agent et du fournisseur.

Avec Databricks Unity Gateway CLI, un administrateur peut modifier un modèle par défaut publié. Le prochain lancement applique ce choix sans exiger que chaque développeur modifie les paramètres de l’agent. Les contrôles par cohortes peuvent limiter le changement aux utilisateurs sélectionnés durant l’évaluation.

La prise en charge de fournisseurs externes élargit cette proposition. La documentation Azure Databricks de Microsoft indique que Claude Code et Codex peuvent passer par des services de fournisseurs enregistrés dans Unity Catalog. Ces services peuvent représenter OpenAI, Anthropic, Amazon Bedrock ou un autre fournisseur pris en charge.

L’agent envoie sa requête vers un point de terminaison Unity Gateway, tandis qu’un en-tête de requête identifie le service de fournisseur visé. La passerelle fournit le secret stocké, vérifie l’accès et enregistre l’usage. Les développeurs n’ont pas besoin de la clé du fournisseur en amont sur leurs machines.

Cette portabilité a des limites. Le modèle sous-jacent doit rester compatible avec l’agent sélectionné, et chaque harnais peut attendre un comportement de requête spécifique au fournisseur. Une passerelle ne peut pas automatiquement permettre à chaque modèle de prendre en charge chaque fonctionnalité propriétaire d’agent.

La matrice des agents pris en charge varie également selon les capacités. Certains clients acceptent des modèles, serveurs MCP et compétences configurés de manière centralisée. Cursor reçoit actuellement une configuration MCP sans que son trafic de modèles soit transféré vers Databricks. Le routage vers des fournisseurs externes est également plus développé pour certains agents que pour d’autres.

Ces différences empêchent Unity Gateway de devenir une interface parfaitement interchangeable pour tous les outils de programmation. La plateforme doit suivre l’évolution des formats de configuration et des comportements d’authentification de plusieurs clients développés indépendamment.

Le projet open source rend cette maintenance visible. Ses adaptateurs écrivent des fichiers spécifiques à chaque agent pour Codex, Claude Code, Gemini CLI, OpenCode, GitHub Copilot CLI, Pi et Cursor. Chaque modification de configuration en amont peut se traduire par un travail de compatibilité pour Databricks.

Pourtant, l’ouverture offre aussi aux acheteurs un moyen d’examiner l’intégration. Les équipes peuvent consulter le dépôt, tester les changements dans des environnements contrôlés et voir quels fichiers le CLI gère. Cette transparence est utile lorsqu’un outil modifie des paramètres sur les machines des développeurs.

L’approche horizontale échange donc de la profondeur contre de la cohérence. Les systèmes natifs des fournisseurs peuvent contrôler davantage de comportements propres à leurs produits. Unity Gateway peut proposer une identité commune, l’accès aux modèles, l’enregistrement MCP, la budgétisation et le reporting sur un éventail plus large d’interfaces.

Le gagnant ne sera pas déterminé par une simple liste de fonctionnalités. Les entreprises évalueront si les contrôles partagés couvrent les risques qu’elles doivent réellement gérer, et si la passerelle ajoute moins de charge opérationnelle qu’elle n’en supprime.

Le routage intelligent relie le choix des modèles aux dépenses

L’argument économique du produit repose sur l’acheminement des tâches courantes vers des modèles moins coûteux, sans obliger les développeurs à gérer le choix du modèle à chaque session.

Les demandes de programmation varient considérablement. Renommer une variable ne requiert pas la même capacité de raisonnement que diagnostiquer une défaillance distribuée entre plusieurs services. Si chaque tâche utilise le modèle approuvé le plus performant, une entreprise peut payer un supplément même lorsque le travail est simple.

Le Smart Routing de Unity Gateway choisit un modèle pour la session principale et peut en sélectionner un autre pour le travail délégué à un sous-agent. Databricks indique que son benchmark interne de programmation a montré des économies de coûts de 35 % grâce à cette approche.

Ce chiffre doit être considéré comme une évaluation interne, et non comme un résultat universel. Les économies réalisables par une autre organisation dépendront de son mix de tâches, des modèles éligibles, de la précision du routage, des conditions des fournisseurs et de sa tolérance aux nouvelles tentatives.

Une première tentative moins coûteuse peut devenir onéreuse si elle échoue à répétition ou produit du code nécessitant davantage de revue. À l’inverse, acheminer chaque demande vers un modèle très performant peut gaspiller le budget sur des modifications prévisibles. Un routeur utile doit distinguer ces cas de manière fiable.

Databricks prend aussi en charge des paramètres par défaut tenant compte du budget. Lorsque l’utilisation atteint un seuil défini, les administrateurs peuvent recommander un agent ou un modèle moins coûteux pour les nouveaux lancements. Les sessions actives continuent sans changer de modèle au milieu du travail.

Les contrôles de dépenses de l’entreprise distinguent les budgets partagés, les limites par utilisateur et les dérogations pour certains utilisateurs ou groupes. Les administrateurs peuvent déclencher des alertes, bloquer les demandes ultérieures adressées à la passerelle, ou appliquer les deux mesures.

L’application des budgets repose sur des estimations quasi temps réel. Les demandes déjà en cours peuvent se terminer, de sorte que la consommation finale peut dépasser un seuil. Les dépenses estimées auprès de fournisseurs externes peuvent aussi différer de la facture finale du fournisseur.

Les paramètres par défaut ne sont pas des restrictions strictes. Databricks précise que les paramètres intelligents par défaut affectent les nouveaux lancements, mais n’empêchent pas un développeur autorisé de sélectionner un autre modèle disponible. Les autorisations Unity Catalog ou le blocage par budget assurent une application plus stricte.

Smart Routing présente d’autres limites. Il fonctionne actuellement avec Claude Code et Codex, et sa liste documentée de candidats est limitée aux services de modèles sous system.ai. Databricks indique qu’il ne peut pas être combiné avec un modèle personnalisé, un fournisseur externe, un emplacement Unity Catalog ou un autre service de modèles en dehors de cet espace de noms.

Ces restrictions réduisent l’argument de portabilité. Une organisation peut centraliser des modèles externes via la passerelle, mais ne peut pas nécessairement les inclure dans la même boucle d’optimisation automatisée. Les acheteurs recherchant un routage neutre vis-à-vis des fournisseurs devraient tester attentivement cette limite.

Le traçage fournit le mécanisme de retour d’information. Databricks indique que Unity Gateway peut collecter l’activité des modèles, les appels d’outils locaux et les invocations de compétences dans une table de traces unifiée. Les administrateurs peuvent alors examiner les échecs répétés d’outils, les sorties surdimensionnées et d’autres schémas qui consomment des jetons sans faire avancer la tâche.

L’entreprise indique avoir utilisé ce processus avec Genie One pour identifier sept bugs d’outils MCP. Databricks estime que leur correction a évité 1,2 million de dollars par an de dépenses inutiles en IA et de perte de productivité.

Là encore, ce chiffre est une estimation de l’entreprise basée sur son propre environnement. Il combine les dépenses directes liées aux modèles avec une estimation de la perte de productivité ; les lecteurs ne devraient donc pas le considérer comme une référence de retour sur investissement transférable.

Un exemple client offre un signal d’une autre échelle. John Xing, CTO de Concurrence, indique que l’entreprise a acheminé plus de 61 milliards de jetons d’entrée d’agents de programmation sur environ 360 000 demandes après avoir adopté Unity Gateway. Il décrit une visibilité centralisée sur l’utilisation et les dépenses, avec une attribution au niveau de l’identité.

Ce témoignage établit que le système a traité un volume substantiel de trafic de production pour au moins un client nommé. Il ne divulgue ni la latence, ni les taux d’erreur, ni l’acceptation du code, ni les résultats de sécurité, ni la manière dont l’organisation a mesuré la satisfaction des développeurs.

L’argument économique reste donc un mécanisme plutôt qu’un résultat garanti. Le routage central crée une possibilité d’aligner les coûts sur la complexité des tâches. Le traçage peut révéler le gaspillage. Les budgets peuvent contenir la consommation. Les économies réelles dépendent toujours de l’adéquation des politiques au travail d’ingénierie réel.

La gouvernance centrale présente encore des lacunes de couverture

Une passerelle ne gouverne que le trafic, les clients et les outils qui la traversent effectivement.

Les développeurs peuvent contourner le plan de contrôle en lançant directement un agent natif, sauf si l’organisation impose le chemin géré au moyen de politiques d’appareil, d’identifiants, de contrôles réseau ou de normes internes. Databricks note explicitement que les sessions natives de Claude Code et Codex en dehors du CLI Unity Gateway ne bénéficient pas de son Smart Routing.

La couverture du trafic est donc la première question à se poser lors d’une évaluation. Un administrateur doit déterminer si chaque demande de modèle, invocation MCP et tâche déléguée atteint la passerelle. Un routage partiel peut produire un enregistrement d’audit incomplet tout en donnant l’apparence d’un contrôle centralisé.

La deuxième question concerne l’exécution locale. Une passerelle peut autoriser un modèle et enregistrer le trafic des outils, mais un agent de programmation peut également lire des fichiers, exécuter des commandes shell, installer des paquets ou modifier un dépôt sur la machine du développeur. Ces actions dépendent du sandboxing du harnais, de son système d’approbation et de la politique locale.

C’est ici que les contrôles d’entreprise natifs restent pertinents. La gouvernance des modèles ne remplace ni la sécurité des terminaux, ni les autorisations de dépôt, ni les protections de branches, ni la revue de code, ni la gestion des secrets, ni les limites d’exécution propres à l’agent.

MCP étend encore la frontière de confiance. Un serveur approuvé peut néanmoins exposer de larges capacités, renvoyer du contenu non fiable ou déclencher des effets de bord. Les administrateurs doivent examiner les outils individuellement, restreindre les identifiants et décider quelles actions exigent une confirmation.

L’attribution au niveau de l’identité facilite une enquête, mais l’attribution seule ne rend pas un outil sûr. Une trace peut montrer après coup qui a initié une opération. Des contrôles préventifs doivent toujours limiter ce que cette identité et l’agent sont autorisés à faire.

La propriété de la configuration introduit également des tensions. Les développeurs maintiennent souvent des paramètres d’agent soigneusement ajustés, des serveurs MCP locaux et des instructions propres à leurs flux de travail. Une configuration centrale peut écraser ces choix ou entrer en conflit avec eux.

Databricks atténue ce risque avec des sauvegardes, des fichiers gérés, des paramètres verrouillés, des aperçus en mode simulation et une commande de restauration. Les entreprises devraient néanmoins tester les mises à niveau sur des environnements de développeurs représentatifs avant un déploiement généralisé.

La compatibilité constitue une autre préoccupation permanente. Les fournisseurs d’agents de programmation peuvent modifier les schémas de configuration, les flux d’authentification, les exigences de modèles ou le comportement du CLI. Unity Gateway doit s’adapter suffisamment vite pour qu’une mise à jour centrale n’interrompe pas tous les clients pris en charge simultanément.

Le dépôt public contient déjà des signalements concernant la prise en charge des plateformes et les combinaisons de fournisseurs. Des problèmes individuels ne prouvent pas que le produit est globalement peu fiable, mais ils illustrent la charge d’intégration créée par une passerelle multi-agents.

La centralisation peut également accroître le rayon d’impact. Un paramètre par défaut erroné, un enregistrement MCP invalide, un chemin d’authentification expiré ou une politique trop restrictive peut affecter de nombreux développeurs simultanément. Les procédures de déploiement par cohorte et de retour en arrière sont essentielles, et non de simples commodités optionnelles.

Les organisations devraient distinguer trois affirmations lors de l’évaluation. Unity Gateway peut centraliser une configuration sélectionnée. Il peut gouverner le trafic acheminé via ses services. Il peut collecter des preuves provenant de clients pris en charge. Aucune de ces affirmations ne signifie qu’il contrôle chaque action effectuée par chaque agent.

Un pilote crédible devrait tester les voies de contournement, le comportement des outils locaux, la récupération après défaillance, les conflits de configuration et l’exhaustivité de l’audit. Il devrait également comparer les enregistrements de la passerelle aux factures des fournisseurs et à la télémétrie côté client.

Le modèle de déploiement le plus solide utilisera des contrôles à plusieurs niveaux. Unity Gateway peut servir de frontière pour le trafic des modèles et des outils. Les contrôles natifs des agents peuvent restreindre l’exécution. Les systèmes existants de livraison logicielle peuvent continuer à appliquer les politiques de revue, de test et de publication.

Trois signaux montreront si la stratégie de passerelle fonctionne

Le prochain test consiste à déterminer si Databricks peut transformer une large compatibilité en adoption mesurable sans affaiblir la couverture des politiques.

Le premier signal est la parité de prise en charge entre agents et fournisseurs. Les acheteurs devraient surveiller si le routage des modèles, Smart Routing, l’enregistrement MCP, les compétences, le traçage et l’accès aux fournisseurs externes deviennent disponibles de façon cohérente dans l’ensemble des clients pris en charge.

Une plus grande parité renforcerait l’argument du plan de contrôle partagé. Des exceptions persistantes pousseraient les entreprises vers une administration propre à chaque agent ou une architecture mixte. La configuration MCP uniquement de Cursor et les restrictions actuelles de Smart Routing offrent des références de comparaison claires.

Le deuxième signal est constitué d’éléments indépendants sur les coûts et la qualité. Databricks a publié un résultat d’économies de 35 % ainsi qu’une estimation interne substantielle de réduction du gaspillage. Les clients doivent désormais indiquer si le routage réduit le coût total des tâches une fois prises en compte les nouvelles tentatives, la revue humaine, la latence et les appels d’outils échoués.

La preuve d’un coût inférieur par tâche achevée validerait le mécanisme de routage. Des économies fondées uniquement sur les prix des jetons seraient moins convaincantes, car des demandes peu coûteuses peuvent tout de même générer des retouches d’ingénierie coûteuses.

Le troisième signal est la couverture de la gouvernance en production. Les entreprises devraient mesurer quelle part des appels de modèles d’agents et des invocations d’outils apparaît dans les enregistrements de la passerelle, puis tester si les politiques bloquent systématiquement les accès interdits.

Une couverture élevée avec peu de contournements appuierait la thèse centrale de Databricks. Des écarts persistants entre les sessions gérées et natives l’affaibliraient, en particulier dans les organisations où les développeurs peuvent installer ou lancer des clients en dehors du chemin approuvé.

Le CLI Databricks Unity Gateway arrive à un moment opportun. Le choix des modèles s’élargit, les agents de programmation accèdent plus profondément aux systèmes, et les consoles distinctes des fournisseurs ne produisent pas naturellement une couche unique de politique à l’échelle de l’entreprise.

Databricks a proposé une réponse claire : préserver l’interface que les développeurs préfèrent, mais faire de la passerelle le point de contrôle durable. Cette réponse est plus flexible que d’imposer un seul agent à chaque ingénieur, tout en étant plus exigeante que l’installation d’un autre utilitaire en ligne de commande.

Les responsables de plateforme devraient désormais mener un pilote encadré avec deux agents, plusieurs catégories de tâches et des tests explicites de contournement. Comparez le coût par tâche achevée, la couverture de traçabilité, les frictions pour les développeurs et le temps de reprise avant d’étendre le déploiement.

La question décisive n’est pas de savoir si ug codex ou ug claude se lance correctement. Il s’agit de déterminer si une seule passerelle peut gouverner les deux avec une exhaustivité suffisante pour que la sécurité fasse confiance aux traces, que la finance fasse confiance aux données de dépenses et que les développeurs continuent d’emprunter le parcours approuvé.