Ton design system parle maintenant à une IA : ce qui change vraiment dans Figma en 2026

Le jour où un agent a lu mon design system mieux que mon client

Sur un mandat récent pour une PME québécoise multi-marques, j'ai branché un agent de code sur le serveur MCP de Figma et je lui ai demandé de générer un formulaire d'inscription à partir de la maquette. En quinze secondes, il a sorti du code React qui utilisait les bons tokens de couleur, le bon espacement, le bon composant de bouton — pas une approximation visuelle, les vraies variables nommées de la bibliothèque. Mon client, lui, détachait encore des composants à la main trois mois plus tôt. C'est à ce moment que la bascule est devenue évidente : le design system ne sert plus seulement à aligner des humains. Il sert à rendre une intention de design lisible par une machine.

C'est le glissement que Figma a lui-même mis en mots à Schema 2025, sa conférence dédiée aux design systems, le 28 octobre 2025 : les design systems passent « de standards statiques à des systèmes vivants », et deviennent « la traduction dont l'IA a besoin pour comprendre le design et le code ». Pendant vingt ans, on a vendu le design system comme une source de vérité pour l'équipe. En 2026, c'est toujours vrai, mais c'est devenu secondaire. La vraie valeur est ailleurs : un système bien tokenisé est aujourd'hui un coefficient de productivité pour tout ce que tu génères avec l'IA, et un système mal foutu produit du code généré tout aussi incohérent que tes maquettes.

Pourquoi la couche de traduction compte plus que la bibliothèque

Le maillon technique de cette bascule, c'est le serveur MCP de Figma, sorti de bêta et passé en disponibilité générale en 2025. Le Model Context Protocol permet à un outil de codage agentique — Claude Code, Cursor, l'éditeur de ton choix — d'aller chercher le contexte directement dans Figma : la structure d'un écran, les noms de composants, les variables associées. Couplé à Code Connect, qui mappe chaque composant Figma à son équivalent codé réel dans ton dépôt, l'agent ne voit plus un extrait CSS générique : il voit le composant Button de ton design system, avec ses props.

La nouveauté de 2025 qui change la donne pour les petites équipes, c'est le Code Connect UI. Avant, établir ce lien design-code demandait d'écrire des fichiers de configuration à la main — un frein réel quand on est seul ou à deux. Désormais, on connecte Figma directement à un dépôt GitHub depuis l'interface, et une fonction de suggestion par IA propose quel fichier de code mapper à quel composant, sans écrire une ligne. J'ai longtemps considéré Code Connect comme un luxe d'équipe de plateforme. Avec cette version, c'est devenu accessible à un studio d'une personne, et je l'active maintenant par défaut sur tout projet qui a un design system codé.

Ma conviction, après avoir testé ça sur des mandats réels : la qualité de génération de ton IA est plafonnée par la qualité de ta tokenisation. Si tes couleurs s'appellent bleu-2 et bleu-clair-final-v3, aucun agent ne devinera lequel est ta couleur d'action. Si elles s'appellent color/action/primary, il le devine — et un humain aussi. La discipline de nommage n'est plus une coquetterie de designer maniaque ; c'est ce qui détermine si ton système est exploitable par une machine.

La spec Design Tokens est enfin stable — et ça périme ton ancien pipeline

Le deuxième grand événement de la fin 2025 est passé plus inaperçu, mais il est structurant. Le 28 octobre 2025, le Design Tokens Community Group du W3C a publié la première version stable de sa spécification, la 2025.10. Pendant des années, on a travaillé avec un brouillon mouvant — j'ai moi-même bâti des pipelines sur des formats qui changeaient à chaque release. C'est fini : il existe maintenant un format d'échange neutre, stable, supporté par plus de dix outils dont Figma, Tokens Studio, Penpot, Sketch et Framer.

Ce que la 2025.10 apporte concrètement et qui justifie de revoir un vieux setup : le support des espaces colorimétriques modernes — Display P3, Oklch et l'ensemble de CSS Color Module 4 — alors que l'ancien format se limitait en pratique à l'hexadécimal. Une couleur n'est plus une chaîne #0066FF mais un objet qui porte son espace colorimétrique, ses composantes, son alpha et une valeur hexadécimale de repli. Même logique pour les dimensions et les durées, qui deviennent des objets structurés avec une valeur et une unité (value 16, unit px) au lieu d'une chaîne ambiguë. Pour quelqu'un qui génère du CSS, du Swift et du Compose à partir d'une source unique, c'est exactement la précision qui manquait.

