Commencer

Prêt à commencer ?

Rejoignez des milliers d'utilisateurs qui créent des choses incroyables avec notre plateforme.

Pas de carte de crédit requise

Restez informé de nos derniers articles et actualités du développement web.

Pas de spam, désabonnement à tout moment

Tailwind CSS v4 : la configuration passe dans le CSS

Fini le tailwind.config.js. La v4 déplace toute la configuration dans votre feuille de style, avec @theme, @plugin et @custom-variant.

#tailwindcss#css#frontend#design

Mike Codeur

02 août 20265 min

Design

Le changement le plus visible de Tailwind CSS v4 n'est pas une nouvelle classe utilitaire : c'est la disparition de tailwind.config.js. La configuration vit désormais dans votre CSS, et ça change la façon dont on branche un design system sur un projet.

Le nouveau point d'entrée

Là où la v3 demandait trois directives et un fichier de config JavaScript, la v4 tient sur une ligne :

@import 'tailwindcss';

Un projet v4 typique n'a plus du tout de tailwind.config.js à la racine. Si vous en gardez un après migration, c'est généralement le signe qu'il reste quelque chose à déplacer dans le CSS.

`@theme` : vos tokens deviennent des utilities

C'est le cœur de la v4. Ce que vous déclarez dans @theme sert deux fois : les variables CSS sont exposées au runtime, et Tailwind génère les classes correspondantes.

@import 'tailwindcss';

@theme {
  --color-background: var(--background);
  --color-foreground: var(--foreground);
}

Déclarer --color-background suffit à obtenir bg-background, text-background, border-background. Le nom du token dicte les utilities disponibles : le préfixe --color-* produit les classes de couleur, --spacing-* les espacements, --font-* les familles de police.

L'intérêt sur un vrai projet : vos tokens de design system ne sont plus recopiés d'un fichier JS vers du CSS. Il y a une seule déclaration, et les classes en découlent automatiquement.

Le mode sombre piloté par une variante

En v4, le dark mode par classe se déclare avec @custom-variant :

@custom-variant dark (&:is(.dark *));

Cette ligne indique que le préfixe dark: s'applique dès qu'un ancêtre porte la classe .dark. C'est exactement ce qu'il faut quand le thème est piloté par du JavaScript (un sélecteur de thème, une préférence stockée) plutôt que par la seule préférence système. Combiné à @theme, on obtient un système propre : les composants n'écrivent jamais une couleur en dur, seulement des tokens.

:root {
  --background: oklch(1 0 0);
  --foreground: oklch(0.15 0 0);
}

.dark {
  --background: oklch(0.15 0 0);
  --foreground: oklch(0.98 0 0);
}

<div class="bg-background text-foreground">
  Ce bloc suit le thème sans une seule classe dark:
</div>

Le piège classique : écrire bg-white dark:bg-slate-900 partout. Ça marche, mais chaque nouvelle couleur devient une double décision à maintenir. Passez par un token, et le mode sombre devient gratuit.

Les plugins aussi passent dans le CSS

Plus besoin de les enregistrer dans un fichier de config :

@plugin 'tailwindcss-animate';
@plugin '@tailwindcss/typography';

OKLCH par défaut

La v4 s'appuie sur oklch plutôt que sur l'hexadécimal. L'avantage est concret : la clarté est perceptuellement uniforme, donc une palette générée en faisant varier le premier paramètre reste cohérente à l'œil, ce qui n'est jamais le cas en HSL.

@theme {
  --color-primary: oklch(0.62 0.19 260);
}

L'hexadécimal continue de fonctionner. Inutile de convertir toute une palette existante le jour de la migration : faites-le quand vous retravaillez les couleurs.

Container queries intégrées

Elles ne demandent plus de plugin : un composant peut réagir à la largeur de son conteneur plutôt qu'à celle de l'écran.

<div class="@container">
  <div class="@sm:text-lg @md:flex @md:gap-6">
    Responsive selon la place disponible, pas selon la fenêtre
  </div>
</div>

C'est la bonne réponse au composant qui doit s'afficher aussi bien en pleine largeur que dans une colonne latérale étroite — un cas que les breakpoints d'écran n'ont jamais su traiter correctement.

Migrer depuis la v3

Remplacer les directives

Les trois @tailwind deviennent un unique @import 'tailwindcss'.

Déplacer le thème

Ce qui vivait dans theme.extend du fichier JS part dans @theme, sous forme de variables CSS.

Déclarer les plugins

Chaque plugin devient une ligne @plugin dans le CSS.

Redéclarer le dark mode

L'option darkMode: 'class' devient une ligne @custom-variant.

Supprimer le fichier de config

Une fois tout déplacé, tailwind.config.js n'a plus de raison d'exister.

Ce qui vivait en v3	Où ça va en v4
`theme.extend.colors`	`@theme { --color-* }`
`theme.extend.spacing`	`@theme { --spacing-* }`
`plugins: [...]`	`@plugin '...'`
`darkMode: 'class'`	`@custom-variant dark (...)`
`content: [...]`	Détection automatique

Ne migrez pas en deux fois. Une config à moitié en JS et à moitié en CSS produit des utilities absentes sans message d'erreur clair — le genre de problème qu'on met une heure à diagnostiquer pour une ligne oubliée.

À retenir

