terminator : piloter le bureau Windows depuis un agent, sans lui voler la souris

Le problème : les agents savent raisonner, pas cliquer

Un assistant capable de lire un dépôt ou d'appeler une API reste bloqué devant une application de bureau classique. Il n'a ni identifiant d'élément, ni sélecteur CSS, ni point d'entrée réseau à interroger. terminator part de ce constat et se présente dans son README comme un « Computer Use MCP that controls your entire desktop », avec l'objectif explicite de donner à Claude, Cursor ou VS Code la capacité d'agir sur n'importe quelle application Windows. Le public visé est double. D'un côté des développeurs qui veulent automatiser un parcours qui traverse un client lourd, un terminal ou un navigateur authentifié. De l'autre des équipes qui cherchent à remplacer une chaîne RPA traditionnelle, le README évoquant la volonté de supprimer la « legacy RPA complexity ». Les cas d'usage listés restent concrets : créer une instance sur GCP puis s'y connecter en CLI, consulter les logs Vercel pour isoler les erreurs fréquentes, tester une fonctionnalité récente à partir des derniers commits. Aucun de ces exemples ne relève du navigateur pur, ce qui situe le projet au-delà de Playwright plutôt qu'à sa place.

Trois canaux de localisation plutôt qu'un seul

Le README résume l'approche en une phrase : l'outil travaille « across all dimensions - pixels, DOM, and Accessibility tree ». Concrètement, un agent qui doit cliquer sur un bouton dispose de plusieurs sources pour l'identifier. L'arbre d'accessibilité Windows expose les éléments par name, role ou window, ce que la matrice de support range sous Element Locators. Le DOM intervient quand la cible est une page, via une extension Chrome qui, selon le README, « enables browser control ». Les pixels couvrent le reste, notamment la capture d'écran d'un écran ou d'un élément. Cette superposition est le vrai argument technique du projet : là où un outil purement visuel dépend d'une reconnaissance d'image fragile, terminator peut retomber sur un localisateur structurel. Le revers est assumé par la documentation elle-même, qui parle de « AI recovery » : le modèle n'est sollicité que lorsque la voie déterministe échoue. Le README décrit cette répartition comme un pré-entraînement des workflows en code déterministe, l'IA n'intervenant qu'en secours. C'est un choix de conception défendable, mais il déplace le problème : la qualité du résultat dépend alors de la couverture des localisateurs sur l'application ciblée, question que le README n'aborde pas.

Installation : une ligne pour Claude Code, un bloc JSON ailleurs

Le chemin le plus court passe par Claude Code, avec la commande fournie telle quelle dans le README : claude mcp add terminator "npx -y terminator-mcp-agent@latest". Pour Cursor, VS Code, VS Code Insiders et Windsurf, le projet fournit un extrait de configuration à coller dans le fichier MCP du client, avec mcpServers comme clé racine, terminator-mcp-agent comme nom de serveur, npx en commande et deux variables d'environnement : LOG_LEVEL à info et RUST_BACKTRACE à 1. Les trois badges d'installation pointent vers des liens vscode:mcp/install qui automatisent cette étape. Le README renvoie aussi vers terminator-mcp-agent/README.md pour les instructions détaillées, et c'est ce fichier qu'il faut lire avant de déployer, car la configuration présentée ici se limite au strict minimum. Deux bibliothèques complètent l'ensemble : terminator-rs et terminator-workflow-recorder sont publiés sur crates.io, avec un paquet Python installable via pip install terminator et un paquet TypeScript via npm i @mediar-ai/terminator. Attention à la nuance de la matrice : le binding Python est marqué Partial, le TypeScript Yes. Le README ne précise pas ce que recouvre ce Partial.

Ce que Windows uniquement implique vraiment

La ligne la plus importante du README tient en une phrase : « Terminator currently supports Windows only. macOS and Linux are not supported. » La matrice de fonctionnalités ne coche aucune case hors Windows, ni pour les localisateurs, ni pour les actions UI, ni pour la gestion des fenêtres, ni pour l'enregistrement de workflows. Un lien vers app.mediar.ai porte le libellé Use on macOS, mais rien dans le matériel fourni ne décrit une prise en charge macOS côté terminator lui-même. Il faut donc traiter ce point comme une limite dure : si votre cible est Linux, le projet n'est pas un candidat, quelle que soit la qualité du reste. S'ajoute une dépendance non triviale pour le volet navigateur : l'extension Chrome. Elle conditionne la partie DOM, donc l'accès aux sessions authentifiées dont le README fait un argument commercial, l'usage de la session navigateur existante sans nouvelle connexion. Une extension à installer et à maintenir, sur chaque poste, dans un contexte où les politiques d'entreprise bloquent souvent ce type d'ajout. Le README ne dit rien de la gestion de cette extension en flotte.

