MarkupGenMarkupGen
DocsRessourcesBlogCas d'usageComparer
Se connecterConvertir gratuitement
  1. MarkupGen
  2. /Blog
  3. /Figma Auto Layout vers CSS : comment ça se traduit en Flexbox (et quand utiliser Grid)
Retour au blog

Publié le 2026-08-05 · Par L'équipe MarkupGen

Figma Auto Layout vers CSS : comment ça se traduit en Flexbox (et quand utiliser Grid)

Figma Auto Layout vers CSS : comment ça se traduit en Flexbox (et quand utiliser Grid)

Si vous avez déjà ouvert un fichier Figma et vu "Auto Layout" activé sur un frame, vous avez déjà eu sous les yeux quelque chose de très proche de CSS Flexbox — les designers de Figma ont délibérément repris ce modèle mental. Direction, gap, padding et alignement se transposent presque un pour un. Là où la correspondance Figma-vers-CSS devient ambiguë, c'est sur le comportement de taille : "hug", "fill" et "fixed" décrivent une intention, pas une déclaration CSS unique, et le résultat correct dépend du contexte de mise en page environnant. Comprendre où la correspondance est directe et où elle ne l'est pas, c'est ce qui permet de passer d'un fichier de design à du CSS responsive et maintenable sans deviner chaque valeur à l'œil.

Ce que contrôle réellement Auto Layout

Auto Layout est la façon dont Figma transforme un frame en véritable conteneur de mise en page, plutôt qu'en simple groupe de formes positionnées de manière absolue. Une fois activé sur un frame, plusieurs propriétés deviennent configurables :

  • Direction — les enfants s'empilent verticalement ou horizontalement.
  • Espacement (gap) — la distance fixe entre chaque élément enfant.
  • Padding — l'espace entre le bord du frame et ses enfants, réglable côté par côté.
  • Alignement — la façon dont les enfants s'alignent sur l'axe principal et l'axe secondaire.
  • Comportement de redimensionnement — le frame et ses enfants s'ajustent-ils au contenu, remplissent-ils l'espace disponible, ou gardent-ils une taille fixe.

Rien n'est arbitraire ici. Chaque propriété existe parce qu'elle correspond à une information dont un véritable moteur de mise en page a besoin — c'est exactement pourquoi elle se traduit si proprement en CSS Flexbox dans la plupart des cas.

Figma Auto Layout vers Flexbox : tableau de correspondance

Ce tableau constitue le cœur pratique de la traduction Figma-vers-CSS. La plupart des lignes sont une équivalence directe ; certaines dépendent du contexte, ce que la colonne Notes précise explicitement.

Propriété Auto Layout Figma Équivalent CSS Notes
Direction horizontale flex-direction: row Valeur par défaut de Flexbox ; les enfants se placent de gauche à droite.
Direction verticale flex-direction: column Les enfants s'empilent de haut en bas.
Gap gap Équivalent direct — inutile de recourir à des astuces avec margin.
Padding padding S'applique au frame qui a Auto Layout activé, pas à ses enfants.
Alignement (axe principal) justify-content Le contrôle d'alignement sur "l'axe principal" de Figma.
Alignement (axe secondaire) align-items, ou align-self sur un enfant précis Figma permet à un seul enfant de surcharger l'alignement du groupe — cela se traduit par align-self, pas par un second align-items.
Ajuster au contenu (hug) souvent aucune taille explicite, ou width/height: fit-content Ce n'est pas une règle universelle — cela dépend si l'élément est un flex item, un élément de type bloc, ou autre chose.
Remplir le conteneur (fill) flex: 1, width: 100%, ou align-self: stretch, selon l'axe Aucune déclaration CSS unique ne remplit toujours un conteneur ; la bonne dépend du mode de mise en page du parent.
Largeur/hauteur fixe width / height explicites, parfois avec des bornes min-/max- Simple en apparence, mais vérifiez si le design impose une limite stricte ou juste une taille par défaut courante.
Mode d'espacement ("packed" vs "space between") gap pour packed ; justify-content: space-between pour space-between Dans Figma, ces modes sont généralement mutuellement exclusifs — space-between distribue l'espace au lieu d'utiliser un gap fixe.
Auto Layout imbriqué éléments imbriqués, chacun avec son propre display: flex Chaque frame imbriqué est un contexte de formatage flex indépendant — traduisez la structure, pas seulement les valeurs.

