Architecture : screenshots, actions, boucle d'interaction

La boucle perception-action

Toute l’architecture de Computer Use tient dans un cycle unique : observer → décider → agir → observer. Tant que ce cycle n’est pas clair dans votre esprit, vos automatisations resteront capricieuses ; une fois qu’il l’est, le reste n’est que plomberie.

La différence avec un script Selenium tient à la position du savoir. Selenium exécute aveuglément une séquence décidée à l’avance : clique ici, puis là, puis tape ceci. Computer Use ne choisit l’étape suivante qu’après avoir regardé le résultat de la précédente. Une popup qui surgit, une page qui met trois secondes de plus à s’afficher, un libellé de bouton modifié pendant la nuit : dans les trois cas, le modèle voit la situation réelle et ajuste, là où le script poursuit sa récitation dans le vide.

Le point de départ : la capture

Chaque itération commence par une image de l’état courant de l’écran. Cette capture provient d’un navigateur headless piloté par Playwright ou Chromium — le cas le plus fréquent sur le web —, d’un bureau virtuel accessible en VNC ou RDP lorsque vous automatisez une application desktop, ou d’un conteneur Docker embarquant un environnement graphique complet quand vous voulez isoler l’agent.

Le screenshot part vers le modèle encodé en base64. La résolution est un vrai paramètre de conception, pas un détail d’implémentation : trop basse, l’IA ne distingue plus les libellés des champs et clique à côté ; trop haute, le coût en tokens grimpe à chaque tour de boucle, et il y a beaucoup de tours.

import base64
from playwright.sync_api import sync_playwright

def capture_screenshot(page) -> str:
    """Capture un screenshot et retourne le base64."""
    screenshot_bytes = page.screenshot()
    return base64.b64encode(screenshot_bytes).decode("utf-8")

L’analyse et la décision

Le modèle reçoit l’image accompagnée du system prompt et de la tâche demandée. Sa décision se construit sur trois sources : ce qu’il voit à l’écran — boutons, champs, menus, messages d’erreur —, ce qu’on lui a demandé d’accomplir, et l’historique des actions déjà tentées avec leurs résultats. C’est ce troisième élément qui l’empêche de recliquer indéfiniment sur un bouton inopérant. Sa réponse n’est pas une phrase mais une action structurée :

# Réponse typique du modèle
{
    "type": "computer_20241022",
    "action": "click",
    "coordinate": [450, 320]
}

Le répertoire d’actions

Le vocabulaire dont dispose le modèle est volontairement réduit, et c’est une force : ces quelques primitives, combinées, couvrent l’essentiel de ce qu’un humain fait avec une souris et un clavier.

Arrêtez-vous sur la dernière ligne : le modèle peut réclamer une nouvelle capture sans rien modifier à l’écran. Il s’en sert typiquement quand il soupçonne qu’une page n’a pas fini de charger et préfère revérifier avant d’agir — un réflexe qui vous évitera bien des clics prématurés.

Le flux complet

Assemblés, ces éléments donnent la boucle suivante. Le screenshot est capturé, envoyé avec la tâche, la réponse est inspectée : si le modèle a terminé, on sort ; sinon on exécute les actions demandées et on repart pour un tour.

import anthropic

client = anthropic.Anthropic()

def computer_use_loop(task: str, page):
    """Boucle principale Computer Use."""
    messages = []
    
    while True:
        # 1. Capturer le screenshot
        screenshot_b64 = capture_screenshot(page)
        
        # 2. Envoyer au modèle avec l'image
        messages.append({
            "role": "user",
            "content": [
                {
                    "type": "image",
                    "source": {
                        "type": "base64",
                        "media_type": "image/png",
                        "data": screenshot_b64,
                    }
                },
                {"type": "text", "text": task}
            ]
        })
        
        # 3. Obtenir la décision du modèle
        response = client.messages.create(
            model="claude-sonnet-5",
            max_tokens=1024,
            messages=messages,
            tools=[{
                "type": "computer_20241022",
                "name": "computer",
                "display_width_px": 1280,
                "display_height_px": 720,
            }]
        )
        
        # 4. Exécuter l'action ou terminer
        if response.stop_reason == "end_turn":
            break
        
        for block in response.content:
            if block.type == "tool_use":
                execute_action(page, block.input)
        
        # La boucle continue avec un nouveau screenshot

Ce que coûte un tour de boucle

Chaque itération additionne trois postes : un envoi d’image d’environ 1500 tokens pour un screenshot en 1280x720, un appel API de 0,5 à 2 secondes de latence, et l’exécution de l’action elle-même, de l’ordre de 100 à 500 ms. Faites le calcul sur un cas réel : remplir un formulaire de cinq champs demande 5 à 10 itérations, soit 10 à 30 secondes au total. Un script Selenium ferait la même chose en deux secondes — mais il faudrait le réécrire à la prochaine refonte du formulaire, ce que l’agent n’exige pas. C’est le prix de la résilience, et il se budgète dès la conception.

Points clés à retenir

• La boucle screenshot → analyse → action est le cœur de Computer Use
• Chaque itération est indépendante : le modèle réévalue la situation à chaque screenshot
• Les actions disponibles sont simples (clic, frappe, scroll, touche) mais combinées, elles couvrent tous les cas
• La latence est de l’ordre de 2 à 5 secondes par action, ce qui est acceptable pour l’automatisation