Skyvern (YC S23) – Agent IA open source pour l’automatisation de navigateur

 (github.com/Skyvern-AI)
4 points par GN⁺ 2024-10-25 | 1 commentaires | Partager sur WhatsApp
  • Skyvern automatise les workflows manuels basés sur des sites web grâce aux LLM et à la vision par ordinateur, et fournit à la fois un SDK compatible Playwright et un constructeur de workflows no-code
  • Contrairement à l’automatisation de navigateur traditionnelle, qui dépend de l’analyse du DOM et de XPath et se montre fragile face aux changements de mise en page, Skyvern comprend les éléments à l’écran avec un Vision LLM et planifie puis exécute les actions nécessaires
  • Skyvern affirme pouvoir faire correspondre des éléments visuels à des actions même sur des sites web jamais vus, et appliquer le même workflow à plusieurs sites web sans XPath ni sélecteurs prédéfinis
  • Le SDK fournit les commandes page.act, page.extract, page.validate, page.prompt et page.agent, ajoutant aux actions Playwright existantes une recherche d’éléments basée sur des prompts en langage naturel
  • Sont également présentés : exécution locale, Docker Compose, Skyvern Cloud, contrôle d’un Chrome existant, tunneling de navigateur, précision de 64,4 % sur WebBench, licence AGPL-3.0 et exception pour les fonctions anti-bot du cloud managé

Le problème que Skyvern veut résoudre

  • Skyvern est un projet qui automatise les workflows basés sur le navigateur avec des LLM et de la vision par ordinateur
  • Il fournit un SDK compatible Playwright qui ajoute des capacités d’IA par-dessus Playwright
  • Il propose aussi un constructeur de workflows no-code afin que les utilisateurs techniques comme non techniques puissent automatiser des workflows manuels sur n’importe quel site web
  • L’automatisation de navigateur traditionnelle repose souvent sur des scripts sur mesure par site, l’analyse du DOM et des interactions basées sur XPath, et peut se casser lorsque la mise en page d’un site change
  • Skyvern n’utilise pas seulement des interactions XPath définies dans le code : il apprend et interagit avec les sites web via un Vision LLM

Fonctionnement et conception

  • Skyvern s’inspire de la conception des agents autonomes pilotés par des tâches popularisée par BabyAGI et AutoGPT
  • Il y ajoute la capacité d’interagir avec des sites web au moyen de bibliothèques d’automatisation de navigateur comme Playwright
  • Il utilise un essaim de plusieurs agents pour comprendre un site web, planifier les actions et les exécuter
  • Les avantages de cette approche se résument en trois points
    • Elle peut fonctionner sur des sites web jamais vus, en faisant correspondre les éléments visuels aux actions nécessaires sans code sur mesure
    • Elle est plus robuste face aux changements de mise en page des sites web, car elle ne cherche pas de XPath ou de sélecteurs prédéfinis pendant la navigation
    • Elle peut appliquer un même workflow à plusieurs sites web et déduire les interactions nécessaires sur chaque site
  • Le rapport technique Skyvern 2.0 est disponible dans Skyvern 2.0: State-of-the-art web navigation with 85.8 on WebVoyager eval

Modes d’exécution

  • Skyvern Cloud est la version cloud managée permettant d’exécuter Skyvern sans gérer soi-même l’infrastructure
  • Skyvern Cloud peut exécuter plusieurs instances Skyvern en parallèle et inclut des mécanismes de réponse à la détection anti-bot, un réseau de proxys et un solveur de CAPTCHA
  • L’exécution locale peut démarrer avec pip install "skyvern[all]" puis skyvern quickstart
  • skyvern quickstart et skyvern run server utilisent par défaut une base de données SQLite située dans ~/.skyvern/data.db
    • Pour utiliser un conteneur Postgres local, passez --postgres
    • Pour utiliser une base de données existante, passez --database-string
    • Docker Compose utilise le service Postgres fourni
  • L’exécution via Docker Compose conteneurise Postgres, l’API et l’UI ; après avoir configuré les clés d’API LLM dans .env, elle démarre avec docker compose up -d
  • L’UI est accessible par défaut sur http://localhost:8080

