Tailwind CSS : le guide pratique
Tailwind CSS a profondément changé la façon dont beaucoup de développeurs écrivent leurs styles. Fini les longues feuilles CSS séparées et les noms de classes à inventer : avec Tailwind, on stylise directement dans le HTML à l’aide de petites classes utilitaires. Cette approche déroute au premier regard, puis devient souvent difficile à quitter. Ce guide pratique explique le concept utility-first, la mise en place, les classes courantes, le responsive, la personnalisation, ainsi que les avantages et les limites.
Le concept : l’approche utility-first
Le CSS traditionnel consiste à créer une classe sémantique (.carte, .bouton-principal) puis à définir ses styles dans un fichier .css. Tailwind propose l’inverse : un grand catalogue de classes utilitaires, chacune faisant une seule chose. p-4 ajoute du padding, text-center centre le texte, bg-blue-500 applique un fond bleu.
On compose alors le style d’un élément en assemblant ces briques directement dans le balisage :
<button class="bg-blue-500 text-white px-4 py-2 rounded hover:bg-blue-600">
Envoyer
</button>
À gauche les sceptiques y voient du « HTML surchargé ». À droite les adeptes soulignent qu’on ne quitte plus jamais son fichier de composant, qu’on n’invente plus de noms de classes, et que le style reste cohérent grâce à une échelle de valeurs prédéfinie (espacements, couleurs, tailles de police).
Mettre Tailwind en place
L’installation se fait via npm, typiquement dans un projet moderne. Voici une mise en place classique :
npm install tailwindcss @tailwindcss/cli
Vous importez ensuite Tailwind dans votre fichier CSS principal :
@import "tailwindcss";
Enfin, vous lancez le processus de compilation, qui scanne vos fichiers et génère uniquement le CSS effectivement utilisé :
npx @tailwindcss/cli -i ./src/input.css -o ./dist/output.css --watch
C’est un point clé : Tailwind ne livre pas des mégaoctets de CSS. Grâce au tree-shaking, seules les classes réellement présentes dans votre code se retrouvent dans le fichier final. Le CSS produit reste donc léger, même avec un catalogue immense à disposition. La plupart des frameworks (Astro, Next.js, Vite) proposent une intégration officielle qui automatise cette étape.
Les classes courantes à connaître
Le vocabulaire de Tailwind est logique et vite mémorisé. Voici les familles les plus utilisées.
Espacements — p pour padding, m pour margin, suivis d’une direction et d’une valeur :
p-4: padding sur tous les côtés.px-6: padding horizontal ;py-2: padding vertical.mt-8: margin en haut ;mb-4: margin en bas.
Typographie :
text-lg,text-2xl: taille du texte.font-bold,font-medium: graisse.text-center,text-gray-700: alignement et couleur.
Couleurs — un fond avec bg-, une couleur de texte avec text-, une bordure avec border-, chacun décliné sur une échelle de 50 à 950 : bg-red-500, text-slate-800.
Mise en page avec Flexbox et Grid :
<div class="flex items-center justify-between gap-4">
<span>Logo</span>
<nav class="flex gap-6">...</nav>
</div>
flex active Flexbox, items-center aligne verticalement, justify-between répartit l’espace, gap-4 ajoute un écart entre les enfants. En quelques classes, une barre de navigation est en place.
Le responsive design
C’est l’un des points forts de Tailwind. Le responsive se gère avec des préfixes de points de rupture directement sur les classes : sm:, md:, lg:, xl:, 2xl:.
Le principe est mobile-first : une classe sans préfixe s’applique à toutes les tailles, et les préfixes ajoutent des règles à partir d’une largeur donnée.
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
<!-- 1 colonne sur mobile, 2 sur tablette, 3 sur desktop -->
</div>
Ici, la grille passe automatiquement de une à trois colonnes selon la largeur de l’écran, sans écrire la moindre media query manuelle. C’est concis et lisible une fois l’habitude prise.
Personnaliser Tailwind
Tailwind n’est pas une camisole : il se configure. Vous pouvez étendre le thème par défaut — ajouter vos couleurs de marque, vos polices, vos espacements — via la configuration.
// tailwind.config.js
export default {
theme: {
extend: {
colors: {
marque: '#1a56db',
},
fontFamily: {
titre: ['Inter', 'sans-serif'],
},
},
},
}
Vous pourrez alors écrire bg-marque ou font-titre comme n’importe quelle classe native. Cette personnalisation garantit une cohérence visuelle : toute l’équipe puise dans la même palette, les mêmes échelles, ce qui limite les incohérences de design.
Pour éviter la répétition de longues listes de classes, deux approches : extraire des composants (dans React, Vue ou Astro, un composant réutilisable encapsule le balisage) ou utiliser la directive @apply pour regrouper des utilitaires dans une classe CSS classique. La première est généralement recommandée. Si vous travaillez sous Astro, notre guide sur le framework Astro montre comment structurer ces composants proprement.
Les avantages et les limites
Comme tout outil, Tailwind a ses forces et ses compromis. Soyons honnêtes sur les deux.
Les avantages :
- Rapidité : on style sans quitter son fichier ni inventer de noms.
- Cohérence : l’échelle prédéfinie et la configuration commune uniformisent le design.
- CSS léger : seul le CSS utilisé est généré.
- Maintenance : supprimer un composant supprime ses styles, il ne reste pas de CSS mort.
Les limites :
- Balisage verbeux : les longues chaînes de classes peuvent alourdir la lecture du HTML.
- Courbe initiale : il faut apprendre le vocabulaire, même s’il vient vite.
- Dépendance : votre style est couplé à Tailwind et à son build.
- Débat esthétique : mélanger structure et présentation heurte les puristes de la séparation des responsabilités.
Ces limites sont surtout affaire de préférence et de contexte. Beaucoup d’équipes trouvent que le gain de vitesse et de cohérence l’emporte largement, en particulier sur des projets à composants (React, Vue, Svelte, Astro).
En résumé
Tailwind CSS propose un changement de mentalité : composer le style à partir de petites classes utilitaires plutôt que d’écrire des feuilles CSS sur mesure. L’approche déstabilise au début, puis séduit par sa rapidité et sa cohérence. Elle n’est pas obligatoire ni universelle, mais elle est devenue un standard de fait dans l’écosystème front-end moderne. Le meilleur moyen de vous forger un avis reste de l’essayer sur un petit projet : en une soirée, vous saurez si son approche vous parle.