Data engineering, SRE et cloud : les commandes, les principes et les métiers, du junior à l'expert

Le pipeline, et pourquoi Parquet

La donnée vient de sources, arrive intacte dans une zone brute, est nettoyée et modélisée en tables, puis servie à un tableau de bord, un modèle ou une API.

Le deck suit le cycle de vie de Reis et Housley (2022) : générer, ingérer, stocker, transformer, servir. La zone brute garde ce qui a été reçu tel quel et n'est jamais modifiée, car elle permet de tout reconstruire après un bogue. Les entrepôts dans le cloud ont changé l'ordre des étapes : on charge d'abord, puis on transforme en SQL dans l'entrepôt (ELT), le modèle sur lequel repose dbt.

CSV et JSON sont du texte : universels, mais volumineux, lents à lire et sans types. Parquet est un format en colonnes (columnar format), compressé, avec les types et le minimum et le maximum par bloc. Avro range des lignes avec un schéma évolutif, pour les messages ; Arrow est une disposition en colonnes en mémoire partagée par pandas, Polars, DuckDB et Spark. Un taux de défaut ne demande qu'une colonne sur 25, donc Parquet lit environ un vingt-cinquième du fichier, et les statistiques par bloc permettent à un filtre de sauter des blocs entiers.

Retenez l'ordre de grandeur, pas les décimales : environ trois fois plus petit et, sur cette machine, à peu près cent fois plus rapide, pour la même réponse. Des durées de quelques millisecondes sont bruitées et varient d'une machine à l'autre.

Retour au sommaire.

SQL sous DuckDB, et le schéma en étoile

Une douzaine de clauses SQL couvrent l'essentiel des requêtes d'un stage, et un schéma en étoile au grain bien énoncé évite de compter deux fois.

Le deck lance douze clauses sur le fichier Parquet avec DuckDB, une base analytique logée dans un paquet Python, sans serveur : sélection et filtres, tri, GROUP BY et HAVING, CASE WHEN, jointures internes et externes, fonctions de fenêtre, CTE, sous-requêtes, et un index avec EXPLAIN sous SQLite.

La question d'entretien classique : WHERE filtre les lignes avant le regroupement, HAVING filtre les groupes après. Affichez toujours l'effectif à côté d'un taux, car un taux sur une douzaine de personnes ne dit rien. Une fonction de fenêtre donne à chaque ligne une valeur calculée sur son groupe sans écraser la table (un rang, une moyenne de groupe, la ligne précédente avec LAG) ; après les jointures, c'est le sujet SQL le plus fréquent en entretien.

Pour la modélisation, le schéma en étoile (star schema) de Kimball place au centre une table de faits mesurés et additifs, et autour des tables de dimensions (qui, quand, quoi). La phrase clé est le grain, ici une ligne par client et par mois de relevé. Pour une dimension à évolution lente (slowly changing dimension, SCD), le type 1 écrase et perd l'historique, le type 2 ajoute une ligne datée pour rejouer le passé, le type 3 garde une seule valeur précédente. La finance a besoin du type 2 : expliquer le défaut d'hier avec la valeur d'aujourd'hui est une fuite de données, comme dans la fiche sur la régression logistique.

Retour au sommaire.

Orchestration, idempotence et tests de données

Un bon pipeline se relance pour n'importe quel jour sans rien doubler, et s'arrête avant de publier quand un test sur les données échoue.

Un orchestrateur (Airflow, Prefect, Dagster) exécute les tâches le long d'un graphe orienté acyclique (directed acyclic graph, DAG). Selon Maxime Beauchemin (2018), une exécution s'occupe d'une période datée et produit une seule partition datée ; une reprise relance le jour en échec et un rattrapage (backfill) relance une série de jours, avec le même code. Cela ne marche que si le traitement respecte l'idempotence.

La partition datée, telle que mesurée dans le deck

1. Un dossier par jour. Le chargement écrit les clients de plus de 60 ans dans un dossier dt= portant la date, une convention Hive que les moteurs relisent comme une colonne.
2. Supprimer, puis écrire. Le dossier du jour est effacé d'abord, si bien qu'une seconde exécution remplace la partition au lieu de s'y ajouter.
3. Rejouer et compter. Avec le 12 octobre chargé deux fois, chaque jour compte toujours 272 lignes, pas 544. Un ajout aurait doublé le jour sans bruit.

