Checklist d'audit de site web, par priorité

Quatre situations à vérifier avant tout le reste

Quatre situations touchent chaque visiteur dès la première page, quel que soit le reste du site. Faites-les vérifier avant tout le reste :

• Le site ne répond pas en HTTPS.
• Le certificat est expiré, auto-signé, ou émis pour un autre nom que le vôtre.
• Le nom de domaine a expiré, ou expire dans moins de quinze jours.
• Le site figure sur une liste de sites dangereux consultée par les navigateurs.

Les trois premières se règlent chez l'hébergeur ou chez le bureau d'enregistrement du domaine. La quatrième demande de trouver pourquoi le site figure sur la liste avant d'en demander le retrait. Un rapport d'audit les traite en une phrase quand aucune ne s'applique : c'est le cas dans les deux rapports publiés en exemple, qui donnent en même temps l'échéance du nom de domaine.

Viennent ensuite les points qui pèsent le plus dans le barème de notre méthode : les traceurs déposés avant le consentement et les données personnelles envoyées hors de l'Union sans garanties, puis l'absence de mécanisme de consentement, l'absence de mentions légales, les couches critiques concentrées chez un seul fournisseur, et SPF ou DMARC absents alors que le domaine reçoit des emails. Dans chaque pilier ci-dessous, la liste commence par ce qui pèse le plus.

Un point sans objet ne compte pas : les obligations de la vente en ligne ne s'appliquent pas à un site qui ne vend rien. Et les piliers eux-mêmes ne pèsent pas le même poids selon ce que le site sert à faire : la méthodologie publie les grilles.

Sécurité et chiffrement : la connexion, et ce que le site publie

La question : les échanges avec vos visiteurs sont-ils protégés, et le site ne publie-t-il rien qui devrait rester privé ? Le chapitre sur la sécurité d'un site web dit sur quelle base chaque point repose.

• Le site répond en HTTPS, et l'adresse en http y renvoie de façon permanente. Sans HTTPS, le navigateur signale le site comme non sécurisé à chaque visite.
• Le certificat est valide, n'est pas près d'expirer, et a été émis pour votre nom de domaine. Un certificat émis pour le nom de l'hébergeur déclenche une alerte qui arrête le visiteur avant la première ligne.
• Le JavaScript servi ne contient aucune clé secrète. Tout script chargé par une page est lisible par n'importe quel visiteur, et une clé secrète publiée doit être considérée comme connue.
• Le serveur refuse TLS 1.0, TLS 1.1 et les suites de chiffrement faibles. Les accepter laisse une connexion se négocier au niveau le plus faible que le serveur tolère.
• Aucune ressource n'est chargée en http depuis une page en https. Le navigateur bloque ou signale ce contenu mixte, et ce qui circule en clair peut être lu ou modifié en chemin.
• Les bibliothèques JavaScript et le CMS ne sont pas dans une version qui présente une vulnérabilité connue. Ces vulnérabilités sont recensées dans des bases publiques, lisibles par tous.
• Aucun sous-domaine ne pointe vers un service tiers abandonné. Celui qui réclame ce service peut publier sous votre nom de domaine.
• Sur une boutique, les pages du tunnel d'achat ne chargent aucun script tiers sans rapport avec le paiement. Chacun de ces scripts s'exécute sur les pages où le client saisit ses informations.
• Les en-têtes HSTS et CSP sont envoyés. Le premier oblige le navigateur à rester en HTTPS ; le second limite les scripts qu'une page peut exécuter.
• Les cookies de session portent les attributs Secure, HttpOnly et SameSite. Sans eux, un cookie peut partir sans chiffrement, être lu par un script ou accompagner une requête venue d'un autre site.
• Les cartes de sources (source maps) ne sont pas publiées. Elles donnent à n'importe qui le code tel qu'il a été écrit, avec ses commentaires.

Le certificat, les versions de TLS et les en-têtes se règlent chez l'hébergeur. Une bibliothèque ou un CMS vulnérable se met à jour. Une clé secrète publiée se remplace : la retirer du code ne suffit pas.

Trois guides détaillent ces points : les en-têtes de sécurité HTTP, l'en-tête HSTS et ce qu'il engage et les attributs des cookies.

