Navigateurs distants: Infrastructure Web pour agents IA comparée

Les agents IA s'appuient sur des navigateurs distants pour automatiser les tâches web sans être bloqués par les mesures anti-scraping. La performance de cette infrastructure de navigateur est cruciale pour le succès d'un agent.

Nous avons évalué 8 fournisseurs sur le taux de réussite, la vitesse et les fonctionnalités. Pour ce faire, nous avons exécuté 160 tâches automatisées, en exécutant 4 scénarios distincts 5 fois pour chaque service afin de mesurer leurs performances réelles. Nous avons également effectué un test de charge avec 250 agents IA parallèles.

Meilleurs résultats du benchmark des navigateurs distants

Voici les meilleurs navigateurs distants basés sur leurs capacités et performances lors de notre benchmark :

Le score composite est la moyenne des scores de taux de réussite, de vitesse et de fonctionnalités. Il reflète les performances de base d'un fournisseur dans des scénarios de tâche unique.

Le score d'évolutivité représente le taux de réussite d'un fournisseur lors de notre test de charge à haute concurrence. Cette métrique évalue explicitement la stabilité et la fiabilité de l'infrastructure lorsqu'elle est soumise à un volume élevé de tâches parallèles. Comme ce test de charge intensif n'a pas pu être effectué pour tous les fournisseurs, le score d'évolutivité est présenté comme une métrique distincte.

Chaque composant de notre système de notation est expliqué ci-dessous :

Taux de réussite

L'évaluation des résultats du benchmark démontre des distinctions de capacités entre les principaux fournisseurs :

• Bright Data a atteint un taux de réussite de 95%.
• BrowserAI, Steel.dev et Anchor Browser ont un taux de réussite de 85%, 70% et 70%, respectivement.
• Browserbase et Airtop ont des taux de réussite inférieurs (50% et 40%, respectivement).

Pour comprendre comment nous avons calculé ces taux de réussite, veuillez consulter notre méthodologie des navigateurs distants.

Vitesse

• Bright Data a un score de vitesse de 100%
• BrowserAI a le temps de démarrage du navigateur le plus court (moyenne 1 sec).
• Airtop a le temps de navigation le plus long (moyenne 160 sec).

Le score de vitesse quantifie le débit du service de navigateur distant, proxy le nombre de tâches réussies accomplies par unité de temps définie. Il reflète l'efficacité globale et la capacité de traitement.

Le temps de navigation pour les résultats corrects (moy) mesure le temps moyen écoulé spécifiquement pendant l'interaction active du navigateur distant avec les pages web pour les tâches individuelles réussies. Cela inclut le temps passé à la navigation sur les pages, au rendu JavaScript et aux interactions directes avec les éléments (par exemple, les clics, la saisie).

• Cette métrique exclut tout délai délibéré côté agent ou temps de traitement des composants externes comme les grands modèles de langage (LLMs).

Le temps de démarrage du navigateur (moy) mesure le temps moyen nécessaire pour que la session du navigateur distant soit prête, après la demande initiale de création ou de connexion à une session.

Le temps total pour les résultats corrects (moy) représente la durée moyenne de bout en bout pour les tâches individuelles terminées.

• Cette métrique inclut le temps de démarrage du navigateur, tous les temps de navigation/interaction actifs, tout traitement côté agent ou délai délibéré, et les latences de communication avec les services externes (par exemple, les LLMs) qui font partie du flux d'exécution de la tâche.

Pour comprendre comment ces scores sont calculés et ce qui distingue les navigateurs les plus performants, veuillez consulter notre méthodologie du temps total pour les résultats corrects.

Évolutivité

Notre test de charge, exécuté conformément à la méthodologie de benchmark d'évolutivité des navigateurs distants, a utilisé 250 agents simultanés pour mesurer les performances de l'infrastructure sous contrainte. Le test a révélé les différences clés suivantes :

• BrowserAI a atteint le taux de réussite le plus élevé avec 86.4%, se terminant en 220 secondes.
• Bright Data a enregistré un taux de réussite de 81.2%, avec un temps d'exécution total de 254 secondes.
• ZenRows a terminé avec un taux de réussite de 51.2% et un temps d'exécution total de 195 secondes.

