Figma
NotionFIGMA NOTION SYNCHRONISER
Prérequis
- Composants Figma nommés et publiés (masters stables)
- Base Notion « Design system » avec propriétés définies
- Convention de statut design / dev / done partagée avec l'équipe
- Accès Notion pour designers et développeurs front
Quand les specs vivent entre commentaires Figma, messages Slack et tickets éparpillés, le développeur reconstruit le contexte à chaque sprint. Notion devient l'index unique : une fiche par composant avec lien frame, props, critères accessibilité et statut d'implémentation. Figma reste la source des pixels.
Structurer la base Notion composants
Créez une database « Composants » avec vues par statut (À intégrer, En cours, Done) et par domaine (Formulaires, Navigation, Cartes). Chaque entrée correspond à un master Figma unique.
Champs obligatoires : lien Figma profond vers le master, props Figma ↔ props React, critères accessibilité (contraste, focus, aria), lien issue ou PR GitHub.
Ajoutez une relation vers les pages « Patterns » ou écrans qui consomment le composant — utile pour évaluer l'impact d'un breaking change.
Alimenter et maintenir les fiches
À chaque nouveau composant ou variante majeure, la fiche Notion est créée avant le statut « Ready for dev ». Le designer remplit props et a11y ; le dev complète le chemin code et l'issue.
Lors d'une release design system, passez en revue les fiches « Done » dont le master Figma a changé : mettez à jour le statut et listez les migrations attendues.
Documentez les anti-patterns dans le corps de la page Notion — le dev les consulte avant d'ouvrir Figma.
Automatiser les rappels avec Make (optionnel)
Make n'a pas besoin de synchroniser chaque pixel : utilisez-le pour les rappels — comment Figma « spec changed » → mise à jour champ « Dernière revue » Notion, ou notification Slack au owner dev.
Un scénario léger : webhook Notion (nouvelle fiche statut « À intégrer ») → message Slack #front avec lien Figma et checklist a11y.
Pour un flux plus riche (statut projet), voir make-sync-airtable-notion — Airtable pilote les KPI, Notion porte la spec narrative.
Erreurs fréquentes
Fiches Notion créées après l'intégration : le dev a déjà improvisé une API.
Liens Figma vers une instance détachée au lieu du master.
Statut « Done » non rétrogradé après refonte visuelle majeure.
Dupliquer Storybook et Notion avec le même contenu sans rôle distinct.
Ce qu'il faut retenir
Notion indexe ; Figma et le repo exécutent.
Une fiche par master ; statut synchronisé avec le code.
Props, a11y et tickets accessibles sans Slack.
Make pour les rappels, pas pour remplacer Dev Mode.
FAQ
Non. Storybook montre le rendu code interactif. Notion porte le process, les décisions, les owners et le lien vers Figma.
À chaque merge design system et avant chaque sprint d'intégration. Une revue mensuelle suffit si le catalogue est stable.
Recommandé : champ URL vers la tâche d'intégration. Le PM suit l'avancement sans quitter son outil de pilotage.