IntroductionL’arrivée de Claude Cowork sur le web et le mobile ne signifie pas simplement un nouvel endroit où cliquer sur un bouton. C’est le signe que les agents d’IA passent de brèves conversations sur ordinateur à des systèmes de tâches de longue durée capables de poursuivre le travail d’un appareil à l’autre.Pour les équipes produit, ingénierie et opérations, la question importante n’est plus seulement de savoir si un agent peut terminer une tâche. La question la plus difficile est de savoir si l’agent peut respecter les bonnes limites pendant qu’il travaille : quels fichiers il peut lire, quels outils il peut utiliser, quelles actions nécessitent une approbation, quelles preuves il doit fournir et comment les humains peuvent examiner le résultat.Cet article explique la signification concrète de cette évolution. Il se concentre sur la conception de l’agent harness : la couche autour du modèle qui gère le contexte, les outils, les autorisations, l’état, les journaux, la validation et le contrôle humain.## Notes sur la source et les imagesPage source d’origine : Claude Cowork 登上移动端与网页端：团队该重新设计 Agent HarnessLa page source analysée exposait une carte de blog SVG par défaut ainsi que des images du site et du pied de page, mais aucune capture d’écran au niveau du corps de l’article, aucun diagramme de workflow, aucune capture de code ni image de résultat clairement nécessaires au contenu de l’article. Afin d’éviter d’insérer des images décoratives ou sans rapport, aucune image n’a été ajoutée au corps de l’article. Si une future version de la source inclut des captures d’écran du produit ou des diagrammes, ils pourront être insérés près des sections correspondantes.## Points clés à retenir- L’extension de Claude Cowork au desktop, au web et au mobile change la manière dont les équipes doivent penser le travail des agents.
- Un agent accessible sur plusieurs appareils n’est pas seulement une interface de chat. C’est un fil de tâche qui peut se poursuivre en arrière-plan.
- Les équipes ont besoin d’un agent harness clair : limites de contexte, autorisations d’outils, suivi d’état, journaux, validation et règles d’approbation.
- L’accès mobile est utile pour vérifier l’avancement et donner des confirmations légères, mais il ne doit pas devenir un raccourci contournant la revue de code, l’approbation de production ou les contrôles sur les données sensibles.
- Le marché dans son ensemble évolue dans la même direction : les produits d’agents deviennent des problèmes d’ingénierie de systèmes, et pas seulement des problèmes de choix de modèle.## Ce qui a changéClaude Cowork s’oriente désormais vers un workflow dans lequel une même tâche peut commencer sur un appareil et se poursuivre sur un autre. Un utilisateur peut confier un travail depuis un ordinateur, vérifier l’avancement depuis un téléphone, répondre à une demande loin de son bureau, puis revenir plus tard pour examiner le résultat final.Cela semble pratique, mais cela modifie aussi le modèle de contrôle. Dans une fenêtre de chat traditionnelle, l’utilisateur reste généralement proche de l’interaction. Avec un agent en arrière-plan, l’agent peut continuer à utiliser le contexte et les outils alors même que l’utilisateur ne surveille plus activement chaque étape.C’est pourquoi l’accès multiplateforme à un agent doit être considéré comme plus qu’une simple fonctionnalité produit. C’est une question de conception de workflow. La tâche doit porter ses propres limites, exigences en matière de preuves et règles d’approbation, que l’utilisateur soit sur desktop, sur le web ou sur mobile.## Pourquoi c’est un problème d’agent harnessUn agent harness est la couche opérationnelle autour du modèle. Le modèle décide de ce qu’il faut faire ensuite, mais le harness détermine ce que lece que le modèle peut voir, quels outils il peut appeler, comment l’état est stocké, comment les actions sont journalisées, comment les échecs sont gérés et à quel moment un humain doit approuver l’étape suivante.Un modèle puissant dans un cadre d’exécution faible peut tout de même créer de sérieux problèmes. Il peut lire les mauvais fichiers, utiliser un outil en dehors du périmètre prévu, produire un travail difficile à relire, ou agir avant que l’équipe n’ait validé le résultat.Lorsqu’un agent travaille sur plusieurs appareils, le cadre d’exécution devient encore plus important. La tâche peut commencer sur ordinateur, se poursuivre dans une session distante, demander une confirmation sur mobile, puis générer un document, une modification de code ou un message. Le modèle d’autorisation doit suivre la tâche, et non l’appareil.Un bon cadre d’exécution répond à des questions pratiques avant le début de la tâche :- Quel est l’objectif exact de la tâche ?
- Quel contexte est autorisé ?
- Quels outils sont disponibles ?
- Quelles actions sont interdites ?
- Quel résultat est attendu ?
- Quelle validation doit être effectuée ?
- Quelles preuves doivent être incluses ?
- Qu’est-ce qui nécessite une approbation humaine ?
- Quand l’agent doit-il s’arrêter ?## Le risque des agents toujours actifsLe travail en arrière-plan est utile. Un chef de produit peut demander à un agent d’organiser les retours clients. Un ingénieur peut demander à un agent d’inspecter les journaux et de suggérer une correction. Un fondateur peut demander un premier brouillon de mise à jour pour les investisseurs pendant un déplacement.Le risque est qu’un agent puisse continuer à agir après que l’utilisateur a cessé de le surveiller attentivement. Ce n’est pas automatiquement dangereux, mais cela exige de meilleures limites.Les équipes devraient séparer les autorisations des agents en catégories claires :| Catégorie d’autorisation | Usage typique | Contrôle recommandé |
|-|-|-|
| Lire des fichiers locaux | Inspecter un dépôt, un dossier ou un ensemble de documents | Limiter par dossier ou par périmètre d’espace de travail |
| Lire des applications connectées | Extraire du contexte depuis les e-mails, les documents, le CRM, les outils de suivi des tickets ou les journaux | Accorder un accès restreint et éviter par défaut les données sensibles |
| Écrire des artefacts locaux | Créer des fichiers, modifier des documents ou préparer des changements de code | Exiger des diffs vérifiables ou un historique des versions |
| Envoyer des messages externes | Envoyer des e-mails, publier du contenu, ouvrir des tickets ou notifier des utilisateurs | Exiger une confirmation humaine explicite |
| Effectuer des actions de production ou destructrices | Déployer, supprimer, modifier la facturation, changer des autorisations ou exécuter des commandes irréversibles | Rendre l’exécution humaine obligatoire |La confirmation sur mobile peut accélérer le flux de travail, mais elle ne doit pas remplacer une véritable conception de l’approbation. Une validation sur téléphone doit confirmer une action bien délimitée, et non accorder un accès large à une tâche floue.## Ce que les équipes de développement devraient changer###
- Définir les limites de la tâche avant l’exécutionChaque tâche confiée à un agent devrait commencer par un bref descriptif. Ce descriptif devrait inclure l’objectif, le contexte autorisé, les outils autorisés, les actions interdites, le résultat attendu, la méthode de validation et la condition d’arrêt.C’est particulièrement important pour les tâches de développement. Une demande vague comme « corrige ce problème » est trop large pour un agent laissé sans supervision. Une version plus sûre nommerait le problème, identifierait les fichiers ou modules concernés, préciserait la commande de test et exigerait un diff ainsi que des notes sur les risques.###
- Demander des preuves, pas seulement des réponsesLes résultats produits par un agent devraient inclure des preuves. Pour les tâches de code, cela signifie des diffs, des résultats de tests, des journaux de compilation et une brève explication des risques. Pour les tâches de recherche, cela signifie des liens vers les sources, un niveau de confiance et des points ouvertsquestions. Pour les tâches opérationnelles, cela signifie le plan d’action, les systèmes affectés, les notes de retour arrière et les points d’approbation.L’objectif n’est pas de faire écrire des rapports plus longs à l’agent. L’objectif est de réduire le coût de la revue.###
- Orienter les tâches selon le risque et le coûtToutes les tâches n’ont pas besoin du modèle le plus puissant ni du budget de raisonnement le plus élevé. Les tâches de faible risque comme le formatage, le résumé et la classification peuvent souvent être exécutées avec des modèles moins coûteux ou plus rapides. Les changements d’architecture, les migrations, le débogage en production et les tâches sensibles sur le plan de la sécurité doivent utiliser des modèles plus puissants et faire l’objet d’une revue plus stricte.Le routage des modèles doit faire partie du dispositif d’encadrement, et non être une réflexion après coup. Une équipe qui oriente les tâches selon le risque peut maîtriser les coûts sans réduire la sécurité.###
- Limiter délibérément la mémoireLes agents peuvent tirer parti d’une mémoire de projet stable : règles du dépôt, commandes courantes, conventions de nommage, notes d’architecture et préférences de style.Ils ne doivent pas stocker à la légère des secrets, des identifiants, des données client, des hypothèses temporaires ou des conclusions non vérifiées. La mémoire n’est utile que lorsqu’elle est soigneusement sélectionnée. Sinon, elle devient une autre source de dérive contextuelle cachée.## Un modèle pratique de dispositif d’encadrementLes équipes n’ont pas besoin d’une plateforme complexe pour commencer. Elles peuvent démarrer avec un modèle de tâche simple et l’appliquer de manière cohérente.```YAML
task_goal: "Décrire le résultat exact que l’agent doit produire."
allowed_context:
- "Lister les dossiers, fichiers, tickets, journaux ou documents que l’agent peut lire."
allowed_tools:
- "Lister les outils tels que terminal, navigateur, gestionnaire de tickets, documentation ou exécuteur de tests."
forbidden_actions:
- "Aucun déploiement en production."
- "Aucun message externe."
- "Aucune suppression de fichiers ou de données."
validation:
- "Exécuter les tests ou contrôles pertinents."
- "Inclure la sortie des commandes ou expliquer pourquoi la validation n’a pas pu être exécutée."
expected_output:
- "Fournir un diff, un résumé, les risques et les étapes suivantes."
human_approval_required_for:
- "Envoi de messages"
- "Déploiement"
- "Suppression de données"
- "Modification des autorisations"
stop_condition: "S’arrêter lorsque le résultat est prêt pour la revue humaine ou lorsque le contexte requis est manquant."
- Peut-il utiliser les outils en toute sécurité et rester dans le périmètre demandé ?
- Produit-il de petits changements faciles à relire plutôt que de grandes réécritures floues ?
- Fournit-il des résultats de tests, des citations, des journaux ou d’autres éléments de preuve ?
- Sait-il quand s’arrêter et demander une intervention humaine ?
- Quel est le coût de l’exécution en jetons, en temps et en effort de revue ?
- À quel point est-il difficile derevenir sur un résultat erroné ?Exécutez chaque tâche plus d’une fois. Les agents sont des systèmes probabilistes. Une seule exécution impressionnante ne prouve pas la fiabilité, et une seule mauvaise exécution ne prouve pas que l’outil est inutilisable. Examinez le taux d’achèvement, les types d’échec, le coût de révision, le coût par résultat utile et l’effort de récupération.## Signaux du marché
Claude Cowork s’inscrit dans un mouvement plus large. Les outils d’IA deviennent des systèmes d’agents qui combinent modèles, outils, autorisations, mémoire, journaux et évaluations.Amazon Bedrock AgentCore montre comment les plateformes cloud évoluent vers une infrastructure d’agents gérée. Les discussions de recherche autour de la harness engineering vont dans le même sens : les capacités du modèle comptent, mais c’est le système qui entoure le modèle qui détermine s’il peut être utilisé de manière fiable. Les documents d’OpenAI sur Codex présentent également la boucle de l’agent comme un problème d’orchestration impliquant les prompts, les outils, l’exécution et la gestion du contexte.L’enseignement pratique est simple : la prochaine étape des produits d’IA ne se gagnera pas uniquement en choisissant le modèle le plus performant. Les équipes auront aussi besoin d’une meilleure stratégie de contexte, d’autorisations d’outils plus sûres, de journaux persistants, d’une évaluation reproductible et d’un contrôle humain clair.## Plan d’action recommandé### Semaine 1 : Auditer l’usage actuel des agentsDressez la liste de tous les agents d’IA ou assistants de programmation utilisés par l’équipe. Incluez les applications de bureau, les agents web, les outils IDE, les agents de navigateur, les bots internes et les scripts connectés aux API de modèles. Pour chaque outil, documentez ce qu’il peut lire, ce qu’il peut écrire et s’il peut déclencher des actions externes.### Semaine 2 : Classer les tâches selon le risqueSéparez les tâches en groupes à risque faible, moyen et élevé.Les tâches à faible risque peuvent inclure le formatage, la synthèse et la génération de brouillons. Les tâches à risque moyen peuvent inclure les modifications de code, la transformation de données ou le triage des tickets. Les tâches à risque élevé incluent les changements en production, le traitement de données client, les travaux de sécurité, les modifications de facturation et la communication externe.### Semaine 3 : Construire un petit benchmark interneChoisissez 20 tâches réelles du mois dernier. Utilisez-les comme ensemble de référence. Incluez des tâches réussies, des tâches échouées, des tâches ambiguës et des tâches qui ont nécessité une correction humaine.Mesurez le taux d’achèvement, le temps de révision, la qualité des preuves, le coût en tokens et la complexité du retour arrière. Cela donne à l’équipe un moyen concret de comparer les agents au lieu de se fier aux affirmations marketing.### Semaine 4 : Standardiser les instructions et la validationAjoutez des instructions de dépôt, des modèles de tâches, des commandes de validation, des exigences de journalisation et des conditions d’arrêt. Rendez le processus de révision visible. Si un agent ne peut pas montrer ce qu’il a modifié et comment il a validé le résultat, la tâche ne doit pas être considérée comme terminée.## FAQ### Qu’est-ce que Claude Cowork ?Claude Cowork est le flux de travail de type agent d’Anthropic pour confier des tâches à Claude sur les interfaces prises en charge, comme le bureau, le web et le mobile. Il est conçu pour un travail orienté résultats, dans lequel Claude peut utiliser des fichiers, des outils et des flux de travail connectés, tandis que l’utilisateur examine et approuve les résultats importants.### Pourquoi Claude Cowork sur mobile et sur le web est-il important ?L’accès mobile et web facilite le suivi et la poursuite des tâches d’agent en dehors de l’environnement de bureau. Le changement le plus important est que le travail des agents devient plus asynchrone, ce qui signifie que les équipes ont besoin de règles plus strictes en matière d’autorisations, de révision, de journaux etvalidation.### 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, la mémoire, les journaux, la validation et l’approbation humaine. Il transforme un modèle de simple générateur de texte en un système de flux de travail contrôlé.### La confirmation mobile suffit-elle pour garantir la sécurité d’un agent ?Non. La confirmation mobile est utile, mais elle ne devrait approuver que des actions clairement délimitées. Les actions sensibles, comme l’envoi de messages externes, la modification de systèmes de production, la suppression de données ou le changement d’autorisations, devraient toujours nécessiter une révision explicite et des règles d’approbation bien définies.### Comment une équipe de développement devrait-elle utiliser les agents d’IA en toute sécurité ?Commencez par des tâches limitées, des limites de contexte claires, des diffs vérifiables, des résultats de test et des conditions d’arrêt. Évitez de donner un accès large aux dépôts, aux identifiants, aux données clients ou aux systèmes de production, sauf s’il existe un solide processus d’approbation.### Que devrait renvoyer un agent après une tâche de développement ?Une sortie utile d’un agent de développement devrait inclure les fichiers modifiés, un résumé du diff, les résultats des tests ou de la compilation, les risques connus et tout travail de suivi. Cela accélère la révision et réduit le risque d’erreurs cachées.### Comment les équipes peuvent-elles comparer Claude Cowork, Codex, Cursor, Copilot et d’autres agents ?Utilisez de vraies tâches issues de votre propre flux de travail et exécutez chaque outil selon les mêmes critères d’acceptation. Comparez le taux d’achèvement, le coût de révision, le type d’échec, les preuves fournies dans la sortie, le coût en tokens et l’effort de restauration, plutôt que de juger uniquement à partir d’une seule démonstration.## Outils associés- Claude Cowork : Flux de travail agentique d’Anthropic pour attribuer des tâches à Claude sur les appareils et surfaces de travail pris en charge.
- Claude Code : Agent de développement d’Anthropic pour les flux de travail de développement en terminal et dans les IDE.
- OpenAI Codex : Agent de développement d’OpenAI pour créer, modifier, réviser et livrer des logiciels avec l’assistance de l’IA.
- GitHub Copilot : Assistant de développement IA de GitHub pour les suggestions de code, le chat, les revues et les flux de travail des développeurs.
- Cursor : Environnement de développement assisté par IA axé sur l’édition consciente de la base de code, le chat et le développement logiciel de type agentique.
- Amazon Bedrock AgentCore : Infrastructure AWS pour créer, déployer et exploiter des agents d’IA à grande échelle.## Liens associés- Article original de NxCode : L’article source qui a inspiré cette version publiée en anglais.
- Page produit Claude Cowork : Page officielle présentant les capacités de Claude Cowork, les surfaces prises en charge et la disponibilité selon les forfaits.
- Utiliser Claude Cowork en toute sécurité : Guide de sécurité d’Anthropic concernant les autorisations, les sessions à distance, l’injection de prompts et la supervision humaine.
- Disponibilité générale d’Amazon Bedrock AgentCore Harness : Annonce d’AWS sur une infrastructure gérée de harnais d’agent.
- Ingénierie des harnais pour l’auto-amélioration : discussion de Lilian Weng sur l’ingénierie des harnais et l’amélioration des systèmes d’IA.
- OpenAI Codex Developers : page officielle destinée aux développeurs pour Codex en tant qu’agent de programmation.
- Unrolling the Codex Agent Loop : explication technique d’OpenAI sur la manière dont Codex orchestre les appels au modèle, les outils, les invites et le contexte.## RésuméLe fait que Claude Cowork soit disponible sur ordinateur, sur le web et sur mobile constitue une mise à jour produit utile, mais sa véritable signification est plus profonde. Les agents d’IA deviennent des systèmes de tâches persistants capables de continuer à travailler en dehors d’une seule fenêtre de discussion.Pour les équipes, la bonne réponse n’est pas de donner aux agents une liberté illimitée. La voie la plus sûre est une délégation contrôlée : périmètre de tâche restreint, autorisations explicites, résultats vérifiables, journaux persistants, commandes de validation et approbation humaine pour les actions sensibles.Un harnais d’agent solide rend l’agent plus facile à approuver, car il rend le travail visible et auditable. Commencez par de petites tâches, mesurez les performances sur des flux de travail réels et n’élargissez les autorisations que lorsque le processus de révision est suffisamment robuste.L’avenir du travail des agents ne repose pas seulement sur des modèles plus intelligents. Il repose sur une meilleure conception du harnais autour des modèles.
