Tailwind v4 : ce qui change concrètement pour vos projets Next.js

Tailwind CSS v4 rompt avec quatre ans de conventions : plus de fichier tailwind.config.js, plus de directives @tailwind, et un moteur de compilation entièrement réécrit en Rust. Pour les équipes qui ont construit leur stack autour de Next.js et Tailwind v3, la migration demande une heure de travail, pas une journée, à condition de comprendre ce qui change vraiment.

Le premier changement perceptible au quotidien est la vitesse. Le moteur Oxide, écrit en Rust, remplace le pipeline JavaScript qui animait les versions précédentes. Les gains varient selon la taille du projet, mais on observe régulièrement sur des bases de code de taille moyenne :

Ces chiffres ne sont pas linéaires : plus la base de code est grande, plus le gain est prononcé. Sur un monorepo avec 200 composants, on passe d'un rebuild à la limite du perceptible à quelque chose d'instantané.

La formule qui gouverne la complexité du scan de classes dans v3 était approximativement :

où $N$ est le nombre de fichiers et $C$ le nombre de classes candidates. Oxide parallélise le scan nativement, ce qui ramène la complexité effective à $O(N / \text{cores})$ dans la majorité des cas.

C'est le changement le plus structurant. Dans Tailwind v4, toute la configuration vit dans le CSS, via la directive @theme.

/* app/globals.css */
@import "tailwindcss";

@theme {
  --font-sans: "Inter", system-ui, sans-serif;
  --color-brand: oklch(55% 0.2 250);
  --color-brand-dark: oklch(42% 0.2 250);
  --spacing-18: 4.5rem;
  --radius-card: 1rem;
}

Ces variables CSS sont automatiquement exposées comme utilitaires : text-brand, bg-brand-dark, p-18, rounded-card. Elles restent aussi accessibles comme variables CSS natives dans n'importe quel fichier.

Le fichier tailwind.config.js reste supporté via le package @tailwindcss/vite pour la compatibilité ascendante, mais il n'est plus nécessaire pour les nouveaux projets.

Tailwind v4 abandonne le plugin PostCSS au profit d'un plugin Vite dédié. Next.js 15 et 16 utilisent Turbopack en mode dev, ce qui nécessite une configuration spécifique.

pnpm add tailwindcss @tailwindcss/vite
pnpm remove autoprefixer postcss

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  experimental: {
    turbopack: true,
  },
};

export default nextConfig;

/* app/globals.css — avant (v3) */
@tailwind base;
@tailwind components;
@tailwind utilities;

/* app/globals.css — après (v4) */
@import "tailwindcss";

Au-delà de la configuration, Tailwind v4 introduit des utilitaires qui faisaient défaut en v3.

Container queries natives

Les container queries permettent de styler un composant en fonction de la taille de son conteneur, pas de la fenêtre. En v3, cela nécessitait le plugin @tailwindcss/container-queries. En v4, c'est intégré :

export function Card({ children }: { children: React.ReactNode }) {
  return (
    <div className="@container">
      <div className="grid grid-cols-1 @md:grid-cols-2 @lg:grid-cols-3 gap-4">
        {children}
      </div>
    </div>
  );
}

Ce composant adapte sa grille à sa propre largeur, pas à celle de la page. Un même composant Card peut afficher une colonne dans une sidebar et trois colonnes en pleine page, sans aucun JavaScript.

Transformations 3D et variant not-

{/* Rotation 3D au survol */}
<div className="hover:[transform:rotateY(180deg)] transition-transform duration-500">
  {/* carte qui se retourne */}
</div>

{/* Variant not- : styles sur tout sauf l'état actif */}
<a className="not-[.active]:opacity-60 hover:opacity-100">
  Lien de navigation
</a>

Ces deux ajouts évitent des contournements en CSS personnalisé qui polluaient les projets v3.

La migration d'un projet Next.js de Tailwind v3 vers v4 suit un chemin prévisible. On peut la modéliser comme une séquence d'étapes à coût fixe :

En pratique, sur un projet de taille standard (50 à 150 composants), chaque étape prend 10 à 20 minutes. La migration complète se fait en moins d'une demi-journée.

# Étape 1 : mise à jour des dépendances
pnpm remove tailwindcss autoprefixer postcss
pnpm add tailwindcss@latest @tailwindcss/vite@latest

# Étape 2 : supprimer postcss.config.js et tailwind.config.ts
rm postcss.config.js tailwind.config.ts

# Étape 3 : remplacer les directives dans globals.css
# @tailwind base; @tailwind components; @tailwind utilities;
# → @import "tailwindcss";

# Étape 4 : déplacer le thème dans @theme {}
# (couleurs, fonts, spacing personnalisés)

# Étape 5 : vérifier les plugins tiers et lancer le build
pnpm build

La documentation officielle Tailwind v4 et le guide de migration détaillent les cas limites, notamment la gestion des préfixes et des variants personnalisés. La RFC initiale sur GitHub explique les choix d'architecture du moteur Oxide.

Tailwind v4 n'est pas une refonte cosmétique. Le moteur Oxide réduit les temps de build de façon mesurable dès les projets de taille moyenne. La configuration CSS-first rapproche le framework des standards natifs de la plateforme. Les container queries et les nouvelles primitives réduisent la quantité de CSS personnalisé à maintenir.

Chez Kreio, tous les nouveaux projets Next.js démarrent sur Tailwind v4 depuis février 2026. La migration des projets existants se planifie au cas par cas, en priorité sur les projets avec des builds lents ou des plugins PostCSS qui créent de la friction.

1. Tailwind CSS v4 — Documentation officielle
2. Guide de migration Tailwind v3 vers v4
3. RFC : Architecture du moteur Oxide (GitHub)