Du design au code : Figma, tokens et WCAG 2.2 pour développeurs

Entre la maquette validée dans Figma et l’interface livrée en production, il existe un fossé que la plupart des équipes franchissent à la main : on relit les valeurs de la charte, on recopie les couleurs, on devine l’usage d’un composant, et on découvre les défauts d’accessibilité bien trop tard. Ce fossé est coûteux et entièrement évitable. Ce guide pose la vue d’ensemble d’une discipline qui se professionnalise vite — le design vu côté développeur — et trace un parcours concret pour le traverser proprement, des valeurs aux composants jusqu’à l’accessibilité vérifiée automatiquement.

🎯 Ce que ce parcours vous permettra de faire

• Extraire par programme les valeurs d’une maquette Figma et les transformer en design tokens exploitables par n’importe quelle base de code.
• Générer, en une commande, vos variables CSS, modules JavaScript et SCSS depuis une source unique de vérité.
• Relier vos composants Figma à vos composants React pour que le Dev Mode affiche votre vrai code.
• Implémenter les nouveaux critères WCAG 2.2 directement dans le CSS et le HTML, pendant le développement.
• Construire des composants réellement utilisables au clavier et par les lecteurs d’écran, et empêcher toute régression grâce à des tests automatisés en intégration continue.

🗺️ Le parcours d’apprentissage

Les tutoriels de ce parcours se suivent dans un ordre logique, chacun construisant une brique du pont entre design et code. Vous pouvez les lire isolément, mais l’enchaînement raconte une histoire cohérente :

1. Extraire les design tokens depuis Figma — récupérer les valeurs de la charte par l’API Variables.
2. Générer ses tokens avec Style Dictionary — transformer ces valeurs en CSS, JS et SCSS.
3. Relier Figma et React avec Code Connect — connecter les composants, pas seulement les valeurs.
4. Implémenter les critères WCAG 2.2 en code — durcir l’accessibilité au niveau CSS et HTML.
5. Construire des composants React accessibles — gérer focus, clavier et sémantique.
6. Tester l’accessibilité en intégration continue — verrouiller les acquis automatiquement.

Pourquoi le design côté code devient critique

Pendant longtemps, la frontière entre design et développement a été nette : le designer livrait une image, le développeur l’interprétait. Cette division produisait deux sources de vérité divergentes. La maquette disait une chose, le code en disait une autre, et l’écart se creusait à chaque évolution. Multipliez par des dizaines de composants, deux ou trois plateformes et un thème sombre, et la cohérence devient un travail à plein temps — ou, plus souvent, un renoncement silencieux.

Trois évolutions ont changé la donne. D’abord, les outils de design sont devenus structurés : les Variables de Figma ne sont plus des étiquettes décoratives mais des données typées, interrogeables par API. Ensuite, un standard ouvert a émergé pour décrire les design tokens indépendamment de tout outil ; le format du Design Tokens Community Group du W3C a d’ailleurs atteint sa première version stable fin octobre 2025, signe d’une maturité nouvelle. Enfin, l’accessibilité est passée du statut de bonne intention à celui d’obligation, juridique dans de nombreux pays et technique dans toutes les bases de code sérieuses, avec l’arrivée de WCAG 2.2 en octobre 2023.

La conséquence pour un développeur front-end est directe : les tâches autrefois manuelles et approximatives — recopier des couleurs, deviner l’usage d’un composant, corriger l’accessibilité après coup — deviennent des pipelines automatisés et vérifiables. Celui qui maîtrise cette chaîne livre des interfaces cohérentes, maintenables et inclusives, sans y consacrer plus de temps ; celui qui l’ignore accumule une dette qui se paie à chaque refonte. Ce n’est plus une compétence de niche, c’est le socle d’un travail front-end professionnel.

Les concepts fondamentaux

Le design token : une valeur nommée et typée

Un design token n’est rien d’autre qu’une décision de design rendue exploitable par une machine : une valeur (un bleu précis, un espacement de 16 px), un nom qui porte une intention (color.action plutôt que blue-600), et un type (couleur, dimension). Cette triple nature — valeur, nom, type — est ce qui distingue un token d’une simple constante CSS. Le nom sémantique permet de changer la valeur sans toucher au code qui l’utilise ; le type permet aux outils de transformer la valeur correctement selon la cible. Un même token color.action deviendra --color-action en CSS, ColorAction en JavaScript et une ressource colorée sur mobile, sans jamais être redéfini.

La source unique de vérité

