Comment on note

Nous chargeons réellement votre page dans Chromium — deux fois, une en profil mobile bridé et une en profil ordinateur — puis nous relevons les mêmes métriques que Lighthouse et les notons avec ses courbes officielles. En parallèle, les en-têtes HTTP passent la grille de Mozilla Observatory, et l’accessibilité est analysée par axe-core, le moteur qu’utilise Lighthouse.

Chaque catégorie donne une note sur 100. La note globale en est la moyenne pondérée.

Conditions de mesure. Profil mobile : écran 412 × 823, réseau limité à 1,6 Mb/s avec 150 ms de latence — le réglage « Slow 4G » de Lighthouse — et processeur ralenti d’un facteur 4. Profil ordinateur : 1350 × 940, sans bridage. La note globale du rapport reprend le profil mobile, comme Google.

Combien de temps nous observons. Nous attendons le silence réseau, dans la limite de dix secondes. Ce plafond était de trois secondes jusqu’au 14 août 2026, et il tronquait les pages lentes : sur gouvernement.fr, nous relevions un plus grand élément à 1,6 s quand Lighthouse en mesure 25,6 s — nous avions simplement fermé les yeux trop tôt. L’élargissement coûte environ deux secondes d’audit sur les pages lentes, et rien sur les autres, qui se taisent bien avant le plafond.

Le Speed Index n’est pas mesuré, car il exige d’analyser image par image un enregistrement vidéo du chargement. Plutôt que d’inventer une valeur, nous excluons ses 10 % de poids et renormalisons la note sur les 90 % restants. Chaque rapport affiche cette couverture.

Annoncer une compatibilité sans la chiffrer ne vaut rien. Nous confrontons donc nos notes à celles de Lighthouse — dans son réglage par défaut, celui de PageSpeed Insights — sur un échantillon de sites publics. Relevé du 11 août 2026, profil mobile :

Sur les pages légères à moyennes, l’écart va de 0 à 5 points. Sur les pages qui exécutent beaucoup de JavaScript, il montait à 12–24 points avant le 14 août 2026 ; deux défauts de notre instrument en étaient responsables et ont été corrigés.

Notre garde de sécurité faussait la mesure. Pour empêcher qu’un site nous fasse interroger une adresse interne par redirection, nous mettions chaque requête de document en pause le temps d’une vérification. Cette vérification prend 9 ms — mais mettre une navigation en pause empêche Chromium de lancer son analyseur de préchargement. Mesuré sur gouvernement.fr : premier affichage à 15,0 s au lieu de 1,6 s. C’était l’instrument qui produisait la mauvaise note, pas le site. La protection fonctionne désormais par surveillance, sans rien mettre en pause.

Bridage appliqué contre bridage simulé. Nous ralentissons réellement le processeur et le réseau, puis nous observons ce qui se passe. Lighthouse, par défaut, charge la page sans bridage puis simule analytiquement des conditions dégradées. Les deux méthodes sont légitimes, mais elles ne mesurent pas la même grandeur, et l’écart se creuse précisément là où il y a beaucoup de code à exécuter.

Lighthouse varie beaucoup lui-même. Sur une même page lourde, trois exécutions successives de Lighthouse dans des conditions identiques nous ont donné 47, puis 65, puis 66. Sur ces pages, viser un écart de moins de cinq points reviendrait à courir après du bruit. Ce sont les métriques détaillées et les ordres de grandeur qui doivent concorder, pas la décimale.

En revanche, un écart important avec PageSpeed Insights sur une page légère serait vraisemblablement un défaut de notre côté. Signalez-le nous : c’est ainsi qu’a été trouvé un défaut de mesure qui faisait perdre jusqu’à 27 points à des pages irréprochables.

Le score part de 100 points, puis chaque test ajoute ou retire des points selon la grille publique de Mozilla : absence de Content-Security-Policy −25, absence de protection contre le clickjacking −20, HSTS manquant −20, cookie de session sans drapeau Secure −40, script tiers chargé en HTTP −50 ; à l’inverse une CSP en default-src 'none' rapporte +10, une Referrer-Policy protectrice +5. Le total est ensuite converti en lettre, de A+ à F.

Trois tests d’Observatory sortent de notre portée et sont signalés comme tels dans chaque rapport plutôt que comptés comme réussis : le partage de ressources entre origines (CORS), l’appartenance réelle à la liste de préchargement HSTS, et la validité de la chaîne de certificats TLS.

Relevé directement dans le DNS public et par une poignée de main TLS : adresses, serveurs de noms, enregistrements MX et CAA, date d’expiration et émetteur du certificat, version de TLS négociée, puis SPF, DMARC et DKIM. Rien n’est envoyé au site, rien n’est modifié.

