J'ai supprimé Sass de mon dernier projet. Et je n'ai rien regretté.

Sur mon dernier projet client, j'ai fait quelque chose que je n'aurais pas osé il y a deux ans : j'ai viré Sass, réduit Tailwind au minimum, et écrit du CSS natif pour toute la logique de style.

Le résultat : 30% de CSS en moins à charger, zéro étape de compilation pour les styles, et un code plus lisible qu'avant.

Ce n'est pas du purisme. C'est pragmatique. Le CSS de 2026 a rattrapé son retard. Les fonctionnalités qui justifiaient Sass, les frameworks utility-first et même certains scripts JavaScript sont maintenant natives dans le navigateur.

Les 6 fonctionnalités qui changent tout

1. Container Queries — la fin du responsive "viewport"

Jusqu'ici, le responsive design se basait sur la taille de l'écran. Le problème : un composant carte réutilisé dans une sidebar étroite et dans une grille pleine largeur avait besoin de variantes différentes. Avec Tailwind, ça donnait CardSmall, CardMedium, CardLarge. Trois composants pour la même chose.

Les container queries règlent ça. Le composant s'adapte à son conteneur, pas au viewport.

.card-wrapper {
  container-type: inline-size;
}

@container (min-width: 500px) {
  .card {
    grid-template-columns: 200px 1fr;
  }
}

J'ai réduit de 40% le nombre de variantes de composants sur mes projets depuis que j'utilise ça. Un seul composant carte qui s'adapte partout.

Support navigateur : 92% global. Chrome, Safari, Firefox — tout le monde est à bord.

2. Le sélecteur :has() — le "parent selector" qu'on attendait depuis 20 ans

C'est probablement la fonctionnalité la plus demandée de l'histoire du CSS. :has() permet de styler un élément parent en fonction de ce qu'il contient.

/* La carte a une image ? Passe en layout horizontal */
.card:has(img) {
  grid-template-columns: 200px 1fr;
}

/* Le champ est invalide ? Bordure rouge sur le groupe */
.form-group:has(input:invalid) {
  border-color: red;
}

Avant ça, il fallait du JavaScript ou des classes conditionnelles en React. Maintenant, c'est deux lignes de CSS.

Support navigateur : 88% global.

3. Le nesting natif — Sass n'a plus de raison d'exister

La raison numéro 1 d'utiliser Sass, c'était le nesting. C'est fini : le CSS natif le supporte.

.card {
  padding: 1rem;

  & .card-title {
    font-size: 1.5rem;
  }

  &:hover {
    box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
  }
}

C'est exactement la même syntaxe que Sass, directement dans le navigateur. Plus besoin de compilation, plus de node_modules juste pour imbriquer du CSS.

Support navigateur : 82% global.

4. Cascade Layers — fini les guerres de spécificité

Si vous avez déjà ajouté !important en désespoir de cause, les cascade layers sont pour vous. Elles permettent de définir l'ordre de priorité de vos styles de manière explicite.

@layer reset, base, components, utilities;

@layer components {
  .button { background: blue; }
}

@layer utilities {
  .bg-red { background: red; }
}

L'utilité vient quand on mixe du CSS tiers (une librairie UI) avec son propre code. Plus besoin de surcharger avec des sélecteurs ultra-spécifiques. On déclare juste que notre layer a la priorité.

Support navigateur : 90% global.

5. OKLCH et color-mix() — les fonctions couleur de Sass en natif

L'autre raison d'utiliser Sass, c'étaient les fonctions couleur (lighten(), darken(), mix()). Le CSS natif fait maintenant mieux.

:root {
  --primary: oklch(60% 0.15 250);
}

.button {
  background: var(--primary);
}

.button:hover {
  /* 10% plus clair, calculé nativement */
  background: oklch(from var(--primary) calc(l + 10%) c h);
}

.badge {
  /* Mélange avec du blanc à 20% */
  background: color-mix(in oklch, var(--primary) 20%, white);
}

