Un agent IA qui navigue sur le web est le dernier recours, pas le premier
Un agent IA qui navigue sur le web fait exactement ce que le nom annonce : il ouvre un navigateur, regarde l'écran, déplace le curseur, tape et clique, comme le ferait une personne. Et c'est là le piège, parce que ça ressemble à une solution universelle : si une personne peut le faire, l'agent le peut. C'est vrai et c'est sans intérêt. Une personne peut aussi recopier mille lignes à la main. Qu'une chose soit possible n'en fait pas la façon sensée de la faire.
La thèse, sans détour : le navigateur, c'est le plan D. Devant lui il y a l'API du système d'en face, l'intégration par connecteur ou iPaaS, et — bien plus souvent qu'on ne l'admet — une personne qui consacre dix minutes par jour à quelque chose qui ne justifie d'automatiser quoi que ce soit. Le navigateur n'entre en scène que si les trois sont réellement fermées. Les voies propres sont dans intégrer l'IA à tes systèmes : ce guide écarte tout ce qui n'est pas un port où se brancher, et celui-ci commence exactement là où l'autre s'arrête, sur le cas qu'il écarte.
La raison de tant de prudence, c'est que cette voie ne casse pas à cause du modèle. Elle casse à cause de choses qui ne dépendent pas de toi : l'écran d'un autre, la session d'un autre, les règles d'un autre. Tu peux tout faire correctement et te réveiller un mardi avec le processus à l'arrêt parce que quelqu'un a déplacé un bouton.
Les trois cas où il n'y a pas d'autre porte
Il existe des situations où le navigateur n'est pas de la paresse : c'est tout ce qui reste. On les reconnaît à un signal commun — ce n'est pas que l'API n'existe pas encore, c'est qu'elle n'existera pas.
- Le portail du fournisseur ou du grand client. On t'oblige à te connecter à leur extranet pour déposer des bons de livraison, télécharger des relevés ou confirmer des commandes. Pas d'API, il n'y en aura pas, et ton volume ne justifie pas qu'on en construise une pour toi. La relation commerciale va dans un sens, et ce n'est pas le tien.
- L'administration. Téléservices, plateformes de marchés publics, registres. Ici l'accès est pensé pour une personne munie de son certificat, et le chemin automatisé soit n'existe pas, soit exige une intégration formelle qui met des mois à être accordée. Attention à ne pas confondre public et ouvert : ce n'est pas la même chose.
- Le vieux système interne. Cet ERP de 2009, l'application de bureau de l'entrepôt, le logiciel installé par un prestataire qui a fermé. Il a une base de données, mais personne ne signe pour y toucher ; il a un écran, et l'écran fonctionne. L'API n'existe pas parce que le budget pour la construire n'existe pas, ce qui est une façon parfaitement valable de ne pas exister.
Le contre-exemple compte autant que les cas. Si le fournisseur a une API et ne te l'a pas donnée parce qu'elle est dans une autre offre tarifaire, ce n'est pas un problème technique : c'est une négociation. Monter un agent qui navigue pour éviter de payer le connecteur coûte généralement plus cher en maintenance la première année que le connecteur lui-même, et ça te place du mauvais côté de leurs conditions d'utilisation. Avant d'écrire la première ligne, demande le prix. Parfois l'automatisation la plus rentable est un e-mail à un commercial.
Ce qui casse toujours : cinq pannes qui ne dépendent pas de toi
Ces cinq-là ne sont pas des risques hypothétiques qui surviendront peut-être. C'est le calendrier de maintenance de tout agent qui vit dans le navigateur d'un autre. Qui te vend ça sans les mentionner ne l'a jamais eu en production.
- L'interface change et personne ne te prévient. Pas de versionnage, pas de note de version, pas de période de grâce. Une refonte, un nouveau champ obligatoire ou un bandeau cookies différent, et le flux s'arrête à mi-chemin. Avec une API cassée, tu l'apprends par un code d'erreur ; ici, tu l'apprends parce que quelqu'un demande pourquoi les factures ne sont pas arrivées.
- La session expire et le second facteur ne négocie pas. Garder un agent authentifié dans le système d'un tiers est le problème ennuyeux qui absorbe la moitié du temps d'exploitation. Si l'accès exige un code à usage unique, une application sur le téléphone de quelqu'un ou un certificat sur une carte, il y a une personne dans la boucle par conception. Ce n'est pas une défaillance de l'agent : c'est une décision de sécurité de l'autre partie, et elle est légitime.
- Le captcha et les conditions d'utilisation. Le captcha n'est pas un obstacle technique qu'on contourne : c'est l'autre partie qui dit explicitement qu'elle ne veut pas de trafic automatisé. Le franchir rompt en général les conditions du service et, selon le contexte, un peu plus que les conditions. Quand un captcha apparaît, la bonne conversation n'est pas avec l'équipe technique, elle est avec celui qui signe le contrat.
- La page qu'il lit peut aussi lui donner des ordres. Un agent qui navigue ne distingue pas de façon fiable le contenu qu'on lui demande de lire d'une instruction cachée dans ce contenu. Ce n'est pas un problème de maturité sur le point d'être réglé : OpenAI a déclaré en décembre 2025 que l'injection de prompt, à l'image des arnaques et de l'ingénierie sociale, a peu de chances d'être un jour totalement résolue (TechCrunch, 22 décembre 2025), et Anthropic a publié ses résultats de robustesse en navigation avec un avertissement explicite : aucun agent de navigateur n'est immunisé (Anthropic, 24 novembre 2025). La conséquence pratique relève de l'architecture, pas du prompt : l'agent ne peut nuire que jusqu'où portent ses identifiants.
- Le coût et l'horloge se comptent par étape. Chaque étape est une capture d'écran, une décision du modèle et une action. Une tâche de douze étapes, ce sont douze décisions avec image, pas un appel. Ce qui par API est une requête de quelques millisecondes devient ici des minutes et une consommation qui grimpe à chaque reprise.
Pourquoi le score du benchmark ne prédit pas le tien
Les chiffres publics de cette catégorie sont meilleurs que ce que beaucoup croient et moins bons que ce que suggère la démo. Sur WebArena, le banc d'essai de référence, le meilleur système suivi au classement public tourne autour de 74 % de tâches accomplies, contre 78 % pour une personne (Steel.dev, classement WebArena). OpenAI a rapporté pour son agent d'usage d'ordinateur 87 % sur WebVoyager et 58,1 % sur WebArena lors de ses tests internes. Des chiffres respectables pour un problème difficile.
Le problème, c'est ce qu'ils mesurent. Ces bancs d'essai tournent sur des répliques de sites publics, par le bon chemin, sans authentification d'entreprise, sans second facteur, sans captcha et — c'est le point important — sans conséquence. Un clic de travers dans un benchmark ajoute un échec à un tableau. Un clic de travers sur le portail de ton fournisseur valide une commande de onze mille euros. Il n'y a aucun moyen de transposer un pourcentage du premier au second, alors n'essaie pas : la seule donnée qui compte est la tienne, mesurée sur ton portail, avec tes cas réels, pendant deux semaines en mode observation.
Traduit en décision : n'achète ni sur la démo ni sur le tableau. Demande un essai sur ton écran, cas tordus inclus — le fournisseur qui écrit le numéro de facture avec un tiret, la commande avec deux lignes annulées — et compte combien de fois il faut le rattraper. Ce pourcentage-là déterminera si le processus t'épargne du travail ou s'il le déplace simplement ailleurs.
Les quatre conditions pour passer en production
Si le cas est légitime et que l'essai s'est raisonnablement passé, il manque encore la partie qui sépare une expérimentation de quelque chose qu'on peut laisser tourner seul. Quatre conditions, aucune facultative : avec trois sur quatre, ça ne part pas en production.
- Action réversible. L'agent n'exécute que des choses qu'on peut défaire sans appeler personne : télécharger, lire, remplir un brouillon, enregistrer sans envoyer. Confirmer, payer, signer et annuler restent hors du périmètre automatique dès le premier jour, même si l'agent est parfaitement capable de cliquer dessus.
- Limite d'étapes stricte. Un plafond d'actions par tâche qui, une fois atteint, arrête et alerte. Sans lui, un agent perdu sur un écran qu'il ne comprend pas relance jusqu'à épuiser le budget, et le premier signal que quelque chose n'allait pas arrive sur la facture.
- Capture de chaque action. Capture d'écran ou journal de ce qu'il a vu et de ce qu'il a cliqué, à chaque étape, conservé hors de la session. Ce n'est pas de la bureaucratie : c'est la seule chose qui permet de reconstituer ce qui s'est passé quand le fournisseur affirme qu'une commande a été confirmée dont personne ne se souvient. Sans preuve, pas d'audit ; et sans audit, ce n'est pas un système, c'est un pari.
- Humain sur l'irréversible. L'étape qui engage de l'argent, envoie quelque chose à un tiers ou change un état qu'on ne peut pas revenir en arrière passe par une personne qui voit ce qui va se produire et l'approuve. Avec assez de contexte pour décider en dix secondes, pas une fenêtre qu'on valide par réflexe.
Les deux dernières conditions ne sont pas propres à cette voie : ce sont celles qui régissent quelles permissions donner à un agent IA et quelle autonomie lui accorder. Ce qui change ici, c'est la marge : quand l'agent agit sur l'écran d'un autre, avec l'identifiant d'un de tes salariés, l'erreur ne reste pas à la maison.
L'ordre de décision, en un après-midi
Quatre questions, dans cet ordre. La première qui donne un oui tranche, et si tu arrives à la quatrième tu sais déjà à quoi tu t'exposes.
- Y a-t-il une API et peut-on te la donner ? Si elle existe, même payante, demande le prix avant de programmer quoi que ce soit. Un connecteur ennuyeux bat un agent brillant qui casse à chaque refonte.
- Y a-t-il une intégration déjà faite — connecteur, iPaaS, export programmé ? L'export nocturne vers un fichier, dont personne ne se vante en démo, résout plus de processus qu'on ne le croit, et il ne casse pas.
- Combien de travail humain y a-t-il vraiment ici ? Dix minutes par jour ne paient pas la maintenance d'un agent qui navigue. Mesure-le avant de décider ; parfois le résultat de l'exercice est de ne pas automatiser, et c'est une réponse parfaitement bonne.
- Si tu es arrivé jusqu'ici, les quatre conditions sont-elles remplies ? Réversible, plafond d'étapes, capture de tout, humain sur l'irréversible. S'il en manque une, le processus n'est pas prêt, et le forcer revient à acquérir un risque pour économiser une formalité.
Nous venons à cette voie à contrecœur et nous l'utilisons quand il le faut, c'est-à-dire plus souvent que nous le voudrions : une bonne partie de l'Europe facture encore contre des portails sans API. Quand c'est le cas, nous la montons avec les quatre conditions posées dès le premier jour et la maintenance budgétée, car ce qui tue ces projets n'est pas de les construire, c'est la troisième refonte. C'est ce qu'il y a sous l'automatisation des opérations et sous l'infrastructure d'IA d'entreprise quand le processus doit cohabiter avec des systèmes déjà en production. Le reste des décisions de montage — permissions, autonomie, mémoire, canal — est dans créer un agent IA qui tient en production.