Top 25 Questions d'Entretien Data Engineering 2026 | SharpSkill

Les entretiens pour les postes de data engineer en 2026 dépassent largement les bases du SQL. Les recruteurs évaluent désormais la conception de systèmes distribués, les architectures temps réel, l'optimisation des coûts cloud et la préparation aux charges de travail IA. Ce guide présente les 25 questions les plus courantes posées lors des entretiens data engineering, des startups aux entreprises du FAANG, avec des réponses concrètes destinées aux praticiens.

Ce que les recruteurs évaluent réellement

Les entretiens modernes en data engineering privilégient la résolution de problèmes plutôt que la mémorisation des outils. Les questions portent sur les arbitrages techniques (batch vs streaming, schéma en étoile vs flocon), pas uniquement sur la syntaxe. Démontrer un raisonnement clair compte davantage qu'une réponse parfaite.

Questions SQL et Optimisation de Requêtes

Quelle est la différence entre une fonction fenêtre et GROUP BY ?

Les fonctions fenêtres (window functions) calculent des agrégations tout en conservant toutes les lignes de la table d'origine, contrairement à GROUP BY qui réduit le résultat à une ligne par groupe. Cette distinction devient critique lors de l'analyse de séries temporelles ou du calcul de moyennes mobiles.

sql

-- GROUP BY: one row per department
SELECT department, AVG(salary) AS avg_salary
FROM employees
GROUP BY department;

-- Window function: every row preserved, avg added
SELECT
  employee_id,
  department,
  salary,
  AVG(salary) OVER (PARTITION BY department) AS dept_avg
FROM employees;

Les fonctions fenêtres permettent également des opérations complexes comme ROW_NUMBER(), LEAD(), LAG(), et le calcul de percentiles sans sous-requêtes. Elles s'avèrent particulièrement utiles pour les rapports analytiques nécessitant à la fois des détails granulaires et des métriques agrégées.

Comment optimiser une requête sur une table de faits de 500 millions de lignes ?

L'optimisation commence par l'analyse du plan d'exécution. Les techniques prioritaires incluent : partitionnement par date ou région géographique, indexation des colonnes utilisées dans les clauses WHERE et JOIN, utilisation de colonnes calculées matérialisées pour les agrégations fréquentes, et compression des données au niveau du stockage. Pour les entrepôts cloud comme BigQuery ou Snowflake, le clustering des tables selon les colonnes de filtrage réduit drastiquement la quantité de données scannées.

Le choix du format de stockage joue également un rôle majeur. Les formats columnaires comme Parquet ou ORC offrent une compression supérieure et permettent le predicate pushdown, tandis que les statistiques au niveau des fichiers (min/max, bloom filters) éliminent les lectures inutiles avant même l'exécution de la requête.

CTE, sous-requêtes ou tables temporaires : quel choix faire ?

Les Common Table Expressions (CTE) améliorent la lisibilité et facilitent la maintenance du code, mais ne garantissent pas de gains de performance. Les optimiseurs modernes matérialisent les CTE uniquement lorsque c'est nécessaire. Les sous-requêtes corrélées dans les clauses WHERE provoquent souvent des scans complets de table et doivent être évitées au profit de JOIN.

Les tables temporaires s'imposent lorsque le résultat intermédiaire est réutilisé plusieurs fois dans la même session ou lorsque la création d'index temporaires accélère les jointures suivantes. Pour plus de détails sur les patterns SQL avancés, consultez cet article sur les window functions et CTEs.

ETL vs ELT et Architecture des Pipelines de Données

ETL ou ELT : quelle approche choisir ?

La différence fondamentale réside dans le lieu de transformation des données. L'ETL (Extract-Transform-Load) transforme les données avant leur chargement dans l'entrepôt, tandis que l'ELT (Extract-Load-Transform) charge d'abord les données brutes puis effectue les transformations directement dans l'entrepôt.

