Cas d'usage : tests E2E, scraping, RPA

Trois domaines, un même outil

Dans cette dernière leçon, vous allez explorer trois cas d’usage concrets de Computer Use en production. Chacun illustre une facette différente de la technologie et les bonnes pratiques associées. Les tests E2E exploitent la robustesse visuelle de l’agent, le scraping sa capacité à traverser des interfaces qui résistent aux analyseurs HTML, la RPA son aptitude à piloter des logiciels qui n’ont jamais prévu d’être pilotés. Tout ce que vous avez construit dans les leçons précédentes — orchestration, gestion d’erreurs, sandboxing, monitoring — se retrouve ici assemblé.

Cas 1 : Tests End-to-End (E2E)

Le problème des tests classiques

Les tests E2E traditionnels (Selenium, Cypress, Playwright) reposent sur des sélecteurs CSS ou XPath. Ils cassent dès que l’interface change — un bouton renommé, une classe CSS modifiée, un composant restructuré. Toute équipe qui a vécu une refonte de design connaît la suite : la suite de tests vire au rouge sur deux cents scénarios alors que l’application fonctionne parfaitement, et quelqu’un passe deux jours à réécrire des sélecteurs.

Avec Computer Use, les tests deviennent visuels : l’agent voit l’interface comme un utilisateur et agit en conséquence. Vous ne lui décrivez plus où cliquer, mais ce que vous cherchez à valider.

Implémentation

La fonction ci-dessous encapsule ce changement de perspective. Le prompt de test comporte trois parties — les étapes, le résultat attendu, les instructions d’exécution — et impose un verdict binaire : l’agent répond PASS ou FAIL, et en cas d’échec, il doit décrire précisément l’écart constaté. C’est cette dernière consigne qui rend le rapport exploitable, car un test rouge sans explication vous oblige à rejouer le scénario à la main.

import anthropic
import base64
from playwright.sync_api import sync_playwright

def e2e_test(test_name: str, steps: str, expected_outcome: str):
    """Exécute un test E2E via Computer Use."""
    client = anthropic.Anthropic()

    pw = sync_playwright().start()
    browser = pw.chromium.launch(headless=True)
    page = browser.new_page(viewport={"width": 1280, "height": 720})

    task = f"""
    Tu exécutes un test E2E nommé "{test_name}".

    ÉTAPES :
    {steps}

    RÉSULTAT ATTENDU :
    {expected_outcome}

    INSTRUCTIONS :
    - Exécute chaque étape dans l'ordre
    - Après la dernière étape, vérifie le résultat attendu
    - Retourne PASS si le résultat correspond, FAIL sinon
    - En cas de FAIL, décris précisément ce qui ne correspond pas
    """

    result = run_agent(task, page=page)

    browser.close()
    pw.stop()
    return result


# Exemple : tester le formulaire de contact
result = e2e_test(
    test_name="Formulaire de contact",
    steps="""
    1. Va sur https://monsite.com/contact
    2. Remplis le champ 'Nom' avec 'Test Automatisé'
    3. Remplis le champ 'Email' avec '[email protected]'
    4. Remplis le champ 'Message' avec 'Test E2E automatisé'
    5. Clique sur 'Envoyer'
    """,
    expected_outcome="""
    Un message de confirmation apparaît :
    'Votre message a été envoyé' ou similaire.
    Pas de message d'erreur visible.
    """
)
print(f"Résultat : {result}")

Remarquez la formulation du résultat attendu : « ‘Votre message a été envoyé’ ou similaire ». Un test Playwright classique exigerait la chaîne exacte et échouerait si le libellé passait au passé composé. L’agent, lui, juge sur le sens.

Ce que vous y gagnez, ce que vous y perdez

