Audit de site web en 2026 : la checklist complète SEO, Core Web Vitals, accessibilité et sécurité

En 2026, l’audit doit être mené par couches. Google continue de fonder la visibilité sur des bases techniques solides et sur des contenus conçus d’abord pour les personnes, même si les résultats peuvent aussi être présentés dans des fonctionnalités alimentées par l’IA. Les Core Web Vitals doivent être évalués à partir de données réelles, l’accessibilité ne peut pas être confirmée par un simple scanner et la sécurité exige bien plus que la présence d’un certificat SSL.

Ce guide couvre l’ensemble du processus : indexation et SEO, LCP, INP et CLS, WCAG 2.2, en-têtes de sécurité, formulaires, analytique et ordre de priorité des corrections.

TL;DR : commencez par les problèmes critiques : indisponibilité du site, blocage de l’indexation, redirections incorrectes, problèmes HTTPS et vulnérabilités. Améliorez ensuite les Core Web Vitals, l’accessibilité des parcours essentiels, les contenus et le maillage interne. Une note de 100/100 dans un outil ne remplace ni les données Search Console, ni les tests sur de vrais appareils, ni la vérification manuelle.

Les normes, seuils et sources ont été vérifiés pour la dernière fois le 23 juillet 2026.

Les principaux domaines de l’audit

Domaine	Ce qu’il faut vérifier	À quoi ressemble un bon résultat	Priorité
Indexation	robots.txt, noindex, sitemap, canonical, codes HTTP	pages importantes accessibles et indexables, doublons consolidés	critique
SEO et contenu	intention, titres, titres de sections, liens internes, données structurées	chaque page importante a un objectif clair et une valeur unique	élevée
Performance	LCP, INP, CLS, TTFB, JavaScript, images, polices	CWV dans la zone « bon » au 75e percentile	élevée
Accessibilité	clavier, focus, sémantique, contraste, formulaires, lecteurs d’écran	parcours principaux conformes au niveau WCAG 2.2 AA	élevée
Sécurité	HTTPS, en-têtes, cookies, dépendances, autorisation, sauvegardes	aucune vulnérabilité critique ni exposition inutile	critique
UX et conversion	mobile, formulaires, navigation, erreurs, confiance	l’utilisateur accomplit l’action principale sans friction inutile	élevée
Mesure	Search Console, analytique, journaux, surveillance	données complètes, conformes à la vie privée et exploitables	moyenne

Que couvre réellement un audit de site web ?

Un audit complet combine au moins six perspectives :

1. SEO technique - le robot peut-il accéder au site, le rendre, suivre les liens et identifier l’URL canonique correcte ?
2. Qualité du contenu - la page répond-elle à un besoin réel, possède-t-elle une structure logique et évite-t-elle les duplications inutiles ?
3. Performance - à quelle vitesse le contenu principal apparaît-il, le site répond-il rapidement et la mise en page reste-t-elle stable pendant le chargement ?
4. Accessibilité - le service est-il utilisable au clavier, avec un lecteur d’écran, avec zoom et sans dépendre uniquement de la couleur ?
5. Sécurité et confidentialité - les communications, sessions, formulaires, dépendances et données utilisateur sont-ils correctement protégés ?
6. UX et objectifs métier - les visiteurs comprennent-ils l’offre et peuvent-ils accomplir l’action essentielle sans étapes inutiles ?

Les outils automatiques constituent un excellent point de départ, mais ne savent pas tout évaluer. Lighthouse peut détecter certains problèmes de performance et d’accessibilité, mais il ne peut pas déterminer si l’offre est compréhensible, si un formulaire correspond aux besoins du client ou si un message d’erreur aide réellement à résoudre le problème.

Avant de commencer : définir le périmètre et l’échantillon d’URL

L’erreur la plus fréquente consiste à analyser uniquement la page d’accueil. En pratique, il faut tester des types de pages représentatifs :

• la page d’accueil,
• la page de service ou de produit la plus importante,
• un article ou un guide,
• une catégorie ou une liste,
• un formulaire de contact, une inscription ou le paiement,
• une page de résultats de recherche,
• une version linguistique,
• la page 404 et les autres états d’erreur,
• une page authentifiée, si elle existe.