| Critère | ETL | ELT | |---------|-----|-----| | Puissance de calcul | Serveur ETL dédié | Entrepôt cloud élastique | | Coût | Infrastructure fixe | Pay-per-query | | Flexibilité | Schéma défini à l'avance | Schéma on-read | | Cas d'usage | Transformations complexes, données sensibles | Data lakes, analyse exploratoire | | Latence | Peut être plus longue | Dépend de la puissance de l'entrepôt |

Les architectures modernes combinent souvent les deux approches : ELT pour les données volumineuses et l'analyse exploratoire, ETL pour les transformations métier complexes nécessitant une logique applicative. Pour approfondir les patterns ETL/ELT, voir cette ressource sur les patterns ETL/ELT.

Comment concevoir un pipeline de données idempotent ?

Un pipeline idempotent produit le même résultat qu'il soit exécuté une ou plusieurs fois. Cette propriété est essentielle pour gérer les réexécutions après échec sans dupliquer les données.

python

# partition_overwrite.py
# Idempotent write: overwrite the entire partition for a given date
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("idempotent_load").getOrCreate()

df = spark.read.parquet("s3://raw-events/2026-04-11/")

# Transform: deduplicate by event_id, keep latest
df_deduped = (
    df.orderBy("event_timestamp", ascending=False)
    .dropDuplicates(["event_id"])
)

# Overwrite only the target partition
df_deduped.write \
    .mode("overwrite") \
    .partitionBy("event_date") \
    .parquet("s3://warehouse/events/")