La v4 ne se contente pas de déplacer un fichier : elle supprime la frontière entre « configurer Tailwind » et « écrire du CSS ». Un design system se déclare une fois, dans une feuille de style, et alimente à la fois les variables CSS et les classes utilitaires. Pour un projet qui doit tenir dans le temps, c'est surtout une source de vérité en moins à synchroniser.

…

Écrit par

Mike Codeur

Auteur

Le nouveau point d'entrée

Là où la v3 demandait trois directives et un fichier de config JavaScript, la v4 tient sur une ligne :

@import 'tailwindcss';

Un projet v4 typique n'a plus du tout de tailwind.config.js à la racine. Si vous en gardez un après migration, c'est généralement le signe qu'il reste quelque chose à déplacer dans le CSS.

`@theme` : vos tokens deviennent des utilities

C'est le cœur de la v4. Ce que vous déclarez dans @theme sert deux fois : les variables CSS sont exposées au runtime, et Tailwind génère les classes correspondantes.

@import 'tailwindcss';

@theme {
  --color-background: var(--background);
  --color-foreground: var(--foreground);
}

L'intérêt sur un vrai projet : vos tokens de design system ne sont plus recopiés d'un fichier JS vers du CSS. Il y a une seule déclaration, et les classes en découlent automatiquement.

Le mode sombre piloté par une variante

En v4, le dark mode par classe se déclare avec @custom-variant :

@custom-variant dark (&:is(.dark *));

:root {
  --background: oklch(1 0 0);
  --foreground: oklch(0.15 0 0);
}

.dark {
  --background: oklch(0.15 0 0);
  --foreground: oklch(0.98 0 0);
}

<div class="bg-background text-foreground">
  Ce bloc suit le thème sans une seule classe dark:
</div>

Les plugins aussi passent dans le CSS

Plus besoin de les enregistrer dans un fichier de config :

@plugin 'tailwindcss-animate';
@plugin '@tailwindcss/typography';

OKLCH par défaut

@theme {
  --color-primary: oklch(0.62 0.19 260);
}

L'hexadécimal continue de fonctionner. Inutile de convertir toute une palette existante le jour de la migration : faites-le quand vous retravaillez les couleurs.

Container queries intégrées

Elles ne demandent plus de plugin : un composant peut réagir à la largeur de son conteneur plutôt qu'à celle de l'écran.

<div class="@container">
  <div class="@sm:text-lg @md:flex @md:gap-6">
    Responsive selon la place disponible, pas selon la fenêtre
  </div>
</div>

Migrer depuis la v3

Remplacer les directives

Les trois @tailwind deviennent un unique @import 'tailwindcss'.

Déplacer le thème

Ce qui vivait dans theme.extend du fichier JS part dans @theme, sous forme de variables CSS.

Déclarer les plugins

Chaque plugin devient une ligne @plugin dans le CSS.

Redéclarer le dark mode

L'option darkMode: 'class' devient une ligne @custom-variant.

Supprimer le fichier de config

Une fois tout déplacé, tailwind.config.js n'a plus de raison d'exister.

Ce qui vivait en v3	Où ça va en v4
`theme.extend.colors`	`@theme { --color-* }`
`theme.extend.spacing`	`@theme { --spacing-* }`
`plugins: [...]`	`@plugin '...'`
`darkMode: 'class'`	`@custom-variant dark (...)`
`content: [...]`	Détection automatique

Prêt à commencer ?

Newsletter

Tailwind CSS v4 : la configuration passe dans le CSS

Articles connexes

Introduction à Next.js 16

Le Proxy Component en React

Prêt à commencer ?

Newsletter

Tailwind CSS v4 : la configuration passe dans le CSS

Le nouveau point d'entrée

`@theme` : vos tokens deviennent des utilities

Le mode sombre piloté par une variante

Les plugins aussi passent dans le CSS

OKLCH par défaut

Container queries intégrées

Migrer depuis la v3

Remplacer les directives

Déplacer le thème

Déclarer les plugins

Redéclarer le dark mode

Supprimer le fichier de config

À retenir

Articles connexes

Introduction à Next.js 16

Le Proxy Component en React

Le nouveau point d'entrée

`@theme` : vos tokens deviennent des utilities

Le mode sombre piloté par une variante

Les plugins aussi passent dans le CSS

OKLCH par défaut

Container queries intégrées

Migrer depuis la v3

Remplacer les directives

Déplacer le thème

Déclarer les plugins

Redéclarer le dark mode

Supprimer le fichier de config

À retenir

Prêt à commencer ?

Newsletter

Articles connexes

Introduction à Next.js 16

Le Proxy Component en React

Prêt à commencer ?

Newsletter

Le nouveau point d'entrée

@theme : vos tokens deviennent des utilities

Le mode sombre piloté par une variante

Les plugins aussi passent dans le CSS

OKLCH par défaut

Container queries intégrées

Migrer depuis la v3

Remplacer les directives

Déplacer le thème

Déclarer les plugins

Redéclarer le dark mode

Supprimer le fichier de config

À retenir

Articles connexes

Introduction à Next.js 16

Le Proxy Component en React

Le nouveau point d'entrée

@theme : vos tokens deviennent des utilities

Le mode sombre piloté par une variante

Les plugins aussi passent dans le CSS

OKLCH par défaut

Container queries intégrées

Migrer depuis la v3

Remplacer les directives

Déplacer le thème

Déclarer les plugins

Redéclarer le dark mode

Supprimer le fichier de config

À retenir

`@theme` : vos tokens deviennent des utilities

`@theme` : vos tokens deviennent des utilities