Exemple de rapport

Voici ce que vous recevez.

Un vrai rapport, sur un vrai site : notre propre site Guardian Wall, analysé le 12 novembre 2026. Les deux documents tels qu'ils sont livrés : l'échantillon gratuit, puis le rapport complet détaillé avec le plan d'action, les corrections et le code à transmettre à votre prestataire.

Les deux documents

Échantillon gratuit

guardianwall.fr : 3 points à corriger en priorité

Analyse de 2 pages publiques de guardianwall.fr, telles qu'un visiteur les voit, le 12 novembre 2026.

Pré-diagnostic gratuit
Exemple réel

Synthèse

  • 96/100Score global
  • 94Accessibilité
  • 95Sécurité
  • 100Obligations et RGPD

Indicateur automatique sur l'échantillon observé, sans certification.

Ce qu'il faut corriger d'abord

1. Texte du pied de page trop pâle pour être lu
À corriger

Ce texte est quasiment invisible pour une personne malvoyante, et difficile à lire pour tout le monde sur un écran de téléphone en extérieur. C'est la seule erreur bloquante relevée sur les pages analysées.

Constaté : La ligne de copyright du pied de page est bleu-gris foncé (#2a4560) sur fond presque noir (#060b18), en 12 pixels : rapport de contraste mesuré 1,98 pour 1, pour un minimum exigé de 4,5 pour 1. Domaine : Accessibilité.

Piste : éclaircir la couleur du texte jusqu'à au moins 4,5 pour 1 sur le fond #060b18.

Corrigé le 12 novembre 2026, le jour même. Nouvelle analyse : accessibilité 100/100, plus aucune erreur bloquante.

2. Vidéo de démonstration sans sous-titres
À surveiller

Si la vidéo est commentée, une personne sourde ou malentendante, ou quiconque regarde sans le son (transports, bureau), perd l'explication. Un lien de téléchargement est bien proposé, ce qui est une bonne pratique.

Constaté : La vidéo de démonstration de l'extension n'a aucune piste de sous-titres (élément track). L'outil ne peut pas savoir si elle contient de la parole : c'est à confirmer à l'écoute. Domaine : Accessibilité.

Piste : écouter la vidéo : si elle ne contient ni parole ni son utile, l'indiquer en légende et la règle est satisfaite.

3. Politique de sécurité qui autorise les scripts en ligne
À surveiller

C'est précisément la protection qu'une CSP doit apporter contre l'injection de script (XSS). Avec 'unsafe-inline', elle est neutralisée pour les scripts. Deux scripts en ligne sont en cause : l'animation de particules de l'accueil et le menu mobile de /extension/.

Constaté : Le site envoie bien une politique de sécurité du contenu, solide sur la plupart des points (object-src 'none', frame-ancestors 'none', upgrade-insecure-requests). Mais script-src contient 'unsafe-inline' : n'importe quel script écrit directement dans la page est autorisé. Domaine : Sécurité visible.

Piste : déplacer le code de l'animation de particules et celui du menu mobile dans un fichier externe, par exemple /js/site.js.

Dans le rapport complet, en plus :

  • les 3 autres points relevés, page par page, et pas seulement les trois premiers ;
  • la correction détaillée de chaque point, étape par étape, avec un exemple de code avant et après ;
  • la référence de chaque règle (critère WCAG, recommandation CNIL ou ANSSI) ;
  • un plan d'action classé par priorité, avec l'effort estimé et la personne à qui le confier ;
  • la façon de vérifier chaque correction une fois faite.

Rapport complet détaillé : Tarif sur demande. Format HTML ou PDF, envoyé par e-mail.

Rapport complet détaillé

guardianwall.fr : rapport complet et plan d'action

guardianwall.fr · 2 pages analysées le 12 novembre 2026 · accessibilité, cookies et RGPD, sécurité visible

À transmettre à votre prestataire
Exemple réel

1Synthèse et périmètre

  • 96/100Score global
  • 94Accessibilité
  • 95Sécurité
  • 100Obligations et RGPD

1priorité 1 : à corriger rapidement

2priorité 2 : à corriger ensuite

3priorité 3 : à vérifier ou surveiller

17contrôles conformes

Pages analysées
/ (accueil), /extension/
Méthode
Navigateur Chromium, moteur axe-core (règles WCAG 2.2 A et AA), observation des cookies et requêtes avant tout choix du visiteur, lecture des en-têtes du serveur
Ce qui n'est pas couvert
Pages derrière une connexion, application Android elle-même, tests manuels au clavier et au lecteur d'écran (inclus dans le pré-diagnostic approfondi)

2Plan d'action priorisé

Plan d'action : points classés par priorité, avec effort estimé et personne concernée
N°PointDomainePrioritéEffortQui
1Texte du pied de page trop pâle pour être luAccessibilitéPriorité 15 minDéveloppeur du site
2Vidéo de démonstration sans sous-titresAccessibilitéPriorité 21 hDéveloppeur du site
3Politique de sécurité qui autorise les scripts en ligneSécurité visiblePriorité 21 hDéveloppeur du site
4Libellé ARIA ignoré sur la liste des navigateursAccessibilitéPriorité 310 minDéveloppeur du site
5Textes sur dégradé ou sur image : contraste à vérifier à la mainAccessibilitéPriorité 345 minDéveloppeur ou graphiste
6Certificat HTTPS à renouveler sous 29 joursSécurité visiblePriorité 35 minHébergeur

Effort total estimé : environ 3 heures de travail pour un développeur web. La seule erreur bloquante se corrige en 5 minutes.

3Détail des points et corrections

1 Texte du pied de page trop pâle pour être luAccessibilité · / (accueil) · 1 élément Priorité 1

RéférenceWCAG 2.2, critère 1.4.3 Contraste minimum (niveau AA) · RGAA 3.2

Effort estimé5 min

À confier àDéveloppeur du site

Ce qui a été constaté

La ligne de copyright du pied de page est bleu-gris foncé (#2a4560) sur fond presque noir (#060b18), en 12 pixels : rapport de contraste mesuré 1,98 pour 1, pour un minimum exigé de 4,5 pour 1.

Élément relevé : <div class="footer-copy">© 2026 Guardian Wall © Développeur : Riadh BEN KHALED .Tous droits réservés.</div>

Pourquoi c'est important

Ce texte est quasiment invisible pour une personne malvoyante, et difficile à lire pour tout le monde sur un écran de téléphone en extérieur. C'est la seule erreur bloquante relevée sur les pages analysées.

Comment corriger
  1. Éclaircir la couleur du texte jusqu'à au moins 4,5 pour 1 sur le fond #060b18.
  2. Profiter de la correction pour rectifier la ponctuation (« BEN KHALED. Tous droits réservés. »).
  3. Vérifier les autres petits textes gris du pied de page avec la même couleur.

Avant

.footer-copy {
  color: #2a4560;   /* 1,98 : 1 */
  font-size: 12px;
}

Après

.footer-copy {
  color: #7a90a8;   /* 5,97 : 1 */
  font-size: 12px;
}
Comment vérifier

Relancer l'analyse : la règle « color-contrast » ne relève plus d'élément sur l'accueil.

Corrigé le 12 novembre 2026, le jour même. Nouvelle analyse : accessibilité 100/100, plus aucune erreur bloquante.

2 Vidéo de démonstration sans sous-titresAccessibilité · /extension/ · 1 vidéo Priorité 2

RéférenceWCAG 2.2, critère 1.2.2 Sous-titres, contenu préenregistré (niveau A) · RGAA 4.3

Effort estimé1 h

À confier àDéveloppeur du site

Ce qui a été constaté

La vidéo de démonstration de l'extension n'a aucune piste de sous-titres (élément track). L'outil ne peut pas savoir si elle contient de la parole : c'est à confirmer à l'écoute.

Élément relevé : <video controls preload="none" poster="assets/demo-poster.webp"> <source src="assets/demo.mp4"> </video>

Pourquoi c'est important

Si la vidéo est commentée, une personne sourde ou malentendante, ou quiconque regarde sans le son (transports, bureau), perd l'explication. Un lien de téléchargement est bien proposé, ce qui est une bonne pratique.

Comment corriger
  1. Écouter la vidéo : si elle ne contient ni parole ni son utile, l'indiquer en légende et la règle est satisfaite.
  2. Sinon, rédiger les sous-titres au format WebVTT (demo.vtt), en français.
  3. Ajouter la piste à la balise video, et une transcription texte sous la vidéo pour le référencement.

Avant

<video controls preload="none" poster="assets/demo-poster.webp">
  <source src="assets/demo.mp4" type="video/mp4">
</video>

Après

<video controls preload="none" poster="assets/demo-poster.webp">
  <source src="assets/demo.mp4" type="video/mp4">
  <track kind="captions" src="assets/demo.vtt"
         srclang="fr" label="Français" default>
</video>
Comment vérifier

Le lecteur affiche le bouton de sous-titres ; la règle « video-caption » ne demande plus de vérification.

3 Politique de sécurité qui autorise les scripts en ligneSécurité visible · Toutes les pages · 1 directive Priorité 2

RéférenceEn-tête Content-Security-Policy, directive script-src · recommandations de l'ANSSI pour la sécurisation des sites web

Effort estimé1 h

À confier àDéveloppeur du site

Ce qui a été constaté

Le site envoie bien une politique de sécurité du contenu, solide sur la plupart des points (object-src 'none', frame-ancestors 'none', upgrade-insecure-requests). Mais script-src contient 'unsafe-inline' : n'importe quel script écrit directement dans la page est autorisé.

Élément relevé : Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; …

Pourquoi c'est important

C'est précisément la protection qu'une CSP doit apporter contre l'injection de script (XSS). Avec 'unsafe-inline', elle est neutralisée pour les scripts. Deux scripts en ligne sont en cause : l'animation de particules de l'accueil et le menu mobile de /extension/.

Comment corriger
  1. Déplacer le code de l'animation de particules et celui du menu mobile dans un fichier externe, par exemple /js/site.js.
  2. Charger ce fichier avec une balise script src, en defer.
  3. Retirer 'unsafe-inline' de script-src. Les blocs de données structurées (type application/ld+json) ne sont pas concernés.
  4. Tester d'abord avec l'en-tête Content-Security-Policy-Report-Only, puis activer.

Avant

script-src 'self' 'unsafe-inline';

<script>
  /* Particles canvas */
  (function () { … })();
</script>

Après

script-src 'self';

<script src="/js/site.js" defer></script>
Comment vérifier

L'animation et le menu fonctionnent ; la console du navigateur n'affiche aucune violation de CSP ; l'analyse ne relève plus la directive.

4 Libellé ARIA ignoré sur la liste des navigateursAccessibilité · /extension/ · 1 élément Priorité 3

RéférenceWCAG 2.2, critère 4.1.2 Nom, rôle et valeur (niveau A)

Effort estimé10 min

À confier àDéveloppeur du site

Ce qui a été constaté

La liste des navigateurs compatibles porte un attribut aria-label sur un simple div, sans rôle. Les lecteurs d'écran ignorent souvent ce libellé.

Élément relevé : <div class="chips" aria-label="Navigateurs compatibles"><span class="chip">Chrome</span> …</div>

Pourquoi c'est important

L'intention est bonne, mais l'information « Navigateurs compatibles » risque de ne jamais être annoncée : la personne entend une suite de mots isolés.

Comment corriger
  1. Transformer le bloc en vraie liste (ul, li), ou lui donner role="list" et role="listitem" à chaque élément.
  2. Garder aria-label sur la liste : il est alors correctement annoncé.

Avant

<div class="chips" aria-label="Navigateurs compatibles">
  <span class="chip">Chrome</span> …
</div>

Après

<ul class="chips" aria-label="Navigateurs compatibles">
  <li class="chip">Chrome</li> …
</ul>
Comment vérifier

NVDA annonce « Navigateurs compatibles, liste, 6 éléments ».

5 Textes sur dégradé ou sur image : contraste à vérifier à la mainAccessibilité · / · /extension/ · 142 éléments Priorité 3

RéférenceWCAG 2.2, critère 1.4.3 Contraste minimum (niveau AA)

Effort estimé45 min

À confier àDéveloppeur ou graphiste

Ce qui a été constaté

142 textes sont posés sur un fond en dégradé, sur une image ou sur l'animation de particules : le moteur ne peut pas calculer leur contraste automatiquement. Ce n'est pas une erreur, c'est une vérification à faire à la main.

Élément relevé : h1 > .grad · .nav-cta · .btn-primary · .nav-logo-text

Pourquoi c'est important

Les titres en dégradé et les boutons sont les éléments les plus visibles du site. Si une zone du dégradé est trop proche du fond, une partie du titre devient illisible pour certains visiteurs.

Comment corriger
  1. Mesurer avec un outil de contraste (Colour Contrast Analyser) la zone la plus claire et la plus foncée de chaque dégradé.
  2. Si une zone passe sous 3 pour 1 pour les grands titres, ou 4,5 pour 1 pour les boutons, foncer ou éclaircir le point du dégradé concerné.
  3. Ajouter une ombre de texte légère sur les titres posés sur l'animation.

Avant

.grad {
  background: linear-gradient(90deg, #00e5c7, #22d3ee);
  -webkit-background-clip: text;
}

Après

/* même dégradé, contraste vérifié sur chaque extrémité */
.grad {
  background: linear-gradient(90deg, #00e5c7, #22d3ee);
  -webkit-background-clip: text;
  text-shadow: 0 1px 2px rgba(0,0,0,.35);
}
Comment vérifier

Chaque extrémité de dégradé mesurée au-dessus du seuil ; captures conservées dans le dossier du client.

6 Certificat HTTPS à renouveler sous 29 joursSécurité visible · Tout le site · 1 certificat Priorité 3

RéférenceBonne pratique d'exploitation : surveillance de l'échéance des certificats

Effort estimé5 min

À confier àHébergeur

Ce qui a été constaté

Le certificat est valide et le protocole négocié est TLS 1.3, ce qui est excellent. Il expire dans 29 jours.

Élément relevé : Certificat TLS de guardianwall.fr, protocole TLS 1.3

Pourquoi c'est important

Sans renouvellement, les navigateurs afficheront une alerte de sécurité à tous les visiteurs. Chez la plupart des hébergeurs, ce renouvellement est automatique : il suffit de le confirmer.

Comment corriger
  1. Vérifier dans l'interface de l'hébergeur que le renouvellement automatique est actif pour guardianwall.fr et www.guardianwall.fr.

Avant

Expire dans 29 jours · renouvellement automatique : à confirmer

Après

Expire dans 29 jours · renouvellement automatique : actif
Comment vérifier

La date d'expiration avance après le renouvellement ; aucune alerte dans le navigateur.

4Contrôles conformes

Ce qui fonctionne déjà bien : à conserver lors des prochaines modifications du site.

  • Redirection automatique vers HTTPS
  • Protocole TLS 1.3
  • En-tête HSTS (max-age 1 an, sous-domaines inclus)
  • En-tête X-Content-Type-Options : nosniff
  • En-tête X-Frame-Options : DENY
  • En-tête Referrer-Policy
  • En-tête Permissions-Policy
  • Aucune version logicielle exposée
  • Aucune version de CMS exposée
  • Aucun contenu mixte
  • Aucun cookie déposé à l'arrivée
  • Aucun traceur connu avant consentement
  • Contact sécurité publié (security.txt)
  • Langue de la page déclarée
  • Lien vers les mentions légales
  • Politique de confidentialité présente
  • Mention d'accessibilité présente

Tous les contrôles automatiques conformes de l'analyse. Le site part d'une très bonne base : c'est aussi ce que montre un rapport.

5Après les corrections

Analyse initiale · 12/11/2026

96/100

Accessibilité 94 · 1 erreur bloquante

Après correction du point 1 · le jour même

98/100

Accessibilité 100 · 0 erreur bloquante

Une fois les priorités 1 et 2 traitées, une nouvelle analyse des mêmes pages permet de comparer l'avant et l'après, point par point. Le rapport complet ne remplace pas un audit RGAA et ne vaut pas certification : il donne à votre prestataire une liste de travail claire, vérifiable et classée.

Rapport complet détaillé : Tarif sur demande. Format HTML ou PDF, envoyé par e-mail.

Demander mon rapport

01

Ce que vous recevez réellement

Votre rapport porte sur votre site et sur ce que l'analyse a réellement mesuré. Rien n'est inventé ni ajouté pour faire peur.

02

Où il est publié

L'échantillon est une page privée, à une adresse impossible à deviner, non référencée et retirée après 60 jours. Le rapport complet vous est envoyé par e-mail.

03

À qui le transmettre

À la personne qui gère votre site : chaque point indique la page, l'élément, la correction et la façon de la vérifier.

Pré-diagnostic gratuit