Extraire un site web en Markdown pour alimenter un RAG

Un RAG ne vaut que ce que valent les documents qu'on lui donne. Si la base contient des menus de navigation, des bandeaux cookies et trois copies de la même page, le modèle retrouvera ce bruit au moment de répondre. Extraire un site en Markdown sert à éviter ça : on garde les titres, les listes, les tableaux et le code, on jette le reste, et chaque morceau reste rattaché à son URL d'origine.

Ce guide décrit la méthode dans l'ordre où elle se pratique, depuis la vérification des règles du site jusqu'au rafraîchissement de la base. Les exemples de requêtes viennent des documentations officielles de Firecrawl et de Context.dev, consultées le 30 octobre 2026. Si vous hésitez encore entre RAG et fine-tuning, commencez par RAG ou fine-tuning.

Réponse courte

Vérifiez d'abord que le site autorise l'accès automatisé, dans ses conditions d'utilisation et dans son robots.txt. Listez ensuite les URL utiles avant de lancer quoi que ce soit, puis fixez une limite de pages et un filtre de chemin. Demandez seulement le contenu principal en Markdown, et conservez avec chaque page son URL, son code HTTP et la date d'extraction. Une API comme Firecrawl ou Context.dev prend en charge le rendu JavaScript et la conversion. Elle ne décide pas à votre place de ce que vous avez le droit d'extraire.

Avant d'extraire : conditions d'utilisation et robots.txt

Deux documents disent ce qu'un site accepte. Les conditions d'utilisation (CGU) peuvent interdire la collecte automatisée, ou la réutilisation du contenu en dehors d'un usage personnel. Le fichier robots.txt, à la racine du domaine, indique quels chemins les robots sont priés de ne pas visiter. Le protocole est normalisé par la RFC 9309, qui précise que ces règles ne constituent pas une autorisation d'accès [1]. Autrement dit, un chemin absent du robots.txt n'est pas pour autant ouvert à toute réutilisation : les CGU et le droit d'auteur continuent de s'appliquer.

Les deux éditeurs cités ici renvoient la responsabilité à l'utilisateur. Context.dev demande de respecter les conditions d'utilisation et les directives robots.txt des sites ciblés, et précise que cette responsabilité ne lui est pas transférée [2]. Le dépôt de Firecrawl indique que respecter les règles des sites revient à l'utilisateur final, et que Firecrawl respecte le robots.txt par défaut [3].

Ces services annoncent aussi gérer les proxies et certaines protections contre les robots. Ce n'est pas une permission. Si un site refuse l'accès automatisé, ne l'aspirez pas : cherchez une API officielle, un export, ou demandez l'accord de l'éditeur. Pour votre propre documentation, ou celle d'un projet qui publie ses pages sous une licence ouverte, la question est souvent réglée d'avance. Si les pages contiennent des données personnelles, leur traitement relève en plus du RGPD.

Délimiter le périmètre avant de crawler

Un crawl sans limite consomme des crédits sur des pages que vous ne voulez pas : archives de tags, versions traduites, pages de connexion. Commencez par lister les URL.

Firecrawl et Context.dev ont tous deux une opération Map qui renvoie les URL d'un domaine sans en extraire le contenu [4][5]. Regardez la liste, repérez le préfixe qui contient la documentation utile (par exemple /docs/), et notez les sections à exclure.

Fixez ensuite trois bornes : un nombre maximal de pages, une profondeur de liens et un filtre de chemin. Chez Firecrawl, la limite par défaut d'un crawl est de 10 000 pages, et chaque page coûte au moins 1 crédit [6]. Mettez donc toujours limit vous-même. Chez Context.dev, maxPages vaut 100 par défaut et plafonne à 500 par appel [7].

Extraire avec Firecrawl

Le crawl de Firecrawl découvre les pages par le sitemap et par les liens, et renvoie pour chacune du Markdown et des métadonnées, dont sourceURL et statusCode [6]. L'exemple suivant vient de la documentation officielle. Il limite le crawl à 100 pages, demande du Markdown et accepte une copie en cache de moins d'une heure [8] :

from firecrawl import Firecrawl
from firecrawl.v2.types import ScrapeOptions

firecrawl = Firecrawl(api_key="fc-YOUR_API_KEY")

# Crawl with cached scraping - 500% faster for pages we've seen recently
crawl_result = firecrawl.crawl(
    'https://firecrawl.dev',
    limit=100,
    scrape_options=ScrapeOptions(
        formats=['markdown'],
        max_age=3600000  # Use cached data if less than 1 hour old
    )
)

for page in crawl_result.data:
    print(f"URL: {page.metadata.source_url}")
    print(f"Content: {page.markdown[:200]}...")

Remplacez l'URL de départ par la vôtre et ajustez limit. Les résultats d'un crawl restent disponibles par l'API pendant 24 heures après la fin du travail [6]. Enregistrez-les tout de suite. Les pages que Firecrawl n'a pas pu lire, y compris celles bloquées par le robots.txt, ne figurent pas dans data : elles se consultent par un endpoint d'erreurs dédié [6]. Une page renvoyée avec un code 404 apparaît en revanche dans les résultats et coûte 1 crédit [9]. Filtrez sur statusCode avant d'indexer.

