Couverture de l'article Bonnes pratiques CSS : pourquoi et comment s'organiser ?
Retour aux articles

L'agence

WanadevStudio

Bonnes pratiques CSS : pourquoi et comment s'organiser ?

Récemment je me suis penché sur les différentes méthodologies CSS existantes afin de faciliter la productivité et la maintenabilité de nos projets, c'est une problématique que bon nombre de développeurs rencontrent tôt ou tard.

^ Je ne vous détaillerai pas chacune des méthodes présentées car ce n'est pas le but, il existe déjà de nombreux articles très bien expliqués que je vous partagerai. En revanche, je vais vous présenter ma façon d'organiser mon CSS !

Pourquoi avoir une bonne méthodologie CSS : la carte d'anniversaire

Le CSS dans un projet c'est sympa, je le vois un peu comme une carte d'anniversaire !

Au début la carte est vide, on peut écrire où on veut. Au fur et à mesure que les participants écrivent, la place se fait de plus en plus rare, on écrit où on peut en essayant de placer notre petit mot tant bien que mal.

L'heureux élu se verra rempli de joie lorsqu'il recevra la fameuse carte écrite avec amour et qu'il va lire déchiffrer avec une attention particulière.

Dites-vous bien que celui qui reçoit la carte est celui qui récupère le genre de projet où chacun a fait son CSS de son coté.

^ Si vous n'avez pas de méthodologie CSS, votre projet doit sûrement ressembler à une belle carte d'anniversaire.

Enfin, pour finir cette introduction, je me permets de rappeler que, dernièrement, Baptiste a publié un article sur l'organisation de notre veille techno. Cet article est ainsi la suite logique de nos méthodes de veille.

Organiser son CSS : la problématique

Trêve de plaisanteries et rentrons dans le vif sujet, quelle que soit l'envergure de votre projet, il sera important de bien le structurer (là je ne vous apprends rien).

Et là où se compliquent les choses... c'est lorsque l'on est plusieurs à travailler sur le même projet (from scratch, en cours, déjà existant etc ...) !

Dans ce cas, vous risquez de rencontrer les problèmes suivants :

  • Duplication de classes et de composant (DRY pour Don't Repeat Yourself)
  • Modules pas assez génériques (pas réutilisables)
  • Conflits entre classes (voire annulation de certaines)
  • Difficile à maintenir / faire évoluer (surtout si on n’a pas travaillé dessus dès le début)

@ Que vous soyez freelance ou dans une équipe en édition. L'objectif est de toujours pouvoir travailler de manière méthodique, (ré)exploitable et dans le cas d'une prestation (faut pas se mentir), rentable. Transition directe vers l'article rédigé par Manuel où il explique comment réduire sa dette technique.

Prenons l'exemple d'un projet développé par une autre équipe sur lequel on devrait apporter des améliorations. S'il n'y a pas de méthodologies ni d'organisation du CSS, ça peut vite devenir l'enfer ! Dit plus grossièrement, ce que l'on souhaite, c'est que ça ne fasse pas casser le design juste parce qu'on a changé la couleur d'un bouton.

Pour résumer, voici ce que l'on souhaite sur nos projets :

  • Qu'il soit évolutif
  • Qu'il soit maintenable
  • Qu'il possède une logique facile/intuitive
  • Un nommage de classe simple et contextuel
  • Éviter les conflits de classes
  • Une ré-utilisabilité des composants / modules

Organiser son CSS : les différentes solutions

Au fil des projets on se fait sa propre méthodo : on avance, on progresse, on s'améliore, on fait de moins en moins d'erreurs... mais en creusant un peu, je me suis rendu compte qu'il existait pléthore de méthodologies CSS éprouvées sur la toile allant de la plus simple à la plus complexe.

D'autres se sont bien évidemment creusés sur le sujet avant nous, voici celles sur lesquelles je me suis penché :

  • BEM
  • OOCSS
  • MCSS
  • SMACSS
  • ITCSS
  • SEM BIO

La méthodologie BEM

Si vous avez commencé à vous intéresser aux méthodologies CSS vous avez certainement entendu parler de BEM (Bloc Element Modifier) qui est l'une des plus populaires.

On trouve de nombreux articles qui en parlent comme par exemple (css-tricks, alsacreation, ou putain de code, etc)).

@ BEM c'est surtout une convention de nommage permettant d'identifier rapidement vos blocs/éléments selon leur contexte et de faire un découpage simple pour réutiliser vos blocs (D.R.Y).

^ Il faut savoir qu'à ce jour il n'existe pas de méthodologie officielle, ces méthodes s'adressent surtout à un public de développeurs ayant une base en CSS dans un souci de lisibilité et de maintenabilité du code.

