Computer use et passage en production

Le directeur technique de Maison Orée a vu une démonstration de « computer use » : un modèle qui regarde l'écran et clique comme un humain, sans aucun outil à écrire. Sa question est légitime : pourquoi maintenir 300 lignes de harness quand les fournisseurs livrent l'équivalent ? La réponse dépend de l'application cible et de ce qu'on exige des garde-fous.

Le mécanisme des deux familles

flowchart TB
  subgraph CU["Computer use (fournisseur)"]
    C1["Capture d'écran"] --> C2["Modèle spécialisé"]
    C2 --> C3["Action : click(x, y), type, scroll"]
    C3 --> C4["Votre code exécute (Playwright, xdotool...)"]
    C4 --> C1
    C2 -.-> C5["safety_decision du fournisseur"]
  end
  subgraph AX["Harness par arbre (ce projet)"]
    A1["Arbre ARIA simplifié"] --> A2["Modèle généraliste + function calling"]
    A2 --> A3["Action : cliquer(role, nom)"]
    A3 --> A4["Guard : classe, confirme, filtre le réseau"]
    A4 --> A1
  end

Dans les deux cas, c'est votre code qui exécute l'action. Aucun fournisseur ne prend la main sur votre navigateur : il propose une action, vous l'exécutez. Les garde-fous de la leçon 4 restent donc à votre charge dans les deux familles.

Ce que proposent les fournisseurs (documentation consultée le 2026-10-15)

Trois observations utiles pour la décision :

1. Les trois fournisseurs demandent explicitement de gérer la confirmation humaine côté client. Le require_confirmation de Gemini est un signal, pas une barrière : c'est votre code qui doit arrêter l'exécution.
2. Les défenses contre l'injection sont des classifieurs sur l'image ou le texte. Ce sont des défenses probabilistes, utiles en complément, au même titre que l'alerte lexicale de ce projet.
3. L'action rendue est une coordonnée. Votre harness ne peut plus écrire une règle « confirmer tout clic sur Exporter » sans retrouver ce qui se trouve sous (x, y) : on peut le faire (document.elementFromPoint), mais c'est de la reconstruction après coup.

La comparaison sur nos critères

Passer en production : ce qui manque à la démo

Ce qui casse en production

Règle de décision

Choisissez le harness par arbre quand l'application cible est un web correctement balisé et que les effets doivent être contrôlés par des règles lisibles. Choisissez le computer use quand l'interface n'expose pas d'arbre exploitable, et déplacez alors les garde-fous vers l'environnement (isolation, réseau, confirmation). Dans les deux cas, si une API existe ou peut être obtenue à un coût raisonnable, elle bat les deux : un agent qui appelle PATCH /commandes/CMD-1042 est plus fiable, plus rapide et plus facile à auditer qu'un agent qui clique.

Nettoyage

Le projet ne crée aucune ressource cloud et aucun conteneur. Exécuté le 2026-10-15 :

$ make clean
Artefacts supprimés.
$ make down
Rien à arrêter : le back-office s'arrête avec le processus qui l'a lancé.
$ make cloud-down
Aucune ressource Google Cloud créée par ce projet : rien à supprimer.
$ make reset
Artefacts supprimés.
Environnement supprimé (.env conservé).

make clean supprime sorties/ (traces, captures, CSV téléchargés) : ces fichiers contiennent des adresses de clients, fictives ici, réelles en production. Fixez leur durée de conservation avant la mise en service.

Exercice

Rédigez la note de décision d'une page pour le directeur technique : harness par arbre, computer use, ou demande d'API à l'éditeur, pour le back-office de Maison Orée. Appuyez-vous sur les mesures de la leçon 6.

Je sais faire

• Expliquer pourquoi l'exécution, la confirmation et le filtrage restent à ma charge avec un computer use de fournisseur.
• Choisir entre arbre, capture et API selon le balisage de l'application et le besoin de contrôle des effets.
• Lister ce qui sépare la démo d'un déploiement : identité, isolement, audit, mesure continue.
• Nettoyer le projet et vérifier qu'il ne reste rien.