À ne pas rater

Sécurité

Une clé exposée, un dépôt privé partagé, un prompt qui exécute n'importe quoi : les accidents arrivent vite. Voici comment les éviter et quoi faire quand c'est trop tard.

Les 5 règles d'or

La sécurité d'un projet ne tient pas à un outil magique : elle tient à quelques réflexes, appliqués à chaque fois. Si vous ne lisez qu'une seule partie de cette page, lisez celle-ci.

Un secret ne se met ni dans un dépôt, ni dans un prompt, ni dans une capture d'écran.
Le fichier .env s'ignore AVANT le premier commit, jamais après.
« Privé » ne veut pas dire « secret » : un dépôt peut devenir public en un clic.
L'agent exécute exactement ce que vous demandez : relisez avant d'accepter, committez avant les grosses modifications.
En cas de fuite : on tourne la clé d'abord, on nettoie le dépôt ensuite. Jamais l'inverse.

Un secret n'est pas une information comme les autres

Avant de publier quoi que ce soit, classez l'information. Ce n'est pas la même chose de partager l'adresse de son site et de partager la clé qui permet de le modifier.

Type	Exemples	Ce que vous pouvez en faire
Public	L'URL du site, le nom du projet, la liste des outils utilisés	Partager librement : c'est fait pour.
Privé	Votre code, vos notes, vos idées, vos prompts	Visible seulement par vous ; ne pas le rendre public sans réfléchir.
Secret	Clé d'API, jeton d'accès, mot de passe, cookie de session	Ne jamais publier, ne jamais écrire dans un prompt, ne jamais montrer en capture.

Trois secrets à reconnaître dans ce projet

La clé du modèle (DeepSeek ou autre) : elle paie chaque requête. Exposée, elle permet à n'importe qui de dépenser sur votre compte.
Le jeton Cloudflare : il peut déployer, modifier les DNS, créer des ressources. Exposé, c'est votre compte qui est en danger, pas seulement le projet.
Les mots de passe (compte GitHub, espace prof) : même un mot de passe « pas important » ouvre une porte à laquelle vous n'avez pas pensé.

Piège n°1 — le secret dans le dépôt

C'est l'accident numéro un des projets qui utilisent une IA : le fichier .env qui contient la clé se retrouve poussé sur GitHub. Pourquoi ? Parce que le fichier était là avant, et qu'un git add . ne fait pas la différence.

# ❌ Ce .env part sur GitHub avec le reste
DEEPSEEK_API_KEY=sk-9f2c…
CLOUDFLARE_API_TOKEN=cfut_4b1e…

La protection s'écrit avant le premier commit, dans .gitignore :

# ✅ .gitignore — le .env reste sur votre machine
.env
.env.*
!.env.example

# Un modèle sans valeurs peut être commité pour documenter
# les variables attendues (voir .env.example)

Les trois réflexes à prendre dès maintenant

Ignorer avant de créer : le .gitignore est le premier fichier d'un projet, pas le dernier.
Vérifier : git check-ignore .env doit afficher .env. Si la commande n'affiche rien, le fichier est suivi : alerte rouge.
Restreindre : chmod 600 .env pour que seul votre compte puisse le lire sur la machine.

Retirer un fichier ne l'efface pas Un fichier supprimé dans un nouveau commit reste lisible dans l'historique : n'importe qui peut afficher l'ancienne version et y trouver la clé. C'est pour cela qu'on tourne la clé d'abord et qu'on nettoie l'historique ensuite.

Piège n°2 — « privé » ne veut pas dire « secret »

Un dépôt privé est un dépôt fermé au public, pas un coffre-fort. Il peut devenir public en un clic, un collaborateur peut en copier le contenu, et une capture d'écran partagée dans un fil de discussion contourne toutes les protections.

Le dépôt privé protège le travail, pas les secrets. Les secrets ne doivent être dans aucun dépôt, privé ou public.
Le site déployé, lui, est public par nature. Tout ce qui est dans le dossier publié est visible : n'y mettez jamais de données internes ou personnelles.
Les variables d'environnement de la plateforme sont faites pour ça : chez Cloudflare, les secrets de déploiement se déclarent dans les réglages du projet, pas dans un fichier poussé.

La bonne question avant chaque envoi « Si ce contenu devenait public demain matin, que se passerait-il ? » Si la réponse est « rien de grave », envoyez. Sinon, retirez-le.

Piège n°3 — l'agent exécute exactement ce que vous demandez

Un agent n'est pas prudent : il est obéissant. Si vous demandez « fais fonctionner le site », il peut supprimer un fichier qui le gêne, réinstaller des dépendances, réécrire une configuration ou lancer une commande destructrice. Ce n'est pas de la malveillance : c'est le résultat d'un ordre trop vague.

Lisez ce qu'il propose avant d'accepter une modification importante, surtout une suppression ou une commande inhabituelle.
Committez avant les grosses demandes : un commit est un point de retour. C'est aussi une protection contre l'agent lui-même.
Utilisez le mode plan (voir la section OpenCode) pour faire décrire la manœuvre avant qu'elle soit exécutée.
Ne collez jamais une commande trouvée sur Internet sans comprendre ce qu'elle fait, même si elle promet de tout réparer.

