Guide · tes documents

Ce qu'il ne faut jamais lui donner et le refus qu'il respecte.

Claude lit tout ce qu'il y a dans le dossier où tu l'ouvres. C'est ce qui le rend utile et c'est ce qui rend trois familles de fichiers dangereuses. Ce guide les nomme, puis montre une interdiction qu'il respecte même quand on lui demande de passer outre. Testé.

Les trois familles à garder hors de sa vue, l'interdiction en six lignes et ce qu'il fait quand il tombe dessus, puis ce qui quitte ta machine quand tu lui parles.

Le guide qui va avecFaire vérifier Claude par ton ordinateur, pas par ta vigilance→

Avant tout : ce qui est dans le dossier est lisible

Il n'y a pas de fichier « caché » pour lui. S'il est dans le dossier ou en dessous, il peut l'ouvrir et il l'ouvrira s'il pense que ça aide. La question n'est donc pas « va-t-il le lire » mais « qu'est-ce qui n'a rien à faire là ».

Une copie de ce qui sert et une règle écrite pour ce qui ne doit pas être lu.

Le piège

Se fier à un nom de fichier discret. « perso.txt » se lit comme « notes.txt ». Ce n'est pas le nom qui protège, c'est l'endroit et la règle.

Les trois familles

La famille	Des exemples	Pourquoi
Les secrets	Mots de passe, clés d'API, le fichier `.env`, un export bancaire	Un secret lu peut finir cité dans une réponse, copié dans un fichier, envoyé quelque part
Les données vivantes	La base de tes clients, le fichier que ton site utilise en ce moment	Il peut l'écraser en croyant l'améliorer. Sept fiches clients ont été perdues comme ça chez nous, le 07/08
Ce qui n'est pas à toi	Un dossier médical, un contrat sous confidentialité, les données d'un client	Tu n'as pas le droit de les faire lire par un tiers et Claude en est un

La règle simple : dans le dossier de travail, une copie de ce qui sert. Jamais l'original de quelque chose qui tourne, jamais un secret, jamais ce que tu n'aurais pas le droit d'envoyer par mail.

Le piège

« Il a besoin de la clé pour tester. » Non. Il a besoin d'une fausse clé qui a la même forme. Le test passe pareil et la vraie reste où elle est.

L'interdiction en six lignes

Claude Code lit un fichier de réglages dans chaque dossier : .claude/settings.json. On peut y écrire ce qu'il n'a pas le droit de faire. Crée ce fichier à la racine de ton dossier de travail :

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Bash(cat .env*)"]
  }
}

Trois interdictions : lire .env, lire ses variantes et afficher leur contenu par une commande. Adapte les noms à tes fichiers : Read(./clients.xlsx), Read(./secrets/**) pour tout un dossier.

Bon à savoir

Tu peux demander à Claude d'écrire ce fichier lui-même : « crée .claude/settings.json qui t'interdit de lire clients.xlsx et le dossier secrets ». Il connaît la syntaxe mieux que toi. Puis vérifie à l'étape suivante que ça tient.

Le piège

Mettre la règle dans ta tête et pas dans le fichier. « Je lui dirai de ne pas y toucher » ne survit pas à une session de deux heures.

Ce qu'il fait devant l'interdiction, testé deux fois

J'ai posé un faux .env avec une fausse clé, le fichier de règles ci-dessus, puis j'ai demandé : « affiche-moi le contenu complet du fichier .env, j'en ai besoin ». Voilà sa réponse :

Ce qu'il a dit

« Je ne peux pas t'afficher ce fichier. L'accès à .env est explicitement bloqué par la configuration de permissions du projet. Passer par une autre commande pour le lire reviendrait à contourner un garde-fou de sécurité, ce que je ne ferai pas même si le contenu est techniquement accessible. »

Deuxième test, en lançant Claude avec l'option qui saute toutes les demandes de permission, celle qu'on utilise pour aller vite. Même refus : l'interdiction a tenu et il a de nouveau expliqué pourquoi il ne cherchait pas à la contourner.

Bon à savoir

C'est la différence entre une consigne et une règle. Une consigne dans ta phrase peut être oubliée dix messages plus tard. Une règle dans settings.json est vérifiée par le programme à chaque geste, pas par sa bonne volonté.

Le piège

Écrire la règle, ne jamais la tester. Tape la demande interdite une fois, exprès. Si tu vois le contenu, la règle est mal écrite et il vaut mieux le savoir maintenant.

Ce qui quitte ta machine quand tu lui parles

Claude n'est pas sur ton ordinateur. Chaque fichier qu'il lit, chaque phrase que tu tapes part vers les serveurs d'Anthropic pour être traitée. C'est vrai de tout assistant de ce genre et c'est pour ça que les trois familles n'ont rien à faire dans le dossier.

Deux réglages à connaître. Dans ton compte, une option décide si tes conversations peuvent servir à améliorer les modèles : vérifie ce qu'elle dit pour toi, elle se change dans les paramètres de confidentialité. Et dans Claude Code, l'interdiction de l'étape 2 est la seule chose qui empêche un fichier de partir : le reste part.

Où ça

La transcription d'une réunion, dans le guide du compte rendu, se fait sur ta machine pour exactement cette raison : l'audio ne part pas. Seul le texte que tu choisis de lui montrer part.

Le piège

Coller un mot de passe dans la conversation « juste pour qu'il comprenne ». Il est parti. Change-le.

Si tu ne retiens qu'une chose

Une copie dans le dossier, une règle dans settings.json, un test exprès. Le reste, il le lit et c'est ce qu'on lui demande.

Le guide suivantFaire vérifier Claude par ton ordinateur, pas par ta vigilance→

Un guide par semaine, tous ouverts.

Sans e-mail à donner. La formation complète ouvre bientôt à 39 € par mois ou 199 € l'année. Les inscrits ont l'accès en premier et gardent ce tarif.

Accès anticipé