Workflow lab : passer du design au code grâce aux agents

Les agents de codage transforment la programmation, mais leur efficacité dépend de la qualité des données. Ce workflow examine la synchronisation code-canvas.
Partager Workflow lab : passer du design au code grâce aux agents
Illustration principale par Marine Buffard
Bienvenue dans Workflow Lab, où nous présentons un exemple de workflow utilisant les produits et les outils Figma.
Fiche d'informations sur le workflow :
Produits Figma : Figma Design, FigJam
Outils : Figma MCP server, Code Connect, use_figma, generate_diagram, search_design_system, generate_figma_design, get_variable_defs
Équipe : designer produit, responsable des design systems, ingénieur logiciel
Problème à résoudre : Et si le résultat de votre agent de codage pouvait être prêt pour la production plus rapidement ?
L'équipe d'ingénierie de Radicle, une application fictive d'apprentissage des STIM, avance plus vite que jamais. Un travail qui prenait des semaines prend à présent des jours, voire des heures. Pour autant, cette rapidité ne la mène pas bien loin ; le code généré par son IA s'écarte le plus souvent des spécifications de conception. L'équipe fournit à son agent de codage des captures d'écran et des tickets de développement comme base de travail, mais cela ne suffit pas pour obtenir des résultats corrects, et l'équipe se retrouve bloquée à devoir retravailler les résultats.
Et si la première version générée par l'IA était plus proche d'être prête pour la production ? En disposant de davantage de contexte de conception (par exemple, des composants approuvés et des tokens documentés dans Figma), un agent de codage peut cerner votre intention en moins de prompts. Dans cet exemple de workflow, un développeur de Radicle utilise les outils de développement Figma afin de fournir un meilleur contexte à son agent de codage pour qu'il puisse générer un code de meilleure qualité. Suivez les étapes pour découvrir comment le développeur maintient une parfaite cohérence entre le design et le code d'une nouvelle fonctionnalité, du premier wireframe jusqu'à la validation finale.
Le problème
L'équipe de Radicle souhaite moderniser la messagerie où les étudiants peuvent communiquer avec les enseignants et leurs camarades. Tout d'abord, elle prévoit d'ajouter un nouveau flux de mise à jour en masse, qui comportera trois interfaces : une barre d'outils, une fenêtre modale et un toast (une notification temporaire). La barre d'outils permettra à l'utilisateur de sélectionner tous ses messages, de les supprimer ou de les marquer comme non lus, la fenêtre modale lui demandera de confirmer ou d'annuler l'action et, enfin, le toast indiquera si l'action a réussi, avec une option pour l'annuler.
Le designer de l'équipe crée chaque écran dans Figma Design, et le développeur du projet intègre ces designs dans son agent de codage. Il obtient rapidement le code, mais l'interface utilisateur n’est pas conforme. Les icônes ne correspondent pas, l'espacement de la fenêtre modale est irrégulier et le toast ne dispose pas de son état d'échec. Le développeur pourrait passer l'après-midi à retravailler l'interface. Au lieu de cela, il prend du recul et repart de zéro avec les outils de développement de Figma.

Planifier avant de rédiger des prompts
Avant de rédiger du code, le développeur définit le comportement souhaité des écrans, des états et des transitions qui définissent le nouveau flux de mise à jour en masse. Il transmet le plan à son agent, ainsi que la fiche technique et le code des composants qui constituent la boîte de réception actuelle. En utilisant l'outil generate_diagramavec le serveur MCP de Figma, le développeur crée ensuite dans FigJam un diagramme modifiable qui illustre le flux sur trois surfaces :
- L'option « tout sélectionner » de la barre d'outils coche tous les messages.
- L'option « supprimer » ouvre la fenêtre modale de confirmation.
- Le bouton « annuler » du toast rétablit le tableau de bord dans son état précédent.
Le schéma fournit un contexte supplémentaire sur lequel l'agent peut s'appuyer, tout en offrant à l'équipe des éléments auxquels réagir avant le début du développement. Le développeur partage le fichier FigJam avec son homologue designer et le responsable des design systems, qui laissent tous deux leur feedback directement sur le diagramme plutôt que dans un fil de discussion Slack.
Fournir à l'agent un système à partir duquel construire
Une fois que tout le monde a donné son accord, le développeur transmet le diagramme FigJam à son agent de codage via le serveur MCP de Figma, ce qui donne à l'agent accès aux composants, aux tokens et aux mises en page du design system de Radicle.
Si le développeur ne disposait que d'une capture d'écran pour travailler, il devrait fouiller dans la base de code à la recherche du bon composant ou solliciter le designer pour clarifier certains détails : savoir si cet espacement de 12 px correspond au bon token d'espacement, si le bouton est celui de type secondaire déjà présent dans le référentiel ou encore si la fenêtre modale constitue un nouveau modèle ou un élément déjà déployé par l'équipe. Au lieu de cela, ces réponses figurent toutes dans le fichier via le serveur MCP de Figma, donnant à l'agent tout le contexte de design dont il a besoin.