Ces contrôles ne dépendent pas de la page auditée mais du domaine : un certificat qui expire dans huit jours ou un domaine sans DMARC coûtent plus cher, en pratique, que quelques points de performance.

Deux limites assumées. SPF et DMARC ne sont exigés que si le domaine publie des serveurs de messagerie (MX) : les réclamer sur un domaine qui ne reçoit pas d’e-mail serait un faux positif. Et le DNS ne permet pas de lister les sélecteurs DKIM : nous testons les plus répandus, si bien que ne rien trouver ne prouve pas l’absence de DKIM — le rapport le dit explicitement plutôt que de conclure à tort.

L’analyse tourne sur la page rendue, après exécution du JavaScript : les contrastes sont réellement calculés et les rôles ARIA résolus, ce qu’une lecture du HTML source ne permet pas. Les règles retenues sont celles des niveaux WCAG 2.0 et 2.1, A et AA.

La note est une part de règles réussies, et non une soustraction : le nombre de règles passées, rapporté à ce même nombre augmenté du poids des règles en échec (2 pour une violation critique, 1 pour une sérieuse, 0,5 pour une modérée, 0,25 pour une mineure).

Pourquoi ce changement, et ce qu’il corrige : le barème précédent retirait un forfait par violation. Sur un site un peu fourni, la somme dépassait 100 et la note tombait à zéro — lemonde.fr sortait à 0/100 alors que 26 de ses 36 règles évaluées passaient. Relevés du 13 août 2026 face au vrai Lighthouse (mobile) : lemonde.fr 68 chez lui, 0 avec l’ancien barème, 67 avec le nouveau ; ovhcloud.com 72 / 15 / 77 ; notre page de démonstration dégradée 89 / 75 / 88 ; fr.wikipedia.org 96 / 85 / 94. L’écart moyen passe de 37,5 points à 2,3.

Écart assumé qui demeure : Lighthouse pondère chaque règle individuellement, avec une table d’une centaine d’entrées qui évolue à chaque version ; nous nous appuyons sur le niveau d’impact publié par axe. Le moteur est le même, la pondération reste plus grossière.

Un audit automatique ne couvre par ailleurs qu’une partie de l’accessibilité réelle — de l’ordre du tiers des critères RGAA. La navigation au clavier, la pertinence des textes alternatifs ou l’ordre de lecture demandent un test humain.

Critère RGAA 4.1. Chaque violation est rattachée à son critère, avec son numéro et son intitulé officiels, repris mot pour mot du référentiel publié par la DINUM. Le niveau WCAG (A, AA) et le numéro du critère WCAG correspondant sont affichés à côté. Hors du français, l’intitulé est une traduction de courtoisie et l’interface le dit : le texte opposable reste le français, et c’est le numéro qui fait référence.

Règle que nous nous imposons : une règle dont le rattachement dépend du contexte ne reçoit aucun numéro. Un bouton sans nom accessible relève du critère 7.1 s’il pilote un composant et du 11.1 s’il valide un formulaire ; trancher au hasard fausserait une déclaration d’accessibilité, qui est un document public engageant celui qui la publie. Ces constats gardent leur thématique et rien de plus.

Un taux distinct est affiché : la part des critères respectés parmi ceux qu’une machine sait trancher, soit environ vingt-cinq sur cent six. Ce n’est pas un taux de conformité RGAA, et c’est écrit à côté du chiffre, y compris dans le PDF — un pourcentage recopié seul dans un appel d’offres deviendrait un mensonge.

Les critères non automatisables sont listés avec leur marche à suivre, et remontés en tête quand la mesure donne une raison de s’en inquiéter : un attribut tabindex positif rend l’ordre de tabulation suspect, des champs sans étiquette rendent la pertinence des étiquettes existantes douteuse.

Enfin, un brouillon de déclaration d’accessibilité est produit au format de la DINUM : engagement, résultats, contenus non accessibles, voies de recours. L’état de conformité y est laissé à compléter, jamais rempli — l’affirmer sur la foi de tests automatiques rendrait la déclaration inexacte.

Chaque constat d’accessibilité porte le sélecteur CSS de chaque élément fautif, son balisage, et la ligne dans le document servi quand elle a pu être retrouvée. La recherche se fait dans le document que le navigateur a réellement reçu, pas dans celui que récupère notre robot : beaucoup de serveurs répondent différemment selon l’agent utilisateur, et la ligne serait alors cherchée dans le mauvais texte.

