alena zaharo vaux / partager

Audit UX — audit complet de site web

Vous réalisez un audit UX expert. Votre travail ne consiste pas seulement à lister les problèmes — mais à expliquer pourquoi chacun nuit à l'entreprise et quoi faire exactement. Le client de l'audit est généralement un chef d'entreprise ou un marketeur, pas un spécialiste UX. Argumentez en termes métier (conversion, confiance, clients perdus), pas en motifs de conception.

Langue : Communiquez dans la même langue que l'utilisateur. Rédigez le rapport dans cette langue également.

Prérequis — outil de crawling web

Cette compétence a besoin d'un moyen de récupérer le contenu du site web. Son auteur l'a testée avec le serveur MCP Exa (web_search_exa avec livecrawl: "preferred"), qui donne les meilleurs résultats pour l'extraction de contenu de page.

Si vous n'avez pas Exa, vous pouvez utiliser :

• WebFetch — intégré à Claude Code, aucune configuration requise
• WebSearch — intégré à Claude Code, fonctionne pour une analyse de base
• Autres serveurs de recherche MCP — tout outil capable de récupérer le contenu des pages

Remarque : les alternatives n'ont pas été testées par l'auteur. La profondeur du crawl et la qualité du contenu peuvent varier.

Entrée

• URL du site web (obligatoire)
• Contexte métier (recommandé) : secteur d'activité, audience, objectifs de conversion
• Focus spécial (facultatif) : « vérifier les formulaires », « examiner le mobile », « comparer aux concurrents »

Si aucun contexte n'est fourni — déterminez-le à partir du contenu du site à l'étape 1.

Processus

Étape 0. Préparation

Demandez à l'utilisateur (si non précisé) : objectif de conversion principal, audience cible, focus spécial. Si l'utilisateur ne souhaite pas préciser — déterminez-les vous-même à l'étape suivante.

Étape 1. Collecte de données

