Plaidoyer pour l'automatisation ennuyeuse

Pourquoi Pollen mise sur des heuristiques et une touche d'IA — plutôt qu'un agent navigateur — et se révèle au final plus rapide, moins cher et plus fiable que la hype.

Si vous avez suivi la conversation sur les « agents IA » ces derniers mois, vous avez sûrement entendu ce pitch : un agent autonome regarde votre écran, lit la page, réfléchit à ce qu'il faut faire, et se fraie un chemin sur n'importe quel site. Langage naturel en entrée, tâche accomplie en sortie. Plus de sélecteurs. Plus de scripts. Plus d'intégrations.

La démo est bluffante. Mais pour la tâche la plus courante sur le web — remplir un formulaire — c'est presque toujours le mauvais outil.

Pollen a fait le pari inverse. On a écrit une extension Chrome qui capture les données d'un formulaire sur un site et les rejoue dans un formulaire d'un autre, y compris sur des pages qu'on n'a jamais vues. On a envisagé de la bâtir comme un agent autonome. On a choisi de ne pas le faire. Cet article explique pourquoi.

Le résumé en une ligne : utiliser l'IA pile là où elle apporte de la valeur, et pas plus loin.

---

Ce que promettent les agents navigateur autonomes

Le pitch s'écrit tout seul. Vous dites à un agent : « Remplis le formulaire d'inscription du site B avec les mêmes données que je viens de soumettre sur le site A. » L'agent :

1. Regarde votre écran (ou lit le DOM)
2. Déduit le sens de chaque champ
3. Clique, tape, scrolle, soumet

Sous le capot, c'est un LLM dans une boucle serrée avec un driver de navigateur — computer use API de Claude, Browser Use, Skyvern, OpenAI Operator, Stagehand, Lavague. Choisissez votre poison. L'interface, c'est du langage naturel ; le backend, c'est un modèle qui génère des actions.

Quand ça marche, on croirait à de la magie.

Ce que les agents navigateur autonomes vous coûtent vraiment

Quand ça ne marche pas — c'est-à-dire la plupart du temps, dès qu'on passe à l'échelle — voilà la facture :

Latence. Une exécution d'agent, c'est une boucle LLM. À chaque étape : capture d'écran → tokenisation → raisonnement → action → on attend que la page réponde → on recommence. Un seul formulaire prend 30 à 120 secondes. Multipliez par 100 soumissions et vous avez largement le temps de regarder la peinture sécher.

Argent. Chaque étape consomme des tokens. Les agents façon computer-use envoient des captures d'écran entières dans la fenêtre de contexte ; ceux qui lisent le DOM envoient des bouts de HTML sérialisé. En pratique, un remplissage coûte entre 0,10 $ et 1,00 $, selon le modèle et la complexité de la page.

Non-déterminisme. Les LLM sont probabilistes. Deux fois le même prompt, deux actions différentes. Un agent peut tout à fait :

• Louper un champ obligatoire et soumettre quand même
• Choisir la mauvaise option dans une liste déroulante
• S'arrêter en cours de route parce qu'il se croit arrivé
• Halluciner un bouton qui n'existe pas et refuser d'avancer

Et vous ne le découvrez qu'une fois la soumission déjà corrompue de l'autre côté.

Échec silencieux. Un script qui plante lève une exception. Un agent qui échoue renvoie un rapport de succès qui a l'air plausible. Vous découvrez le problème plus tard, quand quelqu'un vous demande pourquoi la moitié des enregistrements sont vides.

Débogabilité. Vous demandez « pourquoi l'agent a fait ça ? » Dans le meilleur des cas, vous avez une trace de chaîne de pensée. Dans le pire, un haussement d'épaules. On ne pose pas de breakpoint sur une distribution de probabilités.

Détection de bots. Les agents tapent à des vitesses surhumaines, bougent la souris n'importe comment, et consultent la même page selon le même schéma à chaque exécution. Les fournisseurs de CAPTCHA sont de plus en plus doués pour repérer ça. Bonne chance quand la facture mensuelle arrive.

Sécurité. La plupart des architectures d'agents font transiter vos identifiants par un service cloud qui pilote ensuite un navigateur pour se connecter à votre place. Ça fait deux intermédiaires de confiance de plus pour chaque mot de passe.

