Next.js 15 en pratique : comment j'ai construit un blog de niveau production en un week-end

Introduction

Next.js 15 est sorti depuis peu. J’ai lu la doc plusieurs fois et regardé des tutos, mais tout restait théorique — Server Actions, App Router : je comprenais les concepts, pas leur usage dans un vrai projet. Ce week-end, j’ai arrêté les vidéos et construit un blog full-stack. Frontend, backend, base de données, déploiement : deux jours plus tard, le blog tournait sur Vercel avec un score Lighthouse de 96.

Cet article raconte le parcours — pas un tuto copier-coller, mais le pourquoi des choix et les pièges. Stack : Next.js 15 + Server Actions + Prisma + PostgreSQL, du code prêt pour la production.

Pourquoi Next.js 15 ?

Le choix de la stack m’a fait hésiter longtemps.

À la sortie de Next.js 15, certains dans la communauté disaient : « Encore une mise à jour, j’en peux plus. » Honnêtement, j’étais un peu réticent — la 14 n’était pas encore totalement maîtrisée. En creusant les nouveautés, j’ai compris que cette montée de version valait vraiment le coup.

Server Actions : fini la corvée des API Routes

En full-stack, ce qui m’agace le plus, c’était les API Routes. Créer un api/posts/route.ts, définir POST, parser le body, renvoyer la réponse… toujours le même rituel.

Les Server Actions changent la donne. Vous ajoutez 'use server' devant la fonction et vous l’appelez depuis le composant. Au début, je me disais : « On met du backend dans le frontend ? » Un essai — et c’est adopté.

Exemple : avant, pour créer un article :

// Ancienne méthode : API Route obligatoire
// app/api/posts/route.ts
export async function POST(request: Request) {
  const body = await request.json()
  // plein de logique...
}
// Côté client : fetch
const response = await fetch('/api/posts', {
  method: 'POST',
  body: JSON.stringify(data)
})

Maintenant :

// app/actions/post-actions.ts
'use server'
export async function createPost(formData: FormData) {
  const title = formData.get('title')
  const content = formData.get('content')
  // accès direct à la base
  return await prisma.post.create({
    data: { title, content }
  })
}

Dans le composant, c’est comme appeler une fonction locale. Image parlante : avant, vous alliez chercher la commande au restaurant (API Routes) ; maintenant, elle est livrée chez vous (Server Actions).

Turbopack : le dev va bien plus vite

Next.js 15 a stabilisé Turbopack. Officiellement : +76,7 % au démarrage du serveur local, +96,3 % sur les mises à jour de code. J’ai cru à du marketing — en pratique, les chiffres tiennent la route.

Mon projet compte une trentaine de composants. Avec Webpack : 7-8 s au lancement ; avec Turbopack : moins de 2 s. Une modification de code, le hot reload est quasi immédiat. Le confort au quotidien n’est pas négligeable.

Pourquoi cette stack pour un blog ?

Trois raisons principales :

SSR/SSG natifs — Le SEO compte avant tout. Le rendu serveur et la génération statique de Next.js sont faits pour ça. Google reçoit du HTML complet, bien plus efficace qu’un React 100 % client.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Typage Prisma — Avec Mongoose sur MongoDB, les types se maintenaient à la main ; les bugs arrivaient vite. Prisma génère les types TypeScript depuis le schema : IntelliSense complet, peu d’erreurs.

Server Actions — Plus besoin d’API Routes : au moins 30 % de code en moins. En mode classique, j’aurais ajouté plusieurs fichiers route.ts.

Choix de stack et architecture

Une fois le pourquoi clair, place au comment.

Ma stack complète

• Frontend : Next.js 15 + TypeScript + Tailwind CSS
• Backend : Server Actions Next.js + NextAuth.js
• Base de données : PostgreSQL + Prisma ORM
• Déploiement : Vercel

Pourquoi pas MongoDB ? J’y ai pensé — c’est flexible. Mais Prisma supporte mieux PostgreSQL, et pour articles, utilisateurs et commentaires, le relationnel colle mieux.

Structure des dossiers

my-blog/
├── app/
│   ├── (auth)/          # Pages d'authentification
│   ├── blog/            # Pages du blog
│   │   └── [slug]/      # Routes dynamiques
│   ├── dashboard/       # Tableau de bord
│   ├── actions/         # Toutes les Server Actions
│   └── api/auth/        # Config NextAuth
├── components/          # Composants réutilisables
├── lib/
│   ├── prisma.ts        # Singleton Prisma (crucial !)
│   └── utils.ts         # Utilitaires
├── prisma/
│   └── schema.prisma    # Schema base de données
└── public/              # Assets statiques