Un ordre précis vaut mieux qu'un ordre poli « Supprime les fichiers inutiles » est dangereux. « Liste les fichiers que tu juges inutiles et explique pourquoi, sans rien supprimer » est vérifiable. La précision est une mesure de sécurité.

Piège n°4 — ce qu'on ne met jamais dans un projet ni dans un prompt

Les données personnelles ne sont pas des secrets : ce sont des informations protégées par le RGPD. Un dépôt GitHub, un prompt envoyé à une IA ou un site publié ne sont pas des endroits pour elles.

Jamais : noms et prénoms de camarades, numéros de téléphone, adresses, dates de naissance, notes, photos de personnes, informations de santé.
À la place : un pseudonyme choisi par la personne, ou un code anonyme (comme les codes de dépôt de ce site).
Pour un site de classe : demandez l'accord des personnes citées ou photographiées, et ne publiez rien qui permette de les identifier ou de les localiser.

Le prompt n'est pas un espace privé Ce que vous écrivez dans un prompt peut être conservé, analysé ou réutilisé par le service. Un secret ou une donnée personnelle envoyé dans un prompt doit être considéré comme publié.

Piège n°5 — l'IA se trompe avec assurance

Un modèle de langage produit du texte plausible, pas du texte vrai. Il peut inventer une fonction qui n'existe pas, une bibliothèque imaginaire, une commande dangereuse — avec le même ton confiant que lorsqu'il a raison.

Testez : une réponse non exécutée n'est pas une réponse vérifiée.
Demandez pourquoi : « explique ce que fait cette ligne et pourquoi tu l'as choisie ».
Lisez les erreurs : le message d'erreur, traduit, dit souvent exactement quoi corriger (voir la page Dépannage).
Ne signez jamais ce que vous ne comprenez pas : le projet est évalué sur votre compréhension, pas sur le volume produit.

Que faire en cas de fuite — la procédure

L'ordre des étapes n'est pas négociable : une clé exposée doit mourir avant qu'on s'occupe du dépôt. Nettoyer d'abord, c'est laisser la porte ouverte pendant ce temps.

Tourner la clé, immédiatement. Révoquez le secret là où il a été créé (DeepSeek, Cloudflare, GitHub…), puis créez-en un nouveau. Tant que la clé est vivante, considérez qu'elle est déjà utilisée par quelqu'un d'autre : les robots qui scannent GitHub sont plus rapides que vous.
Nettoyer le dépôt. Retirez le fichier du suivi (`git rm --cached .env`), ajoutez-le au `.gitignore`, committez un état propre. Cela protège la suite, mais ne l'efface pas du passé.
Purger l'historique si nécessaire. Un fichier retiré reste lisible dans les anciens commits. Pour un vrai secret, l'histoire se réécrit avec `git filter-repo`, puis on pousse en force. Pour un projet d'élève, la rotation de la clé règle souvent l'essentiel : une clé morte dans l'historique n'est plus dangereuse.
Prévenir, et vérifier les dégâts. Si c'est un secret partagé ou un jeton de compte, prévenez immédiatement l'enseignant. Regardez l'historique des dépenses et des déploiements : une clé peut avoir été utilisée sans que rien ne vous alerte.

À vous : trouvez la fuite

Sept extraits de fichiers, une seule question : ce contenu peut-il être publié sans danger ? Répondez, puis lisez l'explication.

Score : 0 / 0 — choisissez « Fuite » ou « Pas une fuite » pour chaque situation.

.env

DEEPSEEK_API_KEY=sk-9f2c…
CLOUDFLARE_API_TOKEN=cfut_4b1e…

.gitignore

.env
.env.*
!.env.example
.dev.vars

README.md

curl https://api.deepseek.com -H "Authorization: Bearer sk-9f2c…"

src/config.ts

export const CLOUDFLARE_TOKEN = "cfut_4b1e…";
export const API_URL = "https://api.exemple.fr";

src/pages/index.astro

<a href="https://mon-projet.pages.dev">Voir mon site</a>

notes.txt

Groupe 3 : Lina, 06 12 34 56 78, née le 12/03/2010 — compte rendu à rendre

package.json

{ "dependencies": { "astro": "^7.3.5", "tailwindcss": "^4.3.3" } }

La checklist avant de publier

À parcourir avant chaque push ou chaque déploiement. Si une case reste vide, ne publiez pas.

.env n'est pas suivi par Git : git check-ignore .env affiche bien .env.
Aucune clé, aucun jeton, aucun mot de passe dans le code, le README ou les exemples.
Aucune donnée personnelle (nom, téléphone, adresse, photo, date de naissance) dans le dépôt ni dans un prompt.
Le dépôt ne contient que ce que vous accepteriez de voir public : un dépôt privé peut le devenir.
Le mot de passe de l'espace prof n'est écrit nulle part dans le dépôt.
Le site déployé n'expose pas de page technique (fichiers de configuration, API d'administration) sans protection.
Vous savez quelle clé tourner en premier si quelque chose fuit.

Pour aller plus loin

Dépôt