Liste de vérification de lancement de site

Une liste de vérification de lancement de site est un contrôle QA pré-mise en ligne de l’exploration, des redirections, de la performance, de l’analytique, de l’accessibilité, des métadonnées et des données structurées. Elle réduit le risque qu’un lancement visuellement terminé parte en production avec des problèmes de mesure ou de visibilité.

Indexation et exploration

• Retirer les directives noindex de préproduction et la protection par mot de passe. C’est l’erreur de lancement la plus coûteuse, parce qu’aucune vérification visuelle ne la révèle. Un noindex oublié garde les pages hors de l’index jusqu’à son retrait et un nouveau passage des robots, ce qui peut prendre des semaines sur un site à faible autorité.

  Comment vérifier : Demandez une URL de production par gabarit avec curl -sI, puis affichez sa source.

  Réussi quand : Aucun noindex dans l’en-tête X-Robots-Tag ni dans la balise meta robots, et chaque page renvoie 200 sans demande de connexion.

• Vérifier que le robots.txt et le sitemap XML sont corrects et soumis. Un Disallow: / de préproduction expédié en production bloque toute exploration. Le sitemap ne doit lister que des URL canoniques — ni redirections, ni pages en noindex — car un sitemap rempli d’URL non indexables ralentit la découverte de celles qui comptent.

  Comment vérifier : Ouvrez /robots.txt et le sitemap sur l’hôte de production, explorez les URL du sitemap et soumettez-le dans la Search Console.

  Réussi quand : Aucun Disallow: / pour tous les agents, le sitemap est déclaré dans le robots.txt, la Search Console l’affiche en Réussite, et chaque URL listée renvoie 200 et est sa propre canonique.

• Décider de l’accès des robots IA délibérément, à chaque couche qui l’applique. Le robots.txt est une couche ; une règle de robots au CDN ou au pare-feu applicatif en est une autre, et les deux peuvent se contredire : un robot autorisé par le fichier peut quand même être refusé en périphérie. Écrivez la politique, puis vérifiez chaque couche : les groupes du robots.txt pour les robots IA qui comptent pour vous (un groupe nommé remplace entièrement le groupe *, donc répétez-y chaque règle), un llms.txt si vous en publiez un, et les réglages de robots de ce qui se trouve devant le site. Les trois couches de l’accès des robots IA les passent en revue une à une.

  Comment vérifier : Comparez chaque groupe du robots.txt à la politique écrite, puis consultez les événements de sécurité du CDN ou du pare-feu pour les requêtes de robots vérifiés. Un agent utilisateur usurpé depuis votre poste n’est qu’une approximation.

  Réussi quand : Les robots vérifiés que la politique autorise reçoivent des 200, et chaque groupe nommé reprend les règles du groupe *.

• Valider la Search Console et Bing Webmaster Tools avant le lancement, pas après. Validez une propriété de domaine par DNS pour que les données s’accumulent dès la première exploration, soumettez le sitemap le jour du lancement et déployez le fichier de clé IndexNow avec le site. IndexNow joint Bing et plusieurs autres moteurs, mais pas Google, qui continue de découvrir par le sitemap et la Search Console.

  Comment vérifier : Le jour du lancement, ouvrez les deux outils et demandez l’URL du fichier de clé IndexNow.

  Réussi quand : Les deux propriétés sont validées avec le sitemap soumis, et le fichier de clé renvoie 200 avec la clé pour seul contenu.

• Définir les URL canoniques et résoudre les chemins en double. Choisissez une seule forme pour la barre oblique finale, les majuscules, le www et le protocole, puis redirigez le reste au lieu de le canoniser. Les paramètres de campagne et de filtre sont la source habituelle de doublons imprévus.

  Comment vérifier : Demandez les variantes http, www ou sans www, avec barre oblique finale et en majuscules de quelques URL, puis lisez la balise canonique de chaque page.

  Réussi quand : Chaque variante fait un 301 en un seul saut vers la forme retenue, et la canonique de celle-ci pointe vers elle-même.

• Cartographier et tester les redirections 301 depuis les anciennes URL. Redirigez vers la page équivalente la plus proche, pas vers l’accueil : une redirection vers une destination sans rapport peut être traitée comme un soft 404, qui ne transmet rien. Testez la liste complète après le déploiement, et surveillez les chaînes : chaque saut ajoute de la latence, et les robots de Google en suivent dix au plus, donc limitez chaque ancienne URL à une seule redirection.

  Comment vérifier : Après le déploiement, passez la liste complète des anciennes URL dans un robot d’exploration en mode liste ou une boucle curl.

  Réussi quand : Chaque ancienne URL renvoie un seul 301 vers une page en 200 qui est son équivalent le plus proche : aucune chaîne, et aucune redirection en bloc vers l’accueil.

