Freelance Next.js : un site web rapide, indexable et mesuré dès la mise en ligne

Next.js est un framework open source basé sur React.js, créé par Vercel et lancé en 2016. Il réunit le front-end et une partie du back-end dans la même stack JavaScript : routes, API, gestion des métadonnées, optimisation des images et des polices.

Next.js s'appuie sur React pour les composants d'interface et sur Node.js pour le serveur : un développeur React.js y retrouve ses repères, mais doit maîtriser les règles de cache et de génération propres à Next.js. C'est là que se font la plupart des erreurs de développement web.

Son intérêt tient au moment où le HTML est produit. Google décrit trois phases pour une application web en JavaScript : exploration, rendering puis indexation, et le rendering n'intervient qu'une fois que ses ressources le permettent.

La documentation Google Search Central sur JavaScript ajoute que la génération côté serveur ou le pré-rendu restent une bonne idée, car ils accélèrent l'affichage pour les utilisateurs comme pour les robots, et que tous les robots n'exécutent pas JavaScript.

C'est le point décisif pour le GEO. Les robots des assistants d'IA lisent très souvent le HTML brut : une web app React qui n'affiche son contenu qu'après exécution du JavaScript leur reste en partie invisible, alors qu'un écran Next.js généré côté serveur leur livre le texte complet dès la première requête.

Next.js n'est pas toujours la bonne solution. Pour une vitrine de quelques écrans mise à jour par le marketing sans développeur, un CMS comme WordPress reste souvent l'option la plus simple à maintenir.

Next.js prend tout son sens quand vous avez besoin de performance, d'une interface sur mesure, d'applications web ou d'applications métier, d'un produit SaaS ou d'un frontend « headless » branché sur un CMS ou une API.

Je préfère être clair sur le périmètre : une bonne mission commence par la bonne personne au bon poste.

Je réalise moi-même :

• le cadrage tech et éditorial : architecture des URLs, stratégie de génération, plan de redirections ;
• la création de sites vitrines, d'articles de blog et d'écrans responsive en Next.js avec TypeScript, en HTML, CSS (Tailwind CSS) ;
• l'audit technique d'un projet Next.js existant et la correction des points bloquants ;
• le plan de marquage et l'intégration de la mesure : GA4, Google Tag Manager, Consent Mode ;
• l'optimisation des Core Web Vitals et la qualité du code livré.

Je confie à un spécialiste full-stack de mon réseau, que je sélectionne et dont je suis le travail :

• le développement d'applications métier lourdes, avec une logique serveur complexe en Node.js (Node.js Express, NestJS) ou en PHP (Laravel) ;
• les applications mobiles et les interfaces natives, confiées à un expert du mobile ;
• les missions qui demandent plusieurs développeurs à temps plein sur la durée, avec un lead developer et un product owner côté client ;
• le développement d'une plateforme .NET ou d'un service hors de la stack JavaScript.

Dans ce second cas, je reste votre interlocuteur sur le cadrage, la recette et la mesure : vous n'achetez pas une boîte noire, et vous gardez une vision claire de l'avancement.

Next.js tourne sur Node.js : un hébergement sur Vercel, sur AWS ou sur votre propre serveur Node.js exécute le code côté serveur. Pour un contenu entièrement statique, un simple export suffit et aucun serveur Node.js n'est nécessaire.

Les routes d'API de Next.js couvrent les besoins légers : un formulaire, un webhook, un appel à une API externe. Dès que la logique métier grossit (droits, files de traitement, state management complexe côté client), un backend dédié en Node.js Express, NestJS ou Laravel reste plus lisible et plus facile à tester.

Face à PHP et Laravel, le choix dépend surtout de vos développeurs. S'ils sont déjà à l'aise en PHP, ils peuvent garder Laravel côté serveur et utiliser Next.js pour l'interface ; une équipe JavaScript gagne à rester sur une seule stack, Next.js, Node.js et React, du navigateur à la base de données, avec une API commune.

Sur une petite mission, un développeur full-stack Next.js couvre l'API et l'interface ; sur un projet plus large, mieux vaut séparer les rôles entre frontend et logique serveur.

En pratique, trois combinaisons reviennent dans les projets :

• Next.js, React, Node.js et PostgreSQL : une stack JavaScript unique, la plus simple à recruter ;
• Next.js pour l'interface et Laravel en PHP pour la logique métier, exposée par une API ;
• Next.js branché sur un CMS headless : pour des rédacteurs qui publient souvent.

