Navigateurs distants : Comparaison des infrastructures web pour les agents d'IA

Les agents d'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 navigation est essentielle au bon fonctionnement de l'agent.

Nous avons évalué 8 fournisseurs selon leur taux de réussite, leur rapidité et leurs fonctionnalités. Pour ce faire, nous avons exécuté 160 tâches automatisées, en répétant 4 scénarios distincts 5 fois pour chaque service afin de mesurer leurs performances en conditions réelles. Nous avons également réalisé un test de charge avec 250 agents d'IA en parallèle.

Résultats des benchmarks des principaux navigateurs distants

Voici les meilleurs navigateurs distants en fonction de leurs capacités et de leurs performances lors de notre test de référence :

Le score composite correspond à la moyenne des scores de taux de réussite, de rapidité et de fonctionnalités. Il reflète la performance globale d'un fournisseur dans des scénarios de tâches uniques.

Le score de scalabilité représente le taux de réussite d'un fournisseur lors de notre test de charge à haute concurrence. Cet indicateur évalue précisément la stabilité et la fiabilité de l'infrastructure lorsqu'elle est soumise à un volume important de tâches parallèles. Ce test de charge intensif n'ayant pu être réalisé pour tous les fournisseurs, le score de scalabilité est présenté comme un indicateur distinct.

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

Taux de réussite

L'évaluation des résultats de référence met en évidence des différences 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 relative aux navigateurs distants .

Vitesse

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

Le score de vitesse quantifie le débit du service de navigateur distant, représentant le nombre de tâches effectuées avec succès par unité de temps définie. Il reflète l'efficacité globale et la capacité de traitement.

Le temps de navigation moyen pour l'obtention de résultats corrects mesure le temps moyen écoulé lors de l'interaction active du navigateur distant avec les pages web pour chaque tâche effectuée avec succès. Ce temps inclut la navigation sur la page, le rendu JavaScript et les interactions directes avec les éléments (clics, saisie, etc.).

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

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

Le temps total pour des résultats corrects (moyenne) représente la durée moyenne de bout en bout pour les tâches individuelles effectué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 retards délibérés, et les latences de communication avec les services externes (par exemple, les LLM) 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 de temps total pour des résultats corrects .

Évolutivité

Notre test de charge, exécuté selon la méthodologie d'évaluation de la scalabilité des navigateurs distants , a utilisé 250 agents simultanés pour mesurer les performances de l'infrastructure en situation de forte contrainte. Le test a révélé les principales différences suivantes :

• BrowserAI a obtenu le taux de réussite le plus élevé, soit 86,4 % , en 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 tests comparatifs révèlent des différences de fiabilité, de vitesse et d'évolutivité entre les principaux fournisseurs de navigateurs distants. Ces différences proviennent essentiellement 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 de meilleurs scores de réussite et de rapidité.

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

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

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

Les taux de réussite varient considérablement selon la façon dont chaque fournisseur prend en charge les modèles d'interaction automatisés tels que le remplissage de formulaires, le rendu DOM, la navigation et les flux de travail utilisant intensivement JavaScript.

• Bright Data, BrowserAI et Steel.dev accomplissent systématiquement des tâches impliquant la navigation, l'analyse et l'interaction car 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 plus faibles en termes de fonctionnalités et de taux de réussite, peuvent ne pas offrir une couverture d'automatisation complète ou rencontrer des difficultés sur les sites web complexes.

La stabilité spécifique à l'automatisation semble être une raison essentielle de la dispersion des résultats, notamment pour les tâches nécessitant des interactions en plusieurs étapes (achats en ligne, extraction de prospects).

3. Latence et efficacité de navigation

Les différences de temps de navigation pour obtenir des 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, ce qui suggère une mise en cache efficace, un routage réseau efficace 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 en raison d'une latence réseau plus élevée, d'une exécution JS plus lente ou de goulots d'étranglement dans l'allocation des ressources au niveau du conteneur/VM.

Ces facteurs influencent directement à la fois le score de rapidité et la régularité d'exécution des tâches.

4. Exhaustivité des fonctionnalités et couverture des tâches

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