Zéro cache par défaut. Chaque exécution est un nouvel appel LLM, même pour un site que vous avez déjà automatisé mille fois. Rien n'est retenu d'une fois sur l'autre, sauf à rajouter soi-même la logique qui va bien.

Au final : vous payez cher pour faire tourner un processus lent, imprévisible, non auditable et de sécurité douteuse, qui rate souvent sa cible. Pour remplir un formulaire.

L'alternative ennuyeuse

Voilà ce que Pollen fait à la place.

L'extension, c'est un panneau latéral Chrome Manifest V3 plus un content script. Sur votre site source, vous cliquez sur Capturer. Un parcours déterministe du DOM récupère chaque input, son libellé (résolu via <label for>, aria-label, <label> englobant, placeholder, et quelques heuristiques en plus — toutes dans du code que vous pouvez lire), son type, ses options s'il y en a, et sa valeur courante.

Ensuite, vous passez sur le site cible. Vous cliquez sur Analyser. L'extension lit le formulaire cible de la même manière.

On a donc deux listes structurées : les champs source avec leurs valeurs, les champs cibles qui attendent d'être remplis. C'est le moment où l'IA gagne son salaire — on envoie ces deux listes (pas de captures d'écran, pas de HTML brut, juste les schémas structurés) à Claude avec un seul prompt de classification :

Voici N champs source. Voici M champs cibles. Retournez un tableau JSON de paires {sourceFieldIndex, targetSelector, confidence}.

Claude est excellent pour ça. Faire correspondre sémantiquement « E-mail » et « adresse email de contact », c'est exactement ce que les LLM savent faire. C'est une tâche en one-shot. ~500 tokens en entrée, ~200 en sortie. Coût : environ 0,005 $. Temps : environ 2 secondes.

On met le résultat en cache. La prochaine fois que vous partez de la même source vers la même cible, aucun appel IA.

Puis on remplit. Cette partie est 100 % déterministe :

const el = document.querySelector(mapping.targetSelector);
el.value = value;
el.dispatchEvent(new Event("input", { bubbles: true }));
el.dispatchEvent(new Event("change", { bubbles: true }));
el.dispatchEvent(new Event("blur", { bubbles: true }));

C'est tout. Pas de LLM, pas de raisonnement, pas d'incertitude. Si le sélecteur correspond, le champ se remplit. Sinon, on le log. Remplir 50 champs prend 50 à 200 millisecondes.

Là où les heuristiques battent vraiment l'IA

L'idée reçue, c'est que « l'IA, c'est malin ; les heuristiques, c'est bête ». Pour les problèmes qu'on résout, c'est l'inverse. Quelques exemples :

Détecter les formulaires multi-entités. Certains formulaires contiennent les données de N utilisateurs en une seule soumission : users[0].name, users[0].email, users[1].name, users[1].email. Un agent devrait inférer cette structure à chaque fois — et se tromperait forcément sur les cas tordus. Le détecteur de Pollen, c'est trois regex. Juste, à chaque coup, en microsecondes.

Lire les pages de listes. Un tableau de 500 lignes ou une grille de 50 cartes ? Un agent tenterait de scroller et de s'y retrouver à la lecture. Pollen parcourt <table> et <tbody>, ou repère des parents avec trois enfants ou plus de même structure, et extrait tout en une passe.

Interpréter des cases à cocher. Quand une case cible reçoit "yes", "true", "on", "1", "checked", qu'est-ce que ça veut dire ? Un agent tombera juste la plupart du temps, faux de temps en temps. Pollen a une fonction de 10 lignes avec une liste de valeurs équivalentes à faux codée en dur. Couverte par 25 tests unitaires.

Déclencher les formulaires React. React suit l'état des inputs en interne. Affecter .value ne suffit pas — il faut dispatcher les événements input/change synthétiques comme il faut. Tous les agents IA finissent par se prendre les pieds dedans. Pollen le fait de la même façon à chaque fois.

Des sélecteurs fiables. #username, c'est un ID stable. div > div > form > div:nth-child(3) > input:nth-child(2), non. Un agent n'a aucune idée du chemin qu'il pioche. Pollen prend l'ID en priorité, se rabat sur un attribut name, et ne passe à un chemin structurel qu'en dernier recours — un choix fait une seule fois, mis en cache pour toujours.