OKLCH produit des couleurs perceptuellement uniformes (contrairement à HSL qui donne des résultats incohérents). Et color-mix() remplace toutes les fonctions Sass de manipulation de couleur.

Support navigateur : 88% global.

6. View Transitions — des transitions de page sans framework

C'est la fonctionnalité la plus spectaculaire. Les view transitions permettent d'animer le passage d'une page à l'autre — le genre de chose qui nécessitait Framer Motion ou GSAP.

::view-transition-old(root) {
  animation: fade-out 0.3s ease;
}

::view-transition-new(root) {
  animation: fade-in 0.3s ease;
}

Sur un site Next.js, ça remplace des dizaines de lignes de JavaScript pour les transitions de navigation.

[!NOTE] Attention : Le support est encore à ~65% (Chrome et Edge principalement). Safari et Firefox avancent, mais pour l'instant je l'utilise en amélioration progressive — les navigateurs non supportés ont simplement une navigation instantanée.

Et Tailwind dans tout ça ?

Je ne suis pas en train de dire que Tailwind est mort. J'utilise encore Tailwind v4 sur la majorité de mes projets — y compris ce site.

Mais le contexte a changé. Voici comment je vois les choses en 2026 :

Ce que Tailwind fait encore mieux que le CSS natif :

• La vitesse de prototypage (taper des classes directement dans le HTML)
• La cohérence d'une design system via les tokens (text-sm, p-4, rounded-lg)
• Le purge automatique du CSS inutilisé

Ce que le CSS natif fait désormais mieux :

• Le responsive par composant (container queries vs media queries)
• La logique conditionnelle de style (:has() vs classes JavaScript)
• La manipulation de couleurs (OKLCH vs config Tailwind)
• Les animations liées au scroll (scroll-driven animations vs libs JS)

[!IMPORTANT] Mon approche en 2026 : J'utilise Tailwind pour le layout et l'espacement (les utility classes rapides), et du CSS natif pour la logique de style complexe (container queries, :has(), animations). Les deux se complètent très bien avec @layer.

Ce que ça change pour la performance

Le CSS natif a un avantage mesurable : zéro runtime JavaScript pour le style. Chaque fonctionnalité CSS qui remplace du JavaScript, c'est moins de code à télécharger, parser et exécuter.

Sur un projet client récent, le remplacement d'un Intersection Observer JavaScript par des scroll-driven animations CSS a réduit le bundle JS de 12 KB. Multiplié par 8 composants animés, ça fait une différence visible sur le score INP (Interaction to Next Paint).

Le CSS natif est aussi plus résilient : si le JavaScript plante, les styles CSS continuent de fonctionner. C'est du progressive enhancement par défaut.

Par où commencer

Si vous voulez intégrer ces fonctionnalités dans vos projets :

1. Commencez par :has() et le nesting — Support solide, impact immédiat, aucun risque
2. Ajoutez les container queries sur vos composants réutilisables — c'est le plus gros gain
3. Remplacez Sass par OKLCH + color-mix() si vous l'utilisiez uniquement pour les couleurs
4. Testez les view transitions en progressive enhancement — elles sont impressionnantes quand elles marchent
5. Gardez Tailwind pour ce qu'il fait bien : le prototypage rapide et la cohérence des tokens

Conclusion

Le CSS de 2026 est le plus puissant qu'on ait jamais eu. Il gère le responsive par composant, la logique conditionnelle, les animations au scroll, la manipulation de couleurs et les transitions de page — tout ça nativement.

Ça ne rend pas Tailwind obsolète. Mais ça change l'équation : on n'a plus besoin d'un framework pour écrire du CSS moderne et performant. Les deux approches se complètent, et savoir quand utiliser l'une ou l'autre, c'est ce qui fait la différence.

Besoin de moderniser le CSS de votre site ? Contactez-moi pour un audit performance et une mise à jour vers les standards 2026.