Issa Sanogo

Monitoring des pipelines data en production

Sun, 15 Mar 2026 00:00:00 +0000

Pourquoi monitorer

Un pipeline qui tourne ne veut pas dire un pipeline qui fonctionne. Les données peuvent arriver en retard, être incomplètes ou corrompues — et personne ne s’en aperçoit si le monitoring est absent.

Le monitoring data, c’est répondre à 3 questions en permanence :

Est-ce que ça tourne ? (orchestration)
Est-ce que les données arrivent ? (freshness)
Est-ce que les données sont correctes ? (qualité)

Quick Start (Docker)

Pour tester les checks SQL de cet article :

MinIO et Airflow : construire un data lake local

Sun, 08 Mar 2026 00:00:00 +0000

Pourquoi un data lake local

Travailler avec S3 en production, c’est standard. Mais développer directement sur AWS coûte cher et ralentit les itérations. MinIO résout ça : un stockage objet S3-compatible qui tourne en local.

Combiné à Airflow, on obtient un environnement de développement complet :

Stockage objet (landing, staging, curated)
Orchestration des pipelines
Tests reproductibles sans accès cloud

L’architecture

[Sources]
 ↓
[Airflow DAGs]
 ↓
[MinIO buckets]
 ├── landing/ (données brutes)
 ├── staging/ (données nettoyées)
 └── curated/ (données prêtes à consommer)

Airflow orchestre les DAGs qui lisent et écrivent dans MinIO via le protocole S3. Le code est identique à celui qu’on déploiera en production sur AWS.

Qualité des données en santé : pourquoi c'est plus difficile qu'ailleurs

Mon, 02 Mar 2026 00:00:00 +0000

Pourquoi cet article ?

Pendant mes quatre ans à l’AP-HP puis à l’Institut Jérôme Lejeune, j’ai appris que la qualité des données en santé est un problème à part. Un identifiant patient mal rattaché ne se corrige pas comme une erreur de montant. Les systèmes sont fragmentés, la réglementation interdit l’improvisation, et la tolérance à l’erreur est proche de zéro sur certains flux. Cet article pose le cadre que j’applique depuis, et que j’aurais aimé trouver documenté quand j’ai commencé.

Tester ses pipelines data : ce qui compte vraiment

Sun, 01 Mar 2026 00:00:00 +0000

Pourquoi tester ses pipelines

Un pipeline sans tests, c’est un pipeline qui casse en silence. Les données arrivent mal formatées, un schéma change, une colonne disparaît — et personne ne s’en aperçoit avant qu’un dashboard affiche n’importe quoi.

Les tests ne sont pas un luxe. C’est ce qui permet de refactorer, de déployer et de dormir tranquille.

Quick Start (Docker)

Pour exécuter les tests Python de cet article :

docker run --rm -it python:3.12-slim bash -c "
 pip install -q pandas pytest &&
 python
"

Collez les fonctions de test et lancez-les avec pytest. Pour les tests SQL, lancez un PostgreSQL : docker run --name pg-test -e POSTGRES_PASSWORD=secret -d postgres:16.

Construire un pipeline production-grade : idempotence, erreurs et traitement incrémental

Sun, 22 Feb 2026 00:00:00 +0000

Pourquoi cet article

J’ai eu deux incidents marquants en production. Le premier : un pipeline relancé après un bug avait doublé toutes les données de la table — personne ne s’en était rendu compte pendant 3 jours. Le deuxième : un pipeline critique avait planté un vendredi soir sans alerte, et l’équipe métier a signalé des données manquantes le lundi matin.

Ces deux incidents ont la même cause profonde : des pipelines qui n’étaient pas pensés pour la production. Pas idempotents. Sans gestion d’erreurs. Pas incrémentaux. Ce sont les trois propriétés que j’exige maintenant systématiquement avant de mettre un pipeline en prod.

Modélisation dimensionnelle : structurer un data warehouse

Fri, 20 Feb 2026 00:00:00 +0000

Le problème

Les données brutes sont chargées dans le warehouse. Des tables partout. Des jointures complexes. Les analystes passent plus de temps à comprendre le modèle qu’à produire des insights.

La modélisation dimensionnelle résout ce problème en organisant les données pour la consommation, pas pour le stockage.

Quick Start (Docker)

Pour tester les exemples SQL de cet article :

docker run --name pg-dim -e POSTGRES_PASSWORD=secret -d postgres:16
docker exec -it pg-dim psql -U postgres

Copiez les CREATE TABLE et requêtes directement dans psql. Pour nettoyer : docker rm -f pg-dim.

PostgreSQL en production : ce que j'ai appris en optimisant des requêtes sur de vraies données

Sun, 08 Feb 2026 00:00:00 +0000

Pourquoi cet article

Beaucoup de data engineers traitent PostgreSQL comme une boîte noire : ils savent écrire du SQL, mais ignorent pourquoi une requête est lente, pourquoi un pipeline crée des doublons à la relance, ou pourquoi un chargement plante à mi-chemin.

Cet article couvre les deux côtés : d’abord les fondamentaux théoriques qu’il faut comprendre pour ne pas travailler à l’aveugle, puis les techniques d’optimisation concrètes. Pas un cours académique — ce que j’aurais voulu avoir quand j’ai commencé à débugger des requêtes sur des tables de 200 millions de lignes.

