Transformer des pages web en contexte d’agent avec Firecrawl

« Chercher sur le web » est la fonctionnalité la plus survendue des produits d’IA. La plupart du temps, ça veut dire : récupérer du HTML, espérer que le texte lisible survive, donner l’épave à un modèle et le laisser écrire quelque chose d’assuré.

Chez Notis, l’étape entre « une URL existe » et « un agent peut l’utiliser », c’est Firecrawl. Voici pourquoi cette étape mérite un outil dédié plutôt qu’un après-midi avec un client HTTP.

Du HTML brut, ce n’est pas du contexte

Une page moderne, c’est surtout autre chose que la page. La navigation, les bandeaux cookies, les murs de consentement, trois modales d’inscription à la newsletter, un pied de page avec quarante liens et, quelque part au milieu, les six paragraphes sur lesquels l’utilisateur posait vraiment sa question.

Donne ça à un modèle de langage et deux choses tournent mal. Le signal est noyé, donc la réponse dérive vers ce qui est le plus répété, en général la navigation. Et tu brûles une quantité énorme de contexte sur du balisage qui n’a aucun sens.

Et puis il y a la moitié du web qui ne fait aucun rendu côté serveur. Récupère-la et tu obtiens un <div id="root"> et une prière.

Notre outil de scraping appelle l’endpoint de scrape v2 de Firecrawl et demande du Markdown par défaut. Ce qui revient, c’est le contenu, structuré, dans le format que les modèles gèrent le mieux. Les titres restent des titres. Les listes restent des listes. Les tableaux survivent la plupart du temps. D’autres formats sont disponibles quand une tâche en a besoin, mais le Markdown d’abord est le bon choix par défaut, parce que c’est le format que le reste du pipeline parle déjà.

C’est tout l’argument, et ça paraît anodin jusqu’à ce que tu aies passé un week-end à écrire des heuristiques d’extraction qui cassent sur le premier site à la mise en page inhabituelle.

Sa place dans la boucle d’un agent

Scraper dans un agent, ce n’est pas comme scraper dans un crawler, parce que l’agent décide quoi récupérer en fonction de ce qu’il vient de lire.

Une tâche de recherche typique dans Notis ressemble à ça : quelqu’un pose une question, l’agent cherche, obtient une série de pages candidates, scrape les plus prometteuses, les lit, remarque un manque, scrape une source citée dans l’une d’elles, puis rédige une synthèse et la range là où elle doit aller.

C’est une boucle avec un humain qui attend au bout. Du coup, les modes de défaillance qui comptent sont la latence et le silence. Un scrape qui prend une éternité est pire qu’un scrape qui échoue, parce que l’agent peut contourner un échec, mais pas un blocage.

L’outil est donc conçu pour revenir : avec du contenu quand il le peut, et avec un échec clair et structuré quand il ne le peut pas. Un agent qui sait qu’une page a été bloquée peut essayer une autre source. Un agent qui reçoit une chaîne vide résume tranquillement du vide et a l’air sûr de lui.

On fait aussi tourner un heartbeat régulier sur l’endpoint de scrape. Si Firecrawl est injoignable ou si notre clé est mal configurée, je veux l’apprendre par une vérification, pas par un utilisateur qui demande pourquoi les recherches sont devenues floues cet après-midi.

Le comptage, et le bug qui nous a fait y prêter attention

C’est la partie dont je parlerais à d’autres builders, parce qu’elle nous a coûté de l’argent avant de nous coûter la moindre réflexion.

Notis a des composantes facturées à l’usage. Les outils qui coûtent de l’argent doivent être comptabilisés. Notre outil de scraping ne l’était pas au départ : il appelait l’API et renvoyait le contenu, et la consommation n’arrivait jamais dans notre comptabilité. Chaque scrape était gratuit pour l’utilisateur, mais pas pour nous.

La correction a consisté à donner au scraping une vraie spec de modèle, comme en a un modèle de langage, pour que chaque appel remonte une consommation qui passe par le même circuit de facturation que tout le reste. Un avertissement est même journalisé si la spec disparaît, parce qu’un outil qui échappe silencieusement au comptage, c’est exactement le genre de chose qui reste cassée pendant des mois.

La leçon générale : dans un produit à base d’agents, tout outil qui appelle une API payante est une surface de tarification. Ça n’en a pas l’air, parce que c’est un appel de fonction dans une boucle. Mais les agents appellent des outils bien plus souvent que les humains ne cliquent sur des boutons, et un outil que tu as oublié de compter te le fera découvrir.

Pourquoi on ne l’a pas construit nous-mêmes

Je n’ai pas de dogme sur acheter ou construire, mais le scraping est un très mauvais candidat à la construction maison.

Le travail, ce n’est pas la première version. Le travail, ce sont les proxys, les relances, le rendu des pages chargées en JavaScript, les limites de débit, les protections anti-bots, les bizarreries propres à chaque site, et un extracteur de contenu qui reste bon à mesure que le web change en dessous. C’est un engagement de maintenance permanent sur quelque chose qui n’est pas notre produit.

Une nuance honnête : toutes les capacités web de Notis ne reposent pas sur Firecrawl. La recherche est à part. La Deep research a son propre pipeline. L’automatisation de navigateur est encore un autre outil, pour les tâches qui demandent d’interagir plutôt que de lire du contenu. Firecrawl a un seul job, transformer une page en texte exploitable, et il le fait assez bien pour que j’aie arrêté d’y penser.

C’est le plus beau compliment que je puisse faire à une infrastructure.

Si tu branches ça dans un agent

• Demande du Markdown, pas du HTML. Ton modèle s’en sort mieux et ça te coûte moins de contexte.
• Rends les échecs structurés et rapides. Un agent peut s’organiser autour d’un échec connu ; il ne peut rien faire face à un blocage.
• Comptabilise chaque outil payant au moment de l’appel, et journalise bruyamment si le compteur manque.
• Mets un heartbeat sur tes fournisseurs. Une dégradation silencieuse d’un outil de recherche ressemble à un modèle qui devient moins bon.
• Ne confonds pas scraping et navigation. Lire une page et la piloter sont deux problèmes différents.

Notis est dirigé par son fondateur et s’étend encore de la capture vocale vers Notion à un travail plus large sur des outils connectés. Une bonne partie de ce travail commence par un lien que quelqu’un a collé dans WhatsApp.

Firecrawl, c’est ce qui transforme ce lien en quelque chose avec lequel l’assistant peut vraiment réfléchir. Jette un œil.