Firecrawl : alimenter un RAG local avec des pages web

#Le problème que ça résout

Donner une page web à un modèle local en lui collant son code HTML gâche l'essentiel de la fenêtre de contexte en balises, en menus et en scripts. Pire : le modèle traite les entrées de navigation comme du contenu et vous répond à côté. Toute chaîne de recherche documentaire sérieuse commence donc par une étape d'extraction qui répond à une seule question : dans cette page, qu'est-ce qui est l'article ?

Firecrawl fait ce travail, et la logique de parcours qui va autour : suivre les liens internes, s'arrêter à une limite que vous fixez, exécuter le JavaScript des sites qui n'affichent rien sans lui, et rendre un résultat structuré par page. La sortie est du markdown ou du JSON, deux formats qui se découpent proprement en morceaux pour l'indexation.

#Scrape, crawl, map, extract : quatre métiers différents

Deux habitudes évitent la majorité des mauvaises surprises : lancer un map avant un crawl, pour voir la forme du site avant de lancer un travail dessus ; et fixer une limite de pages explicite à chaque crawl, parce qu'une documentation avec pagination et variantes de langue est souvent dix fois plus grande qu'elle n'en a l'air.

#L'héberger chez soi

C'est la voie qui nous intéresse si l'objectif est de garder la chaîne sur votre matériel. Il s'agit d'une pile Docker Compose : le service d'API, un worker, une file d'attente, et éventuellement un service de navigateur sans interface pour les pages qui n'existent qu'une fois le JavaScript exécuté. Vous clonez le dépôt, copiez le fichier d'environnement d'exemple, démarrez la pile, et l'API répond sur un port local avec les mêmes formats de requête que la version en ligne.

1. 01
   Lire d'abord la page d'auto-hébergement du projet
2. 02
   Trancher la question du navigateur
3. 03
   Vérifier la licence contre votre usage

#Où ça se place dans un RAG local

Une chaîne locale qui fonctionne compte quatre étages, et Firecrawl n'occupe que le premier : l'ingestion transforme les adresses en documents ; le découpage et l'encodage les convertissent en vecteurs avec un modèle d'embedding local ; une base vectorielle stocke ces vecteurs et renvoie les passages les plus proches d'une question ; enfin un modèle local rédige la réponse à partir de ces passages.

Pour des fichiers déjà présents sur votre disque — PDF, documents bureautiques, présentations — ce n'est pas un robot d'exploration qu'il vous faut mais un convertisseur de documents. Et si votre besoin est qu'un modèle consulte le web au moment où il répond, plutôt qu'un corpus ingéré à l'avance, un métamoteur de recherche auto-hébergé est la brique adaptée : il renvoie des résultats à la demande au lieu d'un index à rafraîchir.

• Construire un RAG local de bout en bout avec Python
• Quel modèle d'embedding pour du français
• Donner la recherche web à un modèle local avec SearXNG

#Quand ne pas l'utiliser

#Le point de vigilance juridique

Collecter automatiquement des pages engage votre responsabilité, pas celle de l'outil. Les conditions générales du site visé, ses directives robots, le droit applicable et l'usage que vous faites du contenu comptent davantage que la technique employée. Pour un corpus interne d'entreprise, la question se double de celle du traitement des données personnelles éventuellement présentes dans les pages collectées.

#FAQ