• Bright Data (95 % de couverture des fonctionnalités) et Anchor Browser (91 %) démontrent une forte couverture des capacités, prenant en charge des 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 de l'ensemble des données de référence.

5. Évolutivité en cas de forte concurrence

Notre test de charge utilisant 250 agents simultanés révèle des différences flagrantes dans la capacité des infrastructures à évoluer sous pression :

• BrowserAI atteint le taux de réussite de mise à l'échelle 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 s'adapte assez bien à 81,2%, bien qu'avec des temps d'exécution légèrement plus longs.

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

Méthodologie d'évaluation comparative des navigateurs distants

Notre méthodologie de référence est conçue pour évaluer les performances réelles de chaque navigateur distant selon deux dimensions clés : l’exécution d’une seule tâche 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 des scénarios d'automatisation courants.

Afin de garantir une évaluation équitable et cohérente, nous nous sommes concentrés sur les services offrant 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 test de performance évalue la fiabilité et la rapidité 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 n'est considérée comme « réussie » que si l'agent atteint son objectif final et vérifiable du début à la fin. Ce score reflète la capacité du navigateur à gérer des sites web complexes, à éviter les blocages et à fournir un environnement stable à l'agent.

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

• Tâche 1 – commerce électronique (acheteur IA) :
  • Scénario : Un agent IA reçoit un budget et des idées de cadeaux. Il parcourt un site de commerce électronique pour identifier et acheter le cadeau idéal.
  • Objectif : Réussir la recherche, la navigation, le remplissage des formulaires et l'étape finale de confirmation d'achat.
• Tâche 2 – génération de prospects (SDR IA) :
  • Scénario : Un agent IA reçoit un nom d’entreprise. Pour trouver des contacts correspondants, il effectue une recherche ciblée (Google) sur les profils publics indexés provenant de sources telles que LinkedIn. Il explore ensuite la page de résultats de recherche pour extraire les noms et les URL des profils des prospects potentiels.
  • Objectif : Identifier avec succès au moins un prospect qualifié parmi les résultats de recherche et accéder à son profil LinkedIn pour en vérifier l’accès.
• Tâche 3 – planification de voyage (assistant de voyage) :
  • Scénario : Un agent virtuel se connecte à Booking.com pour trouver des hôtels. Il saisit la destination (Miami, South Beach), sélectionne les dates d’arrivée et de départ (16 et 17 juin 2025) et lance une recherche. Sur la page de résultats, l’agent doit identifier et analyser les hôtels proposés, puis les filtrer pour trouver ceux qui correspondent à 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 (remplissage automatique des formulaires) :
  • Scénario : Un agent IA accède au site web d’une entreprise (aimultiple.com) et doit d’abord gérer les fenêtres contextuelles de consentement aux cookies. Il localise ensuite le formulaire d’inscription à la newsletter, saisit une adresse e-mail de test (test@example.com) et clique sur le bouton « S’abonner » pour finaliser l’inscription.
  • Objectif : Soumettre le formulaire avec succès et obtenir une confirmation.

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

Cet indicateur mesure la vitesse et l'efficacité globales du service, mais il n'est calculé que pour les exécutions réussies . Ainsi, les prestataires sont évalués sur leur capacité à accomplir une tâche rapidement et correctement, sans être pénalisés pour le temps passé sur les tentatives infructueuses.

Le chronomètre se déclenche au lancement du test et s'arrête lorsque l'agent atteint son objectif final. Cette durée totale 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 des pages : temps passé à exécuter tous les appels page.goto() et à attendre que les pages soient entièrement chargées et rendues, y compris le JavaScript complexe.
• Temps de « réflexion » de l’agent : la latence de tous les appels effectués au Large Language Model (LLM) pour décider de la prochaine action.
• Temps d'exécution de l'outil : durée cumulée de chaque interaction avec le navigateur, comme .click(), .fill() et l'exécution de scripts personnalisés pour extraire des données.

Qu'est-ce qui permet d'obtenir un meilleur score (plus rapide) ?

