Audit de sécurité d'un site web
La demande arrive rarement seule. Elle vient d'un client qui exige une preuve avant de signer, d'un assureur qui conditionne sa garantie, d'une autorité qui pose des questions après un incident, ou d'un dirigeant qui a lu une actualité et veut savoir où il en est.
Le mot « audit » recouvre pourtant des prestations qui n'ont ni le même coût, ni la même valeur de preuve. Un rapport de 4 pages produit par un outil automatisé et une revue de code de 5 jours portent le même nom et ne répondent pas à la même question. Cette page décrit ce qui est réellement regardé, ce que chaque niveau ne voit pas, et ce qu'un rapport doit contenir pour servir à quelque chose.
Ce que la loi exige, et ce qu'elle n'exige pas
Aucun texte français ou luxembourgeois n'impose « un audit de sécurité » sous ce nom. Ce qui est imposé, c'est une obligation de résultat proportionnée au risque, assortie d'une obligation de vérifier que les mesures prises fonctionnent. L'audit est le moyen usuel de tenir la seconde.
L'article 32 du RGPD, applicable en France comme au Luxembourg
Le règlement impose au responsable du traitement et au sous-traitant de mettre en œuvre « les mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque ». Parmi ces mesures, le point d) du paragraphe 1 cite explicitement :
« une procédure visant à tester, à analyser et à évaluer régulièrement l'efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement ».
Deux précisions de portée, souvent perdues dans les résumés. Le texte s'applique dès qu'il y a traitement de données personnelles, donc à un simple formulaire de contact. Et les mesures sont dues « selon les besoins », c'est-à-dire proportionnées au risque : un site vitrine et une plateforme de santé ne sont pas tenus au même effort.
Les autres régimes qui peuvent s'ajouter
- NIS2 pour les entités des secteurs couverts, avec une exigence d'évaluation régulière de l'efficacité des mesures. Le périmètre, les seuils et le calendrier sont détaillés dans notre guide de mise en conformité NIS2 et sa déclinaison luxembourgeoise.
- Les exigences contractuelles, souvent plus contraignantes que la loi. Un marché public ou un contrat grand compte peut réclamer un rapport daté de moins de 12 mois, ce qu'aucun texte n'impose.
- Les conditions d'assurance cyber, qui subordonnent fréquemment la garantie à des mesures vérifiables et à leur contrôle périodique.
En France, l'autorité de référence sur la protection des données est la CNIL, et l'ANSSI publie les référentiels techniques. Au Luxembourg, la CNPD tient le même rôle que la CNIL, le Haut-Commissariat à la protection nationale coordonne la cybersécurité de l'État, et le CIRCL assure la réponse aux incidents pour le secteur privé et les communes.
Les 10 risques de référence, édition 2025
Le classement de l'OWASP fait consensus dans la profession et sert de socle à la plupart des méthodologies d'audit applicatif. Sa version 2025 remplace celle de 2021. Une grille encore fondée sur l'édition 2021 mérite donc d'être vérifiée avant de commander un audit.
OWASP Top 10:2025
- A01 Broken Access Control, contrôle d'accès défaillant. Un utilisateur atteint une ressource qui ne lui est pas destinée.
- A02 Security Misconfiguration, mauvaise configuration. En-têtes absents, service de débogage laissé ouvert, droits trop larges.
- A03 Software Supply Chain Failures, défaillances de la chaîne d'approvisionnement logicielle. Catégorie nouvelle et montée en 3e position, elle vise les dépendances : modules, bibliothèques, paquets tiers.
- A04 Cryptographic Failures, défauts de chiffrement, en transit comme au repos.
- A05 Injection, dont l'injection SQL et l'exécution de script côté client.
- A06 Insecure Design, conception non sécurisée. Le défaut est dans le modèle, pas dans le code.
- A07 Authentication Failures, défaillances d'authentification et de gestion de session.
- A08 Software or Data Integrity Failures, atteintes à l'intégrité du logiciel ou des données, notamment lors des mises à jour.
- A09 Security Logging and Alerting Failures, journalisation et alerte insuffisantes. Sans traces, un incident reste invisible et indémontrable.
- A10 Mishandling of Exceptional Conditions, mauvaise gestion des conditions exceptionnelles.
L'arrivée de la chaîne d'approvisionnement en 3e position est le changement le plus parlant pour un site professionnel. Un site Drupal ou Symfony repose sur des dizaines de dépendances qu'aucune équipe ne relit ligne à ligne. La sécurité du projet devient celle de son maillon le plus faible, et ce maillon est très rarement le code que vous avez payé.
Les 4 niveaux d'audit, et ce que chacun ne voit pas
C'est ici que se joue l'essentiel du malentendu commercial. Les 4 niveaux ci-dessous se cumulent, ils ne se remplacent pas. Le point important de chaque ligne est ce qu'elle ne détecte pas.
1. Le scan automatisé
Un outil compare votre site à une base de vulnérabilités connues et vérifie la configuration exposée. Rapide, reproductible, peu coûteux.
Ne détecte pas : les failles de logique métier, les défauts de contrôle d'accès propres à votre application, tout ce qui exige de comprendre à quoi sert le site. Un scan sans faille signalée ne veut pas dire un site sûr.
2. L'audit de configuration et d'exposition
Revue humaine de l'hébergement, des en-têtes, des certificats, des droits, des sauvegardes, des accès d'administration et des services laissés ouverts. C'est le niveau qui donne le meilleur rapport entre l'effort et le risque écarté.
Ne détecte pas : les vulnérabilités présentes dans le code applicatif lui-même.
3. La revue de code et des dépendances
Lecture du code écrit pour le projet, et inventaire des dépendances avec leur état de maintenance et leurs failles publiées. C'est le seul niveau qui traite sérieusement la catégorie A03.
Ne détecte pas : ce qui n'apparaît qu'à l'exécution, dans les conditions réelles de production.
4. Le test d'intrusion
Un opérateur cherche à enchaîner plusieurs faiblesses pour obtenir un accès. C'est le niveau qui produit la démonstration la plus convaincante auprès d'une direction, parce qu'il montre un résultat plutôt qu'une liste.
Ne détecte pas : ce qui sort du périmètre et de la durée convenus. Un test d'intrusion est borné, son absence de résultat ne prouve rien au-delà de ces bornes.
Une règle simple pour choisir : commencez par les niveaux 2 et 3. Ils écartent la majorité des incidents réellement observés sur des sites professionnels, pour une fraction du coût d'un test d'intrusion. Le niveau 4 se justifie quand un tiers exige une démonstration, ou quand les deux précédents sont déjà tenus.
Ce que le rapport doit contenir
Un rapport d'audit sert 2 publics à la fois : une direction qui doit arbitrer un budget, et une équipe technique qui doit corriger. Un document qui ne parle qu'à l'un des deux finit dans un tiroir.
- Le périmètre testé, et surtout le périmètre non testé. C'est la mention qui donne sa valeur juridique au document. Un rapport qui ne dit pas ce qu'il n'a pas regardé ne prouve rien.
- La date et la version. Un audit décrit un état à un instant donné. Sans date, il est inutilisable comme preuve.
- Chaque constat avec son niveau de gravité et sa reproductibilité. Une équipe doit pouvoir reproduire le problème pour vérifier qu'elle l'a corrigé.
- Un plan de correction priorisé, avec une estimation de charge par lot. C'est ce qui transforme une liste de problèmes en décision budgétaire.
- Une synthèse lisible sans compétence technique, en une page, qui dise le niveau de risque et les 3 actions à mener en premier.
- Les outils et les versions utilisés, pour que l'audit soit rejouable par un tiers.
Un signal d'alerte à connaître : un rapport qui liste des dizaines de constats de gravité faible sans jamais hiérarchiser est généralement une sortie d'outil peu retravaillée. Le travail d'audit consiste précisément à écarter le bruit.
Budget indicatif 2026
Les fourchettes indicatives ci-dessous couvrent la prestation d'audit seule, hors correction. Le prix suit la surface à couvrir et la profondeur retenue, pas le nombre de pages : une boutique de 30 pages avec paiement et comptes clients demande plus de travail qu'un site institutionnel de 200 pages statiques.
Site vitrine, formulaires simples
De 1 500 à 3 000 € HT. Niveaux 1 et 2 : scan, configuration, exposition, sauvegardes, accès. Rapport et plan de correction priorisé.
Boutique en ligne ou application métier
De 4 000 à 12 000 € HT. Ajoute la revue de code et l'inventaire des dépendances, les parcours authentifiés, la gestion des sessions et des droits. Restitution orale comprise.
Plateforme à fort trafic, interfaces de programmation
À partir de 15 000 € HT. Périmètre étendu aux interfaces, aux back-offices et aux flux entre applications. Un test d'intrusion s'ajoute généralement à ce budget plutôt qu'il ne s'y inclut.
Pour la remise en conformité, comptez selon les cas de 1 à 3 fois le coût de l'audit. Un écart aussi large s'explique simplement : corriger une configuration prend des heures, reprendre une conception non sécurisée prend des semaines.
Ce que nous trouvons le plus souvent
Sur les sites que nous reprenons en maintenance, 3 constats reviennent avec une régularité qui a cessé de nous surprendre.
Des dépendances non suivies
C'est la catégorie A03, et c'est de loin la première cause de risque que nous rencontrons. Un module installé lors du projet initial, jamais mis à jour depuis, avec une faille publiée entre-temps. Personne n'a fauté : simplement, aucun dispositif ne surveillait. C'est la raison pour laquelle notre suivi de parc affiche l'état de chaque site en continu plutôt qu'au moment d'un audit annuel.
Des accès d'administration oubliés
Comptes de prestataires partis, comptes de test laissés actifs, adresses d'administration accessibles sans restriction. Le correctif coûte quelques heures et écarte un risque majeur, ce qui en fait systématiquement la première ligne de nos plans de correction.
Une journalisation absente
La catégorie A09. Le jour où un incident survient, l'organisation ne peut ni dire ce qui s'est passé, ni prouver ce qui ne s'est pas passé. C'est un problème de conformité autant que de sécurité : sans traces, la notification à l'autorité de contrôle se fait à l'aveugle.
Sur vie-publique.fr, portail de la Direction de l'information légale et administrative avec 2 millions de visites par mois, la sécurité relève d'un socle non négociable dans lequel la veille sur les avis de sécurité et la chaîne de mise à jour comptent autant que le code livré. Le sujet n'est pas la taille du site, c'est la continuité du suivi.
Questions fréquentes
Un audit de sécurité de site web est-il obligatoire ?
Aucun texte ne l'impose sous ce nom. L'article 32 du RGPD impose en revanche, pour tout traitement de données personnelles, « une procédure visant à tester, à analyser et à évaluer régulièrement l'efficacité des mesures ». L'audit est le moyen usuel de tenir cette obligation. Pour les entités relevant de NIS2, l'exigence d'évaluation régulière est également prévue.
Quelle différence entre un scan automatisé et un test d'intrusion ?
Un scan compare votre site à une base de failles connues. Il est rapide et peu coûteux, mais il ignore la logique métier et les contrôles d'accès propres à votre application. Un test d'intrusion mobilise un opérateur qui cherche à enchaîner plusieurs faiblesses. Les deux sont complémentaires et ne répondent pas à la même question.
À quelle fréquence faut-il auditer son site ?
Le RGPD parle d'évaluation régulière sans fixer de rythme. Un audit complet annuel accompagné d'une veille continue sur les dépendances constitue une base défendable. Toute refonte, changement d'hébergement ou ouverture d'une interface de programmation justifie un contrôle supplémentaire.
Combien coûte un audit de sécurité en 2026 ?
De 1 500 à 3 000 € HT pour un site vitrine, de 4 000 à 12 000 € pour une application métier ou une boutique, au-delà de 15 000 € pour une plateforme à fort trafic avec interfaces de programmation. Le prix suit la surface et la profondeur, pas le nombre de pages.
Le rapport peut-il être communiqué à un client ou à une autorité ?
Oui, et c'est une raison fréquente de le commander. Un rapport daté, versionné et assorti d'un plan de correction priorisé vaut preuve de diligence auprès d'un donneur d'ordre, d'un assureur ou d'une autorité de contrôle. Il doit alors distinguer clairement ce qui a été testé de ce qui ne l'a pas été.
Sources officielles
Cet article s'appuie sur les textes européens et sur les publications des autorités françaises et luxembourgeoises compétentes en matière de sécurité des systèmes d'information.
- Règlement (UE) 2016/679, article 32, Sécurité du traitement, texte publié par la CNIL.
- OWASP Top 10:2025, classement de référence des risques applicatifs, publié par l'Open Worldwide Application Security Project.
- Guide d'hygiène informatique, 42 mesures, Agence nationale de la sécurité des systèmes d'information (ANSSI).
- Guide de la sécurité des données personnelles, Commission nationale de l'informatique et des libertés (CNIL).
- Commission nationale pour la protection des données (CNPD), autorité de contrôle luxembourgeoise.
- Haut-Commissariat à la protection nationale (HCPN) et CIRCL, coordination et réponse aux incidents au Luxembourg.
Dernière vérification des sources : 25 août 2026.
Pour aller plus loin
- NIS2 : votre organisation est-elle concernée ? Secteurs, seuils, calendrier et sanctions, en France et au Luxembourg.
- NIS2 au Luxembourg, autorités compétentes et état de la transposition.
- TMA Drupal : que couvre un contrat, à quel prix. La veille sur les avis de sécurité relève de la maintenance, pas de l'audit ponctuel.
- Audit RGAA, la même démarche appliquée à l'accessibilité.
- Audit IA gratuit, test en 2 minutes pour une application générée par un outil d'intelligence artificielle.
Un audit de sécurité à lancer ?
Décrivez votre besoin en quelques lignes. Un référent technique vous répond sous 24 heures ouvrables, sans engagement.