Les techniques clés incluent : écrasement de partition complète (pas d'append), déduplication par identifiant unique, utilisation de timestamps de traitement pour gérer les arrivées tardives, et transactions ACID lorsque disponibles (Delta Lake, Iceberg). Le partitionnement temporel garantit que seules les données affectées sont réécrites.

Qu'est-ce que la data lineage et pourquoi est-elle importante ?

La data lineage trace l'origine, les transformations et la destination des données à travers le pipeline. Elle répond aux questions : d'où viennent ces données ? Quelles transformations ont été appliquées ? Quels systèmes dépendent de cette table ?

En pratique, la lineage facilite le débogage (identifier la source d'une anomalie), assure la conformité réglementaire (RGPD, audits), et permet l'analyse d'impact avant modification d'un schéma. Les outils comme DataHub, Marquez ou les solutions intégrées des plateformes cloud (AWS Glue Data Catalog, GCP Dataplex) automatisent la collecte et la visualisation de la lineage.

Streaming et Traitement de Données en Temps Réel

Batch ou streaming : comment choisir ?

Le choix dépend de trois facteurs : latence requise, complexité du traitement, et coût opérationnel. Le batch processing convient lorsque les rapports quotidiens ou horaires suffisent, que les transformations nécessitent des jointures complexes avec données historiques, ou que le volume justifie l'optimisation des ressources par lots.

Le streaming s'impose pour les cas d'usage nécessitant une latence inférieure à la minute : détection de fraude, recommandations personnalisées en temps réel, monitoring d'infrastructure, ou alertes opérationnelles. Le coût du streaming reste généralement supérieur en raison de l'infrastructure permanente requise (Kafka clusters, Flink jobs).

Expliquez l'architecture de Kafka et ses garanties de livraison

Kafka repose sur un système de logs distribués partitionnés. Les producteurs écrivent dans des topics partitionnés, les consommateurs lisent depuis des offsets qu'ils gèrent. Les partitions permettent la parallélisation tout en garantissant l'ordre des messages au sein d'une même partition.

Les garanties de livraison dépendent de la configuration : at-most-once (acks=0, pas de retry), at-least-once (acks=1 ou all, avec retries, risque de duplicatas), exactly-once (transactions Kafka, idempotence activée). L'exactly-once sémantique nécessite enable.idempotence=true côté producteur et isolation=read_committed côté consommateur.

La réplication entre brokers assure la durabilité : avec min.insync.replicas=2 et acks=all, Kafka garantit que deux réplicas ont confirmé l'écriture avant d'accuser réception au producteur. Les consumer groups permettent le scaling horizontal de la consommation.

Comment gérer les événements arrivant en retard (late-arriving data) ?

Les architectures de streaming définissent des fenêtres temporelles (tumbling, sliding, session windows) et doivent gérer les événements dont l'event_time est antérieur à la watermark. Les stratégies incluent : watermarks configurables autorisant un délai maximal (ex: 1 heure), fenêtres avec late firing déclenchées après la fermeture initiale, et tables de side outputs capturant les événements trop tardifs pour analyse séparée.

Apache Flink et Spark Structured Streaming offrent des mécanismes natifs de gestion des retards via watermarks et allowed lateness. Pour les cas extrêmes, une architecture lambda combine batch et streaming : le layer streaming fournit les résultats rapides mais approximatifs, tandis que le layer batch recalcule les agrégations complètes quotidiennement.

Modélisation de Données et Conception de Schémas

Schéma en étoile vs flocon de neige : avantages et inconvénients

| Aspect | Étoile (Star) | Flocon de neige (Snowflake) | |--------|---------------|-----------------------------| | Structure | Table de faits + dimensions dénormalisées | Dimensions normalisées (3NF) | | Performance | Jointures simples, requêtes rapides | Jointures multiples, plus lentes | | Stockage | Redondance dans dimensions | Optimisé, moins de duplication | | Maintenance | Mises à jour complexes | Mises à jour simplifiées | | Cas d'usage | Analyse OLAP, dashboards | Environnements storage-constrained |

Les entrepôts cloud modernes (BigQuery, Redshift, Snowflake) privilégient les schémas en étoile car le coût de stockage diminue tandis que la puissance de calcul augmente. La dénormalisation améliore drastiquement les performances des requêtes analytiques. Pour approfondir la modélisation, consultez les questions sur la modélisation de données.

Quels sont les types de Slowly Changing Dimensions (SCD) ?

Les SCD gèrent l'évolution des dimensions dans le temps. Type 1 : écrasement de l'ancienne valeur (pas d'historique). Type 2 : ajout d'une nouvelle ligne avec timestamps de validité et flag current (historique complet). Type 3 : ajout d'une colonne previous_value (historique limité). Type 4 : table séparée pour l'historique (mini-dimension).

Le Type 2 reste le plus courant pour les entrepôts analytiques car il permet de répondre à des questions temporelles ("quel était le département de cet employé en janvier 2025 ?"). L'implémentation nécessite des colonnes effective_date, end_date et is_current, ainsi qu'une logique de pipeline gérant les mises à jour via MERGE ou upsert.

Comment modéliser des données d'événements pour l'analyse temps réel et le stockage long terme ?

Une architecture efficace sépare le hot path (streaming) du cold path (batch). Les événements bruts arrivent dans Kafka, sont traités par Flink ou Spark Streaming pour des agrégations en temps réel (compteurs, fenêtres glissantes), puis écrits dans un data lake (S3, ADLS) au format Parquet partitionné par date.

Le schéma doit inclure : event_id (UUID), event_type, event_timestamp (ISO 8601), user_id, session_id, et payload JSON flexible pour gérer l'évolution du schéma. Les agrégations temps réel alimentent des tables OLAP dénormalisées, tandis que les événements bruts restent disponibles pour reprocessing ou analyses exploratoires futures.

Apache Spark et Traitement Distribué

Comment résoudre un problème de data skew dans Spark ?

Le data skew survient lorsque certaines partitions contiennent beaucoup plus de données que d'autres, créant des tasks longs qui ralentissent l'ensemble du job. Les symptômes incluent : quelques tasks prenant 10x plus de temps, OutOfMemory errors sur certains executors, et faible utilisation du cluster.

La technique du salting résout ce problème en distribuant artificiellement les clés déséquilibrées.

python

# salting_technique.py
# Fix skewed join by salting the large table's key
from pyspark.sql import functions as F

SALT_BUCKETS = 10

# Add salt to the large (skewed) table
large_df = large_df.withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), (F.rand() * SALT_BUCKETS).cast("int"))
)

# Explode the small table to match all salt values
small_df = small_df.crossJoin(
    spark.range(SALT_BUCKETS).withColumnRenamed("id", "salt")
).withColumn(
    "salted_key",
    F.concat(F.col("join_key"), F.lit("_"), F.col("salt"))
).drop("salt")