SDK et extensions Playwright basées sur l’IA

  • Le SDK Skyvern est une extension qui ajoute à Playwright une automatisation de navigateur basée sur l’IA
  • Les modes d’installation dépendent de l’usage
    • SDK Python / API cloud : pip install skyvern
    • Serveur local et UI empaquetée : pip install "skyvern[all]" puis skyvern quickstart
    • Serveur local et UI avec Postgres : pip install "skyvern[all]" puis skyvern quickstart --postgres
    • UI empaquetée connectée à une API existante : pip install "skyvern[ui]" puis skyvern run ui --api-url <api-url> --api-key <api-key>
    • TypeScript : npm install @skyvern/client
  • Quatre commandes IA sont ajoutées à l’objet page
    • page.act(prompt) : exécute une action en langage naturel, comme « cliquer sur le bouton de connexion »
    • page.extract(prompt, schema) : extrait des données structurées avec un JSON schema optionnel
    • page.validate(prompt) : vérifie l’état de la page et renvoie un bool
    • page.prompt(prompt, schema) : envoie un prompt arbitraire au LLM avec un schema de réponse optionnel
  • page.agent fournit des commandes de workflow de plus haut niveau
    • page.agent.run_task(prompt) : exécute une tâche complexe en plusieurs étapes
    • page.agent.login(credential_type, credential_id) : s’authentifie avec des identifiants enregistrés dans Skyvern, Bitwarden ou 1Password
    • page.agent.download_files(prompt) : navigue puis télécharge des fichiers
    • page.agent.run_workflow(workflow_id) : exécute un workflow préconstruit
  • Les actions Playwright existantes prennent en charge la recherche d’éléments basée sur l’IA via un paramètre optionnel prompt
    • page.click("#btn") au lieu de page.click(prompt="Click login button")
    • page.fill("#email", "a@b.com") au lieu de page.fill(prompt="Email field", value="a@b.com")
    • page.select_option("#country", "US") au lieu de page.select_option(prompt="Country dropdown", value="US")
    • page.upload_file("#file", "doc.pdf") au lieu de page.upload_file(prompt="Upload area", files="doc.pdf")
  • Il existe trois modes d’interaction
    • Playwright existant : utilisation de sélecteurs CSS/XPath
    • Basé sur l’IA : utilisation du langage naturel
    • AI fallback : tente d’abord le sélecteur, puis bascule vers l’IA en cas d’échec

Contrôle avancé du navigateur

  • Skyvern peut contrôler le navigateur Chrome existant de l’utilisateur
  • Cette approche réutilise le navigateur tel quel, avec ses cookies, connexions et extensions existants
  • Le débogage distant de Chrome peut être activé dans chrome://inspect/#remote-debugging
  • La commande skyvern init browser ouvre la page de débogage distant, attend que l’utilisateur l’active, puis peut enregistrer la configuration
  • Skyvern Cloud peut aussi contrôler un Chrome en cours d’exécution sur une machine locale
    • La commande skyvern browser serve --tunnel lance Chrome et crée le tunnel vers Skyvern Cloud en une seule étape
    • C’est utile pour automatiser des sites sur lesquels l’utilisateur est déjà connecté ou qui se trouvent derrière un VPN
  • Lorsqu’un navigateur est exposé via un tunnel, il faut toujours utiliser --api-key

Performances et évaluation

  • Skyvern affirme avoir atteint des performances SOTA sur le benchmark WebBench avec une précision de 64,4 %
  • Le rapport technique et l’évaluation sont disponibles dans Web Bench: A new way to compare AI browser agents
  • Il affirme aussi être l’agent le plus performant pour les tâches WRITE
    • Les exemples de tâches WRITE incluent le remplissage de formulaires, la connexion et le téléchargement de fichiers
    • Cette catégorie est principalement utilisée pour des tâches proches de la RPA

