Étude de cas : construire un crawler d'offres d'emploi appuyé par le navigateur pour Beyond Tabs

Beyond Tabs n’essaie pas d’indexer toutes les offres d’emploi d’internet.

Le site est volontairement plus étroit : une sélection organisée de postes liés à des langages de programmation de niche et aux communautés techniques voisines. Cela rend le problème de crawling plus intéressant. Un résultat utile n’est pas seulement « cette entreprise a des offres ». C’est « cette source peut contenir des offres pertinentes pour les personnes qui viennent sur Beyond Tabs ».

Le défi actuel est le pipeline carrières. Des centaines d’entreprises ont des portails d’emploi. Certaines utilisent des systèmes ATS connus. Certaines exposent une page de marque au-dessus d’une plateforme partagée. Certaines ont des sites personnalisés avec quelques liens. Certaines sont des agrégateurs à ignorer. Certaines ne révèlent leur vraie structure qu’après exécution de JavaScript, bannière de consentement, contrôle d’âge ou redirection propre à un pays.

C’est précisément le type de travail pour lequel Guida a été construit.

Le problème n’était pas seulement le scraping

Si toutes les entreprises utilisaient le même ATS, la solution serait simple : détecter la plateforme, appeler son API, normaliser les résultats et continuer.

Le web réel ne fonctionne pas ainsi.

Lors d’une passe de tri, un rapport carrières contenait des centaines de portails répartis entre plusieurs catégories : ATS déjà couverts, flux dédiés à une entreprise, sites inconnus génériques et agrégateurs à ignorer. Le groupe « inconnu générique » était le plus inconfortable. Il contenait aussi bien de petites pages statiques que des plateformes de recrutement mondiales cachées derrière des URL de marque.

Une URL seule ne suffisait pas. Quelques exemples anonymisés du tri :

• Une marque grand public ressemblait à une URL carrières propriétaire, mais après le contrôle d’âge elle affichait un tableau SuccessFactors/jobs2web.
• Une entreprise industrielle affichait un site Oracle HCM sous un domaine carrières de marque.
• Un organisme de recherche montrait une page entreprise soignée, mais les liens d’offres partaient vers Lever.
• Une entreprise d’intelligence de marché embarquait un widget BambooHR.
• Une société de trading d’énergie listait les offres sur sa propre page, mais les détails partaient vers HR-ON.
• Une grande entreprise exposait une recherche carrières personnalisée avec des milliers de résultats et des pages détail propres aux produits.

Ces distinctions comptent parce qu’elles déterminent le type de crawler à écrire. Une plateforme partagée doit devenir une infrastructure réutilisable. Un site propriétaire personnalisé demande un processus propre à l’entreprise. Un agrégateur doit être ignoré. Un problème de données source doit être corrigé avant que quelqu’un écrive du code.

Pourquoi WebView2 a changé le flux

Le raccourci tentant consiste à tout classifier avec des requêtes HTTP et des heuristiques d’URL.

Cela aurait été plus rapide. Cela aurait aussi été assez souvent faux pour faire perdre du temps ensuite.

Guida utilise WebView2 comme surface d’automatisation, donc l’agent et l’utilisateur inspectent la même réalité navigateur. Les pages s’affichent avec un moteur normal. JavaScript s’exécute. Les bannières de cookies apparaissent. Les redirections ont lieu. L’utilisateur peut autoriser les domaines nécessaires. L’agent peut inspecter le DOM rendu, les liens visibles, les scripts et l’URL finale dans l’onglet en direct au lieu de deviner depuis du HTML brut.

Pour cette étude de cas, la boucle de travail est devenue :

1. Partir du rapport d’écarts du crawler.
2. Prendre les prochains portails non classés depuis le stockage de l’espace de travail.
3. Réutiliser quatre onglets de navigateur.
4. Appliquer une disposition en quadrants et des viewports Full HD.
5. Naviguer chaque onglet vers une vraie page carrières.
6. Inspecter contenu rendu, liens, scripts, iframes et indices de plateforme.
7. Stocker un constat structuré indexé par clé de portail.
8. Continuer avec le lot suivant.

Le but n’était pas l’autonomie complète. Le but était l’automatisation supervisée. L’utilisateur pouvait voir quelles pages étaient ouvertes, où la navigation bloquait et si l’agent classait la bonne chose.

Le stockage est devenu la mémoire de travail

La première version des notes de tri vivait dans des fichiers texte. Cela n’a pas duré.

Dès que le travail a couvert des centaines de portails et plusieurs sessions, les notes devaient devenir un état interrogeable. Le stockage de l’espace de travail Guida est devenu la mémoire de travail du processus.

