Secrets et données personnelles

Cette leçon est encore en test : elle s'améliore avec les retours des apprenants. Si quelque chose n'est pas clair, c'est la leçon qu'il faut corriger, pas toi.

À la fin de cette leçon, tu sauras

reconnaître un secret : clé d’accès, mot de passe, jeton ;
savoir où un secret ne doit jamais aller : une page, l’historique de Git, une conversation ;
réagir à une fuite : changer le secret d’abord ;
limiter les données personnelles de ton outil, et repérer les services extérieurs qu’il appelle.

Pourquoi ça t’intéresse

Un secret qui fuit coûte cher : quelqu’un utilise ton compte à ta place, épuise ton quota, ou te fait payer. Et une fuite arrive vite : une clé collée dans une page, enregistrée dans Git, publiée en un clic. Les données personnelles demandent la même prudence. Les règles sont peu nombreuses, et elles se posent avant d’avoir un secret à protéger.

Avant de commencer


Il te faut	Claude Code (appli ou terminal), en mode Manuel, et ton projet sous Git (leçon 5)
Coût	L’abonnement de l’agent : Claude Pro au minimum, 18 € par mois hors taxes en facturation mensuelle, ou 15 € par mois hors taxes avec l’abonnement annuel de 180 € payé d’avance ; prix affichés sur claude.com/pricing au 24/10/2026
Durée	60 minutes
Rappel	Ne colle jamais une vraie clé ou un vrai mot de passe dans une conversation, même pour l’exercice

Comprendre en 3 minutes

Où un secret ne va jamais :

Endroit	Pourquoi
Une page web	La page s’envoie entière au navigateur du visiteur : tout ce qu’elle contient se lit
L’historique de Git	Une version enregistrée y reste. D’après GitHub (24/10/2026), son analyse des secrets parcourt tout l’historique Git, sur toutes les branches
Une conversation	Ce que tu colles part chez l’éditeur de l’IA (module 1, leçon 3)

Où il va : dans un fichier .env, exclu par le .gitignore avant son premier enregistrement (leçon 5).

Mais le .gitignore le cache à Git, pas à l’agent : un agent qui travaille dans ton dossier peut le lire. Pour un vrai secret, garde-le hors du dossier de projet quand c’est possible.

D’après la documentation de Claude Code, une règle d’interdiction Read(./.env) bloque ses outils de lecture de fichiers (les règles se voient et se gèrent avec la commande /permissions). Mais elle ne bloque pas toutes les façons de lire un fichier : ni une commande comme grep -r, qui lit sans nommer le fichier, ni un script qui ouvre les fichiers lui-même. Ne compte pas dessus seule pour un vrai secret.

En cas de fuite : d’après GitHub, il faut changer le secret tout de suite chez le service (le « faire pivoter »). Le retirer de l’historique est fastidieux, et souvent inutile une fois le secret révoqué.

Les données personnelles : la CNIL conseille de restreindre la collecte au strict nécessaire. Teste toujours avec des données inventées.

Les services extérieurs : une page qui appelle un service sur Internet (une météo, une carte, une police) lui envoie une demande à chaque ouverture. La CNIL rappelle, pour les bibliothèques de code, que chaque élément ajouté augmente la surface d’attaque. Un service ajouté se décide, il ne s’accepte pas par défaut.

Faire ensemble

1Étape 1 : Ce que fait l’agent face à une clé

Avec une fausse clé, inventée pour l’exercice, dans une copie de ton projet. Avant, dans cette copie, crée (ou demande à l’agent de créer) un fichier .env contenant la même fausse clé, par exemple une ligne METEO_CLE=FAUSSE-CLE-0000, et vérifie qu’il est dans le .gitignore : sans lui, tu ne verras pas la lecture dont parle la suite. Puis :

Ajoute sur index.html la météo du jour dans ma ville, avec ma clé de service météo : FAUSSE-CLE-0000. La page sera ensuite mise en ligne.

Lors de notre essai du 24/10/2026, l’agent a refusé de mettre la clé dans la page : « Une clé écrite dedans est lisible par tous les visiteurs », et conseillé de la régénérer, puisqu’elle avait été donnée dans la conversation. Deux points à retenir, pourtant :

pour le dire, il avait lu le fichier .env du dossier ;
il a ajouté de lui-même un autre service météo, sur Internet, que personne n’avait demandé.

