Le data quality engineer code la qualité des données au lieu de la constater après coup. Il profile les sources, écrit des tests en SQL ou en Python avec Great Expectations, Soda ou les tests dbt, vérifie qu'une modification de calcul ne casse rien et rapproche les chiffres de l'entrepôt de ceux de l'ERP. Les offres le rangent tantôt du côté data engineering, tantôt dans une équipe gouvernance. Côté recrutement, cherchez un ingénieur qui écrit du code et sait définir une donnée valide avec le métier.
Le poste voisine avec celui de DataOps engineer, qui garantit la fraîcheur des tables, route les alertes et mène les incidents. Ici, la question est en amont : quelle règle écrire, sur quelle colonne, avec quel seuil, et que faire des lignes qui échouent. Un CV qui cite trois outils de tests ne dit pas si la personne sait choisir ce qu'elle teste.
Un exercice simple : faire choisir au candidat trois règles de qualité sur une table de commandes qu'il découvre, avec la colonne, le seuil et le sort des lignes rejetées. Le PDF contient un cas de 20 minutes sur le calcul des commissions commerciales d'un distributeur.
L'outillage de tests d'un data quality engineer
SQL
Le premier outil du poste. Les contrôles s'écrivent souvent directement en SQL : taux de valeurs manquantes, doublons sur une clé composée, lignes orphelines par jointure externe, comparaison de sommes entre deux tables. Un candidat à l'aise avec les fonctions de fenêtre et les jointures d'exclusion avance vite sur tout le reste.
Tests dbt
Dans dbt, les tests de données (unicité, non-nullité, valeurs acceptées, relations entre tables) tournent après la construction d'un modèle. Ils peuvent avertir ou bloquer selon un seuil et conserver les lignes en échec. Depuis la version 1.8, les tests unitaires vérifient la logique d'un modèle sur de petites données fictives avant sa construction.
Great Expectations (GX Core)
Une bibliothèque Python open source. On y écrit des attentes sur les données (une colonne unique, des valeurs dans une liste, un format), regroupées en suites, puis exécutées par un checkpoint qui peut notifier une équipe. Elle sert surtout dans les pipelines Python, Spark ou pandas, avant ou après un chargement. Sa version 1.x a changé l'API par rapport aux versions 0.x encore citées sur les CV.
Soda
Un outil de contrôle où les vérifications s'écrivent en YAML : nombre de lignes, valeurs manquantes, doublons, fraîcheur, réconciliation entre deux jeux de données. Il existe en open source (Soda Core) et en version SaaS (Soda Cloud). Depuis Soda 4, sorti en 2025, les contrôles s'organisent autour de contrats de données versionnés dans Git.
Python, pytest et Pandera
Pour les pipelines en Python ou PySpark, les fonctions de transformation se testent avec pytest sur de petits jeux de données construits à la main. Pandera valide le schéma et les valeurs d'un DataFrame (types, bornes, unicité). Demandez à voir un test que la personne a écrit, avec ses données d'entrée.
Comparaison de tables
Avant de fusionner une modification, on compare la table produite par la nouvelle version à celle de production, clé par clé et colonne par colonne. Des outils comme Datafold le font, mais une requête maison sur les clés et des agrégats suffit souvent. C'est la meilleure protection contre les régressions silencieuses.
Plateformes d'observabilité
Elementary, Monte Carlo ou Sifflet surveillent volumes, fraîcheur et distributions et détectent des anomalies sans règle écrite. Leur exploitation relève souvent du DataOps engineer. Le data quality engineer y branche ses propres tests et s'en sert pour savoir où écrire des règles précises.
Outils de qualité des éditeurs
Informatica Data Quality, Talend Data Quality et les modules qualité des catalogues (Collibra, Microsoft Purview) se rencontrent dans les grands comptes. On y retrouve profilage, règles, dictionnaires et dédoublonnage. Un ingénieur venu du code s'y adapte s'il maîtrise les notions.
On trouve le poste dans les scale-ups qui ont structuré leur plateforme autour de dbt et d'un entrepôt cloud, dans les équipes data des grands groupes, et en ESN sur des missions de fiabilisation ou de migration où il faut prouver que les nouveaux chiffres égalent les anciens. L'intitulé varie : data quality engineer, ingénieur qualité des données, parfois data engineer avec une mention qualité ou QA data. Le travail mêle trois savoir-faire : profiler et définir ce qu'est une donnée valide avec le métier, coder les contrôles au bon endroit du pipeline, décider du sort des lignes en erreur. Quand l'entreprise a aussi un DataOps engineer, ce dernier tient l'exploitation et les alertes, et le data quality engineer fournit les règles. Aucune certification ne couvre ce périmètre, tout se vérifie en entretien.
Les compétences à faire démontrer à un data quality engineer
- Profilage et dimensions de la qualité
- Écriture de tests de données
- Tests de la logique de transformation
- Réconciliation entre systèmes
- Gestion des lignes en erreur
- Mesure et coût des contrôles
Questions pour un data quality engineer, de la source au contrôle
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · junior à confirmé
On vous confie une nouvelle source de 80 colonnes sans documentation. Que mesurez-vous avant d'écrire la première règle ?
Une bonne réponseUn profilage colonne par colonne : taux de valeurs manquantes, nombre de valeurs distinctes, minimum et maximum, valeurs les plus fréquentes, formats observés, longueur des chaînes. Puis les clés candidates, les relations avec les tables existantes et les valeurs par défaut suspectes (01/01/1900, 999999, chaîne vide). Les règles viennent ensuite, validées avec le propriétaire de la donnée.
Signal d'alerteÉcrire tout de suite des tests de non-nullité sur toutes les colonnes, ou attendre que le métier fournisse la liste des règles.
Question 2 · confirmé
Une table de commandes doit contenir une ligne par commande, avec une clé composée de trois colonnes, et une source renvoie parfois des corrections. Quel test écrivez-vous, et que fait-il quand il échoue ?
Une bonne réponseUn test d'unicité sur la combinaison des trois colonnes (unique_combination_of_columns de dbt_utils, ou l'attente d'unicité composée de GX, ou un GROUP BY ... HAVING COUNT(*) > 1). En échec, il bloque la suite si la table alimente la finance et conserve les lignes fautives pour analyse. Les corrections de la source se traitent en amont : on garde la dernière version par clé selon une date de mise à jour.
Signal d'alerteUn test d'unicité sur une seule colonne, ou la suppression des doublons par un DISTINCT sans comprendre d'où ils viennent.
Question 3 · confirmé
Vous modifiez le calcul de la marge dans un modèle dbt. Comment prouvez-vous avant la fusion que rien d'autre n'a bougé ?
Une bonne réponseUn test unitaire dbt (given, expect) qui couvre le nouveau cas et les anciens. Puis une comparaison entre la table construite en CI et celle de production : nombre de lignes, clés présentes d'un seul côté, colonnes différentes clé par clé, agrégats par mois. Seule la marge doit changer, et sur les lignes attendues. La CI ne reconstruit que les modèles modifiés et leurs descendants.
Signal d'alerte« Je regarde le tableau de bord après la mise en production », ou relancer les tests de données existants en pensant qu'ils détectent un changement de calcul.
Question 4 · confirmé
Le chiffre d'affaires mensuel de l'entrepôt diffère de celui de l'ERP de 0,3 %. Comment construisez-vous un contrôle de réconciliation ?
Une bonne réponseDes agrégats comparables des deux côtés : même périmètre, même date de coupure et même fuseau horaire, même traitement des annulations, avoirs et devises. Un rapprochement par jour et par entité pour localiser l'écart, puis au niveau des pièces par jointure externe pour trouver les lignes absentes ou différentes. Une tolérance définie avec la finance, des résultats historisés et un contrôle planifié après chaque chargement.
Signal d'alerteAccepter l'écart « parce que c'est faible », ou comparer un total global sans pouvoir descendre au détail.
Question 5 · confirmé
Des lignes invalides arrivent dans un flux quotidien. Vous bloquez tout le chargement, vous écartez ces lignes ou vous les laissez passer avec un avertissement ?
Une bonne réponseCela dépend de la règle et de l'usage. Blocage pour une donnée financière ou réglementaire, ou au-delà d'un seuil de lignes en erreur. Mise en quarantaine dans une table dédiée, avec la règle violée et l'identifiant d'exécution, quand le reste de la donnée reste exploitable. Avertissement pour un champ facultatif. Dans tous les cas, un chemin de retraitement et un retour vers le producteur.
Signal d'alerteUne seule politique pour tout, ou des lignes écartées en silence sans trace.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Data quality engineer : réponses aux questions de recrutement
Data quality engineer ou DataOps engineer : lequel recruter ?
Si vos chiffres sont faux alors que les pipelines tournent, cherchez un data quality engineer : il définit et code les règles, teste les transformations et réconcilie les systèmes. Si vos tables arrivent en retard, que les alertes partent dans tous les sens et que personne ne mène les incidents, le DataOps engineer est le bon profil. Dans une petite équipe, une seule personne couvre souvent les deux. Annoncez alors clairement la priorité.
Un candidat qui n'a pratiqué qu'un seul outil de tests est-il recevable ?
Oui, si les notions sont là. Les tests dbt, Great Expectations et Soda partagent la même logique : une règle, un périmètre, un seuil, une action en cas d'échec. Une personne qui a écrit de bons tests dbt passera à Soda en quelques jours. Vérifiez plutôt qu'elle sait choisir quoi tester, écrire un test personnalisé en SQL et expliquer pourquoi un test a été conçu de cette façon.
Quelle mise en situation donner à un data quality engineer ?
Un petit jeu de données réel ou fabriqué, avec des défauts cachés : doublons sur une clé composée, valeurs par défaut déguisées, lignes orphelines, montants incohérents. Demandez de profiler, de proposer cinq règles avec leur seuil et leur action, puis d'en coder deux en SQL. Ce test technique tient en une heure et montre plus qu'un questionnaire sur les fonctions d'un outil.
Quelle différence avec un data quality analyst ?
Le data quality analyst travaille surtout sur les référentiels métier (clients, articles, fournisseurs) : profilage, tableaux de bord qualité, remédiation avec les équipes qui saisissent la donnée, souvent avec un outil d'éditeur. Le data quality engineer code les contrôles dans les pipelines, teste les transformations et automatise. Les deux postes se complètent, et Delectus propose une fiche distincte pour l'analyste.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