Les avantages de cette approche découlent tous du même principe : plus de sélecteurs CSS fragiles à maintenir, et donc une résilience aux changements de design qui vous rend les refontes indolores. L’agent vérifie par ailleurs l’expérience utilisateur réelle, et non seulement le DOM : là où un test classique confirme qu’un bouton existe dans l’arbre HTML, l’agent constate qu’il est effectivement visible et cliquable. Cette différence lui permet de détecter les problèmes purement visuels — un chevauchement de blocs, un texte tronqué par un débordement — qu’aucune assertion sur le DOM ne remontera jamais.

Le prix à payer tient en trois points. Un test visuel est plus lent, de cinq à trente secondes contre une à cinq secondes pour du Playwright pur, ce qui interdit d’en mettre un millier dans un pipeline d’intégration continue. Le coût API devient non négligeable dès qu’on parle de suites de tests complètes. Enfin, le résultat n’est pas déterministe : le même test peut donner des résultats différents d’une exécution à l’autre. En pratique, la bonne stratégie consiste à conserver vos tests Playwright existants pour les parcours stables et à réserver Computer Use aux scénarios critiques ou aux écrans qui changent souvent.

Cas 2 : Scraping intelligent

Quand le scraping classique échoue

Le scraping classique (BeautifulSoup, Scrapy) suppose que le contenu se trouve dans le HTML renvoyé par le serveur. Cette hypothèse tombe dans quatre situations devenues courantes : les applications monopages qui chargent tout leur contenu en JavaScript après le premier rendu, celles qui encapsulent leurs composants dans du shadow DOM ou des web components inaccessibles aux analyseurs, les sites qui remanient régulièrement leur structure HTML et cassent vos sélecteurs sans prévenir, et ceux qui implémentent des protections anti-bot déclenchées par un client trop mécanique. Computer Use contourne ces obstacles en agissant comme un vrai utilisateur : un navigateur complet, un rendu réel, et une lecture de l’écran plutôt que du code source.

Pipeline de scraping

Le pipeline ci-dessous parcourt une liste d’URL et applique le même prompt d’extraction à chacune. Deux détails méritent votre attention. D’abord wait_for_load_state("networkidle"), qui laisse le JavaScript finir son travail avant la première capture — sans lui, l’agent photographie un squelette de chargement. Ensuite le traitement de la réponse : on tente de désérialiser le JSON, et en cas d’échec on conserve tout de même une entrée contenant l’URL, la nature de l’erreur et les cinq cents premiers caractères de la sortie brute. Vous gardez ainsi de quoi comprendre ce que l’agent a répondu au lieu de perdre la page silencieusement.

import json
from datetime import datetime

def scraping_pipeline(urls: list[str], extraction_prompt: str):
    """Pipeline de scraping avec Computer Use."""
    all_data = []

    for url in urls:
        pw = sync_playwright().start()
        browser = pw.chromium.launch(headless=True)
        page = browser.new_page(
            viewport={"width": 1280, "height": 720}
        )
        page.goto(url)
        page.wait_for_load_state("networkidle")

        task = f"""
        Tu es sur la page {url}.
        {extraction_prompt}

        Retourne les données au format JSON strict.
        Si la page est vide ou inaccessible, retourne {{"error": "page inaccessible"}}.
        """

        result = run_agent(task, page=page)

        try:
            data = json.loads(result)
            data["_source_url"] = url
            data["_extracted_at"] = datetime.utcnow().isoformat()
            all_data.append(data)
        except json.JSONDecodeError:
            all_data.append({
                "_source_url": url,
                "_error": "JSON invalide",
                "_raw": result[:500],
            })

        browser.close()
        pw.stop()

    return all_data


# Exemple : scraper des fiches produits
data = scraping_pipeline(
    urls=[
        "https://shop.example.com/product/1",
        "https://shop.example.com/product/2",
        "https://shop.example.com/product/3",
    ],
    extraction_prompt="""
    Extrais les informations suivantes du produit :
    - nom (string)
    - prix (nombre, en euros)
    - disponible (boolean)
    - description (string, max 200 caractères)
    - note_moyenne (nombre, sur 5)
    """
)

