← Tous les articles
Cas d'usage 6 min de lecture

Le problème du recrawl : maintenir les pipelines RAG à jour

Votre base de connaissances RAG devient obsolète dès la semaine de son déploiement. Voici comment les équipes recrawlent des centaines de sources verticales sans exploser leur budget d'ingénierie.

ragai-trainingdata-collectionvertical-aiuse-case

Le défi

Les startups d'IA verticale se heurtent toutes au même mur vers le deuxième mois. Elles déploient un copilote de support, un assistant de recherche juridique ou un bot de conformité. La première démo séduit les clients. Puis les données vieillissent, et les réponses commencent à s'éloigner de la réalité.

Nous avons vu des équipes concevoir la partie IA proprement, tout en traitant la partie données comme une simple réflexion après coup. Le pipeline d'ingestion se résume à un script Python qui tourne sur l'ordinateur portable d'un développeur. Il extrait 200 URL sources une fois, injecte du Markdown propre dans un vector store, et tout le monde s'en réjouit. Six semaines plus tard, la moitié des réponses citent des pages supprimées, des API dépréciées ou des fonctionnalités produit déployées en mars puis modifiées en mai.

La solution semble simple: réexplorer chaque source chaque semaine. La réalité est plus difficile. En 2026, environ 60 % des sites fiables bloquent les robots d'indexation d'IA (contre 23 % fin 2023), et les protections ne se limitent plus à de simples vérifications du User-Agent. Elles analysent le comportement des sessions, le rythme des requêtes et les signaux au niveau du handshake. Un script simpliste qui fonctionnait en janvier renvoie silencieusement des pages vides en mars.

Pire encore, certains sites servent désormais du contenu tarpit (du charabia généré par chaînes de Markov qui ressemble à de la vraie prose) jusqu'à empoisonner vos embeddings. Vos ingénieurs passent donc la moitié de leur semaine à corriger le scraper au lieu de livrer des fonctionnalités. La qualité de la récupération diminue, les clients s'en aperçoivent, et l'équipe que vous avez recrutée pour développer de l'IA devient une équipe de maintenance de scrapers.

L'approche

Le problème de la réexploration se divise en trois décisions concrètes qui doivent être prises pour chaque requête:

  1. Faut-il effectuer un rendu ? La plupart des portails de documentation fournissent du HTML propre. Une part croissante (tout ce qui est bâti sur Next.js, tout ce qui utilise un rendu côté client) nécessite un rendu complet par navigateur pour renvoyer du contenu exploitable.
  2. Quel proxy choisir ? Résidentiel, datacenter, mobile, géolocalisé, spécifique à un FAI. Le bon choix varie selon la cible.
  3. Le crawl a-t-il réellement réussi ? Un code 200 avec un corps vide, ou une page de vérification, constitue une requête HTTP réussie mais une exploration échouée.

Une plateforme comme FourA traite chacun de ces points comme un élément fondamental.

Pour la décision de rendu, vous appelez Single pour les cas simples et rapides, et Browser pour les cibles lourdes en JS. Le corps de l'appel conserve la même structure, ce qui permet à votre code d'ingestion de bifurquer simplement via un indicateur par source au lieu de gérer une centaine d'exceptions propres à chaque site.

Pour la sélection de proxy, Proxy Finder s'exécute avec chaque appel Single, Browser et Auto. La plateforme choisit une sortie fonctionnelle par requête, renvoie son identifiant opaque dans la réponse (au niveau r.proxy de Single/Browser, ou r.session.proxy sur Auto), et vous réutilisez cet identifiant sur les appels suivants lorsque vous devez conserver la même sortie. Votre crawler n'a pas besoin d'embarquer son propre algorithme de classement de proxys. (Nous avons expliqué pourquoi la taille du pool n'est plus un facteur de différenciation dans Why Proxy Pool Size Stopped Mattering in 2026.)

Et pour répondre à la question « est-ce que cela a vraiment fonctionné », chaque request prend en charge un bloc validate. Vous définissez ce qui constitue un succès : codes de statut acceptés, valeurs de header requises, chaînes de caractères dans le body qui doivent ou ne doivent pas apparaître. FourA renvoie l'un des sept résultats possibles, et seul success est facturable. Un code 200 qui ne respecte pas vos règles de contenu est marqué application_fail et n'entre jamais dans votre jeu de données.

Voici à quoi ressemble un appel de recrawl pour un portail de documentation nécessitant un rendu JS. Nous laissons Auto orchestrer le tout, il sélectionne le bon produit (Single, Proxy ou Browser), gère les protections anti-bot et renvoie le triplet de session pour que le prochain recrawl conserve la même sortie :

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://docs.example.com/changelog",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["<article"], "fail": ["captcha", "Just a moment"]},
        },
    },
).json()

# r["data"] or r["body"]   — rendered content (Auto runs the right sub-product per host;
#                            Single populates "data", Browser populates "body")
# r["session"]              — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["session"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.

Si la cible renvoie un interstitiel Cloudflare, la règle validate.data.fail l'intercepte. Le résultat enregistré pour votre consommation est application_fail. Vous ne payez pas pour cela, et votre code d'ingestion sait qu'il doit réessayer avec un autre proxy au lieu d'injecter une page "Just a moment..." dans vos embeddings.

Pour l'ensemble du corpus, vous intégrez le même schéma dans votre file d'attente de jobs existante. Les équipes avec lesquelles nous avons échangé exécutent des diffs nocturnes par rapport au crawl précédent, ne recalculent les embeddings que pour les documents ayant réellement changé, et actualisent des corpus de 500 sources en deux heures de temps réel. La file d'attente reste la vôtre. Le roulement des proxys, la décision de rendu et la validation du succès sont de notre ressort.

Résultats

Voici à quoi ressemble la boucle de fraîcheur lorsque l'infrastructure cesse d'être le goulot d'étranglement (scénario illustratif basé sur les patterns observés auprès d'équipes d'IA verticale) :

  • 500 URL sources recrawlées chaque semaine, au lieu d'un crawl unique de 200 URL au lancement
  • Temps d'ingénierie sur le scraper : moins de 2 heures par semaine, contre 1 à 2 jours auparavant
  • Fenêtre d'obsolescence de la recherche : 5 à 7 jours, au lieu d'être indéfinie
  • Taux de données corrompues dans le vector store proche de zéro, car les pages de tarpit et interstitiels Cloudflare sont rejetés au niveau de la couche validate avant d'atteindre votre modèle d'embedding
  • Coût prévisible par source, car les crawls en échec n'apparaissent pas sur la facture

L'intérêt n'est pas que ces éléments soient magiques. L'intérêt est qu'ils sont prévisibles et fiables. Et la fiabilité est précisément ce dont l'IA en production a besoin. (Pour en savoir plus sur les limites de rentabilité de l'extraction par LLM hébergé, consultez Quand l'extraction par LLM cesse d'être rentable.)

Point clé

La plupart des équipes développant des IA verticales pensent que leur avantage concurrentiel réside dans le prompt, le choix du modèle ou l'algorithme de retrieval. Ce n'est pas le cas. L'avantage réside dans la boucle de fraîcheur : l'infrastructure discrète qui maintient la base de connaissances exacte semaine après semaine.

Les équipes qui s'imposeront dans l'IA verticale d'ici 2026 ne seront pas celles qui ont les prompts les plus sophistiqués. Ce seront celles dont les utilisateurs ne se demandent jamais si les données sont à jour, parce qu'elles le sont toujours.