Fin de trimestre, et vous ouvrez le même panneau d’administration interne que vous ouvrez depuis cinq ans. Aucune documentation d’API, la connexion passe par un captcha, et le rapport dont vous avez besoin se trouve trois écrans plus loin, derrière une liste déroulante. Vous voulez que l’agent s’en charge, et il cale dès la première étape — il n’y a rien à POST. Un écran est la seule interface que ce système ait jamais eue, et c’est depuis toujours l’angle mort de l’agent.

Sai de Simular comble exactement ce vide. C’est un agent computer-use qui tourne sur un ordinateur cloud : vous lui confiez une tâche en mots, il ouvre des pages, clique sur des boutons et remplit des formulaires comme le ferait une personne, puis rend compte en texte. Côté Hermes, il ne reste qu’à brancher cette capacité — et ce branchement vit désormais dans le catalogue officiel de plugins.

Le monde sans API est plus vaste qu’on ne le croit

Nous avons le réflexe de réduire l’automatisation à « appeler l’endpoint ». Le travail réel dit autre chose : back-offices internes legacy, consoles réservées aux administrateurs, pages SaaS inaccessibles sans session, formulaires de déclaration qui n’existent qu’en HTML. Leur point commun : un humain peut les manipuler, une machine ne peut pas les appeler.

L’ancienne réponse, c’était les scripts Selenium, un jeu de sélecteurs par page, tous cassés à la refonte suivante. Sai prend un autre chemin : il ne maintient pas de sélecteurs, il regarde l’écran et décide de l’étape suivante avec un modèle. Le compromis, c’est la vitesse — chaque clic coûte une décision de modèle — et le gain, c’est que l’automatisation ne vole pas en éclats quand un bouton se déplace.

Cela définit aussi le rôle de Hermes ici. La planification, le contexte, la mémoire et les approbations restent en local. La partie qui clique physiquement appartient à un ordinateur situé ailleurs. Le texte de la tâche, les fichiers que vous lui demandez de téléverser et votre clé d’API partent vers api.simular.ai, et l’ordinateur cloud tourne là-bas.

Trois points à vérifier avant d’installer

Node.js d’abord. Le plugin n’embarque aucun code propre — c’est un paquet Agent Plugins v1 (plugin.json, mcp.json, skills/) — la capacité réelle est le paquet npm @simular-ai/sai-mcp, épinglé à 0.4.0 et lancé via npx. Il vous faut donc Node.js 22.12 ou plus récent, plus npm, sur la machine.

Ensuite, une clé d’API Sai. Créez-la dans API Keys sur platform.simular.ai ; les clés ressemblent à sapi_.... L’offre gratuite inclut un ordinateur cloud et une allocation quotidienne, de quoi vérifier que le flux fonctionne.

Troisièmement, la frontière des données. À trancher avant l’installation, pas après : le contenu des tâches, tout fichier que l’agent téléverse et la clé d’API quittent votre machine pour l’API de Simular, et les tâches consomment le crédit de votre compte Sai. Ce n’est pas un outil local ; c’est un appel de service explicite.

Deux commandes pour installer

L’entrée du catalogue officiel est simular-sai :

hermes plugins install simular-sai --no-enable
hermes plugins enable simular-sai

La première commande récupère le commit épinglé (365b247, version de plugin 0.1.2) et l’installe désactivé, ce qui vous laisse définir la clé avant toute exécution. La seconde l’active.

Mettez la clé dans Desktop, sous Settings > Plugins, ou dans le .env du profil actif :

SAI_API_KEY=sapi_your_key_here

Redémarrez ensuite la gateway pour que le nouveau processus voie la variable d’environnement. Pour vérifier ce que vous avez réellement installé :

hermes plugins info simular-sai

La sortie indique la version, le commit épinglé, la version de Hermes requise (>=0.21.6) et la déclaration complète sur les données. Pour comprendre le fonctionnement du catalogue lui-même, voyez le guide du catalogue de plugins.