Performance : trois seuils de Google, et ce qui les explique

La question : le site reste-t-il assez rapide pour ses visiteurs ? Les trois premiers points sont les Core Web Vitals de Google, et le chapitre sur la performance web dit comment ils sont mesurés.

• La page répond à un geste en moins de 500 millisecondes (INP). Au-delà, un bouton qu'on vient de toucher semble ne rien faire.
• Le contenu principal s'affiche en moins de 4 secondes (LCP). Au-delà, Google classe la page dans la catégorie « mauvais » pour cet indicateur, et le visiteur attend devant une page incomplète.
• Le décalage cumulé de la mise en page reste sous 0,25 (CLS). Un contenu qui bouge pendant le chargement fait toucher le mauvais bouton.
• Ces seuils sont respectés sur téléphone, pas seulement sur ordinateur. Une page rapide sur un poste de bureau peut rester lente sur un téléphone en réseau mobile.
• Le poids téléchargé, le nombre de requêtes, les images servies plus grandes que l'écran, ce qui n'est ni compressé ni mis en cache. C'est là que se lit la cause d'un affichage lent.
• La part du poids et de l'attente qui revient à des services tiers. Un script de mesure ou de publicité peut ralentir une page que vous n'avez pas touchée.

Des images trop lourdes, des fichiers ni compressés ni mis en cache se corrigent sans refonte. Un script tiers qui pèse sur chaque page se discute avec celui qui l'a demandé.

Les guides sur le temps d'affichage du contenu principal et sur les causes d'un site lent vont plus loin.

Référencement : ce que les moteurs lisent vraiment

La question : les moteurs comprennent-ils vos pages ? Le chapitre sur l'audit SEO technique explique pourquoi une page se juge sous deux versions, telle que le serveur l'envoie et telle que le navigateur l'affiche.

• Aucun texte présent dans la page envoyée ne disparaît de la page affichée. Les moteurs liraient alors ce que le visiteur ne verra jamais : c'est le mécanisme que les règles de Google contre le spam visent sous le nom de dissimulation (cloaking). L'écart peut être involontaire ; il se constate sur le texte, pas sur l'intention.
• Le fichier robots.txt et le plan du site (sitemap) existent, et le robots.txt ne contient aucune ligne qu'un robot conforme ignore. Une interdiction mal écrite ne protège rien, et rien ne le signale.
• L'adresse canonique et la consigne noindex sont les mêmes dans la page envoyée et dans la page affichée, et elles se trouvent dans l'en-tête de la page. Une balise que seul le navigateur ajoute, ou posée hors de l'en-tête, peut être ignorée.
• Moins de 5 % des liens internes parcourus mènent à une erreur. Un lien cassé arrête le visiteur et dépense l'exploration du moteur pour rien.
• Aucun site de préproduction n'est public et indexable. Un double du site dans les résultats concurrence l'original.
• Un site multilingue déclare ses versions linguistiques les unes aux autres, dans les deux sens (hreflang). Sans cela, le moteur peut montrer la mauvaise langue.
• Aucune adresse ne passe par deux redirections ou plus, par une boucle, ou par une redirection en JavaScript. Chaque saut ralentit le visiteur et brouille, pour le moteur, l'adresse à retenir.
• Chaque page a un titre et une description, de longueur utile et distincts d'une page à l'autre ; les données structurées portent les champs que leur type exige.

Le fichier robots.txt, le plan du site et les redirections se corrigent sans toucher aux pages. Des balises que seul le navigateur ajoute demandent de revoir la façon dont le site est construit : c'est un projet, pour la personne qui en tient le code.

Pour aller plus loin : ce que robots.txt interdit vraiment, les chaînes de redirection et une préproduction indexée par Google.

Accessibilité : contraste, intitulés, clavier

La question : vos pages restent-elles utilisables par des personnes aux besoins différents ? Le chapitre sur l'audit d'accessibilité cite les critères des WCAG et du RGAA sur lesquels ces points reposent.

