Sur les plans Team et Enterprise, les Projects peuvent être partagés entre collaborateurs. Cela ouvre des usages collectifs puissants — base de connaissances mutualisée, conversations capitalisées, cohérence éditoriale d'équipe — mais cela demande une discipline de gouvernance. Cette leçon vous donne les bons cas d'usage du partage et le cadre minimal qui évite que vos Projects partagés deviennent un dossier partagé désordonné.
Le stagiaire identifie quand partager un Project, configure les droits, et met en place une gouvernance simple.
Partager un Project apporte trois bénéfices structurants : mutualisation des documents (chacun n'a pas à recharger les références), capitalisation des conversations (un collaborateur peut consulter ce que ses pairs ont demandé), cohérence éditoriale (mêmes consignes pour tous, donc mêmes tons et mêmes formats).
Mais le partage est aussi une source de désordre si vous ne posez pas de cadre. Documents qui s'accumulent, consignes modifiées par chacun sans concertation, conversations sensibles visibles par toute l'équipe. Cette leçon vous donne la discipline minimale pour profiter des bénéfices sans subir les inconvénients.
Plan stratégique, gros chantier, programme transversal. Plusieurs collaborateurs travaillent sur les mêmes documents.
Communication client, mails commerciaux, supports salons. Vous voulez un ton et des formats uniformes.
Veille concurrentielle ou réglementaire mutualisée. Documents et synthèses partagés entre cadres concernés.
Symétriquement, plusieurs cas où vous gardez un Project strictement personnel. Pilotage individuel (votre tableau de bord, vos notes hebdomadaires) : c'est votre outil de réflexion personnelle. Données RH nominatives sensibles : pas de mutualisation sans cadrage juridique. Préparation d'arbitrages confidentiels : conseil d'administration, négociations, restructurations.
Règle simple : partager doit servir une intention collective explicite. Si vous partagez « par défaut », vous exposez du contenu qui n'a pas vocation à être collectif. Cette discipline protège à la fois la confidentialité de vos arbitrages et la qualité éditoriale du Project (un Project trop ouvert tend à se diluer).
Dans la pratique, un professionnel a typiquement 70% de Projects personnels et 30% de Projects partagés. Cette répartition est saine.
| Niveau | Peut | Pour qui |
|---|---|---|
| OwnerPropriétaire | Tout : éditer base, modifier consignes, ajouter/retirer membres, supprimer le Project | Vous (créateur du Project) |
| EditorÉditeur | Ajouter/retirer documents, modifier consignes, créer conversations | Co-pilote ou bras droit identifié |
| ViewerLecteur | Consulter base et consignes, créer conversations dans le Project | Membres d'équipe utilisateurs |
Discipline de partage YOAT : un seul owner par Project. C'est généralement vous, le commanditaire du Project. Vous gardez la responsabilité finale de la cohérence et de la qualité de la base.
Editors : un ou deux maximum. Typiquement votre bras droit ou un collaborateur clé du dossier. Au-delà de deux editors, vous perdez le contrôle de qui modifie quoi — la base se contamine de versions, de doublons, de consignes contradictoires.
Viewers : autant que pertinent. Tous les membres d'équipe qui ont besoin d'utiliser le Project sans avoir à l'éditer. Ils peuvent lancer des conversations qui bénéficient de la base et des consignes, sans risque de la dégrader.
2-3 lignes en tête des consignes : "Project partagé. Editors : X et Y. Pour modification base, contacter [...]."
15 minutes par mois. L'owner passe la base en revue, retire l'obsolète, vérifie les consignes.
30 minutes par trimestre. Faire le point avec les editors. Ce qui marche, ce qui pollue, à ajuster.
Quand un nouveau collaborateur rejoint l'équipe, l'onboarding inclut explicitement les Projects partagés. Présentation de la charte du Project, droits attribués, rôle attendu (editor ou viewer). Cinq minutes lors de l'arrivée évitent six mois de tâtonnement.
Symétriquement, quand un collaborateur quitte l'équipe ou change de poste, l'offboarding inclut le retrait des accès aux Projects. C'est une discipline RH classique appliquée aux outils — elle s'oublie facilement avec un produit nouveau comme Claude.
Astuce : intégrez les Projects partagés dans votre checklist d'onboarding/offboarding existante aux côtés des accès Slack, Drive, ou Notion. Cela évite l'oubli et standardise le geste.
Symétrique du piège du Project fourre-tout personnel (leçon 11), mais à l'échelle collective : un Project partagé sans owner clair où chacun ajoute ses documents et modifie les consignes selon son humeur.
Ce qui se passe en pratique. Au mois 1, le Project est propre — vous l'avez créé avec une intention claire. Au mois 3, trois collaborateurs ont ajouté chacun 5 documents non concertés. Au mois 6, les consignes ont été modifiées trois fois sans alignement. Au mois 9, plus personne ne sait pourquoi tel document est dans la base ou pourquoi telle consigne dit le contraire de l'autre.
Conséquences : les réponses du Project deviennent erratiques, l'équipe arrête de l'utiliser, vous perdez l'investissement initial.
Discipline : owner désigné, charte claire, revues trimestrielles. Le Project partagé suit la même règle qu'un dossier partagé Notion ou Drive — il s'entretient activement ou il pourrit.
Le partage de Projects entre membres d'une équipe Team ou Enterprise est couvert par le DPA (contrat de traitement de données) signé par votre organisation avec Anthropic. Pour les bases contenant des données personnelles, vérifier que les finalités de traitement incluent le partage interne — c'est généralement le cas, mais à confirmer avec votre DPO. Pour les données très sensibles (RH nominatif, santé, financier détaillé), envisager un Project personnel avec partage à la demande plutôt qu'un Project ouvert. Sujet approfondi en section 5 (RGPD, leçons 19 et 20).
Vous avez achevé la section 3 « Projects et bases de connaissances ». Quatre leçons pour passer de l'usage outil au poste de travail Claude structuré : créer un Project, constituer une base, rédiger des consignes efficaces, partager en équipe avec gouvernance.
La section 4 « Cowork pour la productivité quotidienne » introduit un produit complémentaire : Cowork, l'agent desktop d'Anthropic. Au lieu d'utiliser Claude dans une conversation, vous lui déléguez des tâches qui s'exécutent sur votre poste — recherche multi-fichiers, automatisations, préparation de livrables. Quatre leçons pour comprendre ce qu'apporte cet outil à un professionnel.