Les tests de données. Un test est une requête qui compte les anomalies et doit renvoyer zéro ; sinon le pipeline s'arrête avant de publier, car un tableau de bord en retard vaut mieux qu'un tableau de bord faux. Le deck écrit à la main les quatre tests génériques de dbt (non nul, unique, valeurs admises, plage plausible). Trois passent ; le test des valeurs admises trouve 345 clients aux codes d'études 0, 5 ou 6 absents de la documentation. Un test en échec appelle une décision écrite, pas forcément une correction.

Au niveau senior, un contrat de données (data contract), la lignée (lineage) et un catalogue répondent à la question de ce qui casse en aval quand une colonne change en amont.

Retour au sommaire.

Le SRE : SLI, SLO et budget d'erreur

La fiabilité est traitée comme une fonctionnalité chiffrée : on la mesure, on convient d'une cible sous les cent pour cent, et l'écart sert à changer.

Le Site Reliability Engineering, né chez Google et décrit dans le livre de Beyer et ses coauteurs (2016), repose sur trois habitudes : mesurer la fiabilité, automatiser le travail répétitif, apprendre des incidents sans chercher de coupable. Le SLI est un rapport des bons événements à tous les événements (par exemple, les requêtes de score servies en moins de 300 ms). Le SLO est la cible interne, par exemple 99,9 % sur 30 jours. Le SLA est un contrat plus lâche, avec pénalités, pour que l'équipe soit alertée avant de payer. Viser 100 % est une erreur : chaque neuf de plus coûte bien plus cher et les utilisateurs ne le voient pas.

Exemple chiffré, avec les valeurs illustratives du deck

1. La fenêtre. Trente jours comptent $30 \times 24 \times 60 = 43\,200$ minutes.
2. Le budget. À 99,9 %, un dixième de pour cent de ce total donne 43,2 minutes, soit 2 000 requêtes en échec sur 2 millions. À 99 %, ce serait 432 minutes, à 99,99 % environ 4,3.
3. La vitesse de combustion. Perdre 10 minutes en une journée donne $r = (10 / 43.2) / (1 / 30) \approx 6.94$, presque sept fois le rythme régulier.
4. L'épuisement. À ce rythme, le budget du mois est vide au bout de $30 / 6.94 \approx 4.3$ jours.

Le budget d'erreur (error budget) tranche : tant qu'il en reste, l'équipe livre ; une fois dépensé, les fonctionnalités attendent et le travail va à la fiabilité. L'alerte surveille la vitesse de combustion (burn rate) plutôt que chaque erreur. Le labeur (toil), travail manuel qui grossit avec le trafic, est plafonné et automatisé ; l'astreinte demande une procédure écrite par alerte.

Les incidents. D'abord atténuer (revenir en arrière, éteindre une fonctionnalité, ajouter des machines), comprendre ensuite, puis écrire un post-mortem sans coupable (blameless post-mortem) avec des actions datées et un responsable pour chacune. Dans le cas fictif du deck, une version livrée sans une variable de configuration est repérée par l'alerte de combustion et annulée, pour 39 des 43,2 minutes du mois.

Retour au sommaire.

Infrastructure en code, Docker et Kubernetes

Serveurs, droits et déploiements sont décrits dans des fichiers versionnés et reconstruits à partir d'images, jamais réparés à la main dans une console web.

• Tout est code, autrement dit l'infrastructure décrite en code (infrastructure as code) (Kief Morris, 2016) : des fichiers relus, reconstructibles à l'identique.
• Immuable : on remplace un serveur par une nouvelle image testée, on ne le rafistole jamais à la main ; revenir en arrière, c'est redéployer la précédente.
• Un petit rayon d'explosion (blast radius) : un changement touche d'abord une petite part du trafic (un canari) et revient en arrière tout seul si le SLI baisse.
• Le moindre privilège (Saltzer et Schroeder, 1975) : chaque personne et chaque programme n'a que les droits nécessaires.
• Une sauvegarde testée : seul un exercice de restauration le prouve, comme l'a montré la panne de GitLab du 31 janvier 2017.

