BEM n’est pas une convention de nommage, c’est une langue pour vos composants

Pour de nombreux développeurs, la première rencontre avec la méthodologie BEM (Block, Element, Modifier) provoque une réaction épidermique. Ces noms de classes à rallonge, ponctués de doubles tirets et de doubles underscores, semblent inutilement verbeux, voire « laids ». On les rejette souvent pour des raisons esthétiques, les jugeant trop rigides ou superflus pour des projets de taille modeste. Cette perception, bien que compréhensible, passe à côté de l’essentiel : BEM n’est pas une simple convention de nommage. C’est un système linguistique.

Imaginez que vous découvriez une langue étrangère. Au premier abord, sa grammaire et sa syntaxe peuvent paraître étranges, contre-intuitives. Pourtant, chaque règle a une fonction : clarifier le sens, éliminer l’ambiguïté, structurer la pensée. BEM fonctionne de la même manière pour vos feuilles de style. Il propose une grammaire pour décrire les relations entre les différentes parties d’une interface utilisateur. Le but n’est pas l’élégance syntaxique, mais la communication efficace et sans équivoque entre les membres d’une équipe et avec le « futur vous » qui maintiendra le code.

Alors, si la véritable clé n’était pas de débattre de la « beauté » d’une classe CSS, mais de comprendre la logique structurelle qu’elle véhicule ? Cet article vous propose de changer de perspective. Nous n’allons pas simplement décrire BEM. Nous allons le décortiquer en tant que langage, en analysant sa syntaxe, sa sémantique et sa grammaire. Vous découvrirez comment chaque partie de `block__element–modifier` a un rôle précis, transformant une simple chaîne de caractères en une documentation vivante de votre interface.

Ce guide vous montrera comment la rigueur de BEM, loin d’être une contrainte, est en réalité un formidable outil de liberté et de scalabilité. En parcourant ses concepts fondamentaux, ses synergies avec d’autres méthodologies comme OOCSS et ses applications dans des projets français d’envergure, vous apprendrez à lire et à écrire ce « langage des composants » pour construire des interfaces plus robustes et plus faciles à maintenir.

Qu’est-ce qu’un « Block » BEM ? La clé de la réutilisabilité de vos composants

Dans la grammaire de BEM, le « Block » est le nom. C’est l’entité sémantique principale, un composant d’interface autonome et réutilisable. Pensez à un bloc comme à une brique de Lego : il a une fonction propre et peut être placé n’importe où dans votre construction sans dépendre de son environnement immédiat. Un menu de navigation (`.nav`), un bouton (`.btn`), une carte (`.card`) ou un champ de recherche (`.search-form`) sont des exemples parfaits de Blocks. La règle d’or d’un Block est son indépendance contextuelle. Un Block ne doit jamais être stylisé en fonction de son emplacement dans la page (pas de `.sidebar .card`) ni influencer les éléments qui l’entourent.

Cette indépendance est la pierre angulaire de la réutilisabilité. En créant un `.card` qui a la même apparence qu’il soit dans une colonne principale, une barre latérale ou un pied de page, vous créez un composant véritablement modulaire. Le nom de classe du Block doit décrire sa fonction (« à quoi il sert ? ») et non son état ou son apparence (« à quoi il ressemble ? »). On préférera donc `.error-message` à `.red-text`. Cette approche garantit que la sémantique de votre HTML reste claire et que votre CSS est découplé de la structure spécifique d’une page.

L’adoption de cette rigueur n’est pas qu’une lubie de puriste. Elle est au cœur des systèmes de design les plus robustes. En France, un exemple frappant est le Système de Design de l’État (DSFR). Chaque composant officiel, qu’il s’agisse d’un bouton (`.fr-btn`) ou d’une carte (`.fr-card`), est conçu comme un Block BEM. Cette approche garantit une cohérence absolue et une maintenabilité à grande échelle sur l’ensemble des sites gouvernementaux, démontrant que la pensée « Block » est un standard de qualité pour les projets critiques.

