La plupart des gens utilisent Claude comme une barre de recherche.
Chaque session commence de la même manière. Vous êtes un rédacteur marketing. Mon entreprise est ceci. Mon public est cela. Maintenant, écrivez-moi le texte. Puis vous fermez l'onglet, et le lendemain vous recommencez tout le briefing depuis le début, formant le même employé chaque matin et le laissant tout oublier le soir venu.
Ce n'est pas un workflow. C'est repartir de zéro, pour toujours.
Les Projets Claude corrigent cela, et presque personne ne les configure correctement. La plupart des gens créent un projet, collent une ligne d'instructions, déposent un PDF au hasard, et se demandent pourquoi ce n'est pas radicalement mieux qu'une discussion normale. La puissance est réelle, mais elle réside dans les détails que l'écran de configuration n'explique pas.
Voici le cours complet sur la configuration des Projets Claude, comme le font les personnes qui les utilisent réellement au quotidien. Chaque fonctionnalité ici est réelle et actuelle. À la fin, vous aurez un projet qui charge automatiquement un contexte complet dans chaque conversation, qui n'aura jamais besoin d'être re-briefé, et qui produira un résultat qui vous ressemble, plutôt qu'à un assistant générique.
Ce qu'est réellement un Projet
Enlevez le marketing et un Projet Claude est trois choses regroupées dans un espace de travail persistant.
Des instructions personnalisées. Une invite au niveau du système qui s'applique automatiquement à chaque conversation au sein du projet. C'est le brief permanent qui façonne le comportement de Claude, à qui il pense parler, et quelles règles il suit, sans que vous ayez à taper quoi que ce soit dans le chat.
Une base de connaissances. Des fichiers et documents auxquels Claude peut se référer dans chaque conversation, toujours disponibles, sans jamais avoir besoin d'être réimportés. Guides de style, spécifications, travaux antérieurs, documents de référence.
Des conversations cloisonnées. Tous les chats du projet sont regroupés et héritent des mêmes instructions et connaissances.
Une chose importante à comprendre d'emblée, car elle fait souvent trébucher les gens. Les conversations au sein d'un projet ne PARTAGENT PAS l'historique des messages entre elles. L'état partagé, ce sont les instructions et les fichiers, pas les chats. Chaque nouvelle conversation démarre avec seulement ces deux éléments chargés. Cela a son importance pour la façon dont vous concevez tout ce qui suit.
Les Projets sont disponibles sur tous les forfaits Claude, y compris gratuit, bien que les utilisateurs gratuits soient limités à cinq projets et que les instructions de projet soient spécifiquement une fonctionnalité payante. Sur les forfaits Pro, Max et Team, vous bénéficiez de la configuration complète.
L'erreur que presque tout le monde commet
Avant la configuration, comprenez l'erreur la plus courante, car l'éviter représente l'essentiel du travail.
Les gens traitent la base de connaissances comme un casier de rangement. Ils y mettent tout. Le manuel de marque entier. Six mois de notes de réunion. Un deck de stratégie de quarante pages. La logique semble solide. Plus de contexte équivaut à de meilleurs résultats.
Cela ne fonctionne pas comme ça, et voici pourquoi. Les connaissances du projet ne sont pas entièrement chargées dans chaque réponse. Claude extrait le contenu le plus pertinent pour chaque requête via la récupération. Lorsque vous surchargez la base de connaissances avec du matériel peu pertinent, vous diluez la capacité de Claude à trouver le signal qui compte vraiment, et vous risquez de remplir la fenêtre de contexte avec des fichiers, laissant moins de place pour la conversation réelle.
La règle qui produit des résultats nettement meilleurs est à l'opposé de ce que les gens attendent. Gardez chaque document de connaissance concis et spécifique, environ une à trois pages. Un guide de voix de marque de trois pages bat un manuel de marque de quarante pages à chaque fois, car le signal utile est plus dense et le bruit est plus faible. La précision l'emporte sur le volume dans la base de connaissances, toujours.
Étape 1 : Créer le projet avec une intention réelle
Ouvrez Claude, cliquez sur Projets dans la barre latérale, cliquez sur Nouveau projet.
Le nom est plus important qu'il n'y paraît. Nommez-le spécifiquement. "Newsletter" ou "Propositions Clients" ou "Documentation API", pas "Travail" ou "Trucs". La raison est que vous finirez par avoir plusieurs projets, et le but même est la séparation. Un nom vague mène à un projet vague qui accumule lentement des éléments sans rapport, ce qui est exactement le problème de dilution mentionné ci-dessus.
Cela mène au premier principe que la plupart des gens oublient. Un projet par domaine. Ne mettez pas votre code backend et votre contenu marketing dans le même projet. Ne mélangez pas le client A et le client B. Des projets séparés signifient un contexte plus propre et plus ciblé, et un contexte ciblé est la raison même pour laquelle les projets fonctionnent. L'instinct d'avoir un méga-projet pour tout est l'instinct de recréer le chatbot générique que vous essayiez de fuir.
Étape 2 : Rédiger les instructions comme un brief permanent, pas comme une invite
C'est la partie la plus importante de toute la configuration, et c'est là que l'écart entre un projet faible et un excellent est le plus grand.
Un bloc d'instructions faible dit "Vous êtes un assistant utile qui rédige du contenu marketing." Cela ne donne à Claude rien qu'il ne possédait déjà.
Un bloc d'instructions solide est un brief permanent complet rédigé pour quelqu'un qui ne sait encore rien de vous, car c'est exactement la situation au début de chaque nouvelle conversation dans le projet. Il doit couvrir qui vous êtes et ce que vous faites, les tâches principales pour lesquelles ce projet existe, vos préférences de ton et de style, votre format de sortie requis, les connaissances du domaine que Claude doit supposer, et surtout, les choses que Claude ne doit jamais faire.
Voici un modèle de structure qui fonctionne pour presque tous les types de projets :
RÔLE
Vous êtes [rôle spécifique] travaillant sur [domaine spécifique]. Vous écrivez pour
[public spécifique qui ne sait rien de vous].
À QUOI SERT CE PROJET
Les tâches principales ici sont [tâche 1], [tâche 2], [tâche 3]. Supposez que chaque demande
concerne l'une d'entre elles, sauf indication contraire.
COMMENT RÉPONDRE
Ton : [spécifique]. Format : [spécifique]. Longueur : [spécifique].
Ne posez pas de questions de clarification sauf si vous êtes vraiment bloqué. Faites une
hypothèse raisonnable, énoncez-la, et continuez.
CE QU'IL FAUT SUPPOSER
[Faits du domaine, détails du produit, positionnement qui doivent être considérés comme acquis
dans chaque réponse.]
NE JAMAIS
[Choses spécifiques que Claude ne doit jamais faire dans ce projet : clichés d'IA, certaines
affirmations, certains formats, quelles que soient vos règles strictes.]
Cette instruction sur le fait de ne pas poser de questions de clarification mérite d'être soulignée. Par défaut, Claude commence souvent par un tour de "avant de commencer, pouvez-vous m'en dire plus sur..." Pour un projet que vous utilisez quotidiennement, ce préambule est une pure friction. Lui dire de faire une hypothèse raisonnable, de l'énoncer et de continuer supprime les allers-retours et accélère immédiatement chaque session.
Rédigez ces instructions pour le lecteur qui n'a aucun historique avec vous, car chaque nouvelle conversation commence réellement là. Les instructions et les fichiers sont les seules choses qui sont transmises. La mémoire de votre dernière conversation ne l'est pas.
Étape 3 : Construire la base de connaissances avec précision
Maintenant, les fichiers. Rappelez-vous la règle. Concis, spécifiques, une à trois pages chacun. Voici ce qui a réellement sa place dans une base de connaissances bien construite, en prenant l'exemple d'un projet de contenu.
Un guide de voix et de style. Comment vous écrivez. Le rythme des phrases, les mots que vous utilisez, les mots que vous bannissez, la sensation de votre production.
Un document sur le public. Pour qui vous écrivez, ce qui les intéresse, ce qu'ils savent déjà, de quoi ils se méfient.
Un document sur les piliers ou le périmètre. Les sujets ou catégories spécifiques que ce projet couvre, afin que Claude reste dans son domaine.
Un petit ensemble de meilleurs exemples. Trois à cinq de vos meilleurs travaux réels. Cela enseigne par la démonstration bien plus efficacement que par la description. Claude apprend vos modèles à partir d'exemples réels mieux qu'à partir de n'importe quelle quantité d'instructions.
Du matériel de référence spécifique au travail. Notes SEO, spécifications produit, contraintes techniques, tout ce que le domaine exige.
Nommez chaque fichier de manière descriptive. "Guide de Voix de Marque v3", "Feuille de Route Produit T2", "Documentation API Module Paiements", pas "notes" ou "trucs". Des noms descriptifs aident la récupération à trouver le bon document pour la bonne requête, ce qui est le mécanisme même sur lequel vous comptez.
Les limites à connaître. Sur les forfaits Pro, Max et Team, vous pouvez avoir jusqu'à 20 fichiers par projet, 30 Mo par fichier, prenant en charge les PDF, texte, markdown, fichiers de code, CSV et images. C'est suffisant si vous suivez la règle de précision. Si vous atteignez la limite, le problème est presque toujours que vous importez du volume au lieu du signal.
Étape 4 : Tester la récupération avant de lui faire confiance
Voici une étape que presque personne ne fait, et elle sépare ceux qui pensent que leur projet fonctionne de ceux qui savent qu'il fonctionne.
Après avoir importé vos connaissances, ouvrez une conversation dans le projet et testez explicitement si Claude peut récupérer chaque document. Demandez directement :
D'après le Guide de Voix de Marque dans les connaissances du projet, comment dois-je
aborder la phrase d'ouverture d'un article ? Citez les conseils spécifiques que vous utilisez.
Si Claude se réfère avec précision au document, la récupération fonctionne. S'il donne une réponse générique ou ne trouve pas les conseils, quelque chose ne va pas. Peut-être que le fichier n'a pas été traité, peut-être que le nom est trop vague, peut-être que le document est enterré sous trop d'autres. Mieux vaut le découvrir lors d'un test que de réaliser trois semaines plus tard que Claude n'a jamais réellement lu votre fichier le plus important.
Effectuez ce test pour chaque document critique. Cela prend cinq minutes et fait la différence entre un projet dont vous espérez qu'il fonctionne et un projet dont vous savez qu'il fonctionne.
Étape 5 : Choisir le bon modèle par conversation
Un détail que la plupart des gens ignorent complètement. Au sein d'un projet, vous pouvez choisir indépendamment le modèle Claude à utiliser pour chaque conversation. Le projet ne vous enferme pas dans un seul modèle.
Cela a son importance pour le coût et la qualité. Utilisez un modèle plus rapide pour la rédaction de routine au sein du projet, et passez à un modèle plus performant pour les conversations qui nécessitent un raisonnement approfondi ou une synthèse complexe. Même projet, mêmes instructions, mêmes connaissances, moteur différent selon les besoins spécifiques de la tâche. La plupart des gens ne réalisent jamais qu'ils peuvent faire cela et soit paient trop cher en utilisant le meilleur modèle pour tout, soit sous-performent en utilisant un modèle rapide pour tout.
Étape 6 : Utiliser les conversations comme une réflexion, pas seulement comme des tâches
Voici une habitude qui rend silencieusement les projets beaucoup plus puissants au fil du temps.
N'utilisez pas seulement les conversations du projet pour des tâches terminées. Utilisez-les pour réfléchir à voix haute. Travaillez sur un problème, expliquez votre raisonnement, discutez des raisons pour lesquelles vous prenez une décision. Parce que le projet est ciblé et cohérent, ces conversations de réflexion aident Claude à comprendre vos schémas de raisonnement, pas seulement vos schémas de production.
Le résultat est qu'au fil des semaines, Claude, au sein d'un projet bien utilisé, commence à correspondre non seulement à votre format mais aussi à votre jugement. Il suggère des approches qui correspondent à la façon dont vous pensez réellement, car il a vu comment vous pensez dans ce contexte ciblé, pas seulement ce que vous produisez.
Étape 7 : Maintenir le projet, car il n'est aussi à jour que ses fichiers
Un projet n'est pas à configurer et à oublier. Il n'est aussi précis que ce qu'il contient, et des connaissances obsolètes produisent un contexte erroné avec assurance, ce qui est pire que l'absence de contexte.
Adoptez une habitude de maintenance. Lorsque votre positionnement change, mettez à jour le guide vocal. Lorsqu'une spécification est révisée, remplacez l'ancienne. Lorsqu'une stratégie évolue, mettez à jour le document de périmètre. Révisez les instructions de votre projet tous les trimestres, car des instructions écrites il y a six mois peuvent maintenant contredire activement ce que vous faites, et Claude suivra fidèlement la règle obsolète.
Les projets qui restent précieux sont ceux que les gens maintiennent à jour. Ceux qui deviennent silencieusement inutiles sont ceux qui ont été configurés une fois et jamais retouchés pendant que le vrai travail évoluait autour d'eux.
La nouvelle couche : Les Projets Cowork
Bon à savoir, car cela étend considérablement tout ce qui précède. Depuis les mises à jour de 2026, les Projets existent également dans Claude Cowork, l'application agentique de bureau, et cette version ajoute des capacités que les projets basés sur le chat n'ont pas.
Les projets Cowork ajoutent une mémoire ciblée qui persiste entre les sessions, vous pouvez donc dire "construis sur le rapport de la semaine dernière" et Claude sait exactement de quoi il s'agit, sans fuite de ce contexte dans vos autres travaux. Ils ajoutent des dossiers locaux dédiés, afin que le projet lise et écrive de vrais fichiers sur votre machine. Et ils ajoutent des tâches planifiées, afin qu'un projet puisse exécuter automatiquement un travail récurrent selon un rythme que vous définissez.
La logique de configuration est la même que tout ce qui précède. Des instructions claires, des fichiers pertinents et concis, un projet par domaine. Mais le plafond est plus élevé, car un projet Cowork ne se contente pas d'informer les conversations, il exécute un travail sur de vrais fichiers et peut fonctionner selon un calendrier sans vous. Un bon premier geste est de le pointer vers un dossier et de dire :
Lis chaque fichier dans ce dossier. Résume ensuite ce que tu sais sur cet
espace de travail : ce qui s'y trouve, à quoi je l'utilise probablement, et quelles instructions
tu suivras. Si quelque chose n'est pas clair, demande avant de supposer.
Cette seule commande fait apprendre le projet à Claude dès le premier jour, et à partir de là, il se souvient.
Quatre modèles de projets que vous pouvez construire aujourd'hui
La théorie n'est utile que lorsqu'elle devient concrète. Voici quatre configurations de projet qui correspondent directement aux cas d'utilisation les plus courants, chacun avec ce qui va dans les instructions par rapport aux connaissances, afin que vous puissiez copier la structure.
Le Projet Contenu. Les instructions définissent votre rôle en tant que rédacteur pour un public spécifique, votre ton, vos règles de formatage et vos interdictions strictes. Les connaissances contiennent un guide vocal, un persona d'audience, un document sur les piliers et trois à cinq de vos meilleures pièces. C'est le projet qui fait en sorte que tout ce que vous publiez sonne systématiquement comme vous, plutôt que comme un rédacteur différent à chaque fois. Les meilleurs exemples dans la base de connaissances font plus de travail ici que n'importe quelle instruction, car la voix s'attrape, ne s'enseigne pas.
Le Projet Code. Les instructions définissent votre stack, vos conventions, vos modèles préférés et les choses que vous ne voulez jamais voir faites. Les connaissances contiennent un document d'architecture, vos fichiers source clés, vos normes de codage et la documentation API pour tout ce que le projet touche. Pointez Claude vers cela et il cesse de suggérer du code qui combat vos modèles existants et commence à les correspondre. Un projet par codebase, jamais partagé, car mélanger deux codebases est le moyen le plus rapide d'obtenir des suggestions qui ne conviennent à aucune des deux.
Le Projet Client. Un projet par client. Les instructions définissent qui est le client, sa marque, ses préférences et le périmètre de votre travail avec lui. Les connaissances contiennent ses directives de marque, les livrables passés, les notes de réunion distillées à l'essentiel et toutes les contraintes qui lui sont spécifiques. C'est ainsi qu'un opérateur solo ou une agence maintient le contexte de chaque client parfaitement séparé, afin que la voix du client A ne se mélange jamais au travail du client B.
Le Projet Recherche. Les instructions définissent la question ou le domaine que vous étudiez et comment vous souhaitez que les résultats soient structurés. Les connaissances contiennent votre matériel source, vos notes antérieures et votre thèse de travail. Au fur et à mesure que vous l'alimentez, il construit une image d'ensemble, et parce qu'il est ciblé, il ne confond pas cette recherche avec tout autre travail sur lequel vous êtes. C'est ce qu'un projet basé sur le chat fait de plus proche du concept de second cerveau, un corpus de connaissances que vous pouvez interroger et qui reste cohérent car il est isolé de tout ce qui n'est pas lié.
Remarquez le modèle commun aux quatre. Les instructions portent les règles permanentes et le comportement. Les connaissances portent le matériel de référence et les exemples. La séparation est délibérée, et placer le bon contenu dans la bonne couche représente l'essentiel de ce qui fait fonctionner un projet. Une règle sur la façon de se comporter appartient aux instructions. Un document auquel Claude doit se référer appartient aux connaissances. Mélanger les deux, mettre des règles de comportement dans un fichier de connaissances ou coller des documents de référence dans la zone d'instructions, est un moyen silencieux de faire sous-performer un projet sans raison évidente.
La personnalisation en couches que la plupart des gens oublient
Encore une chose à savoir, car elle s'empile sur tout ce qui précède. Les instructions du projet ne sont pas la seule couche de personnalisation de Claude, et comprendre comment elles se combinent vous donne un contrôle plus fin.
Il y a trois couches, et elles s'appliquent toutes en même temps à chaque réponse. Les instructions à l'échelle du compte, définies dans les paramètres de votre profil, s'appliquent à tous les chats, partout, indépendamment du projet. Les instructions du projet s'appliquent uniquement à l'intérieur d'un projet spécifique. Et les styles, définis par chat, ajustent le ton et le format pour cette seule conversation.
La démarche pratique consiste à utiliser chacun pour ce qu'il fait de mieux. Mettez les règles qui s'appliquent à tout ce que vous faites avec Claude, comme vos préférences générales de communication, dans les instructions de profil à l'échelle du compte, afin de ne pas les répéter dans chaque projet. Mettez le contexte et les règles spécifiques au projet dans les instructions du projet. Utilisez les styles pour des ajustements ponctuels lorsqu'une conversation particulière nécessite un ton différent de celui par défaut du projet.
La plupart des gens entassent tout dans une seule couche et perdent ce contrôle. Lorsque vous les séparez correctement, vous cessez de répéter vos préférences universelles dans chaque projet, et les instructions de chaque projet restent concentrées uniquement sur ce qui rend ce projet différent. Cette concentration est, encore une fois, le thème central d'une bonne configuration de projet.
La configuration qui porte réellement ses fruits
Mettez le tout ensemble et voici ce qu'un projet correctement construit vous donne qu'un chat normal ne vous donnera jamais.
Chaque conversation commence avec un contexte complet déjà chargé. Votre voix, votre public, vos règles, votre matériel de référence, tous présents avant que vous ne tapiez un mot. Vous cessez de re-briefer. Vous cessez de repartir de zéro. Vous cessez de former le même employé chaque matin.
Le résultat cesse d'être générique et commence à vous ressembler, car Claude travaille à partir de vos exemples réels et de vos normes réelles, pas d'une ardoise vierge plus une invite précipitée d'une ligne.
Et cela porte ses fruits. La première semaine nécessite de petites corrections pendant que Claude apprend vos modèles à partir des fichiers. À la troisième semaine, il correspond suffisamment à votre approche pour que vous cessiez d'expliquer des choses que vous expliquiez auparavant à chaque fois. Les trente minutes de configuration sont rentabilisées sur des mois.
Voici le résultat honnête. La plupart des gens ne bénéficient jamais de cet avantage, non pas parce que la fonctionnalité est difficile, mais parce qu'ils la configurent en quatre-vingt-dix secondes et n'ont jamais fait les parties qui comptent vraiment. La base de connaissances précise. Le vrai brief permanent. Le test de récupération. L'habitude de maintenance.
Faites ces quatre choses et les Projets Claude cessent d'être un dossier pour vos chats et deviennent la différence entre utiliser Claude comme une barre de recherche et l'utiliser comme un système qui sait déjà exactement qui vous êtes et ce dont vous avez besoin.
Configurez un projet correctement cette semaine. Choisissez le travail que vous faites le plus souvent. Rédigez les vraies instructions. Importez trois documents concis. Testez la récupération. Ensuite, regardez à quel point la prochaine conversation sera différente.
Suivez @cyrilXBT pour les constructions complètes, les modèles d'instructions exacts et les configurations de projet que j'utilise chaque jour.
