Jusqu’ici, confier un écran à Claude obligeait chaque équipe à écrire sa propre boucle : recevoir l’ordre de cliquer, le traduire en action sur un navigateur, renvoyer une capture, recommencer. Le 7 octobre, le compte @ClaudeDevs a annoncé que cette plomberie est désormais livrée avec les SDK (kits de développement) Python et TypeScript.
L’API indique ce que Claude veut cliquer ou taper, et le développeur n’a plus à faire correspondre lui-même chaque clic et chaque frappe à une action. Vu d’ici, un simple confort d’intégration. Vu d’Anthropic, une manière de placer son format au centre de l’écosystème.
Une boucle écrite par le SDK, un contrat signé par Anthropic
La documentation de la plateforme Claude décrit le mécanisme sans détour. Le SDK contient une classe pour l’outil navigateur et une autre pour l’outil ordinateur. Le développeur en hérite, puis écrit une méthode par outil membre, comme navigate ou left_click, contre son propre navigateur ou son propre bureau. Le SDK route chaque appel, applique les politiques qu’on lui passe, sollicite une fonction de rappel d’approbation et construit chaque tool_result.
Côté quickstart, la logique est la même : une seule entrée déclarée dans tools, et le modèle appelle chaque action de bureau (screenshot, left_click, type et les autres) comme un outil distinct. Le nom de l’ensemble, computer_toolset_20260801, porte une date : l’interface est versionnée, donc destinée à durer et à évoluer sous le contrôle de son auteur.
Qui écrit le contrat contrôle le point de passage. Tant que chacun bricolait sa boucle, piloter un écran restait une affaire locale. Avec une classe abstraite commune, cela devient un format que le reste de l’écosystème vient adopter.
Browser Use, Browserbase, E2B et Daytona se branchent sur la même prise
Le SDK n’embarque ni navigateur, ni bureau, ni pilote prêt à l’emploi, ni politique d’URL. Anthropic le dit en toutes lettres. Pour combler le vide, @ClaudeDevs oriente vers des pilotes compatibles de Browser Use, Browserbase, E2B et Daytona, chacun avec sa documentation et son exemple, ou vers un pilote écrit maison à partir des exemples des guides de démarrage.
Le partage des rôles est net. L’éditeur garde le modèle et l’interface qui le relie au monde. Les partenaires prennent la partie coûteuse et exposée : faire tourner des navigateurs et des bureaux, les isoler, les jeter. En échange, ils obtiennent ce qui vaut cher pour une jeune société d’infrastructure, une place par défaut dans la documentation du fournisseur de modèle.
Pour le client, l’interchangeabilité est une bonne nouvelle : changer de pilote ne devrait plus demander de réécrire la boucle. Pour les partenaires, c’est une pression. Quand la prise est la même, la différence se joue sur la qualité de l’environnement, pas sur le branchement.
Dix outils, un bureau jetable et une mise en garde écrite noir sur blanc
Le quickstart sur le bureau à distance en VNC (le protocole RFB) est franc sur ses limites. Le pilote d’exemple tient en quelques centaines de lignes, implémente dix des outils de l’ensemble, et n’est pas du code de production. Le texte ajoute que ce qui s’affiche à l’écran oriente la suite des actions du modèle, et qu’un terminal au premier plan exécute tout ce qu’on y tape.
Traduit en pratique : une page piégée, un document ouvert au mauvais moment, et l’agent peut obéir à du texte qu’il vient de lire. Le guide demande donc de lancer l’exemple sur un bureau jetable dans un bac à sable, jamais sur sa propre machine, de garder le serveur sans mot de passe sur localhost et, depuis un conteneur, de ne publier son port que sur l’interface de bouclage de l’hôte (127.0.0.1:5900). Une section de la documentation des SDK, « Running a computer toolset safely », est à lire avant d’aller plus loin.
Anthropic documente le risque, fournit la mécanique, et laisse à l’utilisateur la politique d’URL et l’approbation. La responsabilité est ainsi posée là où le produit s’arrête.
Le bac à sable pèse plus lourd que le modèle
Si la boucle est standard et les pilotes substituables, le modèle ne distingue plus un déploiement d’un autre. Ce qui reste : l’étanchéité de l’environnement, le filtrage du trafic sortant, la durée de vie d’une session, l’enregistrement de ce qui s’est passé, la personne ou la règle qui valide une action sensible. Ces choix décident de ce qu’un agent peut casser, et un incident se produit dans le bac à sable, pas dans l’appel d’API.
Pour qui s’y met, un réflexe utile se trouve dans le dépôt d’exemples : les scripts exercise envoient à votre serveur VNC les appels qu’un modèle enverrait et affichent ce qu’il verrait, sans aucun modèle derrière. On teste ainsi le pilote et l’isolation avant de brancher Claude, et on mesure ce que l’agent pourrait atteindre si une consigne dérapait.
Les sources ne chiffrent ni la fiabilité de Claude sur ces tâches, ni le coût d’un environnement par session, ni la latence ajoutée par chaque partenaire. Ces trois données départageront les pilotes bien plus sûrement que la liste des logos.
Une question de responsabilité reste ouverte pour ce montage. Au premier incident sérieux avec un pilote partenaire, il faudra établir qui répond de l’action : l’éditeur du SDK, le fournisseur du bac à sable, ou l’équipe qui a validé la fonction d’approbation.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 17 évaluations
Faire appel à mes services →