En somme, le Block est la fondation de votre architecture BEM. C’est le substantif de votre langage de composants, une entité qui existe par elle-même et pour elle-même, prête à être assemblée pour construire des interfaces complexes et évolutives.

L’art de l’ « Element » en BEM : pourquoi `block__element` est indissociable

Si le Block est le « nom », l’Element en est une partie constitutive, une composante qui n’a de sens qu’à l’intérieur de son Block parent. Un titre de carte (`.card__title`), un item de menu (`.menu__item`) ou une icône de bouton (`.btn__icon`) sont des Elements. Ils sont sémantiquement et fonctionnellement liés à leur Block et ne peuvent exister de manière autonome. Vous ne trouveriez jamais un `.card__title` en dehors d’un `.card`. C’est cette relation de dépendance qui est matérialisée par le séparateur `__` (double underscore).

Ce séparateur n’est pas un choix esthétique, c’est un connecteur logique. Comme le souligne le développeur Thomas Fortin dans une analyse de la méthodologie, il faut le lire comme une préposition :

Le double underscore ‘__’ n’est pas un simple séparateur, c’est la préposition ‘de’ ou ‘appartenant à’. card__title se lit ‘le titre DE la carte’.

– Thomas Fortin, Article Medium sur les méthodologies BEM & ABEM

Cette vision linguistique change tout. La syntaxe `block__element` devient une prose descriptive qui explicite la hiérarchie de l’interface directement dans le HTML. Il n’y a plus besoin d’inspecter le DOM ou de deviner les relations : le nom de la classe est auto-documenté. Un Element est toujours une partie d’un Block, mais jamais une partie d’un autre Element. On n’écrira donc jamais `.block__element1__element2`.

Cette structure plate, où tous les styles sont appliqués directement via une seule classe, est un avantage majeur. Elle permet de maintenir une spécificité CSS très basse et prévisible, évitant ainsi les guerres de `!important` et les cascades infernales qui hantent les projets mal structurés. Chaque style est précisément ciblé et encapsulé, ce qui rend le débogage et la maintenance beaucoup plus simples. L’Element est la pièce qui donne sa substance au Block, tout en restant humblement à sa place.

En définitive, l’Element est l’outil qui permet de décomposer un composant complexe en parties logiques, tout en préservant une structure de code saine et une sémantique parfaitement lisible.

Le « Modifier » BEM : comment gérer les variations et les états de vos composants

Le Modifier est l’adjectif de la grammaire BEM. Il exprime une variation d’apparence, de comportement ou d’état d’un Block ou d’un Element. C’est lui qui permet de créer un bouton bleu (`.btn–primary`), une carte plus grande (`.card–large`) ou un onglet actif (`.tabs__link–is-active`). Le séparateur `–` (double tiret) signale cette modification. Contrairement à l’Element qui décrit une partie *appartenant* au Block, le Modifier décrit une *qualité* ou un *état* du Block ou de l’Element.

On distingue généralement deux types de Modifiers. Le premier est un Modifier booléen, qui ajoute simplement une classe pour activer un style, comme `.menu–is-open`. Le second est un Modifier clé-valeur, qui se matérialise par deux classes : la classe de base et la classe modifiée (ex : `.btn` et `.btn–primary`). Cette deuxième approche est souvent préférée car elle permet de mutualiser les styles de base dans la classe du Block et de n’appliquer que les changements spécifiques dans la classe du Modifier. C’est le principe de ne pas se répéter (DRY – Don’t Repeat Yourself) appliqué au CSS.

L’exemple de Doctolib, une des figures de la French Tech, illustre parfaitement la puissance des Modifiers dans une application complexe. Le composant `bloc-disponibilites` peut recevoir des Modifiers comme `–urgent` ou `–teleconsultation` pour adapter son affichage. Cette approche permet de gérer une multitude de cas de figure de manière élégante et prévisible, sans créer de nouvelles classes à chaque fois.

