PicoCSS vs Bootstrap vs Tailwind : choisir son framework CSS

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 — 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 — avec 50 kB de CSS qu'on n'utilise pas. Le ratio coût/bénéfice s'inverse : Bootstrap devient une dette, pas un atout.

Le problème avec Tailwind

Tailwind résout le problème de sur-opinionatedness en n'ayant pas de composants. Mais il déplace le problème : pour avoir un design cohérent, il faut configurer le design system dans tailwind.config.js — couleurs RF, typographie Marianne — puis appliquer des classes utilitaires partout dans le HTML. C'est du travail.

Et pour ce projet Symfony avec des templates Twig, c'était la courbe d'apprentissage d'un outil supplémentaire, une étape de build Node.js dans un stack PHP, pour un résultat que 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 */
:root {
    --pico-primary: #000091;          /* Bleu France */
    --pico-primary-hover: #1212ff;
    --pico-del-color: #e1000f;        /* Rouge RF */
    --pico-font-family: 'Marianne', system-ui, sans-serif;
    --pico-border-radius: 0;          /* Institutionnel = pas de rounding */
}

5 variables CSS et le site ressemble à un portail gouvernemental. Pas de !important, pas de spécificité en guerre avec le framework. PicoCSS ne résiste pas — il cède proprement parce qu'il a été conçu pour ça.

Le design system RF en pratique

La charte graphique de l'État français est open source — le système de design DSFR. Couleurs, typographies, espacements, tout est défini et documenté. Avec PicoCSS comme base :

• Police Marianne (téléchargeable sur le DSFR officiel) 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 — et 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.

Conclusion

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 qui a un coût à court terme (pas de composants prêts à l'emploi) et un bénéfice à long terme (aucune dépendance à maintenir, aucune migration de version à gérer).