Comment concevez-vous un pipeline de données fiable et scalable ?

Je commence par comprendre le SLA : à quelle fraîcheur les données doivent-elles être, et quel est le coût d'une défaillance du pipeline en aval ? Ces deux réponses orientent chaque décision d'architecture. Pour la fiabilité, je construis des pipelines idempotents dans la mesure du possible, afin que la réexécution d'un job après une défaillance produise le même résultat sans dupliquer les données. J'utilise des checkpoints pour les jobs de longue durée afin que les défaillances ne redémarrent pas depuis le début. J'ajoute des contrôles de qualité des données à chaque étape : validation du schéma à l'ingestion, vérifications du nombre de lignes entre les étapes, et détection d'anomalies sur les métriques clés en sortie. Pour la scalabilité, je sépare le calcul du stockage afin de les scaler indépendamment, et je conçois pour un traitement incrémental plutôt que des rechargements complets. L'observabilité est intégrée dès le début : chaque pipeline émet des métadonnées d'exécution.

Comment gérez-vous les problèmes de qualité des données dans vos pipelines ?

La qualité des données n'est pas une préoccupation séparée de la conception du pipeline ; elle en fait partie. Mon approche comporte trois couches. D'abord, la validation du schéma et des types à l'ingestion : si les données amont changent de forme de manière inattendue, je veux que le pipeline échoue bruyamment au point d'entrée plutôt que de propager silencieusement de mauvaises données. Ensuite, des vérifications de règles métier entre les étapes : des nombres de lignes qui diffèrent significativement de l'exécution précédente, des taux de null au-dessus d'un seuil dans les champs obligatoires, ou des échecs d'intégrité référentielle. Enfin, la surveillance en sortie : je suis les métriques métier clés dans le temps et alerte lorsqu'elles sortent des plages attendues. Lorsqu'un problème de qualité est détecté, je préfère mettre en quarantaine les enregistrements affectés et continuer à traiter les données propres plutôt que d'arrêter l'ensemble du pipeline.

Comment choisissez-vous entre le traitement par lots et le streaming ?

Je commence par l'exigence métier, pas par la technologie. La question clé est : quelle est la latence maximale acceptable entre un événement et sa disponibilité pour l'analyse ? Si la réponse est des heures ou des jours, le traitement par lots est presque toujours plus simple et rentable. Si la réponse est des minutes ou des secondes, le streaming devient nécessaire. Au-delà de la latence, je considère la complexité opérationnelle : les systèmes de streaming sont significativement plus difficiles à déboguer, rejouer et maintenir que les jobs batch. Pour la plupart des cas analytiques que j'ai traités, le micro-batch (exécution toutes les quelques minutes avec Spark Structured Streaming ou Flink) offre une latence acceptable à un coût opérationnel bien inférieur. Je ne m'engage dans une vraie architecture streaming que lorsque l'exigence de latence ne peut genuinement pas être satisfaite par le micro-batch.

Comment utilisez-vous les outils d'IA et de ML dans votre travail d'ingénierie data ?

Les outils d'IA ont changé quelques aspects de mon flux de travail de manière pratique. Pour l'écriture et la révision de SQL, notamment les fonctions de fenêtre complexes ou les requêtes d'optimisation, l'IA m'aide à itérer plus rapidement et détecte des patterns que je pourrais manquer. Pour la rédaction de la documentation des pipelines et des entrées du dictionnaire de données, l'IA rédige un contenu que je révise et ajuste ensuite. Là où l'IA est devenue genuinement utile, c'est dans la détection d'anomalies sur les sorties des pipelines : plutôt que d'écrire des règles de seuil codées en dur, je peux utiliser des modèles statistiques pour signaler qu'une métrique se comporte de manière inhabituelle. Je fais attention à utiliser l'IA pour la conception de schémas ou les décisions de modélisation des données, car ces décisions ont des conséquences à long terme et le modèle n'a pas le contexte métier complet.

Parlez-moi d'une fois où une défaillance de pipeline a affecté des équipes en aval.