Firecrawl peut aussi être auto-hébergé avec Docker Compose, ce qui garde l'extraction sur votre infrastructure. Mises à jour et sécurité sont alors à votre charge [10].

Découvrir Firecrawl

Lien affilié : Vibarche peut recevoir une commission si vous souscrivez, sans surcoût pour vous.

Extraire avec Context.dev

Le crawl de Context.dev suit les liens depuis une URL de départ et renvoie jusqu'à 500 pages en Markdown dans une seule réponse [7]. La documentation donne ce corps de requête pour POST /web/crawl, qui borne le nombre de pages, la profondeur, le chemin et la durée [7] :

{
  "url": "https://example.com/docs",
  "maxPages": 50,
  "maxDepth": 2,
  "urlRegex": "^https://example[.]com/docs/",
  "stopAfterMs": 60000
}

Le champ partial de la réponse signale un crawl arrêté avant la fin par une échéance [11]. Vérifiez-le avant de considérer la base comme complète. Pour une seule page, l'opération Scrape accepte une option qui ne garde que le contenu principal. Voici l'exemple de la documentation, qui retire aussi les liens du Markdown [12] :

{
  "url": "https://example.com",
  "formats": {
    "markdown": true
  },
  "sharedParams": {
    "mainContentOnly": true
  },
  "markdownParams": {
    "includeLinks": false
  }
}

Une réponse HTTP 200 peut contenir une sortie en échec. Contrôlez success sur chaque format avant de lire data [13]. Au-delà de 500 pages, la documentation renvoie vers les traitements par lots [7].

Découvrir Context.dev

Lien affilié : Vibarche peut recevoir une commission si vous souscrivez, sans surcoût pour vous.

Nettoyer et découper le Markdown

Même avec l'option « contenu principal », relisez quelques pages au hasard. Des pieds de page, des blocs « articles similaires » ou des boutons de partage passent parfois. Supprimez-les avec une règle simple, appliquée à tout le lot, plutôt que page par page.

Découpez ensuite par titres. Le Markdown garde la hiérarchie #, ##, ###, et une section complète sous un titre est en général un meilleur morceau qu'un découpage au nombre de caractères qui coupe un tableau en deux. Gardez les blocs de code entiers. Si une section reste trop longue pour votre modèle d'embedding, coupez-la par paragraphes en répétant le titre de la section en tête de chaque morceau.

Dédoublonnez avant d'indexer. Une même page peut être servie sous plusieurs URL (avec ou sans barre finale, avec un paramètre de suivi). Une empreinte du texte nettoyé suffit à repérer les copies.

Garder la source et la date

Chaque morceau indexé doit porter au moins l'URL d'origine, le titre de la page et la date d'extraction. Sans URL, votre application ne pourra pas citer sa source, et l'utilisateur ne pourra pas vérifier. Sans date, vous ne saurez pas quelle partie de la base est périmée.

C'est la même discipline que pour un PDF : le guide lire un PDF avec Claude, puis citer montre comment exiger des citations vérifiables. Pour des questions qui demandent une information du jour plutôt qu'une base constituée à l'avance, la recherche web citée avec Claude est souvent plus adaptée qu'un RAG.

Rafraîchir sans tout relancer

Les deux services renvoient une copie en cache par défaut. Chez Firecrawl, la fenêtre est de deux jours, et une page servie depuis le cache coûte quand même 1 crédit [8]. Chez Context.dev, elle est de trois jours, et maxAgeMs: 0 demande une capture fraîche [14]. Pour une première extraction, ce cache convient. Pour une mise à jour destinée à capter les changements récents, réduisez la fenêtre ou passez-la à zéro.

Plutôt que de recrawler tout le site, comparez la nouvelle liste d'URL à l'ancienne, extrayez seulement les pages nouvelles ou modifiées, et retirez de l'index celles qui ont disparu. Calez la fréquence sur le rythme de publication du site : une documentation qui bouge une fois par mois n'a pas besoin d'être relue chaque nuit, et le site visité reçoit moins de requêtes.

Ce qui peut casser

Un crawl qui renvoie moins de pages que prévu n'est pas forcément en panne. Le robots.txt peut bloquer une partie du site, le filtre de chemin peut être trop strict, ou le site peut exposer moins de liens que vous ne le pensiez. Chez Context.dev, maxPages est un maximum, pas une promesse [7].

Une page qui se charge en JavaScript peut arriver vide si le rendu n'a pas eu le temps de se terminer. Un Markdown vide chez Context.dev peut aussi venir d'un filtre de contenu qui n'a rien trouvé [12]. Relisez la page dans un navigateur avant de relancer.

Enfin, le contenu extrait reste une donnée non fiable. Une page peut contenir des instructions écrites pour détourner un modèle. Ne laissez pas un texte récupéré déclencher seul une action de votre application.

Pour aller plus loin

Sources

Pages consultées le 30 octobre 2026.