Provisionnement pour l'ère agentique : comment Databricks a créé un distributeur automatique d'infrastructures en libre-service

Chez Databricks, notre organisation d'ingénierie de terrain (field engineering) a pour mission d'aider nos clients à réussir. Cela implique de concevoir des démos, de reproduire des anomalies, de tester des fonctionnalités sur des charges de travail réelles et d'être prêt, à tout moment, à montrer à un prospect ce que la plateforme a dans le ventre. Cela n'a jamais été aussi crucial qu'à l'ère de l'IA, où une seule semaine peut redéfinir le champ des possibles. Avec la croissance de Databricks, permettre à nos équipes de terrain d'agir rapidement, de manière gouvernée et dans le respect des budgets est devenu un défi aussi essentiel que complexe.

Pour résoudre ce problème, nous avons entrepris de concevoir la « Field Engineering Vending Machine », ou FEVM en abrégé. Comme pour tout bon distributeur automatique, le concept est simple : vous demandez ce dont vous avez besoin, vous l'obtenez, et quand vous avez terminé, cela disparaît. Plus important encore, FEVM repose sur des composants natifs de Databricks et place les agents au cœur de son fonctionnement.

Les défis de la croissance à l'échelle

Il y a tout juste trois ans, l'ingénierie de terrain comptait moins de 1 500 personnes. Un petit nombre d'espaces de travail partagés couvrait la plupart des cas d'usage, et une maintenance manuelle permettait de faire fonctionner le tout convenablement. Mais Databricks a grandi rapidement. Le GTM compte désormais plus de 7 000 personnes, dont une part importante d'ingénieurs de terrain. Une infrastructure adaptée à une certaine taille nécessite une conception différente à une autre échelle.

Les espaces de travail Databricks sont optimisés pour un petit nombre d'administrateurs gérant de nombreux utilisateurs, ce qui est logique pour la plupart des déploiements en entreprise. L'ingénierie de terrain a toutefois des exigences différentes : presque tout le monde a besoin d'un accès de niveau administrateur pour faire son travail. Configurer des environnements de démo, tester des fonctionnalités en version préliminaire, exécuter des scénarios spécifiques aux clients — tout cela nécessite le type de contrôle qu'offre un accès administrateur.

À grande échelle, la coordination du travail au sein d'espaces de travail partagés crée une réelle complexité opérationnelle. Plusieurs ingénieurs travaillant dans le même environnement lors d'une démo cruciale peuvent interférer avec le travail des autres, et les limites de la plateforme — sur les catalogues, les instances Lakebase et les charges de travail simultanées, par exemple — deviennent une préoccupation majeure plutôt qu'un sujet secondaire. L'attribution des coûts devient plus difficile à suivre à mesure que l'utilisation augmente et que la responsabilité de l'environnement devient moins claire.

Le problème d'observabilité a également accentué ces défis. Lorsqu'un événement inattendu se produisait dans un espace de travail partagé, retracer ce qui s'était passé, quand et pourquoi nécessitait une investigation manuelle. Nous avions besoin d'un modèle qui rende chaque action de provisionnement transparente, auditable et attribuable dès le départ.

L'idée qui a donné naissance à FEVM était simple : et si chaque ingénieur pouvait disposer de son propre environnement isolé, provisionné en quelques minutes, gouverné de manière centralisée et nettoyé automatiquement ?

Bâtir sur Databricks, pour Databricks

Lorsque Databricks Apps est devenu disponible, l'opportunité était évidente. Nous gérions jusqu'alors les environnements via un ensemble de tâches individuelles — une tâche par mission, s'exécutant séparément et toujours avec un léger train de retard sur la réalité. Les applications nous ont permis d'abstraire tout cela derrière une interface unique : dites-nous ce que vous essayez d'accomplir en langage naturel, et nous déterminerons l'infrastructure à provisionner.

C'est devenu le principe de conception fondamental de FEVM : le provisionnement basé sur les cas d'usage. Vous ne demandez pas "un espace de travail". Vous décrivez ce que vous essayez de faire, qu'il s'agisse de créer une démo pour un client des services financiers, de reproduire un problème d'assistance ou d'animer un hackathon, et vous obtenez un environnement configuré à cet effet. Tout cela est abstrait avec un MCP en son cœur, ce qui signifie que le chat, les services externes et les agents sont tous gérés depuis un point de contrôle unique. Avec l'essor d'outils comme Claude, cela signifie qu'il suffit d'ajouter un simple fichier de compétences .md pour demander un nouvel environnement en ligne de commande en langage naturel et s'y connecter quelques minutes plus tard. Les flux de travail plus complexes deviennent tout aussi simples du point de vue de l'utilisateur.

L'application repose sur un frontend React et un backend Python, déployés via Databricks Apps. Terraform s'exécute en arrière-plan pour gérer le provisionnement effectif des ressources cloud sur AWS, Azure et GCP. Une base de données d'état et de configuration, exécutée sur Lakebase, suit chaque ressource : sa nature, son propriétaire, son utilité et sa date d'expiration.

L'expérience de développement avec Databricks Apps a elle-même été simple. Le travail le plus complexe a consisté à l'intégrer dans l'écosystème plus large : connecter les lancements de flux de travail basés sur Git, gérer l'identité à travers les systèmes de l'entreprise et veiller à ce que l'automatisation des actions administratives sur l'infrastructure backend réelle reste dans nos limites de sécurité. Nous opérons sous un certain nombre d'exceptions de sécurité précisément pour cette raison et nous avons veillé à concevoir une gestion rigoureuse à chaque étape ; les nouveaux modèles sont vérifiés, sécurisés et testés à plusieurs reprises pour s'assurer qu'ils n'exposent pas de nouveaux vecteurs de menace.

Ce que fait l'application

Lorsqu'un ingénieur de terrain ouvre FEVM, il est accueilli par une interface de recherche. Il peut parcourir un catalogue de modèles pour trouver le bon type d'environnement — par exemple, un environnement serverless stable sur AWS, une configuration multi-cloud ou un environnement avec mise à l'échelle automatique Lakebase préconfigurée — et le configurer à partir de là. Il choisit un fournisseur cloud et une région, décrit ce qu'il construit, lui donne un nom (ou en accepte un généré aléatoirement) et déploie.

Plus récemment, nous avons activé des flux de travail axés sur les agents, qui permettent aux utilisateurs de tirer parti de compétences Claude publiées de manière centralisée. C'est une option de plus en plus populaire qui permet aux agents de s'affranchir de l'UI pour interagir directement avec les API sous-jacentes de FEVM. Cela devient particulièrement puissant dans les flux de travail multi-étapes et multi-outils ; par exemple, un utilisateur peut demander à son agent de lancer un nouvel espace de travail, de déployer plusieurs DABs développés localement, de charger des données stockées dans S3, puis d'exécuter un script d'alimentation pour remplir un tableau de bord. Ce type de configuration hyper-personnalisée ne serait pas possible sans un framework d'agents solide, et Databricks Apps rend cela d'une simplicité déconcertante.

Lorsqu'un utilisateur ou un agent demande une nouvelle ressource, l'application récupère en coulisses le modèle Terraform approprié, le transmet à un Git Runner, ajuste les autorisations, puis ajoute les extensions demandées par l'utilisateur, telles que Lakebase, des notebooks ou des ressources prépackagées hébergées dans un volume UC (UC Volume). Par défaut, les environnements de création ont une durée de vie de 90 jours, avec des options de prolongation possibles, tandis que d'autres types de ressources ont une TTL configurable.

Une fois le provisionnement terminé, une notification Slack est envoyée. Lorsque la ressource approche de sa date d'expiration, une autre notification est envoyée. Lorsqu'elle est supprimée, vous en êtes à nouveau informé. La transparence était un objectif de conception fondamental dès le premier jour : chaque étape du cycle de vie est visible, et les ingénieurs connaissent toujours l'état de leurs ressources.

Nous gérons également les ressources partagées via la même interface. Les catalogues autonomes, par exemple, ont des cycles de vie indépendants des espaces de travail auxquels ils sont rattachés. Supprimez un espace de travail et le catalogue persiste ; lancez un nouvel espace de travail dans la même région et le catalogue se réassocie automatiquement. Ce type de gestion du cycle de vie au niveau des ressources est important car Unity Catalog et Lakebase ont tous deux des limites de plateforme strictes, et avec des centaines d'ingénieurs qui provisionnent activement des ressources, le contrôle centralisé est ce qui empêche ces limites de devenir un obstacle.

Une couche d'administration au sein de l'application permet à notre équipe de gérer la configuration globale — ajuster les limites des espaces de travail par cloud, auditer les déploiements actifs, affiner les paramètres par défaut — directement depuis l'UI.

Une échelle que nous ne pensions pas valider si rapidement

Lors de BuildCon — l'un de nos événements d'ingénierie internes — FEVM a traité près de 1 200 demandes de provisionnement en une seule journée. Les ingénieurs de toute l'organisation ont lancé des environnements, effectué leur travail et les ont laissés expirer, sans surcharge de coordination ni conflit de ressources. À ce jour, nous n'avons rencontré aucun problème d'évolutivité, même avec plus de 5 000 utilisateurs actifs ; au moment où nous écrivons ces lignes, nous gérons plus de 2 600 déploiements actifs sur 3 clouds !

Ce chiffre est important pour nous, non seulement en tant que test de charge, mais aussi comme preuve de concept. L'hypothèse derrière FEVM était que le provisionnement isolé et juste-à-temps pouvait éliminer les frictions des environnements partagés à grande échelle. Un tel volume d'appels en une seule journée confirme que la demande a toujours été là et que les ingénieurs avaient simplement besoin d'un outil rendant l'action fluide.

L'avenir agentique vers lequel nous tendons

La vision plus large vers laquelle nous tendons chez Databricks est celle d'une organisation d'ingénierie de terrain axée d'abord sur les agents : un ingénieur décrit la situation d'un client en langage naturel, un agent lance un environnement configuré de manière appropriée, récupère le contexte de compte pertinent, tente de reproduire le problème ou de créer la démo, et renvoie un résumé prêt à être présenté au client. FEVM est la couche d'infrastructure qui rend cela possible.

Nous avons repensé l'architecture de l'application à deux reprises pour en arriver là : refonte du schéma de la base de données, reconstruction du frontend, réévaluation de notre gestion de l'état. Nous avons utilisé l'IA pour accélérer le codage, tout en gardant le contrôle total de l'architecture tout au long du processus. Le résultat est un système auquel nous faisons confiance pour fonctionner à grande échelle.

Ce que nous avons appris

Quelques principes qui ont guidé cette conception :

• Concevez en pensant à l'utilisateur, qu'il s'agisse d'un humain ou d'un agent. Nous avons fait de gros efforts pour partir d'un CUJ et concevoir des fonctionnalités qui répondent à ce parcours. Cela nous permet de rester lucides sur ce qui doit réellement être fait et ce qui relève du simple biais interne.
• La transparence est une fonctionnalité à part entière, pas une réflexion après coup. Rendre visible chaque événement du cycle de vie — provisionnement, expiration, suppression — est ce qui renforce la confiance des ingénieurs qui dépendent de cet outil pour leur travail en direct avec les clients.
• L'intégration de l'écosystème est un travail difficile. L'expérience de développement de Databricks Apps a été rapide et simple, mais connecter FEVM à Git, Slack, aux e-mails, à l'identité d'entreprise et à Terraform multi-cloud a représenté la majeure partie de l'effort d'ingénierie, et c'est de là qu'est venue la majeure partie de la valeur.

Développer pour Databricks sur Databricks. Presque tout dans FEVM s'exécute sur la plateforme elle-même. Cela nous donne un aperçu direct de ce qui fonctionne à grande échelle et nous permet de rester proches de l'expérience produit que nous vendons.

Et ensuite ?

Nous nous concentrons sur trois aspects : étendre l'interface de provisionnement en langage naturel, déployer l'intégration MCP pour l'accès basé sur les outils, et faire évoluer le support au sein de l'organisation GTM plus large. À mesure que les agents assument une plus grande part du travail effectué aujourd'hui par les ingénieurs de terrain, FEVM deviendra la couche de ressources sur laquelle ces agents s'exécutent — pas seulement un outil de provisionnement, mais une infrastructure centrale pour un workflow agentique.

Regardez la session parallèle du Data and AI Summit 2026 Le provisionnement à l'ère agentique : comment Databricks a créé un distributeur d'infrastructure en libre-service pour plus de détails sur la FE Vending Machine.

Pour en savoir plus sur la création d'applications prêtes pour la production sur Databricks, découvrez Databricks Apps, Lakebase et Agent Bricks.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original