• Aucune barrière critique ne se répète sur la quasi-totalité des pages. Une barrière présente partout pèse bien plus qu'un défaut isolé : elle ferme l'accès au site entier.
• Les textes atteignent le contraste exigé, mesuré sur la page affichée, bandeau de consentement compris. Un contraste insuffisant rend le texte illisible pour une partie des visiteurs.
• Les images qui portent une information ont une alternative textuelle ; celles qui décorent restent muettes. Un lecteur d'écran lit la première et doit taire la seconde.
• Chaque lien et chaque bouton a un intitulé qui dit où il mène. Une suite de liens « Lire la suite » identiques ne dit rien à qui la parcourt avec un lecteur d'écran.
• Les champs de formulaire ont un label, et les titres suivent une hiérarchie. Un champ dont le seul repère est un texte d'exemple perd son nom dès qu'on y écrit.
• Tout s'utilise au clavier, et le repère qui montre où l'on se trouve se voit. Un menu qui ne s'ouvre qu'au survol bloque qui navigue sans souris.

Une barrière qui se répète sur presque toutes les pages tient en général à un élément commun, menu, en-tête ou pied de page : corrigée là, elle disparaît partout.

Les guides sur les niveaux A et AA des WCAG, sur le RGAA et sur l'European Accessibility Act disent qui est tenu à quoi.

Conformité et vie privée : consentement, mentions, vente en ligne

La question : ce que le site affiche au titre de ses obligations est-il présent et bien réglé ? Le chapitre sur la conformité RGPD d'un site borne ce périmètre à ce qui se voit de l'extérieur.

• Aucun traceur tiers ne se charge avant que le visiteur ait répondu au bandeau. C'est le point le plus lourd de ce pilier, et un bandeau affiché ne suffit pas si les traceurs partent avant la réponse.
• Dès que des cookies non essentiels sont déposés, un mécanisme de consentement existe, et refuser y est aussi simple qu'accepter.
• Les mentions légales sont publiées, complètes, et liées depuis les pages du site ; la société qu'elles nomment est toujours active. Une page de mentions qu'aucune page ne lie, ou qui nomme une société cessée, ne renseigne personne.
• Sur un site qui vend à des consommateurs : le droit de rétractation, la garantie légale de conformité et le médiateur de la consommation sont mentionnés, et aucun lien ne mène à la plateforme européenne de règlement en ligne des litiges, fermée depuis le 20 juillet 2025.
• Sur un site que la réglementation y oblige, la déclaration d'accessibilité est publiée.
• Aucun enregistrement de session ni aucune reconnaissance par l'empreinte du navigateur ne démarre avant l'accord du visiteur. Le premier dispositif rejoue la navigation, le second identifie sans cookie.
• Des avis de clients affichés disent si leur authenticité est contrôlée, et comment.
• La politique de confidentialité existe, et énonce les traitements, leurs finalités et les droits des personnes.

Bloquer les traceurs jusqu'au consentement et publier des mentions complètes, liées depuis le site, ne touche pas au reste du site. Pour savoir à quelles obligations votre activité est tenue, le texte de loi fait foi, et un juriste tranche les cas douteux.

Quatre guides détaillent ces obligations : les mentions légales, les obligations d'un site e-commerce, la déclaration d'accessibilité et l'enregistrement des sessions avec Hotjar ou Clarity.

Domaine et réseau : expiration, messagerie, DNS

La question : votre domaine et votre messagerie sont-ils protégés ? Ces réglages vivent chez votre bureau d'enregistrement, pas dans le site, et le chapitre sur la sécurité du nom de domaine et des emails dit pourquoi ils échappent si souvent aux regards.

• Le nom de domaine n'expire pas dans les 90 jours. Un domaine expiré coupe le site et la messagerie en même temps.
• Dès que le domaine reçoit des emails, il publie des enregistrements SPF et DMARC complets. Sans eux, un tiers peut écrire à vos clients sous votre nom ; un enregistrement incomplet ne vaut guère mieux, et il se remarque moins.
• La zone DNS est signée avec DNSSEC. Sans signature, rien ne garantit que la réponse reçue par le visiteur est celle que vous avez publiée.
• Le domaine est verrouillé contre le transfert. Il ne change alors pas de bureau d'enregistrement sans qu'on lève d'abord ce verrou.
• Les serveurs de noms sont plusieurs et variés ; un enregistrement CAA, s'il est publié, limite les autorités qui peuvent émettre un certificat pour votre domaine.

