Figma Make rapproche l'édition visuelle du code réel

La distance entre conception Et le développement a toujours été l'une des étapes les plus coûteuses dans le processus de création d'un logiciel. Un concepteur crée une interface. Un développeur la transpose en code. La mise en œuvre s'avère légèrement différente. Le concepteur fait part de ses remarques. Le développeur apporte des modifications. Un autre cas particulier apparaît. Et le cycle se poursuit.

La dernière mise à jour de Make par Figma vise à raccourcir ce cycle. L’entreprise indique que les utilisateurs peuvent désormais connecter Make à une base de code locale, sélectionner des éléments de manière visuelle, ajuster des propriétés telles que les mises en page, les couleurs, les polices ou les dimensions, puis laisser l’agent trouver le code correspondant et appliquer la modification. Cette fonctionnalité prend également en charge la mise en production des modifications depuis Make, ce qui la fait sortir du simple cadre de la génération de prototypes pour s'aventurer sur le terrain plus délicat de la modification de logiciels réels.

Cela ne signifie pas pour autant que les designers remplacent soudainement les ingénieurs. Cela ne signifie pas non plus que chaque modification visuelle doive être soumise à l'examen des développeurs. Il est plus pertinent d'interpréter cette mise à jour ainsi : Figma cherche à rendre le code plus accessible précisément au moment où les décisions de conception sont prises.

Pour les équipes produit, cela pourrait avoir une importance considérable.

Le « Old Handoff » est sous pression

Le passage de la conception au développement s'est amélioré au fil des ans, mais il n'a jamais complètement disparu. Les systèmes de conception, les bibliothèques de composants, les jetons, les outils d'inspection et une meilleure collaboration ont contribué à cette amélioration, mais de nombreuses équipes perdent encore du temps à transposer leurs intentions en implémentation.

Le problème ne réside que rarement dans le manque de communication entre les concepteurs et les développeurs. Il tient plutôt au fait qu’ils travaillent sur des plans différents. Les concepteurs interviennent sur l’interface d’un point de vue visuel. Les développeurs interviennent sur le code sous-jacent. Chaque partie ne perçoit qu’une partie de la réalité.

Cela engendre des frictions bien connues. Une modification d'espacement qui semble mineure dans un fichier de conception peut être liée à un composant partagé. Un ajustement de couleur peut devoir respecter des « design tokens ». L'état d'un bouton peut dépendre de règles d'accessibilité, de la réactivité, de la gestion des erreurs ou de la logique du produit. Une page qui s'affiche correctement dans une fenêtre d'affichage peut présenter des dysfonctionnements dans une autre.

L'intégration du code local dans Figma Make est intéressante, car elle vise à rapprocher ces deux univers. Au lieu de demander au concepteur de décrire une modification et d'attendre que quelqu'un d'autre trouve le bon fichier, l'outil permet à l'utilisateur de pointer du doigt l'interface et de demander directement la modification. L'agent analyse alors le contexte du code et applique la modification.

Il s'agit d'un processus différent de la simple création d'un prototype à partir d'une consigne.

L'édition visuelle prend une dimension plus sérieuse lorsqu'elle touche au code de production

Figma Make s'inscrit déjà dans la vague plus large de création d'applications basées sur l'IA, qui permet aux utilisateurs de générer des prototypes ou des applications fonctionnelles à partir de consignes en langage naturel et de références de conception. Cette nouvelle étape est d’autant plus importante qu’elle permet de se connecter à des bases de code existantes. Selon The Verge, cette mise à jour permet aux équipes d’utiliser Figma Make comme interface visuelle pour créer et modifier de véritables logiciels, et non plus seulement pour explorer des prototypes.

Cela modifie le profil de risque.

Un prototype généré peut présenter des imperfections tout en restant utile. Il aide une équipe à explorer un concept. Une modification apportée à une base de code réelle doit répondre à des exigences plus strictes. Elle doit respecter l'architecture, la réutilisation des composants, l'accessibilité, la gestion de l'état, la réactivité, les tests, les conventions de nommage et les règles du système de conception.

C'est là que l'édition visuelle du code peut s'avérer très efficace, mais uniquement si l'agent comprend le système dans son ensemble. Un simple changement de couleur ou d'espacement est une chose. Une modification de mise en page qui affecte des composants réutilisables sur plusieurs pages en est une autre. Une interface visuelle peut donner l'impression que la modification est locale, alors que la modification du code peut avoir des conséquences plus larges.

C'est pourquoi le workflow des développeurs reste essentiel. Les modifications visuelles doivent faire l'objet d'une révision, d'un contrôle de version et permettre de voir exactement ce qui a changé. Une implémentation efficace doit créer une pull request, afficher les différences, respecter les workflows des branches et permettre aux ingénieurs d'accepter, de rejeter ou de modifier la modification.

Si l'outil prend en charge cette discipline, cela pourrait réduire les allers-retours inutiles. Dans le cas contraire, cela pourrait engendrer de nouveaux types de tâches de mise au point.

