Claude Cowork sur Mobile et Web : Comment les Équipes Devraient Repenser Leur Harnais d'Agent

Introduction

La mise à jour de Claude Cowork d'Anthropic semble simple au premier abord : Cowork s'étend au-delà du bureau pour devenir disponible sur le web et le mobile également. Mais le véritable signal est plus important qu'une nouvelle interface.

Lorsqu'un agent peut continuer à travailler après qu'un utilisateur a quitté son bureau, le produit n'est plus seulement une fenêtre de chat. Il devient un fil de tâches persistant. L'utilisateur peut démarrer une tâche sur son bureau, vérifier l'avancement sur un téléphone, répondre à une demande de clarification depuis un autre appareil, et revenir plus tard pour examiner un artefact.

Ce changement est important pour les équipes utilisant Claude Cowork, Claude Code, Codex, Cursor, GitHub Copilot, NxCode, ou des agents internes. La question n'est plus seulement "Le modèle peut-il résoudre la tâche ?" La meilleure question est : Le système autour du modèle peut-il contrôler le contexte, les outils, l'état, les autorisations, les journaux, la validation et la revue humaine ?

Points Clés à Retenir

• Claude Cowork sur mobile et web est un signal produit, pas seulement une mise à jour de commodité. Il transforme le travail IA en un flux de tâches persistant et multi-appareils.
• La compétition entre produits d'agents se déplace vers le harnais d'agent : autorisations, contexte, état, journaux, routage de modèles, vérification et revue.
• L'accès mobile est utile pour les vérifications de progression et les confirmations limitées, mais il ne devrait pas affaiblir la revue de code, l'approbation de production ou les contrôles de données sensibles.
• AWS AgentCore et la discussion plus large autour de l'ingénierie des harnais montrent que les fournisseurs cloud et les équipes de recherche vont dans la même direction.
• Les équipes devraient traiter cette version comme un moment d'audit de flux de travail, pas simplement comme une autre annonce de fonctionnalité.

Ce Qui a Réellement Changé

Claude Cowork s'étend d'un flux de travail centré sur le bureau à une expérience web et mobile. L'utilisateur peut démarrer une tâche sur un ordinateur, laisser Claude continuer en arrière-plan, vérifier le statut depuis un téléphone, et revenir plus tard pour examiner le résultat.

Cela change le modèle mental.

Un chatbot attend le message suivant. Un outil de complétion de code suggère la ligne suivante. Un agent en arrière-plan continue de travailler après que l'utilisateur s'est éloigné. Cela signifie que les équipes ne peuvent pas placer toute la gouvernance dans une seule session de bureau ou une seule fenêtre de terminal visible.

La page produit de Cowork d'Anthropic met également l'accent sur le contrôle. Les utilisateurs choisissent les dossiers et les outils, et les administrateurs d'entreprise peuvent configurer l'accès et les autorisations. Cela est important car le travail multi-appareils n'est utile que s'il ne transforme pas accidentellement chaque pression sur un téléphone en une large autorisation.

Pour les équipes d'ingénierie, la leçon n'est pas "déplacer chaque tâche sur mobile". La leçon est que le travail délégué devient durable. Les tâches se poursuivront à travers les onglets, les appareils, les réunions, les notifications et les changements de contexte humain. Le modèle opérationnel doit supposer que le travail peut continuer après la première invite.

Pourquoi C'est une Histoire de Harnais

Un harnais d'agent est le système autour du modèle qui transforme une requête en travail contrôlé.

Il inclut :

• L'assemblage du contexte
• L'accès aux outils
• La gestion de l'état
• Les règles de mémoire
• La planification des tâches
• Les nouvelles tentatives et la gestion des échecs
• Les journaux
• Les autorisations
• La validation
• La revue humaine

Un modèle fort dans un harnais faible peut encore échouer gravement. Il peut lire les mauvais fichiers, utiliser le mauvais outil, faire une grande

changement dangereux, ou produire un résultat qui semble soigné mais ne peut être révisé.

L'expansion mobile et web de Claude Cowork rend le harnais plus visible. La tâche peut commencer sur un ordinateur de bureau, se poursuivre dans le cloud, demander une approbation sur mobile, et se terminer par des fichiers ou messages prêts pour la révision. Ce flux nécessite un état et des autorisations qui accompagnent la tâche, et non seulement l'appareil.

