Le changement principal
Claude Cowork est un mode de travail agentique disponible dans l’application de bureau Claude (téléchargeable sur claude.com/download, onglet Cowork entre Chat et Code, compte Pro à 20 $/mois minimum).
Sa spécificité : il ne répond pas avec une seule instance de Claude, mais orchestre plusieurs sessions parallèles qui collaborent sur une même demande. Une tâche peut durer plusieurs minutes, parfois plus de trente, pendant lesquelles Cowork planifie, recherche, exécute et livre sans intervention supplémentaire.
La méthode de configuration longtemps considérée comme la référence reposait sur une architecture de fichiers et de dossiers locaux : un dossier Cowork contenant des sous-dossiers ABOUT ME (fichiers about-me.md, my-company.md, anti-ai-writing-style.md), OUTPUTS et TEMPLATES, sélectionné au démarrage de chaque session. Cette approche fonctionne pour un usage individuel, mais elle se brise dès qu’une équipe doit collaborer, et elle génère deux défauts structurels même en solo.
Le modèle de remplacement tient en deux briques natives : les Skills et les Projects. Rien d’autre. L’enjeu est double : éliminer la pollution de contexte et le coût de maintenance des fichiers, et rendre le dispositif partageable en équipe.
Pourquoi l’architecture fichiers-dossiers échoue
Deux défaillances apparaissent après des mois d’usage intensif.
Les dossiers fuient. Même avec une instruction explicite du type « ne consulte jamais mon dossier de sorties », Cowork lit parfois le dossier OUTPUTS. Le contexte de travail se retrouve pollué par des livrables obsolètes, ce qui dégrade la qualité des réponses de manière invisible.
Les fichiers sont impossibles à maintenir. Un fichier de contexte personnel exige des mises à jour manuelles régulières. Agréable au début, cette discipline devient un goulot d’étranglement pour quiconque a une activité à temps plein. Le fichier vieillit, le contexte se périme, et le système censé faire gagner du temps en consomme.
À l’échelle d’une équipe de plusieurs centaines de personnes, ces deux défauts rendent le système inopérant : un dossier local sur un ordinateur ne se partage pas, ne se synchronise pas, ne se gouverne pas.
Skills : des capacités portables et invocables
Une Skill est une capacité que l’on appelle explicitement dans n’importe quelle conversation via une commande slash (par exemple /linkedin-post). Elle transporte avec elle ses instructions et ses données. Propriété notable : une skill voyage aussi vers d’autres IA (Gemini, ChatGPT).
Une skill peut embarquer des volumes importants de données — certaines contiennent des centaines de pages de posts, d’accroches ou de procédures — que Claude traite à chaque invocation, uniquement pour cette skill. Le contexte lourd devient ainsi scopé et à la demande, au lieu d’être permanent et ambiant.
Trois voies de création :
1. La skill native /skill-creator. Claude pose des questions, on y répond, on teste, on sauvegarde, puis on invoque avec la commande /. Depuis un exemple concret (un modèle de contrat en PDF, par exemple), la skill capture le style, la structure et les clauses types, et produit un livrable prêt à signer.
2. L’outil externe www.makemyskill.com. Gratuit, sans version payante, il génère une skill à partir d’une description en langage naturel, en s’appuyant sur une recherche web plus approfondie que celle de Claude. Le bouton « Download skill » livre le fichier à installer.
3. La conversion d’une conversation existante. Depuis le nom du chat, en haut de l’écran, l’option « Turn into skill » (ou la demande « make it a skill ») transforme le travail déjà accompli en skill réutilisable.
L’installation passe par Claude Cowork > Customize > Skills > Add > Upload a skill. Le fichier .md doit contenir le nom et la description de la skill au format YAML ; un .zip ou .skill doit inclure un SKILL.md.
Point de vigilance : une skill peut se déclencher d’elle-même si sa description correspond au contexte de la conversation, sans invocation explicite.
Projects : des espaces de contexte persistants et partageables
Un Project est un lieu où l’on se rend, par opposition à une capacité que l’on appelle. Les fichiers et les instructions y restent chargés en permanence, le contexte s’y accumule au fil du temps, et l’ensemble se partage avec une équipe comme un espace de collaboration unique.
Création : menu de gauche > Projects > New project, avec trois options
- partir de zéro (nouveau dossier avec instructions et fichiers)
- importer un projet existant depuis Chat
- ou utiliser un dossier déjà en place.
Chaque conversation ouverte dans un Project hérite de l’intégralité de son contexte, sans contaminer les autres projets ni les conversations extérieures.
Configuration recommandée : laisser les instructions du Project vides et ne s’appuyer que sur les fichiers.
Limite connue : le nombre de fichiers par Project est plafonné.
L’arbitrage entre Skill et Project
Le critère de répartition est simple : ce qui peut s’enseigner à quelqu’un est une Skill ; ce qui constitue un contexte spécifique — un client, une campagne — est un Project.
La combinaison optimale consiste à invoquer des skills récurrentes à l’intérieur d’un Project client, en y ajoutant des connecteurs (Gmail, Slack) pour alimenter le contexte en données réelles.
Cet arbitrage s’étend aux trois modes de l’application :
- Chat pour une question rapide sans livrable
- Claude Code pour un livrable logiciel
- Cowork pour tout ce qui prend la forme d’un document — présentations, analyses, travail client.
La configuration minimale comme principe
Contre-intuitivement, l’absence de réglages est le meilleur réglage. Un excès de contexte permanent enferme les réponses dans les mêmes schémas : acceptable pour une tâche répétitive comme un contrat type, néfaste pour tout travail créatif ou exploratoire.
Configuration cible : des settings quasi vides, des instructions globales sans contexte personnel, toutes les options désactivées à l’exception des Connecteurs, artifacts et graphiques activés. Côté modèles : Opus par défaut pour les tâches complexes (avec extended thinking réservé aux cas difficiles), Sonnet ou Haiku pour les tâches simples, et Fable dès sa disponibilité pour les cas les plus exigeants.
AskUserQuestion : inverser le sens de l’interrogation
La technique la plus rentable consiste à demander à Claude de mener l’interview avant d’exécuter : « Interroge-moi une question à la fois en utilisant AskUserQuestion, puis construis. » Claude présente alors un formulaire à choix multiples qui structure la collecte du besoin.
Ce mécanisme s’utilise en boucle, autant de fois que nécessaire, jusqu’à saturation du contexte utile. Il remplace avantageusement le prompt long rédigé à l’aveugle : un dossier bien structuré bat un prompt astucieux, et une interview bien menée bat les deux.
Sortir les livrables du système : l’export direct
Les fichiers produits localement par Cowork n’ont pas vocation à être ouverts sur la machine. Chaque livrable — classeur Excel, document, présentation — part directement vers Google Drive via le bouton d’intégration. Le fichier local disparaît ainsi du périmètre visible par Claude, ce qui supprime par construction le risque de pollution du contexte par d’anciennes sorties.
Pour les demandes de classeurs, un gabarit de prompt structuré améliore nettement le résultat : préciser l’objectif (Purpose), les feuilles attendues (Sheets needed), le formatage souhaité, et exiger que Claude liste ses dix principales hypothèses avant de construire.
La voix comme accélérateur d’entrée
Le facteur limitant du travail avec Cowork est humain : la frappe plafonne autour de 60 mots par minute, la parole atteint 150.
La dictée vocale (via l’outil Wispr Flow) s’insère à trois moments :
- le prompt initial
- les réponses personnalisées aux formulaires AskUserQuestion
- et les retours ou réorientations en cours de tâche.
Bénéfice secondaire : parler produit spontanément plus de contexte et un flux de pensée plus riche qu’un texte tapé.
Discipline de tokens : les mécaniques d’économie
Claude relit l’intégralité de l’historique à chaque tour de conversation : le trentième message coûte environ trente et une fois le premier. Une mesure indépendante attribue 98,5 % de la consommation de tokens à cette relecture d’historique. Six mécaniques en découlent :
1. Redémarrer plutôt qu’enchaîner. Utiliser « Restart from here » ou l’édition du prompt initial plutôt que d’empiler les messages de suivi.
2. Session fraîche tous les vingt messages environ. Faire résumer l’état, copier, coller dans une nouvelle session.
3. Batcher les demandes en un seul message plutôt qu’en une série de requêtes séparées.
4. Router les modèles selon la difficulté: Sonnet ou Haiku pour le simple, Opus et l’extended thinking pour le complexe uniquement.
5. Transformer le fichier de contexte personnel en skill invocable à la demande : le contexte n’est chargé que lorsqu’on l’appelle, au lieu de peser sur chaque session par défaut.
6. Étaler l’usage sur la fenêtre glissante de cinq heures qui régit les quotas.
Mise en pratique
1. Installer l’application de bureau depuis claude.com/download, activer un compte Pro, ouvrir l’onglet Cowork.
2. Vider les réglages : instructions globales sans contexte, options désactivées sauf Connecteurs, artifacts et graphiques.
3. Recenser ses tâches récurrentes enseignables et les convertir en skills — via /skill-creator depuis un exemple, via www.makemyskill.com depuis une description, ou via « Turn into skill » depuis une conversation réussie.
4. Convertir le contexte personnel (profil, entreprise, style d’écriture) en une skill dédiée, invoquée uniquement quand elle est utile.
5. Créer un Project par client ou par chantier, y déposer les fichiers de référence, laisser les instructions vides, brancher les connecteurs pertinents.
6. Systématiser deux réflexes de session : ouvrir par une demande d’interview AskUserQuestion, clore par un export direct vers Google Drive.
7. Appliquer la discipline de tokens : batcher, redémarrer plutôt qu’enchaîner, changer de session régulièrement, router les modèles.
8. Réserver vingt minutes bloquées pour réaliser cette bascule en une fois plutôt que par retouches dispersées.
Le principe décisif
Le contexte doit être scopé et invoqué, jamais permanent et ambiant. Toute l’architecture en découle : les Skills portent les capacités et leurs données lourdes, chargées uniquement à l’appel ; les Projects portent les contextes spécifiques, isolés les uns des autres et partageables en équipe ; les réglages globaux restent vides ; les livrables sortent immédiatement vers Google Drive ; les sessions restent courtes et les demandes groupées.
L’erreur principale à proscrire est le dossier local permanent avec ses fichiers de contexte à maintenir : il fuit, il vieillit, il coûte, et il ne se partage pas. La méthode correcte tient en une phrase : des skills pour ce qui s’enseigne, des projects pour ce qui se contextualise, une interview AskUserQuestion pour cadrer, un export Drive pour livrer, et une discipline de tokens pour durer.