Tailwind CSS : design system et interfaces sur mesure

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.

Ce site, en chiffres

Le site que vous lisez tourne sur Tailwind CSS v4 depuis son premier commit, en juillet 2025. Plutôt que des promesses, voici ce qu'il pèse et comment il est construit, mesuré le 12 octobre 2026.

Le chiffre du CSS mérite une précision. Les démonstrations promettent souvent « quelques Ko » : c'est vrai pour une page vide, plus pour un site avec ses composants, ses états et ses deux thèmes. La compression ramène l'ensemble à 56 Ko, le poids d'une petite image.

Une correction faite une seule fois, pour tout le site

En contrôlant nos propres pages, nous avons trouvé un texte secondaire trop pâle : 1,78:1 sur le fond clair, 2,61:1 sur le fond sombre, loin des 4,5:1 qu'exige le niveau AA des règles d'accessibilité (WCAG). Le texte était lisible pour nous, pas pour tout le monde.

La correction a tenu en deux valeurs, une par thème, dans le fichier de thème. Toutes les pages ont suivi sans toucher à un seul gabarit. C'est l'intérêt concret d'un design system en tokens : une décision de design se prend à un seul endroit.

Responsive et accessibilité : ce qu'on contrôle

Le responsive ne se juge pas sur une maquette, il se vérifie sur l'écran. Avant une mise en ligne, nous contrôlons le rendu au minimum en 390 px (un téléphone courant) et en 1 440 px (un écran de bureau).

• Pas de défilement horizontal de la page. Un exemple réel : en octobre 2026, les tableaux de nos articles débordaient à 427 px sur un écran de 390. Une règle CSS les fait désormais défiler dans leur propre cadre, sans toucher au texte.
• Contrastes mesurés, pas estimés. Chaque couleur de texte est vérifiée contre les fonds où elle apparaît, comme le token corrigé plus haut.
• Polices qui ne bloquent pas l'affichage. font-display: swap affiche d'abord une police système, puis la police du site dès qu'elle arrive.
• Thème sombre sans duplication. Une variante dark déclarée une fois, reprise par tous les composants, y compris ceux de bibliothèques externes.

Du design UI/UX à l'intégration

Nous concevons l'interface de bout en bout : les parcours et les écrans (UX), puis le rendu visuel (UI), et enfin l'intégration en Tailwind. Celui qui dessine l'écran est aussi celui qui le code : rien ne se perd entre la maquette et la production. Deux points de départ possibles :

• Pas encore de maquettes. Nous concevons l'UX et l'UI en interne. Selon la charge et la complexité, un designer partenaire peut nous renforcer, présenté dès le brief, et nous restons votre interlocuteur unique. Les éléments graphiques spécifiques (logo, cartes de visite) sont confiés à un partenaire.
• Vos maquettes Figma. Nous en extrayons les tokens (couleurs, typographie, espacements), puis nous les déclarons dans le fichier de thème Tailwind avant d'écrire le premier écran.

Dans les deux cas, vous recevez un design system documenté : des tokens nommés, des composants Blade réutilisables, et des conventions que le prochain développeur pourra reprendre.

Pour quoi nous l'utilisons

• Design systems : tokens versionnés, thèmes clair et sombre, cohérence d'un écran à l'autre
• Back-offices Filament : Filament étant déjà sous Tailwind, on prolonge naturellement
• Sites institutionnels et landing pages : itération rapide avec un design serré
• Pages éditoriales : une feuille de style dédiée au contenu Markdown, réglée pour la lecture
• 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 clair et sombre déclarés au niveau du root, automatiquement repris par tous les composants
• Des classes nommées (.title-card, .subtitle-card, .markdown-content) et des composants Blade pour les patterns récurrents
• Une convention stricte : pas de valeurs arbitraires sans validation design

Sur Cookuna, notre carnet de recettes en ligne, ce cadre porte deux thèmes complets qui suivent le réglage clair ou sombre du système sur toutes les pages, de la bibliothèque au mode cuisine (voir l'étude de cas Cookuna).

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, compilé par son plugin Vite officiel
• 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.