vérificateur-lancement-site-web

Vérificateur de lancement de site web

Objectif

Vérifier un site web avant sa mise en ligne, pour éviter que rien d'embarrassant ne soit publié. Le vérificateur ne reconçoit pas le site. Il vérifie la préparation, signale ce qui manque et dit exactement quoi corriger.

Il est conçu pour les sites web de petites entreprises : une entreprise, quelques pages, un formulaire de contact ou de prospects, et des visiteurs qui lisent peut-être l'anglais comme langue seconde.

Comment l'utiliser

1. Demandez à l'utilisateur l'un des éléments suivants :
   • Une URL en direct
   • Un dossier de fichiers du site web
   • Un lien de démonstration ou de staging
2. Si l'utilisateur donne uniquement une URL, dites clairement ce qui ne peut pas être vérifié depuis l'extérieur. Ne devinez pas ces éléments. Marquez-les « Nécessite confirmation du client » au lieu de « Réussi ».
3. Vérifiez chaque élément de la liste de contrôle ci-dessous, dans l'ordre.
4. Pour chaque élément, notez la preuve : la page, le fichier, la ligne, la balise ou la capture d'écran où vous l'avez vu. Pas de preuve signifie pas de « Réussi ».
5. Terminez par le format de rapport à la fin de ce fichier.

La liste de contrôle de lancement en 15 points

Vérifiez les 15 points. N'en sautez aucun sous prétexte qu'il semble insignifiant.

1. Page 404 personnalisée

• Un visiteur qui saisit une mauvaise adresse voit une page 404 de marque, pas une page par défaut du serveur ou une page vierge.
• La page 404 renvoie vers la page d'accueil et la page de contact.
• Échec s'il n'y a pas de page 404, ou si c'est celle par défaut.

2. Titres de page uniques

• Chaque page a sa propre balise <title>.
• Aucune deux pages ne partagent le même titre.
• Aucun titre n'est vide, et aucun titre n'est simplement le nom de l'entreprise sur chaque page.
• Les titres décrivent cette page en termes simples.

3. Méta-descriptions

• Chaque page principale a une méta-description.
• Chaque description est unique à cette page.
• Chaque description est un résumé court et simple de ce qui se trouve sur cette page, sans bourrage de mots-clés.
• Échec si une page principale n'a pas de description.

4. Images de prévisualisation sociale

• Lorsque le lien du site est partagé sur WhatsApp, Facebook ou d'autres applications, il affiche une image de prévisualisation, un titre et une description appropriés.
• Vérifiez les balises Open Graph (og:title, og:description, og:image) et assurez-vous que le fichier image existe réellement.
• Échec si l'image de prévisualisation est manquante, cassée ou un espace réservé.

5. Texte alternatif des images

• Chaque image significative a un texte alternatif qui décrit l'image en termes simples.
• Les images décoratives peuvent avoir un texte alternatif vide, mais dites-le.
• Échec si les images principales, les photos de produits ou les photos d'équipe n'ont pas de texte alternatif.

6. Liens internes

• Les pages se lient entre elles de manière logique : Accueil, Services, À propos, Contact, et toutes les pages de services clés.
• Cliquez ou vérifiez chaque lien interne. Aucun lien ne mène à une page manquante, une 404 ou un espace réservé comme #.
• Échec pour tout lien interne cassé.

7. Sitemap et Google Search Console

• Un sitemap.xml existe et répertorie les pages réelles.
• Le site a été soumis à Google Search Console, ou le propriétaire a été informé que cette étape est encore nécessaire.
• À partir d'une seule URL, vous ne pouvez pas prouver la soumission à Search Console. Dans ce cas, marquez-le « Nécessite confirmation du client » et listez-le comme une étape pour le propriétaire. Ne le marquez pas « Réussi » sur une supposition.

8. robots.txt

• Un fichier robots.txt existe à la racine du site.
• Il autorise les pages qui doivent être trouvées et ne bloque pas accidentellement l'ensemble du site.
• Échec s'il est manquant ou s'il bloque tout.

9. HTTPS partout

• Chaque page se charge en HTTPS, pas en HTTP.
• Aucun avertissement de contenu mixte : les images, les scripts et les formulaires doivent également se charger en HTTPS.
• Échec pour toute page HTTP ou contenu mixte.

10. Protection anti-spam sur les formulaires

• Chaque formulaire dispose d'une protection anti-spam, par exemple un captcha, un honeypot ou un service de formulaire avec filtrage anti-spam.
• Échec si un formulaire de contact ou de prospects n'a aucune protection.
• Si le site n'a aucun formulaire, marquez-le « Non applicable pour l'instant » et ajoutez-le à la liste des correctifs comme : « Nécessaire lorsqu'un vrai formulaire sera ajouté. » Ne le marquez pas « Échec » pour un formulaire qui n'existe pas.
• Ne soumettez pas un vrai formulaire pour tester cela à moins que l'utilisateur ne vous y autorise. Vérifiez le code ou les paramètres du formulaire à la place.

11. Page de remerciement après soumission

• Après qu'un visiteur a soumis un formulaire, il voit une page de remerciement ou un message de remerciement clair.
• La page de remerciement confirme ce qui se passe ensuite, par exemple « Nous répondrons sur WhatsApp sous un jour ouvrable. »
• Échec si le formulaire se recharge simplement, s'efface ou n'affiche aucune confirmation.
• Si le site n'a aucun formulaire, marquez-le « Non applicable pour l'instant » et ajoutez-le à la liste des correctifs comme : « Nécessaire lorsqu'un vrai formulaire sera ajouté. » Ne le marquez pas « Échec » pour un formulaire qui n'existe pas.

12. Google Analytics

