EshaRana17/website-review

Révision de site web

Un outil pratique pour réviser les sites web et les pages d'atterrissage des petites entreprises. Il produit des conclusions fondées sur des preuves, des scores et des corrections priorisées qu'un propriétaire non spécialiste peut mettre en œuvre dès cette semaine.

Choisir le workflow

Lisez la demande et choisissez un ou plusieurs workflows. Si l'utilisateur dit simplement "révise mon site", exécutez le Workflow 1 et proposez les workflows 3 et 4 en suivi.

L'utilisateur demande	Workflow	Charger la référence
"Pourquoi cela ne convertit-il pas ?", révision, CRO, retour sur la page d'accueil	1. Examen de la conversion	references/conversion.md
Réécrire le titre, le texte, le CTA, les puces	2. Réécriture du contenu	references/copywriting.md
Accessibilité, a11y, WCAG, lecteurs d'écran, contraste	3. Vérification de l'accessibilité	references/accessibility.md
Site lent, vitesse de page, Lighthouse, Core Web Vitals, en-têtes	4. Performance et technique	references/performance.md
Nouveau site, plan de site, "de quelles pages ai-je besoin"	5. Planification de site	references/site-plan.md

Chargez uniquement le(s) fichier(s) de référence nécessaire(s) pour le workflow choisi.

Entrées et ce qu'elles permettent

Travaillez avec ce que l'utilisateur fournit et dites clairement ce qui n'a pas pu être vérifié.

• URL : si un outil de récupération ou de navigation est disponible, lisez la page. Sinon, demandez une capture d'écran, du texte copié ou un HTML sauvegardé. Ne faites jamais semblant d'avoir visité une page.
• Capture d'écran : bonne pour la hiérarchie, le contenu au-dessus de la ligne de flottaison, le contraste visuel (estimation uniquement), le placement des CTA. Ne peut pas vérifier le texte alternatif, les étiquettes, les en-têtes ou la vitesse.
• Texte copié : bon pour le message et le contenu. Ne peut pas juger la mise en page ou les visuels.
• Fichier HTML : bon pour la structure et le balisage d'accessibilité. Exécutez scripts/page_audit.py dessus (voir ci-dessous). Ne peut pas mesurer la vitesse réelle.
• Rapport Lighthouse ou PageSpeed (copié ou exporté) : utilisez-le comme source de vérité pour les métriques de performance.

Avant de commencer, collectez (ou déduisez et énoncez les hypothèses) : pour qui est la page, quelle est l'action principale unique attendue, et la source de trafic (publicité, recherche, réseaux sociaux, référencement). Si manquant, posez une courte question ou énoncez l'hypothèse et continuez.

Règles de base

1. D'abord les preuves. Chaque conclusion cite ce qui a été observé (citez le texte, nommez l'élément, donnez la valeur mesurée). Pas de conseil générique sans lien avec la page réelle.
2. Pas de faits inventés. Ne fabriquez jamais de témoignages, d'avis, de nombres de clients, de statistiques, de récompenses, de logos ou de garanties. Là où la preuve manque, utilisez un espace réservé clairement marqué comme [citation client réelle ici] et dites quoi collecter.
3. Gardez la voix de la marque. Les réécritures correspondent au ton, au niveau de lecture et au vocabulaire existants, sauf si l'utilisateur demande une nouvelle voix.
4. Priorisez par impact et effort. Les propriétaires ont un temps limité. Classez les corrections, ne déversez pas de listes de contrôle.
5. Séparez mesuré d'estimé. Marquez les rapports de contraste devinés à partir d'une capture d'écran ou les problèmes de vitesse déduits du balisage comme des estimations.
6. Normes énoncées précisément. Utilisez les faits dans les fichiers de référence (WCAG 2.2, seuils Core Web Vitals). Si l'utilisateur cite une norme plus récente, référez-vous-y et dites sur quelle version les conseils sont basés.
7. Langage simple. Expliquez le jargon en quelques mots lors de sa première apparition.

Workflow 1 : Examen de la conversion de page d'atterrissage

Détails, grille de notation et vérifications : references/conversion.md.

Étapes :

