Pourquoi j'utilise Cursor avec le MCP Figma — et pourquoi je teste quand même sur un iPhone câblé

« Le frontend assisté par IA » voulait dire coller une capture d'écran dans un chat et récupérer un CSS proche, mais jamais avec le bon espacement, le bon gris, la bonne hauteur de ligne. Le Model Context Protocol a changé exactement cette partie du handoff design. Cursor parle au serveur MCP de Figma, et au lieu d'aplatir un frame en pixels que le modèle doit deviner, il reçoit le vrai arbre de nodes : auto-layout, valeurs d'espacement, variables liées, noms de composants, échelle typographique. C'est sur cette partie que je m'appuie vraiment au quotidien.

1. Ce que le MCP réussit vraiment

Je sélectionne un frame dans Figma, je donne le lien à Cursor, et il interroge le serveur MCP pour ce node précis. Ce qui revient est structuré : un gap de 8px est le nombre littéral 8, pas quelque chose que je mesure avec un outil règle sur un PNG. Une couleur est le token de design ou le hex que le designer a lié, pas une valeur que je choisis à la pipette en espérant que ça corresponde. Graisse de police, hauteur de ligne, rayon d'angle, la vraie hiérarchie des composants — tout arrive en données, pas en image que je rétro-ingénierie.

• Des espacements qui correspondent au design system, pas au nombre rond le plus proche que j'ai deviné.
• Couleurs et typo en tokens, donc un rebranding met à jour une variable au lieu d'un grep sur tous les composants.
• Des limites de composants qui correspondent à la façon dont la designer a réellement groupé les choses, ce qui rend le markup généré plus facile à garder sémantique.

2. Ce que je vérifie encore à la main

Les données structurées ne sont pas un jugement. Un frame Figma montre un breakpoint à la fois ; il ne dit pas à Cursor ce qui se passe entre 768px et 1024px, ni à quoi ressemble une carte avec un titre sur deux lignes au lieu d'une. Il n'y a pas d'état vide, pas d'état d'erreur, pas de skeleton de chargement, parce que ceux-là n'ont jamais eu de frame de design. Et le markup généré peut être structurellement fidèle au frame tout en restant une div là où un bouton, une nav ou un titre devrait être — je relis encore chaque composant pour la sémantique et l'accès clavier avant de merger.

3. Pourquoi un émulateur ne suffit pas

La barre d'appareils de Chrome DevTools, c'est Chromium qui rend un viewport redimensionné. Ce n'est pas WebKit, ça n'a pas le comportement de viewport dynamique de Safari iOS, et ça ne montrera pas les bugs qui n'existent que sur le vrai moteur. Donc la dernière étape avant tout déploiement, c'est de brancher un vrai iPhone à mon Mac avec un câble. Réglages → Safari → Avancé → Web Inspector, activé une fois sur le téléphone. Puis un câble Lightning ou USB-C vers le Mac, le menu Develop de Safari détecte l'appareil, et j'obtiens un Web Inspector en direct — vrai DOM, vraie console, vrai panneau réseau — attaché à une page qui tourne réellement sur Safari iOS, pas une simulation.

C'est là que j'attrape les bugs qu'un émulateur cache : un padding safe-area-inset qui semble correct dans DevTools et se fait couper sous l'encoche sur le vrai téléphone, un saut de 100vh quand la barre d'adresse de Safari se rétracte au scroll (dvh corrige ça, mais seul un test en direct le prouve), le saut du focus quand le clavier s'ouvre avec un footer fixe à l'écran, l'overscroll élastique qui tire toute la mise en page, et comment la page se comporte réellement ajoutée à l'écran d'accueil comme PWA autonome. Rien de tout ça n'apparaît dans un émulateur. Tout ça apparaît la première fois qu'un vrai client ouvre le lien sur son propre téléphone — donc je préfère le voir avant.

4. Pourquoi Safari en particulier — le navigateur pour lequel je livre vraiment

Je regarde les analytics avant de décider de ce que « correct » veut même dire pour un projet. Pour la plupart des sites de petites entreprises et de services que je construis, la cliente qui ouvre le site est sur téléphone, arrivant d'Instagram, Telegram, Google Maps ou d'un SMS — et pour une grande part de ce trafic, ce téléphone est un iPhone. Chrome desktop, c'est là où je développe. Safari iOS, c'est là où se trouve réellement la personne avec la carte bancaire. Optimiser le pixel-perfect pour le navigateur que je fixe toute la journée en sautant celui que tient réellement la cliente de mon client, c'est optimiser pour le mauvais public.

La boucle réelle

Frame Figma, sélectionné et transmis à Cursor via le MCP. Composant construit à partir de vrais tokens, pas de pixels devinés. Une passe pour la sémantique, les états et les breakpoints que le frame n'a jamais montrés. Puis l'iPhone sort du tiroir, se branche au Mac, et la même page tourne en direct dans le Web Inspector de Safari sur le vrai moteur. Ce n'est qu'après que quoi que ce soit est mergé. Deux outils différents, deux tâches différentes : l'un me rapproche vite du design, l'autre me dit la vérité sur l'appareil que la cliente de mon client va réellement utiliser.

Vous voulez que ça ait vraiment l'air correct sur le téléphone de votre client ?

C'est le pipeline que j'exécute sur chaque build : de vrais tokens de design en entrée, un vrai appareil en sortie. Écrivez via le formulaire de contact et dites-moi quelle plateforme vos clients utilisent réellement — je construirai et testerai pour celle-là, pas pour le navigateur qui m'arrange.