Comment lire un rapport de sécurité de site web — sans paniquer | Scanthra

Scanthra · 7 min de lecture · Mis à jour Mai 2026

Pourquoi ces rapports font peur au premier abord

La plupart des rapports de sécurité ont été écrits, à l'origine, par des testeurs d'intrusion pour d'autres testeurs d'intrusion. Ils utilisent des termes comme « vecteur », « prise de contrôle de sous-domaine vulnérable », « HSTS (forçage HTTPS) preload manquant » comme si tout le monde les lisait autour d'un café. Si tu es propriétaire d'un petit site et que tu viens d'ouvrir un PDF plein de cases rouges, la réaction naturelle est la panique, suivie de la fermeture de l'onglet.

Ne fais pas ça. Presque tous les rapports modernes — y compris ceux de Scanthra — ont la même structure sous le style, et une fois que tu sais où regarder, tu peux en lire un en une dizaine de minutes.

Les quatre choses que chaque problème détecté te dit

1. Gravité — jusqu'où c'est grave, en théorie ?

La gravité, c'est l'impact dans le pire des cas si le problème est réel et que quelqu'un l'exploite. Elle utilise presque toujours cinq niveaux :

• CRITIQUE — dommage direct et immédiat. Exemples : un fichier .env lisible publiquement avec des mots de passe de base de données ; un sous-domaine qu'un attaquant peut s'approprier pour héberger du phishing. Traite ça comme à corriger aujourd'hui.
• ÉLEVÉ — sérieux mais pas instantané. Exemples : une vieille version de WordPress avec des exploits connus ; TLS/SSL (chiffrement) manquant sur le domaine principal. Corrige dans la semaine.
• MOYEN — aiderait un attaquant qui a déjà un point d'appui. Exemples : en-têtes de sécurité manquants, mauvais attributs de cookies. Corrige ce mois-ci.
• FAIBLE — hygiène. Exemples : la bannière du serveur révèle la version du logiciel. Corrige quand tu es de toute façon dans le coin.
• INFO / Observation — pas un problème, juste quelque chose qu'on a remarqué (ex. « tu utilises Cloudflare »). Contexte utile, aucune action requise.

2. Niveau de confiance — à quel point en est-on sûr ?

Les scanners passifs observent ton site de l'extérieur, comme le ferait un visiteur. Ils ne peuvent pas toujours être sûrs à 100 % qu'un problème est réel. Le niveau de confiance est un chiffre, généralement de 0 à 100 %, qui indique à quel point l'outil est sûr de la détection elle-même — séparément de la gravité du problème.

Scanthra utilise un modèle 2D : chaque problème détecté a à la fois une gravité et un niveau de confiance. Nous n'affichons que les problèmes avec un niveau de confiance ≥ 50 %. Tout ce qui est en dessous se retrouve dans la section Observations, où on dit « on a remarqué ça, on n'est pas sûr, voilà pourquoi » au lieu de sonner l'alarme.

Un ordre de lecture pratique :

1. Gravité ÉLEVÉE ou CRITIQUE à ≥ 80 % de confiance — commence ici.
2. Gravité MOYENNE à ≥ 80 % de confiance — planifie dans un sprint.
3. ÉLEVÉ ou CRITIQUE à 50–80 % de confiance — vérifie d'abord, puis corrige.
4. Tout le reste — regroupe dans une fenêtre de maintenance.

3. Le correctif — un paragraphe, en clair

Tout problème détecté qui se respecte vient avec un court paragraphe « comment corriger » sur lequel un développeur peut agir. Dans les rapports Scanthra, ça se trouve sous Corriger soi-même : généralement une ou deux phrases, parfois un extrait de configuration à copier-coller. Si tu ne gères pas le site toi-même, c'est la partie que tu transmets à qui le fait — ton développeur web, ton agence ou le support de ton hébergeur.

Tu n'as pas besoin de comprendre le correctif. Tu dois juste pouvoir le transférer et demander « tu peux faire ça, et quand ? ».

