Spécialistes Tailwind CSS

Pourquoi Tailwind CSS dans nos projets

Nous l'avons adopté en 2021, après avoir vu trop de codebases CSS dériver vers des fichiers de plusieurs milliers de lignes que personne ne se sentait autorisé à nettoyer. Cinq ans plus tard, c'est devenu notre socle CSS systématique sur tous les projets de notre agence Laravel sur mesure.

Notre conviction

Le CSS classique souffre d'un problème de fond : il vit dans des fichiers séparés du markup qu'il style, sa portée est globale par défaut, et il accumule progressivement du code mort que personne n'ose supprimer. Tailwind résout ces trois problèmes d'un coup en déplaçant le style dans le markup et en générant uniquement ce qui est utilisé.

Notre approche concrète

Nous travaillons utility-first par défaut, et nous extrayons en composants Blade ou en classes nommées dès qu'un pattern se répète trois fois ou plus. Le bon ratio entre les deux est ce qui distingue une codebase Tailwind tenable d'un fouillis d'utilities dupliquées.

Pour quoi nous l'utilisons

• Design systems d'agence : design tokens versionnés, theming light/dark, cohérence inter-projets
• Back-offices Filament : Filament étant déjà sous Tailwind, on prolonge naturellement
• Sites institutionnels et landing pages : itération rapide avec un design serré
• Email transactionnel : Tailwind compilé pour les contraintes des clients mail
• Pages CMS éditoriales : prose plugin pour le rendu des contenus markdown
• Composants UI : Flux (sous Tailwind) pour les patterns récurrents

Notre approche du design system

Tailwind n'est pas qu'un outil de stylage rapide. C'est aussi un cadre pour formaliser un design system. Nous utilisons :

• @theme inline pour exposer les tokens couleur, typo, spacing comme variables CSS réutilisables
• Modes light/dark déclarés au niveau du root, automatiquement repris par tous les composants
• Des composants Blade nommés (.title-card, .subtitle-card, .markdown-content) pour les patterns récurrents
• Une convention stricte : pas de valeurs arbitraires sans validation design

Quand ce n'est pas la bonne réponse

• Refonte CSS lourde sans budget : la migration vers utility-first n'est pas gratuite, elle demande de la discipline équipe
• Équipe allergique au markup chargé : la lisibilité s'apprend ; certaines personnes ne s'y feront pas
• Sites légers en pur HTML statique : pour 200 lignes de CSS, le surcoût Tailwind n'est pas justifié

Notre stack autour de Tailwind

• Version : Tailwind CSS v4 (vendor:publish + Vite)
• Composants : Flux (front Livewire), Filament (back-office), conventions Blade maison
• Theming : @theme inline pour exposer les tokens, classes dark: pour le thème sombre
• Typo : Roobert (custom @font-face) + fallbacks system

Nos modes d'intervention

Migration vers Tailwind

Vous avez une codebase legacy avec du SCSS qui déraille ? On planifie la migration par modules, sans rupture utilisateur, avec un design system propre à l'arrivée.

Mise en place d'un design system

Création des tokens, des composants de base, des conventions équipe, de la documentation. Livrable utilisable indépendamment du projet d'origine.

Audit & cleanup

Trop de valeurs arbitraires, classes dupliquées, composants Blade absents : on identifie les patterns à extraire et on remet de l'ordre.

Formation équipe

Vos devs back découvrent Tailwind ? Session pratique sur vos vrais cas pour acquérir les bons réflexes utility-first sans tomber dans les pièges classiques.