Tailwind CSS v4 : le guide complet 2026

Tailwind CSS v4 est la version qui paraît enfin native à la plateforme web moderne. L'ancien tailwind.config.js a disparu, le moteur est réécrit en Rust, et votre système de design vit désormais là où il doit être : dans votre CSS. Si vous repoussez la mise à niveau parce que la v3 « fonctionne encore », 2026 est l'année du saut. Ce guide explique ce qui change, pourquoi cela compte, et comment migrer sans casser votre build.

Pourquoi v4 est une vraie réécriture, pas un simple incrément

Le titre, c'est le moteur Oxide — le cœur de Tailwind reconstruit en Rust, avec Lightning CSS pour seule dépendance. Ce n'est pas du marketing. Les chiffres sont spectaculaires :

Les builds complets passent d'environ 378 ms à près de 100 ms (environ 3,8x plus rapide)
Les rebuilds incrémentaux avec nouveau CSS passent de 44 ms à 5 ms (8,8x plus rapide)
Les builds incrémentaux sans changement CSS s'achèvent en environ 192 microsecondes — un gain de 182x sur la v3

Pour une grande bibliothèque de composants ou un monorepo, cette différence transforme une pause de rechargement perceptible en quelque chose que l'on cesse de remarquer. L'ancien pipeline PostCSS a disparu ; Lightning CSS gère l'analyse, les préfixes vendeurs et le regroupement des @import en une seule passe.

Configuration CSS-first avec @theme

Le plus grand changement conceptuel est le déplacement de la configuration depuis JavaScript vers CSS. Il n'y a plus de tailwind.config.js par défaut. À la place, vous importez Tailwind et déclarez vos tokens de design dans un bloc @theme :

@import "tailwindcss";
 
@theme {
  --font-display: "Satoshi", "sans-serif";
  --breakpoint-3xl: 1920px;
  --color-brand-100: oklch(0.97 0.02 250);
  --color-brand-500: oklch(0.62 0.18 250);
  --color-brand-900: oklch(0.32 0.10 250);
  --ease-snappy: cubic-bezier(0.2, 0, 0, 1);
}

Chaque token défini devient à la fois une vraie propriété CSS personnalisée et une utility générée. La couleur ci-dessus vous donne bg-brand-500, text-brand-100, border-brand-900, etc., sans aucun câblage supplémentaire. Comme les tokens sont aussi exposés en variables :root, vous y accédez depuis des styles inline, des bibliothèques d'animation ou du CSS pur :

<div style="font-family: var(--font-display);">Police d'affichage</div>

Ce seul changement supprime toute une catégorie de friction. Votre palette de couleurs, vos polices, vos breakpoints et vos courbes d'easing ne sont plus prisonniers d'un objet JS que seul Tailwind sait lire — ils deviennent du CSS de première classe que toute la plateforme comprend.

Fini le tableau content

En v3, il fallait lister chaque chemin de template dans un tableau content pour que l'étape de purge sache où chercher. En v4, ce tableau a disparu. Le moteur détecte automatiquement vos fichiers de template selon la structure du projet et votre .gitignore. Quand vous devez réellement inclure un chemin hors périmètre par défaut — un package publié dans node_modules, par exemple — vous le désignez explicitement :

@import "tailwindcss";
@source "../node_modules/@my-company/ui-lib";

Moins de configuration signifie moins de bugs du type « pourquoi mes classes manquent en production », presque toujours dus à un glob content mal réglé en v3.

Des utilities dynamiques que vous ne configurez plus

La v4 génère de nombreuses utilities à la demande plutôt que depuis une échelle fixe. Besoin d'une grille à 15 colonnes ou d'une largeur inhabituelle ? Écrivez-la, tout simplement :

<div class="grid grid-cols-15 gap-4">...</div>
<div class="mt-8 w-17 pr-29">...</div>

Les utilities d'espacement dérivent toutes d'une seule variable --spacing via calc(), donc n'importe quel multiplicateur fonctionne sans entrée de config. Les variantes par attribut de données sont également dynamiques :

<div data-current class="opacity-75 data-current:opacity-100">...</div>

Les container queries sont intégrées