• Google Analytics, ou un outil d'analyse équivalent choisi par le propriétaire, est installé sur chaque page.
• À partir d'une seule URL, vous ne pouvez pas prouver que le propriétaire peut voir les données. Si vous ne pouvez pas vérifier l'accès, marquez-le « Nécessite confirmation du client » et listez-le comme une étape pour le propriétaire.
• Analytics nécessite le compte Google du client. Dites-le clairement. Ne prétendez pas que c'est fait sans ce compte.

13. Politique de confidentialité, avec mention des cookies

• Le site a une page de politique de confidentialité.
• La politique est réelle : elle nomme les données que le site collecte réellement, par exemple les détails des formulaires, et comment elles sont utilisées.
• Elle inclut une mention des cookies si des cookies ou des analyses sont utilisés.
• Échec si la politique est un modèle générique qui ne correspond pas à ce site, ou si c'est un texte copié avec un autre nom d'entreprise.

14. FAQ

• Le site a une section ou une page FAQ.
• Les questions sont celles que les vrais clients posent réellement : fourchette de prix, emplacement, horaires, comment réserver, quoi apporter.
• Échec s'il n'y a pas de FAQ, ou si les réponses sont vagues et sans informations réelles.

15. Uniquement des témoignages réels

• Chaque témoignage sur le site est réel.
• Pas de noms d'espace réservé, pas d'avis inventés, pas de « John Doe », pas de citations génériques présentées comme des clients.
• Si un témoignage ne peut pas être vérifié, marquez-le « Échec » et dites : supprimez-le ou remplacez-le par un vrai avec autorisation.
• Si le site n'a aucun témoignage, marquez-le « Manquant » et dites : aucun trouvé, et aucun faux nom trouvé non plus. N'appelez pas cela « Faux ». Une section de témoignages manquante est une lacune à combler, pas un faux témoignage.
• Un site avec de faux témoignages est un échec critique. Il n'est pas prêt, même si tout le reste réussit.

Vérifications de conception supplémentaires

Celles-ci ne font pas partie des 15 points ci-dessus, mais signalez-les séparément comme « Notes de conception ». Ne les mélangez pas dans le score des 15 points.

• Pas de contenu IA générique : pas de dégradés violets, pas de titre centré plus trois cartes identiques comme conception entière, pas de mise en page générique répétée dans chaque section.
• Mise en page premium, soignée et habitable : hiérarchie claire, typographie lisible, vraies photos ou vrais détails de projet si possible.
• Les nombres sont cohérents sur tout le site : un format, un système de taille. Ne mélangez pas « AED 500 », « 500 AED » et « 500 » pour le même type de prix.
• Les détails de projet, s'ils sont utilisés, sont présentés comme des statistiques, pas comme des affirmations vagues.
• Les informations clés sont faciles à comprendre pour un lecteur faible en anglais : phrases courtes et simples, titres clairs, et coordonnées faciles à trouver.

Règles strictes

• Ne marquez jamais « Réussi » sans preuve.
• N'inventez jamais de témoignage, de statistique, de nombre de clients ou d'avis.
• Ne dites jamais que Search Console ou Analytics est fait sans l'étape du compte Google du client.
• Ne dites jamais qu'un site est prêt si un formulaire n'a pas de protection anti-spam, pas de confirmation de remerciement, ou a de faux témoignages. Ce sont des bloqueurs. Un site sans formulaire du tout est différent : utilisez « Non applicable pour l'instant » pour les vérifications 10 et 11, pas « Échec ».
• N'utilisez jamais un espace réservé pour combler une lacune. Signalez la lacune.
• Rédigez le rapport en phrases courtes et simples. Le propriétaire n'est peut-être pas un lecteur technique.

Format du rapport

Terminez toujours avec ce format, dans cet ordre :

Rapport de lancement : [nom du site ou URL]

Verdict : Prêt / Pas prêt / Pas prêt - bloqueurs trouvés

Utilisez « Prêt » uniquement s'il n'y a aucun « Échec », ou si les seuls éléments ouverts sont des étapes propriétaires que le client a confirmé qu'il effectuera le jour du lancement. « Non applicable pour l'instant » et « Manquant » ne bloquent pas à eux seuls un verdict « Prêt », mais listez-les comme lacunes. Sinon, utilisez « Pas prêt ».

Résultats

#	Vérification	Résultat	Preuve
1	Page 404 personnalisée	Réussi / Échec / Nécessite confirmation du client / Non applicable pour l'instant / Manquant	page ou fichier
2	Titres de page uniques	...	...
3	Méta-descriptions	...	...
4	Images de prévisualisation sociale	...	...
5	Texte alternatif des images	...	...
6	Liens internes	...	...
7	Sitemap et Search Console	...	...
8	robots.txt	...	...
9	HTTPS partout	...	...
10	Protection anti-spam sur les formulaires	...	...
11	Page de remerciement après soumission	...	...
12	Google Analytics	...	...
13	Politique de confidentialité avec mention des cookies	...	...
14	FAQ	...	...
15	Uniquement des témoignages réels	...	...

Correctifs, par ordre de priorité

1. Bloqueur en premier : [quoi corriger, sur quelle page, en termes simples]
2. Correctif suivant : ...
3. ...

Étapes propriétaires - nécessite le client

• [Par exemple : donner l'accès au compte Google pour Search Console]
• [Par exemple : confirmer que les témoignages sont réels et donner la permission de les afficher]
• [Par exemple : rédiger le texte réel de la politique de confidentialité]

Notes de conception

• [Toute note de la section Vérifications de conception supplémentaires, ou « Aucune ».]

Ce qui n'a pas été vérifié, et pourquoi

• [Par exemple : La soumission à Search Console n'a pas pu être vérifiée à partir d'une seule URL.]