AWS pousse une idée connexe du côté cloud via Amazon Bedrock AgentCore. Son modèle de harnais se concentre sur l'orchestration, l'exécution des outils, la gestion du contexte, la persistance de l'état, la reprise après panne et les sessions isolées. Les écrits de Lilian Weng sur l'ingénierie des harnais vont dans la même direction d'un point de vue recherche : un meilleur comportement des agents ne vient pas seulement de poids de modèle plus forts, mais aussi de meilleurs environnements, boucles de rétroaction, évaluations, outils et échafaudages.

En termes pratiques, le harnais est l'endroit où les équipes définissent ce que signifie un « bon travail d'agent ».

Le Risque du Travail Toujours Actif

Les agents multi-appareils ont une valeur évidente.

Un chef de produit peut demander une brève étude client avant de monter dans un train. Un ingénieur peut lancer une investigation de logs, fermer l'ordinateur portable, et approuver un suivi ciblé depuis un téléphone. Un fondateur peut déléguer une mise à jour pour les investisseurs et réviser le brouillon plus tard.

Mais le risque est tout aussi clair. Une tâche qui continue de s'exécuter en arrière-plan peut continuer à utiliser des outils, des fichiers, des applications connectées et du contexte après que l'humain cesse de regarder l'écran.

Les équipes devraient séparer cinq types d'autorités.

Type d'Autorité	Exemple	Règle par Défaut
Lire le contexte local	Fichiers du dépôt, docs, notes	Autoriser uniquement les dossiers définis
Lire les applications connectées	Slack, email, calendrier, CRM	Utiliser l'approbation par connecteur
Écrire des artefacts locaux	Brouillons, branches, feuilles de calcul	Autoriser uniquement avec des diffs révisables
Communication externe	Envoyer un email, poster sur Slack, créer un ticket	Exiger confirmation humaine
Action destructive ou de production	Supprimer des fichiers, faire tourner des secrets, déployer	Exiger approbation explicite et journaux

L'accès mobile devrait accélérer la révision, pas l'affaiblir. Un téléphone est utile pour vérifier l'état d'une tâche, répondre à une clarification, ou approuver une étape suivante ciblée. Ce n'est pas le bon endroit pour réviser une grande diff de code, autoriser une migration de production, approuver des changements de facturation, ou accorder un large accès aux données clients.

Une règle opérationnelle simple fonctionne bien :

Le mobile peut diriger, mais une approbation sérieuse devrait avoir lieu là où les preuves sont visibles.

Ce Que Les Équipes de Code Devraient Changer

1. Rendre le Périmètre de la Tâche Explicite

Chaque tâche déléguée a besoin d'une limite écrite.

Un bon périmètre devrait inclure :

• L'objectif
• Les fichiers, dossiers ou systèmes autorisés
• Les actions interdites
• Les outils autorisés
• Le résultat attendu
• Les commandes de validation
• Les conditions d'arrêt
• Les points d'approbation humaine requis

Sans ces limites, un agent en arrière-plan n'est qu'une invite longue durée avec des outils attachés. Ce n'est pas un modèle opérationnel sûr.

2. Exiger des Preuves, Pas Seulement un Résultat

Un réviseur ne devrait pas avoir à deviner ce que l'agent a fait.

Pour les tâches de code, le rapport final devrait inclure :

• Fichiers modifiés
• Résumé des diffs
• Commandes exécutées
• Tests réussis ou échoués
• Hypothèses
• Risques connus
• Chemin de retour arrière suggéré, si

pertinent

Pour les tâches de recherche, le rapport final doit inclure :

• Liens sources
• Niveau de confiance
• Informations manquantes
• Preuves contradictoires
• Questions ouvertes

L'objectif est de rendre le travail de l'agent vérifiable. Une réponse soignée ne suffit pas.

3. Utiliser le routage de modèles

Toutes les tâches n'ont pas besoin du même modèle, de la même fenêtre de contexte ou du même budget.

Les résumés à faible risque, le tri des problèmes, le formatage et les transformations déterministes peuvent souvent utiliser des modèles moins coûteux. Le débogage difficile, la planification d'architecture, les migrations et les travaux sensibles à la sécurité peuvent justifier des modèles plus puissants et une révision plus stricte.

Une politique de routage pratique pourrait ressembler à ceci :

Type de tâche	Stratégie de modèle suggérée	Niveau de révision
Mise en forme ou nettoyage	Modèle peu coûteux	Révision légère
Résumé ou tri	Modèle peu coûteux	Vérification ponctuelle
Petite correction de code	Modèle moyen/élevé selon le risque	Révision diff + test
Changement d'architecture	Modèle plus puissant	Révision humaine requise
Tâche de sécurité ou de production	Modèle plus puissant + cadre strict	Approbation humaine requise
Communication externe client	Modèle plus puissant ou piloté par humain	Approbation avant envoi