Rien d'exotique dans tout ça. C'est le pain quotidien de l'automatisation de formulaires. Et à chaque fois, une implémentation déterministe bat un appel de modèle sur tous les axes : exactitude, rapidité, coût, débogabilité.

Là où l'IA est vraiment meilleure que les heuristiques

Le seul terrain sur lequel on ne peut pas battre l'IA, c'est l'appariement sémantique entre des sites qu'on n'a jamais vus. Exemple :

• Libellé source : Numéro de téléphone*
• Libellé cible : Contact phone number

Une règle codée en dur devrait anticiper toutes les langues, toutes les formulations, tous les synonymes. Claude sait que c'est la même chose. C'est précisément pour ça qu'on l'utilise. Une fois. Par paire source-cible.

Et si un utilisateur avancé veut ajuster une correspondance — genre « en fait, pointe notre champ email vers work_email de la cible, pas personal_email » — c'est une liste déroulante dans l'UI, pas un nouveau prompt.

Les chiffres

Pour un remplissage typique de ~10 champs :

Au bout de dix passages sur le même flow, Pollen a fait un appel IA. Un agent en a fait dix — et il en fera dix de plus demain.

Le chiffre de fiabilité

Pas question de prétendre « 100 % fiable sur tous les sites d'internet » — c'est un argument marketing, et internet est un environnement hostile (iframes, shadow DOM, heuristiques anti-automatisation, widgets React custom, restrictions CSP). En revanche, ce qu'on affirme, c'est ceci :

Une fois la correspondance établie, l'étape de remplissage est déterministe. Les mêmes entrées produisent les mêmes mutations du DOM, à chaque fois, en quelques millisecondes.

C'est une garantie bien plus forte qu'un agent ne pourra jamais offrir, parce que l'étape de remplissage d'un agent est elle-même une séquence de tokens échantillonnée. Toute la variance de Pollen se concentre dans l'étape de correspondance — où vous pouvez la voir (scores de confiance), la modifier (un clic pour refaire), et la figer (c'est en cache).

Vous n'avez pas à faire confiance au modèle à l'exécution. Vous avez juste à lui faire confiance pendant trente secondes, le temps de la config.

Quand a-t-on encore vraiment besoin d'un agent complet ?

Honnêtement :

• Tâches avec raisonnement multi-étapes. Si le workflow c'est « trouve la commande avec la date d'expédition la plus récente, regarde si le transporteur propose la livraison en deux jours, puis demande un remboursement via le flow de ce vendeur » — là, c'est un boulot d'agent. Aucune heuristique ne peut exprimer « vérifier, puis bifurquer, puis composer ».
• Une UI totalement inédite à découvrir. Un site avec une interaction vraiment unique qui n'a jamais été scriptée, où vous voulez que la machine se débrouille seule.
• Recherche et synthèse. Crawl, résumés, comparaisons — le terrain de prédilection des agents.

Mais si vous remplissez des formulaires, soumettez des données, scrapez des listes pour les renvoyer dans un flow cible, ou refaites le même transfert entre deux sites en boucle — chacun de ces problèmes est borné, structuré et récurrent. Et la structure, c'est ce que les heuristiques avalent au petit-déjeuner.

Ce qu'il faut retenir

Le débat n'est pas « IA ou pas d'IA ». Il est « combien d'IA, et à quel endroit ? »

Les agents navigateur autonomes disent : de l'IA partout, tout le temps. Payez en temps, en argent et en confiance.

Pollen dit : des heuristiques pour le travail mécanique, une touche d'IA pour la seule étape de classification qui en a vraiment besoin, et du cache pour ne jamais payer deux fois. Assez rapide pour ne pas se voir. Assez bon marché pour être gratuit après le premier passage. Assez déterministe pour tourner sans surveillance.

Le cycle de la hype finira par basculer dans l'autre sens. Quand ça arrivera, l'automatisation ennuyeuse sera toujours là — à finir tranquillement en 200 millisecondes pendant que l'agent de l'onglet d'à côté est encore en train de lire la page.