Design responsive Figma : mises en page mobile et desktop expliquées

Qu'un frame Figma ait l'air correct à la fois sur un desktop en 1440px et un téléphone en 375px ne signifie pas que le comportement responsive entre les deux est réglé — Figma vous montre deux instantanés figés, tandis qu'un navigateur a besoin de règles explicites pour combler tout ce que la taille d'écran d'un visiteur réel peut être. Passer de « ces deux frames ont l'air corrects » à une mise en page qui tient réellement la route implique de lire l'Auto Layout et les constraints comme un signal responsive, pas seulement comme des réglages visuels, et de savoir où s'arrête le travail de Figma et où le CSS doit prendre le relais. Voici le modèle mental pratique, ce qu'il faut vérifier avant de coder, et où se situe la sortie responsive automatique de MarkupGen.

Un frame Figma est une spec visuelle, pas du CSS responsive

Figma affiche un frame à une largeur fixe. Rien dans le fichier ne « joue » à travers les tailles d'écran comme le fait un navigateur — ce qui ressemble à du design responsive dans Figma est en réalité un ensemble de règles (la direction, le gap et les modes de taille de l'Auto Layout ; les constraints d'un calque) qui décrivent une intention, pas une simulation fonctionnelle d'un événement de redimensionnement. C'est le CSS qui rend cette intention réelle : flex-direction, gap, les pourcentages, clamp() et les règles @media sont ce qui répond réellement à la largeur du viewport. Traitez le fichier Figma comme la source de vérité pour l'intention, pas comme quelque chose qui contiendrait déjà du CSS responsive terminé.

Les frames mobile et desktop décrivent un seul design, pas deux

Il est courant de voir, dans un même fichier, un frame desktop et un frame mobile conçus à plusieurs semaines d'intervalle et qui ont dérivé sans qu'on s'en rende compte — niveaux de titres différents, variantes de composants différentes, contenu présent sur l'un et absent de l'autre sans raison claire. Traitez plutôt les deux frames comme deux vues du même modèle de contenu : les mêmes titres, les mêmes composants (en utilisant des variantes pour les états, pas des duplicatas ponctuels), et la même information dans le même ordre, sauf raison délibérée de le modifier. Quand les deux frames partagent cette structure sous-jacente, le travail CSS qui suit relève surtout de la mise en page — transformer une rangée en colonne, ajuster le nombre de colonnes d'une grille, replier une UI secondaire — plutôt que de maintenir deux gabarits déconnectés.

Auto Layout et constraints : ce qui influence vraiment le comportement responsive

La direction, le gap, le padding et les modes de taille (hug, fill, fixed) de l'Auto Layout se rapprochent de Flexbox — voir Figma Auto Layout vers CSS pour la correspondance complète propriété par propriété. Pour le comportement responsive en particulier, le mode de taille est le signal le plus important : un élément « fill » vous indique qu'il doit grandir ou rétrécir avec son conteneur (flex: 1, width: 100%), tandis que « fixed » indique le contraire.

Les constraints répondent à une question différente : comment un élément se comporte quand son parent est redimensionné, ce qui compte surtout pour tout ce qui est en dehors de l'Auto Layout :

• Gauche / Droite — ancré à un bord, proche d'un décalage fixe qui reste en place quand le parent est redimensionné.
• Gauche et Droite — s'étire avec le parent, proche de width: 100% avec des marges latérales fixes.
• Centre — reste centré quand le parent est redimensionné, similaire à margin: 0 auto ou à un placement flex/grid centré.
• Scale — se redimensionne proportionnellement avec le parent ; le CSS n'a pas d'équivalent direct unique, et cela se rapproche généralement d'unités relatives.
• Haut / Bas (et combinaisons) — la même logique appliquée à l'axe vertical.

Beaucoup de fichiers réels utilisent les deux ensemble : l'Auto Layout pour la façon dont les enfants d'un conteneur s'organisent entre eux, les constraints pour la façon dont ce conteneur se comporte à l'intérieur de quelque chose de plus grand que lui.

Breakpoints : des frames Figma au vrai CSS