Le but n'est pas de toujours utiliser le modèle le moins cher. Le but est d'utiliser le bon modèle pour le niveau de risque.

4. Limiter la mémoire

Les agents persistants incitent à tout stocker. C'est risqué.

Les équipes doivent stocker des informations stables et réutilisables telles que :

• Règles du projet
• Commandes préférées
• Conventions du dépôt
• Flux de travail acceptés
• Commandes de test
• Préférences de formatage

Les équipes doivent éviter de stocker :

• Secrets
• Données personnelles
• Détails spécifiques au client
• Spéculations temporaires
• Hypothèses non vérifiées
• Contexte commercial sensible sans politique de conservation

Une bonne mémoire améliore la fiabilité du flux de travail. Une mauvaise mémoire transforme l'hypothèse d'hier en instruction cachée de demain.

5. Créer un benchmark local

N'évaluez pas les agents uniquement à travers des démonstrations ou des extraits de réseaux sociaux.

Choisissez des tâches réelles du mois dernier. Incluez des bogues, des refactorisations, des modifications de documentation, du nettoyage de données, des investigations de support et des vérifications de version. Exécutez chaque agent avec le même budget de temps et comparez les résultats.

Mesurez :

• Taux d'achèvement
• Temps de révision
• Coût en jetons
• Type d'erreur
• Problèmes de sécurité
• Complexité de rollback
• Utilité réelle de la sortie

Un benchmark local d'équipe est plus précieux qu'un classement générique car il reflète le travail réel que l'équipe effectue.

Un cadre pratique pour agent We0 AI

Un cadre utile n'a pas besoin de commencer comme un grand projet de plateforme. Une version minimale peut être construite avec un fichier d'instructions de dépôt, un modèle de tâche, une liste de vérification de validation et une règle de révision.

Utilisez un modèle de tâche comme celui-ci :

Objectif :

Contexte autorisé :

Outils autorisés :

Actions interdites :

Commande de validation :

Artéfact attendu :

Approbation humaine nécessaire pour :

Arrêter si :

Ensuite, cartographiez les types de tâches aux flux de travail.

Ce modèle est simple, mais il force l'équipe à rendre visible l'autorisation et la validation.

Pour les flux de travail de type We0 AI, le cadre doit aider les équipes à définir des instructions, exécuter des vérifications reproductibles, comparer les sorties des agents et conserver suffisamment de contexte pour la révision. L'objectif n'est pas de ralentir

adoption. L'objectif est de rendre la délégation suffisamment prévisible pour être digne de confiance.

Comment évaluer Claude Cowork par rapport aux autres agents

Ne comparez pas Claude Cowork, Claude Code, Codex, GitHub Copilot, Cursor ou les agents internes sur la base de « sensations » ou d'impressions vagues.

Utilisez des tâches réelles et posez cinq questions :

1. L'agent peut-il trouver le contexte approprié sans lire excessivement des fichiers privés ou non pertinents ?
2. Peut-il utiliser les outils en toute sécurité et se remettre des échecs d'outils ?
3. Peut-il produire un artefact petit et vérifiable ?
4. Peut-il prouver le résultat avec des tests, des liens sources ou des journaux ?
5. Un humain peut-il arrêter, rediriger ou approuver le travail aux bons moments ?

Exécutez chaque tâche plus d'une fois. Les agents sont stochastiques. Une seule exécution impressionnante ne prouve pas la fiabilité, et une seule mauvaise exécution ne prouve pas que le système est inutile.

Mesurez également la charge de révision. Si un agent crée un artefact volumineux dont la vérification prend plus de temps que d'effectuer la tâche manuellement, il n'est pas utile. Un agent utile réduit le coût pour parvenir à une décision éclairée. Il ne se contente pas de générer plus de résultats.

Ce que le marché nous dit

Claude Cowork mobile et web fait partie d'un changement plus large.

AWS transforme les harnais d'agents en infrastructure cloud gérée. L'agent cloud de GitHub Copilot prend en charge le codage en arrière-plan et les workflows de pull requests. Claude Code, Codex, Cursor et les agents internes poussent tous les équipes vers un travail asynchrone utilisant des outils. Les discussions de recherche autour de l'ingénierie des harnais suggèrent également que de meilleurs systèmes d'agents dépendront d'environnements, d'outils, de boucles de rétroaction et d'évaluations plus solides.

