Claude Cowork 2026 passe au cloud : faut-il encore un Mac ?

Symptôme — Vos nouvelles tâches Claude Cowork s’exécutent dans le cloud, mais votre équipe travaille encore avec des fichiers ou des outils présents sur un Mac.

Solution rapide — Classez chaque tâche selon l’emplacement de ses données et de ses outils : une tâche entièrement cloud n’exige généralement pas de Mac dédié à l’exécution, tandis qu’un accès par l’application de bureau ou un MCP local peut encore nécessiter un Mac connecté.

Pour qui ? Les utilisateurs Pro ou Max qui veulent distinguer le sort des nouvelles tâches de celui des tâches locales déjà lancées.
Les administrateurs qui doivent vérifier les dossiers connectés, l’application de bureau et les serveurs MCP locaux.
Les développeurs qui évaluent un environnement Mac durable pour des agents dépendant d’outils locaux.

Dernière mise à jour : 9 octobre 2026. Vérification fondée sur les notices officielles d’Anthropic relatives à l’utilisation de Cowork, à son architecture et à ses règles de sécurité.

Ce que le passage au cloud change réellement

La modification annoncée concerne un cas précis : les nouvelles tâches Cowork des abonnements Pro et Max démarrées à partir du 6 octobre 2026 s’exécutent dans le cloud. La notice officielle distingue ces nouvelles tâches des tâches locales déjà démarrées, qui continuent selon leur mode d’exécution initial. Elle ne permet pas de conclure que toutes les offres, tous les comptes d’organisation et toutes les fonctions ont basculé selon une règle identique. La notice officielle sur l’utilisation de Cowork sur le Web, l’ordinateur et le mobile précise cette portée.

La distinction à retenir n’est donc pas « cloud ou Mac » au sens absolu. Elle porte sur deux opérations différentes : où l’agent exécute son travail et comment il accède à une ressource qui reste sur votre appareil. Une tâche peut être exécutée dans le cloud sans que cela donne automatiquement à l’agent un accès général au disque local, à une application ouverte ou à un serveur qui tourne sur votre Mac.

Ce tableau sert à classer les dépendances, pas à promettre le même comportement dans chaque configuration. La version de l’application, le type de compte et les réglages définis par l’organisation peuvent modifier les possibilités d’accès.

Les anciennes tâches locales sont-elles transférées automatiquement ?

Non : ne partez pas du principe qu’une tâche locale déjà en cours devient une tâche cloud. La notice du 6 octobre indique que les tâches locales commencées auparavant conservent leur mode d’exécution initial. Si vous voulez poursuivre un travail dans le cloud, vérifiez si vous devez créer une nouvelle tâche, préparer ses fichiers accessibles et lui fournir à nouveau le contexte nécessaire. Ne fermez pas l’application ou la session locale avant d’avoir confirmé l’état de la tâche concernée.

Cette nuance compte notamment pour une opération longue, une analyse de fichiers locaux ou un processus de développement dont les résultats intermédiaires ne sont pas enregistrés dans un emplacement accessible à la nouvelle session. Le changement de mode d’exécution n’est pas, à lui seul, une procédure de migration de l’historique et des dépendances.

À retenir : la règle annoncée concerne les nouvelles tâches Pro et Max à partir de la date indiquée. Pour un compte Team ou Enterprise, vérifiez d’abord la documentation de l’offre et les réglages de votre organisation plutôt que d’appliquer automatiquement la règle individuelle. Anthropic décrit séparément Cowork pour Team et Enterprise.

L’accès aux fichiers locaux : le point à tester

Le passage au cloud ne signifie pas que les fichiers de votre Mac sont automatiquement transférés ni que Cowork peut parcourir l’ensemble de votre disque. L’accès dépend des fichiers ou dossiers que vous choisissez de rendre disponibles et du mécanisme utilisé pour relier l’application de bureau à la tâche. Pour une tâche Claude Cowork sur des fichiers locaux, vérifiez donc le périmètre exact exposé à la session, au lieu de supposer que l’agent voit tout ce que vous voyez dans le Finder.

Les explications officielles sur l’architecture de Cowork distinguent la session cloud de l’accès à des ressources locales. Dans un scénario relié au bureau, des fichiers sélectionnés peuvent être transférés ou présentés à l’environnement de travail selon le mode de connexion et les autorisations accordées. Cela ne constitue pas une autorisation générale sur les autres dossiers. L’aperçu de l’architecture de Claude Cowork et les explications d’Anthropic sur l’isolation et les permissions de fichiers sont les références à consulter pour comprendre cette frontière.

Concrètement, examinez le chemin d’accès comme vous le feriez pour un partage de fichiers : quel dossier est relié, quels fichiers sont concernés, quel compte peut y accéder et si l’application de bureau doit rester ouverte. N’ajoutez pas un dossier parent entier par commodité si la tâche ne requiert qu’un sous-ensemble. Pour des ressources de design, d’audio ou de vidéo, séparez les éléments nécessaires à la tâche des bibliothèques, rushes ou exports qui ne doivent pas être exposés.

