Pourquoi Next.js 15 pour mon portfolio
- next.js
- architecture
- adr
Quand j'ai relancé mon portfolio, la première vraie décision n'était pas une couleur ou une font — c'était le framework. J'avais besoin d'un socle simple à déployer, cohérent avec mon expérience React, et assez moderne pour documenter mes projets sans me battre contre l'outil.
Voici pourquoi j'ai choisi Next.js 15 avec l'App Router.
Le contexte
Mon objectif pour andrewchicout.dev :
- une vitrine professionnelle claire ;
- un blog technique en MDX pour documenter mes choix (comme les ADR) ;
- un déploiement sans serveur à gérer, avec un budget proche de zéro.
Avec dix ans d'expérience React/TypeScript, je voulais rester dans un écosystème que je maîtrise — pas apprendre un framework entier juste pour un site perso.
Pourquoi Next.js 15
Rester dans l'écosystème React
Next.js est l'évolution naturelle de mon stack frontend. L'App Router m'oblige à structurer le projet autrement qu'avec le Pages Router, mais c'est exactement ce que je cherchais : Server Components, routing file-based, et des patterns que je vois de plus en plus en production.
Un file-based routing qui scale sans config
Chaque route correspond à un fichier dans /app. Pas de table de routes à maintenir. Pour un portfolio qui va grossir (blog, projets, about), ça reste lisible mois après mois.
SSG + déploiement Vercel
Le contenu MDX est compilé au build via Velite. Les pages sont générées statiquement, servies via CDN — performances correctes sans infra custom. Sur Vercel, un git push suffit, avec des preview deployments par PR.
MDX natif dans l'écosystème
Pour un blog technique, MDX combine la simplicité du Markdown et la possibilité d'intégrer des composants React. Pas de CMS headless, pas de sync API : le contenu vit dans Git, versionné avec le code.
Ce que j'ai écarté
| Alternative | Pourquoi non |
|---|---|
| Remix | Écosystème moins large pour mon usage solo |
| SvelteKit / Astro | Rupture avec React — coût d'apprentissage non justifié |
| Gatsby | Développement actif arrêté par Netlify |
| CMS headless | Coût et complexité API inutiles pour un blog perso |
| Markdown pur | Pas de composants interactifs dans les articles |
Les trade-offs acceptés
Ce choix n'est pas neutre :
- Courbe d'apprentissage App Router — Server Components, streaming,
paramsen Promise… Il faut investir du temps pour être à l'aise. - Vendor lock-in léger avec Vercel — acceptable pour un portfolio ; Next.js reste portable si besoin.
- Contenu couplé au repo — pas d'interface d'édition web, mais VS Code + Git me conviennent.
Conclusion
Next.js 15 n'est pas le seul choix valable pour un portfolio. C'est celui qui maximise la cohérence avec mon profil, minimise la friction opérationnelle, et me laisse me concentrer sur le contenu plutôt que sur l'infra.
Prochaine étape côté architecture : comment organiser le code et le pipeline MDX.