Le prompt d’extraction typé — chaque champ accompagné de son type attendu — n’est pas une coquetterie : il évite qu’un prix revienne tantôt sous la forme 1500, tantôt "1 500,00 €" selon la mise en page de la fiche.

Bonnes pratiques

Un agent capable de traverser les protections anti-bot n’est pas pour autant autorisé à le faire n’importe comment. Respectez les fichiers robots.txt et les conditions d’utilisation des sites que vous visitez, car la faisabilité technique ne dit rien de la légalité. Espacez vos requêtes d’une à deux secondes entre chaque page, et utilisez un user-agent honnête qui identifie votre bot plutôt qu’une chaîne empruntée à un navigateur grand public : un exploitant qui voit passer un robot poli et identifiable le tolère généralement, alors qu’il bannira un trafic déguisé. Ne surchargez jamais le serveur cible, y compris quand la parallélisation vue précédemment vous en donne les moyens. Enfin, stockez toujours les données brutes en plus des données structurées : le jour où vous découvrirez un champ mal extrait, vous pourrez retraiter votre historique sans revisiter mille pages.

Cas 3 : RPA (Robotic Process Automation)

Automatiser les applications sans API

De nombreux logiciels métier (ERP, CRM, outils comptables) n’offrent pas d’API. Computer Use permet de les automatiser via leur interface web ou desktop. C’est ici que le retour sur investissement est le plus net, parce que l’alternative n’est pas un script plus simple : c’est un humain qui saisit des données à la main, plusieurs heures par semaine, avec le taux d’erreur que cela suppose en fin de journée.

Exemple : saisie de factures

La fonction de saisie construit un prompt à partir d’un dictionnaire de facture. L’étape 3 est la plus instructive : on demande à l’agent de vérifier que le montant TTC calculé par le logiciel est correct. Vous ne vous contentez pas de remplir des champs, vous confiez à l’agent le contrôle que l’opérateur humain effectuait d’un coup d’œil, et vous en obtenez la trace dans le résultat retourné.

def saisir_facture(page, facture: dict):
    """Saisit une facture dans le logiciel comptable."""
    task = f"""
    Tu es connecté au logiciel de comptabilité.

    Saisis cette facture :
    - Fournisseur : {facture["fournisseur"]}
    - Numéro de facture : {facture["numero"]}
    - Date : {facture["date"]}
    - Montant HT : {facture["montant_ht"]} EUR
    - TVA : {facture["tva"]}%
    - Description : {facture["description"]}

    Étapes :
    1. Clique sur "Nouvelle facture" ou "Créer"
    2. Remplis tous les champs dans l'ordre
    3. Vérifie que le montant TTC calculé est correct
    4. Clique sur "Enregistrer" ou "Valider"
    5. Confirme que la facture a été enregistrée avec succès
    """

    return run_agent(task, page=page)


# Traitement par lot
factures = [
    {
        "fournisseur": "ACME Corp",
        "numero": "FAC-2026-0042",
        "date": "01/04/2026",
        "montant_ht": 1500.00,
        "tva": 20,
        "description": "Prestations de conseil Q1 2026",
    },
    {
        "fournisseur": "TechParts SAS",
        "numero": "TP-26-1337",
        "date": "02/04/2026",
        "montant_ht": 3200.00,
        "tva": 20,
        "description": "Fourniture de matériel informatique",
    },
]

for facture in factures:
    result = saisir_facture(page, facture)
    print(f"Facture {facture['numero']} : {result}")

Workflow RPA complet

Un workflow RPA typique en production inclut :

1. Planification : Cron job ou déclencheur événementiel
2. Connexion : Authentification automatique (cookies, TOTP)
3. Exécution : Séquence d’actions avec checkpoints
4. Validation : Vérification des résultats
5. Reporting : Envoi d’un rapport de synthèse

