Rudra Analyzer

Méthodologie

Comment nous testons et notons les sites web

Cette page explique précisément ce que regardent nos contrôles, comment chaque score est calculé, quels outils effectuent les tests et où se situent les limites. Elle décrit les vérifications d'une page qui alimentent les outils gratuits et l'audit de site.

Ce que regarde chaque contrôle

Un audit complet exécute sept contrôles. Chacun a un nom simple, utilisé dans tous nos rapports, et un nom technique qui décrit ce qu'il teste réellement.

SEO

Nom technique
SEO on-page et technique
Ce qu'il vérifie
Titre et méta-description, H1 et ordre des intertitres, URL canonique, règles robots meta et X-Robots-Tag, balises Open Graph et Twitter card, html lang, viewport, couverture des attributs alt des images, données structurées JSON-LD, hreflang, favicon, nombre de mots, liens internes, ainsi que robots.txt, le sitemap XML, llms.txt, les chaînes de redirection et le HTTPS.
Calcul du score
Part de 100. Titre manquant −25, méta-description manquante −15, H1 manquant −15, noindex −30, et des déductions plus faibles (2 à 15 points) pour le reste. Les contrôles les plus récents peuvent retirer au maximum 45 points au total.
Testé avec
Python requests + BeautifulSoup (lit le HTML envoyé par le serveur ; le JavaScript n'est pas exécuté)
Essayer l'outil Vérificateur SEO

Vitesse

Nom technique
Performance de la page (Lighthouse)
Ce qu'il vérifie
La catégorie performance de Lighthouse : First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, Speed Index et Time to Interactive, plus jusqu'à 15 audits en échec.
Calcul du score
Le score de performance de Lighthouse sur 0–100, sans modification. Un audit noté sous 0,5 est marqué critique, sous 0,9 comme avertissement.
Testé avec
Google Lighthouse dans Chrome headless, réglages par défaut (mobile)
Essayer l'outil Test de vitesse de site

Expérience mobile

Nom technique
Mise en page responsive
Ce qu'il vérifie
La balise meta viewport et le débordement horizontal aux tailles ordinateur (1280×800), tablette (768×1024) et téléphone (390×844), avec une capture d'écran pour chacune.
Calcul du score
Part de 100. Balise viewport manquante −20, −15 pour chaque taille où la page est plus large que l'écran, −10 si une taille a rencontré des problèmes de chargement.
Testé avec
Playwright avec Chromium
Essayer l'outil Test mobile

Accessibilité

Nom technique
Tests WCAG automatisés
Ce qu'il vérifie
L'ensemble de règles par défaut d'axe-core — règles WCAG 2.x de niveau A et AA plus bonnes pratiques — exécuté sur la page rendue. Jusqu'à 25 types de violations sont listés, chacun avec le nombre d'éléments concernés.
Calcul du score
Part de 100 et perd des points pour chaque règle non respectée, selon l'impact : critique −15, grave −10, modéré −5, mineur −2.
Testé avec
axe-core injecté dans Chromium via Playwright
Essayer l'outil Vérificateur d'accessibilité

Sécurité du site

Nom technique
Sécurité du transport et en-têtes de sécurité HTTP
Ce qu'il vérifie
HTTPS après redirections ; le certificat TLS (confiance, nom d'hôte, version du protocole, émetteur, expiration) ; HSTS, Content-Security-Policy, X-Frame-Options ou CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy, Permissions-Policy ; numéros de version dans les en-têtes Server ou X-Powered-By.
Calcul du score
Part de 100. Pas de HTTPS −40, pas de HSTS −15, pas de CSP −12, pas de protection contre le clickjacking −8, pas de X-Content-Type-Options −6, pas de Referrer-Policy ou de Permissions-Policy −4 chacun, divulgation de version −3. Certificat invalide ou expiré −40, échec de la connexion TLS −30, expiration dans les 14 jours −10, dans les 30 jours −5.
Testé avec
Python requests + le module ssl de la bibliothèque standard
Essayer l'outil Vérificateur de sécurité

Liens et erreurs de page

Nom technique
Test fonctionnel de base
Ce qu'il vérifie
Charge la page dans un navigateur, enregistre les erreurs de la console JavaScript et les exceptions non interceptées, teste jusqu'à 12 liens uniques vers le même site (même protocole et même domaine) pour détecter les erreurs HTTP, et compte les formulaires sans les envoyer. Les liens vers d'autres sites ne sont pas testés.
Calcul du score
Part de 100. Chaque lien cassé −10 (au maximum −40), chaque erreur JavaScript non interceptée −10 (au maximum −30), chaque erreur de console −5 (au maximum −20).
Testé avec
Playwright avec Chromium
Essayer l'outil Vérificateur de liens cassés

Serveur et disponibilité

Nom technique
Disponibilité et temps de réponse
Ce qu'il vérifie
La page elle-même plus des chemins courants — robots.txt, sitemap.xml, /health, /healthz, /api, /api/health, openapi.json, swagger.json, manifest.json et security.txt — pour détecter les erreurs serveur et mesurer le temps de réponse moyen. Une erreur 404 sur ces chemins facultatifs n'est pas pénalisée.
Calcul du score
Part de 100. Page inaccessible ou 5xx −50, page 4xx −20, −15 pour chaque autre chemin renvoyant une erreur 5xx (au maximum −30), temps de réponse moyen supérieur à 800 ms −8 ou supérieur à 1 500 ms −15.
Testé avec
Python requests
Essayer l'outil Audit de site

Comment les éléments sont collectés

Un constat n'apparaît que lorsqu'un contrôle a réellement vu ce qu'il décrit — une valeur d'en-tête, un élément, une réponse. Chaque constat indique l'origine de ses éléments :

Réponse HTTP
Les codes de statut, redirections et en-têtes de réponse obtenus par une requête normale vers votre page.
HTML
Le code source de la page envoyé par votre serveur, avant toute exécution de JavaScript.
Page affichée et exécution dans le navigateur
La page après son chargement dans Chromium : les éléments affichés, les erreurs JavaScript et les fichiers qui n'ont pas pu se charger.
Lighthouse
Les mesures en laboratoire et les audits issus d'un seul test Lighthouse.
axe-core
Les résultats des règles d'accessibilité pour la page affichée.
Données d'exploration
Dans les analyses de site : les pages, liens, titres et canonicals enregistrés pendant l'exploration — sans requête supplémentaire.
robots.txt et sitemap
Les règles de votre robots.txt et les URL listées dans vos sitemaps XML.
Connexion TLS
Le certificat et la version du protocole présentés par votre serveur.

Confidentialité : les éléments collectés ne contiennent jamais de valeurs de cookies, de jetons, de mots de passe, d'en-têtes Authorization, de clés d'API ni quoi que ce soit saisi dans un formulaire. Les cookies sont signalés uniquement par leur nom et leurs attributs, les champs de formulaire uniquement par leur nom et leur libellé, et les paramètres d'URL qui ressemblent à des jetons sont retirés des URL.

Niveaux de fiabilité

Chaque constat indique notre degré de certitude, pour que vous sachiez sur quoi agir tout de suite et quoi vérifier d'abord.

Élevée

Constaté directement : une valeur d'en-tête, un code de statut, un élément qui ne respecte pas une règle. Vous pouvez le confirmer vous-même en quelques secondes.

Moyenne

Un signal fort qui dépend du contexte — par exemple un cookie qui ressemble à un cookie de session d'après son nom, ou une page listée dans le sitemap vers laquelle aucune page explorée ne pointe.

Faible

Une heuristique qui doit être examinée par une personne, comme un formulaire sans jeton CSRF visible ou des gestionnaires d'événements en ligne. Ces constats sont formulés comme « potentiels » ou « à vérifier manuellement » et ne sont jamais présentés comme des vulnérabilités confirmées.

Contrôles effectués et « Non testé »

Les rapports listent chaque règle que nous avons évaluée, y compris celles qui ont réussi, pour que vous voyiez ce qui a été couvert et pas seulement ce qui ne va pas. Une courte liste de problèmes n'a pas le même sens quand quarante contrôles ont réussi que lorsque cinq seulement ont pu s'exécuter.

« Non testé » signifie qu'un contrôle ne s'appliquait pas ou n'était pas sûr à exécuter — par exemple le contrôle de l'attribut Secure des cookies sur une page qui n'est pas servie en HTTPS, ou un lien vers une adresse privée. « Ignoré » signifie qu'il n'a pas pu s'exécuter, généralement parce que notre propre requête a échoué ou expiré ; le domaine est alors marqué comme partiel et le résumé indique quels contrôles manquent. Un délai dépassé ou une erreur DNS de notre côté correspond à « vérification impossible », jamais à un échec de votre site.

Les contrôles ignorés ou non testés ne coûtent aucun point. Si tout un domaine n'a pas pu s'exécuter — son moteur n'était pas disponible ou il a échoué de notre côté —, il est exclu du score global au lieu d'être compté comme zéro.

Sécurité : des contrôles de sécurité non destructifs

Chaque contrôle est passif et en lecture seule. Concrètement :

  • Nos propres requêtes utilisent uniquement GET ou HEAD — jamais POST, PUT, PATCH ou DELETE. Lorsqu'une page est ouverte dans un navigateur, ses propres scripts s'exécutent comme pour n'importe quel visiteur.
  • Le contrôle CORS est une seule requête GET portant une Origin inoffensive pour un domaine qui ne peut pas exister (https://rudra-audit.invalid), sans cookie ni identifiant.
  • Seule une courte liste fixe de fichiers connus est demandée — comme robots.txt, sitemap.xml, /.well-known/security.txt, llms.txt, humans.txt et le manifeste vers lequel pointe votre page, ainsi que les chemins de santé et de description d'API listés plus haut pour le contrôle du serveur. Nous ne devinons ni n'énumérons d'autres chemins, et les source maps ne sont vérifiées que lorsqu'un de vos propres scripts les mentionne.
  • Les formulaires ne sont jamais envoyés, cliqués, activés ni remplis, et aucune charge d'attaque n'est envoyée.
  • Nous ne nous connectons jamais, n'envoyons jamais d'identifiants et n'essayons jamais de mots de passe.
  • Les requêtes vers des adresses de réseaux privés et internes — localhost, 10.x, 192.168.x, services de métadonnées cloud et similaires — sont bloquées avant d'être envoyées, y compris lors des redirections et, dans nos contrôles de navigateur Playwright, pour chaque requête effectuée par la page pendant son chargement.

Calcul des scores

Chaque domaine part de 100 et perd des points selon les problèmes trouvés ; la vitesse utilise directement le score de Lighthouse. Le rapport liste chaque déduction à côté du constat qui l'a causée, pour que vous voyiez exactement où sont passés les points.

Un même problème n'est jamais déduit deux fois : trois cookies sans Secure forment un seul constat avec une seule déduction. Lorsque le nombre d'occurrences compte, comme pour les liens cassés ou les erreurs JavaScript, la déduction augmente avec ce nombre jusqu'à un plafond indiqué. Les constats informatifs plus récents ne coûtent rien ; quelques contrôles anciens de faible priorité gardent une petite déduction, par exemple l'absence de Referrer-Policy (−4) ou une règle d'accessibilité mineure (−2).

Une analyse de site ajoute des contrôles SEO entre les pages — titres et descriptions en double, problèmes de canonical, liens vers des redirections, URL du sitemap qui renvoient des erreurs, liens de retour hreflang manquants et contenu identique — que les contrôles d'une seule page ne peuvent pas voir. Ensemble, ils peuvent retirer au maximum 5 points au score SEO, et les problèmes déjà notés sur chaque page ne sont pas comptés une seconde fois.

Comment le score global est calculé

Le score global est la moyenne des scores par catégorie, arrondie à l'entier. Seules les catégories qui ont produit un résultat comptent. Si un moteur n'est pas disponible sur notre serveur — par exemple si Lighthouse ne fonctionne pas — cette catégorie est retirée du rapport et de la moyenne, plutôt que d'être comptée comme zéro ou estimée.

Si un contrôle s'exécute mais ne peut pas aboutir, par exemple parce que la page ne se charge pas à temps, il obtient 0 et compte dans la moyenne, car c'est un vrai problème qu'un visiteur rencontrerait aussi.

Les scores sont accompagnés d'un statut simple : 90–100 correspond à « Bon », 50–89 à « À améliorer » et 0–49 à « Faible ». Le statut est toujours écrit à côté de sa couleur.

Les outils que nous utilisons

Nous nous appuyons sur des outils ouverts et reconnus plutôt que d'inventer nos propres mesures.

  • Google Lighthouse

    Mesure les performances de chargement dans un vrai navigateur Chrome. Nous utilisons son score de performance et ses audits tels quels.

  • Playwright et Chromium

    Charge les pages dans un vrai moteur de navigateur pour les contrôles de mise en page mobile, de liens et d'erreurs, et d'accessibilité, et réalise les captures d'écran.

  • axe-core

    Le moteur de règles d'accessibilité open source de Deque, largement utilisé pour les tests WCAG automatisés.

  • requests et BeautifulSoup

    Récupèrent les pages et analysent leur HTML pour les contrôles SEO, sécurité et serveur.

  • Le module ssl de Python

    Ouvre une connexion TLS pour lire votre certificat et le valider auprès des autorités de certification de confiance standard.

Ce que les contrôles automatiques ne peuvent pas vous dire

  • Si votre contenu est utile, exact ou convaincant, ni comment il se classera face à vos concurrents.
  • Les questions d'accessibilité qui demandent un regard humain : si le texte alternatif a du sens, si l'ordre de navigation au clavier est logique ou si le contenu est compréhensible.
  • Si votre site présente des vulnérabilités, des logiciels obsolètes, des mots de passe faibles ou des logiciels malveillants. Le contrôle de sécurité lit votre configuration ; ce n'est pas un test d'intrusion.
  • La vitesse de votre site pour vos vrais visiteurs. Lighthouse effectue un seul test en laboratoire ; les données des visiteurs réels peuvent être différentes.
  • Tout ce qui se trouve derrière une connexion, un paywall ou un formulaire — nous ne voyons que les pages accessibles publiquement.
  • Les problèmes sur d'autres pages. Chaque vérification d'une page ne regarde que l'adresse que vous saisissez.

Pourquoi les résultats peuvent varier d'une analyse à l'autre

C'est la vitesse qui varie le plus. Chaque analyse Lighthouse est un nouveau chargement de page, et les conditions réseau, la charge du serveur, le cache, les publicités et les scripts tiers changent d'un chargement à l'autre. Quelques points d'écart entre deux analyses sont normaux.

Les contrôles effectués dans le navigateur peuvent aussi varier si la page charge du contenu dans un ordre aléatoire, affiche des bannières ou des tests différents, ou bloque parfois les visiteurs automatisés. Les résultats SEO et sécurité ne changent que si votre page ou la configuration de votre serveur change.

Limites connues par domaine

Vitesse

Un test en laboratoire sur un seul chargement, avec la simulation par défaut de Lighthouse d'un téléphone milieu de gamme sur une connexion bridée. Il ne peut pas mesurer l'Interaction to Next Paint (INP), qui nécessite de vraies interactions ; le Total Blocking Time est l'indicateur de laboratoire le plus proche.

Accessibilité

Les règles automatiques ne détectent qu'une partie des problèmes qu'une page peut avoir. Réussir ces tests ne signifie pas que la page est conforme aux WCAG ; des tests manuels au clavier et avec un lecteur d'écran restent nécessaires.

Sécurité

Vérifie que les en-têtes sont présents, pas la solidité de leurs valeurs, et n'examine ni les cookies, ni le contenu mixte, ni les vulnérabilités applicatives.

Liens

Teste jusqu'à 12 liens vers le même site par page. Les liens vers d'autres sites ne sont pas vérifiés, et certains serveurs renvoient des erreurs aux visiteurs automatisés même quand la page fonctionne pour les personnes.

SEO

Lit le HTML envoyé par votre serveur, pas la page après l'exécution de JavaScript. Il ne mesure ni le classement, ni le trafic, ni les mots-clés, ni les backlinks, et des données structurées complètes ne garantissent pas l'affichage de résultats enrichis.

Comment l'IA est utilisée dans les rapports

Lorsqu'il est activé, un modèle d'IA (Claude, d'Anthropic) reformule les vrais résultats d'une analyse en une courte liste priorisée de prochaines étapes. Il reçoit l'adresse analysée, les scores par catégorie et les problèmes détectés par nos outils d'analyse.

Il a pour consigne d'expliquer et de prioriser uniquement ces résultats. Il ne crée pas de problèmes, ne modifie pas les scores et ne prétend pas avoir mesuré quelque chose qui ne l'a pas été. Si l'IA n'est pas configurée ou si la requête échoue, nous utilisons à la place un résumé automatique construit à partir des domaines les moins bien notés — le rapport indique lequel vous lisez.

Les scores et les problèmes proviennent toujours des outils d'analyse décrits ci-dessus, jamais de l'IA.

Ce que deviennent vos données

Les analyses sont temporaires. Chaque analyse, analyse de site et test de mise en page — avec ses résultats, rapports et captures d'écran — est supprimé automatiquement 24 heures après sa dernière activité.

Notre politique de confidentialité explique ce que nous conservons d'autre, comme les informations de compte, et pendant combien de temps.

Lire la politique de confidentialité

Essayez les contrôles

Chaque outil de cette page peut être essayé gratuitement sur une page de votre site, et nos guides expliquent comment corriger ce qu'ils détectent.