À quoi ressemble une tâche de bout en bout

Une fois activé, Hermes dispose d’un nouveau serveur MCP (sai) et d’une skill (simular-sai:sai). La skill décide quand une tâche doit être déléguée ; le serveur fait le travail : démarrer une tâche, attendre, répondre aux demandes d’autorisation, arrêter, téléverser un fichier, lister les ordinateurs et les modèles, et passer l’écran à un humain.

Une phrase suffit à la déclencher :

Use Sai to open Notepad on my cloud computer, type Hello from Sai, and tell me the window title.

Derrière cette phrase :

1. Démarrer. Hermes transmet l’objectif et son contexte à Sai, qui commence à opérer sur l’ordinateur cloud.
2. Attendre. Les tâches ne sont pas instantanées — vous interrogez. N’attendez pas la latence d’une API.
3. Répondre aux autorisations. Quand Sai veut exécuter une commande ou écrire un fichier sur son ordinateur, il demande d’abord, et Hermes répond en votre nom. Une seule tâche a donc deux couches d’approbation : celles des outils de Hermes, plus celles internes à Sai.
4. Récupérer du texte. Le résultat revient en texte, pas sous forme de série de captures d’écran.
5. Passage de main facultatif. Si une étape exige vraiment une personne, sai_live_link renvoie un lien qui permet à son détenteur de piloter cet ordinateur cloud jusqu’à expiration.

Il y a un détail agréable pendant l’exécution : une vue en direct est servie sur 127.0.0.1 (exposée en watch_url), ce qui vous permet de regarder l’ordinateur cloud travailler. Votre clé d’API n’atteint jamais ce navigateur.

Les limites qui font mal plus tard

Ne l’utilisez pas comme navigateur. Si vous scrapez une page publique ou remplissez un formulaire dont vous pouvez appeler l’endpoint, les outils CDP du navigateur sont nettement plus rapides et moins chers. Sai ne gagne sa place que là où « pas d’API » et « besoin d’une manipulation à la manière humaine » se recouvrent.

Les téléversements sont plafonnés. sai_upload envoie un fichier local vers l’ordinateur cloud, jusqu’à 25 MB par fichier. Ce n’est pas un outil de transfert de données.

Un lien live est une vraie clé. Quiconque détient l’URL sai_live_link peut piloter votre ordinateur cloud jusqu’à expires_at. La skill demande à l’agent de ne la donner qu’à vous, mais cette règle est appliquée par un modèle, pas par une serrure — collée dans une conversation de groupe, elle ne revient pas.

Pas de barrière trust: untrusted, volontairement. Les outils de Sai ne portent aucun readOnlyHint, donc une barrière de confiance déclencherait une demande à chaque interrogation sai_task_wait et la tâche ne finirait jamais. Le substitut, c’est l’étape needs_approval propre à Sai, qui demande toujours avant les commandes et les écritures de fichiers.

Ce n’est pas bon marché, et ça ne doit pas tourner en continu. Chaque clic est une inférence de modèle. C’est adapté à « trois fois par jour, dix minutes chaque fois » ; ce n’est pas adapté à « toutes les minutes ». Pour les tâches routinières économes en tokens, restez sur les outils natifs de Hermes.

Quand cela vaut le coup

Ma règle : si un flux de travail est quelque chose que vous faites à la main chaque mois, qui exige une connexion, qui demande de cliquer à travers une pile de pages et qui n’a pas d’API — confiez-le une fois à Sai et voyez. Tout ce qu’un appel curl ou un outil intégré peut faire ne mérite pas ce détour.

L’installation, c’est deux commandes ; la vraie décision porte sur les tâches que vous acceptez d’envoyer, et sur celles qui transportent des éléments qui ne devraient pas résider sur le serveur de quelqu’un d’autre. Réglez ces deux questions et la configuration prend dix minutes. Si ce sont les frontières de permissions qui vous inquiètent, le guide sur l’isolation des plugins et la frontière hôte est la lecture complémentaire.