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

Le problème du recrawl : maintenir la fraîcheur des pipelines RAG

Votre base de connaissances RAG devient obsolète dès la semaine de sa mise en production. Voici comment des équipes effectuent le recrawl de 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 assistant de support, un outil de recherche juridique ou un bot de conformité. La première démo séduit les clients. Ensuite, les données vieillissent et les réponses commencent à s'écarter de la réalité.

Nous avons vu des équipes concevoir proprement la partie IA et traiter la partie données comme une réflexion après coup. Le pipeline d'ingestion est un simple script Python exécuté sur l'ordinateur portable de quelqu'un. Il scrape 200 URL sources une fois, déverse du Markdown propre dans une base de données vectorielle, et tout le monde fait la fête. Six semaines plus tard, la moitié des réponses citent des pages supprimées, des API obsolètes ou des fonctionnalités de produit lancées en mars et modifiées à nouveau en mai.

La solution semble simple : recrawler chaque source chaque semaine. La réalité est plus complexe. D'ici 2026, environ 60 % des sites réputés bloquent les crawlers d'IA (contre 23 % fin 2023), et les protections ne se limitent plus à de simples vérifications de User-Agent. Elles analysent le comportement de la session, le rythme des requêtes et les signaux au niveau du handshake. Un script naïf qui fonctionnait en janvier renvoie silencieusement des pages vides en mars.

Pire encore, certains sites proposent désormais du contenu de type 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 baisse, les clients le remarquent, et l'équipe que vous avez recrutée pour concevoir de l'IA se transforme en atelier de maintenance de scrapers.

L'approche

Le problème du recrawl se divise en trois décisions concrètes qui doivent être prises pour chaque request :

  1. Render ou pas ? La plupart des portails de documentation fournissent du HTML propre. Une part croissante (tout ce qui est construit sur Next.js, tout ce qui utilise le rendu côté client) nécessite un rendu de navigateur complet pour renvoyer un contenu utile.
  2. Quel proxy ? Résidentiel, datacenter, mobile, géolocalisé, spécifique à un FAI. Le bon choix varie selon la cible.
  3. Est-ce que cela a vraiment fonctionné ? Un code 200 avec un corps vide, ou une page HTML avec un CAPTCHA, constitue une request HTTP réussie mais un crawl échoué.

Une plateforme comme FourA traite chacun de ces points comme une priorité absolue.

Pour la décision de rendu, vous appelez Single pour les cas simples et rapides, et Browser pour les cibles riches en JS. Le corps de l'appel a la même structure, de sorte que votre code d'ingestion ne se divise qu'une seule fois selon un indicateur par source, au lieu de gérer une centaine de spécificités propres à chaque site.

Pour la sélection du proxy, Proxy Finder s'exécute lors de chaque appel Single, Browser et Auto. La plateforme choisit un point de sortie fonctionnel par request, renvoie son identifiant opaque dans la response meta.proxy, et vous réutilisez cet identifiant lors des appels suivants lorsque vous devez conserver le même point de sortie. Votre crawler n'embarque pas son propre algorithme de classement de proxy. (Nous avons expliqué pourquoi la taille du pool n'est plus le facteur de différenciation dans Pourquoi la taille du pool de proxy n'a plus d'importance en 2026.)

Et concernant la question « est-ce que cela a vraiment fonctionné », chaque request prend en charge un bloc validate. Vous déclarez ce qui définit un succès : les codes d'état acceptés, les valeurs de header requises, les chaînes de caractères qui doivent ou ne doivent pas apparaître dans le corps. 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 choisit le bon produit (Single, Proxy ou Browser), gère les protections contre les bots et renvoie le triplet de session pour que le prochain recrawl puisse utiliser le même point de 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"]    — rendered body
# r["meta"]    — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["meta"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.

Si la cible déclenche un écran intermédiaire Cloudflare, la règle validate.data.fail le détecte. Le résultat enregistré pour votre utilisation est application_fail. Vous ne payez pas pour cela, et votre code d'ingestion sait qu'il doit réessayer avec un proxy différent au lieu d'envoyer une page « Just a moment... » dans les embeddings.

Pour l'ensemble du corpus, vous intégrez ce même schéma dans votre file d'attente de tâches existante. Les équipes avec lesquelles nous avons échangé effectuent des diffs nocturnes par rapport au crawl précédent, ne génèrent de nouveaux embeddings que pour les documents qui ont réellement changé, et actualisent des corpus de 500 sources en quelques heures seulement. La file d'attente des tâches reste la vôtre. Le renouvellement des proxy, la décision de rendu et le verdict de réussite sont de notre ressort.

Résultats

Voici à quoi ressemble la boucle de fraîcheur une fois que l'infrastructure cesse d'être le goulot d'étranglement (scénario illustratif basé sur les modèles que nous observons chez les équipes d'IA verticale) :

  • 500 URL sources recrawlées chaque semaine, au lieu d'un unique crawl 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 récupération : 5 à 7 jours, au lieu d'être illimitée
  • Taux de données inutiles dans la base vectorielle proche de zéro, car les écrans intermédiaires Cloudflare et les pages tarpit 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 échoués n'apparaissent pas dans la facturation

Le but n'est pas de dire que tout cela est magique. Le but est de montrer que c'est rébarbatif. Et le rébarbatif est précisément ce dont l'IA en production a besoin. (Pour en savoir plus sur le moment où les calculs ne sont plus rentables avec l'extraction par LLM hébergé, consultez Quand l'extraction par LLM cesse d'être rentable.)

Point clé à retenir

La plupart des équipes qui conçoivent de l'IA verticale pensent que leur avantage concurrentiel réside dans le prompt, le choix du modèle ou l'algorithme de récupération. Ce n'est pas le cas. L'avantage concurrentiel réside dans la boucle de fraîcheur : cette infrastructure peu glorieuse qui garantit l'exactitude de la base de connaissances semaine après semaine.

Les équipes qui s'imposeront dans l'IA verticale d'ici 2026 ne seront pas celles qui proposeront les prompts les plus astucieux. Ce seront celles dont les utilisateurs ne remarqueront même pas que les données sont à jour, car elles le seront en permanence.