Chaque fois qu'une entreprise modernise sa plateforme de données avec Microsoft Fabric, la même question revient : Lakehouse, Warehouse ou Eventhouse ? Si vous lisez ce blog, la réponse courte vous semblera familière : il n'existe pas de stockage idéal. Il existe le bon pour chaque type de travail — et le piège consiste à forcer un seul à tout faire.
D'abord, le plateau : tout atterrit dans le même lac
Microsoft Fabric réunit toutes les charges analytiques sur une seule plateforme SaaS, et tout ce qui entre finit au même endroit : OneLake, une copie unique de la donnée. Cela compte plus qu'il n'y paraît : les trois stockages ne sont pas trois silos qui se disputent vos données, mais trois façons différentes de travailler sur le même lac. La différence n'est pas la donnée — c'est la charge de travail.
Lakehouse : le flexible
Le Lakehouse accepte fichiers et tables : données structurées, semi-structurées ou brutes. Un CSV de la balance, le JSON d'une API, du parquet, des logs, même des images — tout atterrit dans sa zone de fichiers, et ce qui se raffine se matérialise en tables Delta. C'est le terrain naturel de l'ingénierie et de la science des données : Spark, R et SQL pour travailler ; T-SQL pour lire.
Quand le choisir : quand votre matière première est variée et qu'il faut la transformer, l'explorer ou entraîner des modèles dessus.
Warehouse : le structuré
Le Warehouse est un entrepôt SQL complet : T-SQL avec DML et DDL complets, écritures transactionnelles et modèles propres pensés pour la BI. Uniquement des données structurées, avec l'ordre et les garanties qu'exige un reporting sérieux. Si votre question est « d'où boit mon Power BI chaque lundi ? », la réponse habite généralement ici.
Quand le choisir : quand la destination est l'analyse métier — modèles en étoile, chiffres réconciliés, rapports qui ne peuvent pas faillir.
Eventhouse : le temps réel
L'Eventhouse reçoit les flux au moment où ils se produisent — télémétrie, événements, logs — et les rend interrogeables en quelques secondes avec KQL (et T-SQL aussi). C'est la pièce pour ce qui ne peut pas attendre le traitement nocturne : capteurs d'atelier, activité d'un site web, surveillance de machines.
Quand le choisir : quand la valeur de la donnée expire en quelques minutes et que la question est « que se passe-t-il maintenant ? ».
Les trois, face à face
| Lakehouse | Warehouse | Eventhouse | |
|---|---|---|---|
| Usage | Ingénierie et science des données | BI et reporting | Analytique temps réel |
| Requête | Spark · T-SQL (lecture) | T-SQL complet | KQL · T-SQL |
| Écritures | Par lots | Transactionnelles | Streaming et lots |
| Donnée | Du brut au structuré | Structurée | Événements · séries temporelles |
Le même lac en dessous. La différence, c'est la charge de travail, pas la donnée.
Le piège (et comment les projets s'enlisent)
Il n'y a pas de stockage idéal : chacun est conçu pour un schéma de travail précis. Forcer un seul à tout couvrir est la recette classique du projet enlisé — le Warehouse noyé sous des fichiers bruts, ou le Lakehouse en mauvaise base pour un reporting qui exigeait des transactions. Le bon choix est dicté par la charge de travail, pas par la mode du moment.
Dans le monde réel : ils se combinent
Les solutions matures ne choisissent pas un stockage : elles les combinent, chacun gérant le schéma pour lequel il a été conçu. Les fichiers et bases de données entrent par le Lakehouse ; la couche raffinée alimente le Warehouse ; les événements tombent dans l'Eventhouse — et au-dessus des trois, un seul rapport Power BI qui raconte tout. Une copie de la donnée, trois moteurs, une seule vérité pour décider.
La même règle que toujours
Si vous suivez cette série, vous connaissez déjà notre conclusion maison : c'est le cas qui choisit l'outil, pas le catalogue. Tout comme il n'y a pas de « meilleur outil de BI » sans connaître votre contexte, il n'y a pas de stockage gagnant dans Fabric sans connaître votre charge de travail. D'abord comprendre ce qui doit circuler, à quelle vitesse et pour répondre à quelle question — et seulement ensuite, choisir la pièce.
Ricardo Borja est fondateur d'Inteleqta et consultant en ERP et Business Intelligence, certifié Microsoft Power BI Data Analyst Associate. Une version visuelle de ce guide a été publiée en carrousel sur son LinkedIn.