Qu’est-ce que l’utilisation de l’ordinateur et pourquoi est-elle importante ? L’utilisation de l’ordinateur est une idée simple aux vastes implications : au lieu de demander aux modèles de répondre à des questions, nous leur demandons d’utiliser des logiciels — parcourir des sites web, remplir des formulaires, avancer dans des processus et accomplir des tâches de bout en bout, de manière autonome.
Cela ouvre l’accès à une vaste catégorie de tâches concrètes aujourd’hui fragmentées entre différentes interfaces : réservations de bout en bout, paiements en ligne, planification de voyages en plusieurs étapes ou processus administratifs sans équivalent API propre. Ces problèmes ne sont pas nouveaux. Ce qui est nouveau, c’est qu’il est désormais possible de les résoudre avec des modèles généralistes.
Des systèmes récents d’Anthropic et d’OpenAI ont présenté des agents qui ne se contentent pas d’agir : ils raisonnent sur l’état, récupèrent après des erreurs et élaborent à la volée des solutions propres à chaque tâche. Le navigateur devient ainsi un environnement d’exécution général pour les agents, mais une question de conception se pose immédiatement : quelle part de cet environnement faut-il exposer au modèle ?
Les premiers systèmes ont répondu en encapsulant le navigateur dans un ensemble fixe d’actions sûres et prédéfinies. Comme nous l’expliquerons dans cet article, cette approche atteint ses limites.
Lors de la création d’agents de navigation, un réflexe courant consiste à ne pas accorder trop de confiance au modèle.
Nous encapsulons donc le navigateur. Nous exposons des outils prédéfinis comme click, type, scroll, select et read_text. Nous simplifions le modèle objet de document (DOM). Nous réduisons l’espace d’action. Nous essayons de rendre le comportement lisible et contrôlable au moyen d’abstractions que nous concevons.
C’est un point de départ raisonnable. Mais c’est aussi, de plus en plus, la mauvaise architecture à long terme.
À mesure que les modèles de pointe progressent, le problème ne tient plus seulement au manque d’outils du modèle. Il tient au fait que nous l’obligeons à passer par des abstractions qui éliminent une trop grande partie du système sous-jacent. Nous comprimons un environnement désordonné et dynamique dans une interface d’action fixe, puis demandons au modèle de bien fonctionner malgré cette perte d’informations.
Ce compromis devient moins intéressant.
L’évolution que nous explorons est simple à décrire, mais lourde de conséquences. Au lieu de considérer l’agent comme un sélecteur d’actions prédéfinies, nous le traitons comme un synthétiseur de programmes opérant dans un environnement d’exécution contraint.
Les modèles sont devenus très performants et n’ont plus besoin de vos garde-fous abstraits : il leur faut l’espace d’action complet pour concevoir, exécuter et améliorer la tâche jusqu’à atteindre leur objectif.
Cet article traite de cette évolution, qui fait passer d’une automatisation du navigateur riche en abstractions à une utilisation contrainte de l’ordinateur, et des changements qu’entraîne cette conception des systèmes.
Le problème n’est pas que les interfaces d’action fixes soient conceptuellement erronées. C’est que le Web ne s’y plie pas.
Les interfaces modernes reposent sur React, Vue et Angular, avec des mises à jour d’état asynchrones, des systèmes d’événements synthétiques et des widgets tiers intégrés dans des iframes interorigines ayant leur propre cycle de vie. Un encapsuleur qui dit « saisir dans ce champ » n’est correct que si la page partage votre définition de la saisie. Beaucoup ne la partagent pas. Définir directement une valeur contourne souvent entièrement la détection des changements du framework. Le champ semble rempli. La validation ne se déclenche jamais. Le formulaire reste inutilisable.
Vous pouvez corriger cela. Vous pouvez ajouter des cas particuliers pour les champs React, déclencher des événements blur après focus et attendre l’inactivité du réseau avant de lire l’état. Chaque correctif est localement pertinent. Ensemble, ils s’accumulent pour former un système de plus en plus difficile à maintenir et de plus en plus propre aux sites déjà rencontrés.
Le problème profond est que vous encodez dans la couche d’abstraction des hypothèses sur le fonctionnement attendu des interactions, avant de découvrir que le Web repose sur d’autres hypothèses.
Prenons un formulaire de paiement Stripe ou Adyen intégré dans une iframe interorigine. Votre encapsuleur ne peut pas y accéder directement, car il réside sur une origine distincte. Votre outil read_text ne peut pas observer son état interne. Votre outil type ne peut pas cibler ses champs. Un agent fondé sur des encapsuleurs se heurte ici à un mur. L’abstraction a été conçue pour le document principal. La tâche réelle se trouve là où l’abstraction ne peut pas voir.
Un décalage similaire apparaît dans des parcours moins évidents. Une liste déroulante contrôlée par un framework peut ne réagir à aucun clic direct, car l’élément visible n’est pas la véritable commande. Elle peut nécessiter une séquence d’événements clavier pour déclencher la transition d’état sous-jacente. De l’extérieur, l’interface semble cliquable. L’abstraction dit « cliquer ». Rien ne se passe.
Prenons aussi un parcours modal en plusieurs étapes dans lequel les mises à jour visibles du DOM sont en retard sur les changements d’état internes. L’action suivante correcte dépend d’une transition d’état qui ne se reflète pas encore dans les éléments visibles par votre encapsuleur. Un agent fondé sur des encapsuleurs finit par agir trop tôt ou lire un état obsolète, car sa vision du système est incomplète.
Dans chaque cas, l’abstraction masque les signaux dont l’agent a réellement besoin.
Un modèle opérant à un niveau inférieur — en examinant le DOM actif, en raisonnant sur les limites des cadres et en synthétisant la séquence d’interaction adaptée à cette surface — peut gérer ces situations. Ce n’est pas que le modèle soit intrinsèquement plus intelligent. C’est qu’il a accès aux informations qui avaient été supprimées.
Le changement vers lequel nous travaillons est simple à décrire : au lieu de demander au modèle de choisir parmi des actions prédéfinies, nous lui fournissons une surface d’exécution de plus bas niveau et la contraignons au moyen de politiques d’exécution plutôt que par la conception d’abstractions.
Ce choix de conception découle d’une évolution plus large du secteur, qui commence à privilégier des outils primitifs de plus bas niveau. Ceux-ci tirent parti de la capacité innée de l’agent à se corriger à l’exécution et à produire du code de qualité, contrairement à des outils spécifiques codés en dur, robustes mais qui privent le modèle de sa faculté d’adaptation à différents environnements.
Il suffit de voir le succès de Claude Code, devenu un outil privilégié de nombreux développeurs, et l’évolution générale du secteur vers les agents fondés sur le terminal. Le principal avantage de Claude Code n’est pas le modèle lui-même, mais le harnais de plus bas niveau. Fournir au modèle des outils moins nombreux, plus modulaires et de plus bas niveau, c’est-à-dire le terminal, améliore les performances d’appel d’outils, principalement parce que l’agent peut raisonner et créer des scripts sur mesure pour la tâche en cours, plutôt que d’essayer d’utiliser des outils généralistes qui encombrent la fenêtre de contexte.
Dans le cas de l’automatisation du navigateur, cela signifie concrètement que le modèle peut examiner directement l’état actif de la page, parcourir les cadres et élaborer un code d’interaction sur mesure pour l’interface actuelle, au lieu de tout ramener à un ensemble fixe d’actions préconstruites.
Le modèle se comporte moins comme un sélecteur que comme un auteur à l’exécution. Il examine l’état actuel, raisonne sur l’interface et synthétise la logique d’interaction propre à cette situation. Il peut construire des séquences en plusieurs étapes, s’adapter à des parcours inhabituels et valider les résultats avant de poursuivre. Lorsqu’une action échoue, le modèle voit l’erreur sous-jacente et se corrige lui-même. Cette approche est plus puissante et plus risquée, mais elle correspond bien mieux à la nature réelle du problème.
Surtout, la suppression de la couche d’abstraction ne rend pas le système moins rigoureux. Elle déplace cette rigueur.
Le travail auparavant consacré à la conception des encapsuleurs et à la gestion des cas limites se déplace vers trois éléments : le prompt, qui devient une forme de formation opérationnelle ; l’environnement d’exécution, qui impose des limites concernant notamment le périmètre de navigation, les actions sensibles et les nouvelles tentatives ; et la couche d’évaluation, qui détermine non seulement si la tâche a réussi, mais aussi si les étapes intermédiaires étaient correctes. Moins d’abstractions fragiles. Des systèmes environnants plus robustes.
Cette évolution simplifie souvent le code produit, tout en renforçant les capacités globales du système. Au lieu d’encoder les schémas d’interaction sous forme d’encapsuleurs réutilisables, l’agent synthétise son comportement à l’exécution. Vous maintenez un petit ensemble de primitives puissantes et un environnement d’exécution contraint, plutôt qu’une gamme croissante d’outils spécialisés et de logiques dédiées aux cas limites.
Cela change également la manière dont le système généralise. Un agent fondé sur des encapsuleurs généralise bien aux tâches qui ressemblent à celles pour lesquelles vous avez déjà créé des encapsuleurs. Un agent doté d’un environnement d’exécution contraint généralise aux tâches qui partagent un même substrat d’exécution, même lorsque l’interface visible diffère.
Par exemple, interagir avec un formulaire de recherche, un parcours de réservation ou une page de paramètres peut sembler totalement différent au niveau de l’interface utilisateur. Mais ces interactions reposent sur des schémas communs : lecture de l’état, déclenchement d’événements, validation des résultats et gestion des mises à jour asynchrones. Un système qui intervient à ce niveau se transpose plus naturellement d’une tâche à l’autre.
Le composant réutilisable n’est pas la liste d’actions. C’est la capacité du modèle à examiner l’état, à agir en toute sécurité et à vérifier les résultats.
La leçon la plus claire de ce travail est que la fiabilité ne vient pas de l’ajout de fonctions auxiliaires pour le modèle. Elle vient souvent d’un nombre réduit de primitives plus puissantes, assorties de contraintes adaptées. La surassistance inscrit en dur des hypothèses sur la manière d’accomplir une tâche. Les contraintes définissent des limites opérationnelles sûres et permettent au modèle de trouver de meilleures solutions locales.
Une surface d’exécution plus puissante exige également un modèle de sécurité plus rigoureux. Dès lors que l’agent n’est plus limité à un petit ensemble d’actions prédéfinies, il intervient de fait directement sur de vrais logiciels. Cela modifie immédiatement le profil de risque.
Quatre aspects doivent être pris en compte dès la conception :
Exposition des données. Si l’agent interagit avec de vraies interfaces, il rencontrera souvent des informations sensibles. Cela exige une approche rigoureuse du masquage et du contrôle d’accès. Les données ne doivent être révélées que lorsque l’exécution l’exige, et les journaux comme les traces doivent être traités avec précaution afin que l’observabilité ne devienne pas la partie la plus sensible du système.
Périmètre d’exécution. Un agent puissant ne doit pas pouvoir intervenir sans limites. En pratique, il faut restreindre les espaces où il peut naviguer, les domaines auxquels il peut accéder et les systèmes avec lesquels il est autorisé à interagir. Ces contraintes doivent être appliquées au niveau de l’environnement d’exécution, et non laissées comme de simples conventions dans les prompts.
Confiance dans l’environnement. Les interfaces modernes peuvent contenir des instructions, des contenus ou des parcours trompeurs, voire activement hostiles. L’attaque par injection de prompt via le contenu des pages constitue une véritable surface d’attaque. Le système a besoin d’une hiérarchie claire des instructions, de contrôles de validation et de conditions d’arrêt pour empêcher l’agent de suivre des consignes indésirables.
Spectre d’autonomie. Toutes les actions ne doivent pas être entièrement autonomes. Dans de nombreux environnements de production, il est important de considérer l’autonomie comme un spectre. Le système peut se montrer très agentique dans son exploration et son exécution, tout en exigeant une approbation pour certaines catégories d’actions.
Le principe sous-jacent est simple : donner plus de pouvoir au modèle exige de renforcer le système qui l’entoure. Une autonomie sans politique n’est pas prête pour la production.
Nous avons cessé de demander : quelles actions du navigateur faut-il exposer ?
Nous avons commencé à demander : comment fournir au modèle un espace d’action complet, et comment l’entourer de politiques d’exécution qui préservent la sécurité ?
Ce changement de perspective modifie vos priorités. Les taxonomies d’actions et l’exhaustivité des encapsuleurs comptent moins. Les politiques d’exécution, l’observabilité et l’évaluation de chaque étape comptent davantage. Les capacités du modèle et la conception du système ne se substituent pas l’une à l’autre. À mesure que les modèles progressent, le rôle du système gagne en importance au lieu d’en perdre.
Les agents de navigation efficaces en démonstration réussissent souvent parce que la tâche est limitée et l’environnement coopératif. Les systèmes de production exigent autre chose : une exécution contrainte, un comportement instrumenté et une évaluation capable de distinguer un résultat correct d’un résultat chanceux.
Moins de conception d’encapsuleurs. Davantage d’ingénierie des systèmes.
Et même si nous nous sommes concentrés sur les agents de navigation, cela ouvre une perspective plus large : considérer l’utilisation de l’ordinateur comme une discipline d’ingénierie des systèmes.