À quoi sert Databricks ? Un guide sans jargon

Databricks sert à rassembler les données d'une entreprise en un seul endroit, à les nettoyer et à en tirer des rapports, des prévisions et des applications d'IA. En termes métier, c'est la plateforme où les données de votre ERP, de vos usines, de votre CRM et de vos fichiers sont travaillées jusqu'à devenir fiables pour les équipes comme pour les modèles.

La réponse complète dépend de votre problème, car Databricks couvre un périmètre large. Pipelines de données, entrepôt de données SQL, tableaux de bord BI, machine learning, agents d'IA et désormais une base Postgres. Très peu d'entreprises ont besoin de tout cela dès le premier jour.

J'ai travaillé avec Databricks sur des programmes de plateforme de données dans l'industrie manufacturière et la défense. Ce guide s'adresse au DSI, au DAF ou au responsable data qui doit décider si la plateforme a sa place dans son architecture.

La présentation officielle de la plateforme par Databricks liste une longue série de tâches possibles. En pratique, j'en vois cinq.

1. Ingénierie des données et ETL. Extraire les données des systèmes sources, les nettoyer et les charger dans des tables. C'est le cas d'usage de fond, et généralement là que part l'essentiel de la dépense. La famille de produits s'appelle Lakeflow. Lakeflow Connect gère l'ingestion et Lakeflow pipelines (anciennement Delta Live Tables) gère la transformation. Lakeflow Designer sert à la préparation visuelle des données, et Lakeflow Jobs à l'orchestration.
2. Entrepôt de données avec Databricks SQL. Databricks SQL est son entrepôt de données cloud, qui tourne sur des SQL warehouses. Les analystes écrivent du SQL sur les mêmes tables que celles construites par les ingénieurs. Pas de copie séparée dans un autre entrepôt.
3. BI et analytique en libre-service. Les tableaux de bord AI/BI sont intégrés à la plateforme, et les tables alimentent aussi Power BI, Tableau ou l'outil que votre entreprise utilise déjà. Genie permet aux utilisateurs métier de poser des questions en langage courant sur des données gouvernées.
4. Machine learning. Prévision de la demande, maintenance prédictive, prédiction de la qualité, tarification. MLflow suit les expériences et les modèles, et le model serving les met en production.
5. IA générative et agents. Agent Bricks est aujourd'hui l'outil pour construire et gouverner des agents d'IA sur vos données. Genie One, disponible en version générale depuis juin 2026, est l'interface destinée aux utilisateurs métier. Les documents plus anciens appellent une grande partie de cet outillage IA Mosaic AI ; les pages produit actuelles mettent en avant Agent Bricks et Genie.

Deux briques plus récentes comptent pour certains acheteurs. Lakebase est une base de données Postgres managée au sein de la plateforme, pour les applications qui ont besoin de lectures et d'écritures transactionnelles rapides à côté des données analytiques.

Databricks a annoncé la disponibilité générale de Lakebase début 2026. Databricks Apps, disponible en version générale depuis mai 2025, permet aux équipes de construire et d'héberger sur la plateforme des applications internes de données et d'IA.

Une remarque sur les noms, car elle brouille les résultats de recherche. Databricks a passé deux ans à promouvoir la « Data Intelligence Platform ». Ses pages produit parlent désormais de « Databricks Data + AI Platform ».

Même plateforme. Et Databricks One a été renommé Genie One.

Avant Databricks, la plupart des entreprises faisaient tourner deux systèmes. Un data lake stockait des fichiers bruts bon marché, dont des journaux de capteurs, des documents et des images, pour les data scientists.

Un entrepôt de données contenait des tables propres et structurées pour la finance et la BI. Les données étaient copiées de l'un à l'autre, et les deux copies finissaient par diverger.

Le lakehouse est la réponse de Databricks : garder une seule copie des données dans des formats ouverts (des tables Delta Lake sur votre stockage cloud) et faire tourner la BI comme l'IA dessus. Unity Catalog se place au-dessus et contrôle qui voit quoi, trace le lignage et journalise les accès. C'est cette couche de gouvernance qui transforme un tas de fichiers en quelque chose qu'un auditeur acceptera.