Le rôle du designer commence à évoluer

Pour les designers, l'intérêt est évident. Bon nombre de choix de conception sont d'ordre visuel et nécessitent une grande précision. Les designers savent reconnaître quand une mise en page ne fonctionne pas, quand l'espacement n'est pas adapté, quand un élément ne correspond pas à la hiérarchie prévue ou quand l'interface mise en œuvre s'est éloignée du système de conception.

Jusqu'à présent, ils devaient souvent signaler ces problèmes de manière indirecte : une remarque, une capture d'écran, un ticket, un message sur Slack, une note d'assurance qualité. Chaque étape ajoute une source de friction. L'édition visuelle offre au concepteur un moyen plus direct d'exprimer la correction à apporter.

Cela ne signifie pas pour autant que chaque designer doive devenir ingénieur logiciel. Mais cela exige une meilleure compréhension du code. Les designers qui utilisent des outils tels que Figma Make devront comprendre qu’une interface ne se résume pas à ce qui s’affiche à l’écran. Il s’agit également d’un système composé de composants, de contraintes, de tokens et de comportements. Les meilleurs designers pourraient se sentir plus à l'aise en raisonnant en termes de mise en œuvre, sans pour autant écrire du code à la main.

Cela pourrait renforcer l'influence du concepteur, non pas parce qu'il contourne l'ingénierie, mais parce qu'il peut intervenir plus directement au niveau de la mise en œuvre.

Cela pourrait également modifier la nature du travail auquel les concepteurs consacrent leur temps. Moins d'heures pourraient être consacrées à la documentation de petites corrections visuelles. Davantage de temps pourrait être consacré à la qualité de l'interaction, à la logique du produit, à l'accessibilité, à la hiérarchie du contenu et à la réflexion systémique.

Les développeurs pourraient s'en réjouir, ou s'y opposer

La réaction des développeurs dépendra de la manière dont l'outil se comporte dans la pratique.

Si Figma Make génère des modifications claires et vérifiables qui respectent la base de code existante, les développeurs pourraient bien l'accueillir favorablement. Les petites corrections visuelles, l'harmonisation avec le système de conception et les ajustements répétitifs de l'interface utilisateur peuvent s'avérer fastidieux. Si un agent les gère efficacement, les ingénieurs peuvent se concentrer sur l'architecture, les performances, la logique, les flux de données, les tests et les tâches techniques à plus forte valeur ajoutée.

Mais si l'agent génère des diffs confus, ignore les conventions existantes ou apporte des modifications qui semblent correctes à première vue mais affaiblissent le code, les développeurs s'y opposeront. Et ils ont raison de le faire.

L'histoire des outils de conversion de design en code est marquée par de nombreuses promesses exagérées. De nombreux outils produisent des résultats qui semblent acceptables lors d'une démonstration, mais qui s'avèrent difficiles à maintenir dans un produit réel. Des recherches récentes sur les workflows automatisés de conversion de Figma en code ont montré que même les modèles les plus performants peuvent rencontrer des difficultés en matière de réactivité de la mise en page et de maintenabilité du code, malgré une fidélité visuelle améliorée.

C'est la norme à laquelle Figma Make devra se conformer. La précision visuelle ne suffit pas. Le code doit faire partie intégrante du produit.

L'opportunité réelle est moins importante que ce que laisse entendre le battage médiatique, mais elle reste néanmoins intéressante

La version la plus optimiste de cette histoire est que Figma Make va “ révolutionner ” le développement logiciel du jour au lendemain. Ce ne sera probablement pas le cas.

La version plus puissante est plus pratique. Figma Make pourrait faciliter certaines modifications du front-end : ajustement des espacements, de la typographie, des couleurs, des détails de mise en page, des variantes de composants, du comportement adaptatif ou des petites améliorations de l'interface. Ce sont précisément ces modifications qui peuvent prendre du temps, car elles se situent à mi-chemin entre les choix de conception et les détails de mise en œuvre.

Si ces modifications s'effectuent plus rapidement, les équipes pourront livrer des produits plus aboutis tout en réduisant les efforts de coordination. Les concepteurs pourront tester leurs idées dans un environnement plus réaliste. Les développeurs pourront examiner des modifications concrètes du code plutôt que d'interpréter des retours d'information vagues. Les chefs de produit pourront découvrir plus tôt des versions des fonctionnalités plus proches de la réalité.

Cet outil peut également s'avérer utile pour la maintenance d'un système de conception. Si une équipe doit appliquer un modèle visuel à de nombreux endroits, un agent IA tenant compte du contexte du code source pourrait aider à identifier les composants concernés et à les mettre à jour de manière plus cohérente qu'un travail manuel consistant à traiter chaque ticket individuellement.

Mais cela ne fonctionne que si la base de code est suffisamment structurée pour que l'agent puisse la comprendre. Un système de composants abouti, une nomenclature claire, des « design tokens » et une architecture cohérente donneront probablement de meilleurs résultats qu'une base de code fragmentée, truffée d'implémentations ponctuelles.