Ces réglages se font dans le compte du bureau d'enregistrement et chez qui gère la zone DNS. Vérifiez au passage que le domaine est à votre nom, sur un compte que vous contrôlez, et que les rappels de renouvellement arrivent dans une boîte que quelqu'un lit.

Les guides sur l'expiration d'un nom de domaine, sur DMARC et DKIM et sur DNSSEC détaillent chaque réglage.

Indépendance et résilience : fournisseurs, droit, données

La question : de qui le site dépend-il, et que se passe-t-il si l'un de ses fournisseurs s'arrête ? Le chapitre sur l'hébergement et les dépendances d'un site distingue les deux moitiés du sujet, la juridiction et la résilience.

• Aucune donnée personnelle ne quitte l'Union pendant une visite sans garanties. Une police, une mesure d'audience ou une carte servies hors de l'Union reçoivent au moins l'adresse IP du visiteur.
• L'hébergement, le DNS, la diffusion du contenu et la messagerie ne reposent pas tous sur un seul fournisseur. Si celui qui porte tout le trafic s'arrête, le site s'arrête avec lui.
• Le fournisseur de chaque couche est nommé, avec son pays et le droit dont il relève. Un serveur en Europe exploité par une société soumise au droit américain reste exposé aux injonctions de ce droit.
• Partir reste possible : le contenu d'un site bâti sur des formats ouverts se déménage, celui d'une plateforme fermée se reconstruit.

Remplacer une police, une carte ou une mesure d'audience servie hors de l'Union ne demande pas de refonte. Changer d'hébergeur, ou répartir les couches entre plusieurs fournisseurs, est un projet qui se décide en sachant de qui le site dépend.

Les guides sur les transferts de données hors UE, sur la dépendance à un fournisseur unique et sur le CLOUD Act vont plus loin.

Contenu et confiance : ce qui fait douter un lecteur

La question : le contenu est-il clair, crédible et bien structuré ? Une partie de ces points se juge plutôt qu'elle ne se mesure, et le chapitre sur l'audit de contenu dit comment chaque jugement s'appuie sur une page et un extrait.

• Aucun texte de remplissage n'est resté en ligne : faux texte latin, valeurs à zéro, intertitres sans texte, « bientôt disponible » oublié. Le visiteur y lit un site inachevé.
• Chaque version linguistique est traduite, et non recopiée de la version principale. Une page annoncée dans une langue et écrite dans une autre perd le lecteur qui l'a choisie.
• Le contenu principal a été mis à jour depuis moins de 24 mois. Une page qui date visiblement fait douter que l'entreprise soit toujours active.
• Les faits ne se contredisent pas d'une page à l'autre, et l'orthographe est tenue. Un chiffre qui change selon la page fait douter des deux.
• L'identité, les coordonnées et la page « à propos » sont atteignables depuis la navigation. Ce sont les premiers signaux qu'un visiteur prudent cherche.
• Les informations importantes sont formulées clairement et structurées, pour qu'un système automatisé puisse les extraire et les attribuer au site.

Ces corrections sont les vôtres, ou celles de la personne qui écrit pour vous : relire les pages signalées, retirer le texte provisoire, mettre à jour ce qui a vieilli.

Les guides sur le faux texte resté en ligne, sur le contenu non traduit et sur les critères E-E-A-T de Google détaillent ces points.

Expérience et fiabilité : ce qui casse sans prévenir

La question : les pages et les parcours qui comptent fonctionnent-ils vraiment ? Ce pilier n'a pas de norme dédiée, et le chapitre sur les bugs et la fiabilité d'un site dit sur quels faits il repose.

• Aucune erreur JavaScript ne se produit au chargement. Une erreur peut arrêter un menu, un formulaire ou un panier sans rien afficher.
• Aucune ressource demandée par la page ne répond en erreur. Une image, un script ou une feuille de style manquants laissent un trou, ou cassent la mise en page.
• Une adresse qui n'existe pas répond 404, avec une page qui ramène dans le site. Une adresse inconnue qui répond 200 fait indexer des pages vides.
• Le site reste utilisable à toutes les largeurs d'écran. À une largeur précise, un bouton peut sortir de l'écran sans barre de défilement pour le trahir.
• Les boutons, menus et onglets font ce qu'ils annoncent. Une capture d'écran montre un bouton, pas ce qu'il fait.
• Les parcours qui font votre activité, contact, devis ou achat, sont atteignables et lisibles jusqu'au formulaire.