Tasks et Workflows

  • Une Task est l’unité de base interne de Skyvern
  • Chaque Task est une requête unique demandant de naviguer sur un site web et d’atteindre un objectif précis
  • Une Task nécessite un url et un prompt
  • Elle peut inclure en option un data schema et des error codes
    • Le data schema sert à faire en sorte que la sortie respecte un schema donné
    • Les error codes servent à arrêter l’exécution de Skyvern dans certaines situations
  • Un Workflow permet d’enchaîner plusieurs Tasks pour en faire une seule unité de travail
  • Exemples de workflows
    • Pour télécharger toutes les factures postérieures au 1er janvier, on peut le composer ainsi : aller à la page des factures, filtrer par date, extraire la liste des factures visées, puis télécharger chaque facture
    • L’automatisation d’un achat e-commerce peut suivre les étapes : navigation vers le produit, ajout au panier, validation de l’état du panier, puis checkout
  • Les fonctions de workflow prises en charge incluent Browser Task, Browser Action, Data Extraction, Validation, For Loops, File parsing, Sending emails, Text Prompts, HTTP Request Block, Custom Code Block et l’envoi de fichiers vers un block storage
  • Les Conditionals sont indiqués comme « Coming soon »

Fonctionnalités principales

  • Le Livestreaming transmet en temps réel le viewport du navigateur vers la machine locale afin de voir ce que Skyvern fait sur le web
    • C’est utile pour le débogage, la compréhension des interactions et l’intervention si nécessaire
  • Le Form Filling peut remplir nativement les champs de formulaires d’un site web
    • En transmettant les informations via navigation_goal, Skyvern comprend le contenu et remplit le formulaire
  • La Data Extraction extrait des données depuis des sites web
    • Si data_extraction_schema est spécifié au format jsonc dans le prompt principal, la sortie suit la structure de ce schema
  • Le File Downloading télécharge des fichiers depuis des sites web
    • Les fichiers téléchargés sont automatiquement envoyés si un block storage est configuré, et ils sont accessibles depuis l’UI
  • L’Authentication prend en charge plusieurs modes d’authentification pour faciliter l’automatisation des tâches derrière une connexion
  • La prise en charge de la 2FA est fournie de plusieurs façons
    • 2FA basée sur QR code, par exemple Google Authenticator, Authy
    • 2FA basée sur l’e-mail
    • 2FA basée sur SMS
    • La documentation associée se trouve dans 2FA support
  • État des intégrations avec les gestionnaires de mots de passe
    • Pris en charge : Bitwarden
    • Pris en charge : Custom Credential Service, HTTP API
    • Non pris en charge : 1Password
    • Non pris en charge : LastPass

Intégrations et LLM pris en charge

  • Skyvern prend en charge le Model Context Protocol (MCP), ce qui permet d’utiliser des LLM compatibles MCP
  • La documentation MCP est disponible dans la documentation du serveur MCP
  • Les intégrations Zapier, Make.com et N8N sont prises en charge
  • Les fournisseurs de LLM pris en charge sont les suivants
    • OpenAI : GPT-5.5, GPT-5.4, GPT-5, GPT-4.1, o3, o4-mini
    • Anthropic : Claude 4.7 Opus, Claude 4.6 Sonnet/Opus, Claude 4.5 Haiku/Sonnet/Opus
    • Azure OpenAI : tous les modèles GPT déployés dans un abonnement Azure
    • AWS Bedrock : Claude 4.7, Claude 4.6 Sonnet/Opus, Claude 4.5 Sonnet/Opus
    • Gemini : Gemini 3.1 Pro, Gemini 3 Flash, Gemini 2.5 Pro/Flash
    • Ollama : modèles hébergés localement via Ollama
    • OpenRouter : accès aux modèles via OpenRouter
    • Compatible OpenAI : endpoints d’API personnalisés suivant le format de l’API OpenAI via liteLLM
  • La configuration détaillée des LLM se trouve dans la documentation de configuration LLM

Exemples d’usage réels

  • Automatisation du téléchargement de factures sur plusieurs sites web
  • Automatisation des processus de candidature à des emplois
  • Automatisation des achats de matériaux pour des entreprises industrielles
  • Création de comptes ou remplissage de formulaires sur des sites gouvernementaux
  • Remplissage de formulaires « contact us » aléatoires
  • Recherche de devis d’assurance sur des sites d’assureurs dans plusieurs langues