La plupart des équipes organisent le lakehouse selon l'architecture médaillon. Trois couches, chacune plus propre que la précédente.

Comment les données traversent les couches médaillon

1. 01

   Systèmes sources

   ERP, MES, historiens, CRM, tableurs et documents.

2. 02

   Bronze

   Données brutes déposées telles qu'elles sont arrivées. Conservées pour l'audit et le retraitement.

3. 03

   Silver

   Nettoyées, dédoublonnées et validées. Une seule version fiable de chaque enregistrement.

4. 04

   Gold

   Modélisées pour le métier : marge par produit, arrêts par ligne, dépenses par fournisseur.

5. 05

   Consommateurs

   Tableaux de bord, reporting financier, modèles de ML, agents d'IA et applications.

La version pour le dirigeant : le bronze, c'est la preuve, le silver, c'est l'enregistrement nettoyé, le gold, c'est la réponse à une question métier. Votre DAF ne devrait jamais voir que du gold. Vos data scientists passeront l'essentiel de leur temps dans le silver.

Dans les programmes industriels sur lesquels j'ai travaillé, le vrai effort se situe dans le silver. Des numéros d'article qui diffèrent d'une usine à l'autre. Des unités de mesure qui ne se rapprochent pas.

Des horodatages de capteurs en heure locale face à des écritures ERP en UTC. Rien de tout cela n'est un problème Databricks, mais c'est dans Databricks que vous finissez par le résoudre.

Databricks ne remplace pas SAP S/4HANA, Oracle Fusion Cloud ERP ou Microsoft Dynamics 365. L'ERP reste le système de référence pour les commandes, les stocks, les factures et le grand livre. Databricks prend des copies de ces données, les combine avec des données que l'ERP ne voit jamais, et alimente l'analytique et l'IA.

Les données ERP arrivent généralement par l'une de trois voies :

1. Connecteurs natifs ou partenaires. Lakeflow Connect, ainsi que des outils de réplication tiers, extraient des tables ou des changements de données depuis la base de l'ERP ou ses API.
2. Extractions depuis la couche de données de l'ERP. Des exports issus des services d'analytique et de données de SAP, Oracle ou Dynamics, déposés dans le bronze.
3. Le produit de données de l'éditeur ERP. Pour les entreprises sous SAP, SAP Business Data Cloud est une option. Il inclut SAP Databricks, un service Databricks managé intégré à l'offre SAP, dont Databricks a annoncé la disponibilité générale. Il existe aussi une voie de partage zero-copy de Business Data Cloud vers un environnement Databricks existant.

La bonne voie dépend des licences, des volumes de données et du poids des données hors ERP. La difficulté n'est jamais l'extraction.

C'est le sens métier : quelle usine, quel grand livre, quelle version d'un client. Si ce n'est pas réglé, mon article sur les raisons de l'échec des migrations de données traite des mêmes causes profondes.

Industrie manufacturière. Le cas le plus solide consiste à croiser les données ERP avec les données d'usine. Relevés de machines et de capteurs issus des historiens et des plateformes IoT, enregistrements du système d'exécution de la production (MES), résultats de contrôle qualité et journaux de maintenance. Rapprochées des commandes, articles et coûts de l'ERP, ces données répondent à des questions qui intéressent autant la finance que les opérations : coût des rebuts par ligne, maintenance avant la panne, qualité fournisseur au regard du prix payé.

Les volumes de capteurs sont importants et désordonnés. Un lakehouse les gère mieux qu'un entrepôt traditionnel. Dans mes missions industrielles, le premier cas d'usage qui a rentabilisé la plateforme a été le calcul des coûts : rassembler les coûts de matières premières et de main-d'œuvre pour aboutir à un coût standard.

La finance est déjà propriétaire de ce chiffre, donc la valeur se voit facilement. Si vous choisissez encore l'ERP sous-jacent, consultez mon comparatif des ERP pour l'industrie manufacturière.

