← 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. Ensuite les données vieillissent, et les réponses commencent à s'éloigner de la réalité.

Nous avons vu des équipes construire la partie IA proprement et traiter la partie données après coup. Le pipeline d'ingestion est un script Python qui tourne sur l'ordinateur de quelqu'un. Il scrape 200 URL sources une fois, pousse du Markdown propre dans un vector store, et tout le monde se réjouit. Six semaines plus tard, la moitié des réponses citent des pages supprimées, des API obsolètes ou des fonctionnalités produit sorties en mars puis de nouveau en mai.

La solution semble simple : recrawler chaque source chaque semaine. La réalité est plus compliquée. D'ici 2026, environ 60 % des sites réputés bloquent les crawlers d'IA (contre 23 % fin 2023), et les protections ne sont plus de simples vérifications de User-Agent. Elles analysent le comportement de 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 servent désormais du contenu piège (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 du produit. La qualité du retrieval baisse, les clients le remarquent, et l'équipe que vous avez embauchée pour faire de l'IA devient un atelier de maintenance de scraper.

L'approche

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

  1. Rendu ou pas ? La plupart des portails de documentation servent du HTML propre. Une part croissante (tout ce qui est construit sur Next.js, tout ce qui a un rendu côté client) nécessite un rendu navigateur complet pour renvoyer du 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 ça a vraiment marché ? Un 200 avec un body vide, ou une page HTML de CAPTCHA, est une HTTP request réussie et un crawl raté.

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 chargées en JS. Le body de l'appel a la même structure, ce qui permet à votre code d'ingestion de se diviser une seule fois via un flag par source au lieu de gérer des centaines de particularités spécifiques aux sites.

Pour la sélection du proxy, Proxy Finder s'exécute lors de chaque appel Single, Browser et Auto. La plateforme choisit une sortie fonctionnelle par request, renvoie son id opaque dans la response (au r.proxy niveau principal pour Single/Browser, ou r.session.proxy pour Auto), et vous réutilisez cet id lors des appels suivants quand vous devez conserver la même sortie. Votre crawler n'intègre pas son propre algorithme de classement de proxy. (Nous avons expliqué pourquoi la taille du pool n'est plus le facteur différenciant dans Pourquoi la taille du pool de proxy n'a plus d'importance en 2026.)

Et pour la question "est-ce que ça a vraiment marché", chaque request prend en charge un bloc validate. Vous déclarez ce qui compte comme un succès : les codes de statut acceptés, les valeurs de header requises, les chaînes du body qui doivent ou ne doivent pas apparaître. FourA renvoie l'un des sept résultats, et seul success est facturable. Un 200 qui échoue à vos règles de contenu est marqué application_fail et n'entre jamais dans votre dataset.

Voici à quoi ressemble un appel de recrawl pour un portail de documentation qui nécessite un rendu JS. Nous laissons Auto orchestrer, il choisit le bon produit (Single, Proxy, ou Browser), gère les défenses anti-bots, et renvoie le triplet de session pour que le prochain recrawl puisse garder 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 affiche un interstitiel Cloudflare, la règle validate.data.fail l'intercepte. Le résultat appliqué à votre utilisation 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'intégrer une page "Veuillez patienter..." dans les embeddings.

Pour le corpus plus large, vous enveloppez le même modèle dans votre file d'attente existante. Les équipes avec lesquelles nous avons échangé exécutent des diffs nocturnes par rapport au crawl précédent, ré-embarquent uniquement les documents qui ont réellement changé, et rafraîchissent des corpus de 500 sources en quelques heures. La file d'attente reste la vôtre. Le roulement de proxy, la décision de rendu, le verdict de succès sont les nôtres.

Résultats

À quoi ressemble la boucle de fraîcheur une fois que l'infrastructure n'est plus le goulot d'étranglement (scénario illustratif basé sur les modèles que nous observons au sein des équipes d'IA verticale) :

  • 500 URL sources recrawlées chaque semaine, au lieu d'un lancement unique de 200 URL
  • Temps d'ingénierie sur le scraper : moins de 2 heures par semaine, contre 1 à 2 jours
  • Fenêtre d'obsolescence du retrieval : 5 à 7 jours, au lieu d'être illimitée
  • Taux de déchets dans le vector store proche de zéro, car les interstitiels Cloudflare et les pages pièges 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

L'idée n'est pas de dire que tout cela est magique. L'idée est que c'est ennuyeux. Et l'ennui est ce dont l'IA en production a besoin. (Pour en savoir plus sur les limites financières de l'extraction par LLM hébergé, voir Quand l'extraction par LLM cesse d'être rentable.)

Ce qu'il faut retenir

La plupart des équipes qui construisent de l'IA verticale pensent que leur avantage concurrentiel est le prompt, le choix du modèle ou l'algorithme de retrieval. Ce n'est pas le cas. L'avantage concurrentiel est la boucle de fraîcheur : l'infrastructure peu glamour qui maintient la base de connaissances fiable semaine après semaine.

Les équipes qui s'imposeront dans l'IA verticale jusqu'en 2026 ne seront pas celles qui auront les prompts les plus astucieux. Ce seront celles dont les utilisateurs ne remarqueront jamais que les données sont à jour, car elles le sont toujours.