La disponibilité de fichiers dans une session ne permet pas non plus de déduire leur durée de conservation. Celle-ci dépend des règles applicables au compte et au type de données. Pour ce point, consultez la documentation officielle sur la durée de conservation des données et faites valider par votre responsable les exigences internes de conservation ou de suppression. Évitez de bâtir une procédure sur une durée supposée qui n’est pas confirmée pour votre configuration.

Comment une tâche cloud lit-elle les fichiers locaux ?

Elle ne lit pas spontanément le disque de votre Mac. Vous devez utiliser un chemin d’accès prévu par Cowork, sélectionner les fichiers ou connecter le dossier requis, puis respecter les autorisations associées. Si votre méthode repose sur l’application de bureau, la disponibilité de celle-ci peut être nécessaire pour maintenir le lien avec les ressources locales. Le test le plus utile consiste à lancer une opération autorisée, fermer ou déconnecter le Mac selon une procédure contrôlée, puis observer si la tâche continue à accéder aux fichiers. Si elle échoue, vous avez identifié une dépendance locale, pas un simple problème de performance cloud.

Ne faites pas ce test sur des données sensibles sans avoir validé au préalable les règles de l’organisation. Vérifiez aussi la sortie produite : un fichier traité dans le cloud peut être enregistré à un emplacement différent de celui du fichier source. Pour les livrables de création, distinguez clairement le fichier de travail, les ressources liées et le dossier de sortie attendu.

Le MCP local et les outils du bureau

Le MCP local désigne ici un serveur ou un outil qui s’exécute sur votre ordinateur, par exemple parce qu’il accède à un répertoire, à une application ou à un service interne disponible uniquement depuis ce poste. Le fait qu’une tâche Cowork s’exécute dans le cloud ne déplace pas automatiquement ce processus. Il faut que l’architecture prévoie explicitement un chemin d’accès depuis la session, avec les autorisations et la connectivité nécessaires.

L’aperçu officiel de l’architecture Cowork explique les limites entre session cloud et composants locaux. Un serveur MCP local ne doit donc pas être traité comme un composant cloud simplement parce qu’il apparaît dans votre environnement de travail. À l’inverse, un connecteur MCP distant peut être conçu pour être accessible depuis une session hébergée, mais il s’agit d’un mode de déploiement différent. La documentation officielle des connecteurs personnalisés fondés sur MCP distant vous aide à distinguer ce cas d’un serveur lié à un ordinateur.

Pour chaque extension ou outil, posez une question opérationnelle : la tâche peut-elle terminer son action quand le Mac concerné est éteint, déconnecté du réseau ou sans session de bureau active ? Si vous n’avez pas vérifié ce cas, considérez l’outil comme une dépendance locale. Évitez également de confondre « l’agent peut appeler un connecteur » avec « le connecteur peut atteindre le serveur installé sur le poste d’un utilisateur ». Le second accès implique un chemin réseau et une politique d’autorisation qu’il faut documenter.

Point de contrôle : une intégration n’est pas « sans Mac » tant que vous n’avez pas validé qu’elle fonctionne lorsque l’appareil qui héberge son processus local n’est plus joignable.

Les tâches planifiées exigent la même prudence. Avant d’utiliser les tâches récurrentes de Cowork, contrôlez si leur exécution dépend de ressources accessibles dans le cloud ou d’un pont local qui doit rester disponible. Une planification ne supprime pas une dépendance à un serveur local ; elle peut au contraire rendre plus visible un échec silencieux si personne ne surveille la connexion.

Deux modèles de travail, deux coûts opérationnels

Le cloud simplifie l’exécution de tâches qui n’ont besoin que de ressources accessibles à la session. Il évite alors de réserver un Mac pour faire tourner l’agent en continu. En revanche, si votre processus dépend encore d’un fichier local, d’une application de création ou d’un serveur MCP sur le poste, il faut maintenir et administrer ce point d’accès. Le choix se fait donc sur le coût total du workflow, pas sur le seul lieu d’exécution de l’agent.

Pour un développeur, une tâche de rédaction ou de synthèse sur des documents déjà accessibles peut ne pas justifier un Mac en permanence. Une tâche qui compile un projet local, lit des données présentes uniquement sur le poste ou déclenche une action dans un outil de bureau a une autre exigence. Pour une équipe audio, vidéo ou design, vérifiez aussi où se trouvent les médias lourds et les fichiers de projet liés : un accès limité aux éléments sélectionnés peut convenir à une analyse, mais pas à un processus qui doit retrouver toute une arborescence et ses dépendances.

Le terme Mac dans un workflow cloud ne signifie donc pas nécessairement que le Mac exécute l’agent. Il peut servir de pont vers un dossier ou un outil, ou ne plus être utile une fois les dépendances remplacées par des ressources accessibles à distance. Cette distinction évite deux erreurs coûteuses : maintenir une machine active alors qu’aucune tâche n’en dépend, ou éteindre un poste qui héberge encore un service indispensable.

Procédure de vérification avant migration