Ce sont différentes histoires de produits, mais elles pointent vers la même réalité opérationnelle : les produits d'IA deviennent des systèmes.

Ils ont besoin :

• De contrôle d'exécution
• D'acheminement de modèles
• De politique de contexte
• D'autorisations d'outils
• D'observabilité
• D'évaluation
• D'approbation humaine
• De pistes d'audit

L'ère du « collez l'invite, obtenez la réponse » n'est pas terminée. Mais pour les équipes sérieuses, ce n'est plus la frontière.

Modèle opérationnel recommandé

Voici un plan de déploiement pratique sur 30 jours.

Semaine 1 : Inventaire de l'utilisation actuelle des agents

Listez chaque outil agent que votre équipe utilise.

Pour chaque outil, enregistrez :

• À quelles données il peut accéder
• Ce qu'il peut écrire
• Quels outils il peut appeler
• S'il peut exécuter des commandes
• S'il touche aux données clients
• Comment les résultats sont révisés
• Si l'utilisation est officielle ou non officielle

Cela donne à l'équipe une base de référence claire.

Semaine 2 : Créer une politique de tâches

Divisez les tâches en risques faible, moyen et élevé.

Cette politique doit être écrite. Si une catégorie de tâche n'est pas claire, traitez-la comme à risque moyen ou élevé jusqu'à ce que l'équipe en décide autrement.

Semaine 3 : Construire un benchmark interne

Sélectionnez environ 20 tâches réelles du mois précédent.

Incluez :

• Corrections de bugs
• Refactorisations
• Mises à jour de documentation
• Enquêtes de support client
• Travaux de nettoyage de données
• Vérifications de version
• Notes de recherche

Exécutez les workflows actuels et au moins une configuration d'agent alternative. Suivez l'achèvement, le temps de révision, le coût, les échecs et les surprises.

Semaine 4 : Renforcer le harnais

Ajoutez ou améliorez :

• Instructions du dépôt
• Commandes de validation
• Exigences de journalisation
• Autorisations des connecteurs
• Conditions d'arrêt
• Listes de contrôle de révision
• Règles d'approbation

Si une tâche

ne peut être vérifié, il ne doit pas être délégué sans un propriétaire humain clair.

Règles pratiques pour l'accès des agents mobiles

L'accès mobile doit être conçu autour d'un contrôle étroit, et non d'une autorité étendue.

Un workflow mobile sécurisé peut permettre aux utilisateurs de :

• Vérifier l'avancement des tâches
• Répondre à une question de clarification
• Approuver une prochaine étape à faible risque
• Arrêter une tâche
• Rediriger une tâche
• Demander un résumé
• Marquer une tâche pour révision sur ordinateur

Il ne doit pas permettre aux utilisateurs de :

• Approuver de grandes différences de code
• Déployer en production
• Supprimer des fichiers
• Envoyer des e-mails clients
• Accorder un accès étendu à des dossiers
• Exposer des secrets
• Modifier la facturation ou les autorisations
• Accepter de gros artefacts générés sans preuve

Cela ne signifie pas que le contrôle mobile est mauvais. Cela signifie que le contrôle mobile doit être limité aux types de décisions qui peuvent être prises de manière responsable depuis un petit écran.

En résumé

Le support mobile et web de Claude Cowork est important car il montre où se dirigent les produits agents. Le travail IA sera persistant, multi-appareils, asynchrone et utilisera des outils.

Les équipes qui considèrent les agents uniquement comme des compléments automatiques plus intelligents manqueront le virage. Les équipes qui considèrent les agents comme des collègues entièrement de confiance créeront un risque évitable.

La voie la plus sûre est la délégation contrôlée : des périmètres de tâches restreints, des autorisations explicites, des journaux persistants, une validation déterministe, un routage de modèle et une révision humaine aux bons moments.

FAQ

Qu'est-ce que Claude Cowork ?

Claude Cowork est le produit de travail agentique d'Anthropic qui permet à Claude de gérer des tâches à travers des fichiers, des outils et des workflows pendant que l'utilisateur examine le résultat final. Son support web et mobile rend le workflow plus persistant et multi-appareils.

Pourquoi l'accès mobile de Claude Cowork est-il important ?

L'accès mobile est important car il change la façon dont les utilisateurs interagissent avec les agents. Au lieu de rester dans une session de bureau, une tâche peut continuer en arrière-plan pendant que l'utilisateur vérifie la progression, répond à des questions ou examine l'état depuis un autre appareil.

Qu'est-ce qu'un harnais d'agent ?

