SQL a cinquante ans. Et il n'a jamais été aussi central. Dans mon quotidien d'analytics engineer, tout passe par ce langage : les transformations dans dbt, les requêtes sur DuckDB, les tables que je sers aux équipes métier. Même les outils no-code finissent par générer du SQL en arrière-plan. Le langage qu'on enterrait à l'époque du Big Data est devenu le pivot entre les pipelines ELT et l'exploration directe des données.
Prends un flux ELT classique. Je charge les données brutes dans un entrepôt cloud, puis je transforme tout avec des modèles SQL. C'est dbt qui m'a vraiment convaincu : tu écris des SELECT, tu les testes, tu les documentes, tu les versionnes. Fini les scripts Python fragiles qui tournent sur un serveur au fond du bureau. La transformation devient du code propre, reviewable et rejouable. Autour de ça, l'open source a explosé. DuckDB transforme mon laptop en mini-entrepôt : je lance un SELECT * FROM 'ventes.csv' et j'obtiens une réponse en quelques millisecondes. ClickHouse, lui, gère des volumes OLAP sérieux quand la RAM ne suffit plus.
Le risque, c'est la prolifération des requêtes ad hoc. Chaque analyste réinvente sa définition du chiffre d'affaires, et personne ne parle de la même chose. La parade, c'est une couche sémantique : des définitions réutilisables, portées par dbt ou par ton outil BI. Apache Calcite mérite aussi le coup d'œil, car c'est le parser que beaucoup de moteurs utilisent en coulisse pour analyser le SQL. Comprendre cet écosystème, c'est comprendre où va l'analyse de données.
SQL, le langage pivot des pipelines ELT et de l'exploration métier
SQL n'est plus un langage de requête. C'est l'interface de toute la stack data. Quand je charge des données dans Snowflake ou BigQuery, la première chose que je fais, c'est écrire un SELECT.
Le modèle ELT a accéléré cette bascule. Avant, tu transformais dans un pipeline séparé, souvent en Python ou Java. Maintenant, tu charges les données brutes et tu transformes dans la base, avec SQL. dbt a rendu ça mainstream : tu écris des SELECT, tu les testes, tu les documentes, et tu les exécutes dans l'entrepôt.
Pourquoi SQL ? Parce que tout le monde le parle. Les data engineers l'utilisent pour charger, les analystes pour explorer, les équipes métier pour lire les dashboards. Même les outils no-code comme Tableau ou Power BI génèrent du SQL en arrière-plan. C'est la lingua franca de la data.
Concrètement, chez moi, un flux ELT typique c'est : ingestion dans DuckDB pour les tests locaux, puis un modèle dbt qui transforme, puis une vue exposée dans Metabase. Tout est du SQL. Si un analyste veut une nouvelle mesure, il modifie le modèle dbt, pas un script Python.
L'impact de l'ELT, c'est que SQL est devenu le point de passage obligé. Il n'y a plus de frontière entre ingestion et exploration. La transformation EST l'exploration. C'est pour ça que l'écosystème open source s'est concentré sur SQL : DuckDB pour l'analytique embarquée, ClickHouse pour l'OLAP haute performance, Apache Calcite pour parser et optimiser les requêtes dans d'autres moteurs.
Reste un piège : la prolifération des requêtes ad hoc. Chacun sa définition du CA, et tu passes tes journées à réconcilier des chiffres. La solution, c'est une couche sémantique avec des définitions réutilisables, portée par dbt ou ton outil BI. Sans ça, SQL devient une tour de Babel au lieu d'une lingua franca.
DuckDB, ClickHouse et l'essor des outils open source d'analyse SQL
Un SELECT sur dix millions de lignes répond en moins de 50 millisecondes sur mon laptop. C'est la première chose qui m'a scotché avec DuckDB. J'ai arrêté mes petits scripts pandas sur-le-champ. Ce moteur SQL embarqué est une claque pour l'exploration interactive : tu pointes un fichier Parquet en local ou sur S3, tu lances une requête, et tu obtiens une réponse instantanée, sans charger la donnée dans un vrai serveur.
Exemple type : tu as des exports journliers dans un bucket S3. Avec DuckDB, je fais SELECT month, sum(price) FROM 's3://mon-bucket/*.parquet' GROUP BY month directement depuis un terminal. C'est tapé en trois secondes, ça tourne en cent millisecondes, et ça me permet de valider une hypothèse avant d'écrire un modèle dbt. C'est devenu mon bac à sable local, et c'est même un moteur de production pour des analyses qui ne nécessitent pas un entrepôt gigantesque. MotherDuck ajoute une couche cloud collaborative par-dessus, donc tu peux partager ces bases à plusieurs.
ClickHouse, c'est une autre bête. Pour de l'OLAP massif, avec des milliards de lignes, des cardinalités énormes et des agrégations sub-secondes, il écrase les entrepôts classiques. Je l'ai utilisé pour un client qui collecte vingt milliards d'événements par jour. Sur Snowflake, ça revenait très cher. Sur une poignée de serveurs ClickHouse autogérés, les requêtes passent en moins d'une seconde. Le moteur est beaucoup moins flexible que DuckDB — tu crées des tables, tu gères des partitions — mais quand le volume devient sérieux, il n'y a pas photo.
Est-ce que ces outils remplacent Snowflake ou BigQuery ? Pour moi, non. Ce sont des compléments. DuckDB pour l'exploration locale, ClickHouse pour les workloads OLAP pointus, et les plateformes cloud pour la gouvernance, les accès métier et l'élasticité. Mais ils imposent une pression énorme sur les acteurs propriétaires. Tu peux faire tourner une stack entièrement open source — DuckDB, dbt, Postgres, Metabase — avec des coûts dérisoires. Et franchement, la tendance ne fait que s'accélérer.
dbt au cœur des transformations SQL dans les flux ELT
Le jour où j'ai mis mes transformations SQL dans dbt, j'ai supprimé 80% de mes scripts Python. Tes SELECT deviennent du code versionné, testé et reviewable, exactement comme une appli. Chaque modèle est un fichier .sql, chaque test une déclaration YAML, et la CI te dit si tu peux merger sans casser les modèles aval.
Concrètement, mon stack ELT : Airbyte charge dans Snowflake, puis dbt enchaîne les modèles en respectant un graphe de dépendances. J'ai des tests sur les clés primaires, les montants non-négatifs, les relations entre tables — tu déclares ça en deux lignes de YAML dans un fichier schema.yml. Si un test casse, dbt stoppe le run et envoie une alerte sur Slack, avant que les données pourries n'arrivent dans les dashboards.
Mais le plus gros gain, c'est la collaboration : avant, chaque analyste écrivait sa propre définition du chiffre d'affaires dans son coin, maintenant tout le monde pousse sa logique dans le même repo, en SQL. Un analyste ouvre une PR pour ajouter une métrique, un ingénieur valide la perf, et la documentation se génère via dbt docs. C'est exactement comme ça que dbt s'articule avec l'ELT : il est la couche de transformation entre le chargement et l'exploration, sans code en dehors de l'entrepôt.
Couche sémantique, tendances récentes et bonnes pratiques
Le calcul du chiffre d'affaires varie de 30% selon les requêtes. C'est le symptôme classique d'une stack sans couche sémantique. Chaque analyste écrit sa propre définition, et les dashboards finissent par se contredire.
La solution, c'est de traiter les métriques comme du code. Avec dbt, tu définis une mesure une fois, tu la testes, tu la documentes. Tout le monde la réutilise depuis le même endroit.
Exemple chez moi : la métrique 'revenue' est déclarée dans un fichier YAML dbt. Chaque dashboard la référence. Un changement de calcul passe par une review de code, pas par un mail.
Du côté des tendances, l'écosystème s'accélère. L'hybrid execution entre DuckDB et MotherDuck te permet de faire tes analyses en local et de basculer dans le cloud quand la donnée grossit. ClickHouse, lui, écrase tout sur les volumes OLAP massifs. Et Apache Calcite s'impose comme le parser SQL caché derrière plusieurs moteurs récents — c'est lui qui transforme ton SQL en plan d'exécution optimal.
Attention à ne pas transformer la gouvernance en prison. Mon approche : les modèles de base sont contractés (tests dbt, contrats de données), mais je laisse les analystes explorer librement dans des sandboxes. Tu encadres le chemin critique, tu libères le reste. La couche sémantique sert à cadrer, pas à bloquer.
Conclusion
Si tu retires SQL de ta stack data, tout s'écroule. Ce langage a cinquante ans, et il n'a jamais été aussi présent. Dans mon quotidien, c'est le pivot entre les pipelines ELT pilotés par dbt et l'exploration métier. DuckDB me sert de mini-entrepôt local, ClickHouse gère les gros volumes OLAP, et une couche sémantique propre évite que chaque analyste réinvente son propre chiffre d'affaires.
J'ai vu des équipes se déchirer sur des définitions de métriques. La solution n'est pas un outil magique, mais une couche sémantique portée par dbt, avec des modèles SQL versionnés et testés. Ce n'est pas glamour, mais ça change tout. Et côté moteur, l'open source a fait des bonds : DuckDB est immédiat, MotherDuck l'étend dans le cloud, ClickHouse pulvérise les records de performance OLAP. Tu n'as plus besoin d'un entrepôt coûteux pour analyser des millions de lignes.
Apache Calcite est le héros invisible. C'est le parser SQL qu'utilisent une bonne partie des moteurs, y compris certains outils que tu croises tous les jours. Il normalise la syntaxe, optimise les requêtes, et rend l'interopérabilité possible. Comprendre cette brique, c'est comprendre pourquoi SQL reste le langage universel malgré les modes successives.
Mon avis tranché : arrête de te disperser. Construis ta stack autour de SQL, dbt pour les transformations, DuckDB ou ClickHouse pour l'exécution, et une couche sémantique pour stabiliser les définitions. L'écosystème est mûr. Le reste est du bruit.