Comment créer une PR avec le code local de Figma Make ? Processus designer 2026

La bêta ne constitue pas une fonction garantie à tous les comptes. Figma indique qu’elle est ouverte progressivement et que l’utilisation du code local passe par son application de bureau bêta sur Mac. Être designer dans une équipe ou avoir accès à un fichier Figma ne suffit donc pas à conclure que la fonctionnalité est disponible.

De quel compte et de quel environnement avez-vous besoin ? Un compte autorisé à utiliser la fonctionnalité, l’application de bureau bêta pour Mac et un accès valide au dépôt du projet. Confirmez ces trois prérequis séparément : une invitation à la bêta ne donne pas automatiquement accès au dépôt, et les droits Git ne donnent pas accès à la bêta.

Le périmètre traité ici est volontairement limité : prendre un projet web déjà existant, réaliser une modification d’interface circonscrite, puis transmettre les changements à l’équipe. Ce n’est pas un parcours pour créer une application entièrement nouvelle, développer un service côté serveur ou modifier l’infrastructure. Ces travaux relèvent de décisions techniques que l’équipe d’ingénierie doit prendre.

Avant de réserver du temps pour la tâche, cochez les conditions suivantes :

• [ ] Le compte utilisé a bien accès à la fonctionnalité bêta.
• [ ] L’application bêta pour Mac est disponible et peut être lancée.
• [ ] L’équipe a confirmé le dépôt, la branche de départ et le niveau d’accès nécessaire.
• [ ] Un ingénieur peut répondre aux questions sur la configuration du projet et ses vérifications.
• [ ] La demande porte sur un changement d’interface que l’équipe pourra relire et tester.

En cas d’échec sur les deux premières cases, arrêtez-vous : une autre machine ou un Mac distant ne remplace pas l’autorisation. Si le problème concerne les accès Git, demandez à l’équipe propriétaire du dépôt de les corriger avant d’essayer de modifier le projet.

Un dépôt est le dossier partagé où l’équipe conserve les fichiers du projet et l’historique des changements. Pour travailler sur le code existant, il faut que la personne qui modifie l’interface puisse accéder au bon dépôt, et que le projet ait été préparé pour être ouvert et lancé dans l’environnement concerné.

Figma recommande de préparer le dépôt et de vérifier la configuration avant la première utilisation du code local. L’ingénieur du projet doit notamment confirmer comment installer les dépendances, démarrer l’aperçu et effectuer les contrôles attendus. Ces réglages peuvent différer selon le site : ne recopiez pas une commande trouvée pour un autre projet sans validation.

Le tableau ci-dessous résume les distinctions importantes entre hébergement Git et remise d’une modification. Les chemins propres à Figma Make sont décrits dans ses instructions de configuration du code local.

Cette différence est opérationnelle. Une branche préparée dans l’application n’est pas forcément une PR prête à examiner dans tous les services Git. D’après la documentation Figma sur la configuration et le dépannage, GitHub permet la création de PR dans l’application, tandis que les PR GitLab et Bitbucket se traitent sur leurs plateformes respectives. Ne présentez donc pas « le code est modifié » comme équivalent à « la PR est créée ».

Définissez aussi le rôle de chacun. Le designer peut cadrer le changement, examiner l’aperçu et préparer une description claire. L’ingénieur confirme les règles du projet, les vérifications et l’intégration dans la branche de l’équipe. La personne qui révise garde la responsabilité d’accepter, de demander des corrections ou de refuser la proposition.

La documentation Figma prévoit deux situations de départ : ouvrir un dépôt local déjà disponible ou cloner un dépôt distant. Dans le premier cas, il faut choisir le dossier réellement associé au projet. Dans le second, il faut utiliser le dépôt auquel le compte a accès et respecter la méthode de connexion adoptée par l’équipe. Dans les deux cas, une sélection du mauvais dossier peut donner un aperçu sans rapport avec le code que vous pensez modifier.

Comment connecter un dépôt GitHub existant ? Confirmez d’abord que le compte autorisé par l’équipe peut accéder au dépôt, puis suivez le parcours de connexion décrit dans les instructions de Figma Make pour le code local. Sélectionnez le bon projet et vérifiez son contenu avant de lancer l’aperçu. Si le projet est inaccessible ou si la connexion échoue, demandez à l’équipe de contrôler les droits et la configuration au lieu de multiplier les tentatives.

