Tu utilises Claude depuis quelques mois. Tu connais Projects, tu connais Artifacts, et pourtant tu te retrouves à recoller ton tone of voice dans chaque conversation, ou à perdre un script Python génial parce qu'il est noyé dans un thread de 40 messages. Le problème n'est pas Claude. Le problème est que tu confonds deux features qui ne résolvent pas le même problème.
Cet article tranche : quand ouvrir un Project, quand rester sur un simple Artifact, et comment combiner les deux pour ne plus refaire le même setup trois fois par semaine. Si tu débutes, commence d'abord par le guide complet pour apprendre Claude, puis reviens ici.
Ce que sont vraiment Projects et Artifacts (en une minute)
Un Project, c'est un espace de travail persistant dans Claude.ai. Tu lui attaches des fichiers (PDF, .md, .txt, images), tu lui écris des instructions personnalisées (ton ICP, ta voix, tes règles), et toutes les conversations ouvertes dans ce Project héritent automatiquement de ce contexte. Tu peux y revenir dans trois semaines, le contexte est toujours là.
Un Artifact, c'est un bloc de sortie isolé généré pendant une conversation : du code, un document markdown, une page HTML, un SVG, un tableau. Il s'affiche dans un panneau séparé à droite du chat, tu peux l'éditer, l'exporter, itérer dessus sans repolluer la conversation.
La confusion vient du fait qu'on présente souvent ces deux features côte à côte, comme deux options à choisir. C'est faux. Ce sont deux couches différentes : Projects gère le contexte d'entrée, Artifacts gère le livrable de sortie. Un Artifact peut très bien vivre à l'intérieur d'un Project. Pour le détail des limites techniques, le comparatif détaillé Projects vs Artifacts liste les quotas et formats supportés.
La vraie question : persistance du contexte ou persistance du livrable ?
Reformule le choix comme ça et tout devient simple.
Projects résout un problème de contexte qui ne devrait jamais être réexpliqué. Ton business, ton ton, ton ICP, tes contraintes légales, ta charte graphique. Si tu te surprends à coller le même paragraphe de brief dans trois conversations différentes la même semaine, c'est un Project que tu aurais dû ouvrir.
Artifacts résout un problème de livrable propre, isolé du bruit du chat. Quand tu rédiges un contrat de 1200 mots ou un composant React de 200 lignes, tu ne veux pas qu'il soit éclaté en 6 réponses successives avec des "voici la suite" entre chaque morceau. L'Artifact te donne un fichier unique, éditable, exportable.
L'axe de décision tient en une phrase : si tu vas revenir sur le sujet, c'est un Project. Si tu produis un asset une fois, un Artifact suffit.
5 cas où Projects est le bon choix
Voici les cinq Projects que la plupart des entrepreneurs solo finissent par ouvrir, dans l'ordre où ils deviennent rentables.
- Contenu récurrent (newsletter, blog). Instructions : ton de voix, structure type, longueur cible. Knowledge : 5 ou 6 anciens posts pour ancrer le style, ta liste des sujets déjà traités, ton persona lecteur. Chaque édition devient un Artifact markdown que tu copies-colles dans Beehiiv ou Substack. Si tu pars de zéro, le pipeline de blog SEO avec Claude détaille la chaîne complète.
- Support client. Instructions : ton, politique de remboursement, escalation rules. Knowledge : ta FAQ, tes CGV, les 20 tickets les plus fréquents. Tu colles un email entrant, Claude te sort une réponse cohérente avec ta doctrine.
- Prospection sortante. Instructions : ICP précis, propositions de valeur, ton (pas vendeur). Knowledge : tes 10 meilleurs cold emails, ta liste d'objections traitées, ton calendrier de relance.
- Admin et compta. Instructions : plan comptable, taux de TVA applicables, format des factures. Knowledge : tes 3 derniers exercices, tes contrats fournisseurs récurrents.
- Développement produit. Instructions : stack technique, conventions de nommage, décisions d'architecture. Knowledge : la spec, le schéma de base de données, l'ADR (architecture decision records). Particulièrement utile si tu fais du vibe coding avec Claude Code en parallèle.
Règle pratique : les instructions contiennent ce qui ne change jamais (ton, règles, format). Le knowledge contient les références à consulter (documents, exemples). Ne mets pas un PDF de 80 pages dans les instructions, Claude va le lire à chaque message et tu vas brûler ton quota pour rien.
5 cas où un Artifact dans une conversation suffit
Inversement, voici les tâches où ouvrir un Project est du sur-engineering pur.
- Un mockup HTML ou SVG one-shot pour valider une idée avec un client. Tu décris ce que tu veux, l'Artifact s'affiche, tu itères deux ou trois fois, c'est fini. Pour les workflows design plus poussés, va voir générer mockups et wireframes avec Claude.
- Un contrat ou des CGV ponctuels pour un cas particulier. Tu lui donnes le contexte dans un seul prompt long, il te rend un document propre, tu exportes, tu archives chez ton avocat.
- Un script Python pour nettoyer un CSV que tu n'utiliseras qu'une fois. Trois lignes de pandas, tu l'exécutes localement, tu jettes le script.
- Un tableau comparatif pour une décision unique (choisir un fournisseur, comparer trois offres SaaS). L'Artifact te donne un tableau markdown que tu colles dans Notion.
- Un email difficile à écrire. Annonce de hausse de prix, refus poli, relance après silence. Tu lui donnes le contexte, tu prends la sortie, terminé.
Le critère commun : tu ne reviendras pas dessus, et tout le contexte tient dans un seul prompt bien rédigé.
Le combo gagnant : Artifacts dans un Project
C'est là que la productivité décolle vraiment.
Prends un Project "Newsletter hebdo". Dans les instructions : ton ("direct, pas de jargon, une idée forte par édition, 600 à 800 mots"), structure ("hook, idée, exemple chiffré, CTA"), règles ("pas de superlatifs, pas de listes à puces"). Dans le knowledge : 3 fichiers, tone of voice détaillé, liste des 40 sujets déjà traités (pour éviter les répétitions), template de l'édition type.
Chaque mardi, tu ouvres une nouvelle conversation dans ce Project. Tu écris "Édition de cette semaine : [sujet]". Claude produit un Artifact markdown qui respecte le ton, évite les sujets déjà couverts, suit la structure. Tu l'édites en place dans l'Artifact, tu exportes, tu envoies. Temps total : 25 minutes au lieu de 2 heures.
Autre exemple, un Project "Site web client Dupont". Instructions : stack (HTML/Tailwind), conventions (mobile-first, accessibilité AA). Knowledge : brief client, charte graphique, contenu validé. Chaque composant (hero, pricing, footer) est un Artifact HTML autonome que tu assembles ensuite. La méthodologie complète est dans créer un site web avec Claude.
Erreurs fréquentes qui te font perdre du temps
Patterns observés sur des comptes Claude.ai d'entrepreneurs depuis 18 mois.
| Erreur | Conséquence | Correction |
|---|---|---|
| Créer un Project pour une tâche unique | 5 minutes de setup pour économiser 30 secondes | Reste en chat simple, utilise un Artifact |
| Tout faire en chat sans Artifact | Sortie longue éclatée, impossible à itérer | Demande explicitement "mets-le dans un Artifact" |
| Surcharger le knowledge avec 50 PDF | Claude se perd, réponses moins précises | 3 à 7 fichiers max, vraiment pertinents |
| Ne jamais archiver les vieux Projects | Interface saturée, mauvais Project ouvert | Archive tout Project inactif depuis 60 jours |
| Conflits instructions Project vs prompt | Claude obéit au mauvais signal | Garde les instructions Project courtes et générales |
L'erreur la plus coûteuse, et la moins visible : surcharger le knowledge. Anthropic recommande implicitement de rester sous une dizaine de documents par Project. Au-delà, la qualité des réponses chute parce que Claude doit arbitrer entre trop de sources concurrentes. Quand tu ajoutes un fichier, supprimes-en un autre si possible.
Grille de décision en 3 questions
Avant chaque nouvelle session avec Claude, pose-toi trois questions dans l'ordre.
- Vais-je revenir sur ce sujet plus de deux fois ce mois-ci ? Si oui, Project. Si non, chat simple.
- Ai-je des documents ou des règles à charger une bonne fois pour toutes ? Si oui, Project (les documents vont dans le knowledge, les règles dans les instructions). Si non, un prompt bien rédigé suffit.
- La sortie doit-elle être un livrable propre, éditable, exportable ? Si oui, demande explicitement un Artifact. Si c'est juste une réponse conversationnelle, laisse Claude répondre en chat.
Tu peux mettre cette grille dans un prompt système ou un fichier markdown que tu gardes ouvert. Voici une version utilisable :
Avant d'écrire à Claude, je vérifie :
[ ] Sujet récurrent ? -> Project
[ ] Documents ou règles stables ? -> Project
[ ] Livrable à exporter ? -> demander un Artifact
Si 2 cases sur 3 cochées : Project + Artifact dedans.
Si 0 ou 1 case : chat simple, Artifact si besoin.Teste cette grille sur tes 3 prochaines conversations. Tu vas probablement découvrir que la moitié de ce que tu fais en chat simple aurait dû être dans un Project, et que la moitié de tes Projects sont en fait des tâches one-shot qui auraient pu rester en conversation libre.
Passer à la pratique
Le bon réflexe Projects vs Artifacts n'est pas une connaissance théorique, c'est un automatisme qui se construit en 3 ou 4 semaines d'usage quotidien. Tu commences par mal classer, tu te corriges, et au bout d'un mois tu ouvres le bon outil sans réfléchir. Si tu veux structurer cet apprentissage avec une méthode complète, des templates de Projects prêts à cloner et un retour sur tes workflows, tu peux rejoindre la formation Maîtriser Claude au quotidien : 9 semaines pour transformer Claude en infrastructure de travail, pas en gadget conversationnel.