Les applications Claude et les Projects : un contexte persistant qui se souvient

Déposez un manuel d'entreprise de 200 pages et un guide de style d'une page dans un Project Claude, et chaque conversation lancée dans ce Project démarre déjà briefée : Claude répond dans la voix de la maison, cite vos politiques internes et ne vous demande plus jamais de recoller les mêmes documents. C'est toute la promesse des Projects, et c'est la fonctionnalité la plus sous-utilisée de l'écosystème Claude.

Cette leçon fait le tour des applications Claude, puis entre dans le détail des Projects comme conteneur de contexte persistant. Vous comprenez déjà la fenêtre de contexte. La question ici est opérationnelle : comment arrêter d'alimenter manuellement chaque conversation avec le même arrière-plan ?

Les trois applications Claude, brièvement

Claude se décline en trois clients qui partagent un même compte et un même jeu de fonctionnalités :

• Web (claude.ai) est la surface canonique. Tout y arrive en premier.
• Desktop (macOS et Windows) ajoute les Connectors locaux via MCPMCPUn standard ouvert qui permet aux assistants IA de se connecter aux outils et données de l'entreprise de façon cohérente et gouvernée, sans intégration sur mesure à chaque fois.Voir la définition complète → et peut agir sur les fichiers et les applications de votre machine. C'est là que Claude cesse d'être une fenêtre de chat pour commencer à toucher votre environnement.
• Mobile (iOS et Android) sert à la capture et aux requêtes rapides : dicter une idée, photographier un tableau blanc, reprendre une conversation de Project dans le train.

Ce ne sont pas trois produits. Un Project crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éé sur le web est immédiatement disponible sur desktop et mobile. Les différences portent sur le *reachreachLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète →* : le desktop peut exécuter des connectors locaux et accéder au système de fichiers, le mobile non.

Un terme à définir avant de passer à la suite : un Connector est une prise qui permet à Claude de lire depuis un système externe ou d'agir dessus (Google Drive, GitHub, une base de données) via MCP, le Model Context Protocol. Nous les traiterons légèrement ici et en profondeur dans une leçon ultérieure. L'objet du jour, c'est la couche de contexte persistant qui se situe *au-dessus* de n'importe quel connector.

Ce qu'est réellement un Project

Un Project est un espace de travail qui regroupe trois éléments et les applique à chaque conversation créée à l'intérieur :

1. Le project knowledge : les fichiers et textes que vous téléversez une fois (PDF, documents, tableurs, texte de référence collé).
2. Les custom instructions : un brief permanent, de niveau système, qui façonne le ton, le format et le comportement.
3. Les conversations elles-mêmes : chaque échange démarré dans le Project, conservé au même endroit.

Le modèle mental : une conversation normale est une pièce vide. Un Project est une pièce où le briefing est déjà affiché au mur avant que vous n'entriez. Vous ne rétablissez pas le contexte chaque fois, vous continuez depuis une base commune.

C'est différent de coller votre manuel dans une seule conversation. Le contexte collé à la volée meurt avec la conversation. Le project knowledge persiste dans toutes les conversations, indéfiniment, pour tous ceux qui ont accès au Project (sur les plans Team et Enterprise, les Projects peuvent être partagés).

La référence officielle se trouve dans la documentation d'aide d'Anthropic sur les Projects.

La mise en place concrète : manuel plus guide de style

Voici le scénario de l'accroche, exécuté correctement.

Vous disposez de deux ressources :

