Qu’est-ce que l’utilisation d’un ordinateur et pourquoi est-elle importante? L’utilisation d’un ordinateur est une idée simple aux vastes implications : plutôt que de demander aux modèles de répondre à des questions, nous leur demandons d’utiliser des logiciels — parcourir des sites Web, remplir des formulaires, suivre des processus en cliquant et accomplir des tâches de bout en bout de façon autonome.
Cela rend possible une vaste catégorie de tâches concrètes actuellement fragmentées entre plusieurs interfaces, comme les réservations de bout en bout, les paiements en ligne, la planification de voyages en plusieurs étapes et les processus administratifs sans équivalent API adéquat. Ces problèmes ne sont pas nouveaux. Ce qui est nouveau, c’est la possibilité 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, se remettent 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 aussitôt : quelle part de cet environnement devons-nous exposer au modèle?
Les premiers systèmes ont répondu en encapsulant le navigateur dans un ensemble fixe d’actions sécuritaires prédéfinies. Comme nous le montrerons dans cet article, cette approche atteint ses limites.
Lors de la création d’agents de navigation, un réflexe courant consiste à ne pas trop faire 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 tentons de rendre le comportement compréhensible 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 s’améliorent, le problème n’est plus seulement le manque d’outils du modèle. C’est que nous l’obligeons à passer par des abstractions qui retirent 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’information.
Ce compromis devient moins intéressant.
Le changement que nous explorons est simple à décrire, mais lourd de conséquences. Plutôt que de traiter l’agent comme un sélecteur d’actions prédéfinies, nous le traitons comme un synthétiseur de programmes fonctionnant 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 : ils ont besoin de l’espace d’action complet pour concevoir, exécuter et améliorer la tâche jusqu’à l’atteinte de leur objectif.
Cet article porte sur ce passage d’une automatisation du navigateur riche en abstractions à une utilisation contrainte de l’ordinateur, et sur les 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 conforme pas.
Les interfaces modernes sont conçues avec React, Vue et Angular, et comprennent des mises à jour d’état asynchrones, des systèmes d’événements synthétiques et des composants tiers intégrés dans des iframes interorigines ayant leur propre cycle de vie. Une enveloppe qui dit « saisir dans ce champ » n’est correcte que si la page accepte votre définition de la saisie. Beaucoup ne l’acceptent pas. L’attribution directe d’une valeur contourne souvent entièrement la détection des changements du cadriciel. Le champ semble rempli. La validation ne se déclenche jamais. Le formulaire reste défectueux.
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 que le réseau soit inactif avant de lire l’état. Chaque correctif est pertinent localement. 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 fondamental 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 intégré par Stripe ou Adyen dans un iframe interorigine. Votre enveloppe ne peut pas y accéder directement, car il se trouve dans 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 enveloppes se heurte ici à un mur. L’abstraction a été conçue pour le document principal. La tâche réelle se trouve dans un endroit invisible pour l’abstraction.
Un décalage semblable apparaît dans des processus moins évidents. Une liste déroulante contrôlée par un cadriciel peut ne pas réagir du tout aux clics directs, 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 processus modal en plusieurs étapes où les mises à jour du DOM visible accusent un retard sur les changements d’état internes. La prochaine action appropriée dépend d’une transition d’état qui ne se reflète pas encore dans les éléments visibles pour votre enveloppe. Un agent fondé sur des enveloppes agit alors trop tôt ou lit un état périmé, car sa vue du système est incomplète.
Dans chaque cas, l’abstraction masque les signaux dont l’agent a réellement besoin.
Un modèle qui fonctionne à un niveau inférieur — en inspectant le DOM actif, en raisonnant sur les limites des cadres et en synthétisant la séquence d’interaction propre à 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 à l’information qui avait été retirée.
Le changement visé est simple à décrire : plutôt que de demander au modèle de choisir parmi des actions prédéfinies, nous lui donnons une surface d’exécution de niveau inférieur et la contraignons par des politiques d’exécution plutôt que par la conception d’abstractions.
Ce choix de conception découle d’une évolution générale du secteur qui commence à favoriser des outils primitifs de niveau inférieur, lesquels tirent parti de la capacité innée de l’agent à se corriger à l’exécution et à produire du code de grande qualité, plutôt que des outils précis codés en dur qui sont robustes, mais limitent la capacité du modèle à s’adapter à différents environnements.
Pensons au succès de Claude Code comme outil principal de nombreux développeurs, ainsi qu’à l’adoption croissante des agents fonctionnant dans un terminal. Le plus grand avantage de Claude Code n’est pas le modèle lui-même, mais le harnais de niveau inférieur. Donner au modèle moins d’outils, mais des outils plus modulaires et de niveau inférieur — c.-à-d. le terminal — améliore l’appel d’outils, surtout parce que l’agent peut raisonner et créer des scripts personnalisés pour la tâche en cours, plutôt que de tenter d’utiliser des outils généralisés qui polluent les fenêtres contextuelles.
Dans le cas de l’automatisation du navigateur, cela signifie concrètement que le modèle peut inspecter directement l’état actif de la page, parcourir les cadres et créer un code d’interaction sur mesure pour l’interface actuelle, plutôt que de tout ramener à un ensemble fixe d’actions préconstruites.
Le modèle se comporte moins comme un sélecteur et davantage comme un auteur de code à l’exécution. Il inspecte l’état actuel, raisonne sur l’interface et synthétise la logique d’interaction adaptée à cette situation précise. Il peut créer des séquences en plusieurs étapes, s’adapter à des processus inhabituels et valider les résultats avant de poursuivre. Lorsqu’une action échoue, le modèle voit l’erreur sous-jacente et se corrige. Cette approche est plus puissante et plus risquée, mais elle correspond beaucoup mieux à la nature réelle du problème.
Il est important de noter que le retrait de la couche d’abstraction ne rend pas le système moins rigoureux. Il déplace cette rigueur.
Le travail auparavant consacré à la conception d’enveloppes et à la gestion des cas limites se déplace vers trois endroits : l’invite (qui devient une forme de formation opérationnelle), l’environnement d’exécution (qui impose des limites comme la portée de navigation, les actions sensibles et le comportement de nouvelle tentative) 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.
L’une des conséquences de ce changement est que le code produit devient souvent plus simple, même si le système global gagne en capacités. Au lieu d’encoder les modèles d’interaction sous forme d’enveloppes réutilisables, l’agent synthétise le 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 logique pour les cas limites.
Cela change aussi la façon dont le système généralise. Un agent fondé sur des enveloppes généralise bien aux tâches qui ressemblent aux enveloppes déjà créées. 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 si l’interface visible diffère.
Par exemple, interagir avec un formulaire de recherche, un processus de réservation ou une page de paramètres peut sembler complètement différent dans l’interface utilisateur. Mais sous la surface, ces interactions partagent des modèles : lecture de l’état, déclenchement d’événements, validation des résultats et gestion des mises à jour asynchrones. Un système qui fonctionne à ce niveau s’adapte 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 à inspecter l’état, à agir de façon sécuritaire 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, contraintes de façon appropriée. Une assistance excessive encode en dur des hypothèses sur la façon d’accomplir une tâche. Les contraintes définissent des limites opérationnelles sécuritaires et permettent au modèle de découvrir de meilleures solutions locales.
Une surface d’exécution plus puissante exige aussi un modèle de sécurité plus rigoureux. Dès que l’agent n’est plus limité à un petit ensemble d’actions prédéfinies, il agit en pratique directement sur de vrais logiciels. Cela modifie immédiatement le profil de risque.
La conception doit tenir compte de quatre enjeux :
Exposition des données. Si l’agent interagit avec de vraies interfaces, il rencontrera souvent des renseignements sensibles. Il faut donc 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 et traces doivent être gérés avec soin afin que l’observabilité ne devienne pas la partie la plus sensible du système.
Portée de l’exécution. Un agent puissant ne doit pas pouvoir agir sans limites. En pratique, il faut restreindre les endroits où il peut naviguer, les domaines auxquels il peut accéder et les systèmes avec lesquels il peut interagir. Ces contraintes doivent être appliquées au niveau de l’exécution, plutôt que laissées comme simples conventions dans les invites.
Fiabilité de l’environnement. Les interfaces modernes peuvent contenir des instructions, du contenu ou des parcours trompeurs, voire activement hostiles. L’injection d’invite par le contenu d’une page constitue une véritable surface d’attaque. Le système a besoin d’une hiérarchie claire d’instructions, de contrôles de validation et de conditions d’arrêt pour empêcher l’agent de suivre des directives non prévues.
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 être hautement 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. L’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 offrir au modèle un espace d’action complet, et comment l’encadrer par des politiques d’exécution qui assurent tout de même sa sécurité?
Ce recadrage change vos priorités. Les taxonomies d’actions et l’exhaustivité des enveloppes 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 remplacent pas mutuellement. À mesure que les modèles s’améliorent, le travail du système gagne en importance plutôt que d’en perdre.
Les agents de navigation efficaces en démonstration réussissent souvent parce que la tâche est ciblé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’enveloppes. Plus 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 vaste où l’utilisation d’un ordinateur devient une discipline des systèmes.