PicoCSS vs Bootstrap vs Tailwind : choisir son framework CSS

Sommaire (6 parties)

Le projet : TOUSPOURRIS.COM, un site satirique de tracking de la corruption politique française. L'UI devait imiter l'esthétique des institutions de la République Française (RF dans la suite), bleu france #000091, rouge #e1000f, typographie Marianne. Un design reconnaissable immédiatement, délibérément officiel pour l'effet ironique. Ce n'est pas un SaaS moderne avec cards arrondies et dégradés. C'est un pastiche institutionnel.

Et ce choix esthétique a dicté le choix du framework CSS. Quand le design est précis et identitaire, le framework n'est plus un accélérateur neutre, il peut devenir un obstacle. J'ai évalué les trois suspects habituels : Bootstrap, Tailwind, PicoCSS. Voici pourquoi deux ont été écartés et le troisième a gagné.

Le problème avec Bootstrap

Bootstrap impose ses composants. Boutons avec border-radius: 0.375rem, couleurs en variables mais système de couleurs entier à écraser, navbar avec comportements préconfigurés. Pour un design générique, dashboard admin, landing SaaS, c'est parfait : les defaults sont les bonnes.

Pour un design institutionnel RF, c'est l'inverse. On passe son temps à annuler ce que Bootstrap a fait. !important partout, variables CSS réécrites. On finit par avoir du Bootstrap-0 : Bootstrap privé de ses defaults. Il reste environ 31 kB de CSS transférés (232 kB décompressés) dont on n'utilise qu'une partie. Pico, lui, pèse environ 12 kB transférés. Le ratio coût/bénéfice s'inverse : Bootstrap devient une dette, pas un atout.

Le problème avec Tailwind

Tailwind règle le problème des composants imposés : il n'en fournit aucun. Mais il déplace le problème : pour avoir un design cohérent, il faut déclarer le design system (couleurs RF, typographie Marianne). Ensuite, il faut appliquer des classes utilitaires partout dans le HTML. Depuis Tailwind 4 (janvier 2025), cette déclaration vit dans le CSS, dans un bloc @theme, et non plus dans tailwind.config.js. C'est du travail.

Pour ce projet Symfony avec des templates Twig, c'était la courbe d'apprentissage d'un outil supplémentaire. C'était aussi une étape de build Node.js dans un stack PHP. Tout ça pour un résultat que le CSS natif peut donner directement. Le rapport effort/bénéfice ne justifiait pas l'introduction de Tailwind dans un contexte où le design system était déjà défini et documenté par l'État français.

Pourquoi PicoCSS

PicoCSS part d'une philosophie différente : des styles propres sur les éléments HTML sémantiques, sans classes. Un <button> est stylé. Un <input> est stylé. Un <nav> est stylé. La base est utilisable immédiatement sans écrire une ligne de CSS. Et surtout : les defaults sont minimalistes et faciles à écraser avec des custom properties CSS.

/* Surcharger le design system PicoCSS avec les couleurs RF */
/* Dans le HTML : <html lang="fr" data-theme="light"> */
:root {
    --pico-font-family: 'Marianne', system-ui, sans-serif;
    --pico-border-radius: 0;          /* Institutionnel = pas de rounding */
}

:root[data-theme="light"] {
    --pico-primary: #000091;          /* Bleu France */
    --pico-primary-background: #000091;
    --pico-primary-hover: #1212ff;
    --pico-primary-hover-background: #1212ff;
    --pico-del-color: #e1000f;        /* Rouge RF */
}

Quelques variables CSS et le site ressemble à un portail gouvernemental. Deux détails comptent : les liens lisent --pico-primary mais les boutons lisent --pico-primary-background. Et Pico déclare ses couleurs avec :root:not([data-theme=dark]), un sélecteur plus fort qu'un simple :root. D'où le :root[data-theme="light"]. Toujours pas de !important. PicoCSS ne résiste pas, il cède proprement parce qu'il a été conçu pour ça.

Le design system RF en pratique

Le code du système de design de l'État, le DSFR, est public. Son usage ne l'est pas. Le dépôt officiel précise qu'il ne doit pas être utilisé par des entités extérieures à l'administration (réplicabilité limitée à un nom de domaine en .gouv.fr). Les fontes Marianne, elles, sont soumises à des conditions spécifiques. Pour un pastiche, relis ces conditions avant de copier quoi que ce soit. Couleurs, typographies, espacements, tout est défini et documenté. Avec PicoCSS comme base :

• Police Marianne (fournie par le DSFR, sous conditions d'usage) chargée via @font-face
• Variables CSS pour --bleu-france, --rouge-marianne, --gris-cool
• Composants custom, badge de « jauge de pourriture », cards politiciens, écrits en CSS natif, sans classe utilitaire

Le résultat : un site qui ressemble à un portail officiel, délibérément. L'effet satirique repose entièrement sur le design. Un visiteur qui arrive sans contexte voit une interface institutionnelle avant de comprendre que c'est de la satire. Ce décalage ne fonctionne que si le design est crédible. Il ne l'aurait pas été avec un Bootstrap par défaut ou un Tailwind configuré à la va-vite.

Quand choisir quoi

Il n'y a pas de framework universel. Critères concrets pour décider :

La vraie question n'est pas « quel framework est le meilleur » mais « contre quoi est-ce que je vais me battre ». Bootstrap impose ses composants. Tailwind impose ses classes. PicoCSS impose presque rien, ce qui peut être un avantage ou un inconvénient selon si tu veux construire ou surcharger.

Ce qu'il faut retenir

PicoCSS n'est pas la réponse universelle. C'est la réponse quand tu as un design précis et que tu ne veux pas passer ton temps à annuler les décisions d'un framework. Pour TOUSPOURRIS.COM, c'était le bon choix : un design institutionnel cohérent en ~300 lignes de CSS custom, sans guerre de spécificité.

Le code est lisible par n'importe quel dev sans connaître les conventions d'un framework spécifique. Dans 2 ans, si quelqu'un reprend le projet, il lit du CSS, pas du Bootstrap ou du Tailwind. C'est une forme de sobriété technique. Elle a un coût à court terme (pas de composants prêts à l'emploi). Elle a un bénéfice à long terme (une seule dépendance CSS, sans build).