La sécurité

La sécurité est le domaine où les erreurs coûtent le plus cher — et où l’IA vous laisse le plus seul. Claude peut écrire un code fonctionnel et malgré tout dangereux, car un code qui « marche » n’est pas un code « sûr ». Ce module couvre les réflexes indispensables, expliqués simplement. Aucun n’est réservé aux experts, mais tous sont non négociables dès que de vraies données entrent en jeu.

Le réflexe que l’IA n’aura pas pour vous

L’IA n’est pas responsable de la sécurité de votre projet — vous l’êtes.

Claude ne vous préviendra pas spontanément que vous exposez une clé secrète ou que vous ouvrez une faille. Il fera ce que vous demandez, parfois de la manière la plus directe, qui n’est pas toujours la plus sûre. La bonne nouvelle : les failles les plus fréquentes sont aussi les plus évitables. Et vous pouvez faire de l’IA une alliée en la sollicitant : « Y a-t-il un risque de sécurité dans ce code ? Quelles bonnes pratiques appliquer ici ? »

Mots de passe et authentification

Première règle, absolue : on ne stocke jamais un mot de passe en clair. Un mot de passe doit être « haché » (transformé de manière irréversible) par des algorithmes prévus pour cela. En pratique, ne réinventez pas l’authentification vous-même : c’est l’un des domaines les plus piégeux du développement, et une erreur y est catastrophique. Utilisez des solutions éprouvées — Supabase Auth (Module 10) gère inscription, connexion, réinitialisation et hachage de façon sécurisée. Laisser une IA improviser un système d’authentification maison est l’une des idées les plus risquées qui soient.

Clés API et secrets : ne jamais les exposer

Une clé API est un identifiant secret qui donne accès à un service (base de données, e-mail, paiement…). La posséder, c’est pouvoir agir en votre nom — et parfois dépenser votre argent. Le piège classique, constant chez les débutants : écrire la clé directement dans le code, puis pousser ce code sur GitHub. La clé devient publique. Des robots scannent GitHub en permanence : une clé exposée peut être exploitée en quelques minutes. Des factures de plusieurs milliers d’euros ont été générées ainsi, en une nuit.

• Les secrets ne vivent jamais dans le code. Ils vivent dans des variables d’environnement (ci-dessous).
• On relit toujours le diff avant de committer (Module 5), précisément pour attraper une clé qui s’y serait glissée.

Si une clé a été exposée, une seule bonne réaction : la révoquer immédiatement et en générer une nouvelle. Une clé publiée un instant est compromise pour toujours.

Variables d’environnement (.env, .gitignore)

Une variable d’environnement est une valeur de configuration stockée hors du code, dans un fichier `.env.local`. Votre code lit la valeur sans jamais la contenir. Le mécanisme essentiel : ce fichier ne doit jamais être envoyé sur GitHub — on l’inscrit dans le `.gitignore`. Fournissez un `.env.example` sans les vraies valeurs pour documenter les variables nécessaires. En production, elles se configurent dans l’hébergeur (Vercel).

# Ne JAMAIS versionner les secrets
.env.local
.env*.local

# À versionner : un modèle sans valeurs
# .env.example  ->  SERVICE_API_KEY=

Point de vigilance propre à Next.js : une variable préfixée par NEXT_PUBLIC_ est exposée au navigateur, donc visible de tous. On n’y met jamais de secret — uniquement des valeurs publiques (une URL, par exemple). Confondre les deux est une erreur fréquente et grave : demandez à l’IA de confirmer, pour chaque variable, si elle est publique ou privée.

Les failles courantes

L’injection.

Des données envoyées par un utilisateur sont exécutées comme du code ou insérées telles quelles dans une requête. La parade : ne jamais faire confiance aux entrées, toujours les valider et les « nettoyer » (Zod aide — Module 10).

Le XSS.

Du contenu malveillant fourni par un utilisateur s’exécute dans le navigateur d’un autre. React protège en grande partie par défaut, mais certaines pratiques rouvrent la faille.

Les mauvaises permissions d’accès.

Un utilisateur accède à des données qui ne sont pas les siennes. L’une des failles les plus répandues sur les applications avec base de données.

L’exposition de données côté client.

Envoyer au navigateur plus d’informations qu’il n’en faut (données d’autres utilisateurs, champs sensibles).

Sécuriser une base de données

Avec une base comme Supabase (PostgreSQL), un concept est fondamental : le RLS (Row Level Security), la sécurité au niveau des lignes. Ce sont les règles qui déterminent, pour chaque utilisateur, quelles données il a le droit de lire ou de modifier. Sans RLS correctement configuré, une application peut laisser n’importe quel utilisateur accéder aux données de tous les autres — une faille majeure, hélas fréquente sur les projets démarrés vite. L’IA peut aider à écrire ces règles, mais la vérification humaine est indispensable : une règle trop permissive ne provoque aucune erreur visible… jusqu’à la fuite de données.