Le principe qui sous-tend toute la chaîne est celui de la source unique de vérité. La charte ne doit exister qu’à un seul endroit ; tout le reste en découle mécaniquement. Quand cette source est la maquette Figma et que le code la dérive automatiquement, un changement de couleur se propage partout en un build, sans intervention. Quand il y a deux sources — la maquette et un fichier CSS recopié à la main — elles divergent fatalement. La construction d’un référentiel de design partagé, qu’on appelle souvent design system, repose entièrement sur ce principe ; pour la dimension conception et gouvernance de ce référentiel, l’article Design system : construire et maintenir un référentiel en donne la vue d’ensemble, que ce parcours complète par la mécanique d’implémentation.

L’accessibilité comme contrainte de code, pas comme finition

Le troisième concept est un changement de regard. L’accessibilité n’est pas une couche cosmétique qu’on ajoute à la fin ; c’est un ensemble de propriétés du code, au même titre que la performance ou la sécurité. Un focus visible, une taille de cible suffisante, une sémantique correcte se décident au moment d’écrire le composant. Traitée ainsi, l’accessibilité coûte peu et tient dans le temps ; traitée en finition, elle devient un audit anxiogène et une série de correctifs fragiles. WCAG 2.2 fournit la grille précise de ces propriétés ; l’enjeu est de l’intégrer au flux de développement plutôt que de la subir.

Vue d’ensemble : les trois ponts entre design et code

Traverser le fossé design-code revient à construire trois ponts indépendants mais complémentaires. Chacun fait l’objet d’un ou plusieurs tutoriels de ce parcours.

Premier pont : les valeurs

Le premier pont relie les valeurs de la charte au code. Il commence par l’extraction : interroger Figma pour récupérer couleurs, espacements et typographies sous forme de tokens structurés. C’est l’objet du tutoriel Extraire les design tokens depuis Figma, qui montre comment lire l’API Variables, comprendre la structure des collections et des modes, résoudre les références entre tokens, et produire un fichier au format standard du W3C. Il se prolonge par la génération : transformer ce fichier neutre en autant de sorties que de plateformes. Le tutoriel Générer ses tokens avec Style Dictionary détaille ce pipeline — source, transforms, formats, fichiers — et montre comment une seule commande produit le CSS, le JavaScript et le SCSS, références résolues. Au bout de ce pont, vos valeurs de design sont synchronisées avec le code, automatiquement, à chaque évolution de la maquette.

Deuxième pont : les composants

Les valeurs ne suffisent pas. Un bouton n’est pas qu’une couleur et un rayon : c’est un composant avec des variants, des états, une API. Le deuxième pont relie le composant Figma à son équivalent dans le code. Sans lui, le Dev Mode de Figma affiche un balisage générique que le développeur doit traduire mentalement, source récurrente d’erreurs d’intégration. Le tutoriel Relier Figma et React avec Code Connect montre comment faire apparaître, directement dans Dev Mode, l’usage réel de votre composant React — import compris, props mappées sur les variants. Designers et développeurs partagent alors une seule définition de chaque composant, et l’écart d’interprétation disparaît.

Troisième pont : l’accessibilité

Le troisième pont garantit que ce qui traverse les deux premiers est utilisable par tous. Il a trois travées. La première implémente les critères WCAG 2.2 au niveau du style et du balisage : taille de cible, focus non masqué et bien visible, alternative aux gestes de glissement, authentification accueillante — c’est le tutoriel Implémenter les critères WCAG 2.2 en code. La deuxième traite les composants riches, là où le HTML natif ne suffit plus : gérer le focus, le clavier et la sémantique ARIA d’une fenêtre modale ou d’un menu, comme le détaille Construire des composants React accessibles avec ARIA. La troisième verrouille l’ensemble : un filet de tests automatisés qui, en intégration continue, bloque toute régression d’accessibilité avant la fusion — c’est l’objet de Tester l’accessibilité en intégration continue. Pour la vue conçue côté utilisateur et conception, l’article Accessibilité web : concevoir pour tous les utilisateurs offre un complément utile.

Comment ces ponts se rejoignent

L’intérêt de la démarche n’apparaît pleinement que lorsqu’on voit les trois ponts fonctionner ensemble. Imaginez le cycle complet. Un designer ajuste la couleur d’action dans Figma. À la prochaine intégration, le script d’extraction récupère la nouvelle valeur, Style Dictionary régénère les variables CSS, et tous les composants qui consomment color.action changent de teinte — sans qu’une seule ligne de code soit modifiée à la main. Le même composant, relié par Code Connect, affiche toujours dans Dev Mode l’usage exact que les développeurs doivent reproduire. Et quand quelqu’un modifie ce composant, les tests d’accessibilité vérifient automatiquement qu’il reste utilisable au clavier et correctement annoncé, refusant la fusion si une régression s’est glissée.

