Comment construire un pipeline de données qui ne plante pas tous les lundis matin

La panique du lundi matin

Vous connaissez la sensation. Vous arrivez à votre bureau le lundi, ouvrez votre dashboard, et les données ne se sont pas mises à jour depuis vendredi après-midi. Le scraper a planté parce que le site cible a changé un nom de classe. Le script de transformation a rencontré une valeur null que personne n’avait anticipée. Le pool de connexions à la base de données était saturé parce que trois jobs ont tourné en même temps.

Personne ne l’a remarqué avant parce que l’alerting — s’il existe — envoie des emails à une boîte partagée que personne ne consulte le weekend.

C’est l’état par défaut de la plupart des pipelines de données. Ils fonctionnent 95 % du temps, et les 5 % restants consomment 80 % de votre temps d’ingénierie.

Ça n’a pas à être comme ça.

Les trois couches qui cassent indépendamment

Chaque pipeline de données a trois couches, et les comprendre séparément est la clé de la fiabilité :

Collecte — récupérer les données depuis des sources externes (API, sites web, bases de données, fichiers). C’est là que la plupart des pannes trouvent leur origine, parce que vous interagissez avec des systèmes que vous ne contrôlez pas.

Transformation — nettoyer, normaliser, enrichir et structurer les données brutes. C’est là que les cas limites dans les données créent des bugs dans votre logique.

Livraison — charger les données traitées dans leur destination (base de données, data warehouse, dashboard, API). C’est là que les problèmes d’infrastructure et les incompatibilités de schéma provoquent des échecs.

Chaque couche a besoin de sa propre stratégie de gestion d’erreurs parce que les modes de défaillance sont complètement différents.

Rendre la collecte résiliente

Les pannes de collecte sont les plus fréquentes parce que les sources externes sont imprévisibles. Les sites changent de mise en page (comme tout praticien du scraping par navigateur headless le sait). Les API retournent des réponses inattendues. Les limites de débit s’activent. Les serveurs tombent.

Retry avec backoff, mais pas éternellement. Quand une requête échoue, relancez-la — mais avec un backoff exponentiel (attendez 1 seconde, puis 2, puis 4, puis 8). Fixez un nombre maximum de retries. Si une source échoue depuis 30 minutes, quelque chose ne va vraiment pas, et réessayer toutes les quelques secondes ne fait que marteler un serveur déjà en difficulté.

Sauvegardez votre progression. Si vous scrapez 10 000 pages et que ça échoue à la page 7 342, vous devriez pouvoir reprendre à la page 7 342 — pas recommencer depuis le début. Stockez des checkpoints (le dernier élément traité avec succès) pour que la reprise ne signifie pas tout refaire.

Séparez la collecte de la transformation. Stockez les données brutes collectées avant de les traiter. Si votre scraper récupère du HTML et tente immédiatement de le parser, un bug de parsing signifie que vous perdez les données brutes et devez re-scraper. Si vous stockez d’abord le HTML brut, vous pouvez corriger le parser et retraiter sans re-collecter.

Surveillez la fraîcheur, pas seulement le succès. Un scraper qui “réussit” mais retourne zéro résultat parce que la structure du site a changé est pire qu’un scraper qui échoue bruyamment. Suivez le nombre d’éléments collectés par exécution et alertez quand ça dévie significativement de la baseline.

Patterns de transformation qui survivent aux cas limites

La couche de transformation est là où “ça marchait en test” rencontre “les données de production c’est le chaos.”

Validez les entrées avant de traiter. Avant de transformer un enregistrement, vérifiez que les champs requis existent et ont les types attendus. Un champ prix qui est soudainement une chaîne (“Contactez-nous pour un devis”) au lieu d’un nombre va propager des erreurs à travers tout votre pipeline si vous ne l’interceptez pas tôt.

Gérez les nulls explicitement. Chaque champ provenant d’une source externe peut être null. Chacun. Concevez votre logique de transformation pour gérer les données manquantes avec grâce — soit avec des valeurs par défaut sensées, en signalant l’enregistrement pour revue, ou en le sautant avec une entrée de log. Ne laissez jamais un null produire un résultat silencieusement faux.

Validation de schéma aux frontières. Définissez des schémas explicites pour vos données d’entrée et de sortie. Des outils comme Zod (TypeScript), Pydantic (Python) ou JSON Schema fonctionnent parfaitement pour ça. Validez chaque enregistrement au point d’entrée et de sortie de votre transformation. Les enregistrements qui ne correspondent pas au schéma vont dans une queue “dead letter” pour investigation, pas dans votre base de production.

Rendez les transformations idempotentes. Exécuter la même transformation deux fois sur la même entrée devrait produire la même sortie sans effets de bord. Ça semble évident, mais c’est étonnamment facile à violer — surtout avec des opérations qui incrémentent des compteurs, ajoutent à des listes ou génèrent des timestamps. L’idempotence signifie que vous pouvez relancer n’importe quelle étape en toute sécurité sans craindre de dupliquer ou corrompre des données.

