Maquettage Figma : les erreurs qui bloquent les développeurs

Maquettage Figma: les erreurs qui bloquent les développeurs

Il est structurel.

Une maquette Figma mal préparée ne décrit pas une interface exploitable. Elle montre une apparence à reproduire. Le développeur doit alors reconstruire la logique absente: comportement des blocs, adaptation au contenu, hiérarchie sémantique, règles responsives, états interactifs et correspondance avec le système de composants. Le transfert de Figma au développeur devient une opération d’interprétation. C’est là que la dette technique commence.

Le maquettage Figma destiné au développement web doit produire autre chose qu’une image fidèle d’un écran. Il doit transmettre un modèle d’interface suffisamment explicite pour être transformé en code propre, accessible et maintenable.

Le coût réel d’une maquette conçue uniquement pour être montrée

Une maquette peut être convaincante en revue de direction et inutilisable en intégration. Ces deux qualités ne se recouvrent pas.

Le design regarde principalement la composition finale: alignement, contraste, rythme visuel, densité, hiérarchie. Le développement doit traiter le système qui produit cette composition. Il doit savoir ce qui se passe lorsque le titre contient deux lignes au lieu d’une, lorsqu’un bouton reçoit un libellé plus long, lorsqu’une carte disparaît sur mobile ou lorsqu’un message d’erreur s’ajoute à un formulaire.

Une image fixe masque ces contraintes. Le navigateur, lui, ne les masque pas.

Les frictions apparaissent généralement à cinq endroits:

• les blocs sont positionnés visuellement, sans logique de flux exploitable;
• les composants ne sont pas reliés à un système de variables ou de styles cohérent;
• les calques portent des noms génériques qui ne donnent aucun contexte;
• les états absents de la maquette sont reconstruits au dernier moment;
• la hiérarchie visuelle ne correspond pas à une hiérarchie HTML correcte.

La conséquence directe est une reconstruction côté front-end. Le développeur ne traduit plus une décision de conception. Il prend une série de décisions qui auraient dû être prises avant l’intégration.

Une maquette prête pour le développement ne décrit pas seulement ce que l’utilisateur voit. Elle décrit ce que l’interface doit faire quand les conditions changent.

L’audit Synqro fournit un ordre de grandeur utile, mais il ne faut pas l’étendre à l’ensemble du marché. Les 70 % et les un à cinq jours supplémentaires concernent le périmètre de cet audit. Ils suffisent néanmoins à établir le mécanisme: une erreur répétée dans chaque écran devient rapidement un poste de coût significatif.

Le calcul est mécanique

Supposons qu’un projet contienne plusieurs gabarits, des composants partagés et des déclinaisons mobiles. Une erreur de structure appliquée à un bouton, une carte ou une barre de navigation ne coûte pas une seule correction. Elle se répète dans chaque instance, puis se propage aux variantes.

Le coût ne se limite pas au temps de développement:

• le développeur interrompt son flux pour demander une précision;
• le designer doit répondre à des questions qui auraient pu être traitées dans le fichier;
• les décisions prises oralement ne sont pas toujours documentées;
• les corrections visuelles arrivent après l’implémentation;
• les écarts entre maquette et interface augmentent à chaque aller-retour;
• les tests d’accessibilité et de responsive sont repoussés vers la fin.

Ce fonctionnement produit une illusion de vitesse au début du projet. Les écrans semblent avancer rapidement. Le ralentissement apparaît ensuite, au moment où chaque exception doit être corrigée dans le code.

Le bon indicateur n’est pas le nombre d’écrans maquettés. C’est le nombre de décisions que le développeur doit encore prendre pour rendre ces écrans fonctionnels.

Auto Layout: remplacer le positionnement visuel par une logique de flux

L’absence d’Auto Layout est l’une des erreurs les plus coûteuses dans un maquettage Figma destiné à l’intégration web. Un groupe de calques peut ressembler à une structure flexible. Il ne l’est pas nécessairement.

Dans Figma, Auto Layout permet d’organiser les éléments selon un flux vertical, horizontal ou en grille. Le rapprochement avec CSS est direct: les flux horizontal et vertical correspondent à une logique comparable à celle de Flexbox. Il ne s’agit pas d’une génération automatique de code. Il s’agit d’un moyen de concevoir une structure qui tient compte des relations entre les éléments.

