Utilisation des pré-processeurs : état de l'art en 2026

Bonjour à tous,

Bien sûr, il existe des enquêtes Stack Overflow, des npm trends et autres outils statistiques, mais pour vous-même : Vous utilisez quoi aujourd'hui comme outils de build pour vos styles ? Si vous en utilisez encore un d'ailleurs ? Et surtout pour quels types de projets (projet perso, d'envergure, legacy, etc) ?

Et ce qui m'intéresse le plus : quelles sont les fonctionnalités dont vous ne pouvez encore vous passer en 2026 ?

Pour vous inciter à répondre je commence par répondre moi-même à ma propre question :

Après avoir longtemps utilisé Stylus, désormais totalement legacy, n'avoir jamais été convaincu par le monolithe Sass, j'ai tenté PostCSS. Ce dernier vendait du rêve sur le papier, avançait sa modularité, mais dans la pratique il repose entièrement sur un écosystème composés de plugins tous autant chaotiques les uns que les autres : incompatibles entre eux souvent, deprecated du jour au lendemain. J'ai fini par adopter une solution maison, avec notamment Lightningcss.

Les avancés de CSS de ces 2 dernières années ont fait reculer le besoin viscéral d'avoir un préprocesseurs sur certains projets. Cependant, voici les fonctionnalités dont je ne peux me passer même aujourd'hui :

- Les variables : en effet, les custom properties ne seront jamais supportés par les media queries (@media) en raison du risque de récursivité infinie ; les @custom-media ne sont pas encore supportées et, de toute façon ne seront jamais supportés eux non plus par @container. Perso j'ai fait un système de variables qui supporte la syntaxe media queries level 5 **.
- Les mixins (@mixin et @include), mais je ne permet pas de descendre au-delà de 3 niveaux de récursivité, sinon je considère qu'il y a un problème de design ; en réalité, je devrais même interdire la récursivité pour cette feature...
- Fusion des @import, avec compatibilité layer(), en un unique fichier.
- Les boucles @for, à utiliser avec modération pour ne pas générer n'importe quoi.

Voilà, je crois que je n'ai rien oublié, j'ajouterais peut-être à terme la résolution de calc() sur les valeurs statiques, mais je ne permettrais pas les mélanges d'unités statiques comme le permet SASS, là encore je trouve que cela encourage les mauvais designs.

C'est à vous !

---

Exemple :

$from-s-to-m: (50em < width <= 70em);

Modifié par Olivier C (01 Sep 2026 - 23:57)

Salut Olivier,

De mon côté, je reste assez pragmatique et mes outils s'articulent autour de ViteJS comme bundler.

Pour le reste, ma stratégie dépend de la taille du projet :

- Projets légers / relativement moyens : Du CSS natif pur. Les évolutions récentes (nesting, custom properties, @layer, etc.) suffisent amplement dans 80 % des cas aujourd'hui.
- Gros projets / architectures complexes : Je reste fidèle à Sass.

Pourquoi Sass sur de grosses architectures alors que le natif a tant progressé ? Principalement pour sa puissance algorithmique que le CSS natif ne peut remplacer :

- @if et @for : Indispensables dès qu'il s'agit de générer des grilles, des échelles typographiques ou des utilitaires dynamiques.
- @mixin et @include : Pour encapsuler des motifs complexes sans répéter de code.
- @function : Pour traiter de la donnée, manipuler des couleurs ou calculer des échelles dynamiques directement à la compilation.

Côté méthodologie et organisation du code, j'utilise deux approches (suivant le projet) :

- L'Atomic Design pour la découpe composant/système de design.
- CUBE CSS (merci d'ailleurs à Raphaël pour la découverte de cette méthodologie).
Modifié par Niuxe (02 Sep 2026 - 01:34)