Introduction

Quand j'ai décidé de refaire mon portfolio, j'ai longuement hésité entre plusieurs approches : un site statique avec Astro, une application React classique avec Vite, ou Next.js avec son App Router.

J'ai passé plusieurs semaines à prototyper, tester, benchmarker. Je voulais comprendre les forces et les faiblesses de chaque solution avant de m'engager.

Après cette phase d'exploration, mon choix s'est porté sur Next.js 14. Voici pourquoi, en détail.

1. Le rendu hybride : la vraie raison de mon choix

Ce qui distingue Next.js des autres frameworks, c'est sa capacité à mélanger plusieurs stratégies de rendu dans un même projet.

Les 3 modes de rendu

SSG (Static Site Generation) La page est générée au moment du build, une fois pour toutes. Le HTML est ensuite servi depuis un CDN. Résultat : des temps de chargement quasi instantanés.

Idéal pour :

  • Page d'accueil
  • Pages statiques (À propos, Contact)
  • Articles de blog (une fois publiés, ils ne changent plus)

SSR (Server-Side Rendering) La page est générée à chaque requête, côté serveur. Le HTML fraîchement généré est envoyé au navigateur.

Idéal pour :

  • Pages qui dépendent de l'utilisateur connecté
  • Données en temps réel
  • Pages avec paramètres dynamiques

ISR (Incremental Static Regeneration) La page est générée statiquement au build, mais revalidée en arrière-plan tous les X temps. Un visiteur voit toujours la version en cache, mais elle est mise à jour discrètement.

Idéal pour :

  • Blogs avec commentaires
  • Catalogues produits
  • Pages avec contenu semi-dynamique

Pourquoi ça compte pour un portfolio

Pour mon portfolio, j'utilise :

  • SSG pour la page d'accueil, À propos, Contact, Projets
  • SSG pour les articles de blog
  • ISR pour rien pour l'instant, mais je garde cette possibilité pour plus tard

Résultat : temps de chargement moyen de 200-300 ms, ce qui est excellent.

Avec Astro, j'aurais eu uniquement du SSG. Avec Vite + React pur, j'aurais eu du CSR (Client-Side Rendering, mauvais pour le SEO). Next.js m'offre les trois dans un seul projet.

2. Le SEO natif : un game-changer

C'est probablement l'argument qui a pesé le plus lourd dans ma décision.

Gérer les métadonnées avec l'App Router

Dans les anciennes versions de Next.js, il fallait passer par une bibliothèque à part pour gérer les balises d'en-tête. Avec l'App Router, cette gestion est devenue native : chaque page peut définir son propre titre, sa description et ses balises Open Graph directement dans son code, sans dépendance externe.

Mieux encore, ces métadonnées peuvent être générées dynamiquement, page par page, à partir du contenu réel de chaque article. Chaque billet de blog obtient ainsi son propre titre, sa propre description et sa propre image de partage sur les réseaux sociaux — sans effort supplémentaire, puisque tout provient automatiquement du frontmatter des fichiers markdown.

Sitemap et robots.txt générés automatiquement

Next.js permet de générer un plan de site (sitemap.xml) et un fichier robots.txt directement en JavaScript, sans dépendance externe. Le plan de site se met à jour automatiquement à chaque nouvel article publié, avec la date de dernière modification et une priorité d'indexation adaptée à chaque type de page.

Résultat : Google indexe correctement chaque page, y compris les nouveaux articles, sans que j'aie besoin de maintenir un fichier XML à la main.

Données structurées (JSON-LD)

Pour aller plus loin dans le SEO, j'ai ajouté des données structurées au format Schema.org directement dans mes articles, ce qui permet à Google d'afficher des "rich snippets" (auteur, date de publication, image) dans les résultats de recherche.

Avec Astro, j'aurais pu faire à peu près la même chose manuellement. Avec Vite + React pur, tout ceci aurait été bien plus laborieux, car le rendu se fait côté client : Google verrait une page vide avant l'exécution du JavaScript.

3. La performance, sans effort particulier

Optimisation automatique des images

Le composant d'image intégré à Next.js a été un vrai confort. Sans rien configurer, j'obtiens :

  • Génération automatique de formats modernes (WebP, AVIF)
  • Redimensionnement adapté à la taille d'écran
  • Lazy loading natif (les images hors écran ne chargent pas)
  • Un effet de flou pendant le chargement, pour éviter le "layout shift"

Optimisation des polices

Le module de gestion des polices de Next.js télécharge et auto-héberge les polices (Google Fonts ou autres) au moment du build, ce qui évite une requête réseau supplémentaire vers un serveur externe et élimine le fameux effet de "flash" de texte non stylé (FOUT).

Code splitting automatique

Chaque page ne charge que le JavaScript dont elle a besoin. Si ma page "Projets" utilise une bibliothèque de graphiques lourde, cette bibliothèque n'est jamais téléchargée par un visiteur qui consulte uniquement mon blog.