4. Tags de conformité — qui s'intéresse à ça en dehors de toi ?

Les problèmes détectés portent souvent des tags comme GDPR:Art32, NIS2:Art21, OWASP:A05. Ce sont des raccourcis qui disent « ce n'est pas seulement notre opinion ; le régulateur/la norme X attend que tu gères ça ». Les trois que tu verras le plus :

• RGPD Art. 32 — la clause générale de l'UE sur les « mesures techniques et organisationnelles appropriées ». Des choses comme le chiffrement en transit (HTTPS) et la configuration résistante aux violations y tombent.
• NIS2 Art. 21 — les mesures de base de la directive NIS2 (directive UE sur la cybersécurité) : gestion des risques, gestion des vulnérabilités, sécurité de la chaîne d'approvisionnement, chiffrement, contrôle d'accès. Même si tu n'es pas toi-même une entité réglementée, tes grands clients te poseront de plus en plus des questions là-dessus.
• OWASP (standard de sécurité applicative) Top 10 — la liste standard de l'industrie des risques les plus courants des applications web. A05 est la mauvaise configuration, A07 est les défaillances d'identification et d'authentification, et ainsi de suite.

Et les faux positifs ?

Aucun scanner passif n'est parfait. Parfois, un outil va signaler quelque chose qui, dans les spécificités de ta configuration, n'est en fait pas un problème. Exemples :

• Un « en-tête de sécurité manquant » qui est en fait défini par ton CDN en amont et que le scanner ne pouvait pas voir.
• Un avertissement « version du CMS (système de gestion de contenu) obsolète » où la chaîne de version est délibérément falsifiée par un plugin de durcissement.
• Un « sous-domaine ne pointe nulle part » où le sous-domaine est intentionnellement en attente pour un lancement à venir.

En cas de doute : corrige quand même. Presque tous les « faux positifs » sont peu coûteux à neutraliser, et ce faisant tu élimines le bruit de ton prochain scan aussi. Les exceptions sont les cas où le correctif représenterait un vrai travail — là, demande à ton développeur de confirmer avant de passer des heures dessus.

Comment partager un rapport avec un développeur

Si tu transfères le PDF, trois phrases suffisent :

« Salut — on a fait un scan de sécurité. Tu peux regarder les problèmes détectés ÉLEVÉS et CRITIQUES à partir de la page 4 et me dire lesquels tu peux corriger ce sprint et lesquels nécessitent plus d'analyse ? Je suis OK pour déprioritiser tout ce qui est FAIBLE pour l'instant. »

C'est tout. Le développeur n'a pas besoin d'une traduction du rapport ; il a besoin de la permission de prioriser.

À quoi ressemble un rapport « propre »

Spoiler : personne n'obtient zéro problème détecté au premier scan. Un site WordPress typique de petite entreprise arrive à ~8–15 problèmes, principalement des en-têtes MOYENS et de l'hygiène des cookies. Une cible raisonnable pour « propre », c'est :

• Zéro CRITIQUE.
• Zéro ÉLEVÉ de plus de 30 jours.
• Une note globale de B ou mieux sur la page de couverture.

Tout ce qui va au-delà, c'est de la perfection — utile, mais pas ce qui fait la différence entre toi et tes clients.

Comment Scanthra rédige ses rapports

On garde délibérément le langage simple. Chaque problème détecté a une ligne d'impact sur l'activité (« si exploité, un attaquant pourrait lire les e-mails des clients, ce qui constituerait une violation du RGPD »), un paragraphe corriger soi-même, et une carte de conformité au début pour que tu voies d'un coup d'œil quels régulateurs s'y intéressent. Si un problème est à la limite, on le déplace dans les Observations plutôt que de te faire peur. L'objectif est un rapport que tu peux lire dans le train du retour et sur lequel tu peux agir le lendemain matin — pas un PDF de 60 pages que tu classes sous « effrayant, à gérer plus tard ».