Pour clarifier leur usage, le tableau suivant synthétise les différents types de modificateurs et leurs conventions.

L’utilisation de préfixes comme `is-` ou `has-` pour les états (ex: `is-disabled`, `has-dropdown`) est une convention particulièrement utile. Elle rend le rôle de la classe immédiatement compréhensible, que ce soit dans le HTML ou via JavaScript qui viendra manipuler ces états. C’est une nouvelle preuve que BEM est avant tout un langage de communication.

En somme, le Modifier apporte la flexibilité nécessaire à tout système de composants. Il permet de gérer la complexité et la diversité des interfaces modernes tout en conservant une base de code propre, structurée et sémantiquement riche.

BEM + Sass : le mariage parfait ou une relation dangereuse ?

À première vue, associer la rigueur de BEM à la puissance d’un préprocesseur comme Sass semble être une évidence. Sass permet d’écrire des noms de classes BEM de manière plus concise grâce à l’opérateur d’imbrication `&`. On peut ainsi structurer ses fichiers `.scss` en miroir de la structure BEM, ce qui améliore considérablement l’organisation du code. Par exemple, le style d’un composant `card` peut être entièrement encapsulé dans un seul bloc de code, facilitant sa maintenance et sa compréhension.

 .card { // Styles du Block

&__title {
// Styles de l'Element 'title'
}

&__button {
// Styles de l'Element 'button'
}

&--featured {
// Styles du Modifier 'featured'
}
}

Cette approche est séduisante et largement adoptée. Cependant, elle cache un piège dans lequel de nombreux développeurs tombent : l’imbrication excessive. La facilité avec laquelle Sass permet d’imbriquer les sélecteurs peut encourager à recréer de la dépendance au DOM, ce que BEM cherche précisément à éradiquer. Imbriquer des sélecteurs sur plus de deux ou trois niveaux (`.card { .content { a { … } } }`) va à l’encontre de la philosophie BEM qui prône une spécificité plate et des classes uniques.

La relation entre BEM et Sass est donc un mariage de raison qui demande de la discipline. Le linguiste vous mettrait en garde : la puissance d’un langage peut aussi conduire à un jargon incompréhensible si l’on en abuse. La bonne pratique consiste à n’utiliser l’imbrication de Sass que pour construire les noms de classes BEM avec `&`, et à s’interdire toute imbrication de sélecteurs HTML ou de classes non-BEM. Cette discipline garantit que le CSS compilé reste propre, avec une spécificité faible et prévisible, tout en bénéficiant de la clarté d’organisation offerte par Sass.

En conclusion, Sass est un excellent outil pour *écrire* du BEM, mais il ne doit pas devenir une excuse pour *détruire* les principes de BEM. Utilisé avec discipline, le duo BEM/Sass permet de construire des architectures CSS à la fois puissantes, organisées et parfaitement maintenables.

Les 3 critiques de BEM (et pourquoi elles sont souvent infondées)

Malgré ses avantages structurels, BEM fait face à des critiques récurrentes. En tant que linguiste du code, il est intéressant de les analyser non pas comme des défauts, mais comme des incompréhensions de la philosophie sous-jacente. Trois arguments principaux reviennent constamment : la verbosité des noms de classes, leur « laideur » perçue, et le sentiment que la méthodologie est surdimensionnée pour les petits projets.

La critique de la verbosité est la plus courante. Taper `.main-navigation__item-link–is-active` semble fastidieux. Cependant, comme le fait remarquer le conférencier Thomas Zilliox, cet argument est de moins en moins pertinent : « Les noms de classes BEM deviennent une documentation vivante de l’interface. L’auto-complétion des éditeurs modernes rend l’argument de la saisie manuelle obsolète. » Le temps « perdu » à taper un nom long est largement compensé par le temps gagné à comprendre instantanément la fonction et la place d’un élément.