Connecter le design system au code
Savoir quel composant utiliser n'est pas la même chose que savoir comment il est construit. Cette partie provient de Code Connect, que le responsable des design systems de Radicle configure. En commençant dans Figma, il connecte la bibliothèque au référentiel GitHub de l'équipe pour que chaque composant pointe vers le fichier qui le met en œuvre. Il rédige ensuite des fichiers de modèles pour des composants tels que les boutons, les icônes et les fenêtres modales au sein de la base de code, en associant les propriétés Figma aux propriétés du code.
À présent, le développeur invite l'agent à concevoir à partir de sa sélection Figma, et Code Connect identifie le composant à importer. Au lieu de gaspiller du temps et des crédits à écrire du nouveau code, l'agent s'appuie sur le plan de mise en œuvre déjà existant.

Cependant, l'état de sélection pour la mise à jour en masse est nouveau, et c'est donc le seul élément que Code Connect ne peut pas mapper. Avant de le concevoir de toutes pièces, le développeur utilise la commande search_design_system, qui parcourt les bibliothèques Figma de l'équipe à la recherche d'un composant de sélection existant. L'agent en identifie un similaire issu d'une fonctionnalité que l'équipe a lancée il y a quelques mois. De là, l'agent trouve ce composant dans le code source et l'adapte au flux de mise à jour en masse. Le résultat est conforme à la marque et cohérent avec le reste de l'application Radicle, et l'agent n'a pas besoin d'inventer un modèle que l'équipe a déjà construit.
Éviter la dérive avant qu'elle ne se produise
Le développeur passe au codage de la fenêtre modale de confirmation. Mais pendant qu'elle y travaille, l'équipe de conception apporte deux modifications : la fenêtre modale doit adopter une nuance plus sombre de la couleur de la marque, et son bouton doit avoir un nouveau rayon d'angle. Le designer publie la mise à jour dans la bibliothèque de Radicle et signale les changements dans un ticket. Au lieu d'effectuer les modifications manuellement, le développeur demande à l'agent de vérifier les écarts.
Il exécute la commande get_variable_defs dans l'agent de codage, ce qui renvoie les variables utilisées dans la fenêtre modale, reflétant désormais les modifications apportées par le designer. L'agent compare celles-ci aux tokens du code, détecte immédiatement les deux discordances, et met à jour la fenêtre modale.


Le chemin vers la production
Le développeur a terminé la barre d'outils, les états de sélection des messages et la fenêtre modale de confirmation – trois éléments issus de composants maintenus par l'équipe. Il reste le toast, qui a été créé lors de la phase de construction et qui, pour l'instant, n'existe que sous forme de code. Il lui faut encore un état d'échec. Le développeur exécute la commande use_figma pour placer le toast sur le canvas sous forme de calques modifiables, et le designer ajoute l'état manquant incluant une action « réessayer ». Le responsable des design systems publie ensuite le nouveau composant et l'associe au code grâce à Code Connect. Le toast fonctionne désormais comme tout le reste dans la bibliothèque de Radicle.
À partir de là, cela ressemble à n'importe quelle autre version. Le développeur ouvre une demande d'extraction, et le diff concerne principalement la logique de la fonctionnalité. Les ingénieurs examinent le code, et le designer vérifie une version de prévisualisation.
Le serveur MCP et Code Connect de Figma donnent à l'agent accès au système utilisé par tous, permettant à l'équipe de se concentrer sur les détails qui façonnent l'expérience utilisateur plutôt que de retravailler le code généré par l'IA. Consacrer plus de temps à la conception permet de réaliser un meilleur travail, et pas seulement de travailler plus vite.
Commencez à donner un meilleur contexte à votre agent en installant le serveur MCP de Figma et en le connectant à l'agent de codage de votre choix. Configurez Code Connect pour les composants que votre équipe réutilise le plus.
Lisez tous nos articles de blog de la série Workflow Lab pour découvrir d'autres manières de travailler dans Figma.
