Un ingénieur ouvre Dawn et demande : « Scrape https://topstartups.io/ et donne-moi les 10 premières startups, avec leurs noms, descriptions, siège social, année de création, URL, réseaux sociaux, sous forme de tableau. »
L'agent réfléchit un instant, récupère la page, parse les listes, consulte 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. Sièges sociaux répartis entre Brooklyn, New York, Londres, San Francisco, Remote. LinkedIn pour la plupart. Années de fondation de 2020 à 2026.
Ce tableau est le résultat de quelques appels FourA.
Cette semaine, Dawn a intégré FourA comme outil de premier ordre au sein de sa plateforme d'agents. Il se trouve dans leur grille d'intégrations aux côtés de Notion, GitHub et Google Drive. Les agents disposant de l'accès à FourA peuvent récupérer une page web publique ou un endpoint HTTP, parser la réponse (y compris le JSON), soumettre un formulaire, vérifier l'accessibilité et extraire du texte ou des liens spécifiques à partir des données reçues. Chaque agent dispose d'un accès explicite ou n'en a pas. Une gouvernance par agent, sans le piège du « chaque agent a accès à tout Internet ».
Ce qui est intéressant n'est pas qu'un agent puisse interroger une URL. La recherche web existe sur 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 distinctes. La recherche sert à répondre à « que dit Internet à propos de X ? ». Des informations larges, génératives, de niveau synthèse. L'extraction sert à répondre à « voici l'URL ou l'endpoint, récupère-le et donne-moi la réponse structurée ». Exigences de fiabilité différentes, profils de coût différents, modes d'échec 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 capacité /web-research pour la tâche globale. FourA sert pour la tâche ciblée. Un agent choisit le bon outil selon ce dont il a réellement besoin. Et c'est le schéma 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 lit ceci
Dawn expose FourA sous la forme de huit outils nommés, chacun correspondant à un schéma d'extraction courant :
foura_fetch_pagepour les pages HTML et textefoura_extract_textpour du contenu lisible et proprefoura_extract_linkspour la navigation, les formulaires, les scripts et les stylesfoura_fetch_jsonpour les endpoints d'APIfoura_head_urlpour les en-têtes, le statut, les redirectionsfoura_probe_sitepour des vérifications rapides d'accessibilitéfoura_submit_formpour les soumissions de formulaires sans connexionfoura_single_requestpour du HTTP arbitraire
L'agent fait son choix selon ce que la requête exige. La requête topstartups ci-dessus en a utilisé trois de manière séquentielle : une récupération, une extraction, un suivi.
L'intégration est suffisamment simple pour être réalisée en une journée. Deux variantes de requêtes opèrent sous le capot : un mode direct avec une signature de requête de niveau navigateur pour les sites qui ne filtrent pas agressivement, et un mode routé par proxy pour tout le reste. Les deux partagent la même structure de requête : URL, en-têtes et corps optionnels, parsing de réponse optionnel. L'agent choisit en fonction de ce que le site cible exige.
Le contrat qu'une plateforme propose à ses agents ressemble généralement à :
- Un ensemble restreint de capacité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 bascule vers le mode direct lorsque la latence ou le coût importe
- Des permissions par agent afin que les clients de la plateforme conservent la gouvernance
- Un parsing de réponse structurée exposé sous forme de paramètre d'outil, et non enfoui dans un prompt système
Mais la partie que la plupart des ingénieurs plateforme sous-estiment se situe au niveau des cas limites. Le scénario des 80 % (une requête réussit en 200 ms, renvoie du HTML propre) est la moitié facile. Les 20 % restants (les sites qui bloquent sur la signature de la requête, qui injectent un challenge JS dans la réponse, qui renvoient une 403 sur un bloc d'IP cloud) déterminent si votre agent livre une réponse correcte ou une hallucination. Nous avons reconstruit notre chemin de requête précisément pour ces cas limites, 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 constamment comment leurs agents peuvent « simplement vérifier cette URL », voici la marche à suivre. La documentation est disponible sur /docs. Nous nous ferons un plaisir 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 nécessitant de consulter une véritable page web en temps réel, il répond correctement au lieu de deviner ou de s'excuser.
C'est le résultat direct d'une primitive d'extraction suffisamment fiable pour figurer aux côtés de GitHub et Google Drive dans une grille d'intégrations. Ce n'est plus un projet de recherche. Cela devient de l'infrastructure de base.
Pourquoi c'est important
Il y a six mois, un agent devant lire une page web relevait du développement sur mesure. Des prompts personnalisés, des scrapers fragiles, des logiques de retry bricolées à la main, un taux de réussite de 60 % les bons jours. L'architecture n'était pas adaptée car cette couche n'existait pas encore. De plus, les sites ciblés par l'agent évoluaient constamment. La détection de bots est passée de signaux statiques à des contrôles comportementaux, ce qui a dégradé les scrapers artisanaux plus vite que les équipes ne pouvaient les maintenir.
Aujourd'hui, cette couche se structure. Dawn s'en est emparé et a déployé une intégration. Nous prévoyons que d'autres plateformes d'agents feront de même cette année, et que le contrat va converger : un outil dédié à la recherche, un outil dédié à l'extraction, une gouvernance par agent, un coût prévisible.
Nous n'en sommes qu'au début. Mais c'est ainsi qu'un standard émerge. Lorsqu'une capacité cesse d'être un projet pour devenir un simple composant prêt à l'emploi.
Si vous développez une plateforme d'agents et souhaitez adopter ce même modèle, contactez-nous. Si vous construisez des agents sur Dawn, FourA est déjà disponible. Il vous suffit de l'activer.