L’argument de la « laideur » est purement subjectif et esthétique. Il oppose une préférence personnelle à un gain objectif de clarté et de robustesse. Dans les grands projets français, notamment dans les secteurs bancaire et de l’assurance, la rigueur de BEM est souvent comparée à celle des normes de qualité AFNOR. Pour ces organisations, la clarté, la prévisibilité et la maintenabilité du code ne sont pas des options, mais des exigences critiques. La syntaxe BEM, loin d’être laide, est le symbole d’une structure saine et pensée pour durer, garantissant la pérennité de projets digitaux complexes.

Enfin, l’idée que BEM est inutile pour les petits projets est un faux débat. La discipline structurelle qu’impose BEM est bénéfique dès le premier composant. Elle établit de bonnes habitudes et prépare le projet à grandir sans accumuler de « dette technique » dans son CSS. Même pour un site d’une seule page, penser en termes de composants réutilisables est une pratique saine qui facilite les évolutions futures. D’ailleurs, avec près de 79% des TPE-PME françaises ayant effectué des dépenses numériques en 2023, la qualité du code, même pour de petites structures, devient un enjeu majeur.

En réalité, ces critiques révèlent une tension entre la liberté apparente d’un code non structuré et la liberté réelle qu’offre une structure bien pensée : celle de faire évoluer un projet sans craindre de tout casser.

OOCSS : la naissance de la pensée « composant » qui a changé le CSS à jamais

Pour comprendre la grammaire de BEM, il faut d’abord comprendre la philosophie dont elle découle : l’OOCSS, ou Object-Oriented CSS. Créée par Nicole Sullivan en 2009, cette approche a marqué une rupture fondamentale dans la manière d’écrire du CSS. Avant OOCSS, il était courant de lier étroitement les styles à la structure du DOM, avec des sélecteurs très spécifiques comme `#sidebar .module .title h3`. Ce couplage fort rendait le code fragile, difficile à maintenir et non réutilisable.

OOCSS a introduit deux principes révolutionnaires. Le premier est la séparation de la structure et de l’apparence. L’idée est de créer des « objets » CSS qui gèrent la structure (padding, margin, layout) et de les combiner avec des « skins » qui gèrent l’apparence (couleurs, bordures, polices). Par exemple, une classe `.media` définirait l’alignement d’une image à côté d’un texte, tandis qu’une classe `.theme-dark` pourrait changer la couleur de fond et du texte. Cela permet de mixer et de combiner les styles de manière flexible.

Le second principe, encore plus fondamental, est la séparation du conteneur et du contenu. Cela signifie qu’un composant (un « objet ») doit avoir la même apparence quel que soit l’endroit où il est placé. C’est l’acte de naissance de la pensée « composant » dans le monde du CSS. Fini les styles qui dépendent de l’ID du parent (`#sidebar .button`). On crée une classe `.button` qui est autonome et réutilisable partout. Cette philosophie a eu un impact immense sur l’écosystème web, influençant directement l’émergence des frameworks JavaScript modernes comme React et Vue.js, qui sont entièrement basés sur une architecture de composants.

En France, cette révolution a été portée par des communautés et des événements précurseurs. Des sites comme Alsacréations et des conférences comme Paris Web ont joué un rôle clé dans la diffusion de ces bonnes pratiques, éduquant des générations de développeurs à penser leurs interfaces non plus comme des pages, mais comme des assemblages de composants indépendants et réutilisables.

En somme, OOCSS a fourni le « pourquoi » : la nécessité de créer des composants modulaires et réutilisables. Des méthodologies comme BEM sont ensuite venues apporter le « comment » : une syntaxe claire et rigoureuse pour nommer et structurer ces composants.

BEM, OOCSS, SMACSS : ce qu’il faut vraiment retenir de ces méthodologies