Pour un petit site, un échantillon de quelques URL ou d’une douzaine peut suffire. Dans une boutique, un portail ou une application, auditez les modèles plutôt que des URL aléatoires. Si un modèle produit utilise un mauvais canonical ou charge un script trop lourd, le problème peut toucher des milliers de pages.

Avant l’audit, rassemblez :

• l’accès à Google Search Console et à l’outil analytique,
• la liste des objectifs métier prioritaires,
• le sitemap et les principaux modèles,
• les informations sur les changements, migrations et baisses de trafic,
• les données de surveillance des erreurs et les journaux serveur,
• les appareils et navigateurs les plus utilisés par les clients.

1. Audit du SEO technique et de l’indexation

Vérifier les codes HTTP et les variantes du domaine

Chaque URL importante doit renvoyer le bon statut :

• 200 pour une page fonctionnelle,
• 301 ou 308 pour une redirection permanente,
• 404 ou 410 pour un contenu supprimé,
• 5xx uniquement en cas de véritable erreur serveur, pas comme état permanent.

Contrôlez http/https, www/non-www, les barres obliques finales et la casse. Toutes les variantes doivent converger vers une version cohérente. Évitez les chaînes de redirections et les redirections massives d’anciennes URL vers une page d’accueil sans rapport avec le contenu initial.

Vérifier robots.txt, noindex et l’accès aux ressources

Le fichier robots.txt contrôle l’exploration au niveau du téléchargement, mais ce n’est pas un mécanisme de suppression d’une page des résultats de recherche. Une URL bloquée peut encore apparaître dans l’index si Google la découvre ailleurs. Pour exclure une page, utilisez notamment noindex, une protection par mot de passe ou la suppression de la ressource.

Vérifiez que :

• les sections importantes ne sont pas bloquées par erreur,
• l’environnement de préproduction est protégé et pas seulement masqué dans robots.txt,
• Google peut charger les CSS, JavaScript et images nécessaires au rendu,
• le sitemap se trouve à la bonne adresse et ne contient que des pages canoniques,
• une balise noindex n’est pas restée après la mise en production.

Évaluer les canonicals et les doublons

Une URL canonique indique la version préférée d’un contenu identique ou très similaire. Google considère le canonical comme un signal fort, mais peut sélectionner une autre URL lorsque les autres signaux se contredisent.

Contrôlez la cohérence entre :

• rel="canonical",
• les redirections,
• les liens internes,
• les sitemaps XML,
• les versions linguistiques,
• le protocole et l’hôte.

Le canonical doit généralement pointer vers une URL fonctionnelle en 200, et non vers une erreur, une redirection ou une URL marquée noindex.

Contrôler le rendu JavaScript

Google traite les applications JavaScript en plusieurs étapes : exploration, rendu et indexation. Le contenu généré côté client peut être traité plus tard que le HTML immédiatement disponible. Les informations et liens critiques ne doivent donc pas dépendre d’un script fragile.

Dans les SPA et les services à rendu hybride, vérifiez :

• le HTML disponible avant l’exécution de JavaScript,
• les liens sous forme de vrais éléments <a href>,
• la gestion des codes de statut,
• les métadonnées générées pour chaque URL,
• le comportement lors de l’ouverture directe d’une sous-page,
• les erreurs d’hydratation et les appels API échoués,
• l’indexabilité de la pagination et des listes à défilement infini.

Contrôler les versions linguistiques

Dans un site multilingue, chaque version doit posséder une URL stable. Vérifiez :

• les attributs hreflang valides,
• les références réciproques entre versions,
• un éventuel x-default,
• un canonical vers la même version linguistique,
• l’absence de redirections automatiques bloquant les robots,
• la traduction des titres, descriptions, contenus et éléments de navigation.

Checklist du SEO technique