Résultats mesurés

Sur mon portfolio final, avec Lighthouse :

| Métrique | Score | |----------|-------| | Performance | 98-100 | | Accessibilité | 100 | | Bonnes pratiques | 100 | | SEO | 100 | | LCP (Largest Contentful Paint) | ~0.8s | | CLS (Cumulative Layout Shift) | 0.00 |

Ces scores n'ont rien de magique : ils viennent du fait que Next.js encourage, par défaut, les bonnes pratiques que j'aurais dû implémenter moi-même avec un setup Vite classique.

4. L'expérience de développement (DX)

Un routing basé sur les fichiers

Avec l'App Router, la structure de dossiers est littéralement le plan du site : chaque dossier correspond à une route, et chaque fichier de page définit le contenu affiché à cette adresse. Pas de fichier de configuration de routes à maintenir séparément, pas de bibliothèque de routing tierce (comme React Router) à installer et synchroniser.

Server Components vs Client Components

L'App Router introduit une distinction fondamentale : par défaut, tous les composants sont des Server Components, exécutés uniquement côté serveur, sans envoyer une seule ligne de JavaScript au navigateur. On bascule en Client Component uniquement quand c'est nécessaire, c'est-à-dire lorsqu'un composant a besoin d'interactivité ou de gérer un état local.

Sur mon portfolio, 90 % des composants restent des Server Components. Seuls le menu mobile, le formulaire de contact et quelques animations sont des Client Components. Le JavaScript envoyé au navigateur est donc minimal.

Route Handlers pour les API

Besoin d'un petit endpoint pour le formulaire de contact ? Pas besoin d'un serveur Express séparé, ni de service externe : Next.js permet de définir directement des routes d'API au sein du même projet, capables de recevoir des requêtes, de les traiter et de renvoyer une réponse.

TypeScript de première classe

Next.js configure TypeScript automatiquement dès la création du projet, avec des types déjà fournis pour les métadonnées, les pages, les layouts, etc. Aucune configuration manuelle nécessaire.

5. Comparaison avec les alternatives envisagées

| Critère | Next.js 14 | Astro | Vite + React | |---------|-----------|-------|--------------| | Rendu hybride (SSG/SSR/ISR) | ✅ Natif | ⚠️ SSG principalement | ❌ CSR uniquement | | SEO out-of-the-box | ✅ Excellent | ✅ Très bon | ❌ Nécessite du SSR externe | | Interactivité React complexe | ✅ Native | ⚠️ "Islands" à isoler | ✅ Native | | Optimisation images/polices | ✅ Automatique | ⚠️ Partielle | ❌ Manuelle | | Écosystème / communauté | ✅ Très large | ⚠️ En croissance | ✅ Large (mais générique) | | Courbe d'apprentissage | ⚠️ Moyenne | ✅ Faible | ✅ Faible | | Idéal pour un blog très statique | ⚠️ Correct | ✅ Excellent | ❌ Peu adapté |

Astro reste, à mon sens, un choix supérieur pour un site purement de contenu statique, sans aucune interactivité complexe. Mais mon portfolio contient des animations, des filtres de projets dynamiques, et je savais que j'allais vouloir ajouter des fonctionnalités interactives (un mini-CMS, des commentaires, etc.) : Next.js m'offrait la marge de manœuvre nécessaire sans devoir migrer plus tard.

6. Les points de friction rencontrés

Par souci d'honnêteté, tout n'a pas été parfait :

  • Courbe d'apprentissage de l'App Router : la distinction Server/Client Components demande un temps d'adaptation, surtout si l'on vient de l'ancien Pages Router.
  • Cache agressif : le système de cache de Next.js peut surprendre au début ; il faut apprendre à utiliser correctement les mécanismes de revalidation.
  • Taille du framework : pour un simple portfolio, Next.js est objectivement "plus lourd" à configurer qu'Astro pour un besoin équivalent en contenu statique pur.
  • Dépendance à Vercel : bien que Next.js fonctionne sur d'autres hébergeurs, certaines fonctionnalités (ISR, Edge Functions) sont plus fluides sur Vercel, ce qui crée une forme de lock-in implicite.

Conclusion

Mon choix de Next.js 14 avec l'App Router n'est pas un choix "par défaut" ou par simple popularité. C'est le résultat d'un arbitrage conscient entre trois besoins : un excellent SEO, une performance quasi-parfaite sans configuration manuelle, et la liberté d'ajouter de l'interactivité sans changer d'outil plus tard.

Astro aurait été plus simple pour un blog purement statique. Vite + React m'aurait donné plus de liberté brute, mais au prix d'un SEO et d'une performance à reconstruire moi-même from scratch.

Next.js, avec son rendu hybride, représente pour moi le meilleur compromis entre simplicité, performance et évolutivité — exactement ce qu'un portfolio de développeur doit incarner.

Ir Prince Ongala Développeur