Assembler les routes et les contrôles de qualité

Une route peut s’afficher correctement tout en publiant un titre générique, des données structurées qui décrivent un autre itinéraire ou un état d’attente absent. Ces défauts se repèrent difficilement en parcourant seulement la page à l’œil. Vous allez organiser des contrôles par route et utiliser des critères explicites pour décider si le catalogue est prêt à être livré.

Construire une matrice de validation

Commencez par recenser les routes qui doivent être contrôlées. Pour ce projet, la page d’accueil présente le catalogue et chaque URL de la forme /randonnees/[slug] présente un itinéraire particulier. Au minimum, testez la page d’accueil, la route de référence /randonnees/cretes-du-jura et une route pour chaque autre itinéraire réellement présent dans lib/randonnees.ts.

Cette matrice est un outil de contrôle, pas une nouvelle structure de fichiers. Conservez les routes, utilitaires et composants prévus par le contrat du projet : lib/metadonnees.ts centralise la génération des métadonnées, lib/donnees-structurees.ts construit le JSON-LD, et la page dynamique fournit les données de l’itinéraire concerné. Les leçons précédentes ont déjà détaillé ces mécanismes ; vérifiez ici leur cohérence d’ensemble.

Contrôler le HTML de chaque route

Lancez l’application avec la procédure déjà utilisée dans votre projet, puis inspectez les réponses HTTP et le HTML rendu. Un contrôle simple permet de vérifier le titre et la présence des marqueurs attendus ; il ne remplace pas la validation sémantique. Pour chaque itinéraire, comparez le slug, le titre de page, la description, l’image Open Graph et l’URL canonique aux données réellement associées à cet itinéraire.

curl -sS http://localhost:3000/randonnees/cretes-du-jura | grep -Eo '<title>[^<]+</title>|property="og:title"[^>]*|rel="canonical"[^>]*|application/ld\+json'

Repérez le titre de la page, la balise Open Graph, le lien canonique et le bloc JSON-LD. Les valeurs exactes dépendent des données du catalogue.

Le résultat de cette commande est un repérage, pas une preuve que les valeurs sont correctes. Ouvrez aussi la réponse complète et vérifiez que le titre et la description ne sont pas vides, que les URLs sont absolues lorsqu’elles sont destinées au partage, et que les chemins d’images pointent vers des fichiers existants dans public/images/randonnees/. Parsez le JSON-LD comme du JSON et comparez son nom et ses informations à la fiche visible ; une chaîne présente dans la page peut malgré tout contenir des données erronées.

Vérifier les états de chargement et le rendu

Sur la route dynamique, observez la page pendant que la partie asynchrone attend ses données, puis après son affichage. L’état temporaire doit être compréhensible, accessible et réserver une place proche de celle du détail final. Vérifiez également que le contenu principal et les métadonnées ne disparaissent pas inutilement pendant cette attente. Pour distinguer un état visible d’un simple rendu rapide, testez avec une connexion ralentie ou une source de données de test dont le délai est maîtrisé.

Inspectez ensuite le réseau sur un build de production. Confirmez que les fragments attendus arrivent progressivement lorsque le rendu est suspendu et que les scripts client téléchargés correspondent aux interactions réellement nécessaires. Le streaming et le découpage client ont été traités dans les leçons précédentes : utilisez leurs contrôles, sans ajouter de JavaScript pour rendre vérifiable une page qui ne nécessite pas d’interaction.

Appliquer les contrôles de qualité

Exécutez les vérifications prévues par les scripts réellement déclarés dans package.json, puis lancez une compilation de production. Ne copiez pas une commande de lint ou de test sans confirmer qu’elle existe dans ce projet. La compilation détecte des erreurs de types et de rendu, mais elle ne certifie ni l’exactitude du JSON-LD ni l’absence de régression de performance ; ces contrôles restent des lignes distinctes de votre matrice.

npx next build

Une compilation de production réussie se termine sans erreur. Les avertissements et la liste des routes générées doivent être examinés, et non ignorés.

Pour le budget client, comparez les ressources JavaScript transférées sur la route à votre budget documenté et à la mesure de référence. Notez les mêmes conditions de mesure et la taille pertinente, sans confondre taille compressée et taille transférée. Si le budget est dépassé, identifiez le script responsable dans le waterfall, puis corrigez la cause avant de valider ; ne relevez pas simplement la limite pour faire passer le contrôle.

Enfin, relancez Lighthouse sur la route de référence et comparez les indicateurs au rapport initial, dans des conditions comparables. Une compilation réussie n’autorise pas une régression : consignez le résultat et bloquez la validation si un indicateur dépasse les règles de non-régression que vous avez fixées. Vous disposez alors d’un état de qualité vérifiable avant les opérations de mise en ligne, qui seront abordées dans les deux prochaines leçons.

À retenir

• Validez la page d’accueil et chaque route d’itinéraire avec une matrice commune.
• Comparez les métadonnées, les images et le JSON-LD aux données de la route affichée.
• Vérifiez l’état d’attente et le rendu progressif sur un build de production.
• Contrôlez le budget JavaScript et Lighthouse par rapport aux références ; aucune régression n’est acceptée.