• Les URL importantes renvoient 200.
• Les redirections sont directes et logiques.
• Aucun blocage robots.txt accidentel.
• La production ne contient pas de noindex involontaire.
• Le sitemap XML ne contient que des URL canoniques.
• Canonicals, liens et sitemap sont cohérents.
• JavaScript ne masque pas le contenu critique aux robots.
• Les pages 404 renvoient réellement le statut 404.
• Les versions linguistiques utilisent correctement hreflang.
• Les paramètres et filtres ne créent pas de doublons massifs.

2. Audit du contenu et du SEO on-page

Chaque page doit avoir un objectif principal

Le titre, le H1, l’introduction, le contenu et l’appel à l’action doivent répondre à la même intention. Lorsqu’une page essaie simultanément de vendre un service, d’expliquer les notions de base et de se positionner sur une douzaine de requêtes sans lien, elle remplit rarement correctement l’un de ces objectifs.

Vérifiez :

• que le title est unique et descriptif,
• que le H1 principal correspond au contenu,
• que l’extrait dans les résultats encourage le clic sans promesse exagérée,
• que les H2 et H3 construisent une hiérarchie logique,
• que la réponse apparaît tôt et non après une longue introduction,
• que l’article apporte expérience, exemples et sources,
• que la date de mise à jour correspond à une véritable modification.

Google recommande des contenus utiles, fiables et créés d’abord pour les personnes, plutôt que des pages conçues uniquement pour manipuler le classement.

Le maillage interne doit créer une structure

Un bon maillage interne aide l’utilisateur à passer à l’étape suivante et montre aux moteurs la relation entre les sujets. Utilisez des ancres descriptives plutôt que de nombreux liens génériques « cliquez ici ».

Les prolongements naturels de cet article sont :

• État du site web POLPROG,
• Core Web Vitals en pratique,
• Stratégie web,
• Performance,
• Sécurité,
• Comment planifier un site d’entreprise qui génère des prospects.

Recherchez aussi les pages orphelines, auxquelles aucun lien interne ne mène.

Images, données structurées et Open Graph

Les images doivent avoir des noms pertinents, des dimensions correctes et un texte alternatif lorsqu’elles transmettent une information. Une image purement décorative doit généralement utiliser alt="". Google prend en charge les formats courants, notamment JPEG, PNG, WebP, SVG et AVIF.

Contrôlez :

• width et height pour éviter les déplacements de mise en page,
• srcset et sizes,
• la compression et le format,
• le lazy loading sous la ligne de flottaison,
• le texte alternatif,
• des données structurées conformes au contenu visible,
• og:title, og:description, og:image et og:url.

Pour des contrôles pratiques, utilisez le Convertisseur et optimiseur d’images et l’Aperçu Open Graph.

SEO dans les expériences de recherche alimentées par l’IA

Google indique que les pratiques SEO fondamentales restent valables pour les fonctionnalités IA de la recherche. Aucun fichier spécial ni nouveau balisage n’est nécessaire uniquement pour apparaître dans AI Overviews ou AI Mode. La page doit rester indexable et respecter les exigences habituelles de Google Search.

La stratégie la plus raisonnable consiste à :

• publier des réponses claires et complètes,
• citer des sources et donner des exemples pratiques,
• actualiser les informations qui évoluent vite,
• éviter les contenus répétitifs produits en masse,
• maintenir une structure sémantique et un bon maillage interne,
• surveiller le trafic et les requêtes dans Search Console.

3. Core Web Vitals et performance

Seuils actuels

Les Core Web Vitals comprennent trois métriques. L’évaluation doit utiliser le 75e percentile des visites réelles, séparément pour mobile et ordinateur.

Métrique	Ce qu’elle mesure	Bon	À améliorer	Mauvais
LCP	apparition du plus grand élément de contenu	≤ 2,5 s	2,5-4,0 s	> 4,0 s
INP	délai de réponse aux interactions	≤ 200 ms	200-500 ms	> 500 ms
CLS	stabilité visuelle de la mise en page	≤ 0,1	0,1-0,25	> 0,25

Les données terrain décrivent l’expérience des vrais utilisateurs, tandis que les données laboratoire aident à reproduire un problème. Ne les confondez pas. Un site peut obtenir une bonne note Lighthouse en local, mais un mauvais INP sur d’anciens téléphones ou un LCP lent dans un pays donné.