1. Test des 5 secondes. À partir du seul premier écran (au-dessus de la ligne de flottaison sur mobile et desktop si les deux sont disponibles), répondez : Qu'est-ce que c'est ? Pour qui est-ce ? Pourquoi devrais-je m'en soucier (résultat ou différenciateur) ? Que faire ensuite ? Marquez chaque Réussi / Partiel / Échoué et citez le texte qui y répond.
2. Notez les huit dimensions (0 à 5 chacune) en utilisant la grille dans la référence : clarté de la proposition de valeur, hiérarchie visuelle, force et placement du CTA, preuve sociale, gestion des objections, friction de formulaire et de paiement, adéquation du message avec la source de trafic, signaux de confiance et de crédibilité.
3. Listez les problèmes avec preuve, impact (Élevé / Moyen / Faible) et effort (Rapide / Modéré / Lourd).
4. Classez les 10 meilleures corrections par impact d'abord, puis par effort (victoires rapides plus haut).
5. Suggérez des tests pour les 2 ou 3 meilleures corrections si le site a suffisamment de trafic (voir la note sur le trafic dans la référence) ; sinon, recommandez simplement de les mettre en œuvre.

Modèle de sortie :

## Examen de la conversion : [nom de la page]

**Audience supposée :** ... | **Action principale :** ... | **Source de trafic :** ...

### Test des 5 secondes
| Question | Résultat | Preuve |
|---|---|---|
| Qu'est-ce que c'est ? | Réussi/Partiel/Échoué | "titre cité" |
| Pour qui est-ce ? | ... | ... |
| Pourquoi s'en soucier ? | ... | ... |
| Que faire ensuite ? | ... | ... |

### Tableau de bord des scores (total X / 40)
| Dimension | Score (0-5) | Raison en une ligne |
|---|---|---|

### 10 meilleures corrections (classées par impact)
1. **[Correction]** - Impact : Élevé | Effort : Rapide
   Pourquoi : ... Preuve : ... Comment : ...

### Ce qui fonctionne déjà
- ...

### Non vérifié
- ... (et quelle entrée le permettrait)

Workflow 2 : Réécriture du contenu

Détails, formules et méthode d'adaptation de la voix : references/copywriting.md.

Étapes :