La méthodologie OOCSS (Object Oriented CSS)

L'approche orientée objet est intéressante, les classes CSS sont abordées comme des objets.

On repère les objets/patterns visuels pour en faire des classes réutilisables afin de rendre le CSS indépendant de la structure HTML. Voir la documentation de OOCSS

La méthode MCSS (Multilayer CSS)

Le CSS multicouche suggère de séparer les styles en plusieurs parties, appelées calques. Quatre couches vous permettent d'organiser vos fichiers selon leur catégorie. Voir la documentation de MCSS

La méthode SMACSS (Scalable and Modular Architecture CSS)

Comme pour MCSS, vos styles sont découpés en plusieurs parties, ici en 5 couches pour une meilleure répartition des fichiers. Cette méthode se veut souple et flexible. Voir la documentation en SMACSS et le Guide complet en PDF

La méthode ITCSS (Inverted Triangle CSS)

Un peu plus complexe : vous avez entre 7 et 9 couches (selon la méthode). La manière de découper vos fichiers change mais globalement le même principe est appliqué.

Voici un article sur ITCSS pour plus de détails.

SEM & BIO ( Scalable Evolutive maintable & BEM ITCSS OOCSS)

Et enfin plus corsée, SEM & BIO : une sorte de patchwork méthodologique car elle regroupe 3 méthodes.

Un article sur SEM&BIO par CSS Tricks.

Et moi ? Quelle méthodologie CSS ?

La plupart des méthodes présentées plus haut se basent toutes plus ou moins sur BEM en matière de nommage de classe. Peu importe la solution que vous choisirez, le plus important est de travailler tous de la même manière et sur les mêmes bases.

Ainsi, voici comment je m'organise :