Voici les points que je contrôle sur chaque développement Next.js, avec la fonctionnalité concernée et le piège le plus fréquent.

Sur les données structurées, la documentation officielle de Next.js sur le JSON-LD recommande de placer la balise script dans layout.js ou page.js et de remplacer « < » par son équivalent Unicode pour éviter une faille XSS.

Le code 308 n'est pas un problème en soi : le guide des redirections de Google le classe parmi les redirections permanentes, au même titre que le 301. Ce qui compte, c'est la cohérence du plan de redirections.

Un front Next.js n'est pas rapide par défaut : un script tiers mal chargé, une police non optimisée, un CSS trop lourd ou une image hors format suffit à le ralentir. Fixez donc des objectifs mesurables dans le cahier des charges : la vitesse fait partie de l'expérience utilisateur.

Google définit trois Core Web Vitals, évalués au 75e percentile des chargements, sur mobile et sur ordinateur, selon web.dev :

• LCP (affichage du plus gros élément) : 2,5 secondes ou moins ;
• INP (réactivité aux interactions) : 200 millisecondes ou moins ;
• CLS (stabilité visuelle) : 0,1 ou moins.

Ces seuils se vérifient sur l'expérience réelle de vos utilisateurs (rapport Signaux Web essentiels de la Search Console), pas uniquement sur un test de laboratoire. Sur mobile, l'écart entre les deux est souvent important.

C'est un point souvent absent des offres de développement, et c'est mon second métier, le tracking et l'analytics. Sur Next.js, la navigation se fait sans rechargement complet : un tag GA4 qui ne compte que les chargements initiaux sous-estime votre audience.

Je vérifie donc :

• que chaque changement d'URL est compté (historique du navigateur ou événement envoyé dans la data layer) ;
• que Google Tag Manager, la bannière de consentement et les services tiers sont chargés une seule fois ;
• que le Consent Mode bloque réellement les tags tant que l'utilisateur n'a pas accepté ;
• que chaque conversion (formulaire, inscription, achat e-commerce) remonte avec ses paramètres.

Sur une application web en React ou en Next.js, je vérifie aussi que les erreurs JavaScript et les bugs de formulaire remontent dans un outil de suivi : une baisse de conversions vient parfois d'un bug, pas du marketing.

Beaucoup de missions commencent par un audit : le site web est en ligne, mais le trafic organique ne décolle pas ou a chuté après une mise en production.

Mon audit compare d'abord le code source et le HTML affiché après exécution du JavaScript : tout contenu absent du premier est fragile pour Google et invisible pour une partie des robots des assistants conversationnels. Je contrôle ensuite les codes HTTP, les métadonnées, le sitemap, les redirections, le poids du JavaScript envoyé au navigateur et la couverture d'indexation dans la Search Console.

Le livrable est une liste priorisée : ce qui bloque l'indexation, ce qui freine la vitesse, ce qui fausse la mesure. Je corrige moi-même ce qui relève de l'interface et de la configuration Next.js ; les corrections côté API ou base de données passent par vos développeurs internes ou par un spécialiste de mon réseau, avec des solutions documentées.

• E-commerce : fiches produits générées à l'avance et revalidées à chaque mise à jour du catalogue, intégration d'une API de paiement, données structurées produit ; les e-commerce à fort volume demandent souvent un front Next.js branché sur une plateforme existante.
• Marketing : pages de campagne rapides, formulaires reliés au CRM, mesure des conversions dans GA4 ; le marketing gagne une autonomie de publication si un CMS headless est en place.
• Applications web : espace client, tableau de bord, outil interne ; la création d'applications de ce type passe par un profil full-stack et une API solide.

• Le code source sur un dépôt GitHub à votre nom, avec un historique Git lisible.
• Une documentation d'installation, de déploiement et de mise à jour.
• Le plan de redirections, URL par URL, et la preuve de son test.
• Le plan de marquage et la recette du tracking (événements, conversions, consentement).
• Un relevé des Core Web Vitals avant et après la mise en ligne.
• Une liste des bugs connus et des évolutions possibles, priorisée.
• Une session de passation pour l'onboarding de votre équipe.

Un portfolio ne suffit pas : demandez à voir des réalisations en ligne, des démos et le dépôt GitHub d'un projet, puis posez ces questions.