Trois réponses possibles, et jamais de fausse précision : une ligne exacte, une ligne approximative (l’élément a été retrouvé par un repère, l’ordre des attributs ayant changé au rendu), ou pas de ligne du tout — soit parce que le HTML servi est minifié sur une seule ligne, soit parce que l’élément est produit par JavaScript. Dans les deux derniers cas, le rapport dit lequel.

Un correctif avant / après accompagne les défauts courants. Il est marqué « prêt à coller » uniquement lorsque la transformation est mécanique et complète ; dès qu’une valeur d’attribut a dû être abrégée pour l’affichage, il redevient un gabarit — coller un code tronqué casserait la page.

La priorité croise la gravité, le nombre d’éléments touchés et un effort estimé : ajouter un attribut est l’affaire d’une minute, revoir une charte de couleurs engage un designer. Le plan de correction exportable reprend la liste dans cet ordre, avec pour chaque entrée l’emplacement, le code et le test de vérification.

Ce pilier ne lit plus le code source : il constate. La page est chargée dans un vrai navigateur et rien n’est cliqué — aucun bandeau accepté, aucune fenêtre fermée. Tout ce que le rapport liste ensuite a donc été obtenu sans consentement : c’est ce qui rend le constat opposable plutôt que probable.

Sont relevés les domaines réellement joints, les cookies effectivement déposés avec leur durée de vie, les clés écrites dans le stockage local, et la présence d’une fenêtre de consentement — cherchée aussi dans les iframes et les shadow DOM, où la plupart des gestionnaires du marché la placent. Les cookies sont classés en trois natures : traceur reconnu, strictement nécessaire (session, panier, anti-CSRF, anti-robot, mémoire du consentement — les exemptions admises par la CNIL), ou indéterminé. Un cookie tiers inconnu n’est jamais rangé parmi les nécessaires.

Transferts hors UE : nous identifions l’organisation qui exploite chaque domaine joint et le droit dont elle relève. Nous constatons donc le destinataire, pas l’emplacement physique de ses serveurs — la nuance est écrite dans le rapport, parce qu’elle change ce qu’on peut en conclure.

Mentions légales : le lien vers les mentions légales est suivi depuis la page d’accueil, et douze éléments imposés par la LCEN et le code de commerce y sont cherchés un à un — dénomination, capital, siège, RCS, TVA, contact, directeur de publication, hébergeur et ses coordonnées, données personnelles, cookies, propriété intellectuelle. Le contrôle est textuel : il repère une absence, il ne juge pas de l’exactitude de ce qui est écrit. Il ne se déclenche que pour les sites relevant vraisemblablement du droit français.

Si le navigateur n’a pas pu tourner, le pilier retombe sur une lecture du HTML, bien plus grossière — et le rapport l’indique au lieu de laisser croire à un relevé réel. Dire d’un site qu’il est « conforme au RGPD » demanderait d’examiner ses traitements, ce qu’aucun outil automatique ne fait.

La note reprend le calcul public du collectif Green IT, celui qu’utilise ecoindex.fr : trois grandeurs seulement — nombre de nœuds du document, nombre de requêtes, poids transféré — converties en rang dans une population de référence, puis pondérées. Le document compte pour la moitié de la note, les requêtes pour un tiers, le poids pour un sixième. Les quantiles et la formule sont repris tels quels de l’implémentation de référence, pour que notre note soit comparable à la leur.

Ces trois grandeurs viennent du chargement déjà effectué pour la performance : l’éco-score n’ajoute ni requête ni seconde à l’analyse. Les émissions affichées (grammes de CO₂ équivalent et centilitres d’eau par visite) sont les fonctions officielles du score, pas une estimation maison.

Ce que ce score ne dit pas : il note la sobriété de la page et rien d’autre. Il ignore votre hébergeur, le mix électrique de vos serveurs et la fréquentation réelle du site. C’est un indicateur de conception, à ne pas confondre avec un bilan carbone.

Ces trois catégories reposent sur des contrôles du document servi : présence et longueur du title et de la meta description, balises Open Graph, hiérarchie des titres, robots.txt et sitemap, URL canonique, langue déclarée, meta viewport, doctype, styles et gestionnaires d’événements en ligne.

La note part de 100 et chaque constat retire des points selon sa gravité : 22 pour un défaut critique, 14 pour un défaut élevé, 8 pour un défaut moyen, 4 pour un défaut faible, 1 pour une simple remarque. C’est un barème maison, contrairement aux trois catégories précédentes. Le pilier RGPD suit le même barème, à une exception près : les simples remarques n’y coûtent aucun point, pour qu’un site sans le moindre traceur obtienne bien 100.