Les trousses d'outils computer use et browser use sont intégrées aux SDK Python et TypeScript de Claude
Selon un message publié le 7 octobre 2026 et relayé par la documentation Claude Platform, les trousses d'outils browser use et computer use disposent désormais de classes dédiées dans les SDK Python et TypeScript de Claude. D'après cette documentation, l'API renvoie l'action que le modèle veut déclencher, par exemple une navigation, une capture d'écran ou un clic, et le SDK enchaîne la boucle, applique les règles configurées, sollicite ta fonction d'approbation et construit le résultat renvoyé au modèle. L'exécution réelle repose sur un pilote que tu écris en sous-classant l'une de ces trousses d'outils. La page cite des intégrations publiées par Browser Use, Browserbase, Daytona et E2B, et un quickstart minimal est disponible dans le dépôt claude-quickstarts, en Python et en TypeScript.
Ce que ça change pour toi
Si tu construis un agent qui pilote un navigateur ou un poste de travail, la partie répétitive du câblage passe côté SDK : tu décris une méthode par action plutôt que de maintenir ta propre boucle d'appels d'outils. Le travail restant se déplace vers le pilote, la politique d'accès et l'environnement d'exécution. Commence par faire tourner le quickstart contre un environnement jetable avant d'envisager le moindre usage sur tes propres machines ou comptes.
Ce que dit Anthropic
Déclarations relevées dans les sources
- Un message du 7 octobre 2026 annonce que les trousses d'outils computer use et browser use sont intégrées aux SDK Python et TypeScript de Claude.
- La documentation indique que l'API signale l'action voulue par Claude, pendant que le SDK exécute la boucle, applique les règles configurées et construit chaque résultat d'outil.
- La documentation précise que le SDK ne fournit ni navigateur, ni bureau, ni pilote prêt à l'emploi, et renvoie vers des exemples de pilotes à écrire soi-même.
- Anthropic cite des intégrations partenaires publiées par Browser Use, Browserbase, Daytona et E2B, ainsi qu'un quickstart et une page de documentation mis en ligne.
Ce que rapportent d’autres sources
Non confirmé par Anthropic
- Aucune autre source ne complète ce fait.
Ce qui manque
À surveiller
- Les versions des SDK Python et TypeScript concernées ne sont pas précisées.
- La tarification associée à l'usage de ces trousses d'outils reste inconnue.
- Les modèles Claude compatibles et les limites d'usage ne sont pas détaillés.
- Le statut des trousses d'outils, disponibilité générale ou aperçu, n'est pas établi.
Un message publié le 7 octobre 2026 annonce que les trousses d'outils computer use et browser use sont désormais intégrées aux SDK Python et TypeScript de Claude. L'API indique ce que Claude veut cliquer ou saisir, et les SDK exécutent la boucle d'exécution et transmettent les actions à des pilotes. Des pilotes compatibles sont cités : Browser Use, Browserbase, E2B et Daytona, avec la possibilité d'en écrire un à partir des exemples des quickstarts. Un quickstart et une documentation sont mis en ligne.
Ce que le SDK prend en charge
D'après la documentation Claude Platform, chacune des deux trousses d'outils correspond à une classe abstraite que tu sous-classes. Tu écris une méthode par outil membre : aller à une adresse, prendre une capture, cliquer, et ainsi de suite. Le SDK se charge d'acheminer chaque appel vers la bonne méthode, d'appliquer les règles que tu lui passes, d'interroger ta fonction d'approbation et de composer le message de résultat renvoyé au modèle.
L'intérêt pratique tient à ce déplacement de responsabilité. Jusque-là, chaque équipe réécrivait la même mécanique : lire l'appel d'outil, le décoder, l'exécuter, remettre en forme la réponse, relancer. Cette plomberie est désormais fournie, et ce que tu maintiens se réduit à l'adaptation vers ton outil d'automatisation.
La documentation mentionne aussi un rapport d'état que tout pilote de navigateur doit fournir, décrivant les onglets ouverts et les changements survenus. Le modèle raisonne sur cet état entre deux actions, donc la qualité de ce que tu renvoies conditionne la qualité de ce qu'il décide ensuite.
Le pilote reste à ta charge
La page est explicite sur le périmètre : le SDK ne livre ni navigateur, ni poste de travail, ni pilote prêt à l'emploi, ni politique d'URL. Autrement dit, la partie qui coûte le plus en exploitation reste de ton côté, qu'il s'agisse de lancer un Chromium pilotable, d'héberger un bureau isolé ou de gérer les sessions.
C'est là qu'interviennent les intégrations citées. La documentation renvoie vers des ressources publiées par Browser Use, Browserbase, Daytona et E2B, chacun proposant sa propre manière de fournir l'environnement d'exécution. Pour une petite équipe, l'arbitrage se pose en ces termes : écrire et héberger ton pilote, ou déléguer l'environnement à un prestataire et accepter la dépendance qui va avec.
Le dépôt claude-quickstarts contient par ailleurs deux exemples minimaux, un pour le navigateur via le protocole Chrome DevTools, un pour le bureau via VNC. Leurs auteurs les présentent comme des démonstrations d'interface, pas comme des bases à mettre en production.
Les garde-fous décrits dans la documentation
Deux mécanismes apparaissent dans les extraits. Le premier est une option de confirmation : dans l'exemple de bureau, toute action autre qu'une capture d'écran est affichée et n'est exécutée qu'après ton accord explicite. Le second est une politique d'adresses, présentée comme un exemple à écrire toi-même, qui filtre les destinations que le modèle peut atteindre.
L'avertissement joint au quickstart de bureau mérite attention : ce qui s'affiche à l'écran oriente la suite des décisions du modèle, et un terminal au premier plan exécute ce qui y est saisi. Les auteurs recommandent un bureau jetable dans un bac à sable, un serveur VNC maintenu sur la boucle locale et la lecture préalable de la section de la documentation consacrée à l'exécution sûre.
Pour toi, cela revient à traiter un agent de ce type comme un utilisateur non fiable disposant d'un clavier. Les comptes, les sessions ouvertes et les fichiers accessibles depuis cet environnement définissent ta surface de risque réelle.
Ce qu'il te reste à vérifier
Les extraits ne permettent pas de trancher plusieurs points qui pèsent sur une décision d'adoption : la version de SDK à partir de laquelle ces aides sont présentes, les modèles concernés, le coût d'un parcours typique, les limites d'usage et le statut de maturité de ces trousses d'outils. Ces éléments figurent peut-être ailleurs dans la documentation, mais les sources citées ici ne les établissent pas.
Une vérification empirique sert davantage qu'une lecture. Une boucle de ce type consomme des captures d'écran à répétition, et le nombre d'allers-retours nécessaires pour une tâche banale détermine la viabilité économique de l'ensemble. Mesure-le sur ton propre scénario avant de dimensionner quoi que ce soit.
Le quickstart de bureau propose aussi un mode qui rejoue les appels sans modèle. C'est le point d'entrée raisonnable pour éprouver ton pilote et ton environnement isolément, avant d'y brancher un modèle et d'additionner les sources d'incertitude.