Les container queries nécessitaient autrefois un plugin. En v4, elles font partie du cœur. Marquez un élément comme conteneur, puis stylez ses enfants selon la largeur du conteneur plutôt que celle de la fenêtre :

<div class="@container">
  <div class="grid grid-cols-1 @sm:grid-cols-3 @lg:grid-cols-4">...</div>
</div>

Vous disposez aussi de variantes conteneur en largeur maximale et de plages empilées pour un contrôle précis :

<div class="@container">
  <div class="grid grid-cols-3 @max-md:grid-cols-1">...</div>
  <div class="flex @min-md:@max-xl:hidden">...</div>
</div>

C'est la fonctionnalité qui rend de vrais composants réutilisables possibles — une carte s'adapte à l'emplacement où elle atterrit, sans rien savoir de la mise en page de la page.

Installation en 2026

Les deux voies les plus utilisées sont le plugin Vite (le plus rapide) et PostCSS.

Vite — la configuration recommandée pour les projets React, Vue, Svelte et SolidJS :

npm i -D tailwindcss @tailwindcss/vite

import { defineConfig } from "vite";
import tailwindcss from "@tailwindcss/vite";
 
export default defineConfig({
  plugins: [tailwindcss()],
});

PostCSS — pour les builds qui le standardisent déjà :

npm i tailwindcss @tailwindcss/postcss

export default {
  plugins: ["@tailwindcss/postcss"],
};

Dans les deux cas, votre point d'entrée CSS tient en une ligne — fini les @tailwind base; @tailwind components; @tailwind utilities; :

@import "tailwindcss";

Migrer depuis v3 sans douleur

Tailwind fournit un outil de migration automatique qui prend en charge l'essentiel, y compris la conversion de votre ancienne config en CSS et le renommage des utilities dépréciées :

npx @tailwindcss/upgrade

Lancez-le sur une branche propre pour faciliter la revue du diff. Les points à vérifier à la main :

Les utilities renommées. Certaines échelles ont bougé — shadow-sm devient shadow-xs, shadow devient shadow-sm, avec des ajustements similaires sur blur, rounded et ring. Le codemod attrape la plupart, mais grepez votre base pour confirmer.
La largeur de ring par défaut passe de 3px à 1px. Si vos états de focus paraissent plus fins, ajoutez ring-3 là où vous comptiez sur l'ancienne valeur.
Les couleurs de border et divide valent désormais currentColor au lieu de gray-200. Fixez une couleur explicite si vous dépendiez du gris implicite.
Plugins et presets. Une config JS peut encore être chargée via @config "./tailwind.config.js"; pendant la transition : pas besoin de tout convertir d'un coup.

Sur un framework comme Next.js, conservez votre PostCSS existant, remplacez le plugin par @tailwindcss/postcss, et substituez les trois directives @tailwind par l'import unique. La plupart des applications buildent au vert dès le premier essai.

Faut-il migrer ?

Pour un nouveau projet en 2026, aucune raison de rester en v3. Le modèle CSS-first, la détection automatique du contenu, les container queries natives et le moteur Oxide poussent tous dans le même sens : moins de config, des builds plus rapides, et un système de design qui est du CSS pur. Pour les projets existants, la migration automatique plus une revue soignée des utilities renommées prend en général un après-midi, pas un sprint — et le gain au build se rentabilise immédiatement pour toute équipe qui recharge des dizaines de fois par heure.

Tailwind v4, c'est l'approche utility-first une fois qu'elle cesse de combattre le navigateur pour commencer à l'utiliser. Pour les équipes de la région MENA qui livrent des interfaces multilingues et compatibles RTL, la config allégée et la boucle de feedback plus rapide sont un gain de productivité direct. La mise à niveau est simple, le bénéfice réel, et l'écosystème — dont shadcn/ui et la plupart des kits de composants majeurs — a déjà fait le saut.

Vous construisez un frontend moderne et le voulez impeccable ? Noqta aide les entreprises de la région MENA à livrer des applications web rapides, accessibles et élégamment stylées. Contactez-nous.

Sources : Blog officiel Tailwind CSS, LogRocket — Guide du développeur Tailwind CSS en 2026, DEV Community — Analyse approfondie du moteur Oxide