Une livraison qui ne corrompt pas votre base de données

La couche de livraison semble simple — juste écrire les données dans la destination. Mais c’est là que l’intégrité des données vit ou meurt.

Utilisez des upserts, pas des inserts. Si vous chargez des données produit quotidiennement et qu’un produit existe déjà, vous voulez le mettre à jour — pas créer un doublon. Les opérations upsert (insérer si nouveau, mettre à jour si existant) basées sur une clé unique empêchent l’accumulation lente de doublons qui afflige la plupart des pipelines de données.

Écritures par lots avec transactions. N’écrivez pas les enregistrements un par un. Groupez-les en transactions de 100 à 1 000 enregistrements. C’est plus rapide (moins d’aller-retours vers la base de données) et plus sûr (si le lot échoue, la transaction fait un rollback propre au lieu de laisser votre base dans un état à moitié mis à jour).

Les migrations de schéma ne sont pas optionnelles. Quand votre modèle de données change — un nouveau champ, un type modifié, une colonne renommée — gérez-le avec des migrations explicites, pas des commandes ALTER TABLE lancées à la volée en production. Des outils comme Prisma Migrate, Alembic ou Flyway trackent les changements de schéma comme des fichiers versionnés applicables de manière cohérente à travers les environnements.

Orchestration : le ciment qui tient le tout

Les étapes individuelles du pipeline peuvent être fiables, mais l’orchestration — quand les choses tournent, dans quel ordre, et ce qui se passe quand quelque chose échoue — détermine la fiabilité globale du système.

N’utilisez pas de cron jobs pour quoi que ce soit de complexe. Cron convient pour “exécuter ce script toutes les heures.” C’est terrible pour “exécuter l’étape A, puis l’étape B si A a réussi, puis l’étape C, mais réessayer l’étape B jusqu’à 3 fois si elle échoue, et envoyer une alerte si le pipeline entier n’est pas terminé en 2 heures.” Pour tout ce qui dépasse la planification simple, utilisez un vrai orchestrateur de workflows.

En 2026, les options pratiques sont :

• Temporal pour des workflows complexes et de longue durée avec une logique de retry et compensation sophistiquée
• Dagster ou Prefect pour des pipelines spécifiques aux données avec des contrôles de qualité intégrés
• Des systèmes basés sur des queues simples (BullMQ, SQS) pour un traitement séquentiel direct

La plupart des pipelines n’ont pas besoin d’Airflow. Malgré sa popularité, la complexité d’Airflow est excessive pour 90 % des cas d’usage de collecte de données. Un système basé sur des queues bien conçu avec une bonne gestion d’erreurs est plus simple et plus fiable.

Un alerting auquel les gens répondent vraiment

La meilleure gestion d’erreurs au monde est inutile si personne ne voit les alertes.

Alertez sur les anomalies, pas juste les erreurs. Un pipeline qui tourne avec succès mais collecte 50 enregistrements au lieu des 5 000 habituels est probablement cassé. Suivez les métriques de référence et alertez quand les valeurs dévient au-delà d’un seuil raisonnable.

Un canal, signal fort. Si votre alerting envoie 20 messages par jour, les gens arrêtent de lire. Réduisez le bruit en dédupliquant les alertes, en groupant les notifications non-critiques, et en ayant des niveaux de sévérité clairs. Les alertes critiques (pipeline de données complètement arrêté) devraient aller sur Slack ou PagerDuty. Les avertissements (plus lent que d’habitude, quelques enregistrements sautés) peuvent aller dans un email récapitulatif quotidien.

Incluez du contexte dans les alertes. “Pipeline échoué” est inutile. “L’étape de collecte a échoué pour la source X : HTTP 403 à la page 234/10000, dernière exécution réussie il y a 2 heures, 233 pages déjà collectées et sauvegardées” — ça c’est actionnable. Incluez ce qui a échoué, pourquoi, ce qui a déjà été complété, et idéalement un lien vers les logs pertinents.

Tout assembler

Chez SilentFlow, nous avons construit des pipelines de données qui traitent des millions d’enregistrements quotidiennement depuis des centaines de sources. Ceux qui tournent de manière fiable partagent tous le même ADN : séparation des responsabilités entre collecte, transformation et livraison. Données brutes stockées avant traitement. Validation de schéma à chaque frontière. Opérations idempotentes de bout en bout. Alerting pertinent avec contexte.

Rien de tout ça n’est de la science-fusée. C’est juste de la discipline — appliquer des patterns connus de manière cohérente plutôt que de prendre des raccourcis qui font gagner du temps aujourd’hui et coûtent des weekends plus tard. La panique du lundi matin est optionnelle. Il suffit de construire le pipeline qui la rend inutile.