L’assemblage ci-dessous réunit les briques des leçons précédentes. La session authentifiée reprend la restauration de cookies, les métriques sont celles de la leçon sur le monitoring, et l’alerte humaine celle de la leçon sur la gestion d’erreurs. Observez surtout la structure des exceptions, imbriquée sur deux niveaux : une facture qui échoue est enregistrée dans les métriques et le traitement continue avec la suivante, tandis qu’une panne au niveau du workflow lui-même — connexion impossible, logiciel indisponible — remonte à l’humain. Un lot de deux cents factures dont trois posent problème ne doit pas s’arrêter à la troisième.

def rpa_daily_workflow():
    """Workflow RPA quotidien."""
    metrics = WorkflowMetrics(workflow_id="daily-invoices")

    try:
        # Connexion
        page = setup_authenticated_session()
        metrics.steps_total = len(factures_du_jour)

        # Traitement
        for facture in factures_du_jour:
            try:
                saisir_facture(page, facture)
                metrics.steps_completed += 1
            except Exception as e:
                metrics.record_error(str(e), facture["numero"])

        # Reporting
        metrics.finalize()
        send_report(metrics.summary())

    except Exception as e:
        alert_human(f"Workflow RPA échoué : {e}")

Choisir le bon cas d’usage

Les trois familles ne se ressemblent ni par leur volume, ni par leur économie. Le tableau suivant vous donne des ordres de grandeur pour arbitrer avant de vous engager, et surtout pour vérifier que le coût unitaire reste inférieur à celui de la solution que vous remplacez.

Une saisie de facture à un dollar reste très rentable si elle remplace dix minutes de travail humain ; le même dollar dépensé pour extraire une page de catalogue accessible en API serait absurde. C’est le critère à garder en tête pour toutes vos décisions d’automatisation visuelle.

Tarifs relevés le 5 août 2026 — les prix évoluent régulièrement : avant tout calcul de budget, vérifiez la grille en vigueur sur la tarification officielle OpenAI.

Points clés à retenir

• Tests E2E : Computer Use rend les tests résilients aux changements d’interface mais plus lents et non déterministes
• Scraping : Idéal pour les sites dynamiques inaccessibles aux scrapers classiques, mais respectez l’éthique et la légalité
• RPA : Permet d’automatiser des logiciels métier sans API, avec un ROI élevé sur les tâches répétitives
• Choisissez Computer Use quand les outils classiques ne fonctionnent pas ou sont trop fragiles
• Combinez toujours monitoring, gestion d’erreurs et sandboxing en production

Testez vos connaissances

L’agent qui voit l’écran : validez la boucle avant les cas d’usage.

1. Sur quelle boucle repose Computer Use ?

Réponse : Capture d’écran (perception) → décision du modèle → action (clic, saisie, défilement) → nouvelle capture : l’agent n’agit jamais à l’aveugle, chaque action est vérifiée par l’observation suivante.

2. Le modèle contrôle-t-il directement la machine ?

Réponse : Non : il émet des demandes d’actions, et votre environnement d’exécution les réalise — le périmètre réel de l’agent est celui que votre infrastructure autorise.

3. Comment gérer l'authentification dans un workflow automatisé ?

Réponse : Par des sessions préparées et des secrets gérés hors du modèle — on ne fait pas saisir des identifiants sensibles à l’agent, on lui fournit un environnement déjà authentifié et cloisonné.

4. Que prévoir pour la gestion d'erreurs ?

Réponse : Des vérifications d’état après chaque étape clé, des reprises (recovery) sur les échecs transitoires, et des points d’arrêt propres — une page qui change ne doit pas dérailler tout le workflow.

5. Quels sont les grands cas d'usage — et leur point commun ?

Réponse : Tests E2E, extraction de données, RPA : trois familles où l’interface est le seul accès ou l’objet même du test — quand une API existe, on préfère l’API.

Perception, action, isolation, recovery : la grille vaut pour tous vos futurs workflows — les cas d’usage ci-dessus l’appliquent trois fois.