J’ai itéré plusieurs fois. Au début, les Server Actions étaient éparpillées dans les pages ; la maintenance devenait ingérable. Un dossier actions dédié a tout simplifié.

Design du schema base de données

Gros piège ici. Ma première version était trop riche : tags, catégories, stats de lecture… À mi-parcours, j’ai tout simplifié — une demi-journée perdue.

Schema final :

// prisma/schema.prisma
generator client {
  provider = "prisma-client-js"
}
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}
model User {
  id        String   @id @default(cuid())
  email     String   @unique
  name      String?
  image     String?
  posts     Post[]
  createdAt DateTime @default(now())
}
model Post {
  id          String   @id @default(cuid())
  title       String
  slug        String   @unique
  content     String   @db.Text
  published   Boolean  @default(false)
  authorId    String
  author      User     @relation(fields: [authorId], references: [id])
  createdAt   DateTime @default(now())
  updatedAt   DateTime @updatedAt
  @@index([slug])
  @@index([authorId])
}

Les deux @@index sont clés pour la perf : requêtes par slug sur la liste, filtre par authorId sur le profil — les index accélèrent nettement les requêtes.

Implémentation des fonctionnalités clés

Architecture posée — place au code.

3.1 Installation et initialisation

Créer un projet Next.js 15 :

npx create-next-app@latest my-blog
cd my-blog
npm install prisma @prisma/client zod next-auth

Puis Prisma :

npx prisma init

Cela crée prisma/schema.prisma et .env. Connexion PostgreSQL :

DATABASE_URL="postgresql://username:password@localhost:5432/myblog?schema=public"

En local, PostgreSQL via Docker :

docker run --name blog-postgres -e POSTGRES_PASSWORD=mypassword -p 5432:5432 -d postgres

3.2 Intégration Prisma

Après le schema, migration :

npx prisma migrate dev --name init

Piège classique : le singleton Prisma Client. Au premier déploiement Vercel, je l’avais oublié — après quelques heures, « Too many connections ». J’ai cru à une attaque DDoS.

En dev, le hot reload recrée des instances Prisma et sature le pool. Solution :

// lib/prisma.ts
import { PrismaClient } from '@prisma/client'
const globalForPrisma = globalThis as unknown as {
  prisma: PrismaClient | undefined
}
export const prisma = globalForPrisma.prisma ?? new PrismaClient()
if (process.env.NODE_ENV !== 'production') {
  globalForPrisma.prisma = prisma
}

Un peu tordu à lire, mais une seule instance en dev, production inchangée. Bonne pratique officielle Prisma.

3.3 Server Actions en pratique

Créer un article, fonction centrale :

// app/actions/post-actions.ts
'use server'
import { prisma } from '@/lib/prisma'
import { revalidatePath } from 'next/cache'
import { z } from 'zod'
// Validation Zod pour la sécurité des types
const PostSchema = z.object({
  title: z.string().min(1, '标题不能为空').max(100),
  content: z.string().min(10, '内容至少10个字'),
  slug: z.string().regex(/^[a-z0-9-]+$/, 'slug只能包含小写字母、数字和横杠')
})
export async function createPost(formData: FormData) {
  const validatedFields = PostSchema.safeParse({
    title: formData.get('title'),
    content: formData.get('content'),
    slug: formData.get('slug')
  })
  if (!validatedFields.success) {
    return { error: '数据验证失败' }
  }
  try {
    const post = await prisma.post.create({
      data: {
        ...validatedFields.data,
        authorId: 'user-id-here' // en prod : depuis la session
      }
    })
    revalidatePath('/blog')
    return { success: true, post }
  } catch (error) {
    return { error: '创建文章失败' }
  }
}

Dans le composant :

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

// app/dashboard/new-post/page.tsx
import { createPost } from '@/app/actions/post-actions'
export default function NewPost() {
  return (
    <form action={createPost}>
      <input name="title" placeholder="标题" />
      <textarea name="content" placeholder="内容" />
      <input name="slug" placeholder="URL slug" />
      <button type="submit">发布</button>
    </form>
  )
}

Pas de useState, pas de fetch, pas de onSubmit. Le formulaire appelle la Server Action ; Next.js gère sérialisation, réseau et erreurs.

Au début, je confondais Server Actions et API Routes : livraison à domicile vs aller au restaurant. Dans la majorité des cas, les Server Actions suffisent.

3.4 Authentification

J’ai utilisé NextAuth.js :

