Série d'accélérateurs TrueFoundry : créer une automatisation Web résiliente lorsque les API n'existent pas

‍

L'écart entre les API

C'est un scénario familier pour les équipes opérationnelles à 10 heures du matin : un flux de travail critique doit être automatisé (vérification de l'inventaire des fournisseurs, analyse des prix compétitifs ou obtention de réservations) mais la plateforme cible n'offre aucun accès programmatique.

À l'ère de la connectivité, de nombreuses plateformes à forte valeur ajoutée bloquent leurs données derrière des « douves numériques ». Ils ne disposent pas d'API publiques, ce qui oblige les développeurs à s'appuyer sur la solution de repli qu'est le web scraping. Cependant, le grattage traditionnel est notoirement fragile. Il repose sur des « sélecteurs fragiles », c'est-à-dire des chemins CSS codés en dur ou des XPaths (par exemple, div.btn-primary) qui s'interrompent dès qu'un développeur frontend change le nom d'une classe en btn-submit.

Pour y remédier, nous avons créé le Accélérateur automatique des réservations de restaurants. Il s'agit d'une implémentation de référence pour une nouvelle catégorie d'automatisation : les agents résilients qui ne se contentent pas de « scraper » le Web, mais qui le font fonctionner.

Le changement : des sélecteurs à l'intention sémantique

L'innovation fondamentale de cet accélérateur est de passer du modèle objet de document (DOM) au profit du Modèle d'objet d'accessibilité (AOM).

Dans un script traditionnel, si un bouton passe d'une barre latérale à un en-tête, l'automatisation échoue. Dans ce système agentic, nous fournissons au moteur d'inférence un instantané de l'arbre d'accessibilité. Il s'agit d'une représentation sémantique de la page conçue pour les lecteurs d'écran, supprimant les modifications de style pour révéler l'utilité fondamentale de l'interface.

Cela permet au système de raisonner en fonction de l'intention plutôt que des coordonnées : « Je vois un widget de calendrier ; je vais cliquer sur la date « 15 » car elle correspond à la demande de l'utilisateur. » Si le site fait l'objet d'une refonte mais que le rôle sémantique du bouton reste « Confirmer la réservation », l'agent s'auto-guérit et le flux de travail fonctionne correctement.

Architecture : le modèle contrôleur-travailleur

Nous avons structuré l'application à l'aide d'un outil spécialisé Contrôleur/travailleur motif. Plutôt qu'un script monolithique, nous avons des agents distincts utilisant Dramaturge pour l'exécution et LLM pour la prise de décisions.

Figure 1 : Architecture de haut niveau

Comme le montre le schéma d'architecture, contrôleur de flux de travail gère l'état en déléguant des tâches à deux composants spécialisés :

1. L'agent de recherche (Discovery) : Cet agent gère la phase non linéaire de « shopping ».
   
   • Construction d'URL dynamique : Au lieu de cliquer sur cinq pages de destination, il construit des paramètres de requête (par exemple, ? cuisine=italian&party_size=4) pour accéder directement aux résultats.
   • Extraction contextuelle : Il identifie les « cartes » dans l'interface utilisateur pour extraire les évaluations, les prix et les créneaux horaires sans avoir besoin de balises HTML spécifiques.
   • Navigation adaptative : Il traite les fenêtres contextuelles et les bannières de cookies comme des « obstacles » à éliminer plutôt que comme des erreurs qui bloquent le script.
2. L'agent de réservation (transaction) : Une fois qu'une cible est sélectionnée, cet agent gère l'interaction dynamique de haute précision.
   
   • Cartographie sémantique des formulaires : Il associe les données utilisateur aux champs de saisie en fonction d'étiquettes (prénom) plutôt que d'identifiants arbitraires (input #user_fname).
   • Raisonnement temporel : Il permet de sélectionner l'heure et de gérer les états « épuisés », avec des fonctionnalités logiques telles que la sélection d'un créneau à 19 h 15 si le créneau de 19 h 00 demandé n'est pas disponible.

Infrastructure : TrueFoundry et le protocole MCP (Model Context Protocol)

L'utilisation de ces agents en production nécessite un plan de contrôle robuste. Nous utilisons Plateforme TrueFoundry pour gérer l'infrastructure et Protocole de contexte modèle (MCP) pour standardiser l'intégration des navigateurs.

Figure 2 : Comment TrueFoundry prend en charge le cycle de vie des applications

• Passerelle TrueFoundry AI : Cela fournit la gestion et l'observabilité unifiées nécessaires. Nous pouvons surveiller de manière centralisée toutes les « pensées » de l'agent, en enregistrant les instantanés AOM et les arbres de décision. Surtout, il impose la limitation du débit, garantissant que nos agents agissent en bons citoyens et ne submergent pas les serveurs cibles.
• MCP et isolation : MCP résume les fonctionnalités du navigateur dans des outils standardisés. La plateforme garantit que chaque session utilisateur s'exécute dans un conteneur isolé. Cela signifie que les cookies de session et le stockage local de l'utilisateur A sont physiquement séparés de ceux de l'utilisateur B, ce qui élimine le risque de contamination croisée des données.

Expérience utilisateur : autonomie supervisée

Pour les flux de travail transactionnels, nous mettons en œuvre un « Vérifier-puis exécuter » motif. L'agent effectue le gros du travail de la découverte mais nécessite une confirmation humaine avant l'exécution finale.

Étape 1 : Intention et découverte

Le système accepte les entrées en langage naturel et les normalise en JSON structuré (Location, Heure, Taille du groupe) pour l'agent de recherche.

Étape 2 : La porte de confirmation

Lorsqu'il trouve un créneau, l'agent de réservation fait une pause. Il présente les détails à l'utilisateur et passe en état d'attente, ne procédant qu'après avoir reçu un signal clair.

L'ingénierie pour les cas extrêmes : le problème du WAF

Le test le plus critique d'un agent Web est sa capacité à gérer des scénarios « Human-in-the-Loop » (HITL). Les sites modernes utilisent souvent des pare-feux d'applications Web (WAF) qui déclenchent des CAPTCHA ou des codes de vérification par e-mail lorsqu'ils détectent une automatisation.

Un script standard échoue ici. Notre système utilise un Machine à états de pause et de reprise.

Figure 3 : Logique d'état de gestion des exceptions

Comme indiqué dans le schéma ci-dessus (étapes 7 à 11), lorsque l'agent détecte une invite de défi :

1. Il arrête l'exécution et en informe l'utilisateur via l'interface de discussion.
2. La session du navigateur reste active (maintenue dans le TTL du conteneur).
3. Une fois que l'utilisateur a fourni le code, l'agent reprend la session sans problème pour terminer la réservation.

Conclusion : Fonctionnement sur le Web

Nous sommes en train de passer du « Web Scraping » au « Web Operating ». En utilisant Playwright pour les « mains » et l'inférence sémantique pour les « yeux », nous pouvons traiter le Web orienté vers l'humain comme une interface programmatique.

Cet accélérateur démontre qu'avec une architecture adaptée : interprétation sémantique, orchestration dynamique et infrastructure sécurisée telle que True Foundry—nous pouvons créer des automatisations résilientes qui comblent les lacunes en matière d'API.

Découvrez les accélérateurs TrueFoundry