Comment améliorer le LCP

Causes fréquentes d’un mauvais LCP :

• serveur lent ou cache absent,
• image hero trop lourde,
• ressource LCP découverte seulement par JavaScript,
• CSS et polices bloquant le rendu,
• longues chaînes de requêtes,
• logique lourde exécutée avant le rendu.

Actions :

• améliorer le TTFB et le cache,
• servir l’image aux bonnes dimensions,
• utiliser un format moderne et la compression,
• donner la priorité à la ressource principale,
• ne pas appliquer le lazy loading à l’image LCP,
• réduire les CSS et scripts critiques,
• utiliser un CDN lorsqu’il réduit réellement la distance vers l’utilisateur.

Comment améliorer l’INP

L’INP se dégrade avec les longues tâches sur le thread principal, l’excès de JavaScript, les rendus coûteux et les gestionnaires d’événements qui effectuent trop de travail.

Vérifiez :

• la durée des tâches dans le panneau Performance,
• les scripts tiers,
• les composants qui se rerendent à chaque changement,
• les grandes listes sans virtualisation,
• les opérations synchrones sur la mémoire et le DOM,
• la validation des formulaires et les animations pendant l’interaction.

Découpez les longues tâches, différez le travail non critique et envoyez le moins de JavaScript possible au navigateur.

Comment améliorer le CLS

Sources fréquentes de déplacements :

• images et iframes sans dimensions,
• publicités sans espace réservé,
• bandeaux cookies injectés au-dessus du contenu,
• polices chargées tardivement,
• composants ajoutés avant le contenu existant,
• animation de propriétés qui influencent la mise en page.

Réservez l’espace, utilisez des placeholders stables et testez toute la séquence de chargement, pas seulement la capture finale.

Ne pas optimiser uniquement la note Lighthouse

Lighthouse est un test de laboratoire exécuté dans des conditions contrôlées. Un bon processus combine :

• Search Console et son rapport Core Web Vitals,
• les données CrUX ou RUM,
• Lighthouse et le panneau Performance,
• des tests sur un appareil plus lent,
• la surveillance des régressions après mise en production.

4. Audit d’accessibilité selon WCAG 2.2

WCAG 2.2 définit des critères qui se testent avec une combinaison d’évaluation automatique et humaine. Un scanner seul ne peut pas confirmer une conformité complète, car certains critères nécessitent une compréhension du contexte et des tests d’interaction.

Clavier et focus

Parcourez l’itinéraire principal sans souris :

• chaque élément interactif est-il accessible,
• l’ordre du focus est-il logique,
• l’indicateur de focus est-il clairement visible,
• une fenêtre modale contient-elle le focus et le restitue-t-elle après fermeture,
• existe-t-il un piège au clavier,
• peut-on ignorer la navigation répétée.

Sémantique et lecteurs d’écran

Vérifiez :

• un H1 logique et une hiérarchie correcte des titres,
• les repères header, nav, main et footer,
• de vrais boutons et liens plutôt que des div cliquables,
• des noms accessibles pour les icônes,
• l’annonce des changements dynamiques,
• l’ordre de lecture correct,
• la langue du document dans l’attribut lang.

ARIA doit compléter le HTML sémantique, pas le remplacer sans nécessité.

Formulaires et erreurs

Chaque champ doit avoir une étiquette visible et une relation programmatique avec sa description. Une erreur doit indiquer ce qu’il faut corriger et ne peut pas être signalée uniquement par la couleur.

Testez :

• étiquettes et instructions,
• champs obligatoires,
• attributs d’autocomplétion,
• ordre de tabulation,
• messages d’erreur,
• résumé des erreurs après envoi,
• comportement avec zoom et sur écran étroit,
• limites de temps et possibilité de les prolonger.

Contraste, zoom et mouvement

Vérifiez le contraste du texte, des icônes et des états de focus. Testez le site avec un zoom à 200 % et 400 %, un texte agrandi et un viewport étroit. Le contenu ne devrait pas nécessiter de défilement horizontal, sauf lorsque cela est réellement justifié.