Raisons des différences de performance

Nos résultats de benchmark montrent des différences de fiabilité, de vitesse et d'évolutivité entre les principaux fournisseurs de navigateurs distants. Ces différences proviennent principalement de variations dans la conception de l'infrastructure, la gestion des sessions et le développement de fonctionnalités axées sur l'automatisation.

1. Stratégies d'infrastructure et d'allocation des ressources

Les fournisseurs disposant d'une infrastructure distribuée plus avancée obtiennent généralement des scores de réussite et de vitesse plus élevés.

• Bright Data domine avec un taux de réussite de 95% et un score de vitesse parfait de 100%, ce qui suggère un équilibrage de charge solide, un provisionnement rapide des instances de navigateur et une isolation stable des sessions.
• BrowserAI, bien que légèrement derrière Bright Data en taux de réussite, affiche le temps de démarrage le plus rapide (1 sec), indiquant un amorçage d'instance hautement optimisé.

En revanche, les fournisseurs moins performants tels que Airtop et Browserbase peuvent s'appuyer sur des files d'attente de provisionnement plus lentes ou des environnements d'exécution moins optimisés, contribuant à leurs taux de réussite inférieurs (40–50%) et à des temps de navigation ou d'exécution totaux nettement plus élevés.

2. Optimisations du moteur de navigateur et préparation à l'automatisation

Les taux de réussite diffèrent considérablement selon la manière dont chaque fournisseur prend en charge les modèles d'interaction automatisée tels que le remplissage de formulaires, le rendu DOM, la navigation et les workflows intensifs en JavaScript.

• Bright Data, BrowserAI et Steel.dev accomplissent systématiquement les tâches impliquant la navigation, l'analyse et l'interaction parce que leurs navigateurs semblent optimisés pour les charges de travail d'automatisation (par exemple, la gestion des redirections, des pop-ups, du rendu JS).
• ZenRows et Hyperbrowser, qui ont obtenu des scores inférieurs à la fois en fonctionnalités et en taux de réussite, peuvent manquer de couverture d'automatisation complète ou rencontrer des défis sur les sites web complexes.

La stabilité spécifique à l'automatisation semble être une raison centrale de la dispersion des résultats, en particulier sur les tâches qui nécessitent des interactions en plusieurs étapes (achats e-commerce, extraction de leads).

3. Latence et efficacité de navigation

Les différences de temps de navigation pour les résultats corrects mettent en évidence les disparités dans l'efficacité avec laquelle chaque navigateur distant traite les pages :

• Bright Data et BrowserAI chargent et interagissent avec les pages en ~2 secondes, suggérant une mise en cache efficace, un routage réseau efficient et des environnements d'exécution JS rapides.
• Airtop, avec un temps de navigation moyen de 13.6 secondes, indique un traitement nettement plus lent, probablement dû à une latence réseau plus élevée, une exécution JS plus lente ou des goulots d'étranglement dans l'allocation des ressources au niveau des conteneurs/machines virtuelles.

Ces facteurs influencent directement à la fois le score de vitesse et la cohérence de l'achèvement des tâches.

4. Complétude des fonctionnalités et couverture des tâches

Certains fournisseurs offrent des ensembles de fonctionnalités plus riches, tels que la rotation de proxy, la gestion des CAPTCHA et des mécanismes d'évitement des blocages, qui contribuent à une plus grande fiabilité dans les scénarios complexes (par exemple, la recherche Google + crawl LinkedIn dans la tâche 2).

• Bright Data (95% de couverture fonctionnelle) et Anchor Browser (91%) démontrent une forte couverture des capacités, prenant en charge les flux d'automatisation complexes.
• Steel.dev (45%) et Hyperbrowser (41%) offrent des capacités plus limitées, ce qui peut expliquer leurs scores de réussite et de vitesse inférieurs sur les tâches en plusieurs étapes.

La maturité des fonctionnalités est directement corrélée au score composite à travers le benchmark.

5. Évolutivité sous haute concurrence

Notre test de charge utilisant 250 agents simultanés montre des différences marquées dans la façon dont les infrastructures évoluent sous pression :

• BrowserAI atteint le taux de réussite d'évolutivité le plus élevé (86.4%) avec des temps d'exécution totaux rapides, ce qui implique une orchestration optimisée et une mise à l'échelle automatique efficace.
• Bright Data évolue raisonnablement bien à 81.2%, bien qu'avec des temps d'exécution légèrement plus longs.

Cette variation d'évolutivité est critique pour les charges de travail d'entreprise ou à haut débit.

Méthodologie du benchmark des navigateurs distants

Notre méthodologie de benchmark est conçue pour évaluer les performances réelles de chaque navigateur distant selon deux dimensions clés : l'exécution de tâche unique et l'évolutivité sous charge.

Nous avons utilisé des agents alimentés par un LLM de pointe pour exécuter une série de tâches réalistes en plusieurs étapes qui imitent les scénarios d'automatisation courants.

Pour garantir un benchmark équitable et cohérent, nous sommes concentrés sur les services qui offrent un contrôle programmatique via la bibliothèque d'automatisation Playwright. Cela nous a permis d'utiliser la même base de code pour tester tous les fournisseurs.

Évaluation des performances en tâche unique

Cette partie du benchmark évalue la fiabilité et la vitesse de chaque fournisseur lors de l'exécution de tâches d'automatisation individuelles et isolées.

Comment nous avons mesuré le taux de réussite

Le taux de réussite mesure la fiabilité de l'infrastructure du navigateur. Une tâche était marquée comme « réussie » seulement si l'agent atteignait son objectif final et vérifiable du début à la fin. Ce score reflète la capacité du navigateur à gérer les sites web complexes, à éviter les blocages et à fournir un environnement stable pour l'agent.

Nous avons exécuté les quatre tâches principales suivantes :

• Tâche 1 – e-commerce (acheteur IA) :
  • Scénario : Un agent IA reçoit un budget et des idées de cadeaux. Il explore un site e-commerce pour identifier et acheter le meilleur cadeau.
  • Objectif : Rechercher, naviguer, remplir les formulaires et atteindre l'étape finale de confirmation d'achat avec succès.
• Tâche 2 – génération de leads (SDR IA) :
  • Scénario : Un agent IA reçoit un nom d'entreprise. Pour trouver des contacts correspondants, l'agent effectue une recherche Google ciblée pour les profils indexés publiquement provenant de sources comme LinkedIn. Il explore ensuite la page de résultats de recherche pour extraire les noms et les URL de profil des leads potentiels.
  • Objectif : Identifier avec succès au moins un lead valide à partir des résultats de recherche et naviguer vers sa page de profil LinkedIn pour vérifier l'accès.
• Tâche 3 – planification de voyage (assistant voyage) :
  • Scénario : Un agent IA navigue sur Booking.com pour trouver des hôtels. Il entre la destination (Miami, South Beach), sélectionne les dates d'arrivée et de départ (juin 16-17, 2025) et effectue une recherche. Sur la page de résultats, l'agent doit identifier et analyser les hôtels listés, en les filtrant pour trouver les établissements dans la fourchette de prix spécifiée ($100 – $200).
  • Objectif : Extraire et lister avec succès au moins deux hôtels qui correspondent à tous les critères (emplacement, prix et date).
• Tâche 4 – formulaires web (remplisseur de formulaires) :
  • Scénario : Un agent IA navigue sur un site web d'entreprise (aimultiple.com) et doit d'abord gérer les pop-ups de consentement aux cookies. Il localise ensuite le formulaire d'abonnement à la newsletter, entre une adresse e-mail de test (test@example.com) et clique sur le bouton « S'abonner » pour terminer l'inscription.
  • Objectif : Soumettre le formulaire avec succès et atteindre un état de confirmation.

Comment nous avons mesuré le temps total pour les résultats corrects