En d'autres termes, Figma Make pourrait avant tout profiter aux équipes qui disposent déjà d'une bonne maîtrise du front-end.

La gouvernance s'intègre au flux de travail

Dès lors que les modifications visuelles peuvent affecter le code en production, la gouvernance devient essentielle. Les équipes ont besoin de règles claires concernant les personnes autorisées à apporter des modifications, les types de modifications nécessitant l'approbation d'un développeur, la manière dont les branches sont créées, la procédure de révision des pull requests et la manière dont les règles du système de conception sont appliquées.

Ce n'est pas seulement une question technique. C'est une question de culture d'équipe.

Les concepteurs peuvent souhaiter avoir davantage de contrôle sur la fidélité. Les développeurs peuvent vouloir préserver la qualité du code. Les équipes produit peuvent souhaiter des itérations plus rapides. La direction peut vouloir des cycles de livraison plus courts. Tous ces objectifs sont légitimes, mais ils peuvent entrer en conflit si le flux de travail n'est pas clairement défini.

Figma Make sera sans doute plus utile dans le cadre d'un travail collaboratif que dans celui d'une utilisation individuelle. Les designers peuvent proposer ou apporter des modifications visuelles. L'agent peut traduire ces modifications en code. Les développeurs peuvent examiner les différences. Le système de conception peut rester le garant de la cohérence. L'équipe produit peut avancer plus vite sans pour autant renoncer à sa responsabilité technique.

Cet équilibre est important. Les outils d'IA doivent faciliter les transitions, et non supprimer la responsabilité professionnelle.

Pourquoi cela a de l'importance au-delà de Figma

L'initiative de Figma s'inscrit dans une tendance plus large de la création logicielle. La frontière entre la conception, le code et la gestion de produit s'estompe progressivement. Les agents de codage basés sur l'IA sont capables de lire des bases de code, de générer des modifications et de répondre à des instructions en langage naturel. Les outils de conception permettent de créer des prototypes fonctionnels. Les équipes produit peuvent tester leurs idées plus rapidement. Les développeurs travaillent de plus en plus avec des agents plutôt que d'écrire chaque ligne de code à partir de zéro.

Les recherches sur les agents de codage permettant de transformer des spécifications visuelles en applications web vont dans le même sens : ces agents ne sont pas seulement évalués sur leur capacité à écrire du code, mais aussi sur leur aptitude à créer des applications fonctionnelles et visuellement cohérentes à partir de spécifications de conception et de captures d'écran.

Cela ne signifie pas pour autant que tout le monde devienne développeur. Cela signifie plutôt que le travail sur les logiciels gagne en souplesse. La personne la plus proche du problème pourra peut-être exprimer la modification de manière plus directe, tandis que l'outil se chargera d'une partie de la traduction.

C'est un aspect important, car de nombreux retards dans le développement des produits ne sont pas dus à un manque d'idées. Ils sont dus aux coûts liés à la coordination entre les différentes disciplines.

Le sens de la marche

La nouvelle intégration du code source dans Figma Make s'inscrit davantage dans une évolution progressive que dans une rupture brutale. La distinction entre les fichiers de conception et la mise en œuvre s'estompe progressivement. Le code devient de plus en plus modifiable grâce à des interfaces visuelles et en langage naturel. Les agents IA s'intègrent désormais à la couche de collaboration entre les disciplines.

L'avantage réside dans des itérations plus rapides et une meilleure cohérence entre ce que les équipes conçoivent et ce que les utilisateurs vivent. Le risque est une baisse de la qualité du code si les modifications visuelles sont considérées comme inoffensives alors qu'elles ne le sont pas.

Les équipes qui en tireront le plus grand bénéfice seront celles qui sauront maintenir une organisation rigoureuse du flux de travail. Elles recourront à l'édition visuelle pour les types de modifications où cette méthode s'avère réellement efficace, associeront les développeurs au processus de révision, maintiendront des systèmes de composants solides et considéreront les modifications générées par l'IA comme des propositions nécessitant une vérification.

Figma Make ne supprimera peut-être pas le passage de relais entre la conception et le développement. Mais il peut faire en sorte que ce passage de relais ressemble moins à un exercice de traduction et davantage à un processus d'édition collaboratif.

C'est un changement significatif. L'avenir du développement de produits ne consistera probablement plus à avoir d'un côté les concepteurs et de l'autre les développeurs, qui se transmettent des fichiers. Il s'agira d'un flux de travail plus intégré, où l'intention de conception, le contexte du code et l'assistance par l'IA se rejoindront plus tôt dans le processus.

Les gagnants ne seront pas les équipes qui laissent n'importe qui modifier n'importe quoi. Ce seront celles qui utilisent ces outils pour gagner en rapidité tout en préservant la cohérence, l'accessibilité et la facilité de maintenance du produit.