Le fichier Terraform du deck déclare un seau de stockage versionné et étiqueté pour la donnée brute, dans la région de Paris. Le cycle est init, plan, puis apply après relecture ; lire le plan, c'est ce qui attrape une destruction imprévue. Terraform n'était pas installé sur la machine de démonstration, donc rien n'a été exécuté.

Un conteneur est un processus isolé qui emporte son système, Python, ses paquets et le code ; il partage le noyau de l'hôte et démarre en une seconde. Les bons réflexes du Dockerfile : une image de base officielle allégée, les dépendances avant le code pour le cache des couches, un utilisateur sans privilèges, la configuration par variables d'environnement. Kubernetes maintient l'état réel d'un cluster égal à l'état déclaré : des pods, un Deployment qui recrée les copies mortes, un Service à adresse stable, un Ingress pour le trafic extérieur. Pour une petite équipe, un service de conteneurs managé suffit souvent.

Retour au sommaire.

Cloud et FinOps : ce que coûte vraiment un mois

Dans le cloud, chaque ressource a un compteur qui tourne, et la facture dépend souvent plus des données qui sortent que du stockage.

AWS, Azure et Google Cloud dominent ; OVHcloud, Scaleway et Hetzner comptent pour le prix et la souveraineté, car des données détenues par une entreprise américaine peuvent être atteintes par le CLOUD Act (2018). Les briques sont partout les mêmes sous d'autres noms : calcul, stockage objet, bases managées, files de messages, fonctions, entrepôt, identités. Quatre compteurs tournent en permanence : le calcul à l'heure, le stockage par gigaoctet mensuel, la sortie réseau (egress) pour chaque gigaoctet envoyé hors du fournisseur, les requêtes au millier.

Chez AWS, la sortie réseau coûte autant que la machine : 400 gigaoctets facturables à 0,090 dollar. Les totaux sont dans deux monnaies et les machines comparables sans être identiques : lisez un ordre de grandeur. En finance, la conformité façonne aussi l'architecture : le RGPD, le règlement DORA (applicable depuis le 17 janvier 2025), l'AI Act, qui classe à haut risque le score de crédit des particuliers, et NIS2.

Retour au sommaire.

Les métiers, les salaires, et junior, senior, expert

Les niveaux se distinguent moins par les outils que par le périmètre : le junior mène une tâche avec fiabilité, le senior répond d'un système, l'expert façonne une plateforme.

Le data engineer construit les tuyaux ; l'analytics engineer transforme les tables brutes en tables métier testées ; les fondations reviennent à l'ingénieur cloud ou plateforme ; l'ingénieur SRE ou DevOps répond de la disponibilité ; le MLOps les traverse tous.

Aucune statistique publique ne donne le salaire d'un data engineer au Luxembourg, et l'Apec n'a pas de fiche SRE ou MLOps : ces repères comparent des métiers, ils ne fixent pas une première offre. Voir aussi la fiche sur l'histoire de l'IA et les métiers.

Junior. Personne n'attend d'un junior qu'il sache tout, seulement qu'il devienne utile et fiable : SQL, Python, Git, le terminal, demander après une recherche raisonnable, de petits changements, jamais la production sans filet. Les erreurs courantes : rester bloqué seul, la pull request géante, une commande destructrice sur le mauvais compte, des chiffres non vérifiés, ne rien écrire.

Senior. Le passage tient au périmètre, pas aux années : un problème flou et un système dont on répond. Le senior écrit un document de conception, consigne ses décisions dans un ADR (Michael Nygard, 2011), estime en fourchettes, relit le code et encadre. Expert. Les ingénieurs staff et principal travaillent en arbitrages : coût contre latence, cohérence contre disponibilité (CAP, PACELC), construire contre acheter, en choisissant l'option la plus simple qui tient le SLO et le budget. Ce qui ne change pas : SQL, le shell, les protocoles réseau, l'idempotence, mesurer avant de croire, écrire clairement.

Retour au sommaire.

À retenir