Figma n'a pas de fonctionnalité native de breakpoints — il n'existe aucun réglage du type « changer de mise en page en dessous de 768px ». Ce qu'un fichier vous donne réellement, c'est soit des frames distincts par taille d'écran, soit un unique frame Auto Layout qui se redimensionne de façon fluide sans aucun changement structurel. Lequel des deux vous avez sous les yeux détermine si le CSS a besoin de règles @media explicites, et choisir des valeurs de breakpoint qui correspondent à l'endroit où la mise en page change réellement de forme — pas des largeurs d'appareil arbitraires — constitue l'essentiel du travail. Des breakpoints Figma aux media queries CSS couvre les deux schémas en détail et les endroits où la traduction manuelle se trompe généralement.

Traduire les décisions Figma en CSS responsive

Une fois les signaux côté Figma clairs, le CSS repose sur un ensemble d'outils assez restreint, appliqué de façon cohérente :

• Flexbox pour la plupart des frames Auto Layout — lignes, colonnes, barres de navigation, listes de cartes.
• Grid pour les mises en page réellement bidimensionnelles, comme un tableau de bord ou une galerie que l'Auto Layout simule avec des lignes et colonnes imbriquées.
• Media queries là où la forme de la mise en page change — une sidebar qui devient une barre de navigation basse, une grille qui devient une colonne unique.
• Dimensionnement fluide (pourcentages, minmax(), clamp()) pour tout ce qui se situe entre les largeurs réellement spécifiées par le designer, plutôt que d'ajouter des breakpoints pour combler les écarts.
• max-width pour empêcher le texte et le contenu de s'étirer de façon inconfortable sur grand écran, même si le frame Figma lui-même n'en montre pas.
• Retour à la ligne et empilement (flex-wrap, une rangée qui devient une colonne) pour le contenu qui doit se reformater plutôt que rétrécir.
• Changements de visibilité pour tout ce qui est réellement réservé au mobile ou au desktop — à faire avec soin, car masquer un élément avec display: none le retire aussi de l'arbre d'accessibilité. Voir Figma vers HTML accessible si le contenu masqué doit rester accessible autrement, comme un menu mobile.

Erreurs courantes en traduisant Figma en mises en page responsive

• Traiter le mobile comme un desktop réduit au lieu d'une mise en page à part entière, avec sa propre hiérarchie et ses propres priorités.
• Coder en dur des dimensions en pixels partout où le frame Figma affiche un nombre précis, au lieu d'utiliser le dimensionnement fill/fixed et les constraints pour décider ce qui doit réellement rester fixe.
• Ignorer le retour à la ligne du texte — un titre ou un libellé de bouton qui tient sur une ligne dans la langue source peut s'étaler sur deux ou trois lignes dans une traduction plus longue, et une mise en page qui suppose un texte sur une seule ligne se casse.
• S'appuyer sur le positionnement absolu pour reproduire un design pixel par pixel, ce qui a l'air correct à la largeur exacte du frame mais casse à toutes les largeurs intermédiaires.
• Ne vérifier que les largeurs auxquelles les frames Figma ont été dessinés — par exemple 375px et 1440px — en négligeant tout ce qui se trouve entre les deux, là où se produisent la plupart des vraies casses.

Checklist de handoff développeur

Avant d'implémenter le comportement responsive à partir d'un fichier Figma, il vaut la peine de vérifier certains points directement dans le design plutôt que de les supposer :

• Quels frames existent, et si mobile et desktop sont censés être le même contenu restructuré, ou des expériences réellement différentes.
• Les réglages Auto Layout de chaque frame — direction, gap, padding et mode de taille sur les éléments qui doivent se redimensionner.
• Les constraints sur tout ce qui est en dehors de l'Auto Layout, en particulier les éléments ancrés à un bord ou centrés.
• L'espacement et la typographie à chaque largeur de frame — évoluent-ils, ou restent-ils fixes ?
• Les variantes de composants — un composant a-t-il une variante mobile distincte, ou s'agit-il du même composant censé s'adapter ?
• Ce qui est réellement différent entre les frames mobile et desktop, et si chaque différence est intentionnelle ou n'est qu'une dérive entre des fichiers modifiés à des moments différents.

Comment MarkupGen automatise la base responsive