# Join on salted key (evenly distributed)
result = large_df.join(small_df, "salted_key")

D'autres approches incluent : broadcast join pour les petites tables (moins de 10MB), adaptive query execution (AQE) de Spark 3.x qui ajuste automatiquement le nombre de partitions, et isolation des clés problématiques pour traitement séparé.

Transformations vs actions dans Spark : quelle différence ?

Les transformations (map, filter, groupBy, join) sont lazy : elles construisent un DAG d'exécution sans traiter les données immédiatement. Les actions (count, collect, write) déclenchent l'exécution du DAG. Cette distinction permet à Spark d'optimiser l'ensemble du plan avant exécution (predicate pushdown, projection pruning).

Comprendre cette différence évite les erreurs courantes : appeler collect() sur un large DataFrame provoque un OutOfMemory, tandis que count() après de multiples transformations sans cache force le recalcul complet à chaque action. L'utilisation judicieuse de cache() ou persist() pour les DataFrames réutilisés améliore significativement les performances.

Repartition vs coalesce : quand utiliser chacun ?

Repartition() effectue un shuffle complet pour redistribuer les données uniformément selon le nombre de partitions spécifié ou les colonnes de partitionnement. Coalesce() réduit le nombre de partitions sans shuffle en combinant les partitions existantes. Repartition s'utilise pour augmenter le parallélisme avant des opérations coûteuses ou pour redistribuer après un filtre agressif. Coalesce optimise l'écriture de fichiers en réduisant le nombre de small files sans coût de shuffle.

Exemple : après un filtre réduisant les données de 90%, coalesce(10) évite d'écrire des centaines de petits fichiers Parquet. Avant un join complexe, repartition(200, "join_key") assure une distribution équilibrée.

Orchestration et Gestion de Pipelines

Airflow, Dagster ou Prefect : comment choisir ?

| Outil | Forces | Faiblesses | Cas d'usage idéal | |-------|--------|------------|------------------| | Airflow | Écosystème mature, nombreux operators, communauté large | Code-as-config verbeux, UI limitée | Pipelines batch complexes, intégrations multiples | | Dagster | Software-defined assets, typing fort, excellente observabilité | Courbe d'apprentissage, écosystème plus jeune | Data lakes modernes, équipes Python expertes | | Prefect | API pythonique, hybrid execution, excellent local dev | Moins d'intégrations natives | Workflows dynamiques, équipes ML/data science |

Airflow domine les environnements d'entreprise nécessitant des intégrations avec de nombreux systèmes legacy. Dagster excelle pour les architectures data lakes modernes avec focus sur la qualité des données. Prefect convient aux équipes privilégiant l'expérience développeur et les workflows ML. Pour maîtriser Airflow, voir les fondamentaux d'Airflow.

Comment gérer les échecs de pipeline en production ?

Une stratégie de gestion d'échecs robuste combine : retry automatiques avec backoff exponentiel pour les erreurs transitoires (timeouts réseau, throttling API), alertes différenciées selon la sévérité (Slack pour warnings, PagerDuty pour critical), mécanismes de circuit breaker pour éviter la surcharge de systèmes downstream, et logging structuré pour faciliter le débogage.

Les pipelines critiques nécessitent des SLO (Service Level Objectives) définis : latence maximale, freshness des données, taux d'erreur acceptable. Les dead letter queues capturent les messages non traitables pour investigation manuelle. L'idempotence permet les réexécutions sans effets de bord.

Quels indicateurs définissent un pipeline production-ready ?

Un pipeline prêt pour la production répond à ces critères : tests unitaires et d'intégration couvrant les cas limites, monitoring avec métriques exposées (records processed, duration, error rate), documentation incluant runbook pour incidents, idempotence garantie, gestion des secrets via vault, versioning du code et des schémas, backfill capability pour reprocessing historique, et data quality checks automatisés.

La CI/CD doit valider le DAG avant déploiement, exécuter des tests sur données sample, et permettre rollback rapide. Les SLA de freshness déclenchent des alertes si le pipeline tarde. L'observabilité inclut data lineage, métriques de volumétrie, et profiling automatique des nouvelles données.