Un bloc correctement configuré doit expliciter plusieurs comportements:

• la direction du flux;
• l’espacement entre les éléments;
• les marges internes;
• l’alignement sur l’axe principal et l’axe secondaire;
• la capacité d’un élément à s’étendre ou à conserver sa largeur;
• le retour à la ligne lorsque la largeur disponible diminue;
• le comportement du conteneur lorsque le contenu change.

Les trois options de flux disponibles dans Auto Layout — vertical, horizontal et grille — ne couvrent pas tous les besoins d’une interface. Elles imposent toutefois une discipline utile: penser en relations, et non en coordonnées.

Groupe simple contre frame avec Auto Layout

Un groupe simple conserve une relation graphique. Il ne formalise pas un comportement. Si un titre s’allonge, si une icône change de taille ou si un bouton reçoit un libellé différent, les éléments voisins ne se repositionnent pas nécessairement de manière cohérente.

Une frame configurée avec Auto Layout établit au contraire une règle de composition. Le contenu influence la taille du conteneur. Le conteneur influence la position des éléments suivants. Cette logique est beaucoup plus proche du fonctionnement d’une page web.

Cette comparaison ne signifie pas qu’Auto Layout produit du CSS prêt pour la production. Figma ne remplace ni l’architecture front-end ni les tests dans un navigateur réel. L’outil réduit cependant l’ambiguïté lorsque le fichier est préparé avec cohérence.

Paramétrer les dimensions sans fabriquer un écran rigide

Le positionnement absolu peut être pertinent pour certains éléments: illustration superposée, badge, icône dans un champ, élément décoratif ou composition volontairement fixe. Il devient problématique lorsqu’il sert à construire toute l’interface.

Une page web doit absorber des contenus variables. Les titres peuvent être plus longs. Les traductions peuvent augmenter la longueur des libellés. Les navigateurs peuvent afficher une police différente. Les utilisateurs peuvent augmenter la taille du texte. Les écrans mobiles réduisent la largeur disponible.

Un fichier exploitable doit donc distinguer:

• les dimensions intrinsèques du contenu;
• les contraintes minimales et maximales;
• les espacements constants;
• les zones qui s’étendent;
• les zones qui se contractent;
• les ruptures de composition entre ordinateur et mobile.

La question à poser n’est pas seulement: quelle largeur fait ce bouton dans la maquette? Il faut demander: que doit-il se passer lorsque son contenu double de longueur?

Cette question révèle immédiatement les fichiers préparés comme des captures d’écran.

Le cas particulier de Clip Content

L’option Clip Content doit également être utilisée avec intention. Elle correspond à une logique comparable à la propriété CSS overflow. Elle détermine si le contenu qui dépasse les limites d’une frame reste visible ou est masqué.

Un masquage accidentel peut produire plusieurs défauts:

• une partie d’un texte disparaît dans certaines tailles;
• un état de focus devient invisible;
• une erreur de formulaire est coupée;
• une image est tronquée sans règle claire;
• un composant semble correct dans Figma mais échoue avec un contenu réel.

Le développeur devra alors décider si le masquage était intentionnel. Une option graphique non documentée devient une règle de rendu implicite. Elle doit être traitée comme telle.

Sémantique et nommage: le coût des calques illisibles

Un calque nommé « Rectangle 89 » ne transmet aucune information utile. Il indique seulement que Figma a généré un nom par défaut. À l’inverse, un nom comme Carte-produit, Titre-section, Bouton-principal ou Message-erreur fournit un contexte immédiat.

Le nommage ne sert pas uniquement à faciliter la navigation du designer. Il crée une couche de communication entre le fichier, les discussions de projet et l’implémentation. Lorsque le développeur inspecte une maquette, il doit pouvoir identifier les rôles sans ouvrir chaque groupe ni comparer visuellement plusieurs variantes.

Un nom explicite permet de répondre plus vite à des questions concrètes:

• ce bloc est-il un composant réutilisable ou une exception?
• cette icône accompagne-t-elle un texte ou porte-t-elle seule une information?
• ce bouton possède-t-il un état désactivé?
• ce groupe correspond-il à une carte, une ligne de tableau ou un simple conteneur visuel?
• cette zone est-elle obligatoire, optionnelle ou conditionnelle?

