gergobalogh/launch-check

Vérification de lancement : cette page est-elle prête ?

Le jour du lancement, une page reçoit la majeure partie de son audience, et une correction au jour 2 en manque la plus grande partie. Faites les choses correctement avant la publication.

Cette checklist s'applique à toutes les pages. Gardez-la vierge de noms de page et de données de page : rédigez ici une nouvelle leçon sous forme de règle générale, et conservez la page et ses chiffres dans les notes du projet.

Comment l'exécuter

1. Nommez la page. Son type (article ou histoire, outil ou jeu, hub), son rôle en une phrase, et ses étapes : arrivé → utilisable → première utilisation → action principale → ça a marché → étape suivante. Réduisez les étapes qui ne s'appliquent pas. N'ajoutez pas d'entrées, de chiffres ou d'actions simplement pour satisfaire une vérification.
2. Servez une build locale (dist/ ou le serveur de développement) avec les analytics bloqués. N'ouvrez jamais la page en ligne.
3. Parcourez toutes les vérifications sur les quatre écrans ci-dessous. Marquez chaque réussite, échec, non vérifié, ou N/A avec une raison. Pour une vérification qui demande un jugement, écrivez ce que vous avez vu (la phrase que vous avez reformulée, la capture d'écran que vous avez regardée), pas seulement « réussi ».
4. Blocant : corrigez-le ou obtenez une dérogation explicite de l'utilisateur, et vérifiez-le s'il n'est pas vérifié. Recommandation : signalez-le ; ça n'empêche pas le lancement.
5. Écrivez le résultat dans les notes ou le tableau de tâches du projet, en comptant les 29 vérifications : Vérification de lancement : 25 réussites, 1 échec, 1 non vérifié, 2 N/A ; blocant : U1 échec ; recommandation : S3 non vérifié ; N/A : U2 (pas de saisie), U3 (pas d'attente).

Écrans : téléphone 390×844, tablette 820×1180, ordinateur portable 1366×768, grand écran 1920×1080. Vérifiez chacun d'eux ; une mise en page large déplace les choses autant qu'une mise en page étroite. Confirmez les échecs de mise en page par une capture d'écran, car la source seule ne peut pas les montrer.

Navigateur : un Chromium sans tête (Playwright) suffit, car une build locale ne nécessite pas de connexion. Avant de charger la page, bloquez votre hôte analytics sur cet onglet (page.route(/votre-hôte-analytics/, r => r.abort())), afin que les vérifications ne soient jamais comptées comme des visites.

Par type de page :

• Article ou histoire : continuer à défiler est l'étape suivante, donc U2 est N/A, et U3 si rien n'attend.
• Outil ou jeu : T2 couvre tout le texte que la page contient ; la première utilisation doit donner un résultat réel.
• Hub : la récompense est de trouver la bonne chose, donc T1 signifie que chaque lien fait ce qu'il promet.

Accroche

• H1 · Blocant. Depuis le premier écran seul, à toutes les tailles, vous pouvez dire en une phrase ce que le visiteur obtient. La récompense, pas le sujet. Écrivez cette phrase. Si vous ne pouvez pas l'écrire, ou si elle ne nomme que le sujet, ceci échoue.
• H2 · Recommandation. Le premier écran donne à un étranger une raison de continuer : un résultat spécifique, un chiffre, un résultat ou une question, et qui est vrai. Cela doit toujours fonctionner pour quelqu'un arrivant d'un article sans contexte.
• H3 · Recommandation. L'aperçu du lien fait la même promesse. og:image, le titre et la description disent la récompense. Vérifiez les balises et l'image dans la build.
• H4 · Blocant. La première action est visible sans défilement à toutes les tailles, et ressemble clairement à une action, avec suffisamment de contraste. Sur une histoire à défilement, la première action est le défilement : un indice de défilement visible réussit.

Corps

• T1 · Blocant. Le corps tient ce que l'accroche a promis, et tôt. La récompense n'attend pas la fin. Si la page est longue, une version courte vient en premier et le reste est au choix du visiteur.
• T2 · Blocant. Ça se lit bien du début à la fin. Lisez tout dans l'ordre, comme un étranger le ferait. Chaque partie découle de la précédente et ajoute quelque chose, rien n'est du remplissage, et vous pouvez raconter le tout en une phrase.
• T3 · Recommandation. Un point principal ou un chiffre par écran. Le reste va dans un tableau ou derrière « plus ». N/A si la page ne présente ni chiffres ni résultats.
• T4 · Blocant. Chaque chiffre et affirmation a une source, et tout ce qui est caché fonctionne. Ouvrez chaque tiroir, onglet et accordéon et suivez chaque lien source. Une section fermée fait toujours partie de la page.
• T5 · Recommandation. Le texte respecte les règles de style de l'auteur et un test de rédaction IA, sans texte de substitution, de brouillon ou de débogage restant. Le texte de la page est publié sous le nom de l'utilisateur, donc signalez les problèmes et demandez ; ne le reformulez pas seul.

Écrans

• S1 · Blocant. Ça a l'air correct sur les quatre écrans, à chaque étape. Prenez une capture d'écran après chaque étape, et regardez chacune : rien de coupé, qui se chevauche ou qui n'est pas stylisé (les éléments créés par script peuvent manquer de CSS ciblé), pas de défilement horizontal. Après une recherche ou une sélection qui déplace une carte, vérifiez que le résultat atterrit dans la partie non couverte par un panneau, à toutes les tailles.
• S2 · Blocant. Tout le texte est lisible à sa taille rendue. Mesurez-le, ne jugez pas à l'œil, et visez 12 px ou plus. Pour les graphiques SVG : taille de police × largeur rendue ÷ largeur viewBox.
• S3 · Recommandation. Utilisable en moins de 2 s sur un téléphone. Utilisable signifie le point le plus précoce auquel la première action fonctionne. Chronométrez à partir du début du chargement, avec un cache froid et un profil CPU et réseau de téléphone indiqué. Une exécution sans limitation sur un ordinateur de bureau ne peut pas montrer une réussite sur téléphone.
• S4 · Blocant. Le chargement lent et le chargement échoué ont tous deux l'air corrects. Testez les réseaux lents (CDP Network.emulateNetworkConditions, 9 / 1.6 / 0.75 / 0.4 Mbps) et un chargement échoué. Servez avec compression comme le CDN pour les temps ; un serveur local non compressé exagère chaque attente. Prenez une capture d'écran toutes les 0,5 s lors de chaque transition de chargement à partir d'un démarrage à froid, et regardez les images. Gardez la dernière bonne image visible avec une étiquette de chargement ; un repli est uniquement pour l'échec. Les étiquettes doivent être correctes pendant le chargement et après l'échec. N/A si rien ne se charge tardivement.

Utilisation

• U1 · Blocant. Après chaque étape, le prochain contrôle est à l'écran à toutes les tailles, là où la page laisse le visiteur. Testez chaque chemin vers une étape séparément (exemple, tapé, cliqué). Vérifiez chaque cible de défilement, en-tête collant et le pli.
• U2 · Recommandation. Il y a un moyen d'entrée en un tap (un exemple ou un préréglage) à côté de toute saisie libre, et l'événement indique lequel a été utilisé. N/A sans saisie libre.
• U3 · Blocant. Toute attente de plus de 2 s affiche une progression et se termine par un résultat clair ou une erreur claire. Simulez une réponse retardée et une réponse échouée localement. Un spinner qui ne se termine jamais échoue. N/A si aucune action n'attend. Un contrôle affiché avant le chargement de son script (un formulaire pour une carte chargée paresseusement) doit fonctionner ou faire la queue : utilisez-le pendant le chargement et après un chargement échoué. Une soumission de formulaire non gérée recharge la page.

Prochaine étape

• N1 · Recommandation. Au moment du succès, il y a une prochaine chose claire : une page connexe, essayez autre chose, rejouez. Placez-la là où le succès se produit, pas dans le pied de page.
• N2 · Recommandation. Boutons de partage qui envoient le résultat : WhatsApp, Facebook, X et copier le lien, chacun transportant une phrase écrite avec le résultat, pas seulement le titre, placé là où le résultat apparaît. La phrase est une copie publique, donc l'utilisateur la rédige : demandez. Un hub sans résultat a toujours besoin d'une phrase de l'utilisateur. N'en inventez pas une ou ne marquez pas ceci N/A seul. L'événement share envoie uniquement le réseau, jamais le texte ou l'URL.

Search

Les réponses IA de Google (AI Overviews, AI Mode) prennent les pages de l'index Search ordinaire : une page qui se classe avec un extrait peut être citée, et aucun fichier ou balisage propre à l'IA n'est nécessaire. Les données structurées doivent correspondre à ce que la page affiche.

• F1 · Blocant. La page peut être indexée : une adresse canonique, pas de noindex errant, listée dans le sitemap. Une page trop mince pour être classée (un stub qui ne fait que rediriger ailleurs, une liste vide) est plutôt exclue de la recherche : noindex et hors du sitemap, sans autre version linguistique pointant vers elle.
• F2 · Recommandation. Le titre dit ce que la page contient, pas seulement le nom du site, avec le nom à la fin ; la description est propre à la page et n'apparaît sur aucune autre page.
• F3 · Recommandation. Une ligne visible indique qui l'a créée, quand elle a été publiée et à quel point ses données sont récentes, avec la même date de publication dans les données structurées. Modifiez la date de modification uniquement lorsque le contenu change réellement. N/A pour un hub.
• F4 · Blocant. Chaque image dans le HTML a une source et un texte alternatif réel, y compris les figures affichées uniquement sans JavaScript. Une <img> vide échoue.
• F5 · Recommandation. Une page construite sur des données propose les données : un CSV après une vérification de la vie privée (uniquement les champs que la page affiche déjà), une ligne de licence à côté du téléchargement, et un balisage Dataset. Une vidéo obtient un balisage VideoObject avec une affiche. N/A lorsque la page n'a ni l'un ni l'autre.

Après le lancement : demandez l'indexation de la page dans Search Console (le compte de l'utilisateur, donc demandez), et ajoutez la question à laquelle elle répond à la liste de questions de réponse IA du projet si celui-ci en tient une.

Mesure

Les vérifications supposent un tracker d'événements respectueux de la vie privée (Umami, Plausible ou similaire) avec des événements personnalisés.

• M1 · Blocant. Les événements sont dans la build qui est lancée. Un événement par étape applicable, un par action, le succès est l'effet et non le clic, et un événement *-leave donne l'étape la plus avancée et le temps de visualisation.
• M2 · Blocant. Les événements se déclenchent via le vrai tracker. Une fonction de tracker simulée peut cacher des événements perdus. Exécutez le vrai tracker sur le nom d'hôte de production, avec context.route servant la build locale et interceptant l'endpoint d'envoi du tracker pour que rien ne quitte la machine. Actionnez chaque contrôle, les liens de saut aussi : chaque événement décrit son action, l'échec n'envoie pas de succès, et un saut au-delà du contenu n'envoie pas d'événement de lecture. Suivez un lien sortant traqué dans le même onglet et vérifiez que l'événement *-leave arrive toujours : une requête démarrée alors que la page se décharge peut être perdue, donc ces liens s'ouvrent dans un nouvel onglet.
• M3 · Blocant. Les événements sont listés dans le fichier docs/analytics.md du projet avec l'heure de mise en ligne, et une spécification d'entonnoir se trouve dans docs/funnels/ (son enregistrement dans l'outil analytics nécessite l'accord de l'utilisateur).
• M4 · Blocant. Rien de ce qu'un visiteur a tapé ou choisi n'est envoyé aux analytics : pas de hachage dans les pages vues (excluez le hachage), pas de texte de requête, pas de lieux. Uniquement des étiquettes et des compartiments fixes.
• M5 · Blocant. Les cibles sont écrites avant le lancement (un nombre par étape que vous prévoyez d'atteindre), afin que la révision après lancement ait quelque chose à comparer.
• M6 · Blocant. Les agents restent hors de la page en ligne, car leurs visites comptent comme du trafic réel. Un script de vérification qui peut pointer vers la page en ligne doit lui-même bloquer les analytics.