Tous les articles

Données alternatives : quand un blocage ressemble à un point de données

Les pipelines de données alternatives perdent plus à cause des échecs de collecte silencieux qu'à cause des mauvais modèles. Voici comment une page bloquée devient un faux signal, et comment l'arrêter.

La page produit d'un détaillant a répondu avec le statut 200 et rien dedans. Le pipeline n'a pas enregistré de blocage. Il a enregistré un rayon vide.

C'est l'échec que personne ne prévoit dans les données alternatives. Ni un jeu de données manquant, ni un fournisseur lent. Une couche de collecte qui continue de vous fournir des lignes tout en mesurant discrètement autre chose que l'entreprise que vous analysez.

Le défi

En janvier 2026, Exabel a interrogé 100 gestionnaires de portefeuille fondamentaux et analystes aux États-Unis, au Royaume-Uni, à Singapour et à Hong Kong, gérant environ 610 milliards de dollars à eux tous. 71 % ont cité la combinaison de données provenant de différentes sources comme la partie la plus frustrante du travail avec des données alternatives, et 94 % ont déclaré qu'ils utilisaient déjà l'IA ou l'apprentissage automatique quelque part dans leur processus de recherche.

Lisez ces deux chiffres l'un à côté de l'autre et la forme du problème apparaît. L'aspect modélisation est bien pourvu en personnel. La plomberie en dessous ne l'est pas.

