Lorsque la demande « Nous voulons aussi voir les données des concurrents dans notre tableau de bord » arrive à l’équipe data
Les sources internes sont stables. Nous contrôlons les schémas, les changements sont annoncés dans les notes de version, et des procédures de retraitement existent même en cas d’échec. Mais dès que la direction et les équipes opérationnelles demandent « Nous voulons aussi voir les prix des concurrents, les avis et les données de marché dans le même tableau de bord », il faut connecter au pipeline des sources qui échappent à notre contrôle.
Pour le web externe, nous ne possédons pas le schéma. Les sites cibles modifient leur structure d’affichage sans préavis, et leurs politiques de blocage se renforcent fréquemment. Si la collecte d’hier est vide, le tableau de bord d’aujourd’hui présente un trou, et des données reçues dans Excel ne peuvent pas être raccordées à un DAG. Cet article explique comment intégrer la collecte web externe aux pipelines internes de DW et de data lake — autrement dit, cette méthode d’intégration. Le principe est simple : externaliser la collecte et permettre à l’équipe data de se concentrer sur le chargement, la modélisation et l’exploitation. Pour traiter le web externe comme un « système source bien géré », cette source doit conclure un contrat dans le langage de l’équipe data.
1. En quoi les données web externes diffèrent-elles des sources internes ?
Avant de les connecter, il faut comprendre ce qui les distingue afin de concevoir l’intégration. Pour les tables internes, les changements de colonnes relèvent de notre procédure de publication ; sur le web externe, le site source peut les modifier à sa guise. Un champ présent hier peut disparaître aujourd’hui, et un même « prix » peut arriver sous des formats mélangés, comme 12,900원 et 12900. Les mises à jour ne sont pas transactionnelles : elles sont effectuées par des traitements batch périodiques. Il faut donc aligner le planning du DAG et le SLA de fraîcheur du tableau de bord sur cette cadence.
La différence la plus dangereuse réside dans les modes de défaillance. Un job interne échoue en levant une exception et s’arrête, mais le pire scénario pour un crawler externe est de s’accumuler avec des valeurs vides tout en prétendant avoir réussi. Si la structure du site change et qu’un sélecteur ne cible plus les bons éléments, le job se termine normalement, mais les enregistrements sont au nombre de 0 ou remplis de valeurs manquantes. Une validation qui ne regarde que le volume ne peut pas le détecter, et comme les pages web passées ne peuvent plus être recollectées, ce trou devient permanent. L’intégration de données externes ne s’arrête donc pas au « chargement » : la validation après chargement fait partie intégrante de l’ensemble.
2. Modèles d’intégration par format de livraison — pas de réponse unique, on s’adapte aux spécifications
La façon de connecter la collecte externe au pipeline dépend du format de livraison. Il existe trois grands modèles ; aucun n’est intrinsèquement correct, le choix dépend des standards du pipeline de l’équipe data.
| Modèle | Déclencheur DAG | Cas approprié | Points à convenir |
|---|---|---|---|
| Interrogation d’API | Planning+capteur | L’équipe data contrôle le moment de récupération | Curseur incrémental·pagination·authentification |
| Chargement direct DB·S3 | Capteur d’arrivée | Gros volumes, éviter la charge du polling | Marqueur de fin·spécifications de table/préfixe |
| Réception de fichiers | Capteur de fichiers | Faible fréquence, transition d’Excel vers le pipeline | Nom de fichier·chemin·schéma des feuilles |
Le modèle d’interrogation d’API consiste à recevoir les données collectées via une API ; le DAG ne consulte alors, depuis le dernier watermark, que les incréments qu’il charge dans la zone d’atterrissage. L’essentiel est que l’équipe data garde la maîtrise du curseur incrémental afin de ne pas récupérer deux fois les segments déjà reçus. Dans le modèle de chargement direct DB·S3, le prestataire de collecte charge directement dans le DW ou le lake, et le DAG ne fait que détecter l’arrivée pour lancer les traitements suivants. Il faut alors convenir à l’avance d’une convention de marqueur de fin (manifest·_SUCCESS) afin d’éviter de consommer des données arrivées à moitié. Le modèle de réception de fichiers consiste à analyser et charger des fichiers normalisés déposés à un emplacement standard ; il est adapté à la période de transition où une opération centrée sur Excel bascule vers un pipeline.
Les trois modèles supposent que nous (côté collecte) et l’équipe data alignions d’abord les spécifications de l’interface. La structure des réponses API, les tables DB/préfixes S3 et les conventions de fichiers sont définis en fonction du pipeline de l’équipe data, puis le format de livraison est choisi en remontant à partir de ces spécifications. Cette concertation n’est possible que si les formats de livraison ne se limitent pas à Excel et incluent aussi l’API, le chargement direct et le dépôt S3.
3. Zone d’atterrissage — le tampon qui évite que l’aval casse lorsque la source externe change
Si les données externes sont injectées directement dans la couche de modélisation, tout l’aval (dbt·tableaux de bord) casse le jour où la source change. La zone d’atterrissage est le dispositif tampon, qui traite ici trois éléments.
Premièrement, la conservation des originaux raw. Une copie est conservée telle quelle, sans modification (réponse API brute, fichier d’origine). L’objectif est de pouvoir réanalyser à partir des originaux sans recollecter si la logique de parsing était erronée ou si un autre champ devient nécessaire ultérieurement. Puisque les pages web passées ne sont pas récupérables, cette conservation des originaux constitue de fait le filet de sécurité.
Deuxièmement, le versionnement des schémas. Voici notre standard de travail avec l’équipe data. Les changements de schéma sont notifiés à l’avance avec une période de dépréciation ; durant cette période, les anciennes et nouvelles versions sont fournies en parallèle afin que l’aval puisse migrer à son propre rythme. Par exemple, nous continuons à publier price_daily.v1 tout en publiant v2, qui ajoute la colonne currency. Une fois prêt, le dbt en aval modifie ses références, puis v1 est retiré à la fin de la dépréciation. Ainsi, « la source a été refondue hier et le tableau de bord est mort aujourd’hui » devient « fonctionnement parallèle jusqu’au prochain trimestre, avec migration d’ici là ». Puisque la responsabilité du changement et la période tampon sont inscrites dans le contrat, l’équipe data n’est pas appelée en urgence comme pompier face à l’imprévu.
Troisièmement, nous traitons le backfill comme une procédure standard. Lorsqu’il manque plusieurs jours de collecte ou qu’un nouveau champ doit aussi être renseigné sur les périodes passées, nous recollectons en définissant la période et les conditions, puis rechargeons la zone d’atterrissage ; le DAG ne remodélise alors que cette plage. La condition préalable est une conception idempotente, avec remplacement de partition ou clé d’upsert, afin que les doublons ne s’accumulent pas même si la même période est réinjectée. Comme le canal de recollecte se trouve de notre côté, l’équipe data n’a qu’à indiquer « quelle période retraiter ».
4. Validation après chargement — détecter les valeurs manquantes silencieuses dans le DAG
Les « valeurs manquantes silencieuses » de la section 1 ne peuvent être détectées que par la validation après chargement. Une porte DQ est placée avant publish ; si les contrôles échouent, les données ne sont pas promues vers l’aval. Au lieu de laisser les données défectueuses atteindre le tableau de bord, elles s’arrêtent dans la zone d’atterrissage et une alerte est déclenchée. La porte vérifie généralement quatre points : que le nombre d’enregistrements ne chute pas brutalement sous le seuil minimal attendu (valeurs manquantes silencieuses), que le taux de valeurs manquantes des champs obligatoires reste sous le seuil défini (collecte partielle), qu’il n’existe pas de drapeau d’anomalie de parsing (refonte de structure), et que l’heure de collecte respecte le SLA de fraîcheur (fraîcheur).
Afin que l’équipe data n’ait pas à créer toutes les règles DQ depuis zéro, nous transmettons avec les données les métadonnées de validation. Elles incluent l’heure de collecte (fraîcheur), les conditions de collecte (mots-clés·catégories·périmètre), l’URL source (lignage·audit), le nombre d’enregistrements (chute brutale par rapport aux attentes) et les indicateurs de valeurs manquantes/anomalies. La supervision ne se situe pas en un seul endroit, celui du crawler : elle couvre à la fois la source (collecte) et le pipeline (chargement). Si une anomalie ou un retard de collecte est détecté, nous en informons l’équipe data via son canal (Slack·webhook) en partageant également l’heure estimée de rétablissement, afin de pouvoir répondre à « pourquoi est-ce vide et quand cela sera-t-il rempli ? ».
5. Catalogue·lignage — répondre à « d’où vient ce chiffre ? »
Lorsque des données externes arrivent dans un tableau de bord, tôt ou tard une réunion de direction ou un audit posera la question : « D’où vient ce prix concurrentiel ? ». Pour y répondre, le catalogue et le lignage doivent enregistrer les métadonnées d’origine et de fréquence. Afin de permettre cette inscription directe, nous fournissons le domaine/URL source, la fréquence de collecte, les conditions de collecte (périmètre ciblé), la version actuelle du schéma, ainsi que le fait que cette source est exploitée de manière externalisée. Ces éléments recoupent les métadonnées de validation, auxquelles s’ajoutent des champs du point de vue du catalogue.
En renseignant ces métadonnées lors de l’enregistrement du jeu de données, le graphe de lignage permet de remonter, depuis un indicateur de tableau de bord, jusqu’à l’URL source. Un état dans lequel il suffit de quelques clics pour répondre à « d’où vient ce chiffre ? » — c’est l’état où les données externes ont été intégrées à la gouvernance au même niveau que les sources internes. C’est là que convergent les raisons d’aligner schéma, backfill et métadonnées avec l’équipe data. Pour devenir un « système source géré », une source externe doit être fournie sous une forme pouvant être officiellement enregistrée au catalogue.
Enfin, il y a la fraîcheur. La collecte externe repose sur des traitements batch périodiques ; le SLA du tableau de bord doit donc être fixé selon cette cadence. Si le batch s’exécute une fois par jour, le tableau de bord doit aussi être conçu comme un « indicateur mis à jour quotidiennement », et son libellé devrait préciser l’heure de collecte batch, par exemple « à ○ h », afin de rester cohérent avec l’exploitation. Pour tout le monde, équipe data comme équipes métier, il est plus sûr de communiquer la fraîcheur non pas comme « à quel point les données sont récentes », mais comme « sur quelle exécution batch elles se fondent ».
Ce que cette intégration apporte à l’équipe data
L’essentiel de l’intégration de la collecte web externe aux pipelines consiste à placer une source incontrôlable derrière une interface contrôlable. En encadrant le schéma par un contrat de version, les échecs par une porte DQ, l’origine par des métadonnées de catalogue et le retraitement par une procédure standard de backfill, les données externes peuvent être traitées comme des sources internes.
La dernière décision consiste à déterminer qui porte l’exploitation continue derrière cette interface — réponse aux blocages, suivi des refontes de sites, supervision et correction de la collecte. Si l’équipe data s’en charge, les personnes qui exploitent les DAGs s’épuisent dans la maintenance de la collecte externe. Nous prenons en charge, dans le cadre d’un abonnement mensuel, le développement, la maintenance, la réponse aux blocages et la supervision de collecte ; nous livrons à l’équipe data une source dotée d’un contrat de schéma, de métadonnées de validation et de métadonnées de catalogue. Puisque les données passent par la collecte → le nettoyage → l’analyse par IA et sont livrées sous forme structurée et chargeable plutôt que raw, la charge de nettoyage de la zone d’atterrissage est également réduite.
La conclusion est simple. Externaliser la collecte et la maintenance web externes pour les traiter comme un système source bien géré, et permettre à l’équipe data de se concentrer sur le chargement, la modélisation et l’exploitation. Nous assurons déjà en prestation l’exploitation d’une surveillance en ligne à grande échelle pour une autorité de régulation sous forme de pipeline périodique, et les demandes de grande ampleur ou de plusieurs départements sont également centralisées par cette approche.
Articles complémentaires
- Comment les données de crawling deviennent des décisions
- Données reçues dans Excel vs données consultées dans un tableau de bord — ce que change le format de livraison
- Les entreprises où chaque département fait son crawling séparément — une gouvernance de collecte de données à l’échelle de l’entreprise pour mettre fin aux investissements redondants
Commencer dès maintenant
Indiquez-nous les spécifications de votre pipeline actuel — orchestration Airflow, data lake S3 ou chargement direct dans le DW — et nous concevrons avec vous l’interface permettant d’y connecter la collecte web externe. Nous alignons le contrat de schéma, les métadonnées de validation et les métadonnées de catalogue dans le langage de l’équipe data.