Le nommage doit rester stable entre les écrans. Si le même composant s’appelle Card, Bloc, Tuile et Rectangle produit selon les pages, le système perd sa cohérence. La nomenclature devient une nouvelle source de traduction.

Relier les calques à la sémantique HTML

La sémantique visuelle et la sémantique HTML ne sont pas identiques. Une grande taille de texte peut signaler un titre sans garantir l’usage d’un élément de titre. Une forme colorée peut ressembler à un bouton sans préciser s’il s’agit d’un lien, d’un contrôle ou d’un élément décoratif.

Le fichier Figma ne peut pas imposer à lui seul la structure HTML finale. Il doit néanmoins éviter de la contredire.

Pour chaque bloc, l’équipe doit pouvoir déterminer son rôle fonctionnel:

• navigation principale;
• titre de niveau approprié;
• contenu éditorial;
• liste d’éléments;
• formulaire;
• champ avec libellé et message d’erreur;
• bouton d’action;
• lien vers une autre ressource;
• élément purement décoratif.

Cette clarification est déterminante pour l’accessibilité numérique. Une interface qui se contente de reproduire la hiérarchie visuelle sans organiser la hiérarchie fonctionnelle peut obtenir un rendu conforme à la maquette tout en restant difficile à utiliser avec un lecteur d’écran ou au clavier.

Les variantes ne sont pas des copies colorées

Un composant bien défini ne se limite pas à une apparence principale. Il doit intégrer ses états et ses contraintes:

• repos;
• survol lorsque ce comportement existe;
• focus clavier;
• pression;
• désactivation;
• chargement;
• erreur;
• succès;
• contenu vide;
• contenu trop long.

Tous ces états ne doivent pas nécessairement apparaître dans chaque écran. Ils doivent être définis au niveau du composant lorsqu’ils ont un impact sur l’intégration.

Le défaut classique consiste à fournir uniquement l’état idéal. Le développeur découvre alors les états réels pendant l’implémentation. Il crée des variantes locales, parfois incompatibles avec le design system. La dette de composants augmente et les corrections deviennent plus difficiles à propager.

Design system: ne pas maquiller chaque écran comme un projet indépendant

Un design system utile n’est pas une bibliothèque de rectangles colorés. C’est un ensemble de règles réutilisables qui réduit les décisions répétées.

Dans Figma, cette logique passe par les composants, les variantes, les styles et les variables. La structure doit permettre de distinguer:

• les fondations: couleurs, typographies, espacements, rayons, ombres;
• les composants élémentaires: boutons, champs, icônes, étiquettes;
• les composants composés: cartes, menus, panneaux, formulaires;
• les gabarits: page de recherche, détail produit, tableau, tunnel de conversion;
• les exceptions documentées.

Sans cette séparation, chaque écran dérive légèrement. Un même bouton change de hauteur, une marge varie de quelques pixels, une couleur est recréée manuellement et une typographie secondaire apparaît sans justification. Ces écarts sont peu visibles dans une revue isolée. Ils deviennent coûteux dès que le produit compte plusieurs parcours.

La logique coût/bénéfice est simple:

• créer une fondation demande un effort initial;
• la réutiliser réduit les corrections sur chaque écran;
• documenter une exception coûte moins cher que de la laisser se propager;
• maintenir un composant centralisé évite des corrections divergentes dans le code.

La cohérence doit survivre au passage dans le navigateur

Une variable Figma n’est pas automatiquement une variable CSS. Un composant Figma n’est pas automatiquement un composant React ou Vue. La correspondance doit être définie par l’équipe.

Le transfert de Figma au développeur devient fiable lorsque les deux environnements partagent une nomenclature et des décisions compatibles. Par exemple, les couleurs peuvent suivre une distinction entre rôles fonctionnels et valeurs brutes: couleur de fond, couleur de texte principal, couleur d’action, couleur d’erreur. Cette approche facilite les changements de thème et évite de diffuser des valeurs isolées.

Même logique pour les espacements. Une interface construite avec une échelle implicite produit des écarts difficiles à expliquer. Une échelle documentée permet de repérer rapidement les valeurs exceptionnelles et d’éviter que chaque écran invente sa propre mesure.

