Mettre un site Next.js en ligne semble simple : un push, un déploiement, c'est fini. En pratique, quelques contrôles évitent des erreurs coûteuses. Voici la checklist que nous avons suivie pour le média Actu by BOVO, avant de le rendre public en octobre 2026.
1. Lint et typage
Un npm run lint et un contrôle de types doivent passer avant tout déploiement. Ils attrapent les erreurs de référence et les imports cassés, souvent avant qu'elles n'atteignent la production.
2. Build de production
Le build doit réussir sans erreur. Surveillez aussi les avertissements : un avertissement sur la taille des données d'une page signale un problème de performance à corriger, pas à ignorer.
3. Redirections et en-têtes
Tout ce qui change d'adresse doit rediriger en 301. Pour nous, cela a concerné le passage de www vers le domaine nu : une règle redirects dans next.config.ts. Les en-têtes de sécurité se déclarent au même endroit : X-Content-Type-Options, Referrer-Policy, X-Frame-Options et Strict-Transport-Security.
Attention à une piège que nous avons rencontré : les règles de redirection avec locales ne voient pas le préfixe /fr de la même manière. Il faut vérifier chaque règle avec un vrai appel HTTP, pas seulement en lisant le code.
4. Sitemap, RSS et robots
Chaque fichier XML doit être valide. Un parseur XML le confirme en une ligne. Vérifiez aussi le nombre d'URL attendu dans le sitemap, la présence des flux RSS et le fichier robots.txt, qui doit pointer vers les sitemaps.
5. Contrôle en ligne
Après le déploiement, testez les URL réelles : pages principales, articles, rubriques, pages d'erreur, images. Une page qui répond 200 peut afficher une image cassée ; un code 404 doit bien renvoyer une page d'erreur lisible.
Nous lançons aussi un contrôle automatique de chaque page en largeurs d'écran, de 320 à 1440 pixels, pour détecter les débordements horizontaux.
Le blocage de déploiement Vercel
Un point peu documenté : sur l'offre Hobby, Vercel refuse de déployer un commit dont l'auteur n'est pas relié au compte. Le déploiement reste en « blocked » sans erreur visible dans l'interface. Pour le contourner sans relier le compte Git, nous déployons une archive du dépôt. Pour une solution durable, reliez le compte Git à l'équipe Vercel.
Ce qui n'a pas été vérifié
Une checklist ne remplace pas un test de charge ni un audit de sécurité complet. Nous n'avons pas mesuré le comportement du site sous forte affluence, et les contrôles de performance se limitent aux pages principales. Pour un site à fort trafic, prévoyez ces tests séparément.
Pourquoi tester les en-têtes et les redirections
Un en-tête oublié ou une redirection mal écrite ne se voit pas sur la page d'accueil. Elle se voit dans les liens de vos anciens articles, dans les moteurs de recherche et dans les partages sur les réseaux. C'est pourquoi chaque règle doit être testée par un appel HTTP réel, avec un code de réponse attendu.
Revérifier après chaque modification
Les contrôles ne valent que pour le déploiement qu'ils accompagnent. Une modification d'un composant partagé, d'un en-tête ou d'une règle de redirection impose de relancer toute la liste, pas seulement le test de la page modifiée.
Sources
- Contrôles réalisés sur le dépôt du média Actu by BOVO, entre le 25 et le 28 octobre 2026. Les commandes exactes sont dans le dépôt, dans
DEPLOIEMENT.md. - Documentation officielle de Next.js, section
redirectsetheadersdenext.config.