// app/api/auth/[...nextauth]/route.ts
import NextAuth from 'next-auth'
import GitHubProvider from 'next-auth/providers/github'
import { PrismaAdapter } from '@auth/prisma-adapter'
import { prisma } from '@/lib/prisma'
export const authOptions = {
  adapter: PrismaAdapter(prisma),
  providers: [
    GitHubProvider({
      clientId: process.env.GITHUB_ID!,
      clientSecret: process.env.GITHUB_SECRET!
    })
  ]
}
const handler = NextAuth(authOptions)
export { handler as GET, handler as POST }

OAuth GitHub : créer une app dans GitHub Developer Settings, renseigner Client ID et Secret dans .env. Dix minutes, bien moins pénible qu’un JWT maison.

3.5 Stratégie SSR/SSG

Au début, tout en SSR : chaque ouverture de la liste interrogeait la base — inutile. J’ai adopté une approche hybride.

Liste du blog — SSG + ISR :

// app/blog/page.tsx
import { prisma } from '@/lib/prisma'
// Régénération toutes les heures
export const revalidate = 3600
export default async function BlogList() {
  const posts = await prisma.post.findMany({
    where: { published: true },
    orderBy: { createdAt: 'desc' }
  })
  return (
    <div>
      {posts.map(post => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.content.slice(0, 150)}...</p>
        </article>
      ))}
    </div>
  )
}

HTML statique au build, régénération horaire — l’utilisateur reçoit un fichier statique, très rapide.

Détail d’article — SSR dynamique :

// app/blog/[slug]/page.tsx
export default async function Post({ params }: { params: { slug: string } }) {
  const post = await prisma.post.findUnique({
    where: { slug: params.slug }
  })
  if (!post) notFound()
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  )
}

Chaque visite interroge la base — adapté aux contenus souvent mis à jour.

Comparaison des performances :

L’écart parle de lui-même. Next.js pour un blog : bon SEO et bonnes perfs.

Déploiement et optimisations

Code prêt — déploiement.

Déploiement sur Vercel

Push GitHub, import du dépôt sur Vercel. Détection Next.js automatique. Variables à configurer manuellement :

DATABASE_URL="votre connexion base de production"
GITHUB_ID="OAuth Client ID"
GITHUB_SECRET="OAuth Secret"
NEXTAUTH_URL="https://your-domain.vercel.app"
NEXTAUTH_SECRET="chaîne aléatoire"

Base de prod : Supabase PostgreSQL gratuit, 500 Mo/mois — largement suffisant pour un blog perso.

Deploy : site en ligne en ~2 minutes. Première visite sur mon domaine : quelques secondes de silence, puis capture d’écran.

Optimisations production

Pool de connexions Prisma :

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
  // Obligatoire en serverless Vercel
  directUrl = env("DIRECT_URL")
}

En serverless, chaque invocation peut ouvrir une connexion ; directUrl réutilise le pool.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Images :

import Image from 'next/image'
<Image
  src="/avatar.jpg"
  alt="用户头像"
  width={100}
  height={100}
  // compression et optimisation automatiques Next.js
/>

WebP, chargement à la demande — gains visibles.

Scores finaux :

Lighthouse : desktop 96, mobile 92, SEO 100. De zéro à un site de niveau production en deux jours — motivant.

Extensions et ressources

Version MVP pour l’instant ; pistes d’évolution :

• Éditeur Markdown : react-md-editor
• Commentaires : Giscus (GitHub Discussions)
• Recherche : Algolia ou full-text Prisma
• Mode sombre : next-themes

Prochaine étape : un éditeur Markdown pour écrire plus vite.

Ressources :

• Documentation Next.js — référence
• Documentation Prisma — Getting Started suffit
• Code complet du projet — clonez et lancez

Faire une fois vaut mieux que lire la doc dix fois. La théorie aide ; seul un projet réel ancre les compétences.

Conclusion

Ce week-end m’a appris :

1. Puissance des Server Actions : elles remplacent la plupart des API Routes
2. Typage Prisma : TypeScript complet, code plus serein
3. Flexibilité SSG/SSR : adapter la stratégie de rendu selon la page
4. Simplicité Vercel : du code à la prod en moins de 5 minutes

Le plus grand gain n’est pas technique — c’est la confiance : le full-stack n’est pas si inaccessible, à condition de s’y mettre.

Si vous voulez votre propre blog, lancez-vous. Les blocages sont normaux ; j’ai avancé doc ouverte, avec des erreurs. Voir le site en ligne compense tout.

J’espère que cet article vous fera gagner du temps. Questions en commentaires — je répondrai quand je peux.

Hâte de voir vos réalisations !