Recruter un DataOps engineer sur la fraîcheur des tables et les incidents

L'intitulé DataOps engineer recouvre deux réalités dans les offres françaises. Dans les grands comptes et les ESN, le poste ressemble souvent à de l'exploitation : supervision des traitements batch, mises en production, support N2 ou N3, parfois des astreintes en heures non ouvrées. Dans les scale-ups, il pose des tests, des détecteurs d'anomalies et des objectifs de fraîcheur sur les tables, et prend la main quand un chiffre est faux. Le poste visé ici est le second, avec ce qu'il emprunte au premier.

Le piège tient à la confusion entre pipeline qui tourne et donnée juste. Un DAG peut réussir en chargeant une table vide ou une colonne de montants à zéro. L'expérience se reconnaît quand la personne parle de fraîcheur mesurée sur les données, d'alertes routées vers un propriétaire, de lignage pour mesurer l'impact et de post-mortem. Citer Monte Carlo, Sifflet ou Elementary sur un CV ne dit rien de tout cela.

Deux points à régler avec le manager : la présence d'astreintes et la personne qui reçoit les alertes aujourd'hui. Un candidat qui demande de lui-même qui est propriétaire de chaque table a souvent déjà vécu le problème. Le PDF part du tableau de bord du lundi d'une scale-up e-commerce.

L'outillage d'un DataOps engineer, de dbt aux plateformes d'observabilité

Tests dbt et source freshness

dbt transforme les données en SQL versionné et embarque des tests : unicité, valeurs non nulles, relations entre tables. La commande source freshness compare le dernier horodatage chargé à des seuils d'avertissement et d'erreur. C'est souvent le premier filet de sécurité, et le point de départ d'un entretien.

Elementary

Un paquet open source pour dbt, avec une version cloud payante. Il ajoute des tests de détection d'anomalies (volume, fraîcheur, changements de schéma), garde l'historique des résultats et envoie les alertes. Demandez comment la personne règle la sensibilité et la période d'apprentissage pour éviter le bruit.

Monte Carlo et Sifflet

Des plateformes SaaS d'observabilité des données. Elles posent des moniteurs automatiques sur l'entrepôt, affichent le lignage jusqu'aux tableaux de bord et gèrent les incidents. Sifflet est un éditeur français. En entretien, creusez surtout ce que la personne a fait des alertes produites par l'outil.

Soda et Great Expectations

Deux outils de contrôle de qualité déclaratifs, utilisés quand les transformations ne passent pas par dbt : ingestion, jobs Spark, fichiers. Les règles s'écrivent en YAML ou en Python et peuvent bloquer un chargement.

Airflow et l'orchestration

L'orchestrateur lance les traitements, les relance en cas d'erreur passagère et prévient en cas d'échec. Airflow 3 a retiré l'ancienne fonction SLA, remplacée par des alertes d'échéance (Deadline Alerts) depuis la version 3.1. Dagster est une alternative qui raisonne par tables plutôt que par tâches.

OpenLineage et le lignage

OpenLineage est un standard ouvert qui décrit quelle tâche lit et écrit quelles tables. Airflow, Spark et dbt savent émettre ces événements vers un catalogue ou un serveur comme Marquez. Pendant un incident, le lignage dit d'où vient le problème et qui en subit les effets.

Prometheus, Grafana, Datadog et PagerDuty

Les outils de métriques, de tableaux de bord et d'alerte venus du monde de l'exploitation. On y suit les durées de traitement, les retards et les indicateurs de fiabilité. PagerDuty ou un équivalent gère l'astreinte, la rotation et l'escalade.

Contrats de données et schema registry

Un contrat de données engage l'équipe qui produit une donnée sur son schéma, sa qualité et sa fraîcheur. Il s'écrit souvent au format ouvert ODCS et se vérifie dans la CI du producteur. Pour les flux Kafka, un schema registry refuse les schémas incompatibles.

Le périmètre change d'un employeur à l'autre. En ESN et chez les grands comptes, les missions DataOps portent souvent sur la supervision de chaînes batch (OpCon, Control-M, Airflow), les mises en production et le support de niveau 2 ou 3, avec des astreintes possibles. En scale-up, le poste se rapproche du SRE appliqué aux données : objectifs de fraîcheur, détection d'anomalies, contrats avec les équipes produit, gestion des incidents. Certaines offres le fusionnent avec le data platform engineer, qui construit l'infrastructure. Aucune certification ne fait référence pour ce métier, donc l'entretien porte sur des incidents vécus et sur la façon dont la personne mesure la fiabilité.