Procédez tâche par tâche plutôt que de changer tous les postes et toutes les permissions en même temps. Cette démarche permet d’attribuer un échec à une dépendance précise et de revenir au mode précédent sans interrompre les autres usages.

1. Relevez le mode d’exécution actuel. Pour chaque tâche, indiquez si elle a été lancée localement avant le changement ou si elle est nouvelle et destinée au cloud. Vérifiez l’état des tâches en cours avant de fermer l’application ou de les relancer.

2. Inventoriez les données utilisées. Notez les fichiers, dossiers et emplacements de sortie nécessaires. Séparez les fichiers accessibles dans le cloud de ceux qui restent uniquement sur le Mac. Ne déduisez pas l’accès à un dossier à partir du seul fait qu’un autre fichier du même projet est disponible.

3. Faites l’inventaire des outils. Pour chaque connecteur ou MCP, identifiez où le processus tourne et quelles ressources il peut joindre. Marquez comme dépendance locale tout outil qui ne fonctionne qu’avec un processus présent sur un poste, tant qu’un test n’a pas démontré le contraire.

4. Testez la disponibilité du bureau. Sur une tâche non sensible ou dans un environnement de validation, vérifiez si l’accès aux fichiers et aux outils persiste lorsque l’application de bureau ou le Mac n’est plus disponible. Faites ce test explicitement ; le lancement réussi d’une tâche ne prouve pas que ses étapes ultérieures survivront à une déconnexion.

5. Vérifiez les permissions. Contrôlez quels dossiers ont été reliés, qui peut modifier les réglages et où les résultats sont enregistrés. Pour un appareil administré, faites valider ces points par l’administrateur avant d’élargir l’accès ou de modifier une politique.

6. Confirmez le périmètre du compte. Les éléments annoncés pour Pro et Max ne doivent pas être extrapolés aux comptes Team ou Enterprise. Consultez la documentation correspondant à votre plan et aux contrôles administratifs réellement activés dans votre organisation.

7. Documentez le retour arrière. Gardez une méthode connue pour reprendre le travail si une dépendance locale manque : relancer la tâche sur le poste prévu, fournir les fichiers par un chemin approuvé ou restaurer temporairement le connecteur. Indiquez au responsable de l’équipe quelles tâches restent dépendantes d’un Mac et pourquoi.

La sécurité doit être vérifiée dans le même mouvement que la continuité de service. Les recommandations d’Anthropic sur l’utilisation sécurisée de Cowork invitent à contrôler les actions autorisées et les informations fournies au système. Dans une organisation, ajoutez à ce contrôle vos propres règles de confidentialité, de journalisation, de révocation des accès et de validation des fichiers de sortie. La présence d’une option dans l’interface ne remplace pas l’approbation de la politique interne.

Votre décision selon le travail réel

Vous n’avez besoin que de tâches cloud. Si vos documents et connecteurs sont accessibles sans passer par un Mac, ne maintenez pas un ordinateur allumé dans le seul but d’exécuter les nouvelles tâches Cowork. Conservez une procédure claire pour les fichiers et les sorties, puis surveillez les permissions conformément aux règles de votre compte.

Vous avez besoin de fichiers locaux, mais pas d’un outil de bureau. Évaluez le mécanisme d’accès prévu, les dossiers effectivement exposés et la disponibilité de l’application de bureau. Vous pouvez conserver un chemin Mac pour ces opérations sans en faire une exigence pour toutes les tâches cloud. Si les données peuvent être déplacées vers un espace autorisé par votre organisation, comparez ce changement avec le maintien du pont local.

Vous dépendez d’un MCP ou d’une application locale. Gardez le Mac dans le parcours tant que le processus n’a pas été déplacé vers un service distant et validé depuis la session cloud. Une migration de l’agent ne migre ni le serveur MCP, ni les données, ni les droits réseau. Pour une équipe, formalisez le poste hôte, les permissions et la personne responsable de son fonctionnement.

Vous administrez Team ou Enterprise. Faites vérifier la politique du compte avant de modifier les pratiques des utilisateurs. Le comportement établi pour les nouveaux travaux Pro et Max ne suffit pas à décrire le périmètre de votre organisation. La configuration des accès, la gestion des appareils et les règles internes peuvent avoir leurs propres exigences.

Si votre environnement a encore besoin de macOS, mais que vous ne souhaitez pas réserver un poste personnel aux tâches de test ou à un accès ponctuel, comparez cette contrainte à un Mac disponible à distance. Un Mac local peut être plus simple pour des périphériques physiques ou un travail intensif et stable, mais il implique achat, maintenance et gestion des accès ; une machine distante ajoute une dépendance au réseau et doit être validée pour vos outils. Vous pouvez examiner les options de location de Mac mini et les informations sur Kvmzen si votre workflow exige réellement un environnement macOS accessible à distance. En revanche, si vos nouvelles tâches fonctionnent entièrement dans le cloud, n’ajoutez pas une machine à votre parc uniquement parce que Cowork a changé son mode d’exécution.