Tailwind CSS v4 : nouveautés et migration depuis v3

Tailwind CSS v4 est sorti en janvier 2025 et représente la plus grande refonte depuis la création du framework. Si vous avez un projet Next.js en production avec Tailwind v3, vous vous êtes probablement demandé : est-ce que ça vaut le coup de migrer ? Spoiler : oui, et voici pourquoi.

Ce qui change vraiment dans Tailwind v4

La v4 n'est pas une simple mise à jour incrémentale. C'est une réécriture profonde du moteur de génération des classes CSS, basée sur CSS natif plutôt que sur PostCSS.

Un moteur de build totalement nouveau

Le moteur de Tailwind v4, baptisé Oxide, est réécrit en Rust (via Lightning CSS). Résultat : des temps de compilation drastiquement réduits.

Sur un projet de taille moyenne :

Full build : de ~3s à moins de 100ms
Rebuild incrémental : quasi-instantané

Ce gain est immédiatement perceptible dans votre DX lors du développement.

Plus de fichier `tailwind.config.js`

C'est le changement qui dérange le plus au premier abord, mais il est en réalité très logique. En v4, la configuration se fait directement dans le CSS :

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

@theme {
  --color-brand: #6366f1;
  --font-sans: "Inter", sans-serif;
  --radius-lg: 1rem;
}

Fini le fichier JavaScript avec extend, theme, etc. Tout passe par des variables CSS custom sous le namespace --tw-* et @theme.

Les variables CSS comme source de vérité

En v4, chaque token de design est exposé en tant que variable CSS native. Vous pouvez donc les utiliser directement dans votre CSS arbitraire ou dans des animations custom :

.my-component {
  background: var(--color-brand);
  border-radius: var(--radius-lg);
}

Et les classes Tailwind continuent de fonctionner exactement comme avant :

<div class="bg-brand rounded-lg text-white px-4 py-2">
  Bouton custom
</div>

Nouvelle syntaxe pour les variantes

La gestion des variantes (hover, focus, dark mode…) devient plus expressive. Vous pouvez désormais composer des variantes comme des fonctions :

<!-- v3 -->
<div class="dark:hover:bg-gray-800">...</div>

<!-- v4 : identique, mais avec support de variantes arbitraires plus puissant -->
<div class="group-hover/sidebar:opacity-100">...</div>

Les variantes nommées (group/sidebar, peer/input) existaient en v3, mais sont maintenant beaucoup plus robustes.

Ce qui disparaît (ou change) en v4

Les plugins JS

Les plugins écrits en JavaScript (via tailwind.config.js) doivent être réécrits en CSS avec les nouvelles directives @plugin. C'est un breaking change à anticiper si vous utilisez des plugins tiers.

/* Équivalent d'un plugin v3 en v4 */
@plugin "tailwindcss-animate";

La plupart des plugins populaires ont déjà publié une version compatible v4.

Quelques classes renommées

Quelques utilitaires ont été renommés pour plus de cohérence :

v3	v4
`shadow-sm`	`shadow-xs`
`shadow`	`shadow-sm`
`blur`	`blur-sm`
`rounded`	`rounded-sm`

Le CLI de migration gère ces renommages automatiquement (voir section suivante).

`@tailwind base/components/utilities` est remplacé

/* v3 */
@tailwind base;
@tailwind components;
@tailwind utilities;

/* v4 */
@import "tailwindcss";

Une seule ligne suffit désormais.

Migrer de v3 à v4 avec le CLI officiel

Tailwind fournit un outil de migration automatique qui couvre 90% des cas :

npx @tailwindcss/upgrade@latest

Ce script va :

Mettre à jour vos dépendances (tailwindcss, @tailwindcss/vite ou @tailwindcss/postcss)
Convertir votre tailwind.config.js en directives CSS @theme
Renommer les classes dépréciées dans vos fichiers
Mettre à jour vos imports CSS

Avec Next.js (App Router)

L'intégration recommandée avec Next.js utilise désormais le plugin Vite (ou le plugin PostCSS si vous restez sur Webpack) :

npm install tailwindcss @tailwindcss/postcss

// postcss.config.js
module.exports = {
  plugins: {
    "@tailwindcss/postcss": {},
  },
};

Et dans votre globals.css :

@import "tailwindcss";

@theme {
  /* vos tokens ici */
}

Next.js détecte automatiquement la configuration PostCSS, aucune modification de next.config.ts n'est requise.

Vaut-il mieux migrer maintenant ?

Pour un nouveau projet : absolument. La v4 est stable, rapide, et la configuration CSS-first est plus intuitive une fois qu'on y est habitué.

Pour un projet existant : le CLI de migration facilite beaucoup la transition. Si vous avez peu de plugins custom, la migration peut se faire en moins d'une heure. Si vous avez beaucoup de personnalisations JS dans votre config, prévoyez un peu plus de temps pour réécrire les plugins en CSS.

Dans les deux cas, le gain en performance de build et la simplification de la configuration valent largement l'effort.

Conclusion

Tailwind CSS v4 marque un tournant : moins de configuration JavaScript, plus de CSS natif, et un moteur de build bien plus rapide. La courbe d'apprentissage est faible pour quiconque connaît déjà Tailwind, et les breaking changes sont gérés efficacement par l'outil de migration officiel.

Si vous démarrez un nouveau projet Next.js aujourd'hui, partez directement sur Tailwind v4. Vous éviterez une migration future et profiterez d'une meilleure DX dès le premier jour.

Vous avez un projet web à démarrer ou à moderniser ? N'hésitez pas à me contacter — je peux vous accompagner de l'architecture jusqu'au déploiement, avec une stack moderne et pensée pour durer.