Performance et Core Web Vitals

• Optimiser les images et servir des formats modernes. L’image est le plus souvent l’élément LCP. Déclarez explicitement largeur et hauteur pour que le navigateur réserve l’espace — leur absence est une cause majeure de décalage de mise en page — et préchargez l’image principale au lieu de la charger en différé.

  Comment vérifier : Lancez Lighthouse sur une URL par gabarit et lisez l’élément LCP et les audits d’images.

  Réussi quand : Les images sont servies en WebP ou AVIF, chaque image a une largeur et une hauteur déclarées, et l’image LCP n’est pas chargée en différé.

• Vérifier LCP, CLS et INP sur des gabarits représentatifs. Les seuils « bons » sont LCP en 2,5 s ou moins, INP de 200 ms ou moins et CLS de 0,1 ou moins, mesurés au 75e centile. Testez une page de chaque gabarit, pas seulement l’accueil : les Core Web Vitals sont évalués par groupe d’URL, donc un accueil rapide masque un gabarit produit ou article lent.

  Comment vérifier : Testez une URL par gabarit dans PageSpeed Insights, sur mobile.

  Réussi quand : Chaque gabarit respecte les seuils LCP et CLS en laboratoire. L’INP se confirme plus tard avec les données terrain, car les outils de laboratoire ne le mesurent pas.

• Confirmer le comportement de la mise en cache et du CDN en production. Les en-têtes de cache qui fonctionnaient en préproduction diffèrent souvent derrière un CDN de production. Vérifiez que le HTML n’est pas mis en cache plus longtemps que prévu et qu’une purge se propage réellement, sinon la première correction de contenu semblera sans effet.

  Comment vérifier : Lisez les en-têtes Cache-Control et d’état de cache du CDN sur le HTML et les ressources statiques, puis modifiez une page et purgez.

  Réussi quand : Le HTML n’est pas mis en cache plus longtemps que prévu, les ressources versionnées le sont longtemps, et la modification apparaît dès la purge.

Sécurité et infrastructure

• Tout servir en HTTPS, avec HSTS et les en-têtes de sécurité de base. Redirigez HTTP vers HTTPS en un seul saut, et n’ajoutez Strict-Transport-Security qu’une fois chaque sous-domaine servi en HTTPS : les navigateurs le mettent en cache, donc une erreur se corrige lentement. Écrivez la politique de sécurité du contenu (CSP) pour les balises autant que pour le site : une CSP qui ne liste pas les points de collecte analytiques et de balises est une cause fréquente de mesure morte le jour du lancement.

  Comment vérifier : Demandez http:// sur chaque nom d’hôte, lisez les en-têtes de réponse d’une page HTTPS et ouvrez la console sur une page où toutes les balises se déclenchent.

  Réussi quand : Un seul 301 vers HTTPS, un en-tête Strict-Transport-Security, et aucune violation de la politique de sécurité du contenu dans la console.

• Abaisser les TTL DNS avant la bascule et écrire le plan de retour arrière. Réduisez le TTL des enregistrements à modifier au moins une période de l’ancien TTL à l’avance, pour que la bascule se propage en minutes plutôt qu’en heures. Écrivez ensuite le retour arrière : ce qui le déclenche, qui décide, combien de temps il prend, et si l’ancien environnement reste accessible jusqu’à l’acceptation du nouveau.

  Comment vérifier : Interrogez les enregistrements avec dig la veille de la bascule, et lisez le document de retour arrière.

  Réussi quand : Les enregistrements affichent le TTL abaissé, par exemple 300 secondes, et le plan de retour arrière nomme un déclencheur, un décideur et un délai de rétablissement.

• Protéger les formulaires contre le pourriel sans les casser. Ajoutez un champ piège ou un défi peu contraignant avant le lancement, car les robots trouvent vite les nouveaux formulaires. Retestez ensuite une vraie soumission de bout en bout : un filtre qui rejette en silence des prospects légitimes coûte plus cher que le pourriel qu’il arrête.

  Comment vérifier : Soumettez chaque formulaire comme un vrai utilisateur, puis une fois avec le champ piège rempli.

  Réussi quand : La vraie soumission arrive dans le CRM ou la boîte de réception, et celle avec le champ piège est rejetée.