• company-handbook.pdf : 200 pages de politiques, avantages sociaux, chemins d'escalade, règles de sécurité.
• style-guide.md : une page sur la voix (chaleureuse, directe, sans jargon, orthographe britannique, ne jamais promettre de remboursement sans validation d'un manager).

Étape 1 : créer le Project. Dans l'application web, ouvrez Projects et créez-en un nommé « Support Desk Assistant ».

Étape 2 : ajouter le manuel au project knowledge. Téléversez company-handbook.pdf dans le panneau de connaissances. Claude l'indexe. Désormais, chaque conversation de ce Project peut se référer à la politique d'escalade de la page 147 sans que vous ne colliez quoi que ce soit.

Étape 3 : rédiger les custom instructions. C'est là que la plupart des gens bâclent. Soyez précis :

You are the internal support assistant for Acme Ltd.

Sources of truth:
- Always ground policy answers in the uploaded company handbook.
- Always follow the uploaded style guide for voice and formatting.

House rules:
- Use British spelling. Warm but direct. No corporate jargon.
- Never promise a refund. For refunds, instruct the user to flag a manager
  and quote handbook section 6.2.
- If the handbook does not cover something, say so plainly and do not guess.
- End policy answers with the handbook section number you used.

Étape 4 : tester. Démarrez une nouvelle conversation dans le Project et demandez : « Un client veut un remboursement au bout de 40 jours. Que lui dis-je ? »

Claude répond en orthographe britannique, sur le ton chaleureux mais direct, refuse de promettre le remboursement, renvoie à la section 6.2 et cite la source. Vous n'avez rien collé. La conversation suivante, et celle que votre collègue lancera demain, se comporteront à l'identique.

Cette répétabilité est tout l'enjeu. Un Project transforme « un Claude qui se trouve savoir ceci aujourd'hui » en « un Claude qui se comporte ainsi de façon fiable, chaque fois ».

Project knowledge vs fenêtre de contexte

Une question légitime : si vous déposez 200 pages, est-ce que cela consomme votre fenêtre de contexte à chaque message ?

Pas comme un collage le ferait. Quand le project knowledge est volumineux, Claude récupère les fragments pertinents plutôt que d'enfourner le document entier dans chaque prompt (la même idée de retrieval que vous avez rencontrée au niveau conceptuel plus tôt dans le parcours). Quand il est réduit, il peut tenir entièrement dans le contexte. Dans les deux cas, vous n'avez rien à gérer manuellement.

Implication pratique : gardez un project knowledge *curaté*. Un manuel resserré plus un guide de style propre valent mieux que le déversement de quarante PDF vaguement liés. La qualité du retrieval baisse quand la base de connaissances est bruitée. Traitez le panneau de connaissances comme une étagère de référence, pas comme un grenier.

Les Styles : la voix sans réécrire les instructions chaque fois

Il y a un recouvrement qui mérite d'être clarifié. Les Styles permettent d'enregistrer une voix d'écriture réutilisable (formelle, concise, le ton de votre marque) et de l'appliquer à n'importe quelle conversation en un clic, *au travers* des Projects. Vous pouvez même apprendre un Style à partir d'exemples d'écriture.

Alors, quand utiliser quoi ?

• Placez les comportements et règles spécifiques à un corpus de connaissances dans les custom instructions du Project (la règle de remboursement ci-dessus).
• Placez la voix réutilisable que vous voulez partout dans un Style.

Dans l'exemple du manuel, « orthographe britannique, chaleureux, direct » relève sans doute d'un Style que vous réutilisez sur de nombreux Projects, tandis que « citer la section 6.2 pour les remboursements » appartient aux instructions de ce Project. Les séparer garde chaque Project léger et votre voix cohérente à l'échelle de l'entreprise.

Où se placent les artifacts et les skills

Deux pièces supplémentaires complètent le tableau dans les applications.

Les Artifacts sont les productions autonomes que Claude génère dans un panneau latéral : un document, une application web fonctionnelle, un graphique, un outil interactif. Dans votre Project Support Desk, vous pourriez demander à Claude de construire un Artifact : une petite application de checklist de triage qui encode la logique d'escalade du manuel. Elle s'affiche en direct, vous pouvez l'itérer dans la même conversation, et elle hérite de l'ancrage du Project.

Les Skills sont des capacités empaquetées et réutilisables : des dossiers d'instructions accompagnés de scripts et de ressources facultatifs que Claude charge quand une tâche en a besoin. Là où un Style façonne la voix et le project knowledge fournit les faits, un Skill enseigne à Claude une *procédure* : comment formater un rapport trimestriel exactement à votre manière, ou comment exécuter un flux précis de traitement documentaire. Les Skills fonctionnent dans les applications, l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → et Claude Code. Voir la documentation Agent Skills pour la structure.

La superposition est le modèle mental à retenir :

• Project knowledge = ce que Claude sait.
• Custom instructions = comment Claude se comporte *ici*.
• Styles = comment Claude sonne *partout*.
• Skills = les procédures que Claude peut exécuter.
• Connectors / MCP = les systèmes que Claude peut atteindre.

Connectors et GitHub : quand un Project a besoin de données vivantes

Une connaissance statique suffit pour un manuel qui change chaque trimestre. Mais certains Projects ont besoin de données *actuelles*, et c'est là qu'interviennent les Connectors.

Sur Claude Desktop, vous pouvez ajouter des Connectors (via MCP) pour qu'une conversation lise depuis Google Drive, interroge un système ou récupère des éléments d'un dépôt en temps réel. Un annuaire de connectors s'étoffe dans les applications, avec la possibilité de construire les vôtres.

L'intégration GitHub est la plus marquante pour les équipes techniques. Connectez un dépôt et Claude peut lire votre base de code comme un contexte vivant, pas comme un instantané périmé. Dans un Project cadré sur un seul dépôt, vous pouvez demander « où validons-nous la fenêtre de remboursement ? » et Claude raisonne sur le code réel. C'est le pont vers Claude Code, l'agent en terminal qui opère directement sur votre dépôt, et qui aura sa propre leçon détaillée plus loin dans ce parcours.

La distinction à garder : le project knowledge est un instantané que vous avez téléversé. Un Connector est une ligne directe vers une source. Utilisez le knowledge pour les références stables (le manuel). Utilisez les connectors pour ce qui bouge sous vos pieds (tickets ouverts, branche courante, tableur de la semaine).

Quand passer à l'API à la place

Tout ce qui précède décrit l'expérience applicative : un humain dans la boucle, qui clique de conversation en conversation. Quand vous voulez tout cela *par programme*, vous descendez vers l'API Messages d'Anthropic, où le contexte persistant à la manière d'un Project devient un system promptsystem promptLes instructions cachées qui définissent le comportement d'un assistant IA avant toute question : son rôle, son ton, ses limites et ses règles.Voir la définition complète → plus des documents attachés à chaque requête.

import anthropic

client = anthropic.Anthropic()

with open("style-guide.md") as f:
    style_guide = f.read()

message = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=(
        "You are Acme Ltd's support assistant. Follow this style guide "
        f"exactly:\n\n{style_guide}\n\n"
        "Never promise refunds; quote handbook section 6.2 instead."
    ),
    messages=[{
        "role": "user",
        "content": "Customer wants a refund after 40 days. What do I say?",
    }],
)

