Comment configure-t-on Tailwind CSS 4 ?

La configuration migre dans le CSS : plus besoin de tailwind.config.js pour la majorité des projets, les tokens et overrides se déclarent directement via @theme. Toutes les valeurs deviennent des CSS variables natives.

Quels navigateurs Tailwind CSS 4 prend-il en charge ?

Tailwind 4 cible Safari 16.4+, Chrome 111+ et Firefox 128+. Les navigateurs plus anciens ne sont plus supportés, car le framework s'appuie sur @property, color-mix() et les cascade layers.

Tailwind CSS 4 : ce qui change vraiment

Q: Qu'est-ce qui change avec le moteur de Tailwind CSS 4 ?

Le moteur est entièrement réécrit (mélange de Rust et de TypeScript) : les builds complets sont environ 3,5 fois plus rapides et les builds incrémentaux peuvent être plus de 100 fois plus rapides, souvent sous les 5 ms en dev.

📚 Introduction

Tailwind 3 était déjà rapide. Tailwind 4 redéfinit ce qu’on appelle “rapide”. L’équipe a entièrement réécrit le moteur en Rust, repensé le pipeline d’intégration aux bundlers modernes (Vite en tête), et déplacé la configuration depuis JavaScript vers… du CSS.

Sur mon site, l’upgrade Tailwind 3 → 4 s’est faite presque sans douleur. Mais derrière l’apparente continuité, beaucoup de choses bougent en coulisses. Voici ce qu’il faut retenir.

⚡ Un nouveau moteur, vraiment

Tailwind v4 introduit un moteur entièrement réécrit, mélange de Rust et de TypeScript optimisé : selon l’équipe, les builds complets sont environ 3,5 fois plus rapides, et les builds incrémentaux peuvent être plus de 100 fois plus rapides (souvent en dessous des 5 ms en dev). Concrètement, sur un projet de taille moyenne :

les rebuilds incrémentaux passent largement sous la barre des 50 ms ;
la détection automatique des sources scanne le projet sans avoir à configurer la liste des chemins (content n’est plus nécessaire dans la majorité des cas) ;
les templates Astro, MDX et Blade sont pris en compte par défaut.

Sur les projets multi-paquets en mono-repo, l’écart se creuse encore : le nouveau moteur ne re-scanne pas les fichiers inchangés, ce qui change radicalement l’expérience en local.

🧩 La configuration migre dans le CSS

C’est le changement le plus visible côté code. Plus besoin de tailwind.config.js pour la majorité des projets : les tokens et les overrides se déclarent directement dans le CSS via @theme :

@import 'tailwindcss';
 
@theme {
	--font-display: 'Noto Sans Variable', sans-serif;
	--color-brand: oklch(72% 0.18 156);
	--breakpoint-3xl: 1920px;
}

L’avantage est double : la configuration est visible dans les DevTools, et toutes les valeurs sont des CSS variables natives, donc accessibles partout en runtime, modifiables à la volée et compatibles avec les thèmes dynamiques.

🔌 Intégration Vite officielle

Tailwind 4 expose un plugin Vite natif. Plus besoin de PostCSS pour la majorité des projets :

// vite.config.js
import { defineConfig } from 'vite';
import tailwindcss from '@tailwindcss/vite';
 
export default defineConfig({
	plugins: [tailwindcss()]
});

Pour Astro (5.2+), une seule commande suffit :

npx astro add tailwind

… qui installe @tailwindcss/vite, l’enregistre dans vite.plugins, et crée un src/styles/global.css avec @import "tailwindcss";. L’ancienne intégration @astrojs/tailwind reste disponible mais uniquement pour Tailwind 3 (mode legacy).

C’est un soulagement pour qui galérait avec les versions de postcss, autoprefixer et les plugins concurrents qui se marchaient dessus.

🆕 Quelques nouveautés concrètes

@custom-variant pour déclarer ses propres variantes en CSS, sans plugin JS (et @variant pour les appliquer dans un sélecteur custom).
Container queries intégrées (@container, variantes @sm:, @lg:…) sans plugin externe.
Color spaces modernes : OKLCH utilisé par défaut pour la palette, gradients en P3, et tokens couleur exposés en CSS variables.
text-shadow-* disponibles nativement (sans plugin tiers).
field-sizing-* pour les textarea qui s’auto-redimensionnent au contenu.
inset-shadow-* et inset-ring-* pour empiler ombres internes et bordures internes proprement.

C’est l’accumulation de ces petites améliorations qui rend l’écosystème plus agréable au quotidien, surtout pour ceux qui aiment écrire le moins de CSS personnalisé possible.

⚠️ Quelques points de friction

Pré-requis navigateurs modernes : Tailwind 4 cible Safari 16.4+, Chrome 111+ et Firefox 128+. Les navigateurs plus anciens ne sont plus supportés (besoin de @property, color-mix() et de cascade layers).
Les plugins Tailwind 3 ne sont pas tous compatibles. @tailwindcss/typography se déclare désormais via @plugin '@tailwindcss/typography'; dans le CSS ; vérifiez vos plugins communautaires avant de migrer.
La documentation a évolué : si vous cherchez « comment configurer X », assurez-vous de lire la doc Tailwind 4, pas les vieux posts de blog qui décrivent encore l’ancien fichier de config JS.
Les snippets générés par certains LLM peuvent encore citer la syntaxe v3 (tailwind.config.js, theme.extend, etc.). Un quick check des classes et directives s’impose.

🎉 Conclusion

Tailwind 4, c’est moins de configuration JavaScript, plus de CSS standard, et un build qui suit enfin la cadence des outils modernes (Vite, Bun, esbuild). L’ergonomie au quotidien y gagne franchement.

Pour un projet existant en v3, comptez quelques heures de migration et un test sérieux des plugins utilisés. Pour un projet greenfield, il n’y a plus aucune raison de commencer en v3.

🎨 Tailwind CSS 4 : ce qui change vraiment au quotidien