Une méthode structurée pour comprendre un site, auditer ses performances, son SEO, son accessibilité et ses pratiques de sécurité.

Analyse d'un site web : méthode, outils et bonnes pratiques

0

Une méthode structurée pour comprendre un site, auditer ses performances, son SEO, son accessibilité et ses pratiques de sécurité.

Photo: Pixabay / Pexels
14 min read

Objectif et cadre

Analyser un site web, ce n'est pas seulement regarder le code source. Un site moderne assemble du HTML, du CSS, du JavaScript, des médias, des appels API, des cookies, du stockage local, des scripts tiers, des outils analytics et parfois des mécanismes d'authentification.

L'objectif peut être de comprendre son fonctionnement, auditer son propre site, améliorer les performances, vérifier le SEO, analyser l'accessibilité ou identifier de mauvaises pratiques de sécurité.

Ce tutoriel reste dans un cadre légal et éthique. Il ne vise pas à contourner une authentification, exploiter une faille, aspirer massivement un site, accéder à des données privées ou perturber un service.

Définir le périmètre

Avant de commencer, notez le cadre d'analyse :

Site analysé :
Objectif : apprentissage / audit interne / performance / SEO / accessibilité / sécurité
Propriétaire :
Autorisation : oui / non
Pages concernées :
Actions autorisées :
Actions interdites :
Dates de test :
Contact technique :

Inspecter le HTML, le CSS et le JavaScript chargés dans son navigateur, mesurer les performances, vérifier l'accessibilité, lire les headers HTTP ou consulter robots.txt et sitemap.xml est généralement acceptable. En revanche, contourner une authentification, accéder à des endpoints privés, lancer des scans intrusifs ou récupérer des données personnelles nécessite une autorisation claire.

Les grands axes d'analyse

Une analyse web se découpe en plusieurs angles complémentaires :

  • front-end : HTML, CSS, JavaScript, DOM, composants, frameworks ;
  • réseau : requêtes, API, scripts tiers, CDN, codes HTTP, temps de chargement ;
  • performance : poids des ressources, rendu initial, cache, Core Web Vitals ;
  • SEO : title, meta description, titres, URLs, maillage, sitemap, indexabilité ;
  • accessibilité : contraste, clavier, textes alternatifs, labels, ARIA ;
  • sécurité défensive : headers, cookies, CORS, CSP, erreurs visibles, dépendances.

L'idée est de comprendre comment le site fonctionne, pas de le pousser hors de son usage normal.

Préparer son environnement

Un navigateur moderne suffit déjà beaucoup. Les outils utiles sont :

  • Chrome DevTools ou Firefox DevTools ;
  • Lighthouse, PageSpeed Insights et WebPageTest ;
  • Wappalyzer ou BuiltWith pour identifier la stack ;
  • curl, wget ou httpie pour inspecter des réponses ;
  • axe DevTools pour l'accessibilité ;
  • Screaming Frog SEO Spider pour le SEO ;
  • Playwright ou Puppeteer pour automatiser des vérifications sur son propre site ;
  • mitmproxy ou Burp Suite uniquement dans un audit autorisé.

Bonnes pratiques : utiliser un profil navigateur dédié, désactiver les extensions inutiles, tester cache vide et cache chaud, vérifier mobile et desktop, noter la date, le navigateur et les pages testées.

Première inspection avec les DevTools

Ouvrez les DevTools avec F12 ou clic droit puis Inspecter. Les onglets essentiels sont :

  • Elements / Inspector : HTML, DOM et CSS appliqué ;
  • Console : erreurs JavaScript et logs ;
  • Network : requêtes réseau ;
  • Sources / Debugger : fichiers JS/CSS ;
  • Application / Storage : cookies, localStorage, sessionStorage, IndexedDB, cache ;
  • Performance : rendu et coûts JavaScript ;
  • Lighthouse : audit automatique.

Commencez par recharger la page avec l'onglet Network ouvert et "Preserve log" activé.

Analyser le HTML

L'onglet Elements permet d'examiner la structure rendue. À vérifier :

[ ] Un seul h1 principal
[ ] Titres dans un ordre logique
[ ] Balises sémantiques utilisées
[ ] Images avec alt pertinent
[ ] Formulaires avec labels
[ ] Liens compréhensibles hors contexte
[ ] Pas de contenu important uniquement en image

Une structure saine ressemble à :

<header>
  <nav aria-label="Navigation principale">
    <a href="/">Accueil</a>
    <a href="/services">Services</a>
  </nav>
</header>