Côté outillage, Style Dictionary — la référence pour transformer des tokens en code — est passé en version 5, alignée sur cette spec. Le format d'export par défaut est désormais le JSON DTCG, les transformations gèrent nativement les nouveaux types d'objets, et la version exige Node 22. Si tu fais encore tourner du Style Dictionary v4 sur un vieux format de tokens, tu n'es pas cassé, mais tu accumules une dette qui va se payer au prochain refactor de thème. Et bonne nouvelle pour ceux qui restent dans Figma : l'import/export natif des variables, attendu depuis des années, est arrivé en novembre 2025 — Figma a délibérément attendu que la spec DTCG atteigne sa 1.0 avant de le livrer, précisément pour ne pas enfermer les gens dans un format propriétaire.

Ce que Figma a réellement livré en 2025 (au-delà du marketing)

Il faut séparer les annonces spectaculaires des gains réels de workflow. Config 2025 a surtout fait parler de quatre nouveaux produits — Figma Sites, Figma Make, Figma Buzz et Figma Draw — qui sont intéressants mais périphériques pour un design system. Le vrai cadeau était moins sexy : Figma a complété une réécriture massive de l'architecture de ses design systems. Résultat mesuré et annoncé par Figma, mettre à jour des variables ou changer de mode est 30 à 60 % plus rapide, et certaines opérations lourdes de bascule d'état sont passées de 3500 ms à 350 ms. Quand on travaille toute la journée dans un fichier de système complexe, c'est le genre de gain qu'on sent physiquement.

Élément	Avant	En 2026
Spec Design Tokens W3C	brouillon (Second Editor's Draft)	version stable 2025.10 (28 oct. 2025)
Style Dictionary	v4	v5 (export DTCG par défaut, Node 22)
Modes de variables Figma	4 maximum	10 (Professional) / 20 (Organization)
Bascule de mode (perf)	lente sur gros fichiers	30-60 % plus rapide ; 3500 ms → 350 ms
Lien design-code	config manuelle	Code Connect UI + serveur MCP (GA)

Trois fonctionnalités de Schema 2025 méritent qu'on les adopte. Les Extended collections règlent enfin le casse-tête du multi-marques : une équipe peut publier une version « marque blanche » du système que les autres étendent avec leur thème propre, tout en héritant automatiquement des mises à jour du système parent. Sur mon mandat multi-marques, c'est précisément ce qui me manquait pour éviter de dupliquer des collections entières. Les Slots corrigent une limite vieille comme les composants Figma : on peut désormais insérer ses propres calques dans une instance — penser à une liste déroulante à laquelle on ajoute des éléments — sans détacher le composant et briser le lien avec le système. Et le linter Check designs détecte les valeurs brutes qui devraient être des variables et suggère le bon token avant le handoff, ce qui élimine la question éternelle du dev : « tu as utilisé quel token, exactement ? »

Détail qui compte si ton système grossit : la limite de modes de variables, longtemps bloquée à quatre, est montée à 10 sur le plan Professional et 20 sur Figma Organization. Quatre modes, c'était suffisant pour clair/sombre plus deux marques ; au-delà, on était coincé. Ce n'est pas une révolution, mais c'est exactement le mur sur lequel butent les systèmes qui réussissent.

Construire pour 2026 sans se fabriquer une usine à gaz

Le risque, en lisant tout ça, c'est de vouloir tout brancher d'un coup — MCP, Code Connect, pipeline Style Dictionary, dix modes — sur un projet qui n'en a pas besoin. Je le dis nettement parce que je l'ai fait : sur-architecturer un design system est aussi coûteux que ne pas en avoir. La plupart des PME avec qui je travaille n'ont pas besoin de vingt modes ni d'un pipeline CI/CD de tokens. Elles ont besoin de trois choses faites correctement : une convention de nommage sémantique qui se traduit telle quelle en code (color/surface/primary devient --color-surface-primary), une vingtaine de tokens de couleur bien choisis plutôt que deux cents nuances jamais utilisées, et le lien design-code activé une fois que le système est stable.

L'ordre compte. Je commence toujours par la discipline de tokens, parce que c'est ce qui rend tout le reste possible — y compris la lisibilité par l'IA. J'ajoute Code Connect et le MCP seulement quand le design system a prouvé qu'il était stable, jamais sur un système encore en mouvement, sinon on maintient des liens vers des composants qui changent toutes les semaines. Et je résiste à la tentation d'adopter chaque nouveauté annoncée : un système qu'on ne maintient pas est un système mort, peu importe le nombre de features cochées.

La vraie question de 2026 n'est plus « est-ce que j'ai besoin d'un design system ». C'est « est-ce que mon système est assez propre pour qu'une machine le comprenne sans moi ». Si la réponse est non, ce n'est pas Figma qu'il faut mettre à jour — c'est ta convention de nommage. Le reste, l'outillage l'a déjà rattrapé.