Découvrez comment l'IA déduit la mise en page, la hiérarchie et l'intention utilisateur à partir des designs, puis génère du code UI — limites, bonnes pratiques et conseils de revue.
« Design to code » par IA traduit une idée visuelle — généralement une frame Figma ou une capture d'écran — en code UI exécutable. L'objectif n'est pas un code parfait, mais un premier jet utilisable qui capture structure, styles et comportements basiques pour qu'un humain puisse l'affiner.
Au fond, le système mappe ce qu'il peut observer vers la façon dont les UIs sont typiquement construites.
L'IA peut deviner des motifs courants : une rangée d'icônes est probablement une barre d'outils ; un label empilé au-dessus d'un input est souvent un champ de formulaire ; des styles cohérents suggèrent un composant réutilisable. Elle peut aussi estimer le comportement responsive depuis les contraintes et espacements.
Mais vous devez généralement préciser ce que les pixels ne garantissent pas : noms réels de composants, design tokens (couleurs/échelle typographique), états (hover/disabled/error), breakpoints, règles de données et interactions effectives (validation, cibles de navigation, analytics).
Considérez la sortie comme un point de départ. Prévoyez de vérifier la structure, remplacer les styles ad hoc par des tokens, l'aligner sur votre bibliothèque de composants et itérer. « Design to code » accélère le travail, mais n'élimine pas le jugement des designers et développeurs.
L'IA ne peut pas déduire les règles produit d'un « bel écran ». Elle s'appuie sur les preuves que vous fournissez — certaines décrivent les pixels, d'autres la structure. Cette différence détermine souvent si vous obtenez un code UI propre ou un positionnement absolu fragile.
Une capture d'écran est l'entrée la plus pauvre : elle contient couleurs et formes, mais pas d'informations explicites sur ce qui est un bouton vs un label, ce qui est réutilisable, ou comment la mise en page doit s'adapter.
À partir des pixels seuls, l'IA doit deviner les limites (où un élément se termine et un autre commence), les styles de texte, les règles d'espacement et même si une « carte » est un seul composant ou plusieurs pièces séparées. Elle ne peut pas non plus inférer les contraintes — le comportement responsive reste donc majoritairement spéculatif.
Quand l'IA peut accéder au fichier de design (ou à un export qui preserve la structure), elle récupère des métadonnées cruciales : frames, groupes, noms de calques, réglages Auto Layout, contraintes et définitions de texte/styles.
C'est là que la mise en page devient autre chose que de la géométrie. Par exemple, une frame Figma en Auto Layout communique l'intention « empiler ces éléments verticalement avec 16px d'écart » bien mieux qu'une capture d'écran. Un nommage cohérent des calques aide aussi à mapper les éléments aux rôles UI (par ex. « Button/Primary », « Nav Item », « Input/Error »).
Un design system connecté réduit les conjectures. Les tokens (couleurs, espacements, typographies) permettent à l'IA de générer du code qui référence une source de vérité au lieu de valeurs hardcodées. Les composants publiés fournissent des blocs prêts à l'emploi et des limites claires pour la réutilisation.
Même de petites conventions — nommer des variantes (Button/Primary, Button/Secondary) et utiliser des tokens sémantiques (text/primary au lieu de #111111) — améliorent fortement le mapping de composants.
Les specs ajoutent le « pourquoi » derrière l'UI : comportement au survol, états de chargement et vides, règles de validation, navigation clavier et messages d'erreur.
Sans cela, l'IA génère souvent un instantané statique. Avec ces informations, la sortie peut inclure des hooks d'interaction, de la gestion d'état et des APIs de composants plus réalistes — plus proche de quelque chose qu'une équipe peut livrer et maintenir.
Les outils design-to-code ne perçoivent pas un écran comme un humain ; ils essaient d'expliquer chaque calque en règles de mise en page : lignes, colonnes, conteneurs et espacements. Plus ces règles sont claires, moins la sortie dépend d'un positionnement fragile.
La plupart des modèles commencent par chercher des alignements répétés et des écarts égaux. Si plusieurs éléments partagent le même bord gauche, baseline ou centre, l'IA les traite souvent comme une colonne ou une piste de grille. Des espacements constants (par ex. 8/16/24) suggèrent que la mise en page peut s'exprimer avec des gaps de stack, des gutters de grille ou des tokens d'espacement.
Quand l'espacement varie légèrement (15px ici, 17px là), l'IA peut conclure que la mise en page est « manuelle » et retomber sur des coordonnées absolues pour préserver la distance pixel-perfect.
L'IA recherche aussi les signaux d'enfermement visuel : arrière-plans, bordures, ombres et des espaces ressemblant à du padding qui suggèrent un conteneur. Une carte avec un fond et un padding interne est un signal clair pour un élément parent contenant des enfants.
Elle cartographie ensuite souvent la structure en primitives telles que :
Un groupement propre dans le fichier de design aide à distinguer parents et frères.
Si le design inclut des contraintes (pinning, hug, fill), l'IA s'en sert pour décider de ce qui s'étire et de ce qui reste fixe. Les éléments en « fill » deviennent typiquement flexibles (flex: 1), tandis que le mode « hug » se mappe à des éléments à la taille du contenu.
Le positionnement absolu apparaît généralement quand le modèle ne peut pas exprimer de façon confiante les relations avec des layouts en flux — souvent à cause d'espacements incohérents, de calques qui se chevauchent ou d'éléments mal alignés. Cela peut sembler correct sur une taille d'écran mais casser la responsivité et le redimensionnement du texte.
Utiliser une petite échelle d'espacements et s'aligner sur une grille claire augmente fortement la probabilité que l'IA produise du code flex/grid propre plutôt que des coordonnées. La cohérence n'est pas qu'esthétique — c'est un motif lisible par machine.
L'IA n'« comprend » pas la hiérarchie ; elle l'infère à partir de motifs qui la signalent habituellement. Plus votre design communique clairement ces signaux, mieux le code généré reflétera votre intention.
La typographie est un indice puissant. Une taille plus grande, une graisse plus forte, un contraste supérieur et un interligne généreux indiquent généralement une priorité plus élevée.
Par exemple, un titre en 32px bold au-dessus d'un paragraphe en 16px normal forme un pattern clair « titre + corps ». Les cas ambigus surviennent quand les styles se confondent — par ex. deux blocs de texte qui diffèrent de seulement 1–2px ou utilisent la même graisse avec des couleurs différentes. L'IA peut alors marquer les deux comme texte courant ou choisir un niveau de titre inadapté.
La hiérarchie s'infère aussi par les relations spatiales. Les éléments proches, alignés et séparés du reste par du blanc sont traités comme un groupe.
Les arrière-plans communs (cartes, panneaux, sections teintées) agissent comme des parenthèses visuelles : l'IA les interprète souvent comme des conteneurs tels que section, aside ou un wrapper de composant. Des paddings irréguliers ou des espacements incohérents peuvent provoquer un regroupement accidentel — par exemple un bouton rattaché à la mauvaise carte.
Les motifs répétés — cartes identiques, éléments de liste, lignes ou champs — sont une forte preuve d'un composant réutilisable. De petites différences (taille d'icône, rayon de coin, style de texte) peuvent cependant pousser l'IA à générer plusieurs versions ponctuelles au lieu d'un seul composant avec variantes.
Les boutons communiquent l'intention par la taille, le remplissage, le contraste et la position. Un bouton rempli à fort contraste est généralement traité comme action primaire ; un bouton outline ou texte devient secondaire. Si deux actions semblent aussi mises en évidence, l'IA peut se tromper sur la vraie action « primaire ».
Enfin, l'IA essaie de mapper la hiérarchie vers la sémantique : titres (h1–h6), régions groupées (section) et clusters signifiants (comme « détails produit » vs « actions d'achat »). Des pas typographiques clairs et un groupement cohérent rendent cette traduction beaucoup plus fiable.
Les modèles prédisent l'intention en rapprochant ce qu'ils voient de motifs appris sur de nombreuses interfaces : formes communes, libellés, iconographie et placements conventionnels.
Certaines dispositions suggèrent fortement des composants spécifiques. Une bande horizontale en haut avec un logo à gauche et des textes à droite est probablement une barre de navigation. Une rangée d'éléments de même largeur dont un est mis en avant mappe souvent sur des onglets. Des boîtes répétées avec image, titre et texte court se lisent comme des cartes. Des grilles denses avec en-têtes alignés deviennent des tableaux.
Ces hypothèses changent la structure : un « onglet » implique un état sélectionné et une navigation clavier, tandis qu'une « rangée de boutons » peut ne pas l'exiger.
L'IA repère des indices d'interaction :
Elle assigne alors des comportements : clic, ouvrir un menu, naviguer, soumettre, étendre/reduire. Plus le design distingue éléments interactifs et statiques, plus la sortie est précise.
Si le design montre des variantes — hover, actif/selected, disabled, error, loading — l'IA peut les mapper à des composants avec états (par ex. disabled buttons, messages de validation, skeleton loaders). Quand les états ne sont pas explicites, elle les omet souvent.
L'ambiguïté est fréquente : une carte est-elle cliquable ou informative ? Une chevron est-elle décorative ou contrôle de disclosure ? Dans ces cas, clarifiez par le nommage, des annotations ou des frames séparées montrant l'interaction.
Une fois que l'IA a une lecture plausible du layout, l'étape suivante est de traduire « ce que ça ressemble » en « ce que c'est » : HTML sémantique, composants réutilisables et styles cohérents.
La plupart des outils mappent calques et groupes vers un arbre DOM : frames deviennent conteneurs, calques de texte deviennent titres/paragraphe, et éléments répétés deviennent des listes ou grilles.
Quand l'intention est claire, l'IA peut attacher une meilleure sémantique — par ex. un top bar devient un <header>, un logo et des liens deviennent une <nav>, une carte cliquable devient un <a> ou un <button>. Des rôles ARIA peuvent parfois être inférés (comme role='dialog' pour un modal), mais seulement si le motif est sans ambiguïté ; sinon la sortie la plus sûre est du HTML basique accompagné de TODOs pour la revue accessibilité.
Pour éviter de générer un seul fichier monolithique, l'IA tente de découper l'UI en primitives :
Les signaux courants pour un composant sont la répétition, un padding/typographie constants et une zone cliquable groupée. Les échecs habituels sont la sur-fragmention (trop de petits composants) ou la sous-fragmentation (tout en dur dans un seul composant).
Le générateur choisit souvent une approche selon le stack cible ou ses choix par défaut :
Une sortie de qualité s'appuie sur des design tokens — couleurs, espacements, radius, ombres — pour rester cohérente quand le design évolue. Une correspondance pixel par pixel produit souvent des valeurs ponctuelles (ex. gaps à 13px, gris presque identiques) qui rendent la maintenance difficile.
Un compromis pratique : préserver la hiérarchie et le rythme d'espacements, puis normaliser en tokens et composants réutilisables (refactoriser ensuite comme indiqué dans /blog/how-to-review-and-refactor-generated-ui-code).
Les fichiers de design sont souvent « finis » car dessinés à quelques tailles fixes (1440 et 375 par ex.). Le code ne peut pas l'assumer. Un outil design-to-code doit décider du comportement entre ces largeurs, en mélangeant indices et valeurs par défaut.
Si votre design inclut plusieurs versions d'un même écran (desktop/tablet/mobile) et que la structure est cohérente, l'IA peut les aligner et inférer où les règles changent. Sans variantes, elle revient à des breakpoints courants et traite la frame comme base, ce qui peut créer des sauts maladroits.
L'IA repère des patterns : cartes répétées dans une grille, espacements égaux et alignements. Elle peut décider qu'une grille 3 colonnes passe à 2 puis 1. Elle peine lorsque le design repose sur des ajustements manuels — éléments qui semblent alignés mais ne le sont pas réellement — car elle ne sait pas si c'était intentionnel.
La plupart des designs utilisent du texte court et propre. Les produits réels ne le font pas. Le code généré fixe souvent des largeurs/hauteurs ou tronque trop vite.
Un rapide test de sanity :
L'IA peut préserver le recadrage pixel-perfect du design, mais les UI responsives ont besoin de règles : conserver le ratio, décider comment recadrer ou quand réduire vs remplacer l'image. Sans indications, attendez-vous à un comportement de type « fill » qui peut couper des parties importantes.
Avant de valider la sortie, prévisualisez aux très petites et très grandes largeurs, et aux tailles intermédiaires. Si quelque chose chevauche, se coupe ou devient illisible, c'est souvent un manque d'intentions de layout — pas du « mauvais code » — et un signal pour clarifier les contraintes dans le design.
L'IA convertit les pixels en code UI de façon surprenante, mais l'accessibilité est un domaine où « avoir l'air juste » diverge souvent de « fonctionner pour tous ». Beaucoup d'exigences ne sont pas visibles sur une frame statique ; le modèle a besoin de signaux explicites.
Quelques choix favorables à l'accessibilité sont visibles et l'IA peut souvent les traduire :
D'autres exigences ne sont pas visibles :
Attendez-vous à des manques comme des associations label/for absentes, des niveaux de titres incorrects, des div cliquables sans support clavier, des styles de focus faibles et des icônes sans alternatives textuelles.
h1 → h2 → h3).header, nav, main, footer) et ne sont pas dupliqués.alt approprié (ou alt="" si décoratif).Ajoutez une spec courte lorsque vous avez des modals, drawers, formulaires complexes, selects personnalisés, drag-and-drop ou tout ce qui implique des états non triviaux. Même quelques notes comme « trap focus in modal », « Esc closes » et « announce inline errors » améliorent considérablement le code généré.
L'IA peut produire un code qui semble correct au premier coup d'œil, mais de petites erreurs d'interprétation s'accumulent vite. La plupart des problèmes viennent de « suppositions raisonnables » quand le design n'encode pas clairement les règles.
Un reproche fréquent : espacements décalés — boutons légèrement décalés, sections trop aérées ou cartes trop compactes. Cela arrive quand le padding est incohérent ou quand Auto Layout est mélangé à des nudges manuels. Le modèle peut imposer un pattern global (ex. « 16px partout ») ou conserver des exceptions accidentelles.
Le markup généré a souvent trop de wrappers. Chaque regroupement visuel inféré devient un div. Le résultat est plus difficile à styler, à déboguer et parfois plus lent à rendre. Vous le remarquerez quand une simple carte devient cinq conteneurs imbriqués uniquement pour aligner une icône et un titre.
L'IA peut fragmenter trop finement (chaque label devient un composant) ou être trop monolithique (tout l'écran dans un seul composant). La cause racine est l'absence de frontières claires : si les motifs répétés ne sont pas identiques, le modèle hésite à extraire un composant partagé.
La typographie « diverge » souvent parce que les styles de texte du design ne se mappent pas parfaitement au code. Subtilités d'interligne, chasse ou graisse se perdent, et les fallback de police changent les métriques. Ainsi un titre qui tenait dans Figma peut se recouper dans le navigateur.
Si hover, focus, error, loading ou empty ne sont pas représentés dans le design, l'IA les invente rarement. L'UI peut avoir l'air correcte statiquement mais échouer à l'interaction.
Les générateurs n'« voient » pas votre design comme un humain — ils lisent un fichier structuré plein de calques, contraintes, styles et instances de composants. Plus cette structure est propre, moins le modèle devine (et moins vous aurez de div soups à démêler).
Les noms de calques sont l'un des signaux les plus forts pour l'intention et le mapping de composants. Préférez des patterns descriptifs qui correspondent à votre façon de construire l'UI :
Button/Primary, Button/SecondaryCard/Product, Card/ArticleForm/Input/Text, Form/CheckboxÉvitez les « Rectangle 12 » ou « Group 5 » — cela pousse l'IA vers des wrappers génériques au lieu de composants réutilisables.
Le positionnement manuel se transforme souvent en coordonnées absolues dans le code. Si vous voulez du flex/grid en sortie, faites que votre design se comporte comme tel :
Quand le design réagit bien dans l'outil, le code généré sera plus responsive par défaut.
Des couleurs, tailles de police et espacements uniques encouragent du CSS one-off. Au lieu de cela :
Cela favorise la consistance et facilite la refactorisation vers un design system.
L'IA ne peut pas inférer ce qu'elle ne voit pas. Ajoutez des variantes clés comme hover/pressed/disabled, états d'erreur pour les inputs, états de chargement et écrans vides.
Quand le comportement compte, annotez brièvement : « opens modal », « server-validated », « shows toast on success ». Une ligne près d'un composant peut éviter un code d'interaction incorrect.
Si vous standardisez un workflow d'équipe, capturez ces conventions dans une checklist légère et liez-la en interne (ex. /blog/design-to-code-checklist).
Le code UI généré par l'IA est un premier jet : il peut faire gagner des heures, mais nécessite une passe humaine pour garantir le comportement, la maintenabilité et la conformité produit.
Commencez par lire le markup comme si vous étiez un lecteur d'écran.
h1, puis des h2/h3 logiques).ul/ol) et pas des div empilées.Si la sémantique est fausse, corriger le CSS ne résoudra pas l'accessibilité ni l'usabilité.
Beaucoup de générateurs reposent sur du positionnement absolu ou des wrappers profonds pour matcher la capture. Cela casse quand le contenu change.
Privilégiez les règles flex/grid plutôt que les coordonnées, et réduisez le nesting jusqu'à ce que chaque wrapper ait une raison claire d'exister (groupe, spacing, boundary de composant). Si vous voyez des patterns répétés de style={{ left, top, width, height }}, remettez cette zone en cause en priorité.
Repérez les motifs répétés (cartes, lignes de formulaire, items de nav) et transformez-les en composants réutilisables. Remplacez ensuite les valeurs hardcodées par des tokens : espacements, radius, typographie et couleurs. Si votre équipe a déjà des tokens, alignez-vous ; sinon, commencez par un set minimal et élargissez-le (voir /blog/design-tokens).
Pas besoin d'une suite de tests lourde pour tirer parti de la génération.
Les générateurs devinent des intentions. Consignez les modifications effectuées (règles d'interaction, breakpoints, décisions de mapping) pour que la prochaine génération ou le prochain développeur ne les annule pas.
L'IA « design to code » fonctionne mieux quand vous la traitez comme un accélérateur, pas un pilote automatique. Les équipes les plus rapides choisissent un workflow adapté à la maturité de leur design system et au risque de l'écran à construire.
1) Assistants IA dans les outils de design (plugins Figma) : idéal pour rester proche du fichier source. On obtient un scaffolding rapide pendant que les designers itèrent, et il est plus simple de garder noms, composants et tokens alignés.
2) Convertisseurs externes (upload/export → code) : utile pour une pipeline répétable sur de nombreux fichiers ou équipes. Plus rapide pour des conversions en masse, mais souvent il faut passer plus de temps à nettoyer la structure et relier les interactions.
En pratique, beaucoup d'équipes combinent design-to-code avec un flux plus large « spec → app livrée ». Par exemple, des plateformes comme Koder.ai étendent le principe : décrire une fonctionnalité en chat, générer des frontends React avec backends Go/PostgreSQL (et Flutter pour mobile), puis itérer avec mode planning, snapshots, rollback et export du code source pour intégration.
L'IA excelle pour :
Soyez prudent avec :
Traitez chaque génération comme un draft : relisez la sortie, notez les problèmes récurrents (naming, états manquants, sémantique incorrecte), puis améliorez votre prompt/spec et les conventions de design. En quelques itérations, la qualité s'améliore plus qu'on ne le pense.
Avant d'adopter, lancez un pilote et notez des scores sur : fidélité au layout, réutilisation des composants, responsivité, bases d'accessibilité et temps de refactor. Si vous comparez des outils, vérifiez aussi les plans et coûts sur /pricing.
C'est une traduction assistée par IA d'une interface visuelle (frame Figma, export de design ou capture d'écran) en code UI exécutable. L'objectif est d'obtenir un premier jet solide — structure, rythme de styles et agencement — qu'un développeur peut refactoriser en tokens, composants et sémantiques prêtes pour la production.
Elle traduit généralement :
Les pixels n'encodent pas tout. Il faut généralement fournir ou préciser :
Une capture d'écran est l'entrée la plus pauvre : couleurs et géométrie, mais pas de structure explicite (couches, contraintes, composants). Attendez-vous à plus de conjectures, plus de positionnements absolus et moins de réutilisabilité.
Un fichier Figma/Sketch ou un export structuré apporte des frames, des noms de calques, Auto Layout, contraintes et styles — des signaux qui produisent des layouts flex/grid plus propres et des frontières de composants plus exactes.
L'IA repère des alignements répétés et des écarts constants pour exprimer l'UI en règles flex/grid. Une cadence d'espacements claire (par ex. 8/16/24) permet de générer des stacks et des grilles stables.
Si l'espacement est incohérent ou si les éléments sont mal alignés, le modèle revient souvent à des coordonnées absolues pour préserver l'apparence exacte, au prix de la responsivité.
Elle cherche des signaux d'« enclosure » visuelle :
Une structure propre et l'utilisation d'Auto Layout aident beaucoup à reproduire les relations parent/enfant en code.
Le positionnement absolu apparaît quand les relations sont ambiguës — chevauchements, espacements incohérents, ou nudges manuels. Cette approche peut coller sur une taille d'écran mais casse quand :
Pour obtenir un rendu flexible, faites en sorte que le design se comporte comme du flex/grid via Auto Layout et contraintes.
L'IA infère la hiérarchie à partir d'indices visuels :
Quand les styles diffèrent de seulement 1–2px ou que les étapes hiérarchiques sont floues, elle peut choisir un mauvais niveau de titre ou considérer un titre comme du texte courant.
Elle devine l'interactivité par affordances :
Si une carte peut être cliquable ou informative, montrez un variant ou annotez-la ; sinon le modèle peut wiring une mauvaise action ou l'omettre.
Faites une passe structurée rapide :
Traitez la sortie comme un échafaudage, puis consignez vos choix pour éviter de les perdre lors d'une génération suivante.