<main>
  <h1>Nos services</h1>
  <section>
    <h2>Accompagnement</h2>
    <p>...</p>
  </section>
</main>

Les balises sémantiques aident l'accessibilité, le SEO et la maintenance.

Analyser le CSS

Le CSS révèle l'architecture visuelle : frameworks, classes utilitaires, variables, media queries, animations, styles inline et responsive design.

Dans les DevTools, sélectionnez un élément pour voir les règles appliquées, les règles écrasées, le modèle de boîte, les marges, le padding et la source du fichier.

Signes positifs :

  • variables CSS bien nommées ;
  • peu de styles inline ;
  • composants réutilisables ;
  • responsive clair ;
  • peu de surcharges inutiles ;
  • cohérence visuelle.

Exemple :

:root {
  --color-primary: #1f6feb;
  --spacing-md: 1rem;
  --radius-md: 0.5rem;
}

Analyser le JavaScript

Le JavaScript peut indiquer la stack, la logique front-end, les appels API et les dépendances tierces. Regardez les bundles, erreurs console, frameworks, source maps et scripts externes.

Indices courants :

React   → __REACT_DEVTOOLS_GLOBAL_HOOK__, root React
Vue     → __VUE__, data-v-xxxx
Angular → ng-version
Next.js → __NEXT_DATA__, /_next/static/
Nuxt    → __NUXT__, /_nuxt/

Les source maps peuvent exposer plus d'informations que prévu : noms de fichiers, commentaires, chemins internes ou logique métier. Ce n'est pas toujours une faille, mais cela mérite vérification en production.

Analyser l'onglet Network

Network montre les requêtes, leur ordre, durée, taille, headers, réponses, erreurs et redirections.

Méthode simple :

  1. Ouvrir DevTools.
  2. Aller dans Network.
  3. Cocher "Preserve log".
  4. Recharger.
  5. Filtrer par JS, CSS, Img, Fetch/XHR, Doc.
  6. Identifier les ressources lourdes, lentes ou en erreur.

Codes fréquents :

200 OK
301 / 302 Redirection
304 Not Modified
401 Unauthorized
403 Forbidden
404 Not Found
429 Too Many Requests
500 Server Error

Documenter domaines contactés, ressources lentes, images lourdes, erreurs 404, dépendances externes, absence de cache et redirections inutiles est utile et peu intrusif.

Lire les headers HTTP

Avec curl :

curl -I https://example.com

Headers intéressants :

Strict-Transport-Security
Content-Security-Policy
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
Cache-Control

Ces headers ne garantissent pas qu'un site est sécurisé, mais leur absence indique souvent des améliorations possibles.

Cookies et stockage local

Dans DevTools, ouvrez Application puis Cookies, Local Storage, Session Storage et IndexedDB.

Pour les cookies, vérifiez :

  • domaine, expiration et chemin ;
  • HttpOnly pour les cookies de session ;
  • Secure en HTTPS ;
  • SameSite adapté ;
  • absence de données sensibles lisibles.

Exemple :

Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax; Path=/

Évitez de stocker des tokens sensibles dans localStorage quand une alternative plus sûre existe. Ce stockage augmente l'exposition en cas de XSS.

Formulaires

Les formulaires sont des zones sensibles. Inspectez méthode GET ou POST, endpoint, validation client, messages d'erreur, autocomplete, labels, anti-spam, CSRF pour les actions authentifiées et comportement en cas d'échec.

Un formulaire doit être validé côté client pour l'expérience utilisateur, mais surtout côté serveur pour la sécurité.

SEO technique

Vérifiez les bases :

<title>Titre clair de la page</title>
<meta name="description" content="Description concise et utile.">
<link rel="canonical" href="https://example.com/page">

Contrôlez la hiérarchie h1, h2, h3, les URLs, le maillage interne, les données structurées JSON-LD, robots.txt et sitemap.xml.

Important : robots.txt n'est pas une protection de sécurité. Il donne des indications aux robots, mais une URL listée peut rester publique.

Performance

Mesurez avec Lighthouse, PageSpeed Insights, WebPageTest, Performance et Network.

Indicateurs importants :

LCP  → Largest Contentful Paint
INP  → Interaction to Next Paint
CLS  → Cumulative Layout Shift
TTFB → Time To First Byte
FCP  → First Contentful Paint

Causes fréquentes de lenteur : images trop lourdes, JavaScript excessif, CSS bloquant, absence de cache, polices mal chargées, trop de scripts tiers, serveur lent ou redirections inutiles.

