Vérifier un site avant sa mise en ligne

Construire des scénarios de visite

Choisissez au moins cinq tâches : trouver un service, comprendre son prix ou ses modalités, consulter une preuve, filtrer une liste, envoyer un message. Testez-les depuis la page d’accueil puis depuis une page interne trouvée directement. Notez pour chaque essai l’appareil, le navigateur, l’URL, l’action, le résultat et la personne responsable du correctif.

Ajoutez les cas moins favorables : champ vide, recherche sans résultat, lien externe indisponible, connexion lente, écran étroit et navigation sans souris. Un parcours réussi sur l’ordinateur du concepteur ne suffit pas à valider l’expérience.

• La tâche peut être terminée sans explication orale.
• Les erreurs indiquent comment reprendre.
• Le retour à la page ou au résultat précédent reste compréhensible.

Relire les contenus et les médias

Contrôlez noms, coordonnées, tarifs, zones couvertes, horaires, dates et promesses. Les images principales doivent être présentes, nettes et adaptées au sujet. Vérifiez les droits d’usage, les légendes utiles, les textes alternatifs et l’absence d’une même photo répétée dans une série de cartes. Les images décoratives peuvent garder un alt vide.

Sur les pages stratégiques, comparez le titre, l’introduction et l’appel à l’action : ils doivent annoncer la même offre. Une page multilingue doit être relue dans chaque langue réellement publiée, y compris menus, formulaires, erreurs et métadonnées.

• Aucune image cassée ni photo principale manquante.
• Chaque langue décrit le même service sans texte oublié.
• Les informations de contact correspondent aux données validées.

Tester l’accessibilité et la performance utile

Parcourez le site au clavier, vérifiez le focus visible, les libellés de formulaire, l’ordre des titres et le zoom. Les contrôles rapides du W3C donnent une première méthode ; ils ne constituent pas un audit complet. Testez les pages et filtres sur téléphone à une largeur réaliste, en portrait et avec un texte agrandi.

Mesurez les pages clés avec des outils de laboratoire et, si le trafic le permet, des données de terrain. Regardez surtout l’image principale, les polices, les scripts et la stabilité de la page. Un score isolé ne remplace pas l’observation d’un parcours qui répond vite et reste utilisable.

• Navigation au clavier et focus visibles.
• Formulaires compréhensibles, y compris après erreur.
• Images dimensionnées et chargement prioritaire de l’image principale.

Contrôler les signaux de découverte

Ouvrez les URL finales et vérifiez leur réponse HTTP, leur canonical, leur titre, leur description et leurs liens internes. Les pages qui doivent être trouvées ne doivent pas rester en noindex ni être bloquées par erreur. Le sitemap doit contenir les URL canoniques utiles ; les anciennes adresses conservant du trafic ou des liens doivent aboutir à leur équivalent. Les exigences techniques de Google Search restent la base de l’indexation.

Pour chaque langue, les liens hreflang doivent pointer vers des versions réellement disponibles et se répondre. Les données structurées doivent décrire ce que la page affiche, sans inventer avis, prix ou implantation. Aucun balisage spécial GEO ou fichier destiné aux LLM n’est requis par Google pour ses fonctionnalités de recherche avec IA.

• URL canonique, sitemap et navigation cohérents.
• Redirections testées, sans boucle ni page sans rapport.
• Alternatives de langue réciproques et contenu traduit.

Prévoir la décision de publication et le suivi

Répartissez les anomalies en bloquantes, importantes et améliorations futures. Un formulaire qui ne transmet pas les demandes, une page principale introuvable ou une mauvaise redirection bloque l’ouverture. Un détail de mise en page peut parfois être traité après publication si son impact est faible et documenté.

Gardez un responsable des premières vérifications en production : parcours de contact, statut des pages, indexation, mesures et retour des visiteurs. Répétez les essais après le déploiement, car l’environnement public peut différer de la préproduction. Le cahier des charges permet de comparer le résultat aux engagements initiaux.

Organiser la décision de mise en ligne

Testez une tâche complète par public prioritaire et attribuez les anomalies. Distinguez un défaut qui bloque une commande ou un contact d’un détail de présentation. Un contrôle automatique réussi ne suffit pas à valider une tâche.

Conservez la version testée, les constats et la procédure de retour. Après publication, contrôlez sur le domaine final la réception des demandes de test, les téléchargements, les canonical, les langues et l’indexation prévue. Préproduction et production peuvent différer.

Décider dans une situation concrète

Exemple fictif : une page de présentation est prête, mais le formulaire reste sans destinataire confirmé. Distinguez défaut cosmétique et rupture de parcours ; une mise en ligne partielle ne doit pas laisser croire qu’une demande peut être traitée.

Préparez une décision de publication avec parcours contrôlé, anomalie restante, responsable et possibilité de reprise. Pour le formulaire, gardez une preuve de réception dans un environnement autorisé ; l’absence d’erreur à l’écran ne suffit pas.

• Définir et suivre la fiabilité des parcours d’un site web

  Distinguer disponibilité, réussite d’une tâche et délais ; définir observations, objectifs, alertes et décisions sans promesse arbitraire.

Qui peut décider de publier ?

Attribuez un responsable à chaque obstacle encore ouvert. Une faute de frappe mineure peut être planifiée ; un paiement doublé, une demande perdue ou une information tarifaire contradictoire nécessite une décision explicite avant lancement. Prévoyez qui peut revenir à la version précédente et quels contrôles permettront de rouvrir le service.