Défense. Les questions sont différentes. Où se trouvent physiquement les données ? Qui exploite la plateforme ?

Peut-on séparer les données classifiées et non classifiées, et prouver les accès lors d'un audit ? Les programmes durent des décennies, donc le choix de plateforme doit survivre à plusieurs cycles technologiques.

Dans mes missions défense, la séparation entre données classifiées et non classifiées a pesé sur la conception plus que tout le reste. Réglez cette séparation avant de concevoir le moindre pipeline.

L'architecture compte ici. Dans Databricks, le plan de contrôle tourne dans le compte de Databricks. Le calcul classique tourne dans votre propre compte cloud.

Le calcul serverless tourne dans le compte de Databricks, dans la même région. Pour un responsable data dans la défense, cette différence est la première conversation, avant toute démonstration de fonctionnalité. Pour les travaux du gouvernement américain, il existe un déploiement distinct, Databricks on AWS GovCloud.

Hors des États-Unis, vérifiez la disponibilité par région et en cloud souverain au regard de vos règles de résidence des données et de contrôle des exportations (obligations de type ITAR comprises) avant d'établir votre liste restreinte. J'ai constaté que le contrôle d'accès fin et les journaux d'audit d'Unity Catalog pèsent lourd dans ces revues.

Il est facile d'acheter Databricks pour le mauvais usage.

1. Ce n'est ni un ERP ni un système de référence. N'y faites pas passer les transactions ni le grand livre. Lakebase gère des données applicatives, pas votre grand livre.
2. Ce n'est pas un outil de tableaux de bord rapides. Si l'objectif est d'obtenir vingt tableaux de bord financiers sur des données ERP propres, Databricks est un chemin lourd pour y arriver.
3. Il ne corrige pas une mauvaise responsabilité sur les données. Si personne n'est propriétaire des données de base client, Databricks traitera simplement le désordre plus vite.
4. Il ne tourne pas tout seul. Il vous faut des data engineers capables d'écrire du SQL et du Python, plus quelqu'un qui surveille les coûts. La dépense est facturée à l'usage, donc les traitements mal écrits apparaissent sur la facture.
5. Il n'est pas gratuit pour un usage professionnel. La Free Edition sert à l'apprentissage et aux expérimentations. Les limites de la Free Edition publiées par Databricks précisent qu'elle ne peut pas être utilisée à des fins commerciales.

La question que j'entends le plus : avons-nous besoin de Databricks, ou un entrepôt plus simple ferait-il l'affaire ? Voici comment je la pose.

Votre situation	Databricks convient	Une option plus simple suffit probablement
Sources de données	ERP plus capteurs, MES, documents, flux externes	Surtout des tables ERP et CRM
Volume et fréquence de changement	Volume élevé, streaming ou quasi temps réel	Traitement par lots quotidien, volume modéré
Principaux utilisateurs	Data engineers, data scientists et analystes	Analystes finance et métier
Projets d'IA et de ML	Cas d'usage financés, avec des responsables	Des idées sans sponsor pour l'instant
Compétences de l'équipe	Ingénieurs SQL et Python en interne ou sous contrat	Surtout des compétences BI et Excel
Besoins de gouvernance	Accès fin, lignage, audit sur de nombreuses sources	Accès standard par rôle

Si la plupart de vos réponses se trouvent dans la colonne de droite, commencez par l'analytique de votre éditeur ERP ou par un entrepôt managé. Pour une comparaison plus fine, lisez mes articles voisins sur Snowflake vs Databricks et Databricks vs Microsoft Fabric.

Pour les coûts, consultez la tarification de Databricks expliquée. Databricks facture le calcul en Databricks Units (DBUs), en paiement à l'usage ou en engagement de consommation, et le stockage cloud et le réseau s'ajoutent par-dessus.

Une liste de contrôle pour décider