Plateformes Cloud et Architecture Lakehouse

Qu'est-ce qu'une architecture lakehouse et pourquoi est-elle importante ?

Le lakehouse combine les avantages du data lake (stockage économique, formats ouverts, schéma flexible) et de l'entrepôt de données (transactions ACID, performances de requête, gouvernance). Les technologies comme Delta Lake, Apache Iceberg ou Apache Hudi ajoutent une couche transactionnelle au-dessus du stockage objet (S3, ADLS).

Cette architecture élimine la duplication entre lake et warehouse, réduit la latence des pipelines ELT, permet le time travel et le rollback des données, et supporte à la fois les workloads BI et machine learning sur les mêmes données. Les métadonnées de table gèrent le versioning, les statistiques de colonnes accélèrent les requêtes, et les transactions ACID garantissent la cohérence lors d'écritures concurrentes.

Comment optimiser les coûts sur un entrepôt cloud ?

L'optimisation des coûts cloud combine plusieurs leviers : clustering et partitionnement des tables selon les patterns de requêtes pour réduire le scan, cache de résultats pour éviter les retraitements identiques, compression aggressive avec formats columnaires (Parquet, ORC), archivage des données anciennes vers stockage froid (S3 Glacier, Azure Archive), et dimensionnement approprié des warehouses (scaling horizontal plutôt que vertical).

BigQuery facture au volume scanné : projeter uniquement les colonnes nécessaires réduit drastiquement les coûts. Snowflake facture le compute-time : arrêter les warehouses inutilisés et utiliser l'auto-suspend. Les requêtes récurrentes bénéficient de vues matérialisées. Le monitoring des requêtes les plus coûteuses via les query logs identifie les optimisations prioritaires.

Prêt à réussir tes entretiens Data Engineering ?

Entraîne-toi avec nos simulateurs interactifs, fiches express et tests techniques.

Explorer Data Engineering

Qualité des Données et Gouvernance

Comment implémenter des contrôles de qualité des données ?

Les data quality checks s'appliquent à trois niveaux du pipeline. À l'ingestion : validation du schéma (types, colonnes requises), contrôle des valeurs nulles, détection d'anomalies statistiques (écart-type, percentiles). Pendant la transformation : checks d'intégrité référentielle, contraintes métier (montant > 0, date cohérente), et reconciliation des volumes (input count = output count après déduplication).

Après chargement : comparaison avec données précédentes (variation brutale du volume ?), freshness monitoring (dernière mise à jour < SLA ?), et profiling automatique pour détecter les dérives de distribution. Les frameworks comme Great Expectations, deequ ou dbt tests automatisent ces contrôles et génèrent des rapports de qualité.

Qu'est-ce qu'un data contract et pourquoi en utiliser ?

Un data contract est un accord formel entre producteur et consommateur de données définissant : schéma (colonnes, types, contraintes), SLA de disponibilité et fraîcheur, sémantique métier (définitions des champs), versioning et rétrocompatibilité, et ownership (équipe responsable).

Les contracts préviennent les breaking changes silencieux, clarifient les responsabilités lors d'incidents, et facilitent la découverte de données. Ils se matérialisent via des fichiers YAML versionnés, validation automatique dans la CI, et enforcement au runtime. Les violations déclenchent des alertes avant impact sur les consommateurs downstream.

Conception de Systèmes et Architecture

Concevez un pipeline analytics temps réel pour 100K événements/seconde

L'architecture type comprend : couche ingestion (Kafka avec partitions multiples pour throughput, retention 7 jours), stream processing (Flink ou Spark Streaming avec état distribué pour agrégations, windowing de 1 minute), stockage OLAP (Druid, ClickHouse ou Pinot pour requêtes sub-seconde sur données récentes), et archivage (S3 Parquet partitionné par heure pour analyse historique).

Le dimensionnement : Kafka avec 20 partitions assure 100K events/sec (5K par partition), Flink avec parallélisme de 40 et checkpointing chaque minute, cluster Druid avec segments optimisés pour requêtes temporelles. Le monitoring inclut lag de consommation, latence end-to-end (event timestamp → disponibilité dashboard), et métriques de backpressure.

