Déployer le catalogue et comparer les résultats
Objectif : Mettre en production une version du catalogue de randonnées et comparer ses mesures au rapport de référence.
Une application qui fonctionne en développement n’est pas encore prête à être mise en ligne. Il faut vérifier le build destiné à la production, contrôler les routes sur une version déployée et comparer les résultats à une référence mesurée auparavant. Vous allez suivre ce processus sans modifier les fichiers du projet.
Préparer un build de production
Le build de production compile l’application et prépare les ressources qui seront servies aux visiteurs. Utilisez le gestionnaire de paquets déjà configuré dans le dépôt et vérifiez que le fichier package.json expose bien les scripts Next.js attendus. Ne remplacez pas une erreur de compilation par un démarrage en mode développement : ce dernier ne représente pas le comportement déployé.
npx next build
npx next startLa première commande termine sans erreur et génère le build de production. La seconde démarre le serveur de production local, généralement sur http://localhost:3000.Le processus ci-dessus suppose que les dépendances du projet sont installées et que les scripts et la configuration existants sont compatibles avec la version de Next.js utilisée. Si le projet fournit déjà des commandes de build ou de démarrage dans package.json, utilisez-les plutôt que de créer de nouveaux scripts. Avant de continuer, vérifiez que le build termine sans erreur et que le serveur sert le catalogue et la route /randonnees/cretes-du-jura.
Déployer d’abord en prévisualisation
Déployez le commit validé dans un environnement de prévisualisation fourni par votre hébergeur. Cette URL permet de tester le build servi à distance sans remplacer immédiatement la version publique. La procédure de déploiement varie selon le fournisseur : utilisez sa configuration existante pour le dépôt et ne copiez pas une commande propre à un hébergeur qui n’a pas été choisi pour ce projet.
Sur l’URL de prévisualisation, ouvrez la page catalogue et la route dynamique /randonnees/cretes-du-jura. Contrôlez le chargement des images, l’affichage de l’état initial puis du détail, l’absence d’erreurs dans la console et le comportement des liens. Vérifiez également le HTML rendu pour confirmer que le titre, la description, l’URL canonique, les champs Open Graph et le JSON-LD correspondent bien à l’itinéraire.
Comparer avant et après
Consignez pour chaque mesure la date, l’URL, le commit testé, l’environnement et les principaux résultats Lighthouse. Comparez les valeurs aux résultats initiaux de la leçon « Mesurer l’état initial d’une route » et appliquez le seuil de non-régression défini dans « Fixer un budget de JavaScript client ». Ne concluez pas à une amélioration sur la base d’un score isolé : vérifiez aussi les indicateurs détaillés et les ressources chargées dans le waterfall.
| Élément | Référence | Prévisualisation |
|---|---|---|
| URL et commit | Route et commit de référence | Route et commit mesurés |
| Conditions | Profil et conditions consignés | Conditions aussi proches que possible |
| Lighthouse | Valeurs de la référence | Valeurs obtenues, sans estimation |
| JavaScript client | Mesure et budget documentés | Mesure vérifiée sur le build |
| Décision | État de départ | Accepter ou bloquer la livraison |
Si une route échoue, si les métadonnées sont incorrectes, si le budget JavaScript est dépassé ou si Lighthouse révèle une régression, bloquez la promotion en production. Identifiez le changement concerné, corrigez-le, puis reconstruisez et remesurez le même parcours. Ne modifiez pas la référence pour faire disparaître une régression : elle ne doit être remplacée que si une nouvelle base a été explicitement validée.
Promouvoir en production
Lorsque les contrôles passent, déployez en production le même commit validé en prévisualisation, selon le mécanisme de promotion de votre hébergeur. Évitez de reconstruire un autre état du code entre les deux environnements : vous devez pouvoir relier les résultats observés au code effectivement publié. Après la mise en ligne, ouvrez les routes principales et vérifiez qu’elles répondent correctement avec leur domaine public.
Archivez le relevé avant-après avec l’identifiant du déploiement et conservez la décision de livraison. La comparaison établit si cette version respecte la référence et le budget ; elle ne remplace pas le contrôle des visiteurs après publication. La prochaine leçon portera sur les mesures de terrain et le suivi de l’application après déploiement.
À retenir
- Construisez et testez le build de production, pas seulement le mode développement.
- Validez les routes, métadonnées et ressources sur une URL de prévisualisation.
- Comparez les mesures Lighthouse aux références avec des conditions aussi proches que possible.
- Bloquez la livraison en cas de régression ou de dépassement du budget JavaScript.
- Promouvez le commit validé et conservez les résultats de comparaison.