Web Agents : et si le terminal remplaçait le navigateur ?

L’automatisation web passe souvent par un agent qui pilote un navigateur. Il clique, tape, fait défiler. Une seule session, continue. Cette approche semble naturelle, mais elle pose un vrai problème : tout reste lié à l’état du navigateur.

Le piège des sessions persistantes

Quand l’agent reste accroché à la même instance, chaque action dépend de la précédente. Une erreur ? Il faut tout reprendre. Le navigateur grossit, les cas limites s’accumulent, et il devient difficile d’inspecter ou de relancer une partie du parcours.

Résultat :

• trop d’état à gérer
• debug compliqué
• aucune réutilisation possible

Webwright : jeter le navigateur, garder le code

Webwright inverse la logique. Au lieu de conserver une session navigateur, l’agent crée des instances fraîches à chaque fois. Il les utilise, en extrait ce dont il a besoin, puis les supprime. Ce qui reste, ce n’est pas le navigateur : c’est le code, les logs, les captures et les fichiers générés dans le dossier local.

Le navigateur devient un outil jetable. Le vrai livrable, c’est le script.

Trois principes simples

1. Du code, pas des clics
Au lieu d’enchaîner « clique ici, attends, tape là », l’agent construit des fonctions réutilisables. Sélection de dates, remplissage de formulaires, filtrage : tout devient du code propre et maintenable.

2. Des artefacts qui durent
Chaque tâche laisse des traces concrètes : scripts d’exploration, logs, captures d’écran. Ce dossier de travail devient la base des futures automatisations. Il est lisible, partageable, versionnable.

3. Une architecture minimale
Trois composants suffisent : un runner, un modèle et l’environnement terminal. Environ 1 000 lignes de code. Pas de superstructures multi-agents. Juste une boucle simple entre le modèle et le terminal.

La boucle en action

1. Le runner envoie la tâche et l’état du workspace au modèle.
2. Le modèle répond par une commande shell (souvent un script Playwright).
3. L’environnement exécute, renvoie les résultats, logs et captures.
4. La boucle continue jusqu’à obtenir un script final, relancé dans un dossier propre et validé par auto-évaluation.

Pas de routage complexe. Juste un terminal et un modèle qui itèrent.

Des résultats concrets

Sur des tâches web réelles :

• 60,8 % de réussite sur le benchmark Odyssey (longue séquence de navigation)
• 86,7 % sur Online-Mind2Web, 300 tâches sur 136 sites
• 66,2 % même avec un modèle plus petit (Qwen 3.5-9B) quand des outils réutilisables sont fournis

Ce ne sont pas des tests jouets. Ce sont des sites en production.

Garder le contrôle

Donner l’accès complet au terminal est puissant, mais risqué. Webwright ajoute trois garde-fous :

• Validation finale obligatoire : l’agent ne peut pas s’arrêter tant qu’il n’a pas relancé son script dans un environnement propre et vérifié les résultats.
• Compression du contexte : les trajectoires longues sont résumées périodiquement pour rester dans les limites du modèle.
• Outils réutilisables : une fois un script validé, il peut être paramétré et transformé en commande CLI, partagé avec d’autres agents.

Ce que ça change pour les développeurs

L’approche de Webwright repose sur quatre idées clés :

• séparer l’intelligence de l’exécution
• privilégier les sessions jetables
• composer des fonctions plutôt qu’enchaîner des actions
• exiger une vérification avant de valider

Le navigateur passe, le terminal reste. C’est là que vit le code, que s’accumulent les preuves.

Une nouvelle direction

Au lieu de construire des machines à états de plus en plus complexes, Webwright propose d’écrire du code. Le navigateur devient accessoire. Le workspace devient la mémoire.

L’idée est encore jeune, mais elle montre une voie plus fiable et plus maintenable pour les systèmes d’agents — pas seulement pour le web, mais pour toute tâche qui demande exploration et itération.

Si vous travaillez sur l’automatisation ou les agents, le dépôt GitHub de Webwright mérite un coup d’œil. Le message est simple : un terminal suffit.