Face à la multiplication des acronymes (OOCSS, SMACSS, BEM), il est facile de se sentir perdu et de voir ces méthodologies comme des approches concurrentes et exclusives. C’est une erreur. En réalité, elles sont largement complémentaires et s’attaquent à différents aspects de l’architecture CSS. Les considérer comme des outils dans une même boîte à outils est une approche bien plus pragmatique.

OOCSS, comme nous l’avons vu, est la fondation philosophique. Elle pose les grands principes : séparation de la structure et de l’apparence, indépendance du contexte. C’est le « pourquoi » de la pensée composant. Elle ne dicte pas comment nommer vos classes ou organiser vos fichiers, mais elle fournit le cadre de pensée essentiel.

SMACSS (Scalable and Modular Architecture for CSS), créée par Jonathan Snook, se concentre sur l’architecture des fichiers. C’est le plan de votre maison CSS. SMACSS propose de catégoriser les règles de style en cinq types : Base (styles par défaut), Layout (grands éléments de mise en page), Module (composants réutilisables, l’équivalent des Blocks BEM), State (variations d’état, comme les Modifiers BEM) et Theme (variations d’apparence). SMACSS vous aide à décider « où » placer votre code.

BEM, enfin, est une convention de nommage. C’est la grammaire précise que vous utilisez pour nommer chaque pièce de votre interface. BEM vous dit « comment » nommer vos classes pour qu’elles soient explicites, non ambiguës et découplées de la cascade. Il s’intègre parfaitement dans la catégorie « Module » de SMACSS.

Le tableau suivant synthétise leurs apports respectifs :

Cette vision synergique est parfaitement résumée par Raphael Goetter, expert CSS et co-fondateur d’Alsacréations, qui offre une métaphore éclairante :

Ces méthodologies ne sont pas concurrentes mais complémentaires : OOCSS est la fondation philosophique, SMACSS l’étage architectural, et BEM le toit qui finalise la structure.

– Raphael Goetter, Alsacréations – Article sur les bonnes pratiques CSS

Ainsi, un développeur avisé ne choisit pas « entre » BEM et SMACSS, mais utilise les principes d’OOCSS, organise ses fichiers avec SMACSS, et nomme ses composants avec la grammaire claire et descriptive de BEM.

OOCSS et BEM : la philosophie et la grammaire, pourquoi vous avez besoin des deux

Considérer BEM sans OOCSS, c’est comme apprendre les règles de grammaire d’une langue sans en comprendre le vocabulaire ou l’intention. Vous pourriez former des phrases techniquement correctes, mais vides de sens. La synergie entre OOCSS (la philosophie) et BEM (la grammaire) est ce qui donne naissance à une architecture CSS véritablement scalable et maintenable.

OOCSS vous enseigne à *penser* en composants : isoler les fonctionnalités, séparer la structure de l’apparence, et viser la réutilisabilité. BEM vous donne les outils pour *nommer* ces composants de manière non ambiguë. Quand vous créez un composant `.card`, c’est la pensée OOCSS qui vous guide. Quand vous nommez son titre `.card__title`, c’est la grammaire BEM qui s’applique. L’un ne va pas sans l’autre. Cette approche hybride est devenue un standard de fait dans de nombreuses équipes de développement en France. Les agences web parisiennes et les ESN lyonnaises, confrontées à des projets de grande envergure comme la refonte de sites e-commerce majeurs, combinent systématiquement ces deux approches pour garantir une architecture saine dès le départ.

Adopter cette double casquette « philosophe OOCSS » et « linguiste BEM » transforme radicalement la qualité de votre code. Vous arrêtez d’écrire du CSS pour une page spécifique et commencez à construire une bibliothèque de composants robustes et indépendants, prêts à être assemblés pour n’importe quelle interface. C’est la promesse d’un code qui vieillit bien, facile à déboguer et agréable à faire évoluer.

En adoptant cette double approche, vous ne vous contentez plus d’écrire des styles. Vous concevez un véritable système, un langage cohérent et partagé pour décrire votre interface, assurant ainsi la robustesse et la longévité de vos projets web.