print(message.content[0].text)

Ce bloc system est l'équivalent API des custom instructions d'un Project, et l'attachement de documents par requête reproduit le project knowledge. L'application rend cela cliquable et persistant ; l'API le rend scriptable et intégrable. Pour les workflows agentiques, le Claude Agent SDK enveloppe ce même modèle avec des outils et des boucles. Commencez par la documentation de l'API.

Règle empirique : utilisez les Projects quand des humains font le travail dans un espace partagé et évolutif. Utilisez l'API / Agent SDK quand c'est le logiciel qui fait le travail à grande échelle.

Quelques habitudes moins évidentes

• Un Project par mission, pas par sujet. « Support Desk Assistant » et « Q3 Marketing Copy » doivent être des Projects distincts, avec des instructions distinctes. Les Projects mixtes produisent un comportement brouillon.
• Versionnez vos connaissances. Quand le manuel est mis à jour, remplacez le fichier plutôt que d'en téléverser une seconde copie. Deux versions dans le panneau de connaissances garantissent des contradictions.
• Rédigez les instructions comme des règles, pas comme des intentions. « Ne jamais promettre de remboursement ; citer la section 6.2 » est applicable. « Être utile sur les remboursements » ne l'est pas.
• Ancrez la règle de citation des sources. Demander à Claude de terminer ses réponses par la section utilisée transforme un assistant assuré en un assistant auditable.

Points clés

• Un Project regroupe connaissances persistantes, custom instructions et conversations, de sorte que Claude démarre chaque échange déjà briefé. ArrArrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtez de recoller le contexte.
• Superposez vos outils par fonction : knowledge (les faits), custom instructions (le comportement ici), Styles (la voix partout), Skills (les procédures), Connectors/MCP (la portée en temps réel).
• Utilisez le project knowledge pour les références stables et les Connectors (comme l'intégration GitHub) pour les données qui bougent sous vos pieds.
• Rédigez les custom instructions comme des règles applicables, avec une exigence de citation des sources, et gardez le panneau de connaissances curaté, pas bourré.
• Quand le travail passe d'humains qui cliquent à du logiciel à grande échelle, le même pattern existe dans l'API Messages (prompt system plus documents attachés) et l'Agent SDK.