Comment j'organise mon CSS sur un projet from scratch

Chaque fois que je démarre un nouveau projet, la question du CSS revient. Quel préprocesseur ? Quelle convention de nommage ? Quelle organisation des fichiers ? Les réponses de la communauté varient, les modes changent, les frameworks prolifèrent.

J'ai simplifié ma réponse au fil des années. Un seul fichier CSS. Pas de Sass, pas de compilation. Des variables custom properties en tête de fichier, des sections commentées, et une règle immuable : une classe, une ligne.

Le fichier commence toujours par un bloc :root qui centralise toutes les valeurs de design : couleurs, typographie, espacements, breakpoints, timing d'animation. C'est le design system du projet, lisible en quelques dizaines de lignes.

L'avantage des custom properties sur les variables Sass, c'est qu'elles sont réelles au runtime. On peut les modifier en JavaScript, les lire dans la console, les surcharger dans un sélecteur enfant. Elles font partie du DOM, pas seulement de la feuille de style compilée.

Après les variables, le fichier suit un ordre logique et stable d'un projet à l'autre : reset minimal, typographie globale, éléments de base (liens, images, formulaires), layout (header, footer, conteneurs), puis les composants page par page.

Chaque section est séparée par un commentaire court. Pas de dossiers, pas de partials, pas d'imports. Tout est dans le même fichier, dans le même ordre. Quand je cherche quelque chose, je sais où regarder.

C'est la règle la plus contraignante, et la plus utile. Chaque règle CSS tient sur une seule ligne :

.btn_primary { display: inline-flex; align-items: center; padding: 14px 28px; border-radius: 40px; background: var(--color_accent); }

Ça peut sembler illisible au premier coup d'oeil. En pratique, c'est l'inverse. Quand on cherche une propriété, on cherche une ligne, pas un bloc. La densité visuelle rend le fichier compact, scrollable, comparable. Un composant de dix propriétés prend une ligne au lieu d'une dizaine. L'ensemble du CSS d'un projet tient souvent en moins de mille lignes.

Je n'applique pas BEM strictement. Les classes reflètent la sémantique du projet plutôt qu'une convention générique. Un composant de navigation s'appelle .main_nav, ses enfants .main_nav a ou .nav_item selon leur complexité. L'underscore sépare les mots, le double underscore ou le tiret signalent une variante.

Ce qui compte, c'est que le nom soit lisible et prévisible dans le contexte du projet. Pas qu'il suive un standard externe qui n'a pas été conçu pour ce site précis.

Plutôt que de regrouper toutes les media queries en fin de fichier, je les place juste après les règles du composant concerné. Ça maintient la cohérence entre le style desktop et le style mobile au même endroit dans le fichier, sans avoir à sauter d'une section à l'autre pour comprendre le comportement complet d'un élément.

Ce n'est pas une règle absolue. Sur des projets très simples, une seule section media query en fin de fichier suffit. La méthode s'adapte au projet, pas l'inverse. C'est peut-être ça, au fond, le seul principe qui compte vraiment.