Figma Dev Mode : promesse tenue ou gadget pour les équipes produit ?
Depuis son lancement en 2023, Figma Dev Mode ambitionne de résoudre l’un des problèmes les plus persistants du développement produit : la friction entre design et développement. L’idée est séduisante : un espace dédié aux développeurs, directement dans l’outil de design, avec des specs, du code généré et un suivi des changements.
Deux ans plus tard, le bilan est contrasté. D’un côté, des fonctionnalités qui ont réellement amélioré le quotidien de certaines équipes. De l’autre, un modèle de pricing qui a provoqué une levée de boucliers dans la communauté, des snippets de code que peu de développeurs utilisent en production, et un écosystème qui évolue si vite (MCP, Code Connect, IA générative) que le périmètre même de Dev Mode se redéfinit en permanence.
Ce que Dev Mode apporte concrètement
Un espace de lecture dédié aux développeurs
Dev Mode transforme l’interface Figma en un environnement lecture seule optimisé pour l’implémentation. Premier avantage : aucun risque de modifier le fichier design par erreur.
Le panneau d’inspection affiche les propriétés de chaque élément sélectionné : dimensions, espacements, couleurs, typographies, rayons de bordure, avec les valeurs exactes.
Le Component Playground permet d’explorer toutes les variantes d’un composant et de voir le code associé, sans quitter Figma.
Le workflow Ready for dev : un signal clair entre design et développement
Les designers marquent des sections ou des frames comme « Ready for dev ». Ce statut crée une file d’attente visible pour les développeurs, directement dans l’outil.
En Dev Mode, seuls les éléments marqués sont mis en avant. Le reste du fichier reste accessible, mais relégué au second plan.
La comparaison de versions permet de voir ce qui a changé entre deux itérations d’un même frame, ce qui réduit considérablement les échanges du type « qu’est-ce qui a bougé ? ».
Les variables et tokens enfin visibles côté développeur
Dev Mode affiche la chaîne complète d’aliasing d’une variable : de la valeur primitive jusqu’au token sémantique appliqué.
Les modes (light/dark, marques) sont visibles et navigables. Un développeur peut comprendre quelle valeur s’applique dans quel contexte, sans demander au designer.
C’est probablement l’apport le plus significatif pour les équipes qui travaillent avec un Design System structuré.
Ce que Dev Mode ne résout pas (et ne prétend pas résoudre)
Les snippets de code : utiles en contexte, rarement en production
Par défaut, Dev Mode génère des snippets CSS, iOS et Android génériques basés sur les propriétés visuelles de chaque élément.
Ces snippets ne tiennent pas compte du Design System, des conventions du projet ni de l’architecture du code. Ils servent de référence visuelle, pas de code à copier-coller en production.
Code Connect (plans Organization et Enterprise) améliore considérablement la situation en liant les composants Figma au vrai code du projet. Mais c’est un investissement de configuration initial significatif. Comme le note un reviewer : le code généré reste « un exemple pour les développeurs », pas du code production-ready.
Le handoff ne se réduit pas aux specs visuelles
Dev Mode excelle dans la transmission des propriétés visuelles, mais ne capture pas l’intention de design. Les interactions, les edge cases et les comportements conditionnels restent à communiquer par d’autres canaux.
Les annotations aident, mais ne remplacent pas la conversation. Les équipes qui réussissent le handoff combinent Dev Mode avec des rituels de synchronisation : design reviews, sessions pair design-dev.
Figma est un outil à canvas libre : les designers peuvent organiser leurs fichiers comme ils le souhaitent, sans structure imposée. Pour un développeur habitué à des interfaces organisées par sections ou par écrans, naviguer dans un fichier mal structuré reste déroutant. Le statut « Ready for dev » aide, mais un fichier mal organisé reste un fichier mal organisé.
L’export de tokens : un angle mort persistant
Il n’existe pas de bouton natif « exporter les tokens vers le code » dans Figma. Le passage des Variables Figma aux variables CSS, SCSS ou Swift nécessite des plugins tiers (Tokens Studio) ou des scripts custom (Style Dictionary).
Cette lacune oblige les équipes à maintenir une chaîne d’outillage parallèle pour la synchronisation design-code des tokens.
Le format W3C Design Tokens (DTCG) progresse vers un standard, mais Figma ne l’implémente pas encore nativement.
Le sujet qui fâche : le pricing du Dev Mode
Ce qui a changé et pourquoi ça pose problème
Avant Dev Mode, Figma offrait gratuitement un panneau Inspect accessible à tous les viewers. Les développeurs pouvaient consulter les specs sans licence payante.
Avec le passage à Dev Mode payant en 2024, cette fonctionnalité de base a été retirée du mode gratuit et déplacée derrière un siège Dev ou Full.
Le coût d’un siège Dev varie selon le plan (environ 12 à 35 $/mois/siège). Pour une équipe avec un ratio développeurs/designers de 3:1 ou 4:1, cela peut doubler ou tripler le budget Figma d’un coup.
Le problème spécifique des freelances et des agences
Le siège Dev est lié à l’organisation, pas à l’individu. Un développeur freelance qui travaille avec plusieurs agences doit être ajouté et payé dans chaque organisation séparément.
Un freelance qui paie son propre abonnement Figma ne peut pas utiliser Dev Mode sur les fichiers d’une autre organisation.
Cette architecture de licensing a été qualifiée de « double dipping » par de nombreux utilisateurs sur le forum Figma. C’est un irritant majeur pour les petites structures, et le sujet reste ouvert dans la communauté.
Ce que cela signifie pour la décision d’achat
Pour les grandes organisations déjà sur un plan Enterprise, l’ajout de sièges Dev est un surcoût absorbable si le ROI en réduction de friction est démontré.
Pour les équipes petites ou moyennes, le calcul est moins évident. Beaucoup de développeurs n’utilisent qu’une fraction des fonctionnalités de Dev Mode : copier un hex, vérifier un espacement.
La question à se poser est simple : combien de temps mes développeurs passent-ils réellement dans Figma, et sur quelles tâches ? Si la réponse est « peu et ponctuellement », le panneau Properties gratuit peut suffire.
L’accélération récente : MCP, Code Connect et IA générative
Le serveur MCP Figma : le design comme contexte pour l’IA
Lancé en bêta fin 2025, le serveur MCP (Model Context Protocol) de Figma permet aux outils de codage assistés par IA (VS Code, Cursor, Windsurf, Claude Code) de lire directement la structure d’un fichier Figma.
Contrairement à un screenshot, le MCP transmet des données structurées : arbre de nœuds, contraintes de layout, tokens, références de composants. L’IA dispose du contexte réel du design, pas d’une image.
Affirm rapporte avoir reconstruit des parcours produit majeurs en moins de deux jours grâce à cette intégration.
Le MCP redéfinit le rôle de Dev Mode : il n’est plus seulement un outil d’inspection, il devient le point d’entrée vers une génération de code contextuelle.
Code Connect : relier les composants Figma au vrai code
Code Connect permet de mapper chaque composant Figma à son implémentation réelle dans le codebase (React, SwiftUI, Jetpack Compose).
Quand un développeur inspecte un composant en Dev Mode, il voit le code de son Design System plutôt que du CSS générique. La configuration se fait désormais directement dans Figma, ce qui abaisse significativement la barrière d’entrée.
Une limite à noter : Code Connect nécessite un plan Organization ou Enterprise. Les équipes Pro n’y ont pas accès.
Les limites actuelles du design-to-code par IA
Le MCP fournit le contexte design, mais l’IA n’a aucune visibilité sur le rendu final de son propre code. Elle ne peut pas vérifier si un style global écrase son output.
Même avec Code Connect, l’IA peut générer des styles ad hoc quand elle rencontre un cas non mappé. La cohérence n’est pas garantie automatiquement.
Le workflow reste un complément, pas un remplacement. Le développeur reste indispensable pour valider, ajuster et intégrer dans l’architecture existante.
Dev Mode dans l’écosystème : comment le situer par rapport aux alternatives
Supernova : structurer et industrialiser le design system jusqu’au code
Supernova se positionne différemment des outils de handoff classiques : la plateforme ne se limite pas à la transmission des maquettes, mais vise à structurer l’ensemble du design system jusqu’à son implémentation.
Connecté à Figma, Supernova permet de transformer des composants en documentation vivante, en tokens et en code directement exploitable par les équipes de développement. Là où Figma Dev Mode reste centré sur l’inspection et la collaboration, Supernova introduit une couche de formalisation et de gouvernance.
Pour les organisations qui cherchent à industrialiser leurs design systems, avec des règles, des standards et une synchronisation forte entre design et code, Supernova offre un cadre plus structurant.
Storybook : la source de vérité côté code
Storybook n’est pas un outil de handoff. C’est le standard de facto pour documenter et tester les composants côté développement.
Dev Mode et Storybook sont complémentaires : Dev Mode sert de pont du design vers le code, Storybook sert de référence vivante côté code.
L’intégration Dev Resources de Figma permet de lier directement un composant à sa page Storybook, créant un chemin continu : design, specs, documentation, code.
La grille de décision : quel outil pour quel contexte
Équipe tout-Figma avec un Design System structuré et un budget Enterprise : Dev Mode + Code Connect + Storybook est la combinaison la plus intégrée.
Équipe avec un processus de validation formel et des parties prenantes non-techniques (PO, QA, marketing) : Zeplin en complément de Figma apporte un espace de collaboration plus lisible.
Petite équipe ou freelances avec un budget limité : le panneau Properties de Figma (gratuit) combiné à un bon nommage des couches et des conventions de fichiers peut suffire.
Dans tous les cas : aucun outil ne remplace la communication humaine. Les équipes qui réussissent le handoff investissent dans des rituels autant que dans des outils.
Alors, promesse tenue ou gadget ?
Dev Mode est un outil réel qui répond à des besoins concrets : inspection, comparaison de versions, visibilité des tokens. Mais il ne tient pas toutes ses promesses, notamment sur la génération de code et son coût.
Sa plus grande force est la transparence sur les variables et les tokens. Pour les équipes qui ont investi dans un Design System structuré, c’est un changement de paradigme dans la lisibilité côté développeur.
Son plus grand défaut reste le pricing. En rendant payante une fonctionnalité d’inspection qui était gratuite, Figma a créé une fracture dans sa communauté qui n’est toujours pas cicatrisée.
L’arrivée du MCP et de Code Connect change la donne. Dev Mode n’est plus seulement un panneau d’inspection : il devient le hub de connexion entre le design et les outils de développement assistés par IA.
La vraie question pour chaque équipe n’est pas « Dev Mode est-il bon ? » mais : notre workflow justifie-t-il son coût, et avons-nous le Design System pour en tirer la pleine valeur ?
