Design system : le guide complet, édition 2026

Les bénéfices attendus sont connus. Ils ne se mesurent qu'une fois le système adopté :

• Cohérence : la même expérience sur le site, l'espace client et l'application.
• Vitesse : les équipes assemblent des composants existants au lieu de redessiner et de recoder.
• Maintenance : un changement de couleur ou de composant se fait à un seul endroit.
• Intégration des nouveaux arrivants : designers et développeurs trouvent les règles écrites.
• Accessibilité : les critères sont traités une fois, dans chaque composant.

Nous ne chiffrons pas ces gains ici : ils dépendent de votre point de départ, et les pourcentages qui circulent ne disent jamais sur quel périmètre ils ont été mesurés. Mesurez les vôtres (voir Mesurer le succès).

Un design system complet n'est pas toujours la bonne réponse. Pour un seul produit porté par une petite équipe, une bibliothèque de composants et quelques tokens suffisent. Le système complet se justifie quand plusieurs équipes, produits ou marques partagent les mêmes éléments, ou quand l'accessibilité et la cohérence deviennent des obligations.

Un design token est une décision de design enregistrée sous forme de variable nommée : une couleur, une taille de police, un espacement, un rayon, une ombre, une durée d'animation. Les tokens sont la source unique que Figma et le code lisent en même temps.

Trois niveaux de tokens

• Primitifs : la palette brute (color.red.600, spacing.4). Ils ne sont jamais utilisés directement dans les composants.
• Sémantiques : le rôle (color.action.primary, color.text.error). C'est le niveau que les designers et les développeurs manipulent.
• Composants : les réglages propres à un composant (button.primary.background), quand un composant doit s'écarter du rôle général.

Nommage, modes et multimarque

Nommez par usage, pas par valeur : color.text.error survit à un changement de rouge, red-500 non. Les modes (clair, sombre, contraste renforcé) et les marques se gèrent en changeant les valeurs des tokens sémantiques, sans toucher aux composants. C'est ce qui permet à un groupe de décliner un même système pour plusieurs filiales.

Le format du Design Tokens Community Group (2025.10)

Le Design Tokens Community Group (DTCG), un groupe communautaire hébergé par le W3C, a publié le 28 octobre 2025 la première version stable de son format, numérotée 2025.10. Le texte le précise : ce n'est ni un standard du W3C ni un document du processus de standardisation du W3C. Il définit un format JSON neutre (propriétés $value, $type, $description), les références entre tokens, les thèmes et plusieurs espaces colorimétriques. Selon le groupe, plus de dix outils et projets open source l'implémentent ou le prennent en charge, dont Style Dictionary, Tokens Studio, Figma et Penpot. Le texte du format recommande les extensions .tokens et .tokens.json.

Voici un extrait au format 2025.10. Il remplace l'exemple de la première édition de ce guide :

{
  "color": {
    "$type": "color",
    "red": {
      "600": { "$value": { "colorSpace": "srgb", "components": [0.827, 0.137, 0.165], "hex": "#d3232a" } },
      "800": { "$value": { "colorSpace": "srgb", "components": [0.561, 0.078, 0.094], "hex": "#8f1418" } }
    },
    "action": {
      "primary": { "$value": "{color.red.600}" },
      "primary-text": {
        "$value": "{color.red.800}",
        "$description": "Texte rouge sur fond clair : contraste d'au moins 7:1"
      }
    }
  },
  "spacing": {
    "$type": "dimension",
    "md": { "$value": { "value": 16, "unit": "px" } }
  }
}

primary et primary-text ne portent pas de valeur propre : leur $value est un alias qui pointe vers un token primitif, avec la syntaxe {color.red.600}. Le type est déclaré une fois sur le groupe et hérité par ses tokens.

La chaîne de production

Les variables Figma (ou Tokens Studio) exportent les tokens en JSON. Un outil de transformation comme Style Dictionary les convertit en variables CSS, en thème Tailwind, en ressources iOS et Android. Le fichier JSON est versionné avec le code : une modification de token passe par une revue, comme une modification de composant.

Une arborescence qui fonctionne dans la plupart des cas :

• Fondations : principes, tokens, couleurs, typographie, grille, espacements, iconographie, animation.
• Composants : une page par composant.
• Patterns : formulaires, tableaux, navigation, authentification, états vides et erreurs.
• Contenus : ton, microcopie, formats de date et de montant, règles par langue.

Chaque page de composant suit le même plan : à quoi il sert, quand ne pas l'utiliser, anatomie, variantes et états, propriétés, règles « à faire, à éviter » illustrées, critères d'accessibilité, exemple de code et lien vers le composant Figma. Un composant sans documentation n'est pas utilisé, ou il est mal utilisé.

Écrivez aussi pour les agents. Les assistants de code lisent la documentation : des règles explicites (« utiliser Button variante primary pour une seule action principale par écran ») valent mieux qu'une page de captures d'écran.