La nuance importante : "Fill container" dans Figma ne se traduit pas toujours par une seule déclaration CSS universelle. Selon que l'élément se trouve dans un conteneur flex, un conteneur de type bloc ou une grille, il faudra flex: 1, width: 100% ou align-self: stretch — la même propriété Figma peut exiger un CSS différent selon son parent.

Le modèle mental : conteneur Auto Layout → conteneur flex

Une fois l'interface Figma mise de côté, les concepts se superposent directement :

Figma CSS
Frame avec Auto Layout Conteneur avec display: flex
Direction flex-direction
Alignement align-items / justify-content
Gap gap
Padding padding
Comportement de taille (hug / fill / fixed) propriétés width / height / flex

Chaque frame Auto Layout est un conteneur flex en puissance. Le vrai travail consiste à décider, pour chaque frame, ce que signifie réellement son comportement de taille dans le CSS correspondant — ce qui fait l'objet de la section suivante.

Hug contents, fill container et taille fixe

Le comportement de taille est là où la traduction manuelle de Figma vers CSS échoue le plus souvent, car Figma exprime une intention alors que CSS exige une déclaration précise.

Hug contents (ajuster au contenu)

Un élément "hug contents" se dimensionne autour de son contenu — il n'a pas de dimension fixe et grandit ou rétrécit selon le contenu. Sur le web, l'équivalent le plus proche consiste souvent à ne simplement définir aucun width ou height explicite, puisque les éléments de bloc et les flex items se dimensionnent déjà selon leur contenu par défaut. Quand il faut être explicite, width: fit-content ou height: fit-content s'en approche, mais ce n'est pas universellement équivalent : dans un conteneur flex, un item sans flex-grow se comporte déjà comme "hug" sans CSS supplémentaire, donc ajouter fit-content par-dessus peut être redondant, voire subtilement différent du comportement par défaut selon les navigateurs.

/* Figma : Hug contents, Auto Layout horizontal */
.button {
  display: flex;
  width: fit-content; /* souvent inutile — les flex items s'ajustent déjà au contenu par défaut */
}

Fill container (remplir le conteneur)

Un élément "fill container" s'étend pour occuper l'espace disponible. Le CSS correct dépend entièrement du parent :

  • Dans un conteneur flex, sur l'axe principal : flex: 1 (ou flex-grow: 1).
  • Dans un conteneur flex, sur l'axe secondaire : align-self: stretch.
  • Dans un parent de type bloc : width: 100%.
/* Figma : Fill container, enfant d'un frame Auto Layout horizontal */
.sidebar-content {
  flex: 1;
}

Il n'existe pas de règle unique "fill container → CSS" qui fonctionne partout. Si le contexte de mise en page du parent est mal identifié, flex: 1 sur un élément qui n'est pas un flex item ne fait rien.

Fixed (taille fixe)

Les dimensions fixes dans Figma se traduisent généralement par un width et/ou height explicite en CSS. Mais une valeur en pixels copiée telle quelle depuis Figma n'est pas toujours la bonne cible : vérifiez si le design impose une contrainte stricte (width: 240px) ou une borne sur un élément par ailleurs flexible (min-width / max-width, min-height / max-height). Traiter chaque valeur fixe comme un width strict est une cause fréquente de mises en page qui ne s'adaptent pas au contenu réel ou aux différents viewports.

Auto Layout vs Constraints

Auto Layout et Constraints résolvent des problèmes liés mais différents, et les confondre est une source fréquente d'erreurs de traduction.

  • Auto Layout contrôle la façon dont les enfants d'un frame sont organisés entre eux — direction, gap, padding, alignement et comportement de taille. C'est l'équivalent le plus proche de display: flex.
  • Constraints contrôlent le comportement d'un élément quand son parent est redimensionné — ancré à gauche/droite/haut/bas/centre, ou mis à l'échelle. Les constraints sont surtout pertinentes pour les éléments qui ne sont pas du tout dans un frame Auto Layout, ou pour définir comment un frame Auto Layout lui-même se comporte dans un parent de taille fixe.