Optimisations courantes : compresser les images, utiliser WebP/AVIF, lazy-loader les images non critiques, minifier, supprimer le code inutilisé, activer le cache HTTP et différer les scripts non critiques.

Accessibilité

Tests rapides :

[ ] Navigation au clavier uniquement
[ ] Focus visible
[ ] Contrastes suffisants
[ ] Images avec alt
[ ] Labels de formulaires
[ ] Structure des titres
[ ] Lecteur d'écran si possible

Problèmes fréquents : boutons sans texte accessible, images sans alt, contrastes faibles, modales non navigables au clavier, focus invisible, liens "cliquez ici" et titres incohérents.

Un bouton clair est souvent meilleur qu'un bouton uniquement iconique :

<button>Fermer</button>

Technologies et scripts tiers

Quelques indices :

WordPress → /wp-content/, /wp-json/
Shopify   → cdn.shopify.com
Next.js   → /_next/static/
Nuxt      → /_nuxt/
Webflow   → webflow.js
Wix       → static.wixstatic.com

Listez aussi les scripts tiers : analytics, tag managers, pixels, chat, paiement, reCAPTCHA, widgets marketing et CDN JavaScript. Trop de scripts tiers peut ralentir le site, compliquer le consentement cookies et augmenter la surface d'exposition.

Lighthouse et automatisation

Lighthouse donne des scores Performance, Accessibility, Best Practices et SEO. C'est une aide, pas un verdict absolu : les résultats varient selon machine, réseau, cache, localisation, extensions et état serveur.

Sur votre propre site, Playwright peut automatiser des vérifications :

import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com');

console.log(await page.title());

const links = await page.$$eval('a', anchors =>
  anchors.map(a => ({ text: a.innerText, href: a.href }))
);

console.log(links);
await browser.close();

À éviter sur des sites tiers sans autorisation : automatiser une navigation massive ou agressive.

Mini-analyse fictive

Pour https://example-demo.local, on observe :

main.js        900 Ko
hero.jpg       3,4 Mo
style.css      180 Ko
analytics.js   tiers

Problèmes probables : image principale trop lourde et bundle JavaScript volumineux.

Le HTML montre :

<h1>Bienvenue</h1>
<h1>Nos services</h1>

Amélioration : garder un seul h1 principal et utiliser h2 pour les sections.

Un cookie de session correctement configuré ressemble à :

session_id
Secure: true
HttpOnly: true
SameSite: Lax

Rapport synthétique :

Points positifs :
- Structure simple
- HTTPS actif
- Cookie de session correctement configuré

Améliorations :
- Compresser l'image principale
- Réduire le bundle JavaScript
- Corriger la hiérarchie des titres
- Ajouter des textes alternatifs
- Vérifier les scripts tiers

Checklist rapide

[ ] Objectif et périmètre définis
[ ] Pages principales identifiées
[ ] HTML inspecté
[ ] CSS inspecté
[ ] JavaScript inspecté
[ ] Erreurs console relevées
[ ] Requêtes Network analysées
[ ] Headers HTTP vérifiés
[ ] Cookies vérifiés
[ ] localStorage/sessionStorage inspectés
[ ] robots.txt consulté
[ ] sitemap.xml consulté
[ ] Performance mesurée
[ ] SEO technique vérifié
[ ] Accessibilité vérifiée
[ ] Scripts tiers listés
[ ] Rapport rédigé

Modèle de rapport

# Rapport d'analyse web

## Informations générales
Site :
Date :
Navigateur :
Pages analysées :
Objectif :

## Résumé
Constats principaux.

## Technologies
CMS/framework :
Bibliothèques JS :
Hébergement/CDN :
Analytics :

## Performance / SEO / Accessibilité / Sécurité défensive
Constats :
Impact :
Recommandations :

## Priorisation
Critique :
Élevé :
Moyen :
Faible :

Ce qu'il faut éviter

Sans autorisation explicite, évitez scan agressif, brute force, exploitation, contournement d'authentification, extraction massive de données, tests destructifs, modification de paramètres sensibles, contournement de paywall ou réutilisation de contenus protégés.

L'objectif d'une analyse responsable est d'améliorer, comprendre et documenter, pas d'abuser du service.

Conclusion

La méthode générale est simple : définir le périmètre, inspecter HTML/CSS/JS, observer le réseau, vérifier headers, cookies et stockages, mesurer performance, SEO et accessibilité, identifier les technologies, documenter les constats et proposer des recommandations concrètes.

Avec un navigateur et les DevTools, on peut déjà apprendre énormément. La limite reste claire : observer et comprendre, oui ; contourner, exploiter ou perturber, non.