Le trajet figma to webflow ressemble à une promesse simple : la maquette existe, elle est validée, il ne reste qu’à la rendre vivante. La réalité du terrain est plus rugueuse. Une maquette est une image figée à trois largeurs d’écran, un site est un système fluide qui doit se comporter correctement à toutes les largeurs, avec des textes de longueurs variables et des images de proportions imprévisibles. Le passage de l’un à l’autre n’est pas une conversion, c’est une traduction. Les projets qui se déroulent bien sont ceux où la maquette a été pensée dès le départ pour être traduite, et où la construction suit une séquence stable plutôt qu’une improvisation section par section.
Pourquoi le passage coince presque toujours
La première source de friction tient à la nature même des deux environnements. Dans l’outil de maquettage, un élément se place où l’on veut, avec une position absolue et des dimensions fixes. Dans le navigateur, un élément appartient à un flux : il pousse ses voisins, se redimensionne selon son contenu et réagit à la largeur disponible. Une maquette construite sans tenir compte de ce flux produit des sections qui se déforment dès que le texte réel remplace le faux texte.
La deuxième source de friction concerne les états. Une maquette montre un bouton au repos, éventuellement au survol. Un site doit gérer le repos, le survol, le focus au clavier, l’état actif, l’état désactivé et parfois l’état chargé. Ces états manquants se décident dans l’urgence pendant la construction, avec des choix rarement cohérents d’un composant à l’autre.
La troisième tient au contenu variable. Un titre de trois mots dans la maquette devient un titre de douze mots dans le site réel. Une carte de réalisation dessinée avec une image en format paysage reçoit une image en portrait. Ces variations, invisibles au moment de la validation, cassent la mise en page si les composants n’ont pas été conçus pour les absorber. Le sujet devient critique dès que les contenus proviennent de collections, dont la logique est décrite dans notre article sur le fonctionnement des collections.
Préparer une maquette réellement convertible
Poser un système avant de dessiner
Une maquette convertible commence par un système de tokens : échelle typographique limitée à cinq ou six tailles, palette réduite avec des rôles explicites, échelle d’espacement fondée sur un multiple unique, rayons d’angle et ombres normalisés. Ce socle se déclare une fois dans les variables et les styles du fichier, puis se réutilise partout. Il correspond directement aux classes globales qui seront créées dans l’outil de construction, ce qui transforme la traduction en simple correspondance.
L’erreur symétrique consiste à dessiner d’abord et à normaliser ensuite. Une maquette qui contient dix-sept tailles de texte et vingt-trois valeurs d’espacement se traduit en un empilement de styles ponctuels, impossible à maintenir. Le nettoyage rétroactif prend plus de temps que la discipline initiale.
Construire en agencement automatique
Toutes les sections doivent être bâties avec l’agencement automatique, l’équivalent conceptuel du mode boîte flexible utilisé dans le navigateur. Un cadre qui empile ses enfants verticalement avec un espacement défini se traduit littéralement. Un cadre où les éléments flottent en position libre demande une reconstruction complète et laisse la porte ouverte aux interprétations.
Le remplissage interne, l’alignement et le comportement de redimensionnement se paramètrent élément par élément. Ce travail paraît fastidieux, mais il constitue la documentation la plus fiable de l’intention du concepteur : le constructeur n’a plus à deviner si une carte doit s’étirer ou conserver sa largeur.
Nommer et composer
Le nommage des calques est la partie que tout le monde saute et que tout le monde regrette. Des noms explicites, en cohérence avec le vocabulaire du projet, permettent de retrouver un élément et de comprendre une structure sans la parcourir entièrement. Les composants et leurs variantes servent quant à eux à déclarer une fois pour toutes les états d’un bouton, d’une carte ou d’un champ de formulaire.
Un dernier élément fait gagner un temps considérable : livrer chaque section dans deux ou trois largeurs, avec le cas du texte long et le cas du texte court. Cette maquette de robustesse vaut mieux que dix commentaires expliquant ce qui devrait se produire.
Outils de conversion : ce qu’on peut en attendre
Plusieurs solutions promettent d’automatiser le passage. Leur maturité a progressé, et la plateforme propose désormais des mécanismes de reprise depuis les maquettes. Leur utilité réelle dépend de la qualité de préparation du fichier source et du type de projet.
| Approche | Ce qu’elle fait bien | Ce qu’elle ne fait pas |
|---|---|---|
| Reprise assistée depuis la maquette | structure de base, styles simples | logique responsive fine, états |
| Extension de conversion tierce | gain de temps sur les sections statiques | classes propres, nommage exploitable |
| Bibliothèque de composants prêts | démarrage rapide, cohérence | fidélité à une maquette sur mesure |
| Construction manuelle guidée | contrôle total, code structuré | rapidité sur les projets simples |
| Copie d’éléments entre projets | réutilisation de blocs validés | adaptation au nouveau système de styles |
Un point mérite d’être posé clairement, parce qu’il alimente beaucoup de déceptions. Aucun outil de conversion ne devine une intention. Il transpose ce qu’il voit : une position, une taille, une couleur. Tout ce qui relève de la décision, quel élément doit s’étirer, lequel doit rester fixe, quelle section devient une liste dynamique, quel bloc disparaît sur mobile, reste à la charge de la personne qui construit. Une conversion produit donc au mieux un point de départ correct, jamais un site livrable. La juger sur ce critère évite d’acheter une promesse qui n’a jamais été tenue par quiconque.
Le second point concerne la propreté du résultat. Les conversions automatiques génèrent fréquemment des classes au nommage arbitraire, des empilements de conteneurs superflus et des styles ponctuels répétés à l’identique. Un site construit ainsi fonctionne le jour de la livraison et devient pénible à faire évoluer six mois plus tard, quand personne ne comprend plus quelle classe agit sur quoi. Le temps théoriquement gagné se retrouve intégralement dans la première évolution un peu ambitieuse.
L’expérience courante donne un ordre de grandeur : sur un site vitrine soigné, une conversion automatique fait gagner du temps sur la mise en place initiale, puis en fait perdre autant en reprise des classes et du comportement responsive. Sur des pages très structurées et répétitives, le gain devient réel. La décision se prend projet par projet, en fonction de la fidélité attendue et de la durée de vie du site.
La construction manuelle, étape par étape
La séquence qui donne les meilleurs résultats commence par le socle et finit par le détail. Première étape : créer les classes globales correspondant aux tokens, typographies, couleurs, espacements, conteneurs. Deuxième étape : construire les éléments d’interface récurrents, boutons, champs, cartes, sous forme de composants réutilisables. Troisième étape : bâtir la page la plus complexe du site, généralement l’accueil, en travaillant section par section et en validant chaque section sur toutes les largeurs avant de passer à la suivante.
Quatrième étape : décliner les autres pages en réutilisant les composants existants, ce qui doit aller vite si les trois premières étapes ont été menées correctement. Cinquième étape : brancher le contenu dynamique et vérifier le comportement avec des données réelles, y compris les cas extrêmes de longueur et de format. Sixième étape : ajouter les animations, en dernier, parce qu’elles compliquent le diagnostic de tout problème de mise en page.
La revue de section mérite d’être formalisée dès la troisième étape. Concrètement, une section n’est déclarée terminée qu’après quatre contrôles : rendu correct sur les quatre largeurs de référence, comportement avec un texte deux fois plus long, comportement avec une image de proportion inattendue, et absence de défilement horizontal parasite. Cette discipline paraît lente sur les deux premières sections et devient un accélérateur ensuite, parce qu’elle empêche la propagation d’une erreur de structure à toutes les pages du site.
Deux principes de méthode évitent la majorité des difficultés. Construire du plus large au plus étroit, en partant du bureau puis en corrigeant les largeurs inférieures, correspond à la logique de cascade de l’outil : un style posé sur la largeur principale se propage vers le bas, l’inverse n’est pas vrai. Utiliser du contenu réel dès la deuxième section, plutôt que du faux texte, révèle immédiatement les faiblesses de la maquette et évite de découvrir les problèmes à la livraison.
Points de contrôle avant de livrer
La relecture finale gagne à être menée avec une grille écrite plutôt qu’à l’intuition. Six vérifications couvrent l’essentiel. Le rendu sur les largeurs intermédiaires, entre la tablette et le bureau, zone où les maquettes ne disent rien et où les mises en page se cassent le plus souvent. La navigation entièrement au clavier, avec un contour de focus visible sur chaque élément interactif. Le contraste des textes sur leurs fonds réels, y compris sur les images. Le poids et le format des médias, sujet qui pèse directement sur le confort perçu. La hiérarchie des titres, qui doit suivre une progression logique et non être choisie pour sa taille. Les états manquants enfin, sur tous les composants interactifs.
Ces contrôles recoupent largement les principes de conception détaillés dans nos astuces pour améliorer un site. Ils supposent une aisance minimale avec l’outil de construction, que les différents formats d’apprentissage abordent avec une profondeur variable, sujet passé en revue dans notre panorama des parcours de formation.
Un dernier conseil de méthode, souvent négligé : archiver la maquette dans l’état exact qui a servi de référence à la construction, et poursuivre les évolutions sur une copie. Les projets où la maquette continue de bouger pendant la construction produisent des divergences invisibles, des discussions stériles sur ce qui avait été validé, et une dette de cohérence qui se paye à chaque évolution ultérieure du site.