Une fois le projet ouvert, démarrez l’aperçu à partir de la procédure fournie par l’équipe. Vérifiez que la page affichée correspond bien à la zone concernée : par exemple, la bonne page, le bon composant et les bonnes données d’exemple. Un aperçu qui ne démarre pas ne prouve pas que la demande de design est incorrecte.

Pour diagnostiquer un blocage, vérifiez les éléments dans cet ordre :

• le compte utilisé possède-t-il les droits attendus sur le dépôt ?
• le dossier ouvert correspond-il au projet visé ?
• les consignes de l’équipe précisent-elles l’installation des dépendances et le démarrage du serveur ?
• le projet nécessite-t-il une configuration locale ou un accès supplémentaire ?
• le message d’erreur correspond-il à un problème d’environnement plutôt qu’à une modification de l’interface ?

Les conseils de dépannage publiés par Figma aident à distinguer les difficultés de configuration des autres problèmes. Transmettez à un ingénieur l’erreur exacte et l’étape à laquelle elle apparaît. N’affirmez pas que l’outil a produit un mauvais changement avant d’avoir établi que le projet se lançait correctement.

La méthode la plus sûre consiste à choisir un changement facile à décrire et à contrôler. Cela peut être un ajustement de présentation, une correction de libellé ou une retouche limitée d’un composant existant. Une refonte simultanée de plusieurs pages rend plus difficile l’identification des changements utiles et des régressions éventuelles.

Dans Figma Make, vous pouvez formuler l’ajustement à partir de l’interface, d’annotations sur la zone concernée ou d’une consigne en langage naturel. Décrivez le résultat recherché en termes observables : l’élément concerné, son état visuel attendu et, si nécessaire, les tailles d’écran à vérifier. Évitez les instructions vagues comme « rendre la page plus moderne », qui ne disent pas à l’équipe quel résultat valider.

Procédez par petites passes :

• Commencez par une zone isolée et vérifiez le résultat dans l’aperçu.
• Comparez la page avant et après sur les états pertinents pour le projet.
• Relisez le code modifié et repérez les fichiers touchés.
• Vérifiez les éléments partagés, comme les styles ou composants utilisés ailleurs.
• Si la modification dépasse la demande initiale, arrêtez-vous et demandez une validation avant d’élargir le périmètre.

L’aperçu ne remplace pas l’inspection du code. Il montre un rendu dans un contexte précis, mais ne suffit pas à établir que les changements respectent le système de design, les conventions du dépôt ou les comportements attendus sur les autres pages. Figma présente le travail sur le code local comme un moyen d’intervenir dans un projet existant ; cela ne signifie pas que chaque résultat généré est prêt à intégrer sans examen.

Avant de poursuivre, comparez le rendu visible et les fichiers modifiés. Si le résultat semble correct mais que des fichiers inattendus ont changé, demandez une vérification technique avant de préparer la PR.

Une branche est un espace de travail séparé de la version de référence. Elle permet à l’équipe d’examiner une proposition sans intégrer immédiatement ses changements au projet principal. Un commit, ou enregistrement de changements, garde une trace des modifications apportées. Ces notions ne sont pas réservées aux ingénieurs : elles permettent au designer et aux réviseurs de savoir ce qui a changé, et de le comparer au code de départ.

Avant la création de la demande de fusion, relisez le diff, c’est-à-dire la comparaison entre les fichiers modifiés et leur version de départ. Confirmez que les changements répondent à la demande et que les fichiers sans rapport n’ont pas été inclus. Ensuite, exécutez les contrôles indiqués par l’équipe : leur nature dépend du projet, il n’existe pas de liste universelle adaptée à tous les dépôts.

Comment préparer une branche et une PR après la modification ? Enregistrez le travail sur une branche dédiée, contrôlez les changements enregistrés, puis créez la PR dans l’application si le projet utilise GitHub. Pour GitLab et Bitbucket, poussez la branche selon la procédure de l’équipe et ouvrez la demande sur la plateforme correspondante. Les ingénieurs doivent ensuite examiner le code et les contrôles avant toute intégration.

