Sécurité de l'application

Une application moderne distingue deux types de configuration : ce qui est spécifique au déploiement (URL de la base de données, clés d'API, mots de passe de service) et ce qui est commun à tous les déploiements (logique métier, structure de page, comportements).

La configuration spécifique vit dans des variables d'environnement, généralement chargées au démarrage depuis un fichier .env. Ce fichier ne doit jamais être versionné dans Git. La règle est simple et non négociable.

Le mécanisme : un fichier .env contient des paires CLE=valeur ; l'application les lit ; un fichier .gitignore liste .env pour empêcher Git de le suivre. Une variante .env.example est versionnée — elle contient les noms des variables sans les valeurs, pour que les autres développeurs sachent ce qu'ils doivent configurer.

En développement local, les secrets vivent dans .env sur votre machine. En production, ils doivent vivre dans le système de secrets de votre plateforme : Vercel Environment Variables, Supabase secrets, AWS Secrets Manager, GitHub Actions secrets selon le contexte. Ces systèmes chiffrent les secrets au repos et n'exposent les valeurs qu'au moment de l'exécution.

Ne stockez jamais un secret dans le code source, même temporairement, même « le temps de tester ». Un secret poussé sur GitHub, même dans un dépôt privé, doit être considéré comme compromis et révoqué immédiatement.

Pour une application qui sert des utilisateurs, l'authentification est l'angle mort le plus dangereux. Trois principes pour ne pas se rater :

Utilisez une bibliothèque éprouvée. N'écrivez pas votre propre système de hachage de mot de passe ni votre propre logique de session. Supabase Auth, Auth.js, Clerk, Firebase Auth — choisissez selon votre stack et restez sur des solutions maintenues.

HTTPS partout. Y compris en local pour les tests. Vercel et la plupart des hébergeurs gèrent automatiquement les certificats. Ne servez jamais une application en HTTP brut au-delà de votre machine.

Validation côté serveur. Tout ce qui arrive du client est suspect. Validez les entrées, autorisez les actions à chaque requête, ne faites pas confiance à un état envoyé par le navigateur.

Si votre application traite des données personnelles d'utilisateurs européens (et vous avez de fortes chances d'en être là), le RGPD s'applique. Trois obligations qui structurent les premières heures de développement :

Minimisation des données. Ne collectez que ce qui est strictement nécessaire à votre service. Pas d'« on prend tout au cas où ».

Information et consentement. Une politique de confidentialité claire, un consentement explicite pour les cookies non essentiels et pour les traitements optionnels.

Droits d'accès et de suppression. Un mécanisme par lequel un utilisateur peut consulter ses données et demander leur suppression. Pas forcément automatisé d'emblée, mais documenté et opérationnel.

Pour les formations Qualiopi, ce point est particulièrement sensible : les données de stagiaires (identité, parcours, évaluations) sont des données personnelles à part entière. Documentez vos traitements dans un registre, même léger.

Procédure à appliquer dès qu'un projet sort du « hello world ». Comptez vingt minutes.