Projects et Artifacts sont deux objets Claude que les entrepreneurs confondent constamment. L'un est un espace de travail persistant, l'autre un livrable généré dans une conversation. Les deux ne se remplacent pas, ils se complètent. Et choisir le mauvais pour un cas donné te coûte du temps : soit tu réexpliques ton contexte à chaque fois, soit tu copies-colles du code que Claude aurait pu éditer en place.
Ce guide règle la confusion en 1500 mots. Tu sauras à la fin, en 30 secondes, laquelle des deux briques utiliser pour la tâche en cours. Si tu démarres avec Claude, commence plutôt par le guide complet pour apprendre Claude qui pose les bases avant d'entrer dans les détails produit.
La confusion de départ : deux objets qui ne jouent pas dans la même catégorie
Un Project, c'est un espace de travail persistant dans Claude.ai. Tu lui donnes un nom ("Client Dupont", "Blog Ottho", "SaaS en cours"), tu y mets des instructions permanentes, des fichiers de référence (brief, charte édito, specs), et toutes les conversations que tu lances dedans héritent de ce contexte. Tu peux y revenir deux semaines plus tard, Claude a toujours le même contexte sous les yeux.
Un Artifact, c'est un livrable généré pendant une conversation : un bloc de code React, un document Markdown complet, une page HTML interactive, un diagramme Mermaid, un tableau structuré. Il apparaît dans un panneau à côté du chat, tu peux le prévisualiser, l'éditer en place sans tout régénérer, le publier et le partager par lien.
Résumé en une phrase : le Project est le classeur, l'Artifact est la feuille que tu produis à l'intérieur. Les deux sont disponibles sur les plans Pro, Max, Team et Enterprise.
Projects : à quoi ça sert vraiment
Trois usages où ouvrir un Project change tout.
Suivre un client ou un produit sur la durée. Tu crées un Project "Client Dupont" avec le brief initial, le ton de voix validé, les derniers livrables, les décisions prises. Deux mois plus tard, quand le client te demande un nouveau post LinkedIn ou une relance email, tu lances une conversation dans ce Project et Claude écrit déjà dans la bonne voix, avec les bons éléments de langage. Zéro réexplication. C'est le gain principal.
Centraliser des assets de référence. Pour un pipeline éditorial, tu mets dans le knowledge du Project : la charte édito (ton, mots interdits, longueur), 2 ou 3 personas détaillés, 5 exemples d'articles qui ont bien marché. Chaque nouvel article généré respecte cette grille sans que tu aies à la recoller dans le prompt. Même logique pour un produit : les specs techniques, les guidelines de marque, la roadmap.
Garder une mémoire de décisions. Les conversations d'un Project restent accessibles. Tu retrouves pourquoi tu as choisi tel positionnement, telle architecture, telle structure de prix.
Les limites, à connaître avant de surcharger :
- Le knowledge d'un Project a une taille maximale. Mettre 50 PDF dilue la pertinence au lieu de l'améliorer.
- Toutes les conversations du Project partagent le même contexte. Si tu mélanges deux clients dans le même Project, Claude confondra leurs briefs.
- Les Projects sont réservés aux plans payants. Pour une vue d'ensemble des différences entre plans, va voir quel abonnement Claude choisir.
Artifacts : l'atelier à l'intérieur de la conversation
L'Artifact apparaît automatiquement quand Claude produit un contenu substantiel et éditable. Les déclencheurs typiques : plus d'une vingtaine de lignes de code, un document rédigé complet, un composant React, une page HTML avec du JavaScript, un diagramme, un SVG.
Ce qui change concrètement par rapport à du texte collé dans le chat :
- Édition itérative. Tu demandes "change la couleur du bouton principal en orange et ajoute un sous-titre", Claude modifie l'Artifact en place. Tu ne régénères pas 300 lignes à chaque ajustement.
- Prévisualisation live. Un Artifact HTML ou React se rend directement dans le panneau. Tu vois ton calculateur de ROI, ta landing, ton composant.
- Publication et partage. Tu publies l'Artifact, tu obtiens un lien, tu l'envoies à un client ou tu l'intègres ailleurs.
Un exemple classique : tu veux un calculateur de ROI pour qualifier des prospects. Message 1 : "génère un calculateur simple avec 3 champs et un résultat". Message 2 : "ajoute la couleur de ma marque et un bouton d'export PDF". Message 3 : "corrige la formule, j'ai oublié les charges patronales". Trois tours, un livrable fini, zéro copier-coller. Pour aller plus loin sur les cas d'usage pratiques, le comparatif détaillé Projects vs Artifacts liste les déclencheurs et les formats supportés.
La règle de décision en 30 secondes
| Question | Si oui | Si non |
|---|---|---|
| Je vais revenir sur ce sujet dans plusieurs conversations ? | Project | Chat simple suffit |
| Je produis un livrable concret (code, doc, composant) que je vais itérer ? | Artifact | Réponse texte classique |
| Les deux à la fois ? | Project qui contient des conversations générant des Artifacts | - |
C'est l'arbre entier. Si tu hésites, pose-toi la question 1 d'abord : la persistance du contexte prime sur le format du livrable.
Trois workflows combinés qui marchent
1. Pipeline blog SEO. Project "Blog Ottho" avec dans le knowledge : la ligne édito (ton, longueur cible, interdictions), 2 personas, 3 exemples d'articles de référence, la liste des liens internes autorisés. Pour chaque nouvel article, une conversation dans ce Project : tu donnes le brief, Claude génère l'article en Artifact Markdown. Tu itères sur l'intro, tu demandes de resserrer un H2, tu publies. Le même Project sert pour 50 articles. Si c'est ton cas, le pipeline de blog SEO avec Claude détaille la méthode complète.
2. Landing page client. Project "Client X" avec le brief, la charte graphique, les concurrents analysés. Dans une conversation dédiée "landing v1", tu demandes la page en Artifact HTML. Tu itères : hero plus percutant, ajout d'une section FAQ, correction du CTA. L'Artifact se met à jour, tu partages le lien au client pour validation. Deux semaines plus tard, nouveau besoin pour le même client ? Nouvelle conversation dans le même Project, Claude connaît déjà la marque. Le guide pour créer un site web avec Claude enchaîne du brief au déploiement.
3. Support produit SaaS. Project "SaaS Y" avec la doc technique, l'API reference, les tickets types déjà résolus. Quand un utilisateur pose une question complexe, tu lances une conversation, Claude génère la réponse et, si besoin, un Artifact avec un snippet de code commenté que tu envoies directement. Les décisions produit prises en conversation restent accessibles pour l'équipe.
Dans les trois cas, la logique est la même : le Project porte le contexte stable, l'Artifact porte le livrable itéré.
Les erreurs qui coûtent cher
- Saturer un Project avec 50 fichiers. Le contexte se dilue, Claude cite des choses hors sujet. Réflexe : garde 3 à 5 documents vraiment utiles, mis à jour.
- Créer un Project par tâche. "Project article du 15 octobre", "Project article du 22 octobre"... Tu perds la logique de persistance. Un Project par domaine (un client, un produit, un canal), pas par tâche.
- Oublier d'actualiser les instructions. Ton positionnement a bougé, ton persona a changé, mais le Project continue de bosser avec les anciennes consignes. Révise les instructions une fois par mois sur les Projects actifs.
- Copier-coller un Artifact au lieu de l'éditer. Tu colles le code dans le chat, tu demandes une modif, Claude régénère tout. Reste dans l'Artifact, les éditions ciblées sont faites pour ça.
- Ne pas publier un Artifact réutilisable. Un calculateur ou un template que tu vas resservir mérite d'être publié et bookmarké, pas enterré dans une conversation que tu ne retrouveras pas.
- Mélanger deux clients dans un même Project. Garanti pour que Claude confonde les briefs. Un Project = un périmètre.
Par où commencer cette semaine
Pas la peine de refondre toute ton organisation. Choisis l'activité la plus récurrente de ton quotidien : ton client principal, ton produit phare, ou ton canal de contenu le plus actif. Ouvre un seul Project pour celle-là.
Mets-y 3 à 5 documents : les instructions permanentes (ton, cadre, objectifs), un ou deux fichiers de référence (brief, charte, exemple de livrable réussi). Pas plus pour commencer.
Lance ensuite ta prochaine demande dans ce Project. Si Claude produit un contenu substantiel, l'Artifact va apparaître. Itère dedans sans copier-coller. Observe la différence sur une semaine : moins de réexplications, livrables plus propres, décisions tracées.
Une fois que ce premier Project tourne, tu en ouvres un deuxième. Puis tu passes à l'étape d'après : connecter des sources externes (voir Claude connecté à Notion et Slack) ou automatiser les pipelines. Pour configurer l'environnement complet avant d'empiler les workflows, le guide setup Claude couvre les bases.
Si tu veux structurer les 5 workflows qui font le quotidien d'un entrepreneur (setup, site, blog, automatisation, marketing) en 5 semaines et 5 projets concrets, c'est exactement ce que couvre la formation Maîtriser Claude au quotidien, cohorte intensive à effectif limité à partir de 900 € TTC.