Ce cycle transforme la nature du travail. Les tâches mécaniques et fragiles — recopier, deviner, corriger après coup — sont absorbées par des pipelines. Le temps humain se reporte sur ce qui en vaut la peine : les décisions de design, la qualité des contenus, le jugement sur l’expérience réelle. C’est exactement le mouvement qu’a connu le reste du développement logiciel avec les tests automatisés et l’intégration continue ; le design côté code n’est que l’extension de cette discipline au territoire de l’interface.

Le paysage des outils

Aucun outil n’est imposé pour construire cette chaîne ; il est utile de connaître les options et leurs compromis avant de s’engager, car migrer plus tard coûte cher. Le paysage se range selon les trois ponts.

Pour extraire les valeurs, deux voies coexistent. L’API Variables de Figma offre l’accès le plus direct et le plus fidèle, mais elle suppose un plan Enterprise. Le plugin Tokens Studio, lui, est accessible à tous les plans et stocke nativement les tokens au format du W3C, avec une synchronisation possible vers un dépôt Git ; c’est souvent le point d’entrée des équipes qui débutent. Le critère de choix n’est pas la richesse fonctionnelle mais l’accès : on prend l’API si on l’a, le plugin sinon — et la suite de la chaîne est identique puisque le format de sortie est le même standard ouvert.

Pour générer les sorties, Style Dictionary fait figure de référence par sa neutralité : il ne privilégie aucune plateforme et se laisse étendre. Des solutions alternatives existent, souvent plus spécialisées ou liées à un écosystème précis, mais le principe « source → transforms → format » qu’incarne Style Dictionary s’est imposé comme le modèle mental commun. Comprendre ce modèle vaut mieux que mémoriser un outil : il se transpose à n’importe quel générateur.

Pour l’accessibilité, l’écosystème s’organise autour du moteur axe-core, présent partout : dans l’extension de navigateur que les développeurs utilisent à la main, dans les intégrations de test (jest-axe, vitest-axe, @axe-core/playwright), et dans des outils d’audit de page comme Lighthouse. Le moteur étant commun, les résultats sont cohérents d’un niveau de test à l’autre ; ce qui change, c’est le moment et la portée du contrôle. À côté, le linter jsx-a11y agit en amont, sur le source, sans rien exécuter. Là encore, le bon réflexe est de superposer les outils selon ce qu’ils voient, plutôt que d’en chercher un seul qui ferait tout.

Un mot sur la tentation de tout déléguer à une bibliothèque de composants « clé en main ». Ces bibliothèques peuvent rendre d’immenses services, à condition de vérifier qu’elles assument réellement les trois responsabilités d’un composant accessible — sémantique, focus, clavier. Une bibliothèque qui les couvre fait gagner un temps considérable ; une qui se contente d’un joli rendu déplace le problème sans le résoudre. Le discernement décrit dans ce parcours sert précisément à juger un tel outil avant de l’adopter.

Adopter la démarche dans une équipe existante

Sur un projet vierge, mettre en place cette chaîne est simple. La vraie question, pour la plupart des équipes, est de l’introduire dans une base de code déjà vivante, avec sa dette et ses habitudes. L’erreur serait de vouloir tout convertir d’un coup ; l’approche qui réussit est incrémentale et guidée par la valeur.

Le point de départ le plus rentable est généralement le filet d’accessibilité, parce qu’il protège l’existant sans rien réécrire. On installe le linter jsx-a11y et un premier test de page en intégration continue, on fige les violations connues comme référence, et on interdit toute nouvelle régression. Dès ce moment, la qualité cesse de se dégrader, même avant qu’on ait corrigé le passif. C’est un gain immédiat, peu risqué, qui crée l’adhésion nécessaire pour la suite.

La deuxième étape consiste à introduire les tokens progressivement. Inutile de migrer toute la charte d’emblée : on commence par les couleurs, le poste le plus visible et le plus sujet aux incohérences. On extrait, on génère des variables CSS, et on remplace les valeurs en dur au fil des fichiers touchés, sans grand chantier dédié. Les espacements, rayons et typographies suivent au même rythme. Chaque token migré réduit la surface de divergence, et le bénéfice se cumule sans jamais bloquer les livraisons en cours.

Le pont Code Connect vient en dernier, car il suppose des composants déjà stabilisés côté code et côté design. On le réserve aux composants les plus repris, pour maximiser le retour. Tout au long de cette adoption, un principe guide les arbitrages : chaque brique doit apporter une valeur autonome, mesurable, sans dépendre des autres pour être utile. C’est ce qui rend la démarche soutenable dans la durée — on n’attend jamais un grand basculement, on récolte à chaque pas. La collaboration s’en trouve aussi clarifiée : le designer possède la source dans Figma, le développeur possède la transformation et les composants, et l’intégration continue arbitre objectivement la qualité. Personne ne recopie le travail d’un autre, et les désaccords se règlent sur des faits — un test qui passe ou qui échoue — plutôt que sur des interprétations.