Chaque export part des réglages Auto Layout propres au frame et de ses constraints de redimensionnement, pas d'une liste de breakpoints générique — direction, gap et padding sont repris à l'identique, et le dimensionnement fill/hug se traduit en CSS fluide, de sorte que le résultat s'adapte aux tailles d'écran sans media queries écrites à la main pour la plupart des mises en page.

Pour les designs où le mobile a réellement besoin d'une structure différente — une navigation empilée plutôt qu'horizontale, un hero réorganisé, une sidebar masquée — l'éditeur intégré peut générer, à partir du HTML/CSS existant, une mise en page Mobile ou Desktop distincte et dédiée à la page en cours, avec sa propre media query ; vous la relisez avant de l'appliquer, et c'est ensuite la taille d'écran du visiteur qui décide laquelle s'affiche. Dans tous les cas, le résultat privilégie le HTML sémantique plutôt que des <div> imbriquées, en Vanilla CSS, Tailwind, Bootstrap, Bulma, Materialize ou Pico, avec un score de qualité IA automatique sur chaque export. Rien de tout cela ne remplace la checklist ci-dessus — c'est un point de départ généré à partir des signaux réels du design, à relire de la même façon que vous relieriez toute autre implémentation responsive avant la mise en production.

Si vous voulez voir comment votre propre fichier Figma répond sur les deux tailles d'écran, essayez le convertisseur Figma vers HTML — ou convertissez directement en React si c'est votre stack — gratuitement, sans carte bancaire.

FAQ

Comment un design Figma doit-il gérer les mises en page mobile et desktop ? Traitez-les comme un seul design exprimé à deux largeurs — le même contenu, les mêmes titres et les mêmes composants — plutôt que comme deux fichiers indépendants. L'Auto Layout et les constraints décrivent la façon dont cette structure commune doit s'adapter ; les vraies différences structurelles, comme une navigation repliée ou un hero réorganisé, sont ensuite implémentées avec des media queries CSS.

L'Auto Layout et les constraints de Figma rendent-ils un design responsive automatiquement ? Non. Ils décrivent une intention — comment un élément doit se dimensionner ou se comporter quand son conteneur change — mais cette intention doit encore être traduite en Flexbox, Grid, dimensionnement fluide ou media queries dans du vrai CSS. Ni Figma ni un outil de conversion ne génère seul toutes les décisions responsives.

Comment choisir les breakpoints CSS à partir d'un design Figma ? Figma n'a pas de fonctionnalité native de breakpoints, donc basez vos breakpoints sur l'endroit où la forme de la mise en page change réellement, pas sur des largeurs d'appareil arbitraires. Si un design utilise des frames séparés par taille d'écran, la mise en page de chaque frame devient généralement un bloc @media ; s'il s'appuie sur le redimensionnement fluide de l'Auto Layout, il n'a souvent besoin d'aucun breakpoint.

Quelle est la différence entre l'Auto Layout et les constraints dans Figma ? L'Auto Layout contrôle la façon dont les enfants d'un frame sont organisés — direction, gap, padding, taille — ce qui se rapproche le plus de display: flex. Les constraints contrôlent le comportement d'un élément quand son parent est redimensionné, comme être ancré à un bord, centré ou mis à l'échelle, ce qui compte surtout pour les éléments en dehors de l'Auto Layout ou pour la façon dont un frame Auto Layout se positionne dans quelque chose de plus grand.

Le mobile et le desktop doivent-ils être des fichiers Figma séparés ? Pas nécessairement, et les garder dans le même fichier avec des composants partagés facilite généralement la détection des dérives. Ce qui compte plus que la structure des fichiers, c'est de savoir si les deux frames représentent le même modèle de contenu — les mêmes composants et la même hiérarchie — la mise en page, et non le contenu, étant ce qui change entre les deux.

Que dois-je vérifier avant d'implémenter un design Figma en responsive ? Les frames qui existent, les réglages Auto Layout et constraints de chacun, la façon dont l'espacement et la typographie changent (ou non) entre eux, si les composants ont des variantes mobiles distinctes, et lesquelles des différences entre les frames mobile et desktop sont intentionnelles plutôt qu'une dérive accidentelle.