Mesure

• Confirmer que l’analytique, le gestionnaire de balises et les conversions se déclenchent en production. Testez dans l’environnement réel, pas en mode aperçu. L’aperçu contourne le consentement, les bloqueurs de publicité et les en-têtes CSP de production — trois mécanismes qui suppriment silencieusement des balises pour une part réelle du trafic.

  Comment vérifier : Réalisez chaque conversion sur le site de production dans une session de navigation ordinaire, avec l’onglet réseau et la vue en temps réel de l’analytique ouverts.

  Réussi quand : Chaque conversion apparaît une seule fois en temps réel, avec les paramètres attendus.

• Vérifier que la gestion du consentement est active et appliquée. Contrôlez l’état refusé aussi soigneusement que l’état accordé. La défaillance à détecter est une balise qui se déclenche avant le consentement : c’est un problème de conformité, pas de données.

  Comment vérifier : Dans un navigateur vierge, refusez le consentement et surveillez l’onglet réseau ; recommencez en l’accordant.

  Réussi quand : Avant tout choix, aucune requête analytique ou publicitaire ne part au-delà des signaux sans témoin permis par votre mode de consentement, et après, les balises suivent le choix.

• Concilier les conversions clés avec les systèmes sources. Comparez une journée de conversions analytiques au CRM ou au système de commandes. Un écart inférieur à environ 5 % correspond à l’attrition normale due aux bloqueurs et au consentement ; un écart plus grand ou unidirectionnel signale une anomalie. Faites-le avant que quiconque publie un rapport, pas après.

  Comment vérifier : Comparez une journée complète de conversions dans l’analytique au CRM ou au système de commandes.

  Réussi quand : L’analytique enregistre un peu moins de conversions que le système source, à environ 5 % près, et jamais davantage.

Contenu et accessibilité

• Valider les titres, méta-descriptions et données structurées. Cherchez les valeurs par défaut des gabarits qui ont survécu : titres dupliqués et descriptions restées à l’état d’espace réservé. Validez les données structurées avec le test des résultats enrichis, et assurez-vous qu’elles décrivent ce que la page montre réellement.

  Comment vérifier : Explorez le site, exportez titres et descriptions, et testez une URL par gabarit dans le test des résultats enrichis.

  Réussi quand : Aucun titre ni description en double ou laissé à l’état d’espace réservé, et aucune erreur de données structurées.

• Vérifier les titres, le texte alternatif et la navigation au clavier. Un seul H1 par page dans un ordre logique, un texte alternatif qui transmet la fonction plutôt que le nom de fichier, et chaque élément interactif accessible au clavier avec un focus visible.

  Comment vérifier : Parcourez chaque gabarit au clavier sans souris, et lancez une vérification automatisée de l’accessibilité comme axe ou Lighthouse.

  Réussi quand : Chaque contrôle est atteignable avec un focus visible, chaque page a un seul H1, et la vérification ne signale ni texte alternatif manquant ni erreur d’ordre des titres.

• Tester les formulaires, les états d’erreur et les pages de confirmation. Testez les chemins d’échec : soumission invalide, doublon, expiration. Les états d’erreur sont la partie la moins testée d’un lancement et la plus susceptible de perdre une conversion sans le signaler.

  Comment vérifier : Soumettez chaque formulaire avec une saisie invalide, deux fois de suite, et avec le réseau ralenti ou coupé.

  Réussi quand : Chaque échec affiche un message clair, conserve la saisie et n’enregistre aucune conversion.

• Définir les images d’aperçu social et le favicon. Donnez à chaque gabarit une og:image avec une URL absolue, et vérifiez l’aperçu dans l’outil de débogage de partage de chaque plateforme avant l’annonce : elles gardent en cache la première lecture. Google affiche le favicon à côté de vos résultats : il doit être carré, d’au moins 8 × 8 px (plus de 48 × 48 est recommandé) et explorable, tout comme la page d’accueil.

  Comment vérifier : Collez une URL par gabarit dans l’outil de débogage de partage de chaque plateforme, et demandez l’URL du favicon.

  Réussi quand : Chaque aperçu affiche l’image et le titre prévus, et le favicon renvoie 200 sans être bloqué par le robots.txt.