1. Gardez la donnée brute intacte et rendez chaque chargement idempotent : une partition datée qu'on remplace, sans jamais y ajouter, rend les relances sans danger.
2. Les formats en colonnes comme Parquet ne lisent que les colonnes utiles ; sur le jeu du cours, le fichier était environ trois fois plus petit et bien plus rapide à parcourir.
3. Un test de données est une requête qui doit renvoyer zéro ligne, et un test en échec bloque la publication.
4. Un SLO de 99,9 % sur 30 jours laisse 43,2 minutes d'indisponibilité, et l'alerte doit surveiller la vitesse à laquelle ce budget brûle.
5. L'infrastructure vit dans du code versionné, les serveurs se remplacent à partir d'images, et les sauvegardes se prouvent par des restaurations.
6. Dans le cloud, la sortie réseau et les machines laissées allumées pèsent souvent plus que le stockage.
7. Junior, senior et expert diffèrent par le périmètre, sur des fondamentaux qui restent les mêmes.

Glossaire

ELT

Extraire, charger, puis transformer en SQL dans l'entrepôt.

format en colonnes (columnar format)

Disposition d'un fichier qui range chaque colonne d'un seul tenant (Parquet), pour ne lire que l'utile.

schéma en étoile (star schema)

Une table de faits mesurés entourée de tables de dimensions qui en décrivent le contexte.

dimension à évolution lente (slowly changing dimension, SCD)

Dimension dont les valeurs changent avec le temps ; le type 2 garde chaque version avec ses dates de validité.

graphe orienté acyclique (directed acyclic graph, DAG)

Des tâches reliées par des flèches de dépendance sans boucle, exécutées par un orchestrateur.

idempotence

Un traitement laisse le même état qu'on le lance une fois ou plusieurs.

rattrapage (backfill)

Relance d'un pipeline sur une période passée, avec le code actuel.

contrat de données (data contract)

Engagement versionné d'un producteur sur les colonnes, les types et la fraîcheur.

budget d'erreur (error budget)

Part d'échec qu'autorise un SLO sur sa fenêtre.

vitesse de combustion (burn rate)

Vitesse à laquelle le budget d'erreur se consomme, comparée à un rythme régulier.

labeur (toil)

Travail d'exploitation manuel, répétitif et automatisable, qui grossit avec le service.

rayon d'explosion (blast radius)

Part des utilisateurs ou des systèmes touchés quand un changement tourne mal.

sortie réseau (egress)

Trafic qui quitte un fournisseur cloud, facturé au gigaoctet.

Les autres fiches du cours

Un résumé public par deck, dans l'ordre du cours.

Précédent : Manuel de l'expert data et IASuivant : Panorama des modèles de machine learning

1. IntroductionHivers de l'IA, emploi et méthode
2. OutilsKaggle, GitHub, Python : les outils
3. Séance 1Cadrage de projet et moindres carrés
4. Séance 2Vraisemblance et régression logistique
5. Séance 3Descente de gradient, ridge et lasso
6. Séance 4Seuil de décision et ML reproductible
7. DevoirUn modèle de référence défendable
8. Séance 5Noyaux, SVM et arbres de décision
9. Séance 6Forêts, boosting, comparaison honnête
10. Séance 7SHAP, équité, ACP et partitionnement
11. DevoirUn modèle champion documenté
12. Séance 8Réseaux de neurones, dérive, prédiction conforme
13. DevoirUn projet de machine learning livré
14. Séance 9Soutenir un projet de machine learning
15. RéférenceProjet de score de défaut de crédit
16. RéférenceRendements boursiers : XGBoost et sentiment
17. RéférenceLe code Python de chaque modèle
18. RéférenceDeep learning, l'essentiel
19. RéférenceDonnées ouvertes et projets par secteur
20. RéférenceManuel de l'expert data et IA
21. RéférenceData engineering, SRE et cloud
22. RéférencePanorama des modèles de machine learning

Toutes les fiches, en liste de lecture

L'attention et le transformer, pas à pas

À propos de ces fiches

Écrites par l'enseignant à partir des slides du deck, comme un résumé public : les idées clés, les formules et un exemple calculé. Les exercices, leurs corrigés, les contrôles et la notation restent dans le deck, pour les élèves du cours.

Révision : 16 octobre 2026.