Un chiffre a un avantage redoutable : il donne l'impression de résumer une réalité compliquée. 68/100 paraît immédiatement compréhensible. Au-dessus de la moyenne, encore loin de l'excellence, quelques corrections à prévoir. Le problème commence lorsque l'on oublie de demander ce que le chiffre mesure réellement.
Le 3 octobre 2026, RoastMyUrl a attribué 68/100 au site itandsecure.fr. Le rapport examine notamment le réseau visible, le DNS, TLS, les en-têtes HTTP, les performances, la configuration e-mail, la visibilité SEO et IA, la vie privée, le contenu et différents signaux de confiance. Il fait remonter des points corrects, d'autres à surveiller et plusieurs pistes d'amélioration.
La tentation serait alors de résumer : "le site est sécurisé à 68 %". Ce serait faux.
Et c'est précisément là que l'exemple devient intéressant. RoastMyUrl touche à des sujets de sécurité, mais RoastMyUrl n'est pas un pentest. Il observe une partie de la surface publique d'un site, agrège des contrôles hétérogènes et transforme ces observations en un indicateur propriétaire. Cette nuance n'est pas cosmétique. Elle change complètement ce que l'on peut faire du résultat.
Le piège commence avec le mot "audit"
Le vocabulaire technique mélange facilement audit, scan, diagnostic, test de sécurité, pentest et analyse de surface. Ces termes ne désignent pourtant ni la même profondeur ni la même méthode.
Le NIST définit le test d'intrusion comme un test de sécurité dans lequel des évaluateurs imitent des attaques réelles afin d'identifier des moyens de contourner les fonctions de sécurité d'un système. L'OWASP décrit de son côté un pentest comme une démarche dans laquelle le testeur agit comme un attaquant et cherche à découvrir, puis à exploiter, des vulnérabilités. L'idée essentielle tient dans deux mots : attaque active.
RoastMyUrl ne travaille pas ainsi. Son propre rapport sur itandsecure.fr indique une analyse en "boîte noire", sans identifiants et sans accès au code source, et précise qu'il s'agit d'une analyse de surface non intrusive. Cela n'empêche pas le moteur d'envoyer des requêtes techniques, d'observer des réponses HTTP, de vérifier TLS ou d'examiner certains services visibles. "Non intrusif" ne veut donc pas dire "aucun trafic réseau". Cela signifie surtout qu'il ne cherche pas à prendre le contrôle du site, contourner une authentification, injecter une charge utile ou démontrer qu'une vulnérabilité peut être exploitée.
"Boîte noire" n'est pas non plus synonyme de pentest : cela décrit surtout le niveau d'information disponible au départ, pas l'agressivité du test.
Ce que 68/100 veut vraiment dire
Dans le rapport du 3 octobre, itandsecure.fr obtient notamment 93/100 sur le réseau, 88/100 sur TLS et les certificats, 95/100 sur la performance, 67/100 sur la visibilité SEO et IA et 39/100 sur les signaux de confiance. Le rapport signale par exemple DNSSEC comme absent ou incomplet, l'absence de CAA, certains en-têtes HTTP à renforcer, l'absence de HSTS Preload, des points à revoir sur la configuration e-mail, la visibilité IA ou encore security.txt.
Pris séparément, ces constats sont utiles. DNSSEC, HSTS, CSP, sitemap, security.txt ou un résultat PageSpeed sont observables et vérifiables. Ensemble, ils donnent une photographie de l'hygiène de surface du domaine.
Mais additionner ces signaux ne transforme pas automatiquement le résultat en mesure globale de sécurité. Le score RoastMyUrl reste un score RoastMyUrl, construit à partir de ses contrôles, de ses seuils et de ses pondérations. Il n'est ni une note CVSS, ni une certification, ni un pourcentage de résistance à une attaque.
Nous avons déjà rencontré le même problème avec d'autres outils d'audit automatisé : deux moteurs peuvent donner des notes très différentes au même site sans que l'un des deux "mente" nécessairement. Ils ne mesurent simplement pas exactement la même chose. C'était notamment l'un des enseignements de notre analyse de SEOPlus! et de son 90/100.
Voir une faiblesse n'est pas démontrer une vulnérabilité exploitable
Prenons un exemple simple. RoastMyUrl peut constater qu'une politique CSP est absente ou insuffisante. C'est une information pertinente, car une CSP bien conçue participe à la réduction de certains risques côté navigateur. Mais l'absence d'une CSP ne démontre pas, à elle seule, qu'une attaque XSS fonctionne réellement sur le site.
Même raisonnement pour DNSSEC, CAA, HSTS Preload ou certains réglages CORS. Leur présence, leur absence ou leur qualité disent quelque chose de la configuration publique. Ils ne racontent pas tout ce qui se passe derrière le domaine.
Un véritable travail de sécurité peut aller beaucoup plus loin : authentification, autorisations, sessions, logique métier, entrées utilisateur, injections, fichiers, secrets, dépendances, API ou scénarios d'attaque enchaînés. L'OWASP Web Security Testing Guide consacre une méthodologie détaillée à ce type de vérifications.
RoastMyUrl ne prétend pas couvrir cet ensemble dans son analyse publique. Le rapport lui-même recommande, pour aller plus loin, une analyse du code source, la détection de secrets, l'examen des dépendances et d'autres contrôles internes. La frontière est donc écrite dans le document. Encore faut-il la lire avant de commenter le score.
L'exemple itandsecure.fr montre surtout à quoi l'outil sert bien
C'est là que RoastMyUrl devient utile. Non pas lorsqu'on lui demande de répondre à une question trop grande, comme "mon site est-il sécurisé ?", mais lorsqu'on lui pose une question plus précise : qu'est-ce qu'un observateur extérieur peut déjà voir et améliorer ?
Sur itandsecure.fr, le diagnostic permet par exemple de repérer rapidement des sujets DNS, TLS, headers, performance, messagerie, SEO, données structurées, exposition à des services tiers et signaux de confiance. Le propriétaire du site peut vérifier chaque élément, décider s'il est pertinent dans son contexte, corriger ce qui doit l'être, puis relancer l'analyse pour constater une éventuelle évolution.
Cette logique ressemble davantage à un tableau de bord de fondations qu'à une tentative d'effraction. Elle est particulièrement adaptée avant une mise en production, après une refonte, après un changement DNS ou d'hébergement, lors d'une revue SEO/GEO, ou simplement pour détecter une régression visible depuis Internet.
Le parallèle avec Mozilla HTTP Observatory est utile. Observatory attribue lui aussi des scores à partir de mécanismes publics, principalement des en-têtes HTTP et de certaines bonnes pratiques. Mozilla ne présente pas pour autant son score comme une preuve exhaustive de sécurité. Nous avions déjà utilisé cette distinction dans notre analyse sur les scores Observatory de plusieurs acteurs français de la cybersécurité.
RoastMyUrl doit aussi surveiller son propre vocabulaire
Il serait trop facile d'expliquer que seuls les utilisateurs comprennent mal les outils. Les éditeurs ont leur part de responsabilité.
RoastMyUrl utilise lui-même des mots comme "audit", "sécurité SSL", "failles", "conformité" ou "risques". Pris sans contexte, ces termes peuvent donner une impression de couverture plus large que la réalité. Lorsque la page d'accueil parle de "failles qui bloquent votre visibilité IA", le mot "faille" décrit ici un déficit de visibilité ou de structuration, pas nécessairement une vulnérabilité de sécurité exploitable.
Même prudence pour la "conformité légale" affichée dans le rapport. Le moteur précise qu'il s'agit d'un indice de présence de pages ou de signaux visibles, et non d'un avis juridique. C'est la bonne limite, mais elle doit rester aussi visible que le score lui-même.
Cette discipline vaut pour RoastMyUrl comme pour tous les outils automatisés : si le langage devient plus spectaculaire que la méthode, le score finit par promettre ce qu'il ne peut pas démontrer.
Ce que l'on ne peut pas conclure
À partir du rapport itandsecure.fr, on ne peut pas conclure que le site est "sécurisé à 68 %". On ne peut pas affirmer qu'il résisterait à une attaque réelle, qu'il ne contient aucune vulnérabilité applicative, que son code source est sain, que ses dépendances sont exemptes de CVE, que ses mécanismes d'authentification et d'autorisation sont corrects ou que sa conformité RGPD est établie.
À l'inverse, un score imparfait ne prouve pas non plus que le site est vulnérable ou mal conçu dans son ensemble. Certaines recommandations peuvent être pertinentes, d'autres secondaires selon le contexte, et certaines observations automatiques peuvent nécessiter une vérification humaine. L'absence de preuve d'une vulnérabilité n'est pas une preuve d'absence, mais l'absence d'un header n'est pas non plus la preuve qu'une attaque fonctionne.
Cette exigence de contexte rejoint notre analyse de la faille de coordination entre experts : un indicateur ne vaut que par les personnes qui savent le qualifier et agir.
C'est probablement la bonne façon de lire RoastMyUrl : comme un instrument de cadrage, pas comme un verdict.
Le 68/100 d'itandsecure.fr ne dit donc pas "voici votre niveau de cybersécurité". Il dit plutôt : "sur le périmètre que nous savons observer depuis l'extérieur, voici les fondations visibles, les écarts détectés et les points qui méritent d'être vérifiés".
Et cette formulation, moins spectaculaire qu'un "site sécurisé à 68 %", est aussi beaucoup plus utile.
Sources et références
- RoastMyUrl, page d'accueil et périmètre du moteur
- RoastMyUrl, llms.txt et description du moteur
- RoastMyUrl, analyse publique de itandsecure.fr
- NIST, définition de "Penetration Testing"
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
- OWASP Web Security Testing Guide v4.2
- MDN HTTP Observatory
