Design systems : un DSL pour l’identité visuelle

Un design system, dans son essence, est bien plus qu’une bibliothèque de composants réutilisables : c’est un langage dédié à l’expression d’une identité graphique (DSL, ou Domain-Specific Language).

Comme tout DSL, un design system définit :

• Un vocabulaire contraint (couleurs, typographies, espacements, composants)
• Une grammaire de composition (comment ces éléments s’agencent)
• Des règles sémantiques (quand et pourquoi utiliser tel élément)

Le domaine métier ici n’est pas la gestion de commandes ou la comptabilité, mais l’ensemble des règles qui font qu’une interface appartient visuellement à une marque. Ces règles, souvent tacites dans l’esprit des designers, trouvent dans le design system une codification explicite et exécutable.

Le vocabulaire : les design tokens

Le vocabulaire du DSL se manifeste dans les design tokens : des variables nommées qui capturent les décisions fondamentales de l’identité.

color.primary.500, spacing.lg, font.heading.xl ne sont pas de simples valeurs : ce sont des termes d’un lexique partagé entre designers et développeurs.

Comme les value objects en DDD, ils encapsulent une signification métier : color.error n’est pas juste du rouge, c’est le rouge qui signifie erreur dans ce système. Utiliser directement #FF0000 dans le code serait comme utiliser une chaîne brute au lieu d’un type EmailAddress : techniquement fonctionnel, mais sémantiquement appauvri et fragile face aux évolutions.

La grammaire : les règles de composition

La grammaire du DSL émerge des règles de composition :

• Un bouton primaire sur fond clair utilise telle combinaison de tokens ; sur fond sombre, telle autre
• Les espacements entre éléments suivent une échelle harmonique, pas des valeurs arbitraires
• Les composants s’emboîtent selon des patterns établis : un Card contient un CardHeader, un CardBody, un CardFooter, dans cet ordre

Ces contraintes ne sont pas des limitations mais des affordances  : elles guident vers des compositions cohérentes tout en interdisant, ou du moins en rendant difficiles, les combinaisons qui violeraient l’identité graphique.

Le système rend les états visuels invalides difficiles à représenter, cf. notre article sur Make Illegal States Unrepresentable.

L’ubiquitous language du design

L’analogie avec les DSL métier s’étend à la notion d’ubiquitous language.

Quand designers et développeurs partagent le vocabulaire du design system, les conversations deviennent précises et non ambiguës. « Utilise un bouton secondary avec un spacing-md » est une phrase exécutable, traduisible directement en code, vérifiable visuellement.

Cette fluidité a un impact économique direct. La friction designer-développeur est coûteuse : allers-retours de clarification, maquettes mal interprétées, corrections post-intégration. Quand les deux parlent le même langage, la passation entre design et développement devient quasi-instantanée.

Les revues de design et les revues de code convergent vers le même référentiel. Les incohérences (un développeur qui improvise une couleur, un designer qui propose un espacement hors grille) deviennent immédiatement visibles comme des violations du langage commun.

Le design system, comme tout bon DSL, crée un espace de communication où l’ambiguïté est réduite.

Gouvernance et évolution

Cette perspective de considérer un design system comme un DSL a des implications sur la gouvernance du système.

Faire évoluer un design system, c’est faire évoluer un langage : ajouter des termes, en déprécier d’autres, modifier des règles grammaticales. Ces changements doivent être gérés avec la même rigueur qu’une API publique : versioning, migration, documentation des breaking changes.

• Les tokens deviennent des contrats
• Les composants deviennent des abstractions stables dont l’implémentation peut changer sans affecter les consommateurs

Et comme pour tout DSL réussi, la valeur réside moins dans les éléments individuels que dans la cohérence systémique qu’ils produisent ensemble ; une cohérence qui, ultimement, constitue l’identité visuelle elle-même.

Cette cohérence n’est pas qu’esthétique : elle construit la confiance. Une interface où chaque bouton a un style différent, où les espacements varient sans logique, signale l’amateurisme. À l’inverse, une cohérence visuelle rigoureuse projette le professionnalisme et rassure l’utilisateur sur la fiabilité du service.