Un ingénieur ouvre Dawn et demande : "Scrape https://topstartups.io/ et donne-moi les 10 premières startups, avec leurs noms, descriptions, sièges sociaux, années de création, URL, pages de réseaux sociaux, le tout sous forme de tableau."
L'agent réfléchit un instant, récupère la page, analyse les annonces, suit le profil de chaque startup et renvoie le tableau. Dix lignes. Chaque colonne est remplie. Pogo, Auctor, Scalify, Omnea, Rivan, Listen Labs, Doppel, Blossom, Avoca, Traba. Des sièges sociaux répartis entre Brooklyn, New York, Londres, San Francisco, Remote. LinkedIn pour la plupart. Années de création de 2020 à 2026.
Ce tableau est le résultat d'une poignée d'appels FourA.
Cette semaine, Dawn a intégré FourA comme un outil de premier plan au sein de sa plateforme d'agents. Il figure dans leur grille d'intégrations aux côtés de Notion, GitHub et Google Drive. Les agents disposant d'un accès à FourA peuvent récupérer une page web publique ou un endpoint HTTP, analyser la response (y compris le JSON), soumettre un formulaire, vérifier l'accessibilité et extraire du texte ou des liens spécifiques à partir du contenu retourné. Chaque agent dispose d'un accès explicite ou n'en a pas. Une gouvernance par agent, évitant le piège classique consistant à donner accès à tout Internet à chaque agent.
Ce qui est intéressant, ce n'est pas qu'un agent puisse interroger une URL. La recherche web existe dans les plateformes d'agents depuis un an. Ce qui est intéressant, c'est la forme de l'outil qui émerge.
La recherche web et l'extraction d'URL sont deux tâches différentes. La recherche sert à répondre à la question « que dit Internet à propos de X ? ». Des informations larges, génératives, de l'ordre du résumé. L'extraction sert à dire « voici l'URL ou l'endpoint, récupère-le et donne-moi la réponse structurée ». Des exigences de fiabilité différentes, des profils de coûts différents, des modes de défaillance différents. Les mélanger dans un seul outil produit un résultat médiocre pour les deux.
L'intégration de Dawn les traite séparément. Ils disposent d'une fonctionnalité /web-research pour la tâche globale. FourA est utilisé pour la tâche ciblée. Un agent choisit le bon outil en fonction de ses besoins réels. Et c'est le modèle de maturation que nous commençons à observer sur les plateformes d'agents en 2026 : l'extraction passe du statut de « recherche greffée » à celui de primitive à part entière.
Pour l'ingénieur plateforme qui nous lit
Dawn expose FourA sous la forme de huit outils nommés, chacun correspondant à un modèle d'extraction courant :
foura_fetch_pagepour les pages HTML et textefoura_extract_textpour un contenu propre et lisiblefoura_extract_linkspour la navigation, les formulaires, les scripts et les stylesfoura_fetch_jsonpour les endpoints APIfoura_head_urlpour les headers, statuts et redirectionsfoura_probe_sitepour des vérifications rapides d'accessibilitéfoura_submit_formpour des soumissions de formulaires sans connexionfoura_single_requestpour du HTTP arbitraire
L'agent choisit en fonction des exigences de la question. La requête topstartups ci-dessus en a utilisé trois successivement : une récupération, une extraction, un suivi.
L'intégration est assez simple pour être réalisée en une journée. Deux variantes de request s'exécutent en arrière-plan : un mode direct avec un fingerprinting de niveau navigateur pour les sites qui ne bloquent pas agressivement, et un mode routé par proxy pour tout le reste. Les deux partagent la même structure de request : URL, headers et corps optionnels, analyse de la response optionnelle. L'agent choisit en fonction des exigences du site cible.
Le contrat qu'une plateforme propose à ses agents ressemble généralement à ceci :
- Un ensemble restreint de fonctionnalités (fetch / extract / probe / submit), chacune avec une définition d'outil ciblée que l'agent peut utiliser
- Le mode proxy par défaut, avec un repli sur le mode direct lorsque la latence ou le coût sont prioritaires
- Une autorisation par agent pour que les clients de la plateforme conservent la gouvernance
- Une analyse structurée de la response exposée en tant que paramètre d'outil, et non enfouie dans un prompt système
Mais la partie que la plupart des ingénieurs plateforme sous-estiment est ce qui se passe aux extrêmes. Le cas des 80 % (une récupération réussit en 200 ms, renvoie du HTML propre) est la partie facile. Les 20 % restants (les sites qui bloquent sur le fingerprint TLS, qui injectent un challenge JS dans la response, qui renvoient une erreur 403 sur un bloc d'adresses IP cloud) déterminent si votre agent fournit une réponse correcte ou une hallucination. Nous avons reconstruit notre chemin de request précisément pour ces cas extrêmes, et la différence entre « semble fiable » et « réellement fiable » représente la majeure partie du travail.
Si vous gérez une plateforme d'agents et que vos clients vous demandent sans cesse comment leurs agents pourraient « simplement vérifier cette URL », voici le modèle à suivre. La documentation est disponible sur /docs. Nous serons ravis de vous guider.
Pour tous les autres
Vous ne verrez rien de tout cela. Vous remarquerez simplement que lorsque vous posez à un assistant IA une question qui nécessite de consulter une page web réelle à l'instant t, il répond correctement au lieu de deviner ou de s'excuser.
C'est le résultat concret pour l'utilisateur d'une primitive d'extraction suffisamment fiable pour figurer aux côtés de GitHub et Google Drive dans une grille d'intégrations. Cela cesse d'être un projet de recherche. Cela devient de la tuyauterie.
Pourquoi c'est important
Il y a six mois, un agent devant lire une page web nécessitait un développement sur mesure. Des prompts personnalisés, des scrapers fragiles, des tentatives de rejeu codées à la main, un taux de réussite de 60 % dans un bon jour. La structure n'était pas adaptée car cette couche n'existait pas encore. Et les sites ciblés par l'agent changeaient constamment. Les technologies anti-bots sont passées de signaux statiques à des contrôles comportementaux, de sorte que les scrapers bricolés se dégradaient plus vite que les équipes ne pouvaient les corriger.
Aujourd'hui, cette couche est en train de se structurer. Dawn s'en est emparé et a déployé une intégration. Nous nous attendons à ce que d'autres plateformes d'agents suivent cette année, et à ce que le contrat converge : un outil dédié pour la recherche, un outil dédié pour l'extraction, une gouvernance par agent, des coûts prévisibles.
Nous n'en sommes qu'au début. Mais c'est à cela que ressemble l'émergence d'une technologie. Quand une fonctionnalité cesse d'être un projet pour devenir un simple branchement.
Si vous développez une plateforme d'agents et souhaitez proposer la même structure, contactez-nous. Si vous construisez des agents sur Dawn, FourA est déjà disponible. Il vous suffit de l'activer.