Les chiffres du README demandent une vérification indépendante

Le README avance que terminator « runs 100x faster than ChatGPT Agents, Claude, Perplexity Comet, BrowserBase, BrowserUse » et atteint un taux de réussite supérieur à 95 %. Ces deux affirmations ne sont accompagnées d'aucun protocole : pas de jeu de tâches décrit, pas de machine de référence, pas de méthode de mesure. Le raisonnement sous-jacent est cohérent (un workflow déterministe s'exécute à la vitesse du CPU, l'appel au modèle n'intervenant qu'en récupération), mais un rapport de performance sans protocole reste une déclaration marketing. Le contraste avec l'alternative est en revanche réel et vérifiable dans l'architecture : un agent qui pilote un écran par captures successives et inférences à chaque étape coûte cher en jetons et en latence, là où un scénario pré-enregistré ne sollicite le modèle qu'en cas d'écart. C'est l'argument à retenir, pas le facteur 100. Le README mentionne aussi un financement de 2,8 M$ et un passage sur un podcast, informations qui n'ont aucune valeur pour juger de la robustesse du logiciel.

Comparer avec Playwright, et avec l'enregistrement de workflows

Le projet se décrit comme « playwright for windows computer use ». La différence d'approche est nette. Playwright s'adresse à des pages web et s'appuie sur un protocole de débogage navigateur, avec des sélecteurs stables, un mode headless et une exécution reproductible en intégration continue. terminator vise des applications Windows natives en plus du navigateur, et doit composer avec des interfaces qui n'exposent pas toujours d'arbre d'accessibilité correct. Là où Playwright échoue de façon déterministe quand un sélecteur disparaît, terminator peut basculer sur une récupération par IA, ce qui échange une erreur franche contre un comportement variable. Le second point de comparaison est interne au projet : terminator-workflow-recorder, publié sur crates.io, sert à enregistrer des workflows humains pour les transformer en automatisation déterministe. Le README mentionne une génération YAML à partir d'événements OS et un SDK NodeJS pour exécuter du JavaScript dans le navigateur. C'est cette chaîne enregistrement puis rejeu qui distingue terminator d'un simple outil de contrôle, et c'est aussi elle qui crée la dette : un scénario enregistré sur une version d'interface devra être réenregistré quand l'application change.

Coût de maintenance et licence MIT

Le rythme de publication est soutenu : les versions listées s'enchaînent entre mars et avril 2026, avec des correctifs fréquents. Un numéro de version en 0.24.x signale un logiciel encore en évolution rapide, ce qui implique de suivre les mises à jour plutôt que de figer une version ancienne. La distribution Windows passe par un installeur hébergé sur cdn.crabnebula.app, et le serveur MCP par npx terminator-mcp-agent@latest : ce @latest signifie que chaque lancement peut tirer une version différente de celle testée, point à surveiller si vous épinglez vos dépendances ailleurs. La licence est MIT, ce qui autorise la modification et la redistribution, y compris dans un produit propriétaire, à condition de conserver l'avis de copyright et le texte de licence. Le README met en avant cette absence de lock-in. Rien dans le matériel fourni ne mentionne de service payant obligatoire : l'hébergement managé et le constructeur de workflows sur mediar.ai sont présentés comme une offre distincte, en version bêta publique. Ce paragraphe ne constitue pas un conseil juridique ; faites relire le fichier LICENSE du dépôt avant toute redistribution.

Conclusion éditoriale

terminator s'adresse aux équipes déjà sur Windows qui veulent donner à Claude, Cursor ou VS Code la main sur des applications natives, et qui acceptent de dépendre d'une extension Chrome pour le volet navigateur. À éviter si votre parc est macOS ou Linux : la matrice de support du README ne coche que la colonne Windows. Avant d'adopter, vérifiez deux points précis : le contenu de terminator-mcp-agent/README.md pour la configuration réelle du serveur MCP, et le comportement de l'outil sur une application cible non standard, car la documentation ne décrit pas ce qui se passe quand aucun des trois canaux (pixels, DOM, arbre d'accessibilité) ne fournit de localisateur exploitable.

Sources officielles

1. License: MIT
2. mediar-ai/terminator on GitHub
3. Project website
4. README
5. Releases