Cette métrique mesure la vitesse et l'efficacité globales du service, mais elle est calculée uniquement pour les exécutions réussies. Cela garantit que les fournisseurs sont jugés sur la rapidité avec laquelle ils peuvent accomplir une tâche correctement sans être pénalisés pour le temps passé sur les tentatives échouées.

Le chronomètre démarre au moment où un test est lancé et s'arrête lorsque l'agent atteint avec succès son objectif final. Cette durée de bout en bout est un chiffre complet qui inclut :

• Temps de démarrage du navigateur : Le temps initial nécessaire pour se connecter au navigateur distant et préparer une session pour les commandes.
• Navigation et rendu de page : Le temps passé à exécuter tous les appels page.goto() et à attendre que les pages se chargent et s'affichent complètement, y compris le JavaScript complexe.
• Temps de « réflexion » de l'agent : La latence de tous les appels passés au LLM (LLM) pour décider de l'action suivante.
• Temps d'exécution des outils : La durée cumulée de chaque interaction du navigateur, telle que .click(), .fill() et l'exécution de scripts personnalisés pour extraire des données.

Qu'est-ce qui conduit à un meilleur score (plus rapide) ?

Un temps inférieur sur le graphique indique une infrastructure de navigateur plus efficace. Les fournisseurs obtiennent un meilleur score en excellant dans ces domaines :

• Initialisation rapide de la session : Offrir des connexions à faible latence et des temps de démarrage de navigateur rapides, ce qui minimise l'attente initiale.
• Rendu de page efficace : Traiter rapidement les pages intensives en JavaScript et le contenu dynamique, permettant à l'agent d'interagir avec les éléments plus tôt.
• Infrastructure stable et réactive : Maintenir les performances sans blocages ni plantages pendant les tâches en plusieurs étapes, en s'assurant que les interactions du navigateur (.click(), .fill()) s'exécutent sans délai.

Un exemple de calcul

Pour clarifier cela, voyez comment un hypothétique « Fournisseur X » serait tracé sur notre graphique après avoir exécuté 10 tâches :

1. Calcul du taux de réussite :
   • Le fournisseur X réussit 7 tâches et échoue à 3.
   • Son taux de réussite est de 70%. Cela détermine sa position sur l'axe des x.
2. Calcul du temps moyen :
   • Les temps d'achèvement pour les 7 tâches réussies sont : 90s, 95s, 100s, 105s, 110s, 115s et 120s.
   • Les temps des 3 tâches échouées sont complètement ignorés.
   • Le temps moyen est calculé à partir des exécutions réussies uniquement :
     (90 + 95 + 100 + 105 + 110 + 115 + 120) / 7 = 105 secondes
   • Cette valeur de 105s détermine sa position sur l'axe des y.

Par conséquent, le fournisseur X serait placé aux coordonnées (70%, 105s) sur le graphique des performances. Cette méthodologie garantit que le graphique reflète avec précision à la fois la fiabilité et la vitesse réelle de chaque service.

Configurations spécifiques au fournisseur

Pour garantir un benchmark équitable et cohérent qui reflète les cas d'utilisation prévus pour chaque service, des plans d'abonnement et des configurations spécifiques ont été utilisés lors des tests :

• Steel.dev : Plan développeur.
• Hyperbrowser : Plan Scale.
• Anchor Browser : Les paramètres spécifiques suivants ont été activés pour toutes les tâches :
  • dedicated_sticky_ip: True
  • extra_stealth: {“active”: True}

Ces configurations sont notées pour fournir un contexte aux résultats de performance, car différents plans ou paramètres peuvent donner des résultats différents.

Évaluation des performances d'évolutivité (test de charge)

Ce benchmark mesure les performances de l'infrastructure des navigateurs distants sous charge simultanée. La métrique principale est le taux de réussite, calculé à partir du nombre de tâches accomplies lorsque 250 agents ont été exécutés en parallèle.

Architecture et exécution des tests

L'architecture de test a utilisé un script orchestrateur Python qui utilisait la bibliothèque multiprocessing pour créer et gérer un pool de 250 processus de travail. Chaque processus fonctionnait indépendamment, créant un environnement à haute concurrence pour simuler un déploiement réel à grande échelle.

