Tailwind v4 : les nouveautés qui changent tout

Tailwind v4 n'est pas une mise à jour, c'est un changement de nature. La v3 était un outil JavaScript qui écrivait du CSS. La v4 est du CSS qui utilise les capacités du navigateur. Cela se voit dès le premier fichier.

Ce site tourne sur Tailwind 4.3. Voici ce qui a réellement changé dans notre travail quotidien.

Le fichier de configuration a disparu

En v3, votre palette, vos polices et vos points de rupture vivaient dans tailwind.config.js — un fichier JavaScript, invisible depuis une feuille de style, qu'il fallait relire pour comprendre d'où venait une couleur.

En v4, ce fichier n'existe plus. Le nôtre a été remplacé par un bloc @theme dans le CSS :

@import 'tailwindcss';

@theme {
  --color-ink: #0e0e0c;
  --color-bone: #f2ebdb;
  --color-acid: #ccff33;
  --color-rust: #e94e1b;

  --font-display: 'Fraunces', 'Times New Roman', serif;
  --font-sans: 'Geist', system-ui, sans-serif;
}

Trois conséquences immédiates :

1. Une seule ligne d'import remplace les trois anciennes directives @tailwind base, @tailwind components et @tailwind utilities.
2. Chaque valeur devient une variable CSS native. --color-acid est utilisable dans une classe Tailwind (bg-acid) et dans du CSS écrit à la main (var(--color-acid)). En v3, ces deux mondes ne se parlaient pas sans plugin.
3. Vos jetons sont lisibles à l'exécution. Un composant peut lire une couleur du thème depuis JavaScript, ce qui était impossible quand elle était compilée dans un fichier de configuration.

Nous nous en servons pour composer des couleurs dérivées directement dans le thème :

--color-ink-soft: color-mix(in srgb, var(--color-ink) 68%, var(--color-bone));

Cette ligne n'aurait pas eu de sens en v3.

PostCSS n'est plus au milieu

Notre projet ne contient ni tailwind.config.js, ni postcss.config.js. Le plugin Vite officiel (@tailwindcss/vite) suffit. Le nouveau moteur est écrit en Rust, et la construction de nos 219 pages, feuilles de style comprises, prend un peu plus de six secondes.

Moins de fichiers de configuration signifie moins d'endroits où un comportement peut se cacher. Sur un projet repris deux ans plus tard, c'est ce qui coûte le plus cher.

Le prix à payer : le navigateur

C'est le point que les annonces passent sous silence. Tailwind v4 s'appuie sur des fonctionnalités CSS modernes : @property, color-mix(), les couches en cascade (@layer). Concrètement, cela signifie Safari 16.4, Chrome 111 et Firefox 128 au minimum.

Si votre audience comprend des postes d'entreprise verrouillés sur d'anciennes versions — cas fréquent dans l'industrie et l'administration —, vérifiez vos statistiques avant de migrer. Il n'y a pas de repli automatique : sur un navigateur trop ancien, la mise en page ne se dégrade pas, elle casse.

Pour un site grand public en 2026, la question est réglée. Pour un intranet, elle mérite cinq minutes d'analyse.

Ce qui change concrètement dans le travail

• Les valeurs arbitraires reculent. Quand un jeton est une variable CSS, bg-[#ccff33] devient inutile : on écrit bg-acid, et la couleur reste modifiable en un seul endroit.
• La frontière entre Tailwind et CSS écrit à la main s'efface. Nos composants Astro mélangent des classes utilitaires et des blocs <style> scopés qui consomment les mêmes variables. Plus de duplication de palette.
• La migration depuis la v3 est réelle. L'outil npx @tailwindcss/upgrade fait le gros du travail, mais les plugins tiers et les configurations élaborées demandent une reprise manuelle. Comptez une demi-journée sur un projet de taille moyenne, pas dix minutes.

Faut-il migrer ?

Nouveau projet : oui, sans discussion.

Projet existant en v3 qui fonctionne : rien ne presse. La v3 continue de fonctionner. Le bon moment est celui d'une refonte visuelle, quand vous alliez de toute façon retoucher la palette.

Projet avec beaucoup de plugins tiers : vérifiez d'abord leur compatibilité v4. C'est là que se cachent les mauvaises surprises, pas dans le cœur de l'outil.