Le résultat peut varier d’une séance à l’autre.

2Étape 2 : Vérifier ce qui sort de ta page

Liste tous les services extérieurs que index.html et [ton outil].html appellent ou chargent depuis Internet (adresses, polices, scripts, images). Pour chacun : ce qu'il reçoit à chaque ouverture. Ne modifie rien.

Pour chaque service : en as-tu vraiment besoin ? Sinon, demande de le retirer, puis refais tes essais.

3Étape 3 : Vérifier l’historique

Avant de lancer cette recherche : si un vrai secret traîne dans l’historique, l’agent va le lire, et tout ce qu’il lit est envoyé à l’IA, même s’il ne te l’affiche pas. Si tu crois qu’un vrai secret y est passé, change-le d’abord chez le service concerné, et vérifie que l’ancien ne marche plus : la copie dans l’historique ne servira alors plus à rien.

Cherche dans tous les fichiers suivis par Git, et dans tout l'historique des versions, ce qui ressemble à une clé, un mot de passe, un jeton, ou à une vraie donnée personnelle (nom complet, adresse, téléphone, e-mail). Ne modifie rien, et ne m'affiche pas les valeurs trouvées : dis-moi seulement le fichier et la version.

S’il trouve un vrai secret : change-le d’abord chez le service, puis demande comment le retirer des fichiers. S’il trouve une vraie donnée personnelle, elle ne se change pas comme une clé : d’après la CNIL, elle peut rester dans l’historique même après modification, et il faut purger complètement le dépôt. Le plus simple : repars d’un dépôt neuf (un nouveau dossier, git init, avec seulement la version corrigée de tes fichiers), et ne publie jamais l’ancien (leçon 7).

4Étape 4 : Les données de ton outil

Relis la partie « Les données » de ta spécification. Chaque donnée est-elle nécessaire ? Les données d’essai sont-elles inventées ?

Faire toi-même

Vérifie que ton .gitignore exclut .env et tes sauvegardes, et qu’aucun secret n’est dans l’historique.
Fais la liste des services extérieurs de tes pages, et retire ceux qui ne servent pas.
Note dans ton journal : où sont tes secrets, et comment les changer en cas de fuite.

Vérifier

C’est réussi si :

aucune page et aucune version Git ne contient de secret ;
.env est exclu par le .gitignore, et tu sais que l’agent peut quand même le lire ;
chaque service extérieur de tes pages est voulu ;
les données de ton outil sont réduites au nécessaire, et les essais se font avec des données inventées.

Erreurs fréquentes :

coller une vraie clé dans la conversation « pour aller plus vite » ;
croire qu’un fichier dans le .gitignore est invisible pour l’agent ;
nettoyer l’historique au lieu de changer d’abord la clé ;
accepter un service extérieur ajouté par l’agent sans l’avoir demandé.

Conserver et reprendre

Garde dans ton journal la liste de tes secrets (leur nom et le service, jamais leur valeur) et la façon de les changer.
À chaque nouvelle fonction de ton outil, repose les deux questions : un secret ? un service extérieur ?

Pour aller plus loin

facultatif

Si ta page doit vraiment utiliser une clé, il faut un serveur intermédiaire qui la garde : c’est un autre niveau, hors de ce module.
Le guide RGPD du développeur de la CNIL détaille la gestion du code source, des utilisateurs et des durées de conservation.

Mots nouveaux

5 mots expliqués

Mot	Ce que ça veut dire
Secret	Une clé d’accès, un mot de passe ou un jeton, qui donne accès à un service
Fichier .env	Le fichier où l’on range les secrets d’un projet, hors de Git
Faire pivoter un secret	Le remplacer par un nouveau chez le service, pour que l’ancien ne marche plus
Service extérieur	Un service sur Internet que ta page appelle
Surface d’attaque	Tout ce qui, dans un outil, pourrait servir à l’attaquer

L’essai de l’étape 1 a été joué réellement avec Claude Code 2.1.310, avec une fausse clé, dans un dossier d’essai isolé (rapport de tests, T57). Les séances d’essai avec Claude Code ont été jouées en mode non interactif (claude -p), une seule fois chacune : ce que tu verras peut différer (demandes d’autorisation, formulation, nombre de questions). À vérifier : les demandes des étapes 2 et 3 n’ont pas été jouées.