Le pipeline qui fonctionnait parfaitement jusqu’hier est vide ce matin
Avec des sources internes, ce genre de problème survient rarement. Pour modifier un schéma, il y a une concertation ; avant de supprimer une colonne, un préavis ; et en cas de problème, une personne responsable. Mais les sources provenant de sites web externes, comme les prix des concurrents, les avis ou les données de marché, sont différentes.
Un jour, le site cible refond sa section d’avis avec React, déplace l’affichage des prix et masque des éléments auparavant visibles uniquement après connexion. Sans préavis. À cet instant, le parsing qui fonctionnait jusqu’hier renvoie des valeurs vides, le modèle dbt les laisse passer telles quelles, et les données d’hier laissent un trou dans le tableau de bord. Les équipes métier demandent : « Pourquoi les données ne correspondent-elles pas ? », et l’équipe data corrige le parseur au milieu de la nuit.
Cet article explique pourquoi cette situation se répète et comment concevoir les responsabilités en partant du principe que les choses vont casser, sous l’angle des contrats de données (Data Contracts).
Pourquoi le web casse-t-il constamment, plus que les autres sources ?
Un contrat de données est un engagement explicite entre une source et ses consommateurs : « Ces données sont fournies sous cette forme, avec cette signification et à cette fréquence. » Ce n’est pas une simple définition de schéma : c’est aussi un engagement précisant qui fait quoi, et quand, en cas de changement.
Dans les systèmes internes, ce contrat fonctionne comme une norme organisationnelle. L’équipe source doit notifier les changements de schéma, prévoir une période de dépréciation avant de supprimer une colonne, et une personne responsable de la correction existe dans l’organigramme en cas de rupture. L’essentiel est que la source est un acteur capable de coopérer. Il est possible de discuter, de coordonner les calendriers et d’attribuer les responsabilités.
Les données web externes sont difficiles parce que cette prémisse s’effondre. Le site cible n’est pas partie à notre contrat. Il ne tient pas compte de notre pipeline, n’envoie aucune notification, et nous ne pouvons pas lui demander un rollback. De plus, une page web n’est pas conçue à l’origine comme une entrée de pipeline. Nous réinterprétons comme données une interface conçue pour les humains ; les caractéristiques suivantes fragilisent donc le contrat.
- Refontes sans préavis : les renouvellements marketing et les changements de framework modifient du jour au lendemain la structure DOM et le mode de rendu (SSR→CSR).
- Tests A/B et écrans selon les conditions : une même URL peut renvoyer un écran différent à chaque visite, et les éléments affichés varient selon la région, la connexion, le niveau d’adhésion ou l’appareil. Si les conditions dans lesquelles les données ont été observées ne sont pas enregistrées, la signification d’un même champ peut changer silencieusement.
- Données partiellement manquantes à cause des antibots et des blocages : lorsqu’un blocage, un captcha ou une limitation de débit intervient, les données ne disparaissent pas nécessairement entièrement ; seules certaines parties manquent. Ces « données réduites qui semblent normales » produisent alors silencieusement des agrégations erronées en aval.
Le point commun est que l’hypothèse de stabilité du schéma, valable pour les sources internes, ne tient pas pour le web externe. Le contrat de données d’une source web externe ne doit donc pas promettre « que rien ne cassera », mais définir qui est responsable de la détection, de la correction et de la recollecte lorsqu’une rupture survient.
Pourquoi une refonte mineure devient-elle un problème pour toute l’organisation ?
Une petite refonte d’un site se propage en aval. Lorsque les règles de parsing ne correspondent plus au DOM réel, des champs deviennent manquants ou des valeurs sont déformées à l’étape de collecte. Si cela n’est pas filtré dans les tables de chargement, les données passent aux transformations dbt, provoquent une propagation silencieuse de NULL et des agrégations erronées, puis finissent par créer des trous dans les tableaux de bord et de mauvaises décisions.
Deux facteurs élargissent le rayon d’impact. Le premier est l’échec silencieux. Il serait presque préférable que le parsing lève une exception et s’arrête. Le cas dangereux est celui où il renvoie une chaîne vide ou NULL comme s’il s’agissait d’une valeur normale, que l’aval laisse passer tel quel : le pipeline est au vert, mais les chiffres sont faux. Le second est un contrat de champs trop large. Si les modèles en aval et les tableaux de bord référencent directement tous les champs collectés, un simple changement d’élément sur le site déstabilise en même temps tous les livrables qui en dépendent.
Conception de tampon — empêcher l’aval de s’effondrer même en cas de rupture
Il est impossible d’éliminer l’instabilité du web externe. En revanche, il est possible d’interposer une couche tampon pour empêcher cette instabilité de se propager en aval.
Conservation du raw. Conservez séparément les originaux collectés (snapshots HTML, réponses brutes, images avant OCR, etc.) et les résultats du parsing. Si l’on découvre que le parsing était erroné, la présence des originaux permet de restaurer les données historiques par re-parsing, sans nouvelle collecte. Si les originaux sont supprimés, un bug de parsing devient immédiatement une perte de données permanente. La conservation du raw est la base commune de la recollecte, de l’audit et de la lignée.
Réduction du contrat de champs. Limitez le contrat aux seuls champs essentiels dont dépend l’aval. Les éléments secondaires que le site modifie fréquemment ne doivent pas figurer dans le contrat, mais rester uniquement dans le raw. Les champs essentiels contractualisés sont validés sur leur type, leur caractère obligatoire et leur plage de valeurs, et ne sont pas transmis en aval en cas de violation. Plus le contrat est étroit, plus le rayon d’impact d’une refonte est limité.
Détection des changements. Se contenter de vérifier si « le parsing a levé une exception » laisse échapper les échecs silencieux. Il faut donc surveiller la forme même des résultats : variation brutale du nombre d’enregistrements par rapport à l’habitude, hausse soudaine du taux de valeurs manquantes dans les champs essentiels, ou distribution de valeurs hors des plages normales (prix à 0 ou anormalement élevé). Dès qu’un seul signal est détecté, l’équipe data est alertée sur son canal. L’objectif est d’identifier une refonte par le changement de forme des données avant qu’un humain ne la remarque.
Voici comment nous travaillons avec les équipes data sur cette couche tampon. Le schéma est défini dès le départ avec l’équipe data. Nous déterminons quels champs doivent constituer le contrat essentiel, alignons le type, l’acceptation de valeurs nulles et la signification de chaque champ, puis faisons en sorte que les couches en aval — dbt et tableaux de bord — se réfèrent à ce contrat. Même lorsqu’un changement est nécessaire, nous ne remplaçons pas unilatéralement le schéma. Nous notifions le changement à l’avance, prévoyons une période de dépréciation et fournissons parallèlement les versions ancienne et nouvelle pendant cette période, afin de laisser à l’aval le temps de migrer, avant de retirer l’ancienne version. Ainsi, même si le site change, l’aval peut basculer dans la fenêtre annoncée, et la refonte ne se traduit pas immédiatement par un trou dans le tableau de bord.
Concevoir les responsabilités en partant du principe que les choses vont casser
Le tampon technique ne suffit pas. Ce qui fait réellement échouer les opérations, c’est l’absence dans le contrat d’une réponse à la question : qui corrige lorsque cela casse ? Le contrat de données doit donc indiquer non seulement le schéma, mais aussi les propriétaires de la détection, de la correction et de la recollecte.
| Propriété | À préciser dans le contrat |
|---|---|
| Détection | Qui opère les signaux d’anomalie, sur quel canal alerter, et quel est le délai cible de rétablissement. L’entité de détection n’est pas le consommateur, mais celle qui opère la collecte |
| Correction | Qui est responsable de réparer les règles lorsque le parseur casse à cause d’une refonte du site. En cas d’externalisation, le prestataire |
| Recollecte(backfill) | Existe-t-il une procédure standard pour combler les trous de la période affectée ? |
Confier la responsabilité de la correction au prestataire constitue la valeur essentielle de l’externalisation. Cela évite que les équipes qui opèrent les DAG de l’équipe data portent la maintenance continue — réponse aux blocages, suivi des changements de sites, réparation des parseurs — et permet à l’équipe data de se concentrer sur le chargement, la modélisation et l’exploitation.
La recollecte est traitée comme une procédure standard, et non comme une exception. Les trous sont comblés en spécifiant une période et des conditions, tout en garantissant des chargements idempotents afin que les doublons ne s’accumulent pas même si une même clé est chargée plusieurs fois. Les watermarks et curseurs incrémentaux permettent de remplir précisément la seule plage concernée. Nous transmettons également les métadonnées immédiatement exploitables pour la validation après chargement (DQ), l’audit et la lignée. L’heure de collecte et les conditions de collecte (région, connexion) servent de base à l’interprétation de la valeur ; l’URL source et la fréquence de collecte sont utilisées pour l’enregistrement dans le catalogue et la lignée ; le nombre d’enregistrements et les indicateurs de valeurs manquantes/anormales alimentent les barrières de validation automatisées. De plus, un marqueur de fin (manifest/_SUCCESS) est laissé pour que l’aval puisse déterminer que le chargement est entièrement terminé, empêchant ainsi l’orchestration d’exécuter des transformations sur des chargements partiels. C’est à cette condition que l’on peut répondre, lors d’un audit, à la question : « D’où vient ce chiffre ? »
En résumé, le contrat de données pour le web externe ne promet pas « que rien ne cassera » : il définit qui est responsable de la détection, de la correction et de la recollecte en cas de rupture, et dans quel délai le rétablissement doit être effectué. C’est seulement lorsque cette propriété est inscrite dans le contrat qu’une source web externe peut être gérée en interne comme un système source bien administré.
En résumé
La raison fondamentale pour laquelle les données web externes cassent continuellement est que, contrairement aux sources internes, la source n’est pas un partenaire contractuel capable de coopérer. Les refontes sans préavis, les tests A/B et les écrans conditionnels font tomber l’hypothèse de stabilité du schéma. Le contrat de données pour le web externe ne doit donc pas affirmer « que rien ne cassera », mais expliciter les propriétaires de la détection, de la correction et de la recollecte en partant du principe que des ruptures surviendront.
Hashscraper travaille avec les équipes data de cette manière. Nous définissons ensemble le schéma, gérons les changements par notification préalable et coexistence des versions, traitons la recollecte au moyen de procédures standard basées sur des chargements idempotents et des watermarks, et transmettons les métadonnées exploitables immédiatement pour le catalogue, la lignée et la DQ, ainsi que les marqueurs de fin. Le développement, la maintenance, la réponse aux blocages et la surveillance de la collecte sont inclus dans une prestation externalisée au forfait mensuel, afin que les équipes qui opèrent les DAG ne s’épuisent pas à maintenir les collectes externes. À grande échelle également, nous avons l’expérience de l’exploitation externalisée de pipelines réguliers pour la surveillance en ligne à grande échelle d’une autorité de régulation.
Externaliser la collecte et la maintenance du web externe pour le traiter comme un système source bien administré, et permettre à l’équipe data de se concentrer sur le chargement, la modélisation et l’exploitation : telle est la voie réaliste pour alimenter de manière stable les tableaux de bord avec des données externes à l’ère des refontes de sites.
Articles à lire également
- Du moment où les données de crawling deviennent une décision
- Données reçues dans Excel vs données consultées dans un tableau de bord — ce que change le format de livraison
- Une entreprise 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
Commencez dès maintenant
Nous pouvons examiner avec vous quel contrat est nécessaire pour éviter qu’une seule refonte ne vide vos tableaux de bord des sources web externes actuellement connectées à votre pipeline. De la définition du schéma à la notification des changements, à la responsabilité de la recollecte et aux spécifications de transmission, nous concevons la solution adaptée au pipeline de votre équipe data.
