Performance 8 min de lecture 20 janvier 2026

Audit technique d'un site web : méthode complète en 8 étapes

Comment auditer un site web existant : performance, accessibilité, SEO technique, sécurité, qualité du code. Méthode terrain utilisée sur des projets AEM, Java et e-commerce à fort trafic.

AuditPerformanceSEOAccessibilitéLighthouseCore Web Vitals

Reprendre un projet web sans audit, c’est partir en mission sans carte. Un audit technique bien mené révèle les problèmes structurels, priorise les corrections et chiffre l’impact potentiel avant d’écrire la première ligne de code. Voici la méthode que j’applique systématiquement avant toute intervention.

Pourquoi auditer avant d’intervenir ?

Sur des projets hérités — et c’est souvent le cas en freelance — le code est rarement documenté, les choix d’architecture sont rarement justifiés, et les problèmes de performance sont rarement localisés. Sans audit, on corrige les symptômes plutôt que les causes.

Un audit de 2 à 3 jours permet de :

Identifier les 20 % de problèmes qui causent 80 % des dysfonctionnements
Estimer le chiffrage d’un forfait avec précision
Aligner les attentes techniques et métier avant de commencer

Étape 1 — Performance perçue (Lighthouse + CrUX)

Le premier réflexe est de lancer Lighthouse en mode navigation privée (pour éviter les extensions) sur la page d’accueil, les pages catégorie et les pages produit si c’est un e-commerce.

# Via CLI pour des mesures reproductibles
npx lighthouse https://monsite.com \
  --output json \
  --output-path ./audit-report.json \
  --chrome-flags="--headless"

Métriques prioritaires à relever :

LCP (Largest Contentful Paint) — cible < 2,5 s
CLS (Cumulative Layout Shift) — cible < 0,1
INP (Interaction to Next Paint) — cible < 200 ms
TTFB (Time to First Byte) — cible < 800 ms

Compléter avec les données réelles CrUX dans Google Search Console (onglet Core Web Vitals) — Lighthouse mesure en labo, CrUX mesure le terrain réel.

Étape 2 — Analyse du chargement réseau

Dans Chrome DevTools → onglet Network, cocher “Disable cache” et “Throttling : Slow 4G” pour simuler les conditions mobiles dégradées.

Points à documenter :

Poids total de la page — un seuil de 2 MB est déjà problématique
Nombre de requêtes HTTP — au-delà de 80, investiguer les doublons
Images non optimisées — format JPEG/PNG > 100 KB alors que WebP/AVIF réduirait de 60 %
Ressources bloquantes — scripts <script src> sans defer ou async dans le <head>
Third-party scripts — analytics, chatbots, A/B testing qui ralentissent le rendu

// Identifier les ressources les plus lentes via la Performance API
performance.getEntriesByType("resource")
  .sort((a, b) => b.duration - a.duration)
  .slice(0, 10)
  .forEach(r => console.log(r.name, Math.round(r.duration) + "ms"));

Étape 3 — SEO technique

# Crawler rapide avec screaming frog ou sitemap check
curl -s https://monsite.com/sitemap.xml | grep -o '<loc>[^<]*</loc>'

Éléments à vérifier :

Balises title/description — uniques, longueurs correctes (50-60 / 120-160 cars)
Structure H1-H6 — une seule H1 par page, hiérarchie cohérente
Pages en noindex dans le sitemap — erreur fréquente (pages légales, pagination)
Canonical URLs — vérifier les doublons www/non-www, trailing slash
Données structurées — Schema.org validé via l’outil de test Google
Core Web Vitals dans Search Console — URLs en rouge/orange à corriger en priorité

Étape 4 — Accessibilité WCAG 2.1

npm install -g @axe-core/cli
axe https://monsite.com --tags wcag2a,wcag2aa

Les violations critiques (impact “serious” ou “critical” dans axe) bloquent des utilisateurs :

Contraste de texte insuffisant (ratio < 4,5:1 pour le corps de texte)
Images sans attribut alt ou alt non descriptif
Formulaires sans <label> associé
Navigation uniquement à la souris (pas de focus clavier visible)
Ordre de lecture incorrect dans le DOM (problème fréquent avec les grids CSS)

Étape 5 — Sécurité de base

# Vérification des en-têtes HTTP
curl -I https://monsite.com

En-têtes à vérifier :

Strict-Transport-Security (HTTPS forcé)
Content-Security-Policy (XSS mitigation)
X-Frame-Options: DENY ou SAMEORIGIN
X-Content-Type-Options: nosniff
Referrer-Policy

Outils complémentaires : securityheaders.com et SSL Labs.

Étape 6 — Qualité du code et dette technique

Pour les projets Java/Spring Boot :

# SonarQube en Docker
docker run -d -p 9000:9000 sonarqube:lts-community

# Analyse du projet
mvn sonar:sonar \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=votre-token

Points d’attention :

Code smells — méthodes trop longues, classes trop grandes, couplage fort
Coverage de tests — sous 40 %, le risque de régression est élevé
Dépendances vulnérables — mvn dependency:check ou npm audit
Logs applicatifs — exceptions répétées, NPE, timeouts

Pour les projets AEM : vérifier l’activation des composants dépréciés (Foundation components vs Core Components), les requêtes JCR non optimisées, et l’absence de cache Dispatcher.

Étape 7 — Monitoring et observabilité

Un site sans monitoring, c’est un site qui tombe silencieusement.

Uptime monitoring — UptimeRobot, Freshping (gratuit jusqu’à 50 monitors)
Error tracking — Sentry (même plan gratuit), permet de voir les erreurs JS en production
Analytics — s’assurer que GA4 ou Matomo sont configurés et que les événements clés sont trackés
Alertes — notifier sur Slack ou email si le temps de réponse dépasse 5 secondes

Étape 8 — Rapport et priorisation

L’audit se conclut par un rapport structuré avec :

Synthèse exécutive (1 page) — note globale par axe, 3 actions prioritaires
Tableau de priorisation — impact × effort × urgence pour chaque problème
Estimation de l’effort — en jours/homme pour chaque correctif

Problème                  | Impact | Effort | Priorité
LCP > 6s sur mobile       | Élevé  | Moyen  | P1
Images non converties WebP | Élevé  | Faible | P1
H1 manquant sur 12 pages  | Moyen  | Faible | P2
CSP manquante             | Élevé  | Faible | P1
Coverage tests < 20%      | Moyen  | Élevé  | P3

Ce qu’un audit révèle systématiquement

Sur les 30+ projets audités, les mêmes problèmes reviennent :

Des images non compressées représentent 60-70 % du poids de page
Des scripts tiers bloquants retardent le rendu de 2-4 secondes
Des pages importantes (catégories, fiches produit) sont absentes du sitemap ou en noindex par erreur
L’accessibilité est traitée en dernier recours plutôt qu’en conception

Mieux vaut découvrir ces problèmes avant de signer un forfait que pendant.

Amine MEGDICHE

Développeur AEM & Java Full Stack — Freelance depuis 2013

← Retour au blog Me contacter