En pratique, le CSS final d'un élément a souvent besoin des deux informations : Auto Layout donne les propriétés flex d'un conteneur et de ses enfants, tandis que les constraints indiquent si ce conteneur doit être traité comme fixe ou doit se redimensionner avec son propre parent. Aucun des deux, seul, ne donne le tableau responsive complet.

Comment Auto Layout aide le CSS responsive

Auto Layout fournit de vraies indications pour le comportement responsive, mais il ne se transforme pas automatiquement en CSS responsive à lui seul. Il vaut la peine d'être précis sur ce qu'il apporte réellement :

  • Le comportement de taille d'Auto Layout (hug / fill / fixed) indique quels éléments doivent grandir, rétrécir ou rester fixes — c'est la base d'une mise en page responsive, traduite directement en flex, width: 100%, ou une taille fixe.
  • Les constraints de Figma ajoutent des informations sur la façon dont les éléments doivent se comporter quand leur conteneur est redimensionné, ce qui compte pour tout ce qui n'est pas régi par Auto Layout.
  • Aucun des deux ne génère de breakpoints. Si la mise en page d'un design change réellement de forme à certaines largeurs — colonnes qui s'empilent, navigation qui se replie — cela nécessite toujours des media queries CSS, car les frames Figma représentent généralement quelques tailles de viewport fixes, pas toute la plage entre elles.
  • Entre les tailles que le designer a réellement spécifiées, un dimensionnement fluide (pourcentages, flex, minmax(), clamp()) reproduit souvent le comportement voulu plus fidèlement que l'ajout de breakpoints supplémentaires pour combler les écarts.

L'objectif est de reproduire le comportement voulu de la mise en page à travers les viewports, pas de recopier les dimensions en pixels du frame Figma que vous aviez sous les yeux.

Quand CSS Grid est plus adapté

Auto Layout est un modèle à axe unique : très efficace pour les lignes et les colonnes, y compris en combinaisons imbriquées. Mais certains designs sont véritablement bidimensionnels, et les forcer dans du Flexbox imbriqué produit un code plus difficile à maintenir que le design original. Le bon choix dépend de la mise en page : Flexbox convient aux agencements unidimensionnels (navigation, groupes de boutons, une rangée de cartes, contenu aligné verticalement ou horizontalement), tandis que Grid convient aux agencements bidimensionnels. Passez à CSS Grid dès que vous observez :

  • Une mise en page où les éléments doivent s'aligner à la fois sur les lignes et les colonnes — grilles de cartes, tableaux de bord, galeries d'images.
  • Un comportement explicite du type "cet élément s'étend sur deux colonnes" ou "sur deux lignes", que Grid gère nativement avec grid-column / grid-row, et que Flexbox ne peut pas exprimer directement.
  • Des designs où le nombre de colonnes doit s'adapter à la largeur disponible (repeat(auto-fit, minmax(...))) plutôt qu'à une liste fixe de breakpoints.
  • Des zones qui se chevauchent ou se superposent au sein d'une même grille, ce qui reste simple avec le système de placement de Grid mais laborieux avec Flexbox.

Une règle simple : si l'Auto Layout d'un frame Figma ne s'imbrique jamais que dans une seule direction à la fois, Flexbox constitue une traduction fidèle. Si vous vous surprenez à construire une grille de frames Auto Layout pour simuler un alignement lignes-colonnes, c'est généralement le signe que l'interface de Figma compense l'absence d'un véritable mode de mise en page Grid bidimensionnel — et il vaut mieux, dans ce cas, générer du vrai CSS Grid.

Pièges courants d'Auto Layout vers CSS