Les animations doivent respecter prefers-reduced-motion. Les éléments qui se déplacent automatiquement doivent pouvoir être arrêtés lorsqu’ils affectent la compréhension.

Checklist d’accessibilité

• Le parcours complet fonctionne au clavier.
• Le focus est visible et logique.
• Les titres et repères décrivent la structure.
• Les boutons et liens ont des noms compréhensibles.
• Les formulaires ont des étiquettes et des erreurs utiles.
• Le contraste respecte WCAG 2.2 AA.
• Le contenu fonctionne avec zoom et reflow.
• Les images informatives ont un texte alternatif adapté.
• Les mouvements peuvent être réduits.
• Les tâches essentielles ont été testées avec un lecteur d’écran.

5. Audit de sécurité et de confidentialité

HTTPS est un début, pas une fin

L’ensemble du site doit fonctionner en HTTPS sans contenu mixte actif. Vérifiez la validité du certificat, la chaîne de confiance, les protocoles pris en charge, le renouvellement automatique et la redirection HTTP vers HTTPS. Lighthouse signale les pages sans HTTPS, mais n’effectue pas un test d’intrusion complet.

Vous pouvez contrôler le domaine et le certificat avec l’Inspecteur DNS et SSL.

En-têtes de sécurité

Les en-têtes ne corrigent pas une autorisation défaillante, mais limitent certaines classes d’attaques et certains comportements dangereux du navigateur. OWASP Secure Headers Project maintient des recommandations et exemples à jour.

Vérifiez au minimum :

• Content-Security-Policy,
• Strict-Transport-Security,
• X-Content-Type-Options: nosniff,
• Referrer-Policy,
• Permissions-Policy,
• la protection contre l’intégration via frame-ancestors,
• les attributs sécurisés des cookies : Secure, HttpOnly et un SameSite approprié.

Il vaut mieux introduire CSP par étapes : commencer par Content-Security-Policy-Report-Only, analyser les rapports, puis activer l’application. Une configuration copiée doit être adaptée aux ressources réellement utilisées.

Pour un contrôle rapide, utilisez l’Inspecteur des en-têtes de sécurité.

OWASP Top 10:2025 comme carte des risques

L’OWASP Top 10:2025 couvre notamment les contrôles d’accès défaillants, les mauvaises configurations, les défaillances de la chaîne d’approvisionnement logicielle, les erreurs cryptographiques, les injections, la conception non sécurisée, les erreurs d’authentification, les problèmes d’intégrité, les défaillances de journalisation et d’alerte, ainsi que la mauvaise gestion des situations exceptionnelles.

En pratique, vérifiez :

• qu’un utilisateur ne peut pas lire ou modifier les données d’un autre,
• que le panneau d’administration dispose d’une protection supplémentaire,
• que l’API valide les permissions côté serveur,
• que les dépendances et images de conteneurs sont maintenues,
• que les secrets ne figurent ni dans le dépôt ni dans le code client,
• que les entrées sont validées et les sorties encodées,
• que les sessions expirent et peuvent être révoquées,
• que les logs n’enregistrent pas mots de passe, jetons ou données sensibles,
• que les erreurs ne révèlent pas stack traces et détails d’infrastructure,
• que les sauvegardes existent et que la restauration a été testée.

Pour les applications gérant connexion, paiements ou données clients, basez le périmètre sur OWASP ASVS plutôt que sur une simple liste d’en-têtes.

Confidentialité et analytique

Contrôlez :

• les scripts exécutés avant consentement,
• si les formulaires collectent uniquement les données nécessaires,
• les durées de conservation,
• l’accès des employés et fournisseurs,
• la possibilité de retirer le consentement,
• la configuration du Consent Mode, s’il est utilisé,
• la journalisation des adresses IP et identifiants,
• la cohérence entre la politique de confidentialité et le fonctionnement réel.

Ne supposez pas qu’un bandeau cookies garantit automatiquement la conformité. Ce qui compte, c’est ce que le site charge et transmet réellement.

6. UX, mobile et conversion