Les assistants de code génèrent désormais une partie des écrans. Sans règles lisibles par une machine, ils produisent des interfaces plausibles mais hors système : couleurs approchées, composants recréés, espacements inventés. Le design system devient la référence qu'ils consultent.

Ce que l'agent doit pouvoir lire

• Les tokens, au format DTCG et avec des noms sémantiques.
• La liste des composants, leurs propriétés et leurs règles d'usage, écrites en phrases.
• Un fichier de règles à la racine du dépôt : quels composants utiliser, ce qui est interdit, comment tester.

Les connecteurs

Le serveur MCP de Figma transmet à l'assistant de code les variables, les composants et la mise en page d'une maquette. Code Connect y ajoute l'import et l'usage réels du composant dans votre code. Le serveur MCP de Storybook, en préversion, donne accès à la documentation des composants et permet à l'agent de lancer les tests, y compris les contrôles d'accessibilité.

Les composants propres aux interfaces IA

Un produit qui intègre un assistant a besoin de composants nouveaux : états de génération (en cours, partielle, erreur), réponse de secours, passage de relais à un humain, indicateurs de confiance, citation des sources. Et la mention qui indique à l'utilisateur qu'il échange avec une IA : l'article 50 du règlement européen sur l'IA l'impose depuis le 2 août 2026, sauf si c'est évident, selon la Commission européenne. Nous traitons la conception de ces parcours dans notre offre Harnessed UX.

L'IA dans la gouvernance

L'IA peut aussi surveiller le système : repérer les composants détachés dans Figma, les couleurs codées en dur, les écarts entre maquette et code. Ses propositions passent par les mêmes revues et les mêmes tests que celles des humains. C'est le principe du harness engineering.

L'équipe core

Une équipe, même réduite, est responsable du système : elle le maintient, examine les propositions, forme les équipes utilisatrices et mesure l'adoption. Deux modèles existent. Centralisé : l'équipe core produit tout. Fédéré : les équipes produit contribuent, l'équipe core arbitre et garantit la cohérence. La plupart des organisations passent du premier au second quand le système grandit.

Le processus de contribution

1. 01

   Proposition

   Le besoin, le cas d'usage, une maquette. Existe-t-il déjà un composant proche ?

2. 02

   Revue par l'équipe core

   Accepté, fusionné avec un composant existant, ou refusé avec explication.

3. 03

   Design et documentation

   Composant Figma, variantes, règles d'usage, critères d'accessibilité.

4. 04

   Développement et tests

   Composant codé, story Storybook, tests d'interaction, visuels et d'accessibilité.

5. 05

   Revue de code

   Par l'équipe core et un représentant de l'équipe qui a proposé.

6. 06

   Publication et annonce

   Nouvelle version, note de version, message aux équipes.

Versioning et dépréciation

• Version majeure (2.0.0) : changement qui casse la compatibilité.
• Version mineure (1.5.0) : nouveau composant ou nouvelle option, sans rupture.
• Correctif (1.4.3) : correction de bug ou amélioration mineure.

Un composant ne disparaît pas du jour au lendemain : il est d'abord marqué déprécié, avec son remplaçant et une date de retrait. Un rituel régulier (revue des propositions, démonstration des nouveautés) garde le lien avec les équipes.

Trois familles d'indicateurs, à suivre dès le produit pilote :

• Adoption : part des produits qui utilisent le système, part de l'interface construite avec ses composants, taux de composants détachés dans Figma.
• Progression : composants documentés, propositions de contribution traitées, délai entre une demande et sa publication.
• Performance : temps de conception et de développement d'un écran type, défauts d'interface et d'accessibilité en recette, satisfaction des équipes utilisatrices.

Mesurez avant de commencer. Sans point de départ, aucun gain ne pourra être démontré.

• Système de Design de l'État (DSFR) : le système des sites de l'État français. La circulaire n° 6411/SG du 7 juillet 2023 le rend obligatoire pour tout nouveau site ou application mobile des administrations centrales, des préfectures, des ambassades et des services déconcentrés ; les opérateurs de l'État peuvent l'utiliser après accord du Service d'information du Gouvernement. Il assume de limiter la personnalisation au profit d'une expérience commune. Une référence pour tout donneur d'ordre public.
• Material Design 3 (Google) : un modèle de tokens et de thèmes dynamiques, documenté pour le web, Android et Flutter.
• Carbon (IBM) : un système open source conçu pour des produits logiciels d'entreprise, avec des composants React et web components.
• Polaris (Shopify) : depuis le 1er octobre 2025, ses composants unifiés sont livrés sous forme de web components pour l'administration, le point de vente et le tunnel de paiement. La preuve qu'un design system peut changer de technologie en gardant ses règles.
• Atlassian Design System : une documentation détaillée sur les tokens, les règles de contenu et l'accessibilité.