Dépannage et commandes d’exploitation

  • Un bug connu de pip install skyvern==1.0.31 peut provoquer (sqlite3.OperationalError) table organizations already exists
    • Supprimez le fichier SQLite restant ~/.skyvern/data.db, mettez à niveau vers la version 1.0.32 ou supérieure avec pip install --upgrade skyvern, puis exécutez skyvern quickstart
    • Si vous devez rester en 1.0.31, vous pouvez utiliser uv pip install skyvern
  • Si pip install skyvern échoue avec ResolutionImpossible, il peut s’agir d’un conflit de résolution de dépendances litellm / fastmcp dans la version 1.0.31
    • Mettez à niveau vers la version 1.0.32 ou supérieure, ou utilisez uv pip install skyvern
  • Commandes utiles pour le débogage
    • skyvern run server : exécuter séparément le serveur Skyvern
    • skyvern run ui : exécuter l’UI Skyvern
    • skyvern status : vérifier l’état des services
    • skyvern stop all : arrêter tous les services
    • skyvern stop ui : arrêter l’UI
    • skyvern stop server : arrêter le serveur

Licence et télémétrie

  • Par défaut, Skyvern collecte des statistiques d’utilisation afin de comprendre les usages
  • Pour désactiver la télémétrie, définissez la variable d’environnement SKYVERN_TELEMETRY sur false
  • Le dépôt open source de Skyvern est soutenu par un cloud managé
  • La logique principale est fournie dans ce dépôt open source sous licence AGPL-3.0
  • Les mesures anti-bot incluses dans l’offre de cloud managé sont explicitement indiquées comme une exception à la logique principale du dépôt open source

À lire aussi