• Distribution des tâches : Chaque agent s'est vu attribuer une requête de recherche de produit unique à partir d'une liste prédéfinie. Cette approche empêche une inflation potentielle des performances due à la mise en cache côté serveur et simule un modèle d'utilisation plus varié.
• Collecte de données : L'orchestrateur a agrégé les journaux et les artefacts (contenu HTML, captures d'écran) de chaque processus de travail pour une analyse post-exécution.

Workflow de l'agent

Chacun des 250 agents a effectué une séquence d'étapes automatisées sur Amazon.com. Une tâche était enregistrée comme réussie uniquement à la fin de l'ensemble du workflow. La séquence était la suivante :

1. Connexion : L'agent a établi une connexion au navigateur distant du fournisseur via son URL de pilote.
2. Navigation initiale : Il a navigué vers la page d'accueil du site web et a géré tous les défis anti-bot pour continuer.
3. Identification du champ de recherche : L'agent a capturé une capture d'écran de la page et l'a soumise à un LLM doté de capacités visuelles pour obtenir le sélecteur CSS du champ de saisie de recherche principal.
4. Exécution de la requête : L'agent a utilisé le sélecteur identifié pour saisir sa requête assignée et soumettre la recherche. Il a ensuite vérifié que la page de résultats de recherche se chargeait en confirmant la présence d'un élément de liste de produits.
5. Extraction des liens de résultats : Sur la page de résultats, l'agent a répété le processus de vision LLM pour obtenir un sélecteur CSS pour les liens de produits. Il a ensuite filtré les URL extraites pour isoler les liens directs vers les pages de produits, à l'exclusion des publicités ou des redirections.
6. Navigation finale : L'agent a navigué vers l'une des URL de produit valides. Le chargement réussi de cette page finale a marqué l'achèvement de la tâche.

Définition du temps total

Le « Temps total » rapporté dans les résultats du test de charge représente la durée de bout en bout nécessaire pour accomplir l'ensemble du lot de 250 tâches simultanées. Il s'agit d'une mesure du temps d'achèvement total de la charge de travail, régie par la fonction bloquante pool.map dans notre script orchestrateur.

Ce calcul inclut le temps d'exécution des tâches réussies et échouées. Le calcul fonctionne comme suit :

1. Un horodatage (start_time) est enregistré immédiatement avant que le pool multiprocessing ne commence à distribuer les 250 tâches de travail.
2. L'orchestrateur attend ensuite que tous les 250 processus parallèles terminent complètement leurs workflows individuels et renvoient un résultat, quel que soit le résultat (succès ou échec).
3. Un horodatage final est pris seulement après que la tâche la plus longue est terminée.

Fonctionnalités

Les fonctionnalités offertes par les principaux fournisseurs sont décrites ci-dessous. Le score de fonctionnalité est calculé pour chaque capacité selon notre méthodologie, puis moyenné sur toutes les fonctionnalités. Pour les fonctionnalités qui peuvent prendre plusieurs valeurs (par exemple, la prise en charge des langages de programmation), le produit qui fournit le plus grand nombre de valeurs (par exemple, le produit qui prend en charge le plus grand nombre de langages de programmation) obtient un score complet de 1, tandis que les autres sont notés au prorata.

Les sections suivantes détaillent les capacités de ces services :

Capacités techniques et gestion des erreurs

Les capacités techniques permettent aux développeurs de travailler avec divers sites web sans avoir à construire et maintenir leurs propres modules de code personnalisés :

Résolution de CAPTCHA : Cette fonctionnalité détecte et résout automatiquement une large gamme de types de CAPTCHA, y compris les défis basés sur l'image, hCaptcha, reCAPTCHA et Cloudflare. Le service gère également les invites CAPTCHA à taux limité et s'adapte aux mécanismes CAPTCHA évolutifs, garantissant un accès constant aux sites web protégés.