Une PR — pull request, ou demande de fusion selon la plateforme — est une proposition de changement soumise à l’équipe. Elle n’est ni une publication en production ni une preuve que le code est correct. La documentation GitHub sur la revue d’une PR décrit le rôle des personnes chargées d’examiner les changements. La revue reste un point de contrôle humain, même lorsque l’édition initiale a été assistée par un outil.

Accompagnez la remise d’un message qui permet à l’équipe de reprendre le travail sans deviner :

• le nom de la branche ;
• un résumé du changement, limité à ce qui a effectivement été modifié ;
• les pages ou composants concernés ;
• les vérifications effectuées et celles qui restent à faire ;
• les décisions de design encore ouvertes ;
• les captures ou références utiles, si l’équipe en a besoin pour comparer le résultat.

La description ne doit pas annoncer que la PR est « prête à fusionner » si les tests ou la revue technique n’ont pas été réalisés. Signalez clairement toute limite connue, par exemple une page qui n’a pas pu être vérifiée ou une dépendance qui demande l’intervention d’un ingénieur.

Un utilisateur Windows peut-il utiliser le code local avec un Mac distant ? Oui, si son compte est autorisé, si l’application bêta pour Mac est accessible dans l’environnement choisi, et si le dépôt ainsi que les outils du projet peuvent y être utilisés. Le Mac distant fournit un environnement Mac ; il ne confère pas de droits supplémentaires sur Figma ou sur Git. Il ne remplace pas non plus la validation de l’équipe.

Pour choisir la suite, utilisez cette liste de conditions :

• Si le compte n’a pas encore accès à la bêta, alors demandez confirmation à Figma ou à l’administrateur concerné ; ne louez pas un Mac dans l’espoir de contourner cette restriction.
• Si le compte est autorisé et qu’un Mac local est déjà disponible, alors utilisez-le si le projet et les règles de l’équipe le permettent.
• Si le compte est autorisé, que vous travaillez sous Windows et que la tâche exige réellement l’application Mac, alors évaluez un Mac distant après vérification de l’accès au dépôt et du processus de transfert des fichiers.
• Si le dépôt, les dépendances ou les contrôles ne sont pas configurés, alors demandez à l’ingénieur du projet de préparer ces éléments avant la séance de modification.
• Si l’équipe n’a pas de procédure de revue, alors convenez-en une avant de créer la PR : changer de machine ne remplace pas cette décision collective.

Le tableau compare les options en fonction de la tâche, plutôt que de présumer qu’une solution convient à tous les projets.

Un Mac distant devient donc pertinent pour une tâche bornée, lorsque le besoin est bien l’application Mac et que l’équipe a déjà cadré l’accès au code. Avant d’adopter ce parcours, vérifiez comment vous vous connecterez et comment vous remettrez les changements à l’équipe. Les pages de MESHLAUNCH présentent les informations disponibles sur l’accès à un Mac distant ; elles ne peuvent pas confirmer votre autorisation à la bêta ni remplacer les droits attribués par le propriétaire du dépôt.

Pour un besoin régulier et durable, un Mac local peut être plus adapté, notamment si votre flux créatif nécessite aussi une utilisation continue d’outils audio ou vidéo. À l’inverse, acheter et entretenir une machine pour une tâche ponctuelle peut ajouter des coûts et de la gestion qui ne sont pas nécessaires à votre projet immédiat. Le Mac distant implique, lui, une dépendance au réseau et aux modalités de transfert : vérifiez ces points avant de retenir cette option. Vous pouvez consulter les informations sur les Mac disponibles chez MESHLAUNCH, puis confronter les conditions proposées à votre propre projet, sans en déduire que la bêta ou les accès Git seront fournis automatiquement.

En pratique, Windows seul ne suffit pas pour lancer cette fonctionnalité Mac ; un Mac local exige de disposer et de maintenir l’équipement ; un Mac distant peut éviter cet achat pour un besoin circonscrit, mais ne résout ni les droits manquants ni la revue de code. Si vous avez vérifié la bêta, les permissions et le périmètre de la modification, évaluez le Mac distant de MESHLAUNCH comme un environnement de travail temporaire, puis faites valider la branche par l’équipe selon son processus habituel.