Construire un espace de travail fiable pour Claude Cowork

Le point central

La qualité des résultats obtenus avec Claude Cowork dépend moins de la longueur du prompt que de la qualité de l’espace de travail auquel il accède.

Un dossier dépourvu de contexte, de règles et d’organisation oblige Cowork à improviser : il ignore le ton attendu, les informations à ne jamais supposer, les fichiers prioritaires et les critères d’un résultat satisfaisant.

Cowork ne travaille pas seulement à partir d’une instruction saisie dans une zone de texte :

Il peut exploiter les fichiers du projet, les règles de fonctionnement, le contexte professionnel, les préférences de communication, les versions antérieures et les exemples de réussite.

L’enjeu consiste donc à transformer une manière de travailler en un système minimal, explicite et réutilisable.

Le modèle repose sur quatre dossiers, deux fichiers fondamentaux et une instruction courte :

4 dossiers du projet + 2 fichiers fondamentaux + prompt court

Cette organisation évite de repartir de zéro à chaque tâche. Les règles et le contexte restent relativement stables ; seuls les éléments propres au projet changent.

Du prompt isolé au système de travail

Pourquoi un dossier sans contexte produit des résultats génériques

L’enchaînement « ouvrir un dossier, écrire un prompt, espérer un bon résultat » laisse Cowork sans cadre opérationnel. Même si la tâche semble explicite, plusieurs informations peuvent manquer :

• le résultat réellement recherché ;
• le public auquel il est destiné ;
• le ton à employer ;
• les sources qui doivent prévaloir ;
• les hypothèses interdites ;
• les fichiers à consulter en priorité ;
• les critères de qualité ;
• l’emplacement du résultat final.

En l’absence de ces éléments, Cowork complète les vides par improvisation. Il peut alors ressembler à une simple interface conversationnelle disposant d’un accès aux fichiers, alors que son intérêt réside précisément dans sa capacité à travailler au sein d’un environnement structuré.

La réponse n’est donc pas nécessairement un prompt plus long. Le contexte durable doit être déplacé vers des fichiers réutilisables afin que l’instruction ponctuelle ne porte plus, à elle seule, toute la charge d’interprétation.

Installer et ouvrir Cowork

Claude Cowork nécessite Claude Desktop. Le parcours d’accès est direct :

1. Télécharger Claude Desktop depuis https://claude.com/download
2. Installer l’application.
3. Se connecter.
4. Sélectionner Cowork.

Les instructions globales se configurent ensuite depuis :

Profile menu → Settings → Cowork → Add your Global Instructions → Save

Elles définissent le comportement que Cowork doit adopter par défaut dans chaque session.

Vous êtes mon partenaire de travail au sein de cet espace de travail.

Commencez par lire :
1. context/HOW-I-WORK.md
2. system/SYSTEM-RULES.md
3. le dossier correspondant dans projects/

N’exécutez pas immédiatement une tâche si l’objectif, le public cible ou le format de sortie ne sont pas clairs.
Posez d’abord des questions lorsque l’absence de contexte risque d’affaiblir le résultat.

N’inventez pas de faits, de décisions, de dates, de chiffres ou d’autorisations.
Signalez clairement toute incertitude.

Utilisez les fichiers de l’espace de travail comme source principale de référence.
Enregistrez les résultats finaux dans le dossier outputs/.

Ces instructions donnent un point de départ stable : lire les fichiers essentiels, ne pas exécuter prématurément, rendre l’incertitude visible, ne pas inventer d’informations et enregistrer les résultats au bon endroit. Le contexte détaillé vient ensuite de l’espace de travail.

Une architecture minimale en quatre dossiers

Une structure initiale trop vaste crée de la complexité avant même qu’un besoin réel apparaisse. Quatre dossiers suffisent pour commencer :

YOUR-WORKSPACE/
├── system/
├── context/
├── projects/
└── outputs/

Chaque dossier remplit une fonction distincte :

• system/ contient les règles fondamentales, relativement stables ;
• context/ contient le contexte durable, lui aussi relativement stable ;
• projects/ contient les éléments propres aux travaux actifs ;
• outputs/ reçoit les productions générées par Cowork.

Cette séparation distingue ce qui définit durablement la manière de travailler de ce qui varie selon chaque tâche. Les dossiers donnent un emplacement aux informations ; les fichiers indiquent comment les interpréter et les utiliser.

Les deux fichiers fondamentaux

context/HOW-I-WORK.md

Ce fichier décrit la personne au travail : son activité, son raisonnement, son mode de communication et ses critères de qualité. Il peut contenir :

• le type de travail réalisé ;
• les destinataires de ce travail ;
• la manière de réfléchir ;
• la manière de communiquer ;
• les caractéristiques naturelles de l’écriture ;
• les formulations ou pratiques rejetées ;
• la hiérarchie des sources en cas de contradiction ;
• des exemples réels lorsqu’ils sont utiles.

Sa fonction est de fournir un contexte durable. Il évite d’avoir à réexpliquer, pour chaque tâche, ce qui caractérise une production fidèle à la manière de travailler attendue.

system/SYSTEM-RULES.md

Ce fichier définit le comportement opérationnel de Cowork. Il peut préciser :

• les principes fondamentaux d’exécution ;
• les situations dans lesquelles une question doit précéder l’action ;
• la conduite à tenir pendant la réalisation ;
• le traitement de l’ambiguïté ;
• les critères d’un résultat solide ;
• les limites à respecter ;
• la vérification finale à effectuer avant livraison.

La distinction entre les deux fichiers est fonctionnelle :

• HOW-I-WORK.md décrit la manière de travailler et de communiquer ;
• SYSTEM-RULES.md transforme cette description en règles d’action.

Extraire les règles réelles par un entretien

Rédiger directement ces deux fichiers présente un risque : décrire une version souhaitée de sa manière de travailler plutôt que les comportements réellement observables au quotidien. Un entretien permet de partir de faits, d’exemples et de préférences concrètes.

L’entretien doit notamment faire apparaître :

• la manière réelle de travailler et d’écrire ;
• les qualités attendues d’un résultat solide ;
• les défauts qui rendent un résultat peu fiable ;
• les informations que Cowork ne doit jamais supposer ;
• les formes d’assistance réellement utiles ;
• les situations dans lesquelles Cowork doit demander des précisions.

Le processus se répartit en trois blocs :

1. contexte professionnel ;
2. voix, style et raisonnement ;
3. comportement du système et règles d’exécution.

Les questions sont posées une par une. Leur nombre n’est pas fixe et ne doit pas dépasser cinquante. Une réponse vague appelle un exemple précis ; une contradiction doit être signalée et résolue ; une aspiration doit être distinguée d’une pratique réelle.

L’entretien doit rechercher des preuves exploitables :

• un paragraphe réellement écrit ;
• une phrase appréciée ;
• une phrase qui ne serait jamais publiée ;
• un exemple de bon ou de mauvais résultat ;
• une décision ou une production réelle.

Il s’arrête dès que les informations recueillies suffisent à produire les deux fichiers. Il ne doit ni flatter ni accumuler des opinions abstraites sans utilité opérationnelle.

L’instruction complète permettant de conduire cet entretien est la suivante :

Vous êtes mon intervieweur dédié à Claude CoWork.

Votre mission consiste à extraire suffisamment d'informations pertinentes et de qualité pour aider à créer deux éléments pour
Claude Cowork :

1. context/HOW-I-WORK.md
2. system/SYSTEM-RULES.md

Votre objectif n'est pas de m'interroger indéfiniment.
Votre objectif est de recueillir suffisamment d’informations spécifiques, concrètes et exploitables pour générer
ces fichiers de manière optimale.

## Objectif de l’entretien

Vous contribuez à définir comment Claude Cowork doit fonctionner avec moi au sein d’un
espace de travail réutilisable.

Cela signifie que vous devez comprendre :

- quel type de travail j’effectue
- ce que je crée habituellement
- pour qui je le crée
- comment je raisonne
- comment j’écris
- ce que j’apprécie dans les résultats de qualité
- ce que je n’aime pas dans les résultats médiocres
- comment je souhaite que Claude Cowork se comporte
- ce que Claude ne doit jamais supposer
- quand Claude doit poser des questions avant d’agir

## Structure de l’entretien

Vous mènerez l’entretien en 3 parties :

### Partie A – Contexte de travail

Utilisez cette partie pour comprendre :

- ce que je fais
- quels types de livrables je crée
- qui est mon public
- ce à quoi ces personnes accordent de l’importance
- quelles sont les sources les plus importantes
- en quoi cet espace de travail devrait m’aider

### Partie B – Ton, style et réflexion

Utilisez cette partie pour comprendre :

- comment je m’exprime au mieux de mes capacités
- comment je m’exprime lorsque j’écris sans y mettre d’effort ou en pilote automatique
- les mots, expressions et structures qui me semblent naturels
- ce que je déteste dans l’écriture
- comment j’organise mes idées
- comment j’aborde les problèmes
- ce que j’ai tendance à remarquer, à mettre en doute ou à mettre en avant
- des exemples concrets d’écrits qui me ressemblent

### Partie C – Comportement et règles du système

Utilisez cette partie pour dé

Traduit avec DeepL.com (version gratuite)

Cette méthode produit des informations réutilisables. Elle évite d’empiler des fichiers sans fonction et de compenser un contexte insuffisant par des prompts toujours plus longs.

Le projet comme seule partie variable

Les deux fichiers fondamentaux restent relativement stables :

system/SYSTEM-RULES.md
context/HOW-I-WORK.md

Les informations variables sont placées dans projects/. Elles peuvent inclure le brief, les notes, les références, les brouillons et tous les fichiers liés à une tâche particulière.

Le principe reste identique pour des travaux différents : article, rapport, présentation, recherche, synthèse, proposition ou revue hebdomadaire. La structure fondamentale ne change pas ; seul le contenu du dossier de projet est remplacé.

Des exemples de dossiers et fichiers sont accessibles ici :

https://drive.google.com/drive/folders/1_dlHpwcUeZa67gQPORVwxFnrObODOQ7h?usp=sharing

Application à une revue de marché

Le dossier peut prendre cette forme :

projects/
└── market-review/
    ├── notes.md
    ├── template/
    ├── references/
    └── drafts/

notes.md rassemble le contexte, les observations, les risques et le résultat attendu :

# Notes sur l'analyse du marché

## Contexte
Nous passons en revue les actions menées par nos concurrents au cours des 30 derniers jours.

## Observations brutes
- Le concurrent A a lancé une offre à prix réduit
- Le concurrent B a simplifié le processus d'intégration
- Le concurrent C publie davantage d'études de cas

## Risques identifiés
- Nous risquons de réagir de manière excessive aux changements de tarification
- Nous ne savons pas encore si ces initiatives génèrent un meilleur taux de conversion

## Ce dont j'ai besoin
Transformez ces informations en une note de décision destinée à un examen interne.

Traduit avec DeepL.com (version gratuite)

references/ accueille les présentations antérieures, rapports sur les concurrents, références comparatives et informations internes utiles à l’interprétation des notes.

drafts/ peut recevoir une première version, une version condensée ou une variante destinée à des décideurs.

Le prompt reste court :

Commence par lire le dossier du projet.
Ensuite, pose-moi tes questions avant de te lancer.
Je veux un dossier de décision, pas un résumé générique.
Enregistre le résultat dans le dossier « outputs/briefs/ ».

La précision décisive réside dans la nature du résultat demandé : une note d’aide à la décision, et non un résumé générique. La production doit établir le contexte de la décision, distinguer les risques des options et aboutir à une recommandation accompagnée d’étapes concrètes.

Application à une revue trimestrielle

Le dossier d’une revue du troisième trimestre peut être organisé ainsi :

projects/
└── q3-review/
    ├── brief.md
    ├── notes.md
    └── template/
        ├── references/
        └── drafts/

Le brief fixe l’objectif, le public, les priorités et les contraintes :

# Synthèse du troisième trimestre

## Objectif
Préparer un rapport de synthèse pour la réunion de la direction.

## Public cible
L'équipe de direction.

## Les points essentiels
- Les changements survenus au cours de ce trimestre
- Les risques à surveiller
- Les décisions qui pourraient s'avérer nécessaires prochainement

## Contraintes
- Rester concis
- Ne pas émettre de spéculations sans les signaler clairement
- Se concentrer sur les implications, et pas seulement sur les activités

Les notes rassemblent les faits marquants et les questions en suspens :

# Notes de bilan du 3e trimestre

## Points forts
- Le chiffre d’affaires est resté stable
- La fidélisation des clients s’est légèrement améliorée
- Deux initiatives ont pris du retard

## Questions en suspens
- Faut-il rééquilibrer les ressources ?
- Ces retards sont-ils d’ordre opérationnel ou stratégique ?

references/ contient les indicateurs, rapports trimestriels précédents, informations financières, synthèses d’équipe et anciennes présentations.

drafts/ reçoit une première version du rapport, une version plus courte, une variante centrée sur les risques ou une structure préparée pour devenir une présentation.

Le prompt peut être formulé ainsi :

Commence par parcourir le dossier du projet.
Applique mes critères de qualité et tiens compte du contexte de travail.
N'hésite pas à me poser des questions avant de rédiger.
Crée ensuite un rapport de synthèse à soumettre pour validation et enregistre-le dans le dossier outputs/reports/

Le résultat attendu ne consiste plus à remettre en ordre des notes dispersées. Il doit faire émerger les indicateurs, les risques et les décisions à discuter.

Application à une présentation stratégique

Une mise à jour stratégique exige une organisation similaire :

projects/
└── strategy-update/
    ├── brief.md
    └── template/
        ├── references/
        └── drafts/

Le brief précise la fonction de la présentation :

# Note d'information sur la mise à jour de la stratégie

## Objectif
Élaborer un plan de présentation pour une réunion de mise à jour de la stratégie.

## Public cible
Dirigeants internes et responsables des différentes fonctions.

## Objectifs de la présentation
- expliquer ce qui a changé
- montrer en quoi cela est important
- mettre tout le monde d'accord sur les prochaines étapes

## Ce que je ne veux pas
- des titres de diapositives sans message
- trop de texte
- un langage de conseil trop générique

Les références peuvent réunir des indicateurs, rapports précédents, informations financières, synthèses d’équipe et anciennes diapositives.

Les brouillons peuvent comprendre une première structure, une version condensée, une variante davantage centrée sur les risques ou un plan prêt à être transformé en diapositives.

Le prompt active les règles et le contexte déjà présents :

Commence par lire le dossier du projet.
Ensuite, pose-moi tes questions avant de te lancer.
Je veux un plan de présentation avec une structure cohérente, des sections bien définieset une description de ce que chaque diapositive doit contenir.
Enregistre-le dans le dossier outputs/drafts/

La production ne doit pas seulement classer les idées. Elle doit transformer un changement stratégique encore flou en narration structurée, avec un rôle explicite pour chaque diapositive.

Le fonctionnement « questions d’abord »

Le fonctionnement « questions d’abord » suit une séquence précise :

1. Cowork lit le dossier du projet.
2. Il repère les informations manquantes.
3. Il pose les questions nécessaires.
4. Il ne construit le résultat qu’après clarification.

L’instruction d’activation peut rester minimale :

Commence par lire le dossier du projet.

Ensuite, pose-moi tes questions avant de te lancer.

Dans une revue de marché, la question peut porter sur la décision réelle à prendre. Dans une revue trimestrielle, elle peut concerner les initiatives et la décision attendue de la réunion. Dans une mise à jour stratégique, elle peut porter sur les chantiers, les prochaines étapes et le format.

Ce fonctionnement est particulièrement adapté lorsque :

• l’objectif n’est pas encore complètement défini ;
• le public influence fortement la forme du résultat ;
• la production a des conséquences réelles ;
• une hypothèse erronée pourrait invalider l’ensemble ;
• plusieurs formats sont possibles ;
• Cowork ne doit pas combler seul les informations manquantes.

Les questions ne constituent donc pas une étape systématique indépendante du besoin. Elles servent à empêcher l’improvisation lorsque l’information absente pourrait affaiblir le résultat.

Pourquoi les prompts peuvent rester courts

Dans une conversation vide, une instruction courte contient rarement assez d’informations. Dans un espace structuré, le contexte est déjà réparti entre :

system/
context/
projects/
outputs/

Le prompt sert alors à activer le système :

Commencez par lire le dossier du projet.
Posez-moi ensuite vos questions avant de vous lancer.
Créez le livrable et enregistrez-le dans le dossier « outputs/ ».

Ou :

Utilisez mes fichiers « HOW-I-WORK » et « SYSTEM-RULES ».
Utilisez ensuite le dossier du projet pour créer une première ébauche dans le dossier « outputs/ ».

La brièveté ne repose pas sur une propriété particulière du prompt. Elle devient possible parce que les règles, le contexte et les informations du projet sont déjà disponibles. Si une instruction doit rester très longue pour faire comprendre les éléments fondamentaux, l’espace de travail ne porte probablement pas encore assez de contexte.

Faire évoluer la structure à partir des répétitions

Deux dérives opposées doivent être évitées : conserver une structure trop pauvre ou construire immédiatement un système démesuré.

Le principe d’évolution consiste à commencer petit et à laisser les tâches révéler les informations manquantes. Un nouveau fichier devient pertinent lorsqu’un motif se répète, et non parce qu’il pourrait éventuellement être utile.

Quand enrichir system/

Une extension devient justifiée lorsque :

• Cowork reproduit régulièrement la même erreur ;
• certaines règles s’appliquent à presque toutes les tâches ;
• les critères de qualité sont devenus plus précis ;
• une manière de travailler doit rester stable d’un projet à l’autre.

Si Cowork confond régulièrement résumé et recommandation, cette distinction doit être ajoutée explicitement dans SYSTEM-RULES.md, éventuellement sous la forme d’une section spécifique.

Quand enrichir context/

Une extension devient pertinente lorsque :

• un public récurrent nécessite son propre fichier ;
• le style d’écriture doit être décrit plus précisément ;
• les références, le ton ou les règles de source de vérité doivent être séparés ;
• la manière de travailler ne tient plus clairement dans un seul fichier.

L’objectif reste de produire un contexte clair et effectivement utilisable, pas d’accumuler des descriptions.

Quand enrichir projects/

Le dossier des projets évolue lorsque :

• un type de tâche utilise toujours les mêmes fichiers ;
• un projet nécessite davantage d’ordre interne ;
• le brief, les notes, les références et les brouillons doivent être mieux séparés ;
• une tâche récurrente possède déjà sa propre logique.

La majorité des évolutions se produit ici, puisque les besoins particuliers varient davantage que les règles fondamentales et le contexte professionnel.

Le critère de croissance utile

Une évolution pertinente doit produire des effets observables :

• moins d’explications nécessaires ;
• moins de corrections ;
• moins de redémarrages ;
• un résultat plus utile dès la première version.

Si ces effets n’apparaissent pas, la structure s’accumule sans améliorer le travail.

Mise en pratique

1. Installer Claude Desktop et ouvrir Cowork. Utiliser https://claude.com/download, puis accéder aux réglages de Cowork.
2. Définir les instructions globales. Imposer la lecture de HOW-I-WORK.md, de SYSTEM-RULES.md et du dossier de projet concerné. Interdire l’invention de faits, décisions, dates, nombres et validations.
3. Créer uniquement les quatre dossiers fondamentaux.

   system/
   context/
   projects/
   outputs/
   

4. Construire les deux fichiers fondamentaux par entretien. Recueillir des comportements réels, des critères précis, des exemples concrets et des limites opérationnelles.
5. Séparer le durable du variable. Placer les règles dans system/, le contexte stable dans context/ et tout ce qui dépend d’une tâche dans projects/.
6. Créer un dossier par projet. Y distinguer, selon les besoins, le brief, les notes, les références, les modèles et les brouillons.
7. Donner au brief une fonction décisionnelle. Préciser le but, le public, les informations prioritaires, les contraintes et les résultats indésirables.
8. Activer le fonctionnement « questions d’abord » lorsque les lacunes sont importantes. Demander à Cowork de lire le dossier avant de poser les questions nécessaires et d’exécuter la tâche.
9. Utiliser un prompt court et ciblé. Indiquer le dossier à lire, la nature exacte de la production, l’éventuelle phase de questions et le répertoire de destination.
10. Faire évoluer la structure seulement après répétition. Transformer en règle ou en fichier autonome ce qui revient régulièrement et produit des erreurs, des corrections ou des explications répétées.
11. Conserver les URLs près de leur fonction. Placer l’adresse de téléchargement près de l’installation, l’adresse des exemples près des structures de projet et l’adresse d’inscription près de la ressource associée : https://artificialcorner.com/subscribe

Le principe décisif

Claude Cowork devient plus fiable lorsque la manière de travailler cesse d’être implicite. Les règles opérationnelles, le contexte professionnel, les critères de qualité et les exemples pertinents doivent exister dans des fichiers que Cowork lit avant d’agir.

La structure minimale comprend quatre dossiers et deux fichiers fondamentaux. SYSTEM-RULES.md fixe le comportement attendu ; HOW-I-WORK.md décrit la manière réelle de travailler, de raisonner et de communiquer ; projects/ contient les éléments variables ; outputs/ reçoit les résultats.

Les fichiers fondamentaux gagnent à être construits par un entretien fondé sur des exemples et des pratiques observables. Chaque projet peut ensuite être déclenché par une instruction courte, puisque le système possède déjà le contexte nécessaire.

La principale erreur consiste à demander au prompt de compenser un espace de travail vide. La méthode correcte consiste à commencer avec une structure réduite, à faire lire le dossier avant toute exécution, à clarifier les lacunes importantes, puis à enrichir le système uniquement lorsqu’une répétition réelle le justifie.