Gestion des erreurs : Cette fonctionnalité évalue le comportement par défaut du service pour les codes d'état HTTP standard qui sont critiques pour une navigation fiable :

• Sensibilisation au 404 (Non trouvé) : La capacité du système à détecter et signaler les erreurs « Non trouvé », permettant aux agents de gérer les pages manquantes de manière appropriée. Nous avons testé en naviguant vers une URL inexistante et en vérifiant si l'agent reçoit une indication claire de l'erreur 404 du service, plutôt qu'une réponse masquée (par exemple, une page d'erreur générique servie avec un statut 200 OK).
• Gestion des redirections 301/302 : Suivi automatique des redirections pour garantir que l'agent arrive à l'URL finale correcte. Nous avons testé en accédant à une URL connue pour émettre une redirection et en confirmant que l'agent est navigué vers l'URL de destination finale sans intervention manuelle.

Interaction JavaScript : Cette fonctionnalité gère les sites web intensifs en JavaScript et prend en charge l'émulation des interactions utilisateur.

• Exécution JavaScript : Rend entièrement JavaScript pour accéder au contenu chargé dynamiquement.
• Automatisation des actions du navigateur : Prend en charge les interactions programmatiques telles que cliquer sur des éléments, taper du texte dans des champs, faire défiler les pages (y compris le défilement infini), attendre l'apparition d'éléments spécifiques ou pendant une durée définie, et gérer les pop-ups ou les modales.
• Sélection d'éléments : Fournit des méthodes de sélection d'éléments, y compris les sélecteurs CSS et XPath.

Connexion : Cette fonctionnalité fait référence à la capacité de saisir des noms d'utilisateur, des mots de passe et d'autres informations d'identification dans les formulaires de connexion et de simuler la soumission de ces formulaires (par exemple, en cliquant sur les boutons de connexion). Cela repose généralement sur la capacité du moteur d'automatisation de navigateur de base à interagir avec les éléments web.

Langages de programmation

La couverture des langages de programmation permet aux développeurs de porter leur code existant sur les plateformes de navigateurs distants.

Cette fonctionnalité évalue l'étendue de la compatibilité des langages de programmation offerte par le service. Un nombre plus élevé de langages pris en charge signifie une flexibilité pour les équipes de développement, leur permettant d'intégrer les capacités de navigateur distant en utilisant leur pile technologique préférée ou existante.

Gestion des sessions

La gestion des sessions est nécessaire pour les interactions plus longues impliquant des interactions en plusieurs étapes (par exemple, l'achat d'un billet d'avion) sur le même site web :

Cette fonctionnalité évalue la capacité du service à gérer et maintenir l'état à travers plusieurs interactions au sein d'une session de navigation.

• Persistance de session : Prise en charge du maintien d'un ID de session cohérent à travers plusieurs requêtes ou actions, permettant des workflows en plusieurs étapes.
• Gestion des cookies : Capacités à gérer automatiquement les cookies (stocker, envoyer, effacer) ou permettre aux utilisateurs d'injecter/gérer des cookies personnalisés pour maintenir les états de connexion ou les préférences spécifiques au site.
• Préservation d'état : La capacité de préserver l'état du navigateur (par exemple, les formulaires remplis, les positions de défilement) à travers une séquence d'actions au sein d'une seule tâche.

Couverture géographique

La couverture géographique inclut à la fois la couverture au niveau des pays, afin que les utilisateurs puissent accéder aux sites web mondiaux, ainsi qu'une couverture granulaire comme le ciblage par ASN ou code postal spécifique.

Ciblage au niveau de la ville : La possibilité de spécifier une ville particulière comme origine des requêtes web. Cela permet une récupération et des tests de données hautement localisés, reflétant ce que les utilisateurs d'une zone urbaine spécifique verraient.

Ciblage par code postal : La capacité de cibler les requêtes en fonction de codes postaux spécifiques. Ceci est particulièrement pertinent pour l'e-commerce (vérification de la disponibilité locale des produits, des prix, des options d'expédition) et les services avec des variations hyperlocales.