À quoi reconnaît-on que la chaîne fonctionne

Mettre en place des pipelines est un moyen, pas une fin ; il faut savoir en lire les effets pour ne pas entretenir une mécanique qui tourne à vide. Quelques signaux concrets indiquent que la démarche porte ses fruits.

Le premier signal est la disparition de la dérive. Avant, un changement de couleur dans la charte mettait des jours à se refléter dans le produit, et certains écrans restaient sur l’ancienne valeur indéfiniment. Avec la chaîne en place, l’écart entre la maquette et le produit livré se mesure en minutes, le temps d’un build. Si vous constatez encore des couleurs « oubliées » quelque part, c’est qu’il reste des valeurs en dur à migrer vers les tokens.

Le deuxième signal est la baisse des allers-retours d’intégration. Quand le Dev Mode affiche le vrai composant, les questions « quelle prop passer ? » et « ce n’est pas le bon composant » s’éteignent. Une chute du nombre de corrections post-intégration, et des revues de code qui portent sur la logique plutôt que sur la conformité à la maquette, sont des marqueurs fiables.

Le troisième signal est le plus parlant : des régressions d’accessibilité interceptées avant la mise en production. Chaque pull request bloquée par le filet pour une étiquette manquante ou un contraste insuffisant est un défaut qui n’atteindra jamais un utilisateur. À l’inverse, si le filet ne se déclenche jamais, méfiez-vous : il est peut-être mal câblé et laisse tout passer. Un filet sain attrape régulièrement de petites fautes — c’est le signe qu’il travaille.

Enfin, un signal plus diffus mais décisif : l’équipe cesse de percevoir tokens et accessibilité comme des corvées séparées du « vrai » développement. Quand poser un token plutôt qu’une valeur en dur, ou vérifier le focus d’un composant, devient un réflexe aussi naturel qu’écrire un test, la démarche a réellement pris. C’est à ce moment que le design côté code cesse d’être un projet pour devenir une manière de travailler.

Les tutoriels du parcours

• Extraire les design tokens depuis Figma avec l’API Variables — lire la charte par programme et produire un fichier de tokens au format W3C.
• Générer ses design tokens en CSS, JS et SCSS avec Style Dictionary — un fichier source, plusieurs sorties, une commande.
• Relier Figma et React avec Dev Mode et Code Connect — afficher le vrai code de vos composants dans Figma.
• Implémenter les nouveaux critères WCAG 2.2 en code — taille de cible, focus, glissement, authentification.
• Construire des composants React accessibles avec ARIA — focus, clavier et sémantique d’une modale.
• Tester l’accessibilité en continu : axe-core, Playwright, jsx-a11y — un filet à trois niveaux dans l’intégration continue.

Erreurs fréquentes à éviter

FAQ

Faut-il un plan Figma payant pour suivre ce parcours ?
L’API Variables et le Dev Mode supposent des plans payants, mais le premier tutoriel décrit une alternative gratuite via le plugin Tokens Studio, et la majorité des tutoriels d’accessibilité ne dépendent d’aucun outil Figma.

Ce parcours est-il réservé à React ?
Les principes — tokens, source unique de vérité, accessibilité au niveau du code — sont universels. Les exemples de composants et de Code Connect utilisent React, mais Code Connect et les outils de test couvrent aussi d’autres technologies comme Vue, Angular et les Web Components.

Dois-je tout mettre en place d’un coup ?
Non. Chaque pont apporte une valeur autonome. Commencer par les tokens, ou par l’accessibilité, est tout aussi valable. L’ordre proposé est pédagogique, pas impératif.

Quelle différence entre design tokens et variables CSS ?
Les variables CSS sont une sortie possible des design tokens. Un token est une définition neutre, indépendante de toute plateforme ; la variable CSS en est la traduction pour le web, au même titre qu’une constante JavaScript pour le code applicatif.

WCAG 2.2 remplace-t-elle WCAG 2.1 ?
Elle l’étend : tous les critères de 2.1 demeurent, à l’exception du critère 4.1.1 devenu obsolète, et neuf critères s’ajoutent. Viser la conformité 2.2 niveau AA couvre donc 2.1.

Combien de temps pour traverser tout le parcours ?
Comptez environ quatre à cinq heures de pratique cumulée pour les six tutoriels, davantage si vous appliquez chaque étape à un projet réel — ce qui est la meilleure façon d’apprendre.

Pour aller plus loin

• Vue conception du référentiel : Design system : construire et maintenir un référentiel.
• Audit et conformité : RGAA et WCAG 2.2 : checklist d’audit d’accessibilité.
• Standard des tokens : designtokens.org — le format du W3C.
• Référence WCAG : W3C — What’s New in WCAG 2.2.