Un job ETL quotidien qui alimentait notre modèle d'attribution marketing a échoué silencieusement : il s'est terminé sans erreurs mais a produit un résultat partiel à cause d'un timeout sur l'un des appels API sources. L'équipe marketing a réalisé son analyse hebdomadaire des dépenses sur des données incomplètes et a détecté la discordance elle-même deux jours plus tard. Quand le problème a été remonté, j'ai diagnostiqué la cause racine en environ une heure : le timeout de l'API était trop bas et le job n'avait pas de validation du nombre d'enregistrements à la fin. J'ai corrigé le problème immédiat en augmentant le timeout et en réexécutant la plage de dates affectée. Ensuite j'ai ajouté une vérification du nombre de lignes en étape finale et une alerte qui se déclenche si le nombre de lignes de sortie tombe en dessous de 90 % de la moyenne sur sept jours. La partie la plus difficile a été de reconstruire la confiance avec l'équipe marketing.

Décrivez une migration de données complexe que vous avez dirigée.

Nous avons migré notre base de données transactionnelle principale d'un schéma Postgres monolithique vers un nouveau schéma supportant la multi-location, tout en maintenant le système en production. Le défi était que nos pipelines analytics, nos outils de reporting et trois microservices en aval dépendaient tous de l'ancien schéma. Mon approche a été d'exécuter les anciens et nouveaux schémas en parallèle pendant six semaines, en écrivant dans les deux et en lisant depuis l'ancien pendant que le nouveau était validé. J'ai construit un job de réconciliation qui tournait chaque nuit et comparait les nombres de lignes et les agrégats clés entre les deux schémas. La migration de chaque consommateur a été faite de manière incrémentale : analytics en premier (risque le plus faible), puis le reporting, puis les microservices. La migration complète a pris dix semaines sans perte de données ni temps d'arrêt.

Donnez un exemple d'amélioration significative de la performance d'un pipeline existant.

Un job Spark nocturne qui agrégeait des données d'activité utilisateur prenait six heures, empiétant sur les heures de bureau et retardant les tableaux de bord dont l'équipe produit dépendait. J'ai profilé le job et trouvé trois problèmes : une jointure lourde en shuffle qui ne tirait pas parti des broadcast joins pour une petite table de lookup, un scan complet de table sur une table partitionnée car le filtre de partition était appliqué après le scan, et une étape de sortie qui écrivait des milliers de petits fichiers. J'ai remplacé la jointure par un broadcast join (la table de lookup faisait moins de 100 Mo), poussé le filtre de partition dans l'étape de lecture, et coalescé la sortie. Le temps d'exécution est passé de six heures à moins de 45 minutes. La correction du filtre de partition a contribué à l'essentiel du gain, réduisant les données scannées à environ 3 % de la table complète.

Quelle est la différence entre un data warehouse et un data lake, et quand utiliser chacun ?

Un data warehouse stocke des données structurées et traitées, optimisées pour les requêtes analytiques. Il applique le schéma à l'écriture, ce qui signifie que les données sont transformées et validées avant d'entrer dans le warehouse. Un data lake stocke les données brutes dans leur format d'origine, structuré ou non, et applique le schéma à la lecture. Il est moins coûteux pour stocker de grands volumes et plus flexible pour l'analyse exploratoire ou les cas d'usage ML. La réponse pratique : la plupart des organisations ont besoin des deux. Le data lake contient les données brutes et intermédiaires ; le data warehouse contient les données curées, prêtes pour les analyses. Le pattern que j'ai le plus utilisé est l'architecture medallion (couches raw, clean, curated) où la couche curated est le warehouse et les couches précédentes vivent dans le stockage objet.

Comment abordez-vous la modélisation des données pour un cas d'usage analytique ?

Je commence par comprendre qui va interroger ces données et comment. Les analystes et les outils BI veulent généralement des tables larges et dénormalisées, faciles à joindre et rapides à interroger. Les data scientists veulent souvent accéder à des tables plus granulaires. Pour la plupart des cas analytiques j'utilise un modèle dimensionnel (tables de faits et de dimensions) car il est bien compris, performant avec le stockage colonnaire, et facilite l'ajout de nouvelles dimensions sans casser les requêtes existantes. J'évite les schémas fortement normalisés dans la couche analytique car le coût des jointures ajoute de la complexité pour les analystes. Je réfléchis aussi aux dimensions à variation lente dès le début : si un client change de segment, les requêtes veulent-elles voir dans quel segment il était au moment de l'événement, ou son segment actuel ? Cette décision doit être prise au moment de la modélisation.

