YOAT Lab
07 · Module 2 — Intégration éditeur et sécurité

Sécurité de l'application

Les erreurs de sécurité les plus fréquentes sont aussi
les plus simples à éviter. Une leçon qui sauve des projets.

11 minutesVariables d'environnementRGPD · Auth · HTTPS
§01 · Pourquoi aborder la sécurité maintenant

Les erreurs se font au démarrage

La plupart des incidents de sécurité applicative ne viennent pas d'attaques sophistiquées. Ils viennent d'erreurs basiques commises en début de projet : clés API dans le code, mots de passe en clair, HTTP en production. Aborder la sécurité dès le départ coûte 30 minutes. La corriger après incident coûte infiniment plus.

Claude Code et la sécurité

Claude génère du code rapide. Il ne génère pas toujours du code sécurisé par défaut. Votre vigilance s'applique toujours, quel que soit l'auteur du code — vous ou l'agent. Cette leçon vous donne les réflexes pour lire le code de Claude avec l'œil de la sécurité.

§02 · Les variables d'environnement

La règle numéro un : jamais de secret dans le code

La première règle de sécurité applicative : ne jamais mettre de secret (clé API, mot de passe, token, connexion base) directement dans le code source. Ni dans le HTML, ni dans le JavaScript, ni dans aucun fichier versionné.

Le problème

Secret dans le code = secret public

Un dépôt Git poussé sur GitHub avec une clé API dans le code — même 30 secondes — suffit. Des bots parcourent GitHub en continu et volent les clés exposées.

La solution

Fichier .env

Un fichier texte à la racine du projet, jamais versionné. Chaque ligne = une variable. SUPABASE_KEY=..., API_SECRET=...

Le .gitignore

Protéger le .env

Ajouter .env dans le fichier .gitignore dès la création du projet. Git ne le verra jamais, ne le poussera jamais.

En production

Variables d'environnement serveur

Sur Vercel, Supabase, Heroku : les secrets s'ajoutent dans les paramètres de l'interface, jamais dans le code déployé.

§03 · HTTPS en production

Pas de HTTP en dehors du développement local

1.
En développement local (localhost), HTTP est acceptable. Votre trafic ne quitte pas votre machine.
2.
Dès que l'application est exposée — un utilisateur peut s'y connecter depuis son navigateur — il faut HTTPS. Sans HTTPS, les identifiants et données transitent en clair sur le réseau.
3.
Sur Vercel (leçon 14), HTTPS est automatique et gratuit. Sur les hébergements classiques, Let's Encrypt fournit des certificats gratuits. Il n'y a plus aucune excuse pour HTTP en production en 2026.
§04 · Authentification — bases

Ne jamais coder l'auth soi-même

L'authentification (connexion, session, permissions) est le domaine où les erreurs de sécurité sont les plus graves et les plus courantes. La règle absolue : déléguer à un service spécialisé.

Pourquoi déléguer

La complexité est sous-estimée

Stockage des mots de passe (bcrypt, argon2), gestion des sessions, tokens JWT, rotation des clés, protection contre le brute force, OAuth... Ce n'est pas trivial.

Supabase Auth

Le choix de la stack

Supabase intègre un service d'authentification complet (email, Google, GitHub...). Configuré en leçon 8. Gratuit, fiable, RGPD-friendly en région UE.

Nextauth / Auth.js

Alternative populaire

Pour les projets Next.js. Intégration claire avec Supabase. Bien documenté, adopté massivement en 2025-2026.

Jamais custom

Erreur classique

Coder sa propre table users avec un champ password en MD5 ou SHA1. C'est la faille la plus exploitée. Ne jamais faire ça.

§05 · RGPD — l'essentiel pratique

Cinq points non négociables

1

Données dans l'UE

Choisir des hébergeurs avec région UE disponible. Supabase : région Frankfurt. Vercel : région Frankfurt disponible. Déclarer la localisation dans la politique de confidentialité.

2

Minimisation des données

Ne collecter que ce qui est strictement nécessaire. Pas d'adresse IP inutile, pas de tracking comportemental non consenti.

3

Durée de conservation

Définir et appliquer une durée de conservation. Les données ne s'accumulent pas indéfiniment.

4

Politique de confidentialité

Obligatoire dès qu'un utilisateur s'inscrit ou que des cookies non essentiels sont déposés.

5

Droit à l'effacement

Prévoir une procédure pour supprimer un compte et ses données sur demande. Techniquement simple, juridiquement obligatoire.

§06 · Revue du code de Claude

Ce qu'il faut toujours vérifier

Quand Claude Code génère du code impliquant des données ou des accès, vérifiez systématiquement ces trois points avant d'accepter la modification.

Clés et secrets

Aucun secret en dur

Cherchez dans le code généré : clé API, token, mot de passe, connexion. Si vous en voyez, c'est un problème. Demandez à Claude de les mettre dans le fichier point env.

Validation des entrées

Tout input est suspect

Claude peut omettre la validation des données saisies par l'utilisateur. Toujours vérifier que les champs de formulaire sont validés côté serveur, pas seulement côté client.

Logs de production

Pas de données sensibles dans les logs

Claude peut ajouter des console.log de débogage avec des données utilisateur. Vérifier qu'aucun log en production n'expose d'identifiants, de tokens ou de données personnelles.

Fin · Leçon 07 acquise

Cap sur la leçon 08

Vous avez les réflexes de sécurité essentiels. La leçon suivante installe Supabase — base de données PostgreSQL hébergée, avec son service d'authentification intégré.

Exercice — appropriation

Sur votre projet de référence : (1) créez un fichier .env à la racine avec vos premières variables (au minimum une clé fictive pour la forme), (2) vérifiez que .env est bien dans .gitignore, (3) demandez à Claude de relire le code de votre projet et de signaler tout secret potentiellement exposé. Notez ce qu'il trouve.

Quiz · Validation des acquis

Quiz · Sécurité de l'application

8 questions · une seule bonne réponse par question · vous pouvez recommencer autant de fois que nécessaire.

1 / 8
Vrai ou faux

Il est acceptable de stocker une clé API directement dans le code JavaScript si le dépôt est privé sur GitHub.

Cliquez sur lecture pour démarrer.
§00 · Intro 0:00 / 11:00 Voix activée