Un harnais d'agent est le système autour du modèle qui gère le contexte, les outils, l'état, les autorisations, la validation, les journaux et la révision humaine. C'est ce qui transforme une réponse de modèle en travail contrôlé.

L'approbation mobile est-elle sûre pour les agents IA ?

L'approbation mobile peut être sûre pour des décisions étroites et à faible risque, comme clarifier une exigence ou vérifier la progression. Elle ne doit pas remplacer une révision complète pour les grandes modifications de code, les actions de production, les données clients, les messages externes ou les opérations destructrices.

Comment les équipes doivent-elles évaluer Claude Cowork par rapport à Codex ou Cursor ?

Utilisez des tâches internes réelles au lieu de démos. Comparez le taux d'achèvement, la charge de révision, le coût, la sécurité, la complexité de retour en arrière, les preuves sources et la capacité à arrêter ou rediriger l'agent aux bons moments.

Que doit inclure un bon modèle de tâche d'agent ?

Un bon modèle doit inclure l'objectif, le contexte autorisé, les outils autorisés, les actions interdites, la commande de validation, l'artefact attendu, les points d'approbation requis et les conditions d'arrêt.

Pourquoi le routage des modèles est-il important pour les workflows agents ?

Différentes tâches ont différents niveaux de risque et de complexité. Les résumés simples peuvent ne pas nécessiter le modèle le plus cher, tandis que les changements d'architecture, le débogage, les migrations et les opérations sensibles à la sécurité

Les tâches peuvent nécessiter des modèles plus puissants et une révision plus stricte.

Quel est le plus grand risque des agents IA toujours actifs ?

Le principal risque est que l'agent continue d'utiliser des outils, un contexte ou des autorisations après que l'utilisateur a cessé d'y prêter une attention particulière. C'est pourquoi un accès limité, des journaux, des artefacts vérifiables et des points de validation sont essentiels.

Outils connexes

• Claude Cowork : produit d'agent IA inter-appareils d'Anthropic pour déléguer et réviser le travail.
• Claude Code : agent de codage d'Anthropic capable de lire les bases de code, modifier des fichiers, exécuter des commandes et travailler avec des outils de développement.
• OpenAI Codex : plateforme d'agent de codage d'OpenAI pour les tâches de génie logiciel et les compétences d'agent.
• GitHub Copilot Cloud Agent : agent de codage en arrière-plan de GitHub pour la recherche de dépôts, les modifications de code et les workflows de pull request.
• Amazon Bedrock AgentCore : infrastructure AWS pour déployer et exploiter des agents avec des capacités d'exécution, de mémoire, d'identité, d'observabilité et de contrôle.
• Cursor : éditeur de code IA utilisé pour le codage agentique, la navigation dans les bases de code et l'automatisation des workflows de développement.

Liens connexes

• Page produit Claude Cowork : page produit officielle d'Anthropic pour Claude Cowork.
• Utiliser Claude Cowork en toute sécurité : article du centre d'aide Claude sur l'utilisation sécurisée et les contrôles de Cowork.
• Documentation Amazon Bedrock AgentCore Harness : documentation AWS pour la configuration et l'exploitation du cadre de contrôle d'agent géré.
• Annonce de disponibilité générale d'Amazon Bedrock AgentCore Harness : annonce AWS de la disponibilité générale du cadre de contrôle AgentCore.
• Ingénierie du cadre de contrôle pour l'auto-amélioration : article de Lilian Weng sur l'ingénierie du cadre de contrôle, l'évaluation et les systèmes d'agents auto-améliorants.
• Documentation GitHub Copilot Cloud Agent : documentation GitHub pour les workflows d'agents en arrière-plan.

Résumé

La prise en charge mobile et web de Claude Cowork est plus qu'une simple mise à jour d'interface produit. Elle montre que le travail des agents devient persistant, multi-appareils, asynchrone et utilisateur d'outils.

Ce changement rend le cadre de contrôle de l'agent plus important. Les équipes ont besoin de portées de tâches plus claires, d'autorisations plus strictes, de journaux persistants, de routage de modèles, de validation déterministe et d'approbation humaine aux bons moments.

Une bonne prochaine étape n'est pas de courir après chaque nouvelle fonctionnalité d'agent. C'est de construire un petit benchmark interne, définir des niveaux de risque et rendre le travail délégué vérifiable.

Le workflow d'agent le plus fort n'est pas celui qui a le plus d'autonomie. C'est celui qui a les limites les plus claires, les meilleures preuves et le chemin de révision le plus sûr.