Les points techniques à faire démontrer par un DataOps engineer

• SLI et SLO de fraîcheur et de volume
• Tests et détection d'anomalies
• Alerting et astreinte data
• Lignage et analyse d'impact
• Contrats de données et changements de schéma
• Gestion d'incidents et reprise des données

Les questions à poser à un DataOps engineer, réponses attendues comprises

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.

1. Question 1 · confirmé

   Le métier veut la table des ventes à jour chaque matin à 8 h. Comment le traduisez-vous en un indicateur que vous pouvez mesurer et en un objectif ?

   Une bonne réponseUn SLI calculé sur les données elles-mêmes : la partition de la veille est présente avant 8 h, ou l'écart entre le dernier horodatage chargé et l'heure courante. Un SLO réaliste sur une fenêtre glissante (par exemple 95 % des jours ouvrés sur quatre semaines), donc un budget d'erreur. Côté outils, un dbt source freshness avec loaded_at_field, warn_after et error_after, ou un moniteur de fraîcheur. L'alerte part avant l'échéance, dès qu'une étape amont prend du retard.

   Signal d'alerte« Si le DAG est vert, la table est à jour. » Ou un objectif de 100 %, qui ne laisse aucune marge et qu'aucune équipe ne tient.

2. Question 2 · confirmé

   Vous devez surveiller 400 tables. Lesquelles reçoivent des tests écrits à la main, et lesquelles une détection d'anomalies automatique ?

   Une bonne réponseUn classement des tables par usage et par criticité, à partir du lignage et de l'historique des requêtes. Les tables critiques reçoivent des tests écrits sur la clé (unicité, non nul), les relations et les règles métier. Toutes reçoivent des moniteurs automatiques de volume, de fraîcheur et de changement de schéma, peu coûteux à généraliser (Elementary, Monte Carlo, Sifflet). La personne règle la sensibilité, la période d'apprentissage et la saisonnalité pour limiter le bruit, et garde en tête le coût des tests sur l'entrepôt.

   Signal d'alerteLes mêmes seuils partout, ou « l'outil détecte tout tout seul » sans aucun test écrit sur les règles métier.

3. Question 3 · confirmé

   Votre canal d'alertes reçoit 150 messages par jour et plus personne ne les lit. Comment reprenez-vous la main ?

   Une bonne réponseUn inventaire des alertes par fréquence et par suite donnée : celles qui ne déclenchent jamais d'action sont supprimées ou rétrogradées. Des niveaux de gravité, un routage vers le propriétaire de la table plutôt qu'un canal commun, et un regroupement par incident : quand une source casse, le lignage permet d'alerter sur la cause et de taire les vingt tests en aval qui échouent par ricochet. Chaque alerte renvoie vers une procédure. Seule une menace sur un SLO de table critique justifie un appel.

   Signal d'alerteCréer un deuxième canal, couper les notifications, ou augmenter tous les seuils sans regarder quelles alertes servent.

4. Question 4 · confirmé

   Une colonne d'une table source change de sens. Comment savez-vous quels modèles et quels tableaux de bord sont touchés ?

   Une bonne réponseUn lignage au niveau des colonnes : le manifest de dbt, les événements OpenLineage émis par Airflow ou Spark, celui de l'outil d'observabilité ou du catalogue (Unity Catalog, DataHub, OpenMetadata), prolongé jusqu'aux tableaux de bord grâce aux intégrations BI. La personne en tire la liste des propriétaires à prévenir. Elle connaît aussi les angles morts : SQL généré dynamiquement, notebooks, extractions vers Excel.

   Signal d'alerteUn grep dans le dépôt Git comme seule méthode, ou une question posée sur Slack en espérant que les bons utilisateurs répondent.

5. Question 5 · senior

   Une équipe produit veut changer le type d'un champ dans les événements qu'elle publie. Comment faites-vous pour que les pipelines en aval ne le découvrent pas en production ?

   Une bonne réponseUn contrat de données versionné chez le producteur (au format ODCS, ou un schéma Avro ou Protobuf dans un schema registry réglé en compatibilité BACKWARD ou FULL), vérifié par la CI de l'équipe produit avant le merge. Un changement incompatible passe par une nouvelle version du champ ou du flux, une période où les deux coexistent, puis un retrait annoncé. Côté data, les contrats de modèles dbt bloquent un type inattendu, et un moniteur de changement de schéma sert de filet.

   Signal d'alerte« On corrigera quand ça cassera », ou un contrat rédigé dans un document Word que personne ne vérifie automatiquement.

DataOps engineer : ce que les recruteurs demandent souvent

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.