dbt & analytics engineering : l'émergence d'un nouveau métier data

Entre le data engineer qui pose les pipelines et le data analyst qui produit des dashboards, un troisième métier s'est imposé en 5 ans : l'analytics engineer. Outillé par dbt, il transforme la donnée brute en modèles métier exploitables, en appliquant les pratiques du génie logiciel (tests, versioning, CI/CD) au SQL. Voici ce que ce métier change concrètement, et comment dbt est devenu son outil de référence.

Le triangle data engineer / analytics engineer / data analyst

Rôle	Cœur de mission	Compétences clés	Livrables
Data Engineer	Pipelines, ingestion, plateforme	Spark, Kafka, Airflow, cloud	Pipelines fiables, raw layer
Analytics Engineer	Modélisation transformation, semantic layer	SQL, dbt, modélisation, tests	Tables métier, modèles dbt, KPIs
Data Analyst	Analyse, dashboards, recommandations	BI, statistiques, métier	Dashboards, études ad-hoc

L'analytics engineer fait le chaînon manquant : il prend la donnée brute des ingestions et produit des assets métier réutilisables, documentés, testés, sur lesquels les analystes branchent leur BI.

dbt en bref

dbt (data build tool) est un framework SQL-centric qui transforme la donnée dans le warehouse (Snowflake, BigQuery, Databricks, Redshift, Postgres, DuckDB…). Son apport :

• SQL + Jinja : modèles SQL paramétrables.
• Lineage automatique entre modèles.
• Tests déclaratifs (unicité, non-null, valeurs autorisées, custom).
• Documentation auto-générée + glossaire métier.
• Versioning Git natif des transformations.
• CI/CD : tests sur PR, build incrémental.
• Macros réutilisables (DRY pour SQL).
• Materializations : view, table, incremental, ephemeral, snapshot.

Pourquoi dbt s'est imposé

Avant dbt, la couche transformation reposait sur des stored procs, des notebooks ou des scripts SQL versionnés à la main. dbt apporte :

• Pratiques de génie logiciel au SQL : pull requests, tests automatiques, builds reproductibles.
• Modèle d'organisation : staging → intermediate → marts → exposures.
• Couplage faible au moteur : un même projet dbt tourne sur plusieurs warehouses.
• Communauté énorme : packages, conventions, formations, contenus.
• Démocratisation : un analyst senior peut produire des modèles propres sans devenir data engineer.

dbt Cloud vs dbt Core

Dimension	dbt Core (open source)	dbt Cloud (SaaS)
Licence	Apache 2.0, gratuit	Plans payants par seat
Exécution	CLI sur infra perso (Airflow, Dagster, GitHub Actions)	Hébergé, scheduler intégré
IDE	Local (VS Code + extension)	IDE web intégré, lineage visuel
Orchestration	À votre charge	Jobs natifs, alerting
CI/CD	À assembler	Intégré (Slim CI, PR previews)
Semantic Layer	Métriques en config	MetricFlow + API queryable
Gouvernance	À construire	Catalog dbt Explorer, mesh entre projets
Quand le choisir	Équipe outillée, infra existante	Vélocité, scale, gouvernance multi-équipes

Le Semantic Layer : pourquoi c'est central

Le semantic layer dbt (powered by MetricFlow) résout un problème classique : chaque équipe redéfinit "chiffre d'affaires net" avec sa propre formule. Le semantic layer permet de :

• Déclarer des métriques une seule fois (revenue, retention rate, NPS).
• Servir ces métriques via une API consommée par Looker, Tableau, Power BI, Hex, Mode.
• Garantir que toutes les couches consommatrices voient les mêmes chiffres.
• Versionner et tester les définitions de métriques comme du code.

Voir Data Contracts pour fiabiliser les inputs amont.

Modèle de delivery analytics engineering

Organisation du projet dbt

• Staging : un modèle par source, renommage, typage, cleaning de base.
• Intermediate : jointures et logiques métiers intermédiaires.
• Marts : tables exposées aux consommateurs (par domaine : finance, marketing, produit).
• Exposures : déclaration des dashboards et outils aval pour le lineage end-to-end.

Cycle de delivery type

1. Ticket métier → backlog analytics engineering.
2. Spec : métrique attendue, granularité, dimensions, SLA fraîcheur.
3. Modélisation : staging → intermediate → mart.
4. Tests : unicité PK, valeurs autorisées, cohérence métier.
5. PR + revue : CI dbt build + tests.
6. Merge : déploiement automatique en prod (build incrémental).
7. Documentation : descriptions champs, lineage, glossaire.
8. Exposition : dashboard Tableau / Power BI / Looker branché.

Bonnes pratiques

• DRY via macros et packages.
• Conventions de nommage strictes (fact_, dim_, stg_, int_).
• Tests systématiques (unicité, complétude, ranges).
• Documentation comme code (descriptions versionnées).
• Slim CI : ne reconstruire que ce qui a changé.
• dbt Mesh pour des projets multi-équipes (cas Data Mesh).

Voir Data Mesh en pratique.

Écosystème complémentaire

Catégorie	Outils typiques
Orchestration	Airflow, Dagster, Prefect, dbt Cloud Scheduler
Ingestion	Fivetran, Airbyte, Meltano, Stitch
Warehouse	Snowflake, BigQuery, Databricks, Redshift, DuckDB
Data quality	dbt tests, Great Expectations, Soda, Elementary
Observability	Monte Carlo, Bigeye, Metaplane, Elementary
BI	Looker, Tableau, Power BI, Hex, Mode, Lightdash
Reverse ETL	Hightouch, Census

Voir Data observability et Reverse ETL & operational analytics.

Profil analytics engineer : compétences et TJM

Compétences attendues :

• SQL avancé (window functions, CTE, performance, dialectes).
• dbt (Core + Cloud), Jinja, packages, macros.
• Modélisation dimensionnelle (Kimball, Data Vault si pertinent).
• Git / CI/CD appliqué au data.
• Communication métier : capacité à challenger les besoins et à vulgariser.
• BI : connaissance d'au moins un outil consommateur.
• Plus : Python pour scripts d'appui, semantic layer, MetricFlow.

Indicateurs TJM marché :

Profil	TJM EUR/jour
Junior analytics engineer (1-2 ans)	450–550 €/jr
Confirmé (3-5 ans, dbt en prod)	550–700 €/jr
Senior (architecte transformation, semantic layer)	700–850 €/jr

Voir TJM consultant IT.

Conclusion : analytics engineering, le métier qui fiabilise la couche métier

L'analytics engineer est le métier qui transforme un warehouse en plateforme de décision fiable. dbt en est l'outil central, le semantic layer la pièce qui fait converger les définitions métiers. Les organisations qui investissent dans ce rôle constatent une accélération nette des projets BI et ML — celles qui s'en passent continuent de débugger des chiffres incohérents sur les comités exécutifs.

Pour aller plus loin :

• Data Mesh en pratique
• Data Contracts
• Data observability
• Reverse ETL & operational analytics

ForTeam IT positionne des analytics engineers et data leads capables de poser une couche dbt propre, un semantic layer, et de structurer la transformation data. Si c'est votre terrain, vous êtes au bon endroit.

Rejoindre ForTeam IT