Un audit technique peut être réussi tandis que le site continue à ne pas atteindre son objectif. Parcourez le chemin principal comme un nouveau visiteur :

• comprend-on dès le premier écran ce que fait l’entreprise,
• chaque CTA décrit-il une action précise,
• la navigation évite-t-elle de devoir deviner,
• le formulaire ne demande-t-il que les informations nécessaires,
• les erreurs sont-elles faciles à corriger,
• téléphone et e-mail sont-ils cliquables sur mobile,
• les éléments ne se chevauchent-ils pas,
• les pop-ups laissent-ils le contenu utilisable,
• les messages de succès sont-ils sans ambiguïté,
• le site résiste-t-il à une connexion lente et à des requêtes échouées.

Testez aussi la page 404, les résultats de recherche vides, les produits ou services indisponibles, les sessions expirées et les paiements échoués. Les états exceptionnels déterminent souvent si une personne reviendra.

Pour les sites de génération de prospects, consultez Comment planifier un site d’entreprise qui génère des prospects.

7. Mesure, surveillance et qualité des données

Search Console montre les performances du site dans Google Search, tandis que l’outil analytique montre ce que font les visiteurs après leur arrivée. Croiser ces perspectives aide à distinguer un problème de visibilité d’un problème de conversion.

Vérifiez :

• que la propriété Search Console couvre la bonne variante de domaine,
• les erreurs d’indexation et actions manuelles,
• les requêtes, pages, pays et appareils,
• les variations de clics et d’impressions après déploiement,
• la complétude des événements analytiques,
• l’exclusion du trafic interne et des robots,
• l’exactitude du tunnel de conversion,
• les alertes d’erreurs JavaScript et serveur,
• la surveillance de disponibilité et du certificat.

Ne corrigez pas tout simultanément sans point de référence. Enregistrez l’état initial et déployez les modifications par groupes afin d’en mesurer l’effet.

Combien de temps prend un audit ?

Les valeurs ci-dessous sont des estimations pratiques, pas une norme officielle. Le périmètre dépend du nombre de modèles, de l’accès aux données, de la technologie et du niveau de risque.

Périmètre	Temps indicatif	Contenu
Contrôle rapide d’une URL	15-30 min	statut, métadonnées, CWV de base, HTTPS et erreurs principales
Petit site d’entreprise	2-6 h	échantillon, SEO, CWV, accessibilité, sécurité et UX
Site éditorial ou multilingue	1-3 jours	modèles, indexation, hreflang, liens, données et priorités
Boutique en ligne	3-7 jours	catégories, produits, filtres, paiement, données structurées, performance
Application web	5-10+ jours	rôles, autorisation, parcours, API, états d’erreur, tests manuels
Audit de sécurité à haut risque	périmètre séparé	modélisation des menaces, ASVS, tests applicatifs et infrastructure

Le coût augmente moins avec le nombre brut d’URL qu’avec le nombre de comportements différents. Mille produits sur un seul modèle peuvent être plus simples à évaluer qu’une application avec dix rôles et de nombreux états.

Comment prioriser les corrections ?

Utilisez un modèle simple : impact × portée × risque ÷ coût de mise en œuvre.

P0 - corriger immédiatement

• site ou fonction critique indisponible,
• sections importantes bloquées à l’indexation,
• fuite de données ou contournement d’autorisation,
• certificat expiré ou contenu mixte actif,
• migration produisant des erreurs massives et des URL perdues,
• formulaire qui ne transmet pas les demandes.

P1 - priorité élevée

• mauvais CWV sur les modèles essentiels,
• barrières importantes au clavier et dans les formulaires,
• canonicals ou hreflang incorrects,
• offre peu claire et conversion difficile,
• dépendances critiques non corrigées,
• absence de surveillance des erreurs importantes.

P2 - planifier au prochain cycle

• titres dupliqués et maillage interne faible,
• textes alternatifs manquants,
• images lourdes sous la ligne de flottaison,
• données structurées incohérentes,
• pages 404 et états vides peu travaillés,
• problèmes touchant les modèles moins fréquentés.

P3 - optimisation et développement