Un temps plus court sur le graphique indique une infrastructure de navigateur plus performante. Les fournisseurs obtiennent un meilleur score en excellant dans les domaines suivants :

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

Un exemple de calcul

Pour illustrer cela clairement, voici comment un hypothétique « Fournisseur X » serait représenté sur notre graphique après l’exécution de 10 tâches :

1. Calcul du taux de réussite :
   • Le fournisseur X réussit 7 tâches et échoue sur 3.
   • Son taux de réussite est de 70 % . Cela détermine sa position sur l'axe des abscisses.
2. Calcul du temps moyen :
   • Les temps d'exécution des 7 tâches réussies sont : 90 s, 95 s, 100 s, 105 s, 110 s, 115 s et 120 s.
   • Les temps des 3 tâches ayant échoué sont complètement ignorés .
   • Le temps moyen est calculé uniquement à partir des exécutions réussies :
     (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 positionné aux coordonnées (70 %, 105 s) sur le graphique de performance. Cette méthode garantit que le graphique reflète fidèlement la fiabilité et la vitesse réelle de chaque service.

Configurations spécifiques au fournisseur

Afin de garantir une évaluation juste et cohérente reflétant 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 d'échelle.
• Anchor Browser : Les paramètres spécifiques suivants ont été activés pour toutes les tâches :
  • adresse_ip_répétable_dédiée : Vrai
  • furtivité supplémentaire : {« actif » : Vrai}

Ces configurations sont mentionnées afin de contextualiser les résultats de performance, car différents plans ou paramètres peuvent donner des résultats différents.

Évaluation des performances de mise à l'échelle (test de charge)

Ce test de performance évalue les résultats d'une infrastructure de navigateur distant sous charge simultanée. Le principal indicateur est le taux de réussite, calculé à partir du nombre de tâches accomplies lorsque 250 agents sont exécutés en parallèle.

Architecture et exécution des tests

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

• Répartition des tâches : chaque agent s’est vu attribuer une requête de recherche de produit unique, issue d’une liste prédéfinie. Cette approche permet d’éviter une potentielle augmentation des performances due à la mise en cache côté serveur et simule un usage 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.

Flux de travail de l'agent

Chacun des 250 agents a exécuté une séquence d'étapes automatisées sur Amazon.com. Une tâche n'était considérée comme réussie qu'une fois le flux de travail complet achevé. La séquence était la suivante :

1. Connexion : L'agent a établi une connexion avec le navigateur distant du fournisseur via l'URL de son pilote.
2. Navigation initiale : Le système a accédé à la page d’accueil du site web et a surmonté tous les obstacles liés aux robots pour poursuivre.
3. Identification du champ de recherche : L’agent a pris une capture d’écran de la page et l’a soumise à un LLM doté de capacités visuelles afin d’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 et soumettre la recherche. Il a ensuite vérifié le chargement de la page de résultats 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 LLM-vision pour obtenir un sélecteur CSS pour les liens produits. Il a ensuite filtré les URL extraites afin d’isoler les liens directs vers les pages produits, en excluant les publicités et les redirections.
6. Navigation finale : L’agent a accédé à l’une des URL de produit valides. Le chargement réussi de cette page finale a marqué la fin de la tâche.

Définition du temps total

Le « Temps total » indiqué dans les résultats du test de charge correspond à la durée totale nécessaire pour exécuter l'ensemble des 250 tâches simultanées. Il s'agit d'une mesure du temps d'exécution total de la charge de travail, régi par la fonction bloquante `pool.map` de notre script d'orchestration.

Ce calcul prend en compte le temps d'exécution des tâches réussies et des tâches ayant échoué. Le calcul fonctionne comme suit :

1. Un horodatage (start_time) est enregistré immédiatement avant que le pool de multiprocessing ne commence à distribuer les 250 tâches de travail.
2. L'orchestrateur attend ensuite que les 250 processus parallèles aient entièrement terminé leurs flux de travail individuels et renvoyé un résultat, quel qu'en soit le résultat (succès ou échec).
3. L'horodatage final n'est pris qu'une fois la tâche la plus longue terminée.

Caractéristiques

Les fonctionnalités offertes par les principaux fournisseurs sont décrites ci-dessous. Le score de chaque fonctionnalité est calculé selon notre méthodologie, puis moyenné sur l'ensemble des fonctionnalités. Pour les fonctionnalités pouvant prendre plusieurs valeurs (par exemple, la prise en charge des langages de programmation), le produit offrant le plus grand nombre de valeurs (par exemple, celui prenant en charge le plus grand nombre de langages de programmation) obtient la note maximale de 1, tandis que les autres reçoivent un score 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 différents sites web sans avoir à créer et à maintenir leurs propres modules de code personnalisés :

Résolution des CAPTCHA : Cette fonctionnalité détecte et résout automatiquement de nombreux types de CAPTCHA , notamment les CAPTCHA par image, hCaptcha, reCAPTCHA et les défis Cloudflare. Le service gère également les CAPTCHA à débit limité et s’adapte à l’évolution des mécanismes CAPTCHA, garantissant ainsi 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 essentiels à une navigation fiable :

• Gestion des erreurs 404 (Page introuvable) : Le système est capable de détecter et de signaler les erreurs « Page introuvable », permettant ainsi aux agents de gérer correctement les pages manquantes. Nous avons effectué un test en accédant à 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 avec un code de statut 200 OK).
• Gestion des redirections 301/302 : Suivi automatique des redirections pour garantir que l’agent accède à l’URL finale correcte. Nous avons effectué un test en accédant à une URL connue pour générer une redirection et en vérifiant que l’agent est bien dirigé vers l’URL de destination finale sans intervention manuelle.

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