Les limites de l’automatisation: Figma vers le code, sans promesse artificielle

Les outils d’export peuvent réduire certaines tâches répétitives. Des solutions comme Zeplin, Anima ou Avocode peuvent exporter des extraits HTML, CSS, React ou Vue.js et faciliter l’inspection des propriétés.

Leur utilité est réelle, mais limitée. Un extrait de code n’est pas une architecture. Il ne décide pas correctement:

• où placer la logique métier;
• comment gérer les données absentes ou lentes;
• quelle sémantique HTML utiliser;
• comment organiser les états;
• comment réduire le poids des ressources;
• comment garantir la navigation au clavier;
• comment maintenir les composants sur plusieurs versions du produit.

L’export peut donc servir de support de transition, pas de substitut à l’intégration. Un code produit automatiquement doit être relu, simplifié et confronté aux contraintes du projet. Sans cette étape, l’équipe risque d’importer une structure verbeuse, des styles redondants et des comportements rigides.

Automatiser l’extraction d’un style ne résout pas l’absence de décision architecturale.

Le cas Figma Sites

Lancé le 7 mai 2025 lors de la conférence Config 2025, Figma Sites illustre cette tension entre rapidité de publication et exigences de production. L’outil a fait l’objet de critiques concernant la structure HTML non sémantique, le respect des règles WCAG et les performances liées au référencement naturel.

Le point n’est pas de déclarer l’outil inutilisable. Il faut distinguer le contexte de mise en ligne.

Pour une page de démonstration interne ou un prototype public temporaire, un outil de publication intégré peut réduire le délai entre l’idée et l’exposition. Pour un site d’entreprise durable, il faut évaluer la structure générée, la maîtrise des métadonnées, la performance, la capacité d’évolution et la conformité aux exigences d’accessibilité.

Un outil qui accélère la première mise en ligne peut augmenter le coût des corrections futures si son socle ne permet pas de contrôler proprement le HTML, les scripts, les ressources et les composants.

Évaluer l’outil sur le résultat, pas sur la promesse

Avant d’intégrer un flux automatisé dans un projet professionnel, il faut produire une page représentative et l’examiner sur plusieurs axes:

• structure des titres et des zones de navigation;
• ordre de lecture au clavier et avec un lecteur d’écran;
• poids des images et des scripts;
• comportement sur mobile;
• gestion des états d’erreur;
• possibilité de modifier le contenu sans casser la mise en page;
• maîtrise du code ou des sorties générées;
• capacité à intégrer des mesures de performance.

Un export qui reproduit correctement la capture d’écran mais échoue sur ces points ne réduit pas le risque. Il le déplace vers la phase de correction.

Organiser le transfert design-to-dev sans multiplier les réunions

Le transfert de la maquette au développeur ne doit pas être un événement unique à la fin de la conception. Cette méthode concentre les ambiguïtés au moment où le code est déjà engagé.

Une collaboration plus robuste suit un ordre de contrôle progressif.

1. Valider la structure avant le détail visuel

Commencer par les parcours, les zones fonctionnelles et les contraintes de contenu. Les détails de couleur et d’ombre ne doivent pas précéder la validation de la hiérarchie.

Cette étape permet de repérer les problèmes d’architecture de l’information: navigation trop profonde, action principale mal placée, formulaire fragmenté ou contenu essentiel relégué dans un panneau difficile d’accès.

2. Construire les composants avant les pages finales

Créer les composants réutilisables et leurs variantes. Tester leur comportement avec du contenu court et long. Vérifier les états d’erreur, de chargement et de désactivation.

Une carte qui fonctionne uniquement avec le titre prévu dans la maquette n’est pas un composant. C’est une composition figée.

3. Préparer les contraintes responsives

Décrire ce qui change entre les largeurs d’écran. Ne pas transmettre uniquement une version ordinateur et une version mobile en laissant le développeur déduire l’interpolation.

Il faut préciser:

• les éléments qui disparaissent;
• ceux qui changent d’ordre;
• ceux qui passent sur plusieurs lignes;
• les zones qui deviennent défilantes;
• les composants qui changent de variante;
• les seuils à partir desquels la composition est modifiée.