Les 6 dimensions de la qualité des données — et celles qu'on oublie toujours

Tue, 03 Feb 2026 00:00:00 +0000

Pourquoi c’est le sujet n°1

Une donnée de mauvaise qualité coûte cher. Pas seulement en argent : en confiance. Quand un dashboard affiche des chiffres incohérents, personne ne le regarde plus. Et quand personne ne regarde, les décisions se prennent au doigt mouillé.

Le vrai coût de la mauvaise qualité, c’est l’érosion de la confiance dans la plateforme data.

Les 6 dimensions de la qualité

1. Complétude

Les données attendues sont-elles présentes ? Des colonnes NULL partout, des lignes manquantes, des fichiers vides — c’est le symptôme le plus fréquent.

Le Zen du data engineering

Mon, 02 Feb 2026 00:00:00 +0000

Pourquoi cet article ?

J’ai passé deux jours à traquer une duplication silencieuse en production. Le pipeline tournait, les logs étaient verts, les chiffres étaient faux. Quand j’ai fini par trouver la cause — une absence de contrôle d’unicité à l’insertion — je me suis demandé combien de mes pipelines avaient le même défaut. C’est ce genre de moment qui m’a poussé à formaliser les principes que j’applique maintenant systématiquement. Ils sont largement inspirés du Zen of Python.

Batch, micro-batch, streaming : quel pattern pour quel besoin

Sun, 01 Feb 2026 00:00:00 +0000

Le choix qui structure tout

Le premier choix d’architecture d’une plateforme data est : comment la donnée circule de la source à la destination ? Ce choix impacte le tooling, les coûts, les compétences nécessaires et les délais de livraison.

Il existe 3 patterns. Chacun a ses cas d’usage légitimes.

Pattern 1 : Batch

La donnée s’accumule, puis est traitée en bloc à intervalles réguliers (toutes les nuits, toutes les heures).

Structurer un projet Python pour les pipelines data

Sun, 01 Feb 2026 00:00:00 +0000

Le problème

La plupart des projets data démarrent avec un seul script. Puis deux. Puis dix fichiers éparpillés dans un dossier sans structure.

Résultat : personne ne sait où est quoi, les imports cassent, et le déploiement est un cauchemar.

Structurer son projet dès le départ coûte 10 minutes. Ne pas le faire coûte des heures de dette technique.

Quick Start (Docker)

Pour reproduire la structure et les tests de cet article :

Data products : penser produit quand on est data engineer

Sat, 31 Jan 2026 00:00:00 +0000

Pourquoi cet article ?

J’ai livré un pipeline dont personne ne s’est servi. Trois jours de développement, une architecture propre, zéro utilisateur. Le problème n’était pas technique. Je n’avais pas posé la bonne question au départ. C’est ce raté qui m’a fait basculer vers une approche produit : commencer par le problème métier, pas par la donnée disponible. Cet article retrace ce changement de perspective.

Qu’est-ce qu’un data product ?

Un data product est un livrable basé sur la donnée qui résout un problème précis pour un utilisateur défini. Ce n’est pas juste une table ou un dashboard.

Modern data stack : ce qui compte vraiment

Fri, 30 Jan 2026 00:00:00 +0000

Ce qui a changé

Il y a 10 ans, une plateforme data coûtait des millions et prenait des mois à déployer. Aujourd’hui, une startup peut avoir une stack data solide pour quelques centaines d’euros par mois.

La raison : le cloud, le pay-per-use, et des outils composables qui font chacun une seule chose bien.

Les 5 couches d’une stack moderne

1. Sources

Tout ce qu’on veut analyser : bases applicatives (PostgreSQL, MySQL), outils SaaS (Salesforce, Stripe, HubSpot), fichiers, flux d’événements.

ETL vs ELT : comment choisir

Mon, 26 Jan 2026 00:00:00 +0000

Rappel : qu’est-ce que l’ETL ?

ETL signifie Extract, Transform, Load. C’est le processus fondamental du data engineering : extraire des données de systèmes sources, les transformer, puis les charger dans un système cible (warehouse, base analytique).

ELT inverse les deux dernières étapes : on charge d’abord la donnée brute dans le warehouse, puis on la transforme sur place en SQL.

La différence n’est pas cosmétique. Elle impacte l’architecture, les coûts, la sécurité et la maintenabilité.

dbt en production : au-delà du getting started

Mon, 05 Jan 2026 00:00:00 +0000

dbt, c’est quoi en une phrase

dbt te permet d’écrire des transformations SQL comme du code versionné, testé, documenté et déployé proprement.

Quick Start (Docker)

Pour tester dbt sans rien installer, avec PostgreSQL :

docker run --name pg-dbt -e POSTGRES_PASSWORD=secret -p 5432:5432 -d postgres:16
docker run --rm -it python:3.12-slim bash -c "
 pip install -q dbt-postgres &&
 dbt init my_project --skip-profile-setup &&
 cd my_project &&
 bash
"

--skip-profile-setup crée le projet sans prompts interactifs. Configurez ensuite la connexion vers host.docker.internal:5432 dans ~/.dbt/profiles.yml et lancez dbt debug.