• Exécution JavaScript : Rendu complet du code 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, saisir 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 fenêtres contextuelles ou modales.
• Sélection d'éléments : Fournit des méthodes pour sélectionner des éléments, notamment les sélecteurs CSS et XPath.

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

langage de programmation

La prise en charge des langages de programmation permet aux développeurs de porter leur code existant sur des plateformes de navigateurs distantes.

Cette fonctionnalité évalue la compatibilité du service avec un plus grand nombre de langages de programmation. Un plus grand nombre de langages pris en charge offre une plus grande flexibilité aux équipes de développement, leur permettant d'intégrer les fonctionnalités du navigateur distant à leur environnement technique actuel ou préféré.

Gestion de session

La gestion de session 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 au cours de plusieurs interactions au sein d'une session de navigation.

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

Couverture géographique

La couverture géographique comprend à la fois une couverture au niveau national, permettant aux utilisateurs d'accéder à des sites web mondiaux, ainsi qu'une couverture plus granulaire comme un ciblage spécifique basé sur un ASN ou un code postal.

Ciblage au niveau de la ville : 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 très localisés, reflétant ce que verraient les utilisateurs d’une zone urbaine spécifique.

Ciblage par code postal : Possibilité de cibler les requêtes en fonction de codes postaux spécifiques. Ceci est particulièrement pertinent pour le commerce électronique (vérification de la disponibilité locale des produits, des prix et des options de livraison) et les services présentant des variations hyperlocales.

Ciblage ASN (Numéro de système autonome) : Cette option permet d’acheminer les requêtes via des fournisseurs d’accès Internet (FAI) ou des blocs réseau spécifiques, identifiés par leur ASN. Ce ciblage avancé peut s’avérer utile pour simuler le trafic de segments de réseau particuliers ou pour des stratégies de déblocage très spécifiques.

Intégrations

L'intégration aux bibliothèques ou protocoles d'automatisation du navigateur, tels que MCP, facilite l'utilisation de l'agent :

Compatibilité avec Playwright : Évalue la capacité à se connecter et à contrôler des sessions de navigateur à distance à l'aide de Playwright.

Compatibilité avec Puppeteer : Évalue l'intégration avec Puppeteer , utilisant souvent Puppeteer-core pour la connexion aux instances de navigateur distantes.

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

