Tailwind CSS 4 : ce qui a changé et comment migrer

01Configuration en CSS via @theme

Plus de tailwind.config.js. Les tokens (couleurs, espacements, polices, radius, breakpoints) se déclarent directement dans le CSS avec la directive @theme. C'est plus standard (CSS natif), plus accessible aux designers qui ne maîtrisent pas JavaScript, et ça permet aux Server Components de Next.js de lire les tokens sans hack. Sur nos design systems chez Krealabs, la config tient en 50 lignes de CSS pur, fini les fichiers TypeScript de 200 lignes pour configurer Tailwind.

@import "tailwindcss";

@theme {
  /* Couleurs */
  --color-accent: #8f99ed;
  --color-background: #0a0a0a;
  --color-foreground: #fafafa;

  /* Typographie */
  --font-sans: "Switzer", system-ui, sans-serif;
  --font-serif: "Instrument Serif", serif;
  --font-mono: "Geist Mono", monospace;

  /* Radius unique */
  --radius: 0.625rem;
  --radius-lg: 1rem;

  /* Breakpoints custom si besoin */
  --breakpoint-3xl: 1920px;
}

02Oxide : le moteur Rust qui change tout

Le nouveau moteur Oxide (écrit en Rust et compilé via lightningcss) scanne et compile en quelques millisecondes même sur de gros projets. Le HMR en dev est quasi instantané : on voit le changement de classe pratiquement en temps réel. Sur nos projets typiques (50-100 routes Next.js), le temps de compile en CI passe de 30s à 3-5s. Sur un monorepo de 300 fichiers, on est passé de 2 minutes à 12 secondes. C'est aussi une bonne nouvelle pour les développeurs sur des machines moins puissantes : le compile Tailwind n'est plus un goulot d'étranglement.

03Auto-détection des fichiers

Plus besoin de configurer la propriété 'content' avec des glob patterns. Tailwind 4 scanne automatiquement tous les fichiers de votre projet (sauf .gitignore et node_modules). Cela élimine une source classique de bugs : oublier d'ajouter un dossier au content, et observer des classes qui disparaissent en production sans raison apparente. Si vous avez vraiment besoin d'exclure ou inclure des fichiers spécifiques, la directive @source dans votre CSS permet de surcharger.

04Nouvelles fonctionnalités CSS

Tailwind 4 expose plein de nouveautés modernes : container queries natives (@container), color-mix() pour combiner des couleurs (utile pour les hover states), conic-gradient et radial-gradient en utilities, accent-color pour styliser les checkboxes/radios, et un meilleur support des subgrid CSS. La directive @variant permet de créer ses propres variantes (genre @variant hover-and-focus). Le système de couleurs est aussi modernisé avec les color spaces P3 (display-p3) supportés nativement.

/* Variantes custom */
@variant hover-and-focus (&:hover, &:focus-visible);

/* Container queries */
<div className="@container">
  <div className="@md:flex @lg:grid-cols-3">...</div>
</div>

/* Color-mix pour hover */
<button className="bg-accent hover:bg-[color-mix(in_oklab,var(--color-accent)_80%,white)]">

05Pièges classiques de la migration

Si vous utilisez @apply massivement, attention : Tailwind 4 le décourage (et il est plus lent qu'avant). Préférez les classes utilitaires inline ou les variantes de composants via cva. Les plugins JavaScript existants (tailwindcss-animate, typography, forms) ne sont pas tous compatibles — vérifier la doc officielle de chacun avant la mise à jour. Le scan automatique de fichiers peut détecter des classes en commentaires ou dans des chaînes de caractères inattendues (logs, JSON) — vérifier que rien n'arrive en prod par erreur. Les modes JIT et Just-In-Time ne sont plus configurables car c'est le mode par défaut.

06Migration de Tailwind 3 vers 4 : le pas-à-pas

Étape 1 : `npx @tailwindcss/upgrade` lance l'outil de migration officiel qui convertit tailwind.config.js en @theme et met à jour la plupart des classes obsolètes. Étape 2 : audit manuel des plugins (vérifier compatibilité). Étape 3 : tester en local avec un build production complet pour repérer les classes manquantes. Étape 4 : tester visuellement chaque page critique. Étape 5 : déployer en preview Vercel et comparer avant/après. Comptez 1 jour pour un projet de taille moyenne (50 fichiers), 2-3 jours pour un gros projet avec des plugins custom.

07Performance build : les chiffres concrets

Sur le projet Krealabs (~250 fichiers TSX, 35 routes prerendered) : temps de build Tailwind 3 = ~12s, Tailwind 4 = ~1.8s (factor 6.6x). Dev server cold start avec Turbopack : 3-4s contre 8-10s avant. Hot reload : pratiquement imperceptible (<50ms). Sur les projets clients de plus grande taille (1000+ fichiers), les gains sont encore plus marqués. À noter : le CSS final est aussi plus petit (~10-15% en moyenne) grâce à un meilleur tree-shaking et une compression Oxide.