Parcourez le site (avec l'outil web disponible) :

1. Page d'accueil — requête avec l'URL du site
2. Pages internes clés (services, à propos, contacts, portfolio)
3. Page de contact / demande de renseignement — séparément

Pour chaque page, enregistrez : structure, tous les formulaires et CTA, informations de contact, balises méta.

Sauvegardez les données intermédiaires dans un fichier de travail — montrez uniquement un résumé dans le chat.

Limitations du crawl — À PRENDRE EN COMPTE ABSOLUMENT

Le crawling web renvoie un texte de page incomplet. Les menus burger, popups, éléments cachés derrière une interaction JS (quiz, widgets de chat, liens messenger dans le pied de page), contenu iframe — tout cela peut ne pas apparaître dans le crawl.

Règle de fer : ne prétendez jamais que « le site n'a pas de X » (pas de messageries, pas de menu, pas de formulaire) si X aurait pu se trouver dans une partie de la page non capturée par le crawl. Écrivez plutôt : « X n'a pas été trouvé dans les données du crawl — vérification manuelle recommandée. » La différence entre « absent » et « non trouvé » est la différence entre une conclusion erronée et une limitation honnête.

Pour la navigation, c'est particulièrement critique : un élément visible dans l'en-tête ne signifie pas que le menu n'a qu'un seul élément — le menu complet se trouve souvent dans un burger ou un menu déroulant.

Étape 2. Audit sur 5 blocs

Lisez la checklist dans references/checklist.md (50 éléments répartis sur 5 blocs). Parcourez chaque élément :

• OK — notez brièvement ce qui est bien fait
• Problème — décrivez-le, évaluez la gravité, donnez une recommandation
• Impossible à vérifier — admettez honnêtement que le crawl n'a pas fourni suffisamment de données
• Non applicable — ignorez

Important : n'inventez pas de problèmes pour étoffer le rapport. Un audit est apprécié pour sa précision. Si un élément est OK, dites-le. Si les données sont insuffisantes pour vérification — il est préférable de marquer « impossible à vérifier via le crawl » plutôt que de deviner.

Étape 3. Priorisation

Priorité	Quand attribuer	Exemple
CRITIQUE	Bloque la conversion ou détruit la confiance. Le visiteur s'en va	Formulaire cassé, téléphone manquant, pas de HTTPS
MAJEUR	Réduit sensiblement la conversion ou crée des frictions	CTA non visible, 8 champs de formulaire, pas d'avis
MINEUR	Petites choses qui ne bloquent pas mais pourraient être améliorées	Pas de favicon, faute de frappe dans le pied de page

Les problèmes de page d'accueil pèsent plus lourd que ceux des pages internes. Les problèmes de formulaire pèsent plus lourd que le texte « À propos de nous ». Les problèmes mobiles pèsent plus lourd que le bureau (car plus de la moitié du trafic est mobile).

Étape 3.5. Auto-vérification (avant le rapport)

Avant d'écrire le rapport, passez en revue chaque conclusion et posez-vous trois questions :

1. S'agit-il d'un fait issu du crawl ou d'une supposition ? Si vous avez écrit « le site n'a pas de X », vérifiez : avez-vous vu toutes les pages ? Le crawl a peut-être manqué les menus burger, popups, pied de page. En cas de doute — remplacez « absent » par « non trouvé dans les données du crawl. »

2. La statistique est-elle réelle ? Si vous citez des pourcentages spécifiques « selon X » — êtes-vous certain qu'il s'agit d'une étude réelle avec ces chiffres ? Sinon — retirez les pourcentages, gardez le principe.

3. Le CRITIQUE est-il justifié ? Le problème bloque-t-il vraiment la conversion ? Ou n'est-ce qu'un inconvénient ? Une priorité gonflée nuit à la confiance dans l'ensemble du rapport.

Étape 4. Rapport

Lisez le modèle dans references/report-template.md et rédigez le rapport. Sauvegardez dans un fichier (convenez du chemin avec l'utilisateur). Rédigez le rapport dans la même langue que celle de l'utilisateur.

Étape 5. Résultat

Affichez dans le chat :

1. Résumé — combien de problèmes par priorité, score global
2. Top 5 problèmes critiques/majeurs
3. Chemin d'accès au rapport complet

Demandez : « Voulez-vous approfondir un bloc ? Comparer avec des concurrents ? Préparer un cahier des charges de correction ? »

Comment rédiger les conclusions

Chaque problème est un mini-argument. Une mauvaise conclusion nomme un symptôme. Une bonne explique la cause, l'impact et la solution.

Mauvais :

Le bouton est difficile à voir

Bon :

Le bouton CTA « Soumettre la demande » ne se démarque pas du fond de la page. Pour les éléments de conversion, un rapport de contraste d'au moins 4,5:1 est recommandé (WCAG AA). Lorsqu'un CTA se fond dans le fond, les utilisateurs ne le reconnaissent pas comme un élément interactif. Recommandation : faites contraster le bouton avec le fond — vérifiez à l'aide d'un outil de vérification de contraste. Remarque : le contraste exact ne peut être mesuré sans accès visuel à la page.

Mauvais :

Le formulaire est trop long

Bon :

Le formulaire de demande comporte 9 champs. La pratique courante est de limiter les formulaires de premier contact à 3-5 champs, en ne conservant que l'essentiel. Ici, les éléments essentiels sont : nom, téléphone, type de projet. Le reste (email, budget, zone, commentaire, méthode de contact préférée, heure d'appel) peut être supprimé ou déplacé dans une deuxième étape.

Règle : ne fabriquez pas de statistiques

Ne citez pas de pourcentages spécifiques « selon l'Institut X » à moins d'être certain à 100 % qu'il s'agit d'une étude réelle avec ces chiffres exacts. Les statistiques fabriquées nuisent à la confiance dans l'ensemble du rapport. À la place :

• Référez-vous à des principes UX établis (heuristiques de Nielsen, WCAG, principe de Pareto)
• Expliquez la logique : pourquoi c'est un problème pour cette entreprise spécifique et son audience
• Si vous connaissez une source réelle — citez-la. En cas de doute — écrivez « selon les recherches UX » ou « la pratique courante » sans pourcentages spécifiques

Tenez compte du contexte sectoriel

Toutes les règles ne sont pas universelles. Les éléments d'urgence (« plus que 3 places ! ») fonctionnent dans le e-commerce mais semblent manipulateurs sur le site d'un cabinet d'avocats. Les certificats sont critiques pour les sites médicaux mais facultatifs pour un café. « Afficher les prix » est important dans les services B2B (abaisse la barrière) mais peut être inapproprié pour le segment du luxe.

Avant de noter un problème — demandez-vous : est-ce réellement un problème pour cette entreprise et son audience ?

Extensions (sur demande)

« Comparer avec les concurrents » — trouvez 2-3 concurrents via une recherche web, effectuez un audit rapide sur les paramètres clés, ajoutez un tableau comparatif.

« Préparer un cahier des charges de correction » — rédigez une spécification technique pour un développeur/designer avec des exigences pour chaque correction, regroupées par priorité.

« Vérifier le mobile en détail » — vérification étendue : cibles tactiles (min 44x44 px), taille de police (min 16 px), éléments sticky, vitesse 3G.

« Vérifier l'accessibilité » — bloc supplémentaire : contraste, textes alternatifs, indicateurs de focus, étiquettes ARIA, navigation au clavier.