1. Pouvez-vous citer trois décisions métier qui changeront si la plateforme de données fonctionne ? Sinon, arrêtez-vous et trouvez-les.
2. De quelles sources de données avez-vous besoin au-delà de l'ERP, et quelle est leur taille ?
3. Qui est propriétaire des données de base client, article, fournisseur et du plan comptable ?
4. Quelles sont vos contraintes de résidence des données, de souveraineté et de contrôle des exportations ?
5. Disposez-vous d'une équipe d'ingénierie des données sur le long terme, ou allez-vous la financer ?
6. Quel outil de BI conservez-vous, et lira-t-il les données depuis Databricks SQL ?
7. Qui est responsable de la dépense mensuelle de la plateforme, et quelle alerte déclenche une revue ?
8. Qu'allez-vous arrêter quand ce sera en production ? Si la réponse est rien, vous ajoutez du coût au lieu de consolider.

Choisissez un cas d'usage avec un responsable métier nommé et de vrais enjeux financiers. Dans l'industrie, ce sont souvent les rebuts, les arrêts ou les stocks. Construisez-le à travers bronze, silver et gold, avec la gouvernance Unity Catalog activée dès la première table.

Mesurez le résultat et le coût d'exploitation. Décidez ensuite s'il faut passer à l'échelle.

Je ne commencerais ni par une migration à l'échelle de l'entreprise ni par un agent d'IA. La gouvernance a sa place dans ce premier développement, pas dans une phase ultérieure ; mon guide sur le cadre de gouvernance de l'IA explique pourquoi.

Si vous comparez Databricks à d'autres plateformes, ou cherchez comment il s'articule avec SAP, Oracle ou Dynamics 365, je donne des conseils indépendants sur ces décisions. Vous pouvez me contacter ici.

Qu'est-ce que Databricks, en termes simples ?

Databricks est une plateforme cloud où les entreprises stockent, nettoient et analysent de grandes quantités de données, et construisent du machine learning et de l'IA par-dessus. Elle fonctionne sur AWS, Microsoft Azure et Google Cloud. Voyez-la comme l'atelier d'ingénierie entre vos systèmes sources et vos rapports, modèles et outils d'IA.

Databricks est-il une base de données ou un entrepôt de données ?

Les deux, en partie. Databricks SQL est un entrepôt de données cloud construit sur le lakehouse, et Lakebase est une base Postgres managée pour les applications. En dessous, les données sont stockées sous forme de tables en format ouvert sur un stockage cloud. Ce n'est pas un système de référence transactionnel comme un ERP.

Quelle est la différence entre Databricks et Snowflake ?

Les deux font de l'analytique SQL sur des données cloud. Databricks est parti de l'ingénierie des données et du machine learning sur des formats ouverts. Snowflake a démarré comme entrepôt de données SQL managé. Les deux se recoupent désormais largement. Le bon choix dépend de vos types de données, de vos compétences et de vos projets d'IA. Mon comparatif Snowflake vs Databricks traite le sujet en détail.

Databricks remplace-t-il SAP ou d'autres ERP ?

Non. L'ERP reste le système de référence pour les transactions et le grand livre. Databricks prend des copies des données ERP, les combine avec d'autres sources comme les données d'usine et de capteurs, et alimente l'analytique et l'IA. Les clients SAP peuvent aussi utiliser SAP Databricks au sein de SAP Business Data Cloud.

Qu'est-ce que l'architecture médaillon dans Databricks ?

Une façon d'organiser les données en trois couches. Le bronze contient les données brutes telles qu'elles sont arrivées. Le silver contient des enregistrements nettoyés et validés. Le gold contient des tables prêtes pour le métier, destinées au reporting, au ML et à l'IA. Chaque couche est plus raffinée que la précédente, et les utilisateurs métier ne devraient consommer que du gold.

Databricks est-il gratuit ?

Databricks Free Edition est gratuite pour apprendre et expérimenter, avec des quotas et des limites fonctionnelles, et ne peut pas être utilisée à des fins commerciales. L'usage professionnel est facturé à la consommation en DBUs, soit en paiement à l'usage, soit via un contrat d'engagement de consommation, avec le stockage cloud et le réseau en plus.