Issu du passage de notre maquette Page Carrefour dans l'intégration Figma + shadcn MCP. La Partie 1 décrit ce dont nous avons besoin dans les fichiers. La Partie 2 est une structure à discuter — elle peut être écartée. La Partie 3 liste les corrections concrètes à faire sur Page Carrefour.
Gardez les composants (Button, Card, …) isolés sur une page Composants, avec leurs variantes. Gardez les maquettes sur leur propre page. Kiro lit la maquette pour comprendre l'usage, et le composant pour comprendre sa structure — mélangés, il ne peut pas les distinguer.
Ne laissez pas de composants en trop ou en double dans une frame de composition. Les restes créent du bruit et rendent flou quelle version fait foi.
Chaque élément qui correspond à un composant doit rester une instance vivante liée à celui-ci — pas détachée, pas redessinée en formes brutes. Une instance détachée est invisible pour le mapping : Kiro la reconstruit comme un one-off au lieu de reconnaître le composant.
Sur Page Carrefour, le fil d'ariane, la carte d'avis, la notation et les cartes « atouts » étaient tous des frames détachées — chacune a dû être reconstruite à la main plutôt que mappée.
Le nom d'une frame doit dire ce qu'elle est, pour qu'elle se mappe à un élément et un composant qui ont du sens.
À privilégier : Header Hero Card Testimonial Section : Pourquoi l'UCPA
À éviter : Frame 222 Group 11 Container Flex
Sur Page Carrefour, les sections arrivaient nommées Frame 222, container… — savoir laquelle était le hero, le footer, les avis a dû se déduire du contenu, pas des noms.
Toutes les couleurs, espacements, tailles et typographies viennent des variables globales — jamais d'une valeur en dur ni d'un style ponctuel. Une page Style Guide peut refléter les variables, mais elle n'est jamais un second endroit où les valeurs sont modifiées.
C'est la règle la plus impactante. Nous avons déjà rencontré de vrais bugs dus à des écarts : un token d'espacement dont les deux paliers étaient inversés ; un h1 réglé sur la valeur mobile, si bien que tous les titres desktop s'affichaient ~16 px trop petits ; et du contenu de page encore lié à des valeurs kit/wireframe résiduelles (--sds-*, une couleur wireframe #100D08) au lieu des tokens UCPA.
L'idée : l'identité de marque et le theming vivent dans une seule core library. UCPA est à la fois l'identité et son propre projet. Les projets réels, en production — speedboat, alpha, labalaguère — se placent en dessous, chacun avec ses propres composants et tokens de thème ; common regroupe ce qui est partagé. Les pages/features (Page Carrefour, Tunnel d'achat, toute nouveauté) se lient à la core plutôt que de redessiner les éléments localement.
Kiro a les composants de la core reliés via Code Connect, ce qui lui permet de mapper chaque élément de design au bon composant de code. Quand un designer modifie un composant, son lien Code Connect passe en « obsolète » ; un dev lance une commande de re-liaison ciblée sur cette page et ce composant. La configuration du projet embarque un manifeste des IDs de pages et des mappings, versionné dans le repo, pour qu'un simple checkout sache déjà où se trouve chaque élément.
Le MCP de Figma peut récupérer le contexte d'un projet Make directement dans l'agent. On partage un lien de prototype Make et l'agent récupère le comportement et les styles de ce composant — par ex. le mouvement d'une popup — et l'implémente sur notre vrai composant, portant l'animation du prototype jusqu'à la production. (Nécessite un client MCP compatible « resources ».) Doc Figma →
La page « Composants » est en grande partie le kit shadcn générique, mais elle contient déjà quelques vrais masters qui fonctionnent : la Top Navigation et le Hero Header (avec sa galerie d'images). Le nav desktop et le hero desktop les utilisent correctement. Ce qui manque, c'est le reste des composants UCPA — les cartes, le fil d'ariane et le footer : ceux-là n'ont pas de master et sont détachés sur la maquette. Il faut (1) créer ces masters manquants, puis (2) ne placer que des instances sur les maquettes.
Chacun est aujourd'hui une frame détachée sur la maquette. À créer en vrai master (avec ses variantes), puis à replacer en instances partout.
CardProduit — note + titre + lieu + badges d'activitéCardArticle — image + titre + description + badges + bouton « Lire l'article »ReviewCard / Avis — note + 5 étoiles + titre + texte + avatarMediaCard — image + légende (un seul composant pour Destinations ET Activités)Fil d'arianeFooter — composant simplement foncé (#0f1f28)
CardProduit aura probablement besoin des états Complet / Indisponible (le master Badge les a déjà). MediaCard : même structure pour « Suisse/Népal/Pérou » et « Course d'orientation/Trail/Canirando » — un seul composant.
Le master Hero Header existe déjà (variantes Image = mosaique | Seule, options logo et note). Le hero desktop en est déjà une instance correcte. Seul le hero mobile a été détaché et simplifié — il faut le re-lier au master Hero Header (en variante responsive), pour que les deux breakpoints partagent un seul composant.
Ces éléments sont déjà des instances de vrais masters, sur desktop et mobile : Top Navigation, Button, Badge, Accordion (la FAQ), le slider.
| Bloc | Desktop | Mobile | Action |
|---|---|---|---|
| Top Navigation | ✓ instance | ✓ instance | aucune |
| Button / Badge / Accordion / slider | ✓ instances | ✓ instances | aucune |
| Hero | ✓ instance (Hero Header) | ✗ détaché | re-lier le mobile au master |
| CardProduit | ✗ détaché ×6 | ✗ détaché ×6 | créer master → remplacer |
| CardArticle | ✗ détaché ×1 | ✗ détaché ×3 | créer master → remplacer |
| ReviewCard / Avis | ✗ détaché ×3 | ✗ détaché ×3 | créer master → remplacer |
| MediaCard | ✗ détaché (3 + 3) | ✗ détaché (Activités ; Explore à confirmer) | créer master → remplacer |
| Fil d'ariane | ✗ détaché ×1 | ✗ détaché ×1 | créer master → remplacer |
| Footer | ✗ détaché ×1 | ✗ détaché ×1 | créer master → remplacer |
À nettoyer : un fil d'ariane masqué traîne sur le hero mobile (nœud 29061:33507, visibilité désactivée) — à supprimer. Ouvrir dans Figma →
Note desktop/mobile : la plupart des sections existent sur les deux breakpoints (cartes produits, Activités, Articles, bloc « À propos UCPA »). « Plus de séjour » est un bouton « voir plus » en bas de la section cartes, pas une section à part. Les décomptes diffèrent (ex. cartes Article : desktop ×1 / mobile ×3).
Chaque variable doit être réellement utilisée (liée à un composant ou une frame) ; purgez les variables orphelines. Gardez les primitives que les tokens sémantiques aliasent. Exposez en variable ce qui n'en est pas encore (ex. la largeur de contenu de la page). Confirmez si les interlignes 100 (lus comme normal) sont volontaires.
D1 — le bloc note / « notation ». Il apparaît dans le hero, la carte produit et la carte avis, mais dessiné différemment à chaque fois (hero : note + « 84 avis » ; produit : note + « (8 581) » ; avis : note + 5 étoiles). À trancher : (A) le garder à l'intérieur de chaque parent, ou (B) en faire un master Avis/Rating partagé avec variantes. B implique d'unifier d'abord les trois formes.
D2 — même question pour tout bloc imbriqué : même élément réutilisé → master à part ; stylé au cas par cas / unique → le laisser à l'intérieur.