L’architecture
  • mon-projet.scss (includes)
  • Base
    • fonts, mixin, variables, reset (ici pas de .class ni de #id)
  • Layout (header, footer)
  • Components (boutons, blocs réutilisables)
  • Patterns (pages spécifiques, comportement spécifique)
  • Dependencies (réservé au chargement des librairies et à leurs override)

Un peu plus de précisions sur mon découpage (5 parties) qui se veut être un compromis entre toutes les méthodes trouvées.

Base va principalement servir pour l'initialisation du projet. Import de nos fonts, variables et mixin pour le preprocessing (sass/less/stylus) et un reset pour initialiser mes éléments HTML (uniquement sur les balises - pas de .class ni #id)

Layout, réservé aux blocs principaux que l'on va retrouver sur toutes nos pages ou presque (header, footer, dashboard)

Components, les briques et tout type de composant servant à être ré-utilisés (rappelez-vous le D.R.Y) comme les boutons, les cards, les alertes, blocs propres à mon design...

Patterns pour les pages et les comportements spécifiques, ma page profil, page de connexion sont des pages uniques que l'on va retrouver qu'une seule fois.

Dependencies car il nous faut un dossier pour regrouper les dépendances. C'est également l'endroit où l'on override la variable ou le comportement de certaines dépendances (Bootstrap, select2).

Depuis mon-projet.scss je fais un appel à mes fichiers. C'est mon « entrypoint ».

Voici un exemple de ce que pourrait donner une arborescence de dossier :

image

Identification des éléments

Pour le découpage de mon design et de mes éléments, on ne ré-invente pas la roue. Ce que BEM propose répond à nos besoins. Ce sera à vous de bien faire votre découpage.

@ Idéalement et s'il vous est possible de le faire, prenez un moment pour analyser les maquettes à intégrer afin d'identifier les briques réutilisables de celles qui ne le sont pas, les patterns spécifiques, vos boutons etc.

C'est une partie délicate car la logique de votre découpage ne sera pas forcement celle de votre collègue.

méthodologie CSS et convention de nommage

Pour le nommage des classes, tout se fait en minuscule, un tiret en guise de séparateur pour les noms composés que ce soit un bloc, un élément ou un modificateur.

Ensuite, deux underscores devant le nom de notre élément et deux tirets devant le modificateur.

block__element--modifier

head-block
menu-block
menu-block__item
menu-block__item--is-active

Méthodologie CSS : pour résumer

  • Je construis une arborescence structurée et logique de mes fichiers CSS ;
  • J'importe les fichiers de base et j'applique les resets CSS ;
  • J'identifie mes différentes briques à travers les maquettes ;
  • Je fais mon découpage afin de le répartir dans la structure du dossier.

Cette solution est évolutive et non exhaustive, l’optique est de gagner en performance, maintenabilité et productivité. Il est évident que cette méthodologie évoluera, et qu'elle s'ajustera en fonction des projets et des équipes.

Et vous ? Quelle méthode CSS ?

Commentaires

Il n'y a actuellement aucun commentaire. Soyez le premier !

  • Couverture de l'article Retour sur le Meet-up Python du 30 juin 2025
    Retour sur le Meet-up Python du 30 juin 2025

    Il y a 2 jours

    Ce lundi 30 juin 2025 nous accueillions la branche lyonnaise de l'AFPy dans nos locaux pour un meetup autour du langage Python. Malgré les fortes températures, une trentaine de personnes ont répondu présentes pour ce moment de convivialité et d'échange.

  • Couverture de l'article Figma Make : enfin une passerelle prometteuse entre design et code grâce à l'IA
    Figma Make : enfin une passerelle prometteuse entre design et code grâce à l'IA

    Il y a 3 semaines

    Depuis quelques années, les outils d'IA pour générer des intégrations d'interfaces à partir de maquettes fleurissent. On en a testé plusieurs chez WanadevDigital : de Locofy à Uizard, en passant par Framer AI. Tous ont leurs qualités, mais jusqu’ici, il manquait un vrai pont stable entre les intentions du designer et la réalité du code front.

    L’arrivée de Figma Make change la donne. Et si je devais résumer son impact en une phrase : ça fonctionne, et ça fonctionne pour tout le monde, designers, développeurs et intégrateurs !

  • Couverture de l'article Maîtriser la traduction (i18n) dans un projet web - Partie 2 : Conseils pour une localisation gérable et évolutive
    Maîtriser la traduction (i18n) dans un projet web - Partie 2 : Conseils pour une localisation gérable et évolutive

    Il y a 4 mois

    Dans la partie 1, nous nous sommes concentrés sur la mise en place d'une base solide pour la gestion des traductions dans un projet Vue. Maintenant que votre système de traduction est opérationnel, il est temps d'examiner de plus près comment structurer, gérer et faire évoluer vos fichiers de traduction de manière efficace.

    Cette partie couvrira les bonnes pratiques que nous utilisons chez Wanadev pour créer des clés de traduction maintenables, éviter les pièges courants et garantir que vos fichiers de traduction restent propres et évolutifs au fur et à mesure que votre projet grandit.

  • Couverture de l'article Maîtriser la traduction (i18n) dans un projet web - Partie 1 : Configurer proprement
    Maîtriser la traduction (i18n) dans un projet web - Partie 1 : Configurer proprement

    Il y a 4 mois

    Mettre en place l'internationalisation (i18n) dans un projet web peut sembler simple. Cependant, de nombreux projets se retrouvent avec des configurations de traduction mal gérées, difficiles à maintenir ou à faire évoluer à mesure que l'application grandit. Une stratégie i18n robuste est essentielle pour offrir une expérience utilisateur fluide dans plusieurs langues.

    Je vous décris ici, les pratiques que nous avons établies chez Wanadev au fil des années d'expérience pour mettre en œuvre et gérer les traductions dans les projets Vue. Bien que les exemples soient spécifiques à Vue, la plupart de ces pratiques peuvent être appliquées à n'importe quel framework.

  • Couverture de l'article Bien choisir sa typographie : quelques bases pour un message clair
    Bien choisir sa typographie : quelques bases pour un message clair
    Méthodologie

    Il y a 9 mois

    On n'écrit pas "Je t'aime" comme "Je te hais" ! Cette petite phrase résume bien ma problématique : quand on doit délivrer un message, la compréhension de ce dernier ne se fait pas uniquement par la lecture simple du texte, mais aussi par sa mise en forme. Et de cette mise en forme dépend la bonne compréhension du message. Dans cet article, nous allons nous pencher sur l’histoire et les familles de typographies dans le but de sensibiliser sur l’importance des choix de typographies dans la communication. Nous verrons ensuite quelques astuces pour bien sélectionner sa typographie et mettre en forme son message.

  • Couverture de l'article Les solutions CPQ sont-elles accessibles à toutes les entreprises ?
    Les solutions CPQ sont-elles accessibles à toutes les entreprises ?
    Méthodologie

    Il y a 9 mois

    Le CPQ (Configure, Price, Quote) est un outil essentiel pour les entreprises cherchant à optimiser leurs processus de vente. Il permet aux équipes commerciales de configurer rapidement et facilement des produits ou services complexes en fonction des besoins spécifiques des clients, tout en garantissant la cohérence des prix. Grâce au CPQ, les vendeurs peuvent établir des devis précis et personnalisés en temps réel, tout en tenant compte des remises, des promotions ou des ajustements spécifiques. Aujourd'hui les CPQ tirent majoritairement parti de la 3D pour proposer une visualisation de produit plus réaliste et complète.