Une checklist sécurité avant mise en production couvre l'authentification, les secrets, les dépendances et le RGPD. Points de contrôle essentiels pour une PME.
La majorité des failles de sécurité découvertes après une mise en ligne existaient déjà avant le déploiement — elles n'ont simplement jamais été vérifiées. Une checklist de mise en production sert exactement à ça : transformer des bonnes pratiques diffuses en points de contrôle vérifiables un par un, avant que l'application ne soit exposée publiquement.
Qu'est-ce qu'une checklist sécurité avant mise en production ?
C'est une liste de contrôles techniques et organisationnels vérifiés systématiquement avant chaque déploiement, couvrant l'authentification, la gestion des secrets, les dépendances logicielles et la conformité réglementaire. Elle remplace une vérification informelle, dépendante de la mémoire d'un développeur, par un processus reproductible et traçable.
Quels contrôles vérifier sur l'authentification et les accès ?
- Mots de passe hashés avec un algorithme adapté (bcrypt, argon2) — jamais en clair ni en MD5/SHA1
- Limitation du nombre de tentatives de connexion (protection brute-force)
- Sessions expirées après inactivité, cookies en
SecureetHttpOnly - Comptes admin protégés par une authentification forte, jamais par un mot de passe par défaut
- Principe du moindre privilège : chaque compte n'a accès qu'aux ressources strictement nécessaires à son rôle
Ce dernier point est souvent négligé dans les petites structures, où un seul compte administrateur cumule tous les droits par simplicité. C'est justement ce compte qui, en cas de compromission, expose l'intégralité du système.
Comment gérer les secrets et clés API avant un déploiement ?
Aucun secret — clé API, mot de passe de base de données, token de service tiers — ne doit apparaître dans le code source ni dans un commit Git, même dans l'historique. Les secrets réels vivent dans des variables d'environnement injectées au niveau du serveur, jamais commitées. Un secret qui a fuité dans un historique Git doit être révoqué immédiatement, pas seulement supprimé du fichier : un attaquant qui consulte l'historique le retrouvera malgré tout.
Un contrôle simple avant chaque déploiement : lancer un scan de secrets sur le dépôt (recherche de motifs de clés API, tokens, chaînes de connexion) pour détecter ce qui aurait pu être ajouté par erreur dans un commit récent.
Faut-il auditer les dépendances avant chaque mise en production ?
Oui — une dépendance PHP, JS ou système avec une vulnérabilité connue (CVE publiée) expose l'application même si le code applicatif est propre. Un contrôle automatisé des dépendances (audit de composer/npm) avant chaque déploiement évite de livrer une faille déjà documentée publiquement. Ce contrôle prend quelques secondes à exécuter et détecte des vulnérabilités qu'une revue de code manuelle ne verra jamais, puisqu'elles se situent dans du code tiers non écrit par l'équipe.
Quels contrôles réseau et applicatifs vérifier ?
| Domaine | Contrôle |
|---|---|
| Réseau | HTTPS forcé, certificat valide, en-têtes de sécurité (CSP, HSTS) |
| Formulaires | Protection CSRF active, validation serveur systématique — jamais côté client seul |
| Base de données | Requêtes paramétrées uniquement, jamais de concaténation SQL |
| Logs | Aucune donnée sensible (mot de passe, token, numéro de carte) loguée en clair |
| Uploads | Type et taille de fichier validés côté serveur, exécution de scripts empêchée dans le dossier d'upload |
| RGPD | Consentement traceurs, durée de conservation définie, page de confidentialité à jour |
Ces contrôles recoupent une bonne partie du référentiel OWASP Top 10, la liste des vulnérabilités web les plus fréquentes maintenue par l'Open Web Application Security Project — une référence standard pour tout audit de sécurité applicative, PME ou grand groupe.
Qui doit valider cette checklist avant le déploiement ?
La checklist doit être validée par une personne distincte de celle qui a développé la fonctionnalité, même dans une petite structure — un regard extérieur détecte ce que l'auteur du code ne voit plus après plusieurs jours dessus. Standardiser ce contrôle dans le pipeline de déploiement (CI/CD) évite qu'il dépende de la mémoire d'une seule personne, et garantit qu'aucune mise en production n'échappe à la vérification, y compris dans l'urgence.
À quelle fréquence revoir cette checklist ?
Une checklist sécurité n'est pas figée : elle doit évoluer à chaque nouvelle vulnérabilité majeure découverte dans l'écosystème utilisé (PHP, Symfony, bibliothèques JS), et être revue au minimum une fois par an même sans incident. Une checklist jamais mise à jour depuis deux ou trois ans donne une fausse impression de sécurité — les menaces évoluent plus vite que les habitudes internes.
Que faire en plus d'une checklist technique ?
La checklist réduit le risque, elle ne l'élimine pas. Deux compléments renforcent durablement la posture de sécurité d'une PME :
- Un test d'intrusion périodique — un audit externe qui tente activement d'exploiter des failles, plutôt qu'une simple revue de contrôles. Recommandé au minimum avant une refonte majeure ou une fois par an sur une application traitant des données sensibles.
- Une sensibilisation minimale des équipes — la majorité des compromissions passent par un facteur humain (phishing, mot de passe réutilisé) plutôt que par une faille technique. Un rappel annuel des bons réflexes coûte peu et réduit un risque que la checklist technique ne couvre pas.
Un plan de reprise minimal — que faire si un incident survient malgré tout (isolement, restauration depuis une sauvegarde, communication) — complète utilement cette checklist préventive.
Cette checklist couvre le socle technique — pour les garanties contractuelles et réglementaires à exiger d'un prestataire, voir sécurité web et RGPD pour PME. Elle s'ajoute aux contrôles de performance vérifiés avant mise en ligne, détaillés dans l'impact réel des Core Web Vitals. Pour un audit sécurité complet avant votre prochain déploiement, contactez KSolution.
