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)
| Gemini Computer Use | Claude computer use | OpenAI computer use | |
|---|---|---|---|
| observation | captures d'écran | captures d'écran (outil zoom en plus) | captures d'écran |
| action | click, type... avec coordonnées normalisées 0-999 et un champ intent | 17 outils membres du toolset computer_toolset_20260801 (left_click avec coordonnées, type, screenshot, zoom...) | soit actions souris/clavier structurées, soit exécution de code (PyAutoGUI ou Playwright), recommandée par le fournisseur pour son modèle actuel |
| environnements | navigateur, mobile, bureau | bureau | navigateur, bureau |
| sécurité côté fournisseur | safety_decision (autorisé, require_confirmation, bloqué) ; détection d'injection dans les captures en option, désactivée par défaut | classifieurs qui analysent les résultats d'outils, captures comprises, pour signaler les injections | consignes de confirmation et de consentement ; limites d'étapes, de durée et de coût recommandées ; vérifier l'état réel plutôt que la réponse finale |
| modèles | gemini-3.8-flash recommandé, gemini-4-argon, gemini-3.5-flash-lite | voir la table de compatibilité du fournisseur | voir la documentation du fournisseur |
Trois observations utiles pour la décision :
- Les trois fournisseurs demandent explicitement de gérer la confirmation humaine côté client. Le
require_confirmationde Gemini est un signal, pas une barrière : c'est votre code qui doit arrêter l'exécution. - 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.
- 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
| Critère | Harness par arbre | Computer use |
|---|---|---|
| application bien balisée (formulaires, tableaux, libellés) | cibles nommées, actions classables : adapté | fonctionne, actions moins lisibles |
| application canvas, PDF affiché, logiciel de bureau, captcha visuel | arbre vide ou inutile | adapté |
| contrôle des effets par règle | sur le rôle et le nom, avant exécution | sur des coordonnées, après reconstruction |
| jetons par observation (mesuré leçon 6) | 1 149 (arbre simplifié) | ~1 100 par capture, plus le défilement |
| contenu hors écran | présent dans l'arbre | absent sans défilement (3 valeurs sur 9 manquées dans notre mesure) |
| effort de développement | outils à écrire et à maintenir | boucle d'exécution d'actions générique |
| filtre réseau, liste blanche, budget, traces | à votre charge | à votre charge aussi |
Vous devez automatiser la saisie de bons de livraison dans un logiciel de bureau Windows sans API, dont les écrans sont dessinés sans contrôles accessibles. Quelle approche retenez-vous ?
Sans contrôles accessibles, l'arbre n'apporte rien : la capture est la seule observation disponible. Les garde-fous se déplacent alors vers l'environnement : machine isolée, réseau restreint, confirmation des validations. Le poste de l'opérateur expose ses autres sessions et fichiers à l'agent. Dire qu'aucune automatisation n'est possible ignore précisément le cas d'usage du computer use.
Le fournisseur renvoie safety_decision = regular (action autorisée) pour un clic sur « Exporter en CSV ». Votre politique interne exige une confirmation pour tout export. Que fait votre harness ?
La décision du fournisseur est une entrée parmi d'autres, calibrée sur ses propres critères, pas sur votre politique métier. Votre harness reste responsable des règles qui vous engagent. Redemander au modèle n'ajoute aucune garantie, et bloquer tous les clics rend l'agent inutile.
Passer en production : ce qui manque à la démo
| Sujet | Démo | Production |
|---|---|---|
| identité | un compte operateur partagé | un compte de service dédié à l'agent, droits minimaux, sans droit d'export si la tâche n'en a pas besoin |
| confirmation | terminal ou opérateur scripté | interface de validation avec l'identité de qui confirme, journal d'audit en écriture seule |
| isolement | Chromium headless local | navigateur dans un conteneur sans accès au reste du réseau, profil effacé après chaque tâche |
| liste blanche | un hôte | hôtes et chemins, redirections vérifiées (leçon 4), idéalement proxy filtrant |
| secrets | .env | gestionnaire de secrets, rotation, masquage vérifié dans les traces |
| mesure | 5 tâches | jeu de tâches écrit par les opérateurs, rejoué à chaque mise à jour de l'application cible ou du modèle |
| surveillance | lecture des traces | compteurs : requete_bloquee, confirmation_refusee, budget_epuise, appels à capture_ecran, étapes par tâche |
Ce qui casse en production
| Symptôme | Cause | Parade |
|---|---|---|
| l'agent échoue sans erreur après une mise à jour de l'application | libellé renommé (« Enregistrer » devient « Sauvegarder ») | rejouer make e2e sur la recette à chaque livraison de l'éditeur |
| les opérateurs valident tout | 40 confirmations par heure | actions de lot explicites, et seuils : un export de plus de 50 lignes demande une seconde validation |
| fuite par un canal non prévu | navigateur avec accès au réseau interne | conteneur isolé ; la liste blanche du harness n'empêche pas une extension ou un service worker mal configuré |
| coût qui dérive | captures en repli devenues systématiques | alerte sur la part d'appels capture_ecran |
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.
Voir la solution
Décision : harness par arbre maintenant, API demandée à l'éditeur pour les deux actions à effet.
- Le back-office est correctement balisé : 25 tâches sur 25 réussies avec l'arbre, aucun recours à la capture.
- Les actions à effet (statut, export) passent par une confirmation lisible (« Cliquer « Enregistrer le statut » sur /commandes/CMD-1042 (statut=Expédiée) »). Avec le computer use, il faudrait reconstruire cette lecture à partir de coordonnées.
- Le coût mesuré est d'environ 0,05 .
- Risque résiduel : une injection mieux formulée que celle testée. Il est contenu par le filtre réseau et la confirmation, testés avec un modèle détourné.
- Demander à l'éditeur un chiffrage pour deux points d'API (changement de statut, export filtré) plutôt que l'API complète à 40 jours-homme : ce sont les deux seules actions qui demandent une confirmation, donc celles où l'API apporte le plus de contrôle.
- Revoir la décision si l'éditeur remplace l'interface par une application canvas, ou si la part de refus des opérateurs dépasse 10 %.
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.