Le navigateur ne connaît pas les deux tailles choisies dans Figma. Il doit gérer toutes les largeurs intermédiaires.

4. Relier chaque décision à une règle vérifiable

Une annotation utile explique un comportement. Elle ne répète pas ce que l’écran montre.

Préciser qu’un panneau reste ouvert après sélection, qu’un champ affiche son erreur sous le libellé, qu’une image est décorative ou qu’un bouton devient indisponible pendant l’envoi produit une information exploitable. Ajouter une note vague sur l’intention générale ne produit aucune règle d’implémentation.

5. Contrôler une page dans le navigateur avant de généraliser

L’intégration d’un premier écran doit servir de test du système. Si le développeur doit recréer les espacements, renommer les composants et corriger les contraintes dès la première page, le problème se trouve dans le fichier source.

Corriger la maquette et les composants à ce stade coûte moins cher que de laisser l’écart se répandre sur toutes les pages.

Une procédure de contrôle avant remise au développement

La liste suivante ne remplace pas une revue technique. Elle fournit un seuil minimal pour un fichier destiné à l’intégration web.

• Structurer les frames. Utiliser des frames pour les conteneurs fonctionnels. Réserver les groupes simples aux relations graphiques qui ne nécessitent pas d’adaptation.
• Configurer Auto Layout. Définir le flux, les espacements, les marges internes et les règles d’extension. Tester la réaction à un contenu plus long.
• Nommer les calques. Remplacer les noms par défaut par des rôles compréhensibles et cohérents entre les écrans.
• Centraliser les fondations. Utiliser des styles ou des variables pour les couleurs, les textes et les dimensions répétées.
• Déclarer les variantes. Inclure les états qui ont un impact fonctionnel: focus, erreur, chargement, désactivation et contenu vide.
• Vérifier les deux axes. Tester le comportement horizontal et vertical. Une maquette qui tient sur une largeur fixe ne suffit pas.
• Contrôler le masquage. Vérifier chaque usage de Clip Content. Confirmer qu’aucun texte, focus ou message d’erreur n’est coupé par inadvertance.
• Indiquer la sémantique attendue. Identifier les titres, les listes, les boutons, les liens, les formulaires et les zones de navigation.
• Tester l’accessibilité en amont. Vérifier le contraste, la visibilité du focus, la taille des zones interactives et la cohérence de l’ordre de lecture.
• Documenter les exceptions. Une valeur ou une composition unique doit avoir une raison identifiable. Sinon, elle deviendra probablement une incohérence.
• Prévoir des contenus réalistes. Utiliser des titres longs, des messages d’erreur complets, des noms de produits variables et des traductions potentiellement plus étendues.
• Faire relire le fichier par un développeur. Pas pour valider le goût visuel. Pour révéler les comportements qui restent implicites.

La question finale est simple: le développeur peut-il intégrer l’écran sans demander quelle règle s’applique dès que le contenu, la largeur ou l’état change?

Si la réponse est non, le maquettage Figma n’est pas terminé. Il est seulement visuellement avancé.

Conclusion: préparer le code avant de le produire

Les erreurs de maquettage Figma qui ralentissent le développement ne sont pas des détails de rangement. Elles révèlent une rupture entre conception et exécution.

Un fichier fondé sur des groupes, des coordonnées fixes, des calques anonymes et des états incomplets oblige le front-end à reconstruire l’interface. Auto Layout, les frames, le nommage explicite, les composants et les variantes ne garantissent pas à eux seuls une intégration correcte. Ils réduisent cependant le volume de décisions implicites et rendent les compromis visibles avant la mise en production.

La méthode la plus rentable consiste à traiter la maquette comme un artefact technique:

1. modéliser les relations avant les pixels;

2. tester les composants avec des contenus variables;

3. définir les états qui modifient le comportement;

4. relier la hiérarchie visuelle à une structure sémantique;

5. confronter rapidement le fichier à un navigateur réel;

6. corriger les règles à la source plutôt que multiplier les exceptions dans le code.

Le transfert de Figma au développeur devient alors une transmission de contraintes, pas une remise de captures d’écran. C’est cette différence qui sépare une interface simplement reproduite d’un produit web maintenable, accessible et capable de supporter sa propre évolution.