Même avec une correspondance claire, les développeurs qui reproduisent Auto Layout à la main butent souvent sur les mêmes détails :

  • L'alignement mixte se retrouve aplati. Figma permet à chaque enfant de surcharger l'alignement du groupe ; il est facile de survoler ce détail et d'appliquer une seule valeur align-items à tout le monde, perdant ainsi les surcharges individuelles qui nécessitent align-self.
  • L'ambiguïté entre "hug" et "fill". Un frame réglé pour s'ajuster à son contenu ressemble à un frame de largeur fixe sur une seule taille d'écran, mais se comporte de façon totalement différente dès que le contenu ou la taille d'écran change.
  • gap négligé au profit de margin. Certains développeurs continuent d'utiliser des astuces à base de margin au lieu de gap, héritage des anciennes pratiques Flexbox — devenu inutile maintenant que gap bénéficie d'un excellent support navigateur, et cela réintroduit exactement les bugs d'espacement que gap était censé résoudre.
  • Les frames Auto Layout imbriqués deviennent des conteneurs flex imbriqués sans réflexion. Chaque frame imbriqué constitue son propre contexte flex, et une traduction littérale, un pour un, peut générer plus d'éléments wrapper que nécessaire.
  • Padding appliqué au mauvais élément. Il est facile d'appliquer le padding d'un frame à un enfant plutôt qu'au conteneur, ce qui fausse l'espacement basé sur gap entre les éléments frères.
  • Supposer qu'Auto Layout rend seul une mise en page responsive. Comme vu plus haut, Auto Layout et les constraints informent le comportement responsive — ils ne remplacent pas les media queries quand la forme de la mise en page doit réellement changer.
  • Imbriquer du Flexbox pour simuler une grille bidimensionnelle. Si vous empilez des frames Auto Layout pour aligner à la fois lignes et colonnes, c'est généralement le signe que CSS Grid est la cible la plus adaptée.

Utiliser Auto Layout dans un workflow Figma-vers-code

Cette correspondance est bien connue, mais l'appliquer correctement sur chaque frame, chaque valeur de gap et chaque conteneur imbriqué d'un vrai fichier de design — tout en interprétant en plus la direction, la taille et la hiérarchie entre frames — est fastidieux. C'est exactement ce type de travail de traduction répétitif que MarkupGen est conçu pour aider à résoudre. Le processus tient en quatre étapes : exporter le frame depuis Figma via le plugin dédié, qui récupère structure, styles et images directement dans votre espace de travail ; l'IA de MarkupGen construit le HTML et le CSS à partir de cette structure réelle, en mappant la direction, le gap, le padding et l'alignement d'Auto Layout vers une structure Flexbox équivalente ; vous affinez ensuite le contenu, les polices et la mise en page visuellement dans un éditeur intégré ; puis vous exportez le package final. Les breakpoints responsives sont générés à partir des contraintes de redimensionnement du design, et vous choisissez le format de sortie — HTML/CSS classique, Tailwind CSS, ou composants React — selon votre stack. Comme pour toute conversion automatisée, vérifiez le comportement de taille sur les éléments hug/fill/fixed et les breakpoints déduits — ce sont un bon point de départ, pas un substitut à la vérification du résultat par rapport au design. Si vous préférez partir d'un exemple fonctionnel plutôt que d'un fichier vide, essayez le convertisseur Figma vers HTML de MarkupGen sur votre propre design, ou consultez le guide complet de conversion Figma vers HTML pour découvrir le workflow de bout en bout.

FAQ

Comment Figma Auto Layout se traduit-il en CSS ? Direction, gap, padding et alignement se traduisent directement en flex-direction, gap, padding et justify-content/align-items. Le comportement de taille — hug, fill et fixed — se traduit aussi en CSS, mais la déclaration exacte dépend du contexte de mise en page plutôt que d'être une correspondance fixe un pour un.

Figma Auto Layout est-il la même chose que CSS Flexbox ? Ils sont étroitement liés, mais pas identiques. Auto Layout a été délibérément modelé sur les concepts de Flexbox, donc la plupart des propriétés se transposent directement. La principale différence est que Figma exprime la taille comme une intention de design (hug, fill, fixed), tandis que CSS exige de choisir la déclaration précise qui produit cette intention dans un contexte donné.

Que signifie "hug contents" en CSS ? Cela signifie que l'élément se dimensionne autour de son contenu au lieu d'avoir une taille fixe ou étirée. Sur le web, c'est souvent le comportement par défaut des éléments de bloc et des flex items sans largeur explicite, ou cela peut être rendu explicite avec width: fit-content / height: fit-content si nécessaire.