Un panel collecté sur le web (prix, statut des stocks, pages carrières, nombre d'avis, assortiment de la place de marché) est une série temporelle avant tout. Chaque série temporelle comporte une hypothèse que personne n'écrit dans les spécifications : l'observation d'aujourd'hui a été collectée de la même manière que celle d'hier. Brisez cette hypothèse bruyamment et vous obtenez une alerte. Brisez-la silencieusement et vous obtenez un signal.

Trois de ces ruptures silencieuses apparaissent dans presque chaque panel collecté sur le web.

Le 200 qui n'est pas du contenu. Les défenses contre les bots ont cessé de répondre avec un 403 clair depuis longtemps. Une page de challenge, un mur de consentement ou un modèle de résultats vides arrive avec un statut de succès et un contenu que votre parseur lit comme zéro résultat. Moins d'annonces semble identique à moins de demande.

Le point de vue a changé. Prix, devise, assortiment, bannière promotionnelle, et parfois si la page s'affiche du tout : les détaillants décident de tout cela en fonction de l'origine apparente de la request. Si la collecte de lundi est sortie en Allemagne et celle de jeudi est sortie en Pologne, il y a un saut dans votre série qui vous appartient, et non au détaillant.

La rotation qui a pris la première réponse obtenue. Faites une rotation des sorties sans dire au collecteur ce que signifie un succès, et il s'arrête à la première sortie qui répond. Un refus est une response. Ainsi, la ligne atterrit, la tâche passe au vert, et personne ne regarde à nouveau.

Aucun de ces éléments ne lance d'exception. L'ingestion compte les lignes, le tableau de bord reste vert et l'analyste obtient un graphique. Ensuite, le modèle passe un trimestre à apprendre le comportement de votre infrastructure de collecte au lieu du comportement de l'entreprise.

L'approche

Traitez l'intégrité des données comme une propriété de la request, et non du parseur en aval. Trois choses doivent être vraies.

1. Indiquez à quoi ressemble une vraie page. Le collecteur n'a aucun moyen de le deviner par lui-même. Donnez-lui une chaîne de caractères présente uniquement dans le contenu authentique et quelques-unes spécifiques aux refus, et une page de challenge cessera d'être comptabilisée comme une observation. Nous avons abordé ce sujet lorsque les règles validate ont été déployées: la request elle-même décide de ce que signifie un succès.

import requests

r = requests.post(
    "https://api.foura.ai/api/proxy",
    headers={"X-API-Key": "YOUR_API_KEY"},
    json={
        "maxTries": 8,
        "exitCountries": ["DE"],
        "request": {
            "method": "GET",
            "url": "https://retailer.example/p/12345",
            "validate": {
                "status": {"accept": [200]},
                "data": {
                    "accept": ["data-testid=\"price\""],
                    "fail": ["Access Denied", "Just a moment"]
                }
            }
        }
    }
).json()

observation = r["data"]        # content your rules accepted, or nothing
exit_id = r["proxy"]           # opaque ID of the exit that delivered it
served_from = r["exitCountry"] # verify it against what you asked for

La rotation a désormais une définition de terminé. Elle continue de tester des sorties jusqu'à ce que l'une d'elles renvoie quelque chose qui respecte vos règles, au lieu de renvoyer le premier objet en forme de page qu'elle rencontre.

2. Maintenez le point d'observation fixe. exitCountries est une liste d'autorisation stricte de codes de pays visibles par la cible, et les sorties dont la géographie est inconnue sont ignorées plutôt que substituées. Deux mises en garde honnêtes, toutes deux bonnes à savoir avant de commencer à développer. Les métadonnées des pays sont actualisées selon un cycle (normalement en environ dix minutes), ce n'est donc pas une recherche en direct au moment de la request, c'est exactement pourquoi la response inclut exitCountry pour que vous puissiez vérifier. Et lorsque le pool n'a aucune correspondance pour la portée que vous avez demandée, l'appel revient avec un HTTP 200 et une enveloppe d'erreur plutôt qu'une exception. Lisez le corps, pas le statut. Conservez la portée et réessayez plus tard au lieu de l'élargir, car une portée élargie constitue une rupture dans la série.

3. Conservez l'identité de la sortie. Le champ proxy est un ID opaque, pas une adresse. Passez-le en retour lors d'un appel Single ou Browser ultérieur et la page de détails proviendra du même point d'observation que la page de recherche qui l'a trouvée (comment réutiliser une sortie). Stockez cet ID et le header X-FourA-Request-Id à côté de chaque ligne. Lorsqu'un analyste remet en question un pic six semaines plus tard, la question "était-ce réel ?" devient une simple recherche au lieu d'un débat.

Pour une source que vous intégrez et que vous ne comprenez pas encore, Auto est le moyen le plus rapide de trouver un chemin fonctionnel : elle parcourt l'échelle du moins cher au plus cher, vous indique quel échelon a gagné, et vous restitue la session qui a fonctionné. Utilisez-la pour trouver l'itinéraire, puis placez le volume de production sur les moteurs directs. Rejouez cette session via Single où rien ne nécessite de rendu, et Browser où c'est véritablement nécessaire. La recherche de chemin et la collecte en régime permanent sont des tâches différentes.

Résultats

Ce qui change lorsque ces trois propriétés sont respectées, sur un panel de quelques milliers de pages de produits par jour chez une douzaine de détaillants (scénario illustratif basé sur des références de l'industrie) :

  • Un écart est un écart, pas une supposition. Les refus n'entrent jamais dans le panel sous forme de zéros, donc un ensemble de résultats vide signifie que le détaillant n'a rien montré, et votre signal d'absence vaut la peine d'être exploité.
  • Lignes comparables. Chaque observation dans une série provient du pays dans lequel la série est définie, donc un mouvement de prix est un mouvement de prix.
  • Historique reproductible. L'ID de sortie et l'ID de la request par ligne signifient que tout point de données contesté peut être retracé jusqu'à l'appel exact qui l'a produit.
  • Moins cher par ligne utilisable. Les requests qui auraient produit une observation rejetée sont réessayées au moment de la collecte plutôt que d'être payées, analysées, stockées et ensuite supprimées d'un backtest.

Mais ce dernier point est ce que les équipes de recherche sous-estiment. Une mauvaise ligne n'est pas gratuite simplement parce qu'elle était bon marché à récupérer. Elle coûte un cycle de recherche, et parfois elle coûte la confiance de la personne qui doit valider le signal.

Point à retenir

Les acheteurs de données alternatives évaluent les fournisseurs sur la couverture, la latence et la profondeur historique. Presque personne ne pose la question qui détermine si un panel est exploitable : comment se comporte ce jeu de données le jour où la source refuse de répondre ?

Un fournisseur qui supprime la ligne est honnête. Un fournisseur qui renvoie une page de courtoisie comme observation vous a vendu une mesure de sa propre infrastructure, et vous en paierez le prix dans un backtest qui fonctionne jusqu'à ce qu'il échoue. Cette question a sa place dans chaque liste de contrôle de diligence des données, et elle a sa place dans votre propre pipeline en premier lieu, car si vous collectez les données vous-même, vous êtes le fournisseur.