Figma et Linear : connecter design et développement
Intégrer Figma avec Linear : embed natifs, plugin Figma et flux de travail qui maintiennent design et ingénierie synchronisés.
By Ellis Keane · 2026-03-15
Il y a un peu plus d'un an, le passage du design à l'ingénierie est devenu un genre de théâtre de bureau. Un designer termine un composant dans Figma, laisse trois commentaires soigneusement formulés, colle un lien dans Slack et mentionne l'ingénieur qui va le construire. L'ingénieur ouvre le lien deux jours plus tard, lit deux des trois commentaires, rate une variante et livre quelque chose d'assez proche pour que personne ne le remarque avant le QA.
Si vous avez vécu cette forme particulière de malentendu (et je l'ai vécue à plusieurs reprises), vous savez déjà que la solution n'est pas "mieux communiquer". Il s'agit de connecter les outils pour que le contexte voyage avec le travail. Voici comment intégrer Figma avec Linear – les intégrations natives, le plugin et les trois flux de travail qui rendent la connexion véritablement utile.
Ce que fait réellement l'intégration Figma de Linear
Linear prend en charge les intégrations Figma depuis un certain temps, et les bases sont solides. Collez une URL Figma dans n'importe quelle description d'issue ou commentaire, et Linear génère un aperçu intégré du design. Ces aperçus sont statiques par défaut – Linear les fige au moment de l'intégration pour préserver le contexte, ce qui est un choix délibéré. Vous pouvez actualiser manuellement en mode édition, mais le design ne se mettra pas à jour silencieusement sous vos yeux.
Vous pouvez aussi ajouter des liens Figma en tant que pièces jointes à une issue, ce qui les garde organisés dans la barre latérale plutôt qu'enterrés dans un fil de commentaires qui atteint inévitablement quarante messages d'ici jeudi.
Ce que l'intégration figma linear ne fait pas, c'est être bidirectionnelle. Linear voit Figma, mais Figma ne voit pas Linear. Les commentaires restent là où ils ont été écrits. Les changements de statut ne se propagent pas. Si un ingénieur marque une issue comme "Terminé" dans Linear, personne dans Figma n'en sait rien à moins que quelqu'un ne le dise – ce qui en pratique signifie que personne dans Figma n'en sait rien.
Comment intégrer Figma avec Linear : étape par étape
La configuration est simple (heureusement – tout n'a pas besoin d'une danse OAuth en douze étapes !).
Étape 1 : Activer l'intégration
Rendez-vous dans les paramètres de votre espace de travail Linear, puis dans Intégrations. Trouvez Figma dans la liste et cliquez sur Activer. Vous serez redirigé vers Figma pour autoriser la connexion. Accordez l'accès, et la partie administrative est terminée.
Étape 2 : Lier des frames à des issues
Une fois activée, coller n'importe quelle URL Figma dans une issue Linear génère un aperçu intégré. Pour de meilleurs résultats :
- Liez des frames spécifiques, pas des fichiers entiers. Un lien vers
figma.com/file/abc123?node-id=42:1337 montre le composant pertinent. Un lien vers figma.com/file/abc123 montre ce que Figma décide être la vue par défaut, ce qui n'est généralement pas ce que vous voulez.
- Utilisez la description de l'issue pour la référence de design principale. Les commentaires fonctionnent pour l'itération, mais la description est ce que les ingénieurs lisent en premier quand ils prennent une issue.
- Ajoutez le lien Figma avant que l'issue entre dans le sprint. Cela semble évident, mais je suis sincèrement stupéfait de la fréquence à laquelle le contexte de design est ajouté après qu'un ingénieur a déjà passé vingt minutes à le chercher.
Étape 3 : Installer le plugin Figma
Figma dispose d'un plugin Linear qui permet aux designers de créer et mettre à jour des issues Linear directement depuis le canevas. Sélectionnez un frame, ouvrez le plugin, renseignez le titre de l'issue et l'équipe, et il crée l'issue avec le lien Figma déjà attaché. Le plugin prend aussi en charge la mise à jour du statut de l'issue et du responsable sans quitter Figma.
Cela inverse le passage du design au développement : de "l'ingénieur cherche le design" à "le designer envoie le design à l'ingénierie". Dans l'expérience de notre équipe, ce seul changement a réduit d'environ de moitié les messages Slack du type "où est le design pour ça ?". Croyez-moi, ça vaut à lui seul les cinq minutes que ça prend à configurer !
Là où l'intégration native montre ses limites
Je ne veux pas minimiser ce que Linear et Figma ont construit – pour une connexion légère, ça fonctionne. Mais il y a des lacunes qui méritent d'être nommées, car prétendre qu'elles n'existent pas mène, trois mois plus tard, à la conversation "on a une intégration, pourquoi rien ne se synchronise ?".
Les commentaires ne se croisent pas. Si un designer laisse des retours dans Figma et qu'un ingénieur répond dans Linear, aucun ne voit la réponse de l'autre sans vérifier manuellement les deux outils. D'après notre expérience, la plupart des malentendus entre design et développement viennent de ce silo de commentaires – pas de mauvaises spécifications, mais de conversations qui se déroulent simultanément dans deux endroits.
Le statut est unidirectionnel. Un issue qui passe à "En cours" dans Linear ne met rien à jour dans Figma. Le designer doit vérifier Linear (ou, plus réalistement, demander dans Slack) pour savoir si ses designs sont en cours de développement.
Aucune notification de changement. Quand un designer met à jour un frame lié à une issue Linear, l'ingénieur assigné à cette issue ne reçoit aucune alerte dans Linear. Comme les aperçus sont statiques par défaut, l'ingénieur pourrait construire contre une version du design qui a déjà été révisée. À moins que quelqu'un n'actualise manuellement l'intégration ou ne dise quelque chose dans Slack, la mise à jour est invisible.
Flux de travail pour combler les lacunes
Les intégrations résolvent le problème de référence. Ces trois flux de travail résolvent le problème de coordination – et ce sont eux qui déterminent si votre intégration figma linear améliore réellement le passage ou ajoute simplement une autre connexion d'outils que personne ne maintient.
Modèle 1 : Issues prêtes pour le design
Avant qu'une issue de design entre dans le backlog du sprint, trois choses doivent être attachées dans Linear :
- Lien vers le frame Figma (frame spécifique, pas le fichier)
- Notes de design résumant ce qui a changé depuis la dernière itération (car l'aperçu intégré montre l'état actuel, pas ce qui est nouveau)
- Critères d'acceptation qui font référence spécifiquement au design – "correspond au frame Figma" n'est pas un critère d'acceptation. "Utilise le token d'espacement de 8px entre le titre et le sous-titre de la carte" en est un.
Quelques minutes supplémentaires de préparation par le designer par issue. Le bénéfice : des ingénieurs qui peuvent commencer à construire sans mener d'abord une expédition archéologique dans Slack.
Modèle 2 : Labels de revue de design
Créez un label Linear personnalisé – quelque chose comme "Nécessite une revue de design" – et appliquez-le aux issues une fois construites mais nécessitant que le designer vérifie l'implémentation. L'astuce (et je réalise que ça semble douloureusement évident) est d'en faire une partie du modèle du cycle de vie de l'issue pour qu'il se déclenche automatiquement quand une issue passe à "En revue". Je le dis par expérience – nous avons créé exactement ce label, l'avons utilisé religieusement pendant deux sprints, puis avons discrètement arrêté parce que personne ne l'avait intégré à un modèle. Vous vous souvenez de l'ingénieur du début qui a raté une variante et livré "assez proche" ? C'était un label de revue de design manquant.
Modèle 3 : Sections Figma comme cartes de sprint
Pour les projets plus importants, dédiez une section ou page Figma aux designs du sprint en cours. Chaque frame correspond exactement à une issue Linear. Nommez les frames pour qu'ils correspondent à l'identifiant de l'issue – ENG-142 – Refonte du composant carte – pour que les ingénieurs puissent trouver le bon frame sans faire défiler quarante artboards nommés "Frame 247".
Ancrer ces habitudes
Les équipes que j'ai vues réussir à faire fonctionner cela partagent quelques traits : les designers lient les frames avant que les issues entrent dans le sprint (pas après que les ingénieurs se plaignent), les ingénieurs appliquent le label de revue avant de marquer les issues comme terminées (pas comme une réflexion après coup), et personne ne traite Slack comme le système de référence pour les décisions de design.
Ce dernier point importe plus que n'importe quelle intégration – et si vous avez déjà passé quinze minutes à chercher "ce fil où on a décidé de changer le rayon de bordure", vous savez exactement ce que je veux dire. Slack est l'endroit où les conversations de design ont lieu, et aussi l'endroit où elles disparaissent. Si une décision de design a été prise dans un fil, quelqu'un doit mettre à jour le fichier Figma ou l'issue Linear – sinon, elle aura disparu dans trois semaines, enterrée sous des alertes de déploiement et des plans de déjeuner.
"Si une décision de design a été prise dans un fil, quelqu'un doit mettre à jour le fichier Figma ou l'issue Linear – sinon, elle aura disparu dans trois semaines, enterrée sous des alertes de déploiement et des plans de déjeuner." – Chris Calo
L'intégration native Figma-Linear gère bien l'intégration et la référence. Pour une prise de conscience bidirectionnelle – commentaires, statut, notifications de changement – vous avez besoin soit d'une discipline manuelle, soit d'une couche qui connecte le contexte entre les deux outils automatiquement.
Et si vous connectez plus que Figma et Linear – en ajoutant Slack, GitHub et Notion – la charge manuelle de tout garder synchronisé s'accumule rapidement. C'est une conversation différente, mais elle vaut la peine d'être tenue avant la prochaine rétrospective "qui a changé ce design et pourquoi personne ne l'a dit ?".
Connectez Figma, Linear, Slack et GitHub dans un graphe de connaissances – pour que le contexte de design voyage avec le travail.
Q: Sugarbug connecte-t-il Figma et Linear automatiquement ? A: Oui. Sugarbug ingère des signaux depuis Figma et Linear, en corrélant les commentaires de design et les mises à jour de fichiers avec les changements de statut des issues dans son graphe de connaissances. Quand un designer laisse un commentaire sur un frame, Sugarbug peut le faire apparaître à côté de l'issue Linear concernée sans que personne n'ait besoin de copier des URLs.
Q: Sugarbug peut-il suivre le passage de design à travers Figma, Linear et Slack ? A: Sugarbug connecte Figma, Linear, Slack, GitHub et Notion dans un graphe de connaissances unique. Les retours de design, les discussions d'ingénierie et les statuts des tâches restent corrélés, afin que le contexte ne soit pas perdu lors du passage.
Q: Linear dispose-t-il d'une intégration Figma native ? A: Oui. L'intégration Figma native de Linear permet de coller des URLs Figma dans des issues pour créer des aperçus intégrés, et d'utiliser le plugin Figma pour créer ou mettre à jour des issues depuis le canevas. Cependant, elle est unidirectionnelle – les commentaires et les changements de statut ne se synchronisent pas entre les outils.
Q: Comment lier un frame Figma à une issue Linear ? A: Collez l'URL du frame Figma dans la description ou dans un commentaire de l'issue Linear. Linear génère un aperçu intégré. Vous pouvez aussi utiliser le plugin Figma de Linear pour créer des issues directement depuis le canevas avec le lien déjà attaché.
Q: Pourquoi les commentaires Figma n'apparaissent-ils pas dans Linear ? A: L'intégration Figma native de Linear intègre des aperçus de design mais ne synchronise pas les commentaires entre outils. Le commentaire Figma d'un designer et le commentaire Linear d'un ingénieur existent dans des silos séparés. Des outils comme Sugarbug comblent cet écart en ingérant des signaux des deux et en les reliant dans un graphe de connaissances partagé.