Tailwind CSS a changé la façon de styliser les sites, au point que la question ne se pose plus vraiment chez les développeurs : en 2026 il domine les projets React, Next.js et Astro. La vraie question, celle qui intéresse quelqu’un qui paie un site plutôt que celui qui l’écrit, c’est ce que ce choix coûte en maintenance et en dépendance.
À retenir. Le CSS classique sépare le style du HTML, Tailwind le met dedans. Aucun des deux n’est meilleur en soi : le CSS classique gagne quand vous ne contrôlez pas le HTML, Tailwind gagne dès qu’il y a des composants. Et si vous ne codez pas, le seul critère qui vous concerne est celui-ci : les deux sont des standards repris facilement par un autre prestataire, ce qui n’est pas le cas d’un thème propriétaire.
La différence, en deux blocs de code
Le même bouton, écrit des deux façons. C’est tout le débat, et il tient en dix lignes.
.btn-primary {
padding: 0.5rem 1rem;
border-radius: 0.5rem;
background: #2563eb;
color: white;
font-weight: 600;
}
.btn-primary:hover {
background: #1d4ed8;
}<button class="px-4 py-2 rounded-lg bg-blue-600 text-white font-semibold hover:bg-blue-700">
Envoyer
</button>Dans le premier cas, le style vit dans un fichier à part et le HTML reste lisible. Dans le second, tout est sous les yeux au même endroit et il n’y a plus de nom de classe à inventer. Le reste de cet article découle de cette seule différence.
CSS classique : ce qu’il fait gagner et perdre
Le CSS traditionnel sépare le style du HTML. Vous créez des classes sémantiques, `.card`, `.btn-primary`, et vous écrivez les règles dans des fichiers `.css` séparés. C’est le fonctionnement natif du navigateur, celui qui n’a besoin de rien d’autre.
Avantages du CSS classique
- HTML propre : le balisage reste lisible et sémantique, ce qui compte quand quelqu’un d’autre reprend le fichier.
- Réutilisation immédiate : une classe égale un style appliqué partout, sans passer par un composant.
- Aucune dépendance : pas d’outil de compilation, pas de version à suivre, le fichier marche tel quel dans dix ans.
- Contrôle total : vous écrivez exactement ce dont vous avez besoin, ni plus ni moins.
Inconvénients du CSS classique
- Les fichiers grossissent, et personne n’ose supprimer une règle dont il ignore où elle sert encore.
- Le nommage est un métier à lui seul. BEM, OOCSS, SMACSS existent précisément parce que nommer les choses est difficile.
- Le CSS mort s’accumule : les classes d’une section supprimée il y a deux ans sont toujours téléchargées par vos visiteurs.
- Les allers-retours entre le HTML et le CSS ralentissent, surtout sur un projet qu’on ne connaît pas par cœur.
Tailwind : ce qu’il fait gagner et perdre
Tailwind propose des classes utilitaires atomiques : une classe, une propriété. Le framework ne livre pas une feuille de style figée, il génère le CSS à partir des classes réellement utilisées en analysant vos fichiers. C’est ce qui explique la plupart de ses avantages, et son principal inconvénient.
La version 4, sortie début 2025 et arrivée en 4.3 courant 2026, a changé le moteur. La compilation passe par Oxide, en partie écrite en Rust : l’équipe annonce une construction de son propre site en 105 ms contre 960 ms auparavant, une installation 35 % plus légère, et une configuration qui se fait désormais en CSS plutôt qu’en JavaScript.
Avantages de Tailwind
- Développement rapide : pas besoin de quitter le fichier, ni d’inventer un nom de classe pour un bouton qui ne servira qu’une fois.
- Pas de CSS mort : seules les classes présentes dans le code produisent du CSS, donc la feuille ne peut pas gonfler avec des règles orphelines.
- Système de design intégré : les espacements, les couleurs et les tailles viennent d’une échelle commune, ce qui empêche les vingt-trois nuances de gris d’un projet mal tenu.
- Responsive et thème sombre par préfixe : `md:flex`, `dark:bg-gray-800`, sans écrire une seule requête média.
Inconvénients de Tailwind
- Le balisage devient verbeux. Un bouton peut porter douze classes, et une relecture rapide du HTML devient pénible.
- Il faut apprendre le vocabulaire. Quelques jours pour être à l’aise, et cette connaissance ne se transpose pas ailleurs.
- Un outil de compilation est obligatoire. Sans lui, aucune classe ne produit de style, ce qui exclut les contextes où l’on ne peut rien compiler.
- Les cas très spécifiques restent verbeux, et il faut alors passer par la syntaxe entre crochets, moins lisible.
Le comparatif, critère par critère
| Critère | CSS classique | Tailwind |
|---|---|---|
| Outil de compilation | aucun | obligatoire |
| Lisibilité du HTML | bonne | dégradée |
| Poids du CSS livré | croît avec le projet | proportionnel aux classes utilisées |
| Cohérence visuelle | à tenir à la main | imposée par l’échelle |
| Reprise par un tiers | immédiate | quelques heures d’acclimatation |
| Vous ne contrôlez pas le HTML | seule option viable | inutilisable |
| Projet à composants | duplication de nommage | terrain naturel |
Ce que ça change pour vous si vous ne codez pas
C’est la partie que les comparatifs oublient, alors que c’est la seule qui vous engage. Trois conséquences concrètes.
La reprise par un autre prestataire. Les deux approches sont des standards publics, documentés, connus de dizaines de milliers de développeurs. Ce n’est pas le cas d’un thème propriétaire ou d’un constructeur visuel, où la reprise suppose d’acheter la même licence et d’apprendre un outil fermé. Sur ce critère, le débat Tailwind contre CSS classique est un faux débat : les deux vous laissent libre.
Le coût des modifications. Sur un site à composants, changer la couleur d’accent se fait à un seul endroit dans les deux cas. Sur un site où le style a été écrit page par page, ce qui arrive plus souvent qu’on ne l’avoue, Tailwind rend la modification plus rapide parce que la valeur est là où on la lit.
La performance perçue. Elle se joue ailleurs : images non optimisées, polices bloquantes, scripts tiers. Le poids du CSS est rarement le problème d’un site vitrine, et choisir Tailwind pour gagner quelques kilo-octets serait choisir pour la mauvaise raison.
L’approche hybride, et le piège de @apply
Rien n’empêche de combiner les deux, et c’est ce que je fais sur la plupart des projets : Tailwind pour la mise en page et les utilitaires, du CSS écrit à la main pour les quelques endroits qui le demandent.
Une correction par rapport à la première version de cet article, où je conseillais `@apply` pour les composants répétés. La documentation officielle ne recommande pas cette voie : face à la duplication, elle propose d’abord les boucles, l’édition multi-curseur, puis les composants ou les partiels de gabarit, et ne mentionne le CSS écrit à la main que lorsqu’un partiel serait disproportionné pour un simple bouton (documentation Tailwind, gestion de la duplication, relevée le 1er septembre 2026). En pratique, `@apply` recrée le problème que Tailwind résout : une couche d’indirection entre ce que vous lisez et ce qui s’applique.
La question qui tranche
Contrôlez-vous le HTML ? Si oui, et s’il y a des composants, Tailwind. Si non, parce que le balisage vient d’un CMS, d’un module tiers ou d’un courriel, CSS classique, sans hésiter.
Le reste, la courbe d’apprentissage, la verbosité, les préférences de chacun, se discute mais ne décide pas. Et ce choix vient après celui du framework, qui a bien plus d’effet sur le résultat : voir Next.js contre Astro si la question est encore ouverte.
Questions fréquentes
Tailwind ralentit-il mon site ?
Non, plutôt l’inverse. Comme le CSS est généré à partir des classes réellement présentes, la feuille livrée ne contient rien d’inutile. Sur un site vitrine, elle pèse généralement moins qu’un fichier CSS écrit à la main et jamais nettoyé.
Un autre développeur pourra-t-il reprendre un site en Tailwind ?
Oui. C’est un standard largement diffusé, la documentation est publique et la syntaxe s’apprend en quelques heures pour quelqu’un qui connaît le CSS. Le vrai risque de dépendance ne vient jamais du framework de style, il vient des thèmes propriétaires et des constructeurs visuels.
Faut-il migrer un site existant vers Tailwind ?
Rarement pour le seul plaisir de migrer. Une migration de style coûte des jours et n’apporte rien de visible à vos visiteurs. Elle se justifie quand elle accompagne une refonte déjà décidée pour d’autres raisons, pas comme projet en soi.
En résumé
Tailwind n’est pas meilleur que le CSS classique, c’est un outil différent pour un contexte différent. Il domine les projets à composants, le CSS classique reste la seule option quand le balisage vous échappe, et les deux vous laissent libre de changer de prestataire. Si vous n’écrivez pas le code vous-même, c’est ce dernier point qui compte, et il est vrai dans les deux cas.
Sources relevées le 1er septembre 2026 : documentation Tailwind, styliser avec des classes utilitaires et annonce du moteur Oxide par l’équipe Tailwind.
