La qualité d'un Project dépend directement de la qualité de sa base de connaissances. Cette leçon vous donne les critères pour sélectionner les bons documents, les organiser sans surcharge, et anticiper les pièges les plus coûteux : la base obèse, la base obsolète, la base contradictoire. Trois disciplines simples qui font la différence entre un Project utile et un Project ignoré.
Le stagiaire sélectionne les documents à intégrer dans une base de connaissances et anticipe les pièges classiques.
L'erreur courante consiste à charger massivement dans la base : tout ce qu'on a sous la main, par sécurité. Conséquences immédiates : Claude met plus longtemps à répondre, les sujets se contaminent, et la pertinence des réponses chute.
L'autre erreur, symétrique, consiste à charger trop peu : seulement deux ou trois documents, en pensant garder la base légère. Claude se prive alors d'éléments de contexte qui auraient nourri ses analyses. Cette leçon vous donne les bonnes proportions et le réflexe d'entretien régulier.
Charte, guide méthodologique, document fondateur du dossier. Stable, change rarement.
Tableau de bord du mois, indicateurs derniers trimestres. À actualiser périodiquement.
Compte rendu du dernier comité, décisions prises. Mémoire vivante du dossier.
Notes précédentes, mails type, présentations. Pour cohérence éditoriale.
Volume optimal observé : entre 5 et 30 documents par Project. En dessous de 5, la base est anecdotique — Claude ne peut pas s'en imprégner. Au-dessus de 30, vous entrez en zone de surcharge : Claude met plus de temps, la qualité chute, et certains documents sont sous-utilisés.
Volume total cumulé recommandé : jusqu'à 200 pages environ. C'est le seuil au-delà duquel la mécanique de cache reste efficace mais où la pertinence des réponses commence à diluer.
Si vous dépassez 200 pages, c'est généralement le signe qu'il faudrait scinder en plusieurs Projects. Un Project « pilotage commercial » et un Project « pilotage RH » plutôt qu'un Project « pilotage tout » obèse.
| Piège | Symptôme | Correction |
|---|---|---|
| Base obèseTrop volumineuse | Réponses lentes, qualité diluée, Claude perd le focus | Élaguer ou scinder en deux Projects |
| Base obsolèteVieillissante | Réponses en décalage avec la réalité courante | Tournée d'actualisation mensuelle |
| Base contradictoireVersions multiples | Claude hésite, donne des réponses incohérentes | Une seule version active par sujet |
Comme une mailing list ou un dossier partagé, une base de connaissances se détériore avec le temps sans entretien. Les documents s'accumulent, les versions se multiplient, les références deviennent caduques.
Discipline YOAT : tournée d'entretien mensuelle de 15 minutes par Project actif. Trois gestes : retirer les documents devenus obsolètes ; remplacer les versions périmées par les courantes ; vérifier que les consignes (custom instructions) sont toujours alignées avec le sujet courant.
Ce rendez-vous mensuel devient vite un réflexe et coûte peu. À l'inverse, ne jamais entretenir une base la rend inutilisable au bout de 6 mois — vous abandonnez le Project et vous reperdez le bénéfice de la persistance. L'entretien est ce qui distingue les utilisateurs avancés des débutants.
Avant de charger un document dans une base de connaissances, posez-vous trois questions : est-ce que je l'enverrais par mail à un consultant externe ? Est-ce que j'accepterais qu'il soit lu par mon équipe DSI ? Est-ce que mon DPO l'autoriserait dans un système IA ? Si la réponse à l'une des trois est non, ne chargez pas — ou anonymisez d'abord.
Pour les organisations avec un cadrage RGPD strict, la règle minimale est le plan Team avec DPA signé. Pour les données vraiment sensibles (financier détaillé, RH nominatif, secret industriel), envisagez Enterprise avec contrat sur mesure ou anonymisation systématique.
Ce sujet est traité plus en profondeur en section 5 (leçons 19 et 20 sur le RGPD). Pour cette leçon, retenez la règle d'avant : pas de chargement sans réflexe de classification.
Le piège qui dégrade tous les Projects à terme : charger des documents par sécurité « pour plus tard, on verra ». Vous trouvez un PDF qui pourrait servir, vous le glissez dans la base, vous passez à autre chose. Six mois après, votre base contient 80 documents dont vous ne savez plus à quoi ils servent.
Conséquences. Premièrement, Claude lit tout à chaque conversation — vous payez en tokens et en latence pour des documents inutiles. Deuxièmement, les documents sans rapport polluent les réponses sur des sujets précis (Claude croise involontairement des informations qui n'ont rien à voir). Troisièmement, vous perdez la confiance dans la base et vous arrêtez d'utiliser le Project.
Discipline : chaque document chargé doit avoir une utilité identifiée. Si vous ne pouvez pas dire en une phrase pourquoi ce document est dans cette base, ne le chargez pas. Mieux vaut une base de 10 documents bien choisis qu'une base de 50 documents flottants.
Les limites techniques des Projects évoluent au fil des versions de Claude. Volume maximal de documents, taille des fichiers, formats acceptés — ces paramètres peuvent changer d'une mise à jour à l'autre. Les chiffres cités dans cette leçon (5-30 documents, jusqu'à 200 pages) sont des recommandations pédagogiques qui restent valides au-delà des limites techniques. Au moment de la consultation, vérifier sur docs.claude.com les limites en vigueur — généralement plus généreuses que les seuils pédagogiques recommandés ici.
La leçon 13 approfondit la rédaction de consignes personnalisées efficaces. Les custom instructions sont l'autre pilier d'un Project : elles encodent durablement le ton, le rôle, les contraintes. Bien rédigées, elles transforment Claude en assistant adapté au dossier. Mal rédigées, elles ne servent à rien — ou pire, elles polluent les réponses.
Vous apprendrez la structure type de consignes efficaces, des exemples concrets pour des cas professionnel fréquents, et les anti-patterns à éviter.