1 commentaires

 
GN⁺ 2024-10-25
Commentaires sur Hacker News

  • Je me demande comment vous voyez la fonctionnalité computer use de Claude, annoncée récemment par Anthropic
    Maintenant que computer use de Claude vient de sortir, j’aimerais savoir quel est le principal facteur différenciant de Skyvern

    • Je travaille dans ce domaine, et la capacité de Claude à compter les pixels et interagir avec l’écran à des coordonnées précises me semble être une innovation assez utile qui peut améliorer les approches existantes
      Jusqu’ici, l’approche classique consiste généralement à dessiner des boîtes englobantes autour des éléments interactifs, à demander au LLM d’émettre un appel d’outil comme click('A12'), puis à mapper A12 à l’élément HTML réel pour exécuter l’action via Selenium/JS. Dessiner ces boîtes englobantes de manière heuristique est déjà délicat, et obtenir le bon comportement peut aussi être difficile si le gestionnaire de clic est attaché à un autre élément du DOM
      Pour les cas d’automatisation, il est probablement plus efficace d’exécuter directement sur l’écran des actions de haut niveau comme click(x, y) ou type("foo"), sans remapper les éléments visuels vers des éléments HTML. Cela dit, pour l’instant, fournir le HTML comme contexte au LLM tend aussi à donner de meilleures performances que de se limiter à un raisonnement purement visuel. Je suis donc plutôt optimiste sur l’approche de Claude, et particulièrement enthousiaste si le raisonnement visuel continue de progresser
    • Le produit et le lancement d’Anthropic sont vraiment impressionnants, et le fait de pouvoir accomplir beaucoup de choses sur des sites web avec seulement usage d’outils + micro-agents + captures d’écran + coordonnées est marquant
      Cela dit, je doute que les concurrents restent sans rien faire au lieu de construire quelque chose de similaire. Les équipes de xAI, Gemini, OpenAI, Mistral et MetaAI ne vont probablement pas se contenter d’attendre, et comme ce domaine a de fortes chances de devenir un pilier important de l’avenir, il est peu probable qu’une seule entreprise rafle tout
      Il est aussi important de savoir d’où viendra la vraie valeur dans ce type de système. Il est très possible que de belles démos et un produit sympa et utilisable ne suffisent pas, car la plupart des gens veulent surtout de la véritable automatisation de workflow. Pour un usage personnel, cela peut suffire, mais les entreprises voudront probablement quelque chose de plus complexe
      Enfin, la question de savoir si tout cela sera optimisé uniquement pour Claude est également essentielle. Si l’on veut l’exécuter sur son propre LLM open source, ou continuer à changer de modèle pour utiliser en permanence le meilleur du marché, il peut être difficile d’obtenir cette flexibilité avec une solution fournie par un grand acteur. Anthropic a en effet tout intérêt à pousser l’usage interne de Claude
      C’est ce dernier point qui est encourageant. Les utilisateurs open source de Skyvern peuvent choisir le modèle qu’ils veulent et ne sont pas liés à Claude. Il peut aussi fonctionner avec des modèles open source comme Gemini, GPT-4O et Llama 3.2

  • Ce ne sera probablement pas le premier wrapper IA sur Playwright sorti cette semaine, ni même le premier du mois
    L’usage du point de vue de l’automatisation des processus métier semble plus convaincant que l’automatisation des tests. L’automatisation des tests accorde beaucoup plus d’importance à l’exactitude du processus et à sa reproductibilité, alors que pour l’automatisation métier, dans bien des cas, seul le résultat compte, même si on y parvient par un chemin étrange
    Cela dit, dans la vidéo d’exemple, il fallait rédiger un prompt assez conséquent pour le faire fonctionner, et même plusieurs ko de données de payload devaient être fournis en texte brut plutôt qu’au format CSV. Si l’idée est de remplacer des personnes pour qui utiliser directement le générateur de code Playwright est trop technique, je ne suis pas certain qu’il y ait tant de gens capables de faire l’un mais pas l’autre
    En plus, il semble que l’utilisateur doive transmettre en clair jusqu’aux identifiants de connexion au site web et aux informations de carte bancaire. Si le compte Skyvern d’un utilisateur est compromis, il faudra une gestion extrêmement robuste des données sensibles pour éviter des conséquences graves
    Je trouve aussi que les personnes qui construisent des wrappers Playwright basés sur des LLM ont tendance à exagérer la fréquence des refontes de sites web, surtout quand il s’agit de vieux sites ou de sites gouvernementaux. Par exemple, j’exploite depuis des années un long ensemble d’automatisations de navigateur Playwright interagissant avec des sites gouvernementaux, et je n’ai dû faire de maintenance qu’une seule fois, quand la procédure métier de l’organisme a changé. Même avec Skyvern, comme la procédure aurait changé, il aurait fallu modifier le prompt et le payload
    La différence avec l’automatisation Playwright, c’est qu’on peut vérifier par assertions la réussite ou l’échec de chaque étape ainsi que l’exactitude des données enregistrées, ce qui permet de savoir qu’une mise à jour de procédure est nécessaire. Je ne vois pas cette possibilité dans Skyvern, et je crains qu’il ne rate des changements de procédure et commence à saisir de mauvaises données ou à oublier des étapes

    • Il est vrai que la structure actuelle des prompts et des payloads est plutôt du côté complexe, mais nous avons pu utiliser des LLM pour aider les utilisateurs à générer ce payload
      Les utilisateurs techniques veulent en apprendre davantage et créer eux-mêmes leurs payloads, tandis que les utilisateurs non techniques commencent en demandant au LLM de les aider à générer le prompt final pour Skyvern. C’était inattendu, mais le flux s’est révélé étonnamment naturel
      L’étape 1 consiste à construire les choses de manière complexe, c’est-à-dire Playwright, l’étape 2 est l’étape actuelle, qui consiste à fabriquer l’équivalent de Playwright avec des prompts complexes, et l’étape 3 consiste à construire quelque chose qui fabrique l’équivalent de Playwright avec des prompts plus simples. Chaque étape abaisse la barrière technique nécessaire à la création d’automatisations
      Je pense que la fréquence des changements de sites web est une proposition de valeur plus secondaire de l’automatisation basée sur les LLM. La valeur principale, c’est la capacité à gérer des situations très dynamiques. Par exemple, pour automatiser un site e-commerce dont les pop-ups promotionnelles changent chaque semaine, Skyvern s’en soucie à peine, alors qu’un script Playwright peut casser
      J’aime aussi l’exemple de Geico parce qu’il montre bien quelque chose qui était auparavant très difficile à automatiser. Le formulaire change à chaque exécution, et pourtant Skyvern le traverse facilement
      Sur la question de l’exactitude des données, nous sommes en train de lancer une fonctionnalité de workflow permettant d’enchaîner plusieurs tâches. L’aspect intéressant de cette fonctionnalité est qu’elle permet d’ajouter une étape où Skyvern vérifie lui-même le résultat avant de continuer. Par exemple, après avoir ajouté n produits au panier, il peut aller dans le panier et vérifier l’état du panier
      Comme on peut s’y attendre, cela jette aussi les bases pour que d’autres agents utilisent ce type d’outils afin de construire eux-mêmes des workflows avec des prompts plus simples. En résumé, c’est la première étape d’un long parcours visant à rendre l’automatisation des processus métier de plus en plus facile grâce aux LLMs

  • À ce stade, créer une startup au-dessus d’un LLM tiers demande soit beaucoup d’audace, soit un modèle économique axé sur des revenus à court terme
    Si l’horizon n’est pas de quelques mois mais de plusieurs années, le risque est élevé. Anthropic s’est lancé dans ce domaine hier, et il est fort probable qu’OpenAI et Google suivent bientôt

    • De nombreuses entreprises comme Vercel ou Supabase ont bâti de grosses activités en “enveloppant” AWS
      Elles utilisent littéralement AWS tout en le concurrençant pour proposer leurs propres produits. Ce marché est vaste et laisse de la place à des approches variées
      Il est clair qu’OpenAI, Anthropic et Google vont construire de grandes activités dans ce domaine, mais il n’y a aucune raison d’exclure que quelqu’un d’autre ait une bonne idée et la concrétise en s’appuyant sur un grand fournisseur d’infrastructure
    • Je ne sais pas ce que signifie exactement « s’est lancé ». Je ne suis pas bien au courant de ce qui s’est passé

  • Le fait que ce soit open source sous AGPL est intéressant
    La documentation donne peut-être déjà la réponse, mais en parcourant rapidement le code source, j’ai eu l’impression qu’ils n’utilisaient pas LangChain et qu’ils prévoyaient une intégration pour pouvoir contribuer plus tard à cette communauté. Je me demande ce qu’ils ont utilisé pour construire la logique de chaîne pensée/action dans Skyvern et, s’ils recommençaient aujourd’hui, s’ils envisageraient une orientation LangChain/Graph

    • Au début, nous utilisions le framework AutoGPT
      On en voit encore beaucoup de traces dans des éléments comme les tâches et les étapes, mais à mesure que nous avons voulu aller plus loin et traiter des cas plus complexes, nous avons constaté que le framework était très limitant
      Par exemple, nous utilisons aujourd’hui une architecture multi-agents dans laquelle tournent des micro-agents chargés d’analyser des SVG ou de remplir de l’autocomplétion dynamique, et une telle structure aurait été vraiment difficile avec les frameworks existants
      Des frameworks comme LangChain sont bien pour le prototypage initial, mais deviennent trop contraignants quand on veut repousser leurs limites

  • Si « automatisation du navigateur » vous prête à confusion, il s’agit de faire manipuler un site web cible par un programme, comme avec des outils de la famille Selenium
    En général, cela consiste à injecter des événements de frappe au clavier et des mouvements/clics de souris sur un site web appartenant à quelqu’un d’autre pour lui faire accomplir certaines actions. Une fois cela compris, le reste de l’explication devient clair

  • Chaque fois que je vois ce type d’outil d’automatisation de workflow avec LLM, plusieurs questions me viennent sur les cas d’usage et les conséquences à long terme
    D’abord, je me demande si cela sert à contourner les frictions dues au manque d’interopérabilité entre outils. Par exemple, si le propriétaire du site web avait fourni un service REST, cela aurait-il été plus efficace ? Si de tels outils existent, les entreprises pourraient-elles cesser de fournir des endpoints de service même lorsque cela serait pertinent ?
    Ensuite, s’il existe une bonne raison de ne pas avoir d’endpoint de service, par exemple pour des raisons de sécurité, les workflows automatisés peuvent être utilisés pour contourner ces mesures. Un acteur malveillant pourrait-il utiliser l’outil pour désactiver des services majeurs ? Les créateurs de l’outil pourraient-ils eux-mêmes devenir de tels acteurs ? Des revendeurs pourraient-ils l’utiliser pour empêcher les consommateurs ordinaires d’acheter des produits très demandés ?
    Troisièmement, si cela sert à contourner une maintenance interne reportée d’outils et de processus, l’existence de tels outils pourrait donner à la direction un prétexte pour repousser encore davantage cette maintenance. Cela pourrait finir par devenir une dépendance critique dans le workflow du support
    Quatrièmement, si cela sert à contourner de bonne foi des anti-patterns de conception de site web, les propriétaires des sites auront-ils intérêt à casser ces workflows ? Au final, n’est-ce qu’une étape supplémentaire dans une course aux armements ?
    J’ai toujours ce genre de pensée quand je vois qu’on ajoute une couche logicielle sur des processus complexes, en recouvrant le problème d’une couche de complexité supplémentaire au lieu de simplifier le processus à la racine. Il est évident que le projet peut être utile, mais je m’interroge sur ses effets à long terme

    • Les sites web sans API relèvent en général de l’une de deux raisons. Soit ils veulent protéger leurs données, comme LinkedIn, soit ils n’ont ni les moyens ni l’envie de créer une API, comme les petits sites ou les portails gouvernementaux
      Skyvern résout ce problème, mais si le coût des LLM baisse, cela pourrait aussi rendre inutile pour ces sites de créer une API
      Je ne veux pas que Skyvern soit utilisé sur des sites web qui interdisent ce type de comportement. LinkedIn en est l’exemple typique. En particulier, l’une des raisons pour lesquelles nous n’avons pas open sourcé le code lié aux anti-bots ou aux CAPTCHA est que nous recevons des demandes du type « manipulation des recommandations Reddit ». Nous ne voulons pas soutenir ce genre d’acteurs malveillants
      Globalement, je pense que l’automatisation de navigateur par IA a un effet net positif. Si le besoin d’API diminue, il y a moins besoin de maintenir à la fois une API et une UI, l’expérience devient plus simple, et il y a moins de code, donc un système plus simple
      Sur le dernier point, je n’en suis pas certain à 100 %. En général, je pars du principe que si des entreprises ne créent pas d’API, c’est faute de budget, pas pour des raisons malveillantes. Des entreprises comme LinkedIn essaieront sans doute de bloquer les tentatives d’automatisation, mais je ne veux pas participer à ce jeu du chat et de la souris

  • Je me demande si Skyvern peut récupérer des données sur plusieurs sites web à structures différentes et les fusionner en données structurées dans un seul fichier CSV ou JSON
    Par exemple, peut-il récupérer les taux de comptes de dépôt sur plusieurs sites bancaires, extraire le nom de la banque, le logo de la banque, le nom du produit et le taux de chaque compte, puis exécuter la requête enregistrée selon une fréquence comme chaque jour ou chaque semaine ?

    • En théorie, c’est possible. Il faut le configurer avec la fonctionnalité de workflow et chaîner plusieurs tâches pour collecter les informations

  • Je me demande si quelqu’un a déjà essayé Skyvern sur des sites de compagnies aériennes
    Par exemple pour extraire les disponibilités de sièges prime sur des billets en miles entre le point A et le point B. Les compagnies aériennes changent constamment leurs écrans et semblent avoir des protections anti-scraping assez fortes

    • Nous n’avons pas encore aidé sur exactement ce cas d’usage, mais nous sommes en train de faire une intégration avec une entreprise qui l’utilise pour automatiser l’achat de billets Alaska et Southwest à la place de vrais humains
      L’idée sera de beta tester les transactions par carte bancaire et d’en valider la fiabilité

  • Je construis quelque chose de similaire à plus petite échelle, et ce domaine semble assez prometteur
    En limitant le périmètre du problème à l’interaction/scraping sur une seule page, cela a été très stable et utile dans l’entreprise. Mais l’automatisation de type agent a aussi l’air intéressante

    • C’était particulièrement utile dans des situations très dynamiques
      Par exemple, remplir les formulaires de contact de centaines de sites web est vraiment difficile à gérer avec du code classique à cause de toute cette diversité, alors que ce n’est pas un gros problème pour un agent IA

  • Je me demande s’il existe des chiffres sur WebArena(https://webarena.dev) ou VisualWebArena(https://jykoh.com/vwa)

    • Pas encore. Notre dataset interne est trop biaisé, donc nous ne l’avons pas partagé publiquement, mais cela devrait arriver dans quelques semaines