• Livrer de vraies pages 404 et 500. Une page absente doit renvoyer un statut 404, pas un 200 avec un texte « introuvable », que Google traite comme un soft 404. Donnez-lui un chemin de retour dans le site, et assurez-vous que la page d’erreur serveur existe avant que la première panne en ait besoin.

  Comment vérifier : Demandez une URL inventée et lisez le code d’état, puis simulez une erreur serveur.

  Réussi quand : L’URL inventée renvoie 404 avec un chemin de retour dans le site, et la page d’erreur s’affiche avec un statut 5xx.

• Publier la politique de confidentialité et adapter la bannière de consentement aux territoires desservis. La politique doit être en ligne avant le début de la collecte, et les réglages par défaut de la bannière doivent suivre la règle la plus stricte qui s’applique : la Loi 25 du Québec et la LCAP ne fonctionnent pas comme les valeurs par défaut américaines. Confirmez ensuite que les promesses de la bannière correspondent à ce que font réellement les balises, avec les vérifications de consentement de la section Mesure.

  Comment vérifier : Comparez la politique et la bannière à l’inventaire des balises, selon le réglage par défaut de chaque territoire.

  Réussi quand : Chaque balise qui se déclenche est déclarée dans la politique, et aucune ne se déclenche avant le choix que demande la bannière.

Surveillance après lancement

• Surveiller la Search Console pour les erreurs d’exploration et d’indexation. Attendez-vous à des variations de positions pendant quelques semaines après un changement d’URL : c’est le réexploration et le retraitement, pas nécessairement un problème. Ce qui mérite une action, c’est la hausse des pages exclues comme explorées-non-indexées ou découvertes-non-indexées.

  Comment vérifier : Consultez le rapport Indexation des pages chaque semaine pendant le premier mois.

  Réussi quand : Les pages indexées se rapprochent du nombre d’URL du sitemap, et « Explorée, actuellement non indexée » n’augmente pas.

• Suivre la disponibilité, les 404 et les chaînes de redirection. Surveillez les référents des 404 pour repérer les liens entrants qui pointent vers des URL oubliées par le plan de redirection : ce sont celles qui coûtent du trafic.

  Comment vérifier : Mettez en place une surveillance de disponibilité, et filtrez les journaux serveur ou l’analytique sur les 404 avec leurs référents.

  Réussi quand : Les alertes de panne joignent une personne nommée, et chaque 404 qui a un référent externe reçoit une redirection.

• Revérifier les Core Web Vitals avec des données terrain après quelques semaines. Les outils de laboratoire mesurent une exécution sur une connexion. Les données terrain reflètent les appareils et réseaux réels, et le rapport d’expérience utilisateur Chrome demande environ 28 jours de collecte avant que les chiffres post-lancement aient un sens.

  Comment vérifier : Environ 28 jours après le lancement, ouvrez le rapport Core Web Vitals et les données terrain de PageSpeed Insights.

  Réussi quand : Chaque groupe d’URL est jugé Bon pour LCP, INP et CLS sur mobile.

Si un lancement fait partie d’un changement de plateforme, le guide de décision sur le CMS headless ci-dessous couvre les compromis d’architecture.

Sources

Les affirmations factuelles de cette page ont été vérifiées auprès de ces sources primaires le 10 octobre 2026 :

• web.dev — Web Vitals (mis à jour le 31 octobre 2024) — appuie les seuils LCP, INP et CLS et le 75e centile.
• Aide Search Console — rapport Core Web Vitals — appuie le regroupement des URL similaires dans l’évaluation.
• Chrome for Developers — API CrUX (mis à jour le 11 février 2025) — appuie la fenêtre glissante de 28 jours des données terrain.
• Google Search Central — Déplacements de site avec changement d’URL (mis à jour le 20 août 2026) — appuie le traitement des redirections sans rapport comme des soft 404.
• Google — Codes d’état HTTP et robots de Google (mis à jour le 4 février 2026) — appuie la limite de dix sauts de redirection.
• Google Search Central — Consignes générales sur les données structurées (mis à jour le 10 juillet 2026) — appuie le test des résultats enrichis et le balisage du seul contenu visible.
• Google Search Central — Favicon dans les résultats de recherche (mis à jour le 28 août 2026) — appuie les exigences de taille et d’exploration du favicon.
• Aide Search Console — rapport Indexation des pages — appuie les états explorée-non-indexée et découverte-non-indexée.