Comment lire un rapport d’analyse de sécurité de site web

Votre première analyse de sécurité peut ressembler à un vidage de diagnostic : un score en tête, un mur de constats colorés et beaucoup de sigles. Le score indique *où vous en êtes* ; les constats indiquent *quoi faire ensuite*. Ce guide explique comment lire un rapport comme le ferait un ingénieur sécurité, du chiffre principal jusqu’au seul correctif qui compte le plus cette semaine.

Commencez par le score, mais n’en restez pas là

IsSafeSite combine trois dimensions en un seul chiffre : Sécurité (60 %), SEO (20 %) et Protection du trafic (20 %). Un site peut avoir une bonne note globale tout en masquant un problème critique ; traitez donc le score comme une tendance à surveiller dans le temps, pas comme un réussite/échec. L’essentiel d’une analyse, ce sont les constats en dessous.

Triez par gravité, puis par effort

Chaque constat porte une gravité. Traitez-les dans cet ordre pour consacrer votre temps là où le risque est le plus élevé :

1. 1Critique — exploitable maintenant, ou expose directement des données. À corriger aujourd’hui.
2. 2Élevé — une voie d’attaque réaliste ou un contrôle manquant qui affaiblit tout le reste.
3. 3Moyen — des lacunes de durcissement qui comptent combinées à un autre problème.
4. 4Faible / Info — des rappels de bonnes pratiques ; regroupez-les dans une passe de nettoyage.

À gravité égale, faites d’abord les correctifs peu coûteux. Un en-tête Strict-Transport-Security manquant est un changement d’une ligne à fort impact ; refondre la gestion des sessions ne l’est pas. Éliminer d’abord le « faible effort / forte gravité » est le plus rapide pour faire bouger le chiffre et raccourcir la liste.

Lisez un constat de bout en bout

Chaque constat est rédigé pour être compris seul. Un bon constat répond à quatre questions :

• Ce qui a été observé — l’en-tête, le chemin, le champ de certificat ou la réponse exacts qui l’ont déclenché.
• Pourquoi c’est important — le risque concret, pas un avertissement générique.
• Comment le corriger — la directive, le bloc de configuration ou le changement de code précis.
• Comment le confirmer — à quoi devrait ressembler une nouvelle analyse propre.

Résistez à l’envie d’appliquer en masse des correctifs issus d’un résultat de recherche. Une valeur d’en-tête copiée d’un site sans rapport peut casser votre application (une Content-Security-Policy trop stricte en est l’exemple classique). Lisez le « pourquoi » avant d’appliquer le « comment ».

Distinguez les faux positifs des vraies lacunes

L’analyse automatisée est de la correspondance de motifs à grande échelle ; attendez-vous donc à des faux positifs occasionnels : un en-tête défini au niveau du CDN que le scanner n’a pas vu, ou un chemin « exposé » volontairement public. L’analyse vous donne gravité, confiance et preuves précisément pour que vous puissiez trancher. Vérifiez avec votre propre configuration avant d’écarter quoi que ce soit, et quand vous écartez, notez pourquoi.

Transformez le rapport en un plan court

Terminez le rapport par un plan, pas par une liste de 40 tâches. Un rythme hebdomadaire réaliste ressemble à ceci :

1. 1Corrigez cette semaine tous les Critiques et tout Élevé tenant en une ligne.
2. 2Planifiez les Élevés et Moyens restants avec des responsables et des dates.
3. 3Réanalysez après chaque lot pour voir le score bouger et détecter les régressions.
4. 4Gardez une note d’exceptions pour tout ce que vous acceptez sciemment.

Les constats d’en-têtes et de TLS que vous rencontrerez le plus ont chacun leur analyse détaillée : voir Les 10 erreurs d’en-têtes de sécurité les plus courantes et Les erreurs de configuration SSL/TLS qui mettent votre site en danger. Quand vous voudrez automatiser la réanalyse, la page des fonctionnalités et la documentation de l’API montrent comment l’intégrer à la CI.