Un site qui s'affiche, c'est un site qui fonctionne. Pas un site qui est sûr. La confusion entre les deux m'a coûté cher : mon premier projet mis en ligne en grande pompe, avec un joli certificat vert et un formulaire de contact qui marchait du tonnerre. Trois semaines plus tard, un fichier .env traînait à la racine, accessible depuis n'importe quel navigateur. Mot de passe de la base de données en clair. J'ai appris ce jour-là que l'audit de sécurité se fait avant le lancement, pas après le premier incident.
Ce guide est celui que j'aurais voulu lire à l'époque. Il ne parle pas d'un site déjà en production — il parle du moment précis où vous vous apprêtez à appuyer sur le bouton, et où il est encore temps de rattraper le coup sans que personne ne s'en aperçoive.
Points clés à retenir
- Un audit pré-lancement dure 2 à 4 heures sur un site de taille moyenne, et il se fait sur l'environnement de pré-production, pas en production.
- Les trois fuites les plus fréquentes avant go-live : fichiers de configuration exposés, comptes de test encore actifs, environnement de staging indexé par Google.
- Distinction capitale : ce qui bloque le lancement (secrets exposés, absence de HTTPS, admin sans mot de passe fort) et ce qui peut attendre la semaine suivante.
- La conformité RGPD fait partie de l'audit sécurité. Un bandeau cookies mal configuré, c'est un risque juridique autant qu'un signal de négligence.
- Aucun outil ne remplace la lecture des fichiers. Les scanners trouvent 60 à 70 % des problèmes, le reste se voit à l'œil nu.
Pourquoi un audit de sécurité d'un site web avant lancement change tout
La différence entre un site audité avant mise en ligne et un site corrigé après coup ne tient pas à la technique. Elle tient au coût.
Un secret exposé repéré avant le lancement, c'est une variable à déplacer et cinq minutes de travail. Le même secret repéré après, c'est une rotation de clés, une vérification des logs d'accès sur 72 heures, une notification éventuelle aux utilisateurs concernés, et cette désagréable sensation d'avoir joué à la roulette russe avec les données de gens qui vous ont fait confiance. J'ai fait les deux. Je vous laisse deviner laquelle des deux nuits a été la plus courte.
Ce que les scanners automatiques ne voient pas
Les outils automatisés sont utiles. Ils sont aussi rassurants à tort. Un scanner détecte les en-têtes HTTP manquants, les versions de bibliothèques obsolètes, un certificat mal configuré. Il ne détectera jamais que votre fichier robots.txt de pré-production pointe encore vers le sitemap de staging. Ni que le compte test-admin avec le mot de passe test-admin est toujours actif. Ni que votre formulaire de contact renvoie le contenu de tous les champs dans un e-mail en copie cachée.
Le mien, de scanner, m'avait donné un score de 92/100 deux jours avant le lancement. Score vert. Fierté. Et un fichier de configuration lisible par tout le monde.
La confusion pré-production / production
Voilà l'angle mort de la plupart des checklists que j'ai pu lire : elles décrivent l'audit d'un site déjà en ligne. Or le moment le plus dangereux, c'est celui où l'environnement de pré-production est encore accessible publiquement, avec ses données factices, ses comptes de test, sa base de données non chiffrée et son indexation Google encore autorisée.
Vérifiez ce point en priorité. Si votre environnement de staging répond sur une URL publique et que Google l'a déjà indexée, vous avez un problème qui n'a rien à voir avec la sécurité du site final — et qui peut exposer exactement les mêmes informations sensibles.
Comment vérifier la sécurité d'un site web : la méthode en 4 passes
Quand on me demande comment vérifier la sécurité d'un site web, je réponds toujours la même chose : dans cet ordre précis. Pas celui des outils, celui du risque.
- Passe 1 — secrets et fichiers exposés. Tout ce qui traîne à la racine et qui ne devrait pas être lisible :
.env,config.php,.git/, sauvegardes.sql, fichiers de logs. - Passe 2 — authentification et comptes. Comptes de test supprimés ? Mot de passe admin solide ? Double authentification activée ? Rôles correctement attribués ?
- Passe 3 — transport et en-têtes. HTTPS forcé, redirection HTTP→HTTPS, en-têtes de sécurité (HSTS, Content-Security-Policy, X-Frame-Options).
- Passe 4 — messagerie et DNS. SPF, DKIM, DMARC configurés. E-mails transactionnels testés. Sous-domaines oubliés vérifiés.
Passe 1 : chasser les fichiers sensibles à la main
Ouvrez un terminal. Tapez quelques URL à la main. C'est fastidieux, c'est le seul moyen fiable.
votresite.com/.env— doit renvoyer 404, pas le contenu de vos variables.votresite.com/.git/config— idem. Si le dépôt est exposé, tout votre code source l'est.votresite.com/backup.sqlou toute variante — les sauvegardes oubliées à la racine sont un classique.votresite.com/phpinfo.php— un fichier de debug oublié révèle la version de PHP, les chemins serveur, les extensions chargées.
Sur mon dernier projet, cette passe a pris vingt minutes et a révélé deux choses : un README.md qui contenait les identifiants de connexion FTP (le développeur précédent avait documenté son déploiement, gentiment), et un dossier /old/ avec une version antérieure du site, sans aucune protection.
Passe 2 : authentification et comptes fantômes
Combien d'utilisateurs ont un accès administrateur sur votre site ? Si vous ne connaissez pas la réponse, c'est déjà un problème. Sur les projets que j'ai repris, j'ai systématiquement trouvé au moins deux comptes admin « temporaires » qui traînaient depuis dix-huit mois.
La règle est simple : après la mise en production, aucun compte de test ne survit. Aucun. Et l'admin principal a un mot de passe de 20 caractères minimum, stocké dans un gestionnaire, avec une double authentification activée. Si votre CMS ne supporte pas la double authentification nativement, il existe des extensions qui le font très bien.
Comment faire un audit de site web : le tableau de contrôle qui décide du lancement
Voici le tableau que j'utilise maintenant systématiquement. La colonne « bloquant » est celle qui compte : elle sépare ce qui vous fait reporter le lancement de ce qui peut attendre le lundi suivant.
| Contrôle | Outil / méthode | Seuil de réussite | Bloquant ? |
|---|---|---|---|
| Fichiers de configuration exposés | Accès manuel aux URL sensibles | 404 sur tous les chemins | Oui |
| HTTPS forcé + redirection | Navigateur (HTTP → HTTPS) | Redirection 301 permanente | Oui |
| En-têtes de sécurité | Scanner d'en-têtes en ligne | HSTS, CSP, X-Frame-Options présents | Non (mais à corriger sous 7 jours) |
| SPF / DKIM / DMARC | Vérification DNS | Les trois enregistrements valides | Oui sur SPF et DKIM, non sur DMARC strict |
| Comptes de test | Panneau d'administration | Zéro compte non légitime | Oui |
| Indexation du staging | Recherche site:staging.votresite.com | Aucun résultat | Oui |
| Bandeau cookies + politique de confidentialité | Vérification manuelle | Consentement préalable, finalités listées | Oui |
Ce tableau ne couvre pas tout, et c'est volontaire. Il couvre les erreurs qui font réellement mal le premier jour. Un audit complet à 200 points de contrôle, personne ne le fait avant un lancement — et un audit partiel qui tient debout vaut infiniment mieux qu'un audit parfait jamais exécuté.
Comment réaliser un audit de sécurité : les 4 critères à vérifier
Quand on me demande quels sont les 4 critères de sécurité qui structurent un audit, je réponds par ces quatre piliers. Ils sont indépendants les uns des autres, et un site peut échouer sur un seul et être vulnérable malgré les trois autres.
1. La confidentialité : qui peut lire quoi ?
C'est le critère qui m'a coûté le plus cher, comme raconté plus haut. Confidentialité signifie que les données sensibles (identifiants, données personnelles, secrets de configuration) ne sont accessibles qu'aux personnes et systèmes légitimes. Concrètement : fichiers de configuration protégés, base de données non exposée, communications chiffrées, logs sans données personnelles en clair.
2. L'intégrité : le contenu peut-il être modifié par un tiers ?
Un site dont le contenu peut être altéré par un attaquant n'est pas un site sûr, même s'il n'expose aucun secret. Cela passe par des bibliothèques à jour, un CMS patché, des formulaires protégés contre les injections, et des sauvegardes vérifiées — parce qu'une sauvegarde jamais testée n'est pas une sauvegarde, c'est une promesse.
3. La disponibilité : le site résiste-t-il à la charge et aux abus ?
Le dernier critère qu'on oublie toujours. Un site qui tombe sous une attaque par déni de service, même basique, n'est pas sécurisé. Limitation de débit sur les formulaires, protection contre les attaques par force brute sur la page de connexion, pare-feu applicatif si le trafic le justifie.
4. La traçabilité : saura-t-on ce qui s'est passé ?
Si un incident survient après le lancement, pourrez-vous reconstituer la séquence ? Journaux d'accès activés, horodatés, conservés assez longtemps, et — détail que j'ai négligé pendant des mois — vraiment lisibles. Un log de 400 000 lignes que personne ne consulte ne remplit pas ce critère. Il donne juste bonne conscience.
La checklist go-live : ce qui reste à faire dans les dernières 48 heures
Le jour du lancement, la liste se réduit à une poignée de vérifications concrètes. Celles-ci, je les coche désormais une par une, dans l'ordre :
- Le fichier
robots.txtde production autorise bien l'indexation, et celui du staging la bloque — pas l'inverse. - Les e-mails transactionnels (inscription, mot de passe oublié, confirmation de commande) arrivent réellement dans une boîte Gmail, pas seulement dans un dossier spam introuvable.
- Le certificat SSL couvre bien les sous-domaines utilisés (souvent oublié :
www,api,mail). - La page de connexion admin n'est pas accessible via une URL devinable sans protection anti-force brute.
- Le bandeau cookies bloque réellement les scripts de mesure d'audience avant consentement — pas seulement l'affichage visuel.
- Les comptes créés pendant les tests sont supprimés. Tous.
Sur ce dernier point, franchement, je me suis fait avoir deux fois. Deux. Il y a toujours un compte oublié, souvent celui créé à la va-vite pour un test de paiement un vendredi soir.
Et le RGPD dans tout ça ?
La conformité réglementaire ne se substitue pas à l'audit technique, elle le complète. Trois éléments à vérifier avant mise en ligne : mentions légales complètes, politique de confidentialité qui décrit réellement les traitements effectués (pas un copier-coller générique), et consentement aux cookies recueilli avant tout dépôt de traceur non essentiel. Ce n'est pas de la paperasse : un site qui collecte des données sans base légale claire expose son éditeur, indépendamment de toute faille technique.
Ce que j'aurais aimé savoir avant mon premier lancement
L'audit de sécurité avant lancement n'est pas un examen qu'on passe ou qu'on rate. C'est une lecture attentive de ce qu'on a construit, faite à un moment où les corrections coûtent encore presque rien.
Les outils gratuits font le travail de surface en une heure. La lecture manuelle des fichiers, la vérification des comptes, le test réel des e-mails — c'est là que se trouvent les problèmes qui comptent vraiment, et personne ne le fera à votre place. Un scanner vous donnera un score. Ce score ne vous dira jamais que votre fichier .env est lisible par le premier venu.
Alors avant d'appuyer sur le bouton : ouvrez un terminal, tapez votresite.com/.env, et regardez ce qui s'affiche. Si la réponse vous fait sourire, vous êtes prêt. Si elle vous fait pâlir, vous venez de gagner plusieurs semaines de tranquillité — et probablement une nuit de sommeil.