Essayez vous-même vos parcours de contact, de devis ou d'achat jusqu'au bout, sur téléphone comme sur ordinateur : c'est le chemin que prennent vos clients. Une erreur JavaScript ou une ressource manquante se corrige sur la page où elle se produit.

Les guides sur les erreurs JavaScript, sur les images et ressources qui ne chargent pas et sur les erreurs 404 disent ce que chacun de ces défauts casse.

Qui contrôle quoi, et ce qu'il faut exiger

Une partie de cette liste se vérifie en lisant le site : les mentions, les coordonnées, le texte provisoire, les parcours. Le reste se mesure, dans les réponses du serveur et dans ce que le navigateur charge et envoie pendant la visite. Confiez cette partie à quelqu'un qui n'a pas construit le site, et demandez le résultat par écrit. Sur un site neuf, faites-le avant de signer la recette. Le guide sur la recette d'un site web dit qui vérifie quoi.

Exigez de ce résultat, pour chaque défaut, la page en cause et la valeur relevée, la source quand le point repose sur une loi, une norme ou une spécification, et la liste de ce qui n'a pas pu être vérifié. Un point non vérifié ne doit jamais apparaître comme conforme.

La liste sert aussi à lire un audit qu'on vous propose : à chaque pilier absent correspond une question restée sans réponse. Un audit centré sur le référencement en couvre une section, et le guide audit SEO ou audit de site compare les deux.

Les plus fréquents en défaut, et les plus rares

Ces pourcentages portent sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026. Chacun ne compte que les sites où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : ces chiffres décrivent nos audits, pas l'ensemble des sites.

Les trois plus fréquents relèvent de l'indépendance et de la conformité, deux piliers que les listes de contrôle les mieux classées dans les moteurs abordent peu.

Les deux derniers chiffres disent l'inverse. Le HTTPS et le certificat figurent dans presque toutes les listes de contrôle, et ouvrent celle-ci parce qu'une panne arrête chaque visiteur, pas parce qu'elle est fréquente sur les sites audités. Une liste qui s'arrête à eux laisse de côté les défauts qui reviennent le plus, et qui ne se voient pas à l'écran.

Toute la liste, sur chaque page analysée

Notre audit vérifie les points de ces listes sur les pages analysées de votre site, sur les 9 piliers, et les réunit dans un seul rapport.

Les mesures se font dans un navigateur, comme chez un visiteur. La page est chargée sans rien cliquer, et ce qui s'y est déjà déposé est relevé. Le clavier est éprouvé par de vraies pressions de touches, le site est affiché à trois largeurs d'écran, et les contrôles sont réellement actionnés quand cela ne modifie rien chez vous. Sur la page de référence, en général l'accueil, la réponse du serveur est comparée à la page affichée. Les temps d'affichage viennent des visiteurs réels quand Google en publie pour le site, d'une mesure en laboratoire sinon ; la réactivité ne se mesure que sur des visiteurs réels, et sans leurs données elle est déclarée non vérifiable, jamais supposée bonne.

Chaque pilier reçoit une note sur cent selon un barème documenté et stable, appliqué aux faits relevés pendant l'audit. Les quatre situations du début plafonnent la note globale, et un point sans objet ne compte pas.

Pour chaque défaut relevé, le rapport cite la page et la valeur observée ; quand le point repose sur une loi, une norme ou une spécification, il cite sa source. C'est le document que vous remettez à la personne qui corrige. Chaque limite de l'examen est indiquée dans le rapport. Un point non vérifiable n'est jamais présenté comme conforme. Les deux rapports publiés en exemple montrent ces points tels qu'un rapport les présente, pilier par pilier.

Vous donnez l'adresse du site, sans aucun accès à fournir. Les forfaits commencent à 200 € HT ; seuls changent le nombre de pages analysées et le prix. Ils sont détaillés sur la page des tarifs. Le rapport est livré en 5 jours ouvrés jusqu'à 60 pages, paiement encaissé à la livraison.