Databricks Genie face aux agents de code : l’avantage décisif du contexte métier

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.

Genie s’appuie sur les actifs de données existants

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 ^[3]. 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 ^[1].

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.

Le mode Agent enquête au lieu de répondre en un seul coup

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 ? » ^[2]. En coulisses, selon Databricks, ce mode planifie, teste des hypothèses et raisonne à travers plusieurs requêtes pour répondre aux questions métier ^[2]. 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 ^[2].

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.

Pourquoi les agents de code généralistes dérapent plus facilement

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 ^[9]. 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 ^[1][3]. 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.

Un benchmark utile, mais pas une preuve universelle

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 ^[3]. 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 ^[7].

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 ^[12]. 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 ^[4].

Quand Genie a le plus de chances de faire mieux

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 :

• des experts métier ont configuré l’espace Genie avec les bons jeux de données, des requêtes d’exemple et des consignes ^[7] ;
• l’organisation dispose de définitions de métriques claires et de modèles de données de confiance ^[4] ;
• la réponse dépend de la capacité à retrouver les bonnes tables, dashboards, notebooks ou documents ^[1][3] ;
• la question exige une enquête en plusieurs étapes, par exemple une analyse de cause racine ou une exploration de scénarios ^[2] ;
• les équipes surveillent les réponses et améliorent l’espace grâce aux retours utilisateurs ^[7].

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.

À retenir

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 ^[2][3][7].

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 ^[3][7][12]. 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.