Prise en charge du protocole MCP (Model Context Protocol) : indique si le service propose une intégration avec le protocole MCP. Ce protocole facilite l’échange de données structurées entre les outils (navigateurs, par exemple) et les modèles d’IA (LLM), permettant ainsi aux agents d’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 une prise en charge optimisée pour extraire des données structurées directement à partir des principales pages de résultats des moteurs de recherche (SERP), telles que Google, Bing, DuckDuckGo et Baidu.

Sécurité

La sécurité des données est essentielle pour les agents, notamment pour ceux qui interviennent sur des systèmes sécurisés. Nous avons vérifié si les concepteurs de ces navigateurs distants possédaient des certifications de sécurité des données en consultant leurs sites web.

Exigences relatives aux navigateurs distants pour les types d'agents d'IA

Les exigences relatives aux navigateurs distants varient selon le type et l'usage prévu de l' agent d'IA qui les utilise. Les agents d'IA peuvent être globalement catégorisés selon leur mode de fonctionnement, ce qui détermine les exigences spécifiques de l'infrastructure des navigateurs distants :

• Agents d'IA côté serveur : Ces agents fonctionnent généralement de manière autonome ou avec une supervision humaine 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 lors de fonctionnements prolongés.
• Agents d'IA en temps réel : ces agents interagissent directement avec les utilisateurs finaux qui attendent activement une réponse. Pour ces agents, les navigateurs distants doivent privilégier une faible latence, une réactivité élevée et des performances constantes.

Agents backend

Cas d'utilisation et agents typiques :

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

agents orchestrateurs-travailleurs

Ces agents utilisent un coordinateur qui répartit les tâches entre plusieurs agents spécialisés travaillant en parallèle ou en séquence.

Exigences critiques :

• Persistance de session entre agents : maintien du contexte pendant que différents agents exécutent leurs portions de code.
• Coordination multi-onglets : Plusieurs agents consultent simultanément 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 succès, 95 % de couverture des fonctionnalités) et BrowserAI (85 % de succès, 86 % de fonctionnalités) gèrent la coordination multi-agents de manière fiable.

Agents de surveillance

Ces agents effectuent des contrôles programmés 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 géolocalisées
• Fiabilité à grande échelle : la surveillance à grande échelle amplifie les coûts des défaillances
• Gestion des CAPTCHA : Résolution automatique pour un fonctionnement sans surveillance

Bright Data offre un taux de réussite de 95 % pour le ciblage par code postal et ASN. BrowserAI atteint 85 % de réussite avec des fonctionnalités similaires. Les fournisseurs sans géolocalisation précise ne prennent pas en compte les variations liées à la localisation.

Agents en temps réel

Cas d'utilisation et agents typiques :

• Recherche : OpenAI Recherche approfondie
• analyste financier

Agents de routage

Ces agents classent les données entrantes et les acheminent vers les gestionnaires spécialisés appropriés.

Exigences critiques :

• Classification et transfert rapides : minimiser les surcharges de routage
• Initialisation instantanée des spécialistes : aucun délai de démarrage après les décisions de routage
• Préservation du contexte lors des transferts : transférer l'état de la 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 la préservation de l'état manquant augmentent le temps de réponse total.

Agents de recherche

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

Exigences critiques :

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

BrowserAI prend en charge Bing, DuckDuckGo et Baidu (991259_1691 et 86 % respectivement), avec une couverture des fonctionnalités de 95 % et 86 %. Steel.dev ne prend en charge que Bing (991259_1712) avec 45 % des fonctionnalités. Anchor Browser offre 91 % des fonctionnalités, mais un taux de réussite de seulement 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 en cas d'utilisation parallèle).

Défis et mesures d'atténuation

Bien que notre objectif soit d'exécuter exactement le même test pour tous les navigateurs distants, certains défis se présentent :

• Les LLM sont probabilistes ; par conséquent, nos agents demandent à différents navigateurs d'agents d'accéder à différents sites web. Mesures d'atténuation : Nous
  • Utilisez des garde-fous et un réglage de basse température pour minimiser les variations.
  • Posez des questions aussi précises que possible.
  • Nous avons exécuté chaque agent plusieurs fois (par exemple, 5) pour nous assurer que toutes les solutions testées recevaient des requêtes similaires.

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.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire