Les projets : votre contexte persistant

Observez ce que font la plupart des utilisateurs de Claude au bureau : chaque matin, ils ouvrent une nouvelle conversation et recommencent le même rituel. Ils expliquent qui est leur entreprise, ce qu’ils y font, quelles conventions de ton s’appliquent, quels documents font référence. Dix minutes de mise en contexte avant la première vraie question, et le lendemain tout est à refaire. Les projets règlent exactement ce problème : un espace où vos instructions et vos documents de référence persistent, et que chaque conversation ouverte dans cet espace utilise automatiquement. Le contexte cesse d’être un préambule qu’on récite ; il devient un acquis. À la fin de cette leçon, vous saurez découper vos projets, écrire des instructions qui tiennent, et décider ce qui va dans le projet ou dans la conversation.

Les projets existent sur tous les forfaits (cinq au maximum en Free). Un projet réunit des instructions, une base de connaissances (fichiers de 30 Mo au plus, ou documents Google Drive), une mémoire propre au projet, et les conversations qui en héritent. Sur les forfaits payants, quand les connaissances dépassent la fenêtre de contexte, Claude passe en mode recherche (RAG) et ne charge que les passages utiles : la capacité du projet est multipliée jusqu’à dix.

Comment découper : par sujet récurrent, pas par service

L’erreur classique consiste à créer un grand projet « Marketing » ou « Direction commerciale » qui finit par tout contenir et ne rien cadrer : les instructions y deviennent vagues à force de vouloir couvrir tous les cas. La bonne unité, c’est le sujet récurrent, le dossier sur lequel vous revenez semaine après semaine avec les mêmes conventions et les mêmes référentiels. Concrètement : un projet par client important, où vivent l’historique de la relation, le contrat et les conventions de ton propres à ce compte ; un projet par processus qui se répète (réponses aux appels d’offres, revues mensuelles, recrutement), parce qu’un processus a des règles stables qui méritent d’être écrites une fois ; un projet par produit, qui rassemble argumentaires, objections connues et fiches techniques. Le test est simple : si deux conversations du même projet exigent des consignes contradictoires, le projet couvre deux sujets, et il faut le scinder.

Écrire de bonnes instructions de projet

Les instructions fixent, une bonne fois, la manière dont Claude doit se comporter dans ce contexte. Un texte court, mais qui se travaille. Exemple complet pour un projet « Appels d’offres » d’une équipe commerciale :

« Tu assistes l’équipe commerciale de [entreprise], spécialisée en [domaine]. Dans ce projet, nous répondons à des appels d’offres publics et privés. Conventions : vouvoiement, ton sobre et factuel, aucune promesse hors catalogue, toujours signaler les exigences du cahier des charges que nous ne couvrons pas. Quand je te donne un cahier des charges : commence par un tableau exigences/notre couverture/écarts, avant toute rédaction. Nos références citables figurent dans le document “références-clients.pdf” joint au projet. N’en invente jamais d’autres. »

Trois traits font la qualité de ces lignes. Des conventions explicites : le ton est fixé, et surtout les interdits le sont ; Claude n’aura pas à deviner ce que votre organisation considère comme une faute. Un comportement par défaut : face à un cahier des charges, le tableau d’analyse vient avant toute rédaction ; c’est devenu le réflexe du projet. Une frontière factuelle : les références citables sont celles du document joint, et rien d’autre. Cette dernière ligne ferme la porte à l’invention là où elle coûterait le plus cher, dans un document contractuel envoyé à un prospect. Le cours officiel Claude 101 recommande la même recette : contexte, processus, ton, exigences.

Ce qu’on joint au projet, et ce qu’on n’y joint pas

Les documents du projet obéissent à une logique de durée de vie. Joignez les référentiels stables : la trame type de réponse, la grille tarifaire, la charte éditoriale, l’organigramme. Ce sont les documents que chaque conversation du projet a besoin de connaître, et qui changent rarement. En revanche, les documents du jour, le cahier des charges reçu ce matin, le brouillon en cours, se joignent à la conversation, pas au projet : ils concernent un cas, pas le sujet, et restent hors de la base de connaissances. Un référentiel qui évolue tous les mois se met à jour dans le projet une fois par mois, et toutes les conversations en bénéficient aussitôt. Nommez les fichiers de façon descriptive (« Grille-tarifaire-2026-T4.pdf » plutôt que « doc1.pdf ») : Claude s’appuie sur les noms pour retrouver la bonne information, et vous pouvez les citer dans vos questions.

En équipe : partager le projet

Sur Team et Enterprise, un projet se partage avec des personnes nommées, une liste d’adresses ou toute l’organisation, selon trois niveaux : peut voir (consulter et discuter), peut modifier (changer instructions et connaissances, gérer les membres) et propriétaire. C’est le moyen le plus simple de diffuser une pratique : le projet « Appels d’offres » ci-dessus, partagé en lecture, met toute l’équipe au même niveau de conventions sans réunion de formation. Les propriétaires de l’organisation peuvent restreindre le partage.

Mettre le système en route

Le meilleur point de départ, c’est votre tâche récurrente la plus fréquente. Créez un projet pour elle, écrivez une dizaine de lignes d’instructions portant les trois traits (conventions, comportement par défaut, frontière factuelle), joignez deux documents de référence et testez sur un cas réel. Les instructions s’affinent ensuite à l’usage, selon une règle : dès qu’une réponse vous oblige à répéter une consigne déjà donnée dans une conversation précédente, cette consigne a sa place dans les instructions. En quelques semaines, le projet cesse d’être un dossier de rangement pour devenir un collaborateur qui connaît déjà le dossier quand vous ouvrez la conversation. Et si la consigne porte sur une procédure plutôt que sur un dossier, c’est un skill qu’il vous faut (leçon 7).

À vous de jouer

1. Créez le projet de votre tâche récurrente la plus fréquente, avec dix lignes d’instructions : relisez-les et cochez les trois traits.
2. Joignez deux référentiels stables, nommés clairement, puis lancez une conversation sur un cas réel en joignant le document du jour à la conversation, pas au projet.
3. Posez une question qui exige de citer un des référentiels par son nom. La frontière factuelle tient-elle ?
4. Sur Team ou Enterprise : partagez le projet en « peut voir » à un collègue et demandez-lui son retour sur les instructions.

Sources officielles : Introduction to projects (Claude Academy) · Qu’est-ce qu’un projet ? · Limites des fichiers de projet · Mémoire des projets

Points clés à retenir

• Un projet = un sujet récurrent, avec instructions, connaissances et mémoire persistantes ; cinq projets en Free, RAG jusqu’à 10× sur les forfaits payants.
• Bonnes instructions : conventions explicites, comportement par défaut, frontières factuelles.
• Dans le projet, les référentiels stables, bien nommés ; dans la conversation, les documents du jour.
• Toute consigne que vous répétez deux fois doit remonter dans les instructions ; une procédure devient un skill.
• Sur Team et Enterprise, partagez le projet : voir, modifier, propriétaire.