Le rapport du crawler a été importé dans une collection indexée par identifiant stable de portail. Les constats issus du navigateur ont été stockés dans une collection séparée, avec le même identifiant et un schéma cohérent. Il devenait facile de répondre :

• Quels portails n’ont pas encore été triés ?
• Lesquels sont des plateformes partagées ?
• Lesquels demandent des crawlers personnalisés ?
• Quels constats viennent de preuves navigateur en direct ?
• Qu’est-ce que l’agent a vu au moment de décider ?

Cela a changé la nature du travail. Au lieu de demander à l’agent de se souvenir du point d’arrêt, le processus pouvait reprendre depuis les données.

Le registre compte parce que le crawling est un travail opérationnel

Un crawl carrières n’est pas un script ponctuel. C’est un flux de travail.

Les portails mettent en file des URL d’offres. Les processus de récupération visitent les pages. Les processus d’analyse extraient et indexent les annonces. Certains éléments terminent. Certains sont ignorés parce qu’un résultat connu existe déjà. Certains échouent temporairement. Certains partent dans la file des rejets. Certaines prises en charge expirent et demandent récupération.

C’est pourquoi le registre de traçabilité des flux est devenu important. Un pipeline de crawler sans visibilité opérationnelle laisse l’utilisateur deviner. Le registre donne à Guida un endroit pour expliquer ce qui s’est passé : exécutions, éléments, états, étapes, événements, réessais, échecs et résultats liés.

Cette pression a ensuite conduit au travail dédié sur la Workflow Ledger Console. Pour Beyond Tabs, l’utilisateur ne doit pas se demander si le crawler est terminé, bloqué, en train de réessayer ou silencieusement cassé. L’application doit le montrer directement.

Ce que Guida a bien fait

Guida a rendu le travail inspectable.

La disposition en quadrants permettait de regarder quatre vrais sites à la fois. Le panneau MCP History montrait les appels d’outils. Le panneau Store montrait les constats structurés. Les onglets montraient les pages réellement rendues. Cette combinaison est plus utile qu’un flux de logs headless, parce que l’utilisateur peut intervenir lorsque le web se comporte comme le web.

Guida a aussi rendu le travail reprenable. Une fois les constats déplacés dans le stockage de l’espace de travail, les lots pouvaient continuer entre sessions sans dépendre de la mémoire conversationnelle ni de notes éditées à la main.

Surtout, Guida a gardé l’agent ancré. L’agent ne classait pas des pages à l’intuition ou sur des hypothèses périmées. Il regardait des preuves rendues et notait la raison de la classification.

Ce qui reste à améliorer

Ce n’était pas sans friction.

La navigation peut encore signaler un échec même lorsque la page s’est chargée, donc le flux a besoin de contrôles de suivi avec l’URL courante et le DOM. La boucle de tri à quatre onglets mérite aussi un contrôle plus haut niveau : « prépare ce lot, garde ces onglets en quadrants et stabilise la disposition » devrait être une opération de premier ordre plutôt qu’une suite d’appels bas niveau sur onglets et disposition.

Les demandes de consentement et les listes de domaines autorisés avancent au rythme humain, ce qui est correct, mais l’interface doit rendre visibles les autorisations en attente et les pages bloquées. Cette leçon produit apparaît déjà dans Guida : le MCP Approval Center rend visibles les demandes d’autorisation, et les consoles dédiées aux flux et aux files déplacent la récupération opérationnelle hors des petits panneaux latéraux.

Ce sont des problèmes produit, pas des raisons d’abandonner l’approche. Le pari de fond reste valable : un vrai navigateur, un état visible, des données d’espace de travail structurées et un usage des outils IA traçable.

La leçon

Le crawler Beyond Tabs est exactement le genre de problème qui se situe entre navigation manuelle et scraping industriel.

Il a besoin d’automatisation, mais pas d’automatisation aveugle. Il a besoin d’aide IA, mais pas d’un agent invisible qui parcourt le web. Il a besoin de pipelines de données, mais aussi de jugement humain. Il doit passer à l’échelle, mais seulement après des classifications fiables.

Le rôle de Guida est de rendre ce terrain intermédiaire praticable.

Pour Beyond Tabs, cela signifie utiliser un flux appuyé par le navigateur pour décider quels crawlers construire, quelles plateformes partagées prendre en charge, quelles sources ignorer et quels échecs demandent attention. Pour Guida, c’est une vraie étude de cas qui montre pourquoi l’automatisation visible, locale et supervisée du navigateur est différente d’un scraper headless de plus.

L’objectif long terme est simple : les utilisateurs ne doivent pas se sentir dans le noir pendant que l’automatisation tourne. Ils doivent pouvoir voir le navigateur, inspecter les preuves, faire confiance à l’état stocké et comprendre le pipeline.

C’est la direction produit que cette étude de cas aide à valider.