• données structurées supplémentaires,
• réduction supplémentaire du poids,
• tests de textes et CTA,
• enrichissement des contenus,
• nettoyage des composants et de la documentation.

Plan de correction à 30, 60 et 90 jours

Les 30 premiers jours

Résolvez les problèmes P0, l’indexation, les redirections, HTTPS, les formulaires et les risques de perte de données. Établissez une mesure de référence.

D’ici 60 jours

Travaillez sur les modèles prioritaires : Core Web Vitals, clavier, formulaires, contenu, maillage interne et sécurité applicative. Mettez en place la surveillance des régressions.

D’ici 90 jours

Améliorez les modèles secondaires, normalisez le processus de publication, ajoutez des contrôles automatiques dans la CI et planifiez des audits récurrents après les versions importantes.

Checklist complète avant de clôturer l’audit

SEO et indexation

• Les robots peuvent charger les pages et ressources importantes.
• Le sitemap XML est à jour.
• Canonicals, redirections et liens sont cohérents.
• Aucun noindex involontaire.
• Les pages importantes ont un titre, un H1 et un contenu uniques.
• Le maillage mène aux pages importantes pour l’activité.
• Les versions linguistiques utilisent correctement hreflang.
• Les données structurées correspondent au contenu visible.
• Les métadonnées Open Graph sont complètes.

Performance

• LCP, INP et CLS respectent les seuils dans les données terrain.
• L’image LCP a les bonnes dimensions et la bonne priorité.
• JavaScript ne bloque pas l’interaction.
• Les images ont des dimensions et un format adaptés.
• Polices et ressources critiques ne créent pas de retard évitable.
• Les résultats sont surveillés après déploiement.

Accessibilité

• Le site fonctionne sans souris.
• Le focus est visible.
• La sémantique et l’ordre des titres sont logiques.
• Les formulaires ont des étiquettes et des erreurs utiles.
• Contraste et reflow respectent WCAG 2.2 AA.
• L’interface a été testée avec un lecteur d’écran.

Sécurité et confidentialité

• HTTPS fonctionne partout et le certificat est surveillé.
• Les cookies de session ont des attributs sécurisés.
• Les en-têtes sont adaptés à l’application.
• Les permissions sont vérifiées côté serveur.
• Dépendances et secrets sont contrôlés.
• Logs et alertes permettent de réagir.
• Les sauvegardes ont été testées.
• Les scripts de suivi respectent le consentement.

UX et activité

• L’offre est compréhensible sans lire toute la page.
• Les CTA mènent à l’action prévue.
• Les formulaires et le paiement fonctionnent sur mobile.
• Les états d’erreur aident l’utilisateur.
• Événements et conversions sont correctement mesurés.
• Chaque correction a un responsable, une priorité et une échéance.

Comment utiliser l’outil État du site web POLPROG ?

L’outil État du site web permet de commencer l’audit à partir d’une URL et de contrôler SEO, performance, accessibilité, sécurité et bonnes pratiques. Les tests sont exécutés côté serveur et ne nécessitent pas d’inscription.

Un processus efficace :

1. Analyser la page d’accueil et chaque modèle important.
2. Noter les erreurs critiques et les tendances répétitives.
3. Confirmer les CWV avec des données réelles.
4. Tester manuellement clavier, formulaires et parcours essentiels.
5. Contrôler séparément les en-têtes de sécurité, DNS et SSL et Open Graph.
6. Prioriser le backlog selon l’impact et le risque.
7. Répéter le test après mise en œuvre et surveiller les régressions.

Conclusion

Le meilleur audit de site web en 2026 ne se termine pas par un document contenant cent avertissements. Il se termine par une liste d’actions courte et ordonnée, qui distingue les problèmes critiques des détails cosmétiques, attribue les responsabilités et permet de vérifier le résultat après mise en œuvre.

Assurez-vous d’abord que le site est disponible, indexable et sécurisé. Améliorez ensuite les parcours clés, les Core Web Vitals et l’accessibilité. Optimisez seulement après les détails moins importants. Cet ordre crée généralement plus de valeur que la recherche d’une note parfaite dans un seul scanner.