Passer au contenu principal
Repérez les écarts de design avant la mise en production. Cette automatisation s’exécute sur chaque pull request (PR) comportant des modifications de l’interface utilisateur : elle capture des captures d’écran des composants mis à jour, récupère les frames Figma correspondantes via le MCP Figma, puis publie une revue inline sur la PR avec des annotations précises sur les écarts d’espacement, de couleur, de typographie et de mise en page.

Utiliser ce modèle

Ouvrez Figma Design Review on PR dans Devin et créez l’automatisation avec la configuration par défaut. Vous pouvez la personnaliser avant de l’enregistrer.
Vous cherchez un guide pratique ? Consultez le tutoriel pas à pas pour Figma Design Review on PR.

​
Ce que fait cette automatisation

La revue de design est l’un des aspects les plus difficiles à automatiser en ingénierie frontend. Le MCP Figma donne à Devin un accès programmatique aux designs de référence — tokens, spécifications des composants, dimensions des frames — afin qu’il puisse comparer un composant rendu à ce que le designer a réellement spécifié et fournir un retour précis sur les écarts.

​
Fonctionnement

Déclencheur : événement GitHub — pull.request
  • Événement : github:pull_request
    • Conditions :
      • action eq opened
      • repository.full_name eq your-org/your-repo
Ce que fait Devin : démarre une session avec tout le contexte de l’événement, exécute le prompt ci-dessous et, si vous le souhaitez, vous avertit en cas d’échec.

​
Prérequis

  • Intégrations:
  • Serveurs MCP:
    • Figma MCP — permet de connecter Devin à Figma

​
Exemple de prompt

Ce modèle inclut ce prompt. Vous pouvez le modifier après avoir cliqué sur Utiliser le modèle, ou le laisser tel quel.

​
Mise en place

  1. Ouvrez Automations → Templates dans Devin.
  2. Cliquez sur Figma Design Review on PR. La page de création s’ouvre avec ce modèle déjà prérempli.
  3. Connectez toutes les intégrations requises et installez les serveurs MCP si ce n’est pas déjà fait.
  4. Remplacez les valeurs fictives dans les conditions de déclenchement (par exemple, remplacez your-org/your-repo par votre repo réel).
  5. Passez le prompt en revue et adaptez-le à la langue, aux conventions et aux garde-fous de votre équipe.
  6. Cliquez sur Create automation.
La plupart des modèles d’automatisation incluent des limites d’ACU et d’invocation suggérées afin de maîtriser les coûts pendant les premières étapes du déploiement progressif. Conservez-les telles quelles jusqu’à ce que vous soyez sûr du comportement de l’automatisation, puis augmentez-les en fonction de votre charge de travail.

​
Quand utiliser ce modèle

  • Équipes très axées sur le design system, pour lesquelles la fidélité visuelle est essentielle
  • Grandes codebases frontend avec de nombreux contributeurs aux sensibilités design variées
  • Réduction des goulots d’étranglement dans la revue de design (au lieu d’attendre qu’un designer examine chaque PR)
  • Garantir une cohérence visuelle à l’échelle du produit

​
Idées de personnalisation

  • Restreindre à des repos, répertoires ou patterns de fichiers spécifiques
  • Configurer les tolérances des design tokens (pixel-perfect vs. « suffisamment proche »)
  • Ajouter un ID de fichier Figma obligatoire à chaque modèle de PR
  • Associer cela à une règle de lint du design system pour bloquer les fusions en cas d’écart important

​
Voir aussi