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, parce que chaque conversation repart de zéro. Les Projets règlent exactement ce problème : ils créent un espace où vos instructions et vos documents de référence persistent, et que chaque nouvelle conversation ouverte dans cet espace utilise automatiquement. Le contexte cesse d’être un préambule qu’on récite ; il devient un acquis.

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

La première question qui se pose est celle du découpage. 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, cela donne un projet par client important, où vivent l’historique de la relation, le contrat et les conventions de ton propres à ce compte. Cela donne aussi un projet par processus qui se répète — les réponses aux appels d’offres, les revues mensuelles, le recrutement — parce qu’un processus a par définition des règles stables qui méritent d’être écrites une fois. Et cela donne un projet par produit, qui rassemble argumentaires, objections connues et fiches techniques. Le test est simple : si deux conversations dans le même projet exigent des consignes contradictoires, c’est que le projet couvre deux sujets, et qu’il faut le scinder.

Écrire de bonnes instructions de projet

Les instructions d’un projet fixent, une bonne fois, la manière dont Claude doit se comporter dans ce contexte. C’est un texte court, mais il se travaille. Prenons un exemple complet, celui d’un projet « Appels d’offres » pour 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. »

Regardez ce que ces quelques lignes accomplissent, parce que trois traits distincts y font la qualité. D’abord, des conventions explicites : le ton est fixé, et surtout les interdits le sont — aucune promesse hors catalogue, signalement obligatoire des écarts. Claude n’aura pas à deviner ce que votre organisation considère comme une faute. Ensuite, un comportement par défaut : face à un cahier des charges, le tableau d’analyse vient avant toute rédaction. Vous n’aurez plus à le redemander ; c’est devenu le réflexe du projet. Enfin, une frontière factuelle : les références citables sont celles du document joint, et rien d’autre. Cette dernière ligne est peut-être la plus précieuse, parce qu’elle ferme la porte à l’invention là où elle coûterait le plus cher — dans un document contractuel envoyé à un prospect.

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. La conséquence pratique : 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, au lieu que chacun travaille sur la version qu’il a sous la main.

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 en vérifiant qu’elles portent bien les trois traits vus plus haut — conventions, comportement par défaut, frontière factuelle — puis joignez deux documents de référence et testez sur un cas réel. Les instructions s’affinent ensuite à l’usage, et le critère d’affinage tient en une règle : dès qu’une réponse vous oblige à répéter une consigne que vous aviez déjà donnée dans une conversation précédente, cette consigne a sa place dans les instructions du projet. En quelques semaines de ce régime, le projet cesse d’être un dossier de rangement pour devenir ce qu’il doit être : un collaborateur qui connaît déjà le dossier quand vous ouvrez la conversation.

Points clés à retenir

• Un projet = un sujet récurrent, avec instructions et documents persistants
• Bonnes instructions : conventions explicites, comportement par défaut, frontières factuelles
• Dans le projet, les référentiels stables ; dans la conversation, les documents du jour
• Toute consigne que vous répétez deux fois doit remonter dans les instructions
• Les projets transforment Claude en collaborateur qui connaît déjà le dossier