Que signifie "fill container" en CSS ? Cela signifie que l'élément s'étend pour utiliser l'espace disponible dans son parent. Selon le contexte, c'est flex: 1 sur l'axe principal d'un conteneur flex, align-self: stretch sur l'axe secondaire, ou width: 100% dans un parent de type bloc — il n'y a pas de déclaration unique qui s'applique toujours.

Figma Auto Layout crée-t-il automatiquement du CSS responsive ? Non. Le comportement de taille d'Auto Layout et les constraints de Figma fournissent des indications utiles sur la façon dont les éléments doivent s'adapter, mais les breakpoints pour les mises en page qui changent de forme à différentes largeurs doivent toujours être écrits sous forme de media queries CSS.

Faut-il utiliser CSS Grid ou Flexbox pour un design Figma ? Cela dépend de la mise en page, pas de savoir lequel est "meilleur". Flexbox convient aux agencements unidimensionnels — lignes, colonnes, navigation, groupes de boutons. Grid convient aux mises en page véritablement bidimensionnelles, comme les tableaux de bord ou les grilles de cartes où les éléments doivent s'aligner à la fois sur les lignes et les colonnes.

Essayez-le avec Figma to HTML

À lire aussi

Figma to HTML vs React vs Tailwind : lequel choisir ?Blog

Figma to HTML vs React vs Tailwind : lequel choisir ?

Un guide de décision pour les trois choix de sortie les plus demandés de MarkupGen — quand exporter Figma en HTML/CSS, quand exporter en React, et où Tailwind trouve vraiment sa place.

Lire la suite
De Figma au code : React, Vue et frameworks CSS chez MarkupGenBlog

De Figma au code : React, Vue et frameworks CSS chez MarkupGen

MarkupGen convertit un design Figma en composants React ou Vue 3 (plus Svelte et Angular), ou en HTML/CSS avec Tailwind, Bootstrap et bien d'autres.

Lire la suite
Comment évaluer le HTML généré par IA avant de le livrerBlog

Comment évaluer le HTML généré par IA avant de le livrer

Une checklist reproductible pour juger un export Figma vers code IA au-delà du « ça a l'air bon » — fidélité visuelle, sémantique, responsive, accessibilité et poids.

Lire la suite
Le HTML généré depuis Figma est-il prêt pour le SEO ?Blog

Le HTML généré depuis Figma est-il prêt pour le SEO ?

Un HTML converti peut ressembler exactement au design et nuire quand même au SEO. La checklist à suivre avant de publier un export Figma vers code.

Lire la suite
Figma vers HTML accessible : le guide pratiqueBlog

Figma vers HTML accessible : le guide pratique

Ce que l'accessibilité exige vraiment dans un workflow Figma vers HTML — balisage sémantique, titres, ARIA, formulaires, contraste et navigation au clavier.

Lire la suite
Figma vers CSS : le guide pratique de conversionBlog

Figma vers CSS : le guide pratique de conversion

Oubliez la dépendance à un framework. Comment les valeurs Figma se convertissent en CSS pur, directement modifiable — et quand ce choix l'emporte sur Tailwind ou Bootstrap.

Lire la suite
Comparer

MarkupGen vs. TeleportHQ : convertisseur ou plateforme low-code

TeleportHQ associe l'export Figma-to-code à un CMS, des formulaires et un hébergement intégrés ; MarkupGen reste concentré sur un résultat HTML/CSS/React propre et autonome.

Lire la suite
MarkupGen pour les développeurs front-endCas d'usage

MarkupGen pour les développeurs front-end

Ne reconstruisez plus vos maquettes à la main. Transformez vos frames Figma en HTML/CSS ou composants React propres et concentrez-vous sur la logique, pas sur le layout.

Lire la suite

Transformez votre prochain design Figma en code en quelques minutes

Commencez gratuitement et exportez du HTML, CSS ou React propre depuis n'importe quel fichier Figma.

Convertir gratuitement
MarkupGenMarkupGen© 2025 MarkupGen. Tous droits réservés.
BlogCas d'usageComparerRessources
À proposDocumentationConfidentialitéConditionsContact