Comment migrer un système legacy vers une architecture moderne sans interruption ?

Le pattern strangler fig permet une migration progressive. Phase 1 : dual writes (nouveau système en parallèle, ancien système fait autorité). Phase 2 : mirror traffic (validation que nouveau système produit résultats identiques). Phase 3 : bascule progressive des consommateurs (feature flags par équipe). Phase 4 : décommission de l'ancien système.

Les étapes critiques incluent : identification des dépendances via lineage, tests de charge du nouveau système, stratégie de rollback rapide, et data reconciliation continue entre ancien et nouveau. La migration des données historiques peut utiliser du backfill parallèle. La communication fréquente avec les stakeholders évite les surprises.

Un dashboard affiche des chiffres incorrects : comment déboguer ?

La méthodologie systématique : identifier le périmètre (une métrique ou toutes ? Une période ou tout l'historique ?), comparer avec les données source (requête manuelle sur la table finale), vérifier la data lineage (quelle transformation produit cette table ?), isoler la transformation problématique (tests unitaires sur échantillon), et valider la logique métier (agrégation correcte ? Filtres appropriés ?).

Les causes courantes incluent : duplicatas dans les jointures (missing DISTINCT), fuseaux horaires incohérents, conversions de devises obsolètes, filtres appliqués au mauvais niveau (WHERE vs HAVING), et refresh incomplet des vues matérialisées. Les logs de pipeline et métriques de volumétrie accélèrent le diagnostic.

Préparation à l'Entretien Data Engineering

La maîtrise technique ne suffit pas : les entretiens évaluent également la communication et le raisonnement. Lors de questions de conception système, commencer par clarifier les contraintes (volume de données, latence requise, budget), proposer plusieurs approches avec leurs trade-offs, puis approfondir la solution retenue.

Pour les questions de code, penser à voix haute : expliquer l'approche avant d'implémenter, discuter la complexité temporelle et spatiale, évoquer les cas limites. Les questions comportementales ("décrivez un incident de production difficile") doivent suivre le framework STAR (Situation, Task, Action, Result).

La préparation structurée via la track data engineering couvre l'ensemble des sujets techniques avec des exercices pratiques. Les mock interviews permettent de s'entraîner à la gestion du temps et au stress. Réviser les fondamentaux (SQL, Python, systèmes distribués) reste prioritaire par rapport à l'apprentissage de nouveaux frameworks.

Conclusion

Les entretiens data engineering en 2026 évaluent des compétences multiples : maîtrise SQL et optimisation de requêtes, conception de pipelines batch et streaming, architecture de systèmes distribués, qualité et gouvernance des données, et optimisation des coûts cloud. Les questions techniques se combinent avec l'évaluation de la capacité à raisonner sur des trade-offs et communiquer clairement.

Les points clés à retenir :

SQL avancé : fonctions fenêtres, optimisation via partitionnement et indexation, choix entre CTE et tables temporaires
Pipelines : idempotence, ELT vs ETL selon le contexte, data lineage pour observabilité
Streaming : comprendre Kafka et ses garanties, gérer les late-arriving data, arbitrage batch vs temps réel
Modélisation : schémas star pour performance OLAP, SCD Type 2 pour historique, séparation hot/cold path
Spark : résolution de data skew via salting, compréhension transformations lazy, repartition stratégique
Orchestration : choix d'outil selon le contexte, gestion robuste des échecs, définition de SLO
Cloud : architecture lakehouse pour unifier analytics et ML, optimisation continue des coûts
Qualité : checks à 3 niveaux (ingestion, transformation, post-load), data contracts pour gouvernance
Système : conception scalable, migration progressive, débogage méthodique

La préparation efficace combine révision théorique, pratique sur projets réels ou datasets publics, et simulation d'entretiens. Les recruteurs valorisent les candidats capables d'expliquer leurs choix techniques, d'identifier les limites de leurs solutions, et de s'adapter aux contraintes métier.