Expliquez-moi comment vous construiriez un pipeline analytique en temps réel de zéro.

Je commencerais par remettre en question si cela doit vraiment être en temps réel. Si la réponse est oui, mon architecture aurait quatre couches. Ingestion : les événements circulent des systèmes sources vers une file de messages comme Kafka ou Pub/Sub, qui découple les producteurs des consommateurs et offre une capacité de replay. Traitement de stream : un job Flink ou Spark Structured Streaming lit depuis la file, applique des transformations et des agrégations, et écrit les résultats dans la couche de service. Service : un magasin analytique rapide comme ClickHouse, Druid ou BigQuery gère la charge de requêtes des tableaux de bord. Surveillance : le pipeline émet des métriques de lag et j'alerte si le lag dépasse la cible. Les parties sur lesquelles je passe le plus de temps en amont sont la conception du schéma au point d'ingestion et la décision exacte de l'état à maintenir dans le processeur de stream.

Ingénieur data

Les entretiens pour un poste d'ingénieur data évaluent votre capacité à concevoir des pipelines fiables, modéliser les données pour des cas d'usage analytiques et collaborer efficacement avec les équipes engineering et data science. Les recruteurs veulent voir que vous pensez à la qualité des données et aux modes de défaillance, pas seulement au débit, et que vous pouvez faire des compromis pragmatiques entre les approches techniques. Ce guide couvre les questions les plus fréquentes et les réponses qui font la différence.

Pour des conseils généraux de préparation aux entretiens, consultez notre guide sur les questions d'entretien courantes.

Questions d'entretien courantes pour Ingénieur data

Questions comportementales pour les postes Ingénieur data

Questions techniques pour les candidats Ingénieur data

Ce que les recruteurs recherchent pour un poste Ingénieur data

Ce que les recruteurs recherchent chez les candidats ingénieur data :

Des preuves que vous avez construit des pipelines qui ont échoué et récupéré. L'idempotence, le checkpointing et les contrôles de qualité des données signalent une vraie expérience en production.
La qualité des données comme préoccupation intégrée, pas une réflexion après coup. Les ingénieurs qui disent seulement "nous exécutons des tests" sont moins convaincants que ceux qui décrivent la validation à l'ingestion, à la transformation et en sortie.
Des choix technologiques pragmatiques. Les candidats solides expliquent pourquoi ils ont choisi le batch plutôt que le streaming, plutôt que d'opter par défaut pour l'option la plus récente.
La communication avec les consommateurs de données. Les ingénieurs data possèdent une infrastructure dont dépendent les autres. La capacité à expliquer une défaillance de pipeline à une partie prenante non technique compte autant que le correctif.
Des opinions sur la modélisation des données. Les recruteurs écoutent des termes comme la modélisation dimensionnelle et les dimensions à variation lente.

Questions à poser à votre interlocuteur

→À quoi ressemble la stack de données actuelle, et quels sont les plus grands manques ou points de douleur ?
→Comment la responsabilité de la qualité des données est-elle gérée : équipe ingénierie data, producteurs de données, ou partagée ?
→À quoi ressemble le processus d'astreinte ou de réponse aux incidents pour les pipelines de données ?
→Comment les data scientists et analystes consomment-ils les données ? Interrogent-ils directement le warehouse ou l'équipe construit-elle des produits data spécifiques ?
→Quel est le plus grand projet de migration ou de re-architecture de données dans la roadmap actuellement ?

Entrainez-vous sur ces questions avant votre entretien

Le simulateur d'entretien construit une session de pratique autour d'une offre d'emploi spécifique et de votre parcours, pour que vous répétiez les questions les plus susceptibles d'être posées.

Commencer l'entrainement

Gratuit pour commencer. Sans engagement.

Métiers similaires

Ingénieur Machine Learning

Tech9 questions