1. 1Quelle stratégie de génération choisiriez-vous pour chaque type de contenu, et pourquoi ?
2. 2Comment gérez-vous les métadonnées, la canonical et le sitemap ?
3. 3Quel code HTTP renvoie un contenu supprimé dans vos développements ?
4. 4Quels Core Web Vitals mesurez-vous sur vos derniers sites, en données réelles ?
5. 5Comment le tracking GA4 compte-t-il les changements d'URL ?
6. 6Le code sera-t-il versionné sur un dépôt Git ou GitHub qui m'appartient ?
7. 7Comment traitez-vous les bugs signalés après la livraison, et dans quel délai ?
8. 8Avez-vous prévu des tests automatisés, une intégration continue et une recette avant la mise en ligne ?

Un bon freelancer répond avec des exemples précis issus de son expérience, pas avec des promesses générales : c'est le meilleur test de son expertise.

• Tout rendre côté client « parce que c'est du React » : le site web perd alors l'avantage principal de Next.js, et le contenu n'apparaît plus dans le HTML initial.
• Appeler une API lente à chaque requête alors que le contenu change une fois par semaine : la génération statique avec revalidation suffit et soulage le serveur Node.js.
• Charger tous les scripts marketing dans le layout racine : chaque écran du site web paie leur poids, et l'INP se dégrade.
• Migrer de React.js ou de WordPress vers Next.js sans plan de redirections : les URLs historiques tombent en 404 et le trafic suit.
• Laisser des routes d'API Next.js exposées sans contrôle d'accès ni limite de débit.
• Repousser la mise à jour de Next.js et de Node.js pendant des mois : les correctifs de sécurité s'accumulent et la migration devient une mission à part entière.

Aucune de ces erreurs ne vient d'un manque de compétence en code : elles viennent d'un cadrage qui oublie le référencement, la mesure ou la maintenance. C'est précisément ce que je couvre en début de mission.

Le vrai critère est simple : combien de personnes le chantier mobilise-t-il à temps plein ?

• Une seule personne, sur un lot bien défini : un freelancer, ou un full stack developer, qui vous donne un accès direct à la personne qui code et un démarrage rapide.
• Plusieurs profils en parallèle (design, front, logique serveur, mobile) : une équipe structurée ; voyez ma page agence Next.js.
• Un produit développé en continu pendant des années : un recrutement interne, éventuellement épaulé par un expert externe au démarrage pour l'onboarding et les premiers choix d'architecture.

Commencez par un cahier des charges utile. Listez les types de contenus, l'existant à reprendre, les outils à connecter (CMS, CRM, paiement) et les URLs actuelles qui reçoivent des visites. Cette dernière liste évite la plupart des pertes de trafic lors d'une refonte.

Choisissez ensuite entre forfait et régie. Le forfait convient à un périmètre stable, comme la création d'une vitrine. La régie convient à un produit digital qui évolue chaque semaine. Dans les deux cas, prévoyez les tests, la correction des bugs, la maintenance et la recette dans le budget.

1. 1Cadrage avec votre équipe tech : objectifs business, inventaire des URLs, choix des technologies (Next.js, React, CMS, base de données) et de l'hébergement (Vercel, AWS ou serveur Node.js).
2. 2Design et arborescence validés avant le premier développement.
3. 3Développement itératif, avec livraisons régulières et un environnement de prévisualisation non indexable.
4. 4Recette : métadonnées, codes HTTP, redirections, données structurées, conversions.
5. 5Mise en ligne, suivi de l'indexation dans la Search Console et des premières conversions.

Je suis ingénieur diplômé de l'École Centrale Paris (aujourd'hui CentraleSupélec) et de l'ESSEC Business School. Je programme depuis l'âge de 12 ans, en autodidacte, et ma passion pour la data remonte à l'école d'ingénieur.

Je travaille au quotidien avec Next.js : ce site tourne sur Next.js 16 et React 19 avec l'App Router, des métadonnées produites par generateMetadata, des fichiers sitemap.ts et robots.ts, une image de partage générée par le code et des données structurées JSON-LD. Ce sont exactement les points que je contrôle en mission chez un client.

Mon expertise principale est le référencement et le GEO, avec le tracking et le CRO. J'ai conçu mes propres outils, comme SERPmantics pour l'optimisation sémantique ou 12pages pour détecter la cannibalisation, et je les utilise en mission.

Décrivez-moi votre site actuel, vos clients, vos objectifs et vos délais : je vous dis si Next.js est le bon choix et qui doit intervenir. J'interviens à distance, en France et à l'international. Me contacter.