1. Capturez la voix. Notez le ton (par exemple chaleureux, direct, technique, ludique), la longueur des phrases, la personne (nous/vous/je), les mots que la marque utilise et évite. Énoncez ce profil de voix en deux ou trois lignes avant de réécrire.
2. Trouvez le message principal. Client, problème, résultat, différenciateur, preuve disponible. Si le différenciateur n'est pas clair, demandez ou proposez deux angles.
3. Rédigez des options de titre (5 est un bon défaut), chacune utilisant un angle différent (résultat, problème, appel à l'audience, différenciateur, spécificité). Donnez une justification d'une ligne pour chacun et recommandez-en un.
4. Rédigez un sous-titre qui ajoute le comment, le qui ou la preuve que le titre a omis.
5. Rédigez des variantes de CTA (3 à 5) : mené par un verbe, spécifique sur ce qui se passe ensuite, avec éventuellement une ligne de réduction de risque en dessous (par exemple "Aucune carte requise"), seulement si c'est vrai pour cette entreprise.
6. Réécrivez les puces de fonctionnalités en avantages : fonctionnalité, puis ce que cela signifie pour le client. Gardez les affirmations que l'utilisateur peut soutenir.
7. Signalez les affirmations qui nécessitent une preuve et listez les preuves à collecter au lieu de les inventer.

Sortie : profil de voix, tableau des titres (option, angle, justification), choix recommandé, sous-titre, liste de CTA, puces avant/après, liste des preuves nécessaires.

N'écrivez jamais de faux témoignages, de nombres d'avis, de notes, de logos de clients, de lignes "comme vu dans" ou de résultats numériques que l'utilisateur n'a pas fournis.

Workflow 3 : Vérification de l'accessibilité (essentiels WCAG 2.2 AA)

Détails, liste de critères et extraits de corrections : references/accessibility.md.

WCAG 2.2 est une recommandation du W3C depuis octobre 2023 (dernière édition datée du 12 décembre 2024). Il a supprimé 4.1.1 Parsing et ajouté neuf critères de succès, dont six au niveau A ou AA. Cette vérification couvre les essentiels que la plupart des petits sites échouent ; ce n'est pas un audit de conformité complet, et dites-le dans la sortie.

Étapes :

1. Si le HTML est disponible, exécutez scripts/page_audit.py et utilisez sa sortie comme preuve.
2. Vérifiez les essentiels dans cet ordre : contraste du texte, contraste non textuel, texte alternatif, titres et points de repère, étiquettes et erreurs de formulaire, accès clavier et focus visible, focus non obscurci, taille des cibles, mouvement et animation, langue et titre de page, noms des liens et des boutons.
3. Pour chaque échec, donnez : numéro et nom du critère, niveau, où il se produit, qui cela affecte, et un extrait de correction copiable.
4. Recommandez une série de tests manuels : navigation uniquement au clavier, zoom à 200 % et redimensionnement à 320 px CSS, et un lecteur d'écran (NVDA, VoiceOver ou TalkBack).

Sortie : résumé (nombre de blocages / sérieux / mineurs), tableau des résultats, extraits de correction, liste de contrôle des tests manuels, liste "non vérifié".

Workflow 4 : Performance et technique de base

Détails, seuils et guide de mesure : references/performance.md.

Les Core Web Vitals sont LCP (chargement), INP (réactivité, a remplacé FID en mars 2024) et CLS (stabilité visuelle). Seuils bons au 75e percentile des chargements de page : LCP 2,5 s ou moins, INP 200 ms ou moins, CLS 0,1 ou moins.

Étapes :

1. Demandez si l'utilisateur a un résultat PageSpeed Insights ou Lighthouse. Les données de terrain (utilisateurs réels, provenant du Chrome UX Report) priment sur les données de laboratoire ; dites lesquelles vous avez.
2. Sans mesures, déduisez les problèmes probables du balisage ou des captures d'écran et étiquetez-les comme des hypothèses à vérifier.
3. Vérifiez : élément LCP et comment il se charge, formats et dimensions des images, chargement des polices, CSS et JS bloquant le rendu, scripts tiers, sources de changement de mise en page, viewport mobile et cibles tactiles, mise en cache et compression, HTTPS et en-têtes de sécurité.
4. Produisez une liste de contrôle priorisée : P1 (corriger maintenant), P2 (ce mois-ci), P3 (agréable à avoir), chacune avec "comment mesurer" nommant l'audit Lighthouse exact ou le champ PageSpeed.

Workflow 5 : Planification de site à partir de zéro

Détails, plans de page et ébauches de contenu : references/site-plan.md.

Étapes :

1. Brief. Collectez le type d'entreprise, la localisation ou la zone de service, le client principal, les 3 meilleurs services ou produits, la conversion principale (appel, réservation, devis, achat, inscription), les preuves disponibles, la voix de la marque, le budget pour le contenu. Demandez les lacunes en une question groupée, ou procédez avec les hypothèses énoncées.
2. Plan de site. Commencez minimal (généralement 5 à 8 pages). Justifiez chaque page par une question client à laquelle elle répond ou une recherche pour laquelle elle peut se positionner.
3. Plan page par page. Pour chaque page : objectif, CTA principal, sections dans l'ordre, ébauche de contenu (direction du titre plus points clés), preuve à placer, liens internes.
4. Liste de contrôle de lancement. Technique, accessibilité, analytique et juridique.
5. Liste de tâches de contenu pour le propriétaire (photos, citations, nombres à collecter).

Sortie : récapitulatif du brief, arborescence du plan de site, plans de page, liste de contrôle de lancement, liste de tâches de contenu.

Script d'aide : page_audit.py

scripts/page_audit.py est un script Python 3 utilisant uniquement la bibliothèque standard. Il lit un fichier HTML local et ne touche jamais au réseau. Utilisez-le chaque fois que l'utilisateur fournit du HTML (page sauvegardée, exportation ou source).

python scripts/page_audit.py chemin/vers/page.html            # rapport lisible
python scripts/page_audit.py chemin/vers/page.html --json     # lisible par machine

Il rapporte : lang manquant, balise viewport, titre et méta-description ; images sans alt ou sans width/height ; champs de formulaire sans étiquette accessible ; problèmes d'ordre des titres (niveaux sautés, h1 manquant ou multiple) ; nombre de scripts externes et leurs hôtes ; boutons et liens ressemblant à des CTA.

Le code de sortie est 0 lorsqu'aucun problème n'est trouvé, 1 lorsque des problèmes sont trouvés, 2 en cas d'erreur d'utilisation ou de fichier. Considérez ses résultats comme des preuves de balisage uniquement : il ne peut pas voir le CSS, le contraste, le contenu rendu par JavaScript ou les performances réelles. Un exemple de fichier pour l'essayer se trouve à assets/sample.html.

Si l'utilisateur ne donne qu'une URL, ne téléchargez pas de pages avec ce script. Demandez-lui de sauvegarder la page ("Enregistrer la page sous" du navigateur, HTML uniquement) ou de coller la source.

Combinaison de workflows

Pour une "révision complète", exécutez 1, puis 3 et 4 sous forme courte (uniquement les principaux résultats), et terminez par une liste de priorités fusionnée unique de 10 éléments maximum afin que le propriétaire ait un seul plan, pas trois.

Liste de contrôle qualité avant de répondre

• Chaque score et conclusion a une preuve provenant de la page.
• Aucune preuve, nombre ou citation inventé.
• Les corrections sont classées et chacune a un impact et un effort.
• Les normes sont citées par numéro et version lorsque pertinent.
• La section "non vérifié" est honnête sur les limites des entrées.
• Les réécritures correspondent au profil de voix énoncé.