Une LLM locale a collecté des annonces via le DOM, puis s’est arrêtée après la sixième requête

Un parseur classique de site de petites annonces échoue souvent avant même de produire sa première ligne utile : le serveur répond par une erreur 403, limite la fréquence des requêtes ou renvoie une page assemblée par JavaScript. L’auteur de l’expérience a essayé une autre approche : confier à un modèle Qwen local de classe 7B/8B l’interaction avec le site au moyen d’un navigateur classique et extraire les données à partir d’indices sémantiques plutôt que de fragiles classes CSS.

Dans cet exemple simple, la mission consistait à trouver une station de travail mobile rare équipée d’une carte graphique précise, puis à recueillir son nom, son prix, sa ville et un lien vers le vendeur. L’agent ouvrait les résultats dans Edge, piloté par Playwright, examinait le DOM et recherchait des points de repère familiers : un symbole monétaire, un grand texte adjacent et l’identifiant de l’annonce dans le lien. Lorsque les informations sur le vendeur se trouvaient ailleurs dans la page, les enregistrements étaient reliés à l’aide de l’Item ID.

Pourquoi le DOM s’est révélé plus utile que le CSS

Une interface moderne peut changer les noms de ses classes après chaque mise à jour. Un sélecteur qui fonctionnait hier peut renvoyer une liste vide demain. Les indices textuels sont plus stables : le prix contient toujours un symbole monétaire, la fiche mène à une adresse unique et le titre reste proche du prix dans la structure de la page.

L’agent utilisait ces indices comme points de repère. Il commençait par trouver le nœud contenant le prix, remontait ensuite jusqu’au conteneur de la fiche, en extrayait le titre et le lien, puis associait les champs supplémentaires grâce à l’identifiant. Cette méthode ressemble à celle d’un humain : nous ne connaissons pas non plus le nom de la classe CSS d’un bouton, mais nous comprenons sa fonction grâce à son texte et à sa position.

Un autre résultat est encore plus intéressant. Dans une annonce, le titre promettait une carte graphique haut de gamme, tandis que la description mentionnait un modèle inférieur doté de 16 Go de mémoire. L’agent a repéré la divergence et signalé la fiche pour une vérification manuelle. Pour une équipe produit, c’est plus important qu’une brillante démonstration d’autonomie : le modèle ne se contentait pas de recopier des lignes, il vérifiait la cohérence des données au sein de l’annonce.

Là où l’expérience s’est heurtée à la réalité

À la sixième requête, la plateforme a renvoyé une erreur 429 indiquant un trop grand nombre de requêtes. L’agent a cessé d’en envoyer de nouvelles et généré un rapport à partir des données déjà enregistrées. C’est un comportement raisonnable, mais il invalide en même temps l’affirmation tapageuse d’une « victoire » sur le système antifraude. L’utilisation d’un navigateur classique ne rend pas le système invulnérable : la plateforme continue d’observer la fréquence des actions et peut restreindre l’accès.

Le taux de correspondance de 100 % annoncé par l’auteur n’a pas non plus été confirmé par un test indépendant. La taille de l’échantillon, le nombre de fiches manquées et le taux d’erreur sur d’autres pages restent inconnus. L’expérience comprenait un débogage interactif et une surveillance manuelle ; il est donc prématuré de qualifier le système de totalement autonome.

Il existe également une limite juridique. La capacité technique à lire une page ne vaut pas autorisation de collecter massivement ses données. Avant tout lancement, il faut vérifier les conditions de la plateforme, le fichier robots.txt, la charge admissible et les règles relatives au traitement des données personnelles. Les mécanismes de protection ne doivent pas être considérés comme des obstacles gênants à contourner discrètement.

Ce que les développeurs peuvent en retenir

L’intérêt de ce travail ne réside pas dans une recette permettant de contourner les blocages, mais dans son approche architecturale. Pour les scénarios autorisés, un agent de navigation peut combiner trois niveaux : la vérification visuelle d’une capture d’écran, l’analyse du DOM à l’aide de marqueurs sémantiques et un tampon local permettant de terminer proprement le travail après une erreur.

En production, cette approche doit être complétée par de strictes limites de fréquence, des nouvelles tentatives avec un délai croissant, un journal des actions, un contrôle de l’exhaustivité de l’échantillon et une validation humaine des résultats litigieux. Il convient de commencer sur son propre site ou dans un environnement de test où l’automatisation est explicitement autorisée.

La conclusion pratique est simple : une petite LLM locale est déjà capable de piloter un navigateur et d’extraire des données structurées d’une page dynamique. Mais la qualité d’un agent ne se mesure pas à sa capacité à franchir toutes les protections à n’importe quel prix. Elle tient à son aptitude à respecter les restrictions, à repérer les contradictions et à s’arrêter en toute sécurité lorsque le site dit « assez ».