Ciblage ASN (Autonomous System Number) : L'option d'acheminer les requêtes via des fournisseurs d'accès Internet (FAI) spécifiques ou des blocs réseau identifiés par leur ASN. Ce ciblage avancé peut être utile pour imiter le trafic de segments de réseau particuliers ou pour des stratégies de déblocage très spécifiques.

Intégrations

Les intégrations aux bibliothèques ou protocoles d'automatisation de navigateur comme MCP facilitent l'utilisation par les agents :

Compatibilité Playwright : Évalue la capacité à se connecter et à contrôler les sessions de navigateur distant en utilisant Playwright.

Compatibilité Puppeteer : Évalue l'intégration avec Puppeteer, utilisant souvent Puppeteer-core pour se connecter aux instances de navigateur distant.

Compatibilité Selenium : Mesure la prise en charge du contrôle des sessions de navigateur distant via Selenium WebDriver.

MCP (Model Context Protocol) Prise en charge : Indique si le service offre une intégration avec le Model Context Protocol. MCP est conçu pour faciliter l'échange structuré de données entre les outils (tels que les navigateurs) et les modèles d'IA (LLMs), permettant aux agents IA de mieux comprendre le contenu web et de l'utiliser plus efficacement.

Moteurs de recherche

Cette fonctionnalité évalue si le service de navigateur distant offre des fonctionnalités spécialisées ou un support optimisé pour l'extraction de données structurées directement à partir des pages de résultats des principaux moteurs de recherche (SERPs), tels que Google, Bing, DuckDuckGo et Baidu.

Sécurité

La sécurité des données est critique pour les agents, en particulier pour ceux qui effectueront des actions sur des systèmes sécurisés. Nous avons évalué si les créateurs de ces navigateurs distants disposaient de certifications de sécurité des données sur la base de leurs sites web.

Découvrez davantage de nos benchmarks et analyses basées sur les données dans la recherche Google.

Ajouter comme source préférée

Exigences des navigateurs distants pour les types d'agents IA

Les exigences pour les navigateurs distants varient en fonction du type et de l'utilisation prévue de l'agent IA qui les emploie. Les agents IA peuvent être largement catégorisés par leur mode opérationnel, ce qui dicte à son tour des demandes spécifiques sur l'infrastructure du navigateur distant :

• Agents IA backend : Ces agents fonctionnent généralement de manière autonome ou avec une supervision humaine directe minimale, souvent déclenchés par des événements système ou des tâches planifiées. Ils nécessitent des navigateurs distants optimisés pour la stabilité, l'évolutivité et une gestion robuste des erreurs pendant les opérations prolongées.
• Agents IA en temps réel : Ces agents interagissent directement avec les utilisateurs finaux qui attendent activement une réponse. Pour ceux-ci, les navigateurs distants doivent donner la priorité à une faible latence, une haute réactivité et des performances constantes.

Agents backend

Cas d'utilisation et agents typiques :

• Suivi et gestion des candidats
• SDR IA
• Planification de réunions
• Surveillance des prix
• Automatisation web

Agents orchestrateur-travailleur

Ces agents utilisent un coordinateur qui délègue des tâches à plusieurs agents spécialisés travaillant en parallèle ou en séquence.

Exigences critiques :

• Persistance de session entre les agents : Maintenir le contexte pendant que différents agents exécutent leurs parties
• Coordination multi-onglets : Plusieurs agents naviguant simultanément sur différentes sources
• Fiabilité d'exécution des outils : Chaque agent utilise des outils distincts qui doivent fonctionner de manière cohérente

Bright Data (95% de réussite, 95% de couverture fonctionnelle) et BrowserAI (85% de réussite, 86% de fonctionnalités) gèrent la coordination multi-agents de manière fiable.

Agents de surveillance

Ces agents exécutent des vérifications planifiées sur plusieurs cibles à intervalles réguliers.

Exigences critiques :

• Ciblage géographique : Précision au niveau de la ville et du code postal pour les données spécifiques à l'emplacement
• Fiabilité à haut volume : La surveillance à grande échelle amplifie les coûts d'échec
• Gestion des CAPTCHA : Résolution automatique pour un fonctionnement sans surveillance

