L’unité clé de configuration est le Genie space, souvent décrit comme un espace Genie. D’après la documentation Microsoft, des experts du domaine, par exemple des analystes de données, configurent ces espaces avec des jeux de données, des exemples de requêtes et des consignes textuelles afin d’aider Genie à traduire les questions métier en requêtes analytiques . La même documentation indique que les équipes peuvent suivre et améliorer ses performances grâce aux retours des utilisateurs .
Ce point est moins anecdotique qu’il n’y paraît. Dans l’analytics d’entreprise, les termes « client actif », « revenu net », « bookings », « churn » ou « pipeline » peuvent changer de sens d’une société à l’autre, voire d’un service à l’autre. Un agent de code qui ne voit que le prompt de l’utilisateur peut générer une requête apparemment correcte, mais fondée sur la mauvaise définition. Avec un espace Genie bien configuré, le champ des possibles est plus étroit, donc potentiellement plus pertinent.
Databricks explique que les agents de données évoluent dans un environnement lakehouse dynamique, où le contexte sémantique est dispersé entre tables, notebooks, tableaux de bord et documents . Des analyses externes décrivent aussi Genie comme utilisant une recherche spécialisée dans les actifs de données existants, avec des index destinés à améliorer leur découverte .
C’est crucial : avant même d’écrire une requête, un agent doit trouver le bon point de départ. Une requête peut être techniquement correcte et fausse sur le fond si elle joint la mauvaise table, ignore le tableau de bord de référence ou passe à côté d’une définition métier. L’avantage revendiqué de Genie tient à sa capacité à chercher et raisonner dans l’environnement de données de l’entreprise, plutôt qu’à répondre uniquement depuis le prompt.
Beaucoup de questions métier ne sont pas de simples exercices de text-to-SQL. « Pourquoi la conversion baisse-t-elle ? » ou « comment améliorer la marge ? » demandent souvent plusieurs étapes : confirmer la tendance, la découper par segment, tester des hypothèses, comparer des périodes, puis résumer ce que les données permettent réellement d’affirmer.
Databricks décrit Genie Agent Mode comme capable de traiter des questions plus avancées, du type « pourquoi ? », « et si ? » ou « comment pourrions-nous améliorer ? » . En coulisses, selon Databricks, ce mode planifie, teste des hypothèses et raisonne à travers plusieurs requêtes pour répondre aux questions métier . L’entreprise ajoute que ce mode adapte l’ampleur de son raisonnement à la complexité de la question, avec des chemins plus rapides pour les demandes courantes et une analyse plus rigoureuse pour les sujets complexes .
Cette logique se rapproche davantage du travail d’un analyste que du comportement d’un agent de code généraliste. L’objectif n’est pas seulement de produire une requête, mais de mener une investigation structurée sur les données de l’entreprise.
Les agents de code traditionnels sont optimisés pour générer, modifier et expliquer du code. Ils peuvent être très utiles pour écrire du SQL, manipuler des notebooks, construire des pipelines ou aider à éditer des tableaux de bord. Mais l’analytics d’entreprise ajoute une couche plus délicate : le modèle doit comprendre des définitions métier, des actifs gouvernés et une logique sémantique, pas seulement être fluide en programmation.
Un guide consacré à l’analytics agentique sur Databricks souligne que les LLM qui écrivent du SQL se heurtent directement à ce manque de contexte et qu’en l’absence de définitions métier explicites, ils peuvent halluciner des tables . C’est le risque central : obtenir une requête crédible à l’œil nu, mais branchée sur les mauvaises données ou construite avec la mauvaise logique de métrique.
Genie tire donc son argument de la spécialisation. Databricks attribue son gain de précision à des techniques propres aux agents de données, tandis qu’une couverture externe évoque une recherche spécialisée, du « parallel thinking » et des architectures multi-LLM . Ces techniques ciblent des flux d’analytics où le système doit retrouver le contexte, raisonner sur les données et expliquer ses résultats — pas seulement écrire du code.
Le chiffre le plus frappant reste celui publié par Databricks : plus de 90 % de précision pour Genie contre 32 % pour un agent de code de premier plan sur un benchmark interne de tâches réelles d’analyse de données . Il appuie la thèse de l’éditeur : les agents de données ont besoin de contexte spécialisé et de raisonnement métier.
Mais la limite est tout aussi importante. Parce que ce benchmark est interne et communiqué par Databricks, il ne faut pas le considérer comme une garantie générale. En production, la précision dépendra de la qualité des espaces Genie de chaque organisation : définitions sémantiques, requêtes d’exemple, consignes textuelles et boucle de retour utilisateur .
Il y a aussi le vieux principe du « garbage in, garbage out » : si les données d’entrée sont mauvaises, la réponse le sera probablement aussi. Un commentaire sur l’industrialisation de la couche sémantique dans Databricks avertit que de mauvaises tables ou de mauvais modèles peuvent encore dégrader les performances de Genie . Un autre aperçu note également que Genie devient plus utile lorsque le modèle de données sous-jacent capture correctement les définitions métier, les relations et les métriques de confiance .
Genie est surtout pertinent pour des questions d’analytics métier, pas pour une tâche de programmation générale. Il devrait être à son avantage lorsque :
Un agent de code peut rester le meilleur choix pour du développement logiciel, la mise en œuvre de pipelines de données ou l’édition générale de notebooks. Mais pour des utilisateurs métier qui posent des questions en langage naturel sur des données d’entreprise, la portée plus étroite de Genie devient précisément son avantage : l’agent est contraint par le contexte de données de l’organisation.
Databricks Genie peut être plus précis qu’un agent de code traditionnel parce qu’il traite l’analytics d’entreprise comme un problème de contexte et de raisonnement, et non comme un simple problème de génération de code. Il mobilise une terminologie propre à l’organisation, une configuration par des experts, la recherche dans les actifs de données et une démarche d’enquête proche de celle d’un analyste pour réduire le risque de réponses plausibles mais fausses .
La prudence reste nécessaire : la promesse la plus spectaculaire vient d’un benchmark interne de Databricks, et les performances réelles dépendront de la qualité des données, du modèle sémantique et de la boucle d’amélioration continue . Avant de s’appuyer sur Genie pour des décisions importantes, une équipe devrait le tester sur ses propres questions à réponse connue, ses métriques de référence et ses flux métier les plus critiques.