Dev Mode Figma, effet de mode ou pas ?

Depuis fin janvier 2024, la version beta gratuite du Dev Mode, c’est fini ! Désormais un siège coûte 25€/mois pour une entreprise. Cela nous a, assez logiquement, conduit à nous confronter à un choix simple : poursuivre sur la version payante ou bien arrêter. 

Pour rappel, le Dev Mode est un espace dans Figma présenté lors de la dernière édition de la conférence Config et qui est dédié aux développeurs pour leur permettre de collecter toutes les infos & assets d’une maquette (voire de les transformer directement en code) en vue de l’intégration. Mais qu’en est-il vraiment ? Après plusieurs mois de tests en beta, nos designers et nos développeurs ont fait leur choix d’une même voix : on vous explique lequel et pourquoi. 

C’est quoi déjà le Dev Mode Figma ? 

Avant tout, retour sur cette petite révolution annoncée en juin dernier, qui promettait de transformer l’approche du design, la faisant glisser vers un mode “design to code” et établissant un véritable lien entre développeurs et designers pour unifier la chaîne de production digitale. Concrètement, le Dev Mode est une interface simplifiée où les assets et les informations sur les éléments et les composants (couleurs, tailles, etc.) sont plus facilement accessibles : une évolution significative de l'inspecteur situé dans la barre latérale, fournissant aussi de nombreux insights essentiels aux développeurs. 

Côté fonctionnalités, on retrouve la possibilité de :

• Naviguer entre les assets prêts pour le développement, les extraire, les exporter
• Naviguer entre les images
• Identifier facilement les modifications entre les versions, comparer les maquettes
• Ajouter des liens et des ressources externes tels que des liens vers Storybook, Jira, etc.
• Visualiser les styles appliqués
• Faire des annotations (nouvelle fonctionnalité très pratique ajoutée depuis l’arrêt de la bêta fin janvier)
• Et enfin, gros atout sur le papier, générer du code personnalisable 

Pas de Dev Mode pour nous : c’est tout, pour le moment

Malgré tous les avantages des fonctionnalités précédemment évoquées, nous avons décidé de ne pas utiliser le Dev Mode à date. Et c’est une décision longuement réfléchie issue d’une phase de test et d’échanges entre les équipes design et développement (web & mobile). Il en est ressorti que, bien que l'équipe design ait trouvé le Dev Mode réellement intéressant et bénéfique, notamment pour son intégration similaire à Zeplin, il n’en a pas été de même pour l’équipe de développement. En effet, après avoir testé la version beta, nos lead développeurs ont constaté que, mis à part l'amélioration de l'accès aux informations de l'Inspecteur, le Dev Mode ne leur apportait pas d'avantages significatifs. 

Plus précisément, nos développeurs ne se sont servis du Dev Mode que pour passer les différentes sections en mode « Ready to Dev » et pour collecter les informations de marges des blocs ou d’autres composants. Finalement, toutes les autres informations, comme les typographies ou les couleurs, se retrouvent déjà sur l’inspecteur basique, il n’y a donc pas de besoin réel pour l’instant de foncer sur le Dev Mode. 

D’autre part, si le code qui peut être généré est “valable”, il n’est à leur sens pas exploitable en l’état car pas suffisamment optimisé pour les développeurs les plus aguerris sur leur technologie. On voit d’ailleurs déjà apparaître certaines extensions comme Locofy, qui ajuste le code de Figma pour qu’il soit mieux adapté aux différentes solutions web du marché, démontrant bien que le code généré actuellement n’est pas encore optimum.

Le code made in Dev Mode a le mérite d’exister et peut être utile pour certains devs, mais n’est pas suffisamment propre et structuré à date pour nos projets web complexes. Cela nécessite de repasser dessus, notamment pour rendre le code plus léger, plus véloce, plus dynamique et faire valoir les principes d’éco-conception, ce qui représente au final une perte de temps pour nous. Par exemple, le Dev Mode génère du CSS mais en réalité nous n’écrivons plus de CSS directement, nous utilisons entre autres Tailwind CSS, qui nous permet déjà d’optimiser le rendu final en regroupant tout dans un seul fichier de style (sans duplication), de simplifier le template final en utilisant les classes, de visualiser les couleurs ou la font qu’on utilise, etc.

Gaëtan Senn, Développeur full stack

Nous ne doutons pas de la pertinence du Dev Mode quand il s’agit de générer quelque chose de temporaire. Cela peut donc être très utile en phase de POC puisque cela permet de coder rapidement. De la même façon, le Dev Mode peut sembler une bonne option pour des petites structures, surfant sur la vague du no-code qui reste pertinente pour des services simples avec un nombre d’utilisateurs modéré. Mais quand il s’agit de projets s’intégrant dans des écosystèmes plus complexes, comme la quasi-totalité de ceux déployés chez USERADGENTS, cela ne suffit pas. Sur le web, comme pour les applications mobiles. 

Côté app mobile, le Dev Mode peut être utile pour générer des aperçus rapides ou des prototypes, mais la logique de composants n’est pas encore au rendez-vous. Le Dev Mode produit des ébauches de code SwiftUI ou Kotlin. Ce n’est pas pensé pour la réutilisation du code produit, il faut toujours retravailler le rendu par la suite. Les dev n’ont pas besoin qu’on écrive un layout pour eux, ils ont besoin qu’on leur automatise le design system. Si Figma pouvait gérer tout seul un package qui implémente tout le design system d’une app qu’on aurait plus qu’à exploiter, là bien sûr, jackpot.  

Cyrille Legrand, Lead Dev iOS

Alors maintenant, c’est quoi le programme ? 

Une chose est sûre : nous allons continuer à utiliser Figma. Et le fait que nous nous passions, pour le moment, du Dev Mode, ne va pas grandement impacter notre quotidien. 

Même si l’engouement de la communauté des designers autour du Dev Mode est tout à fait compréhensible, nous avons préféré adopter une philosophie légèrement différente de celle très “low-code” de Figma. L’optique ? Favoriser une vraie collaboration main dans la main, où les designers pensent les interfaces pour servir aussi les enjeux des développeurs, en termes de performance ou de RSE notamment. Nous pensons qu’il n’est pas réellement viable d’imposer aux développeurs une manière d’utiliser leurs entrants, il faut trouver une manière de faire et un process qui conviennent à tous, en évitant par exemple de sur-structurer les maquettes si au final cela complexifie le travail du reste de l’équipe projet (chefs de projet, devs…). 

Ces réflexions autour du Dev Mode nous ont permis d’améliorer et fluidifier la collaboration entre nos équipes qui, pour devenir plus étroite, nécessite l’établissement d’une nomenclature commune à tous et implique de revoir et préciser certains de nos process. Par exemple, nous allons encore plus nous baser sur les variables de Figma (une autre nouveauté disponible dans Figma depuis Config 2023, à retrouver dans notre récap’ par ici), qui, même si elles sont en bêta, nous permettent de véritablement poser un socle solide en nous basant sur des valeurs primitives et des design tokens. Nous comptons aussi réduire la voilure sur la présence de booléens dans les composants pour garder une présentation intelligible de nos design systems auprès des développeurs mais aussi auprès de nos clients. En fait, c’est une des briques du Dev Mode qui permet de jouer avec les variants que nous cherchons à “contourner” en amenant de la simplification dans notre organisation.