Bright Data offre 95% de réussite avec le ciblage par code postal et ASN. BrowserAI offre 85% de réussite avec des capacités similaires. Les fournisseurs sans géo-ciblage granulaire manquent les variations spécifiques à l'emplacement.

Agents en temps réel

Cas d'utilisation et agents typiques :

• Recherche : OpenAI Deep research
• Analyste financier

Agents de routage

Ces agents classifient les entrées et les dirigent vers les gestionnaires spécialisés appropriés.

Exigences critiques :

• Classification et transfert rapides : Minimiser le surcoût de routage
• Initialisation instantanée du spécialiste : Aucun délai de démarrage après les décisions de routage
• Préservation du contexte à travers les transferts : Transférer l'état de session aux agents routés

Le démarrage en 1 seconde de BrowserAI réduit la latence dans le routage multi-sauts. Bright Data offre un démarrage en 2 secondes avec un score de vitesse de 100%. Le démarrage en 4 secondes d'Airtop et l'absence de préservation d'état augmentent le temps de réponse total.

Agents de recherche

Ces agents recueillent des informations à partir de sources multiples et synthétisent les résultats.

Exigences critiques :

• Contexte multi-onglets : Maintenir l'état à travers des sources simultanées
• Couverture des moteurs de recherche : Accès à diverses plateformes de recherche
• Qualité d'extraction de contenu : Données structurées propres pour le traitement LLM

Bright Data et BrowserAI prennent en charge Google, Bing, DuckDuckGo et Baidu avec une couverture fonctionnelle de 95% et 86%. Steel.dev ne prend en charge que Google et Bing avec 45% de fonctionnalités. Anchor Browser fournit 91% de fonctionnalités mais un taux de réussite de 70%.

Exigences supplémentaires

• Réponses rapides
• Stabilité de l'infrastructure pour une utilisation en temps réel (c'est-à-dire que les temps de réponse ne doivent pas se dégrader avec une utilisation parallèle).

Défis et atténuations

Bien que nous visions à exécuter exactement le même test pour tous les navigateurs distants, il y a quelques défis :

• Les LLMs sont probabilistes ; par conséquent, nos agents demandent à différents navigateurs agents d'aller sur différents sites web. Atténuations : Nous
  • Tirons parti des garde-fous et d'un paramètre de basse température pour minimiser les variations.
  • Ayons des requêtes aussi spécifiques que possible.
  • Nous avons exécuté chaque agent plusieurs fois (par exemple, 5) pour garantir que toutes les solutions testées reçoivent des requêtes similaires.

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Sarı, Ekrem},
  title  = {{Navigateurs distants: Infrastructure Web pour agents IA comparée}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/remote-browsers}},
  note   = {AIMultiple. Consulté le 30 Juin 2026}
}

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017. AIMultiple informe chaque mois des centaines de milliers d'entreprises (selon similarWeb), dont 55 % des entreprises du classement Fortune 500. Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes et le Washington Post, ainsi que par des entreprises mondiales comme Deloitte et HPE, des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne. Vous trouverez d'autres entreprises et ressources réputées ayant fait référence à AIMultiple. Tout au long de sa carrière, Cem a exercé les fonctions de consultant, d'acheteur et d'entrepreneur dans le secteur des technologies. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la numérisation. Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité directe du PDG. Il a également piloté la croissance commerciale de la société de deep tech Hypatos, qui a atteint un chiffre d'affaires annuel récurrent à sept chiffres et une valorisation à neuf chiffres en seulement deux ans. Les travaux de Cem chez Hypatos ont été présentés dans des publications technologiques de référence telles que TechCrunch et Business Insider. Cem intervient régulièrement lors de conférences internationales sur les technologies. Diplômé en génie informatique de l'université de Bogazici, il est également titulaire d'un MBA de la Columbia Business School.

Voir le profil complet

Recherche effectuée par

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA chez AIMultiple, spécialisé dans l'automatisation intelligente, les GPU, les agents IA et les frameworks RAG.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire