UnHTML contre une capture d'écran calquée : ce que vous obtenez vraiment

Ce que "capture d'écran plus calque" veut vraiment dire

"La calquer" veut en général dire une de deux choses dans Figma : la fonction intégrée Vectorize, ou un plugin de calque communautaire. Les deux partent du même endroit, une image aplatie. Les deux produisent le même type de résultat : de la géométrie vectorielle.

La fonction Vectorize de Figma transforme une image statique en calques vectoriels éditables, mais sa documentation la présente autour de symboles dessinés à la main, de lettrage et d'illustrations, pas de captures d'interfaces. Vous sélectionnez une image, ouvrez More dans la barre d'outils secondaire, et choisissez Vectorize. Nulle part dans la propre description de Figma il n'est question de calques de texte ou d'auto layout en sortie. L'avertissement est explicite : les images complexes ou en basse résolution peuvent mal se vectoriser. Une capture d'une page web chargée en texte se rapproche du pire cas que décrit cet avertissement.

Des plugins communautaires comme Image Tracer font le même travail avec une interface différente : on entre un bitmap, on récupère des tracés vectoriels redimensionnables. Ces outils travaillent uniquement à partir de données de pixels. Ils n'ont aucune notion du DOM d'origine de la page, de son CSS, ni de quels pixels formaient un paragraphe de texte par rapport à une icône décorative. Un titre et une ombre portée deviennent tous deux de la géométrie calquée, et ni l'un ni l'autre n'est du texte que vous pouvez sélectionner, éditer ou reformater.

Ce qu'ajoutent les outils IA de capture d'écran

Une catégorie plus récente se situe entre le simple calque et un véritable import : les plugins de conception assistés par IA à partir de captures d'écran. image.to.design, par exemple, prend une capture d'écran et la fait passer par un modèle qui extrait le texte, nomme les calques de façon plus utile que "Rectangle 17", applique des groupes d'auto layout et tente d'identifier des composants comme les boutons, les barres de navigation et les cartes.

C'est une vraie avancée par rapport à un plugin de calque, et il faut le reconnaître honnêtement : pour une maquette rapide de l'interface de quelqu'un d'autre, ou une référence que vous comptez redessiner à la main de toute façon, cette structure déduite peut faire gagner un vrai temps. Mais l'outil continue de travailler à partir d'une image aplatie de la page, assemblée après que chaque valeur CSS ayant produit cette image a déjà disparu. L'outil reconstruit l'espacement, la couleur et la mise en page à partir de pixels et d'une estimation entraînée, pas à partir des valeurs que le navigateur a réellement utilisées. La description de div.RIOTS le dit elle-même : les designs complexes ou inhabituels peuvent nécessiter un nettoyage manuel.

L'extraction de texte en particulier n'est toujours pas une chose que Figma fait nativement. Une demande de fonctionnalité de longue date sur le forum de Figma réclamant un OCR intégré traîne depuis avril 2024, avec une réponse qui se résume à "on fait remonter ça à l'équipe". L'activité la plus récente renvoie toujours vers des plugins tiers. Vous voulez extraire du texte d'une capture d'écran dans Figma aujourd'hui ? Vous dépendez de la capacité d'un modèle de plugin à bien deviner, pas d'une fonctionnalité intégrée.

Cette estimation peut se tromper de façons qui comptent. L'OCR lit l'apparence des pixels, pas ce que dit le balisage, et ne peut donc pas vous dire qu'un titre était en réalité un <h2> dans un conteneur flex avec un gap de 24px, ou qu'un prix était une valeur en direct tirée d'un modèle plutôt qu'un texte statique. Le fichier Figma reconstruit peut sembler correct au premier regard, et pour une maquette ponctuelle, c'est souvent suffisant. Mais chaque chiffre qu'il affiche, espacement, rayon d'angle, hauteur de ligne, est une estimation à laquelle le modèle est arrivé en regardant une image, pas une valeur qu'il a lue sur la page.

Ce qu'UnHTML capture à la place

UnHTML saute complètement l'étape de la capture d'écran. Il lit le DOM et le CSS en direct de la page et construit des frames, du texte, des images, des vecteurs et de l'auto layout directement à partir de ce que le navigateur a réellement rendu. Le texte arrive en tant que texte, parce que c'était du texte sur la page. L'auto layout vient des vraies règles flexbox et grid de la page, pas de la supposition d'un modèle sur l'emplacement probable des espaces.

Le plugin gratuit importe jusqu'à 500 calques par page, en positionnement absolu. Pro supprime cette limite et ajoute la conversion en auto layout, pour 39 $ en paiement unique par éditeur. Studio étend une licence Pro à cinq éditeurs pour 119 $ en paiement unique. Par défaut, l'import ne fait aucune requête réseau, rien ne quitte votre machine, et la récupération de ressources distantes est une option explicite qu'il faut activer soi-même.

Où UnHTML recourt encore à un repli

Rien de tout cela ne rend l'import exact au pixel près, et il ne prétend pas l'être. Si une police utilisée sur la page n'est pas installée localement, UnHTML la remplace, Inter par défaut, et consigne chaque remplacement dans le rapport d'import pour que vous sachiez exactement ce qui a changé. Si la mise en page d'une section est trop complexe pour être reproduite en auto layout propre, elle bascule d'elle-même en positionnement absolu plutôt que de forcer une structure cassée. Les limites de fidélité sont l'échange honnête pour travailler à partir de la structure réelle de la page plutôt que d'une image de celle-ci. Voir comment les polices manquantes sont remplacées et consignées pour le détail de cet échange côté polices.

Ce qui compte, c'est ce que le repli préserve par rapport au nettoyage manuel d'un outil de capture d'écran. Quand UnHTML bascule en positionnement absolu, le texte reste du vrai texte, les couleurs restent les vraies valeurs CSS de la page, et le rapport d'import vous dit exactement quel frame a basculé et pourquoi. Le nettoyage d'un outil de capture d'écran, lui, est manuel : c'est vous qui devez remarquer que le padding d'un bouton semble faux et le corriger à l'œil, parce qu'il n'y a jamais eu de valeur CSS derrière à lire en premier lieu.

Choisir le bon outil pour la tâche

Les deux approches ne sont pas vraiment en concurrence pour le même travail. Vectorize et les plugins de calque conviennent à de l'art de référence statique : une image de moodboard, une capture annotée d'un concurrent, de l'art que vous n'avez jamais l'intention de reconstruire fonctionnellement. Les outils IA de capture d'écran vont un cran plus loin, utiles pour une maquette rapide quand le résultat n'a pas besoin de correspondre au vrai CSS de la source.

Une structure éditable que vous avez réellement l'intention de redessiner ou de reconstruire est un travail différent, et c'est celui pour lequel UnHTML et les autres outils qui lisent la structure sont construits. La distinction devient plus nette dès qu'on compare des outils précis : voir dans quel sens la conversion s'effectue vraiment pour comment cela se joue face à Anima, et design vers code et web vers design ne sont pas le même travail pour comprendre pourquoi un outil construit pour aller du design vers le code ne fonctionne pas automatiquement bien dans l'autre sens.

Questions fréquentes

La fonction Vectorize intégrée de Figma peut-elle transformer une capture d'écran en un design d'interface fonctionnel ?

Vectorize est construite pour de l'art statique comme des symboles dessinés à la main, du lettrage et des illustrations. Elle transforme une image en tracés vectoriels, mais la propre documentation de Figma ne décrit pas qu'elle produise des calques de texte, des frames ou de l'auto layout, et elle avertit que les images complexes ou en basse résolution peuvent mal se vectoriser. Une capture d'une page web est exactement le cas complexe et chargé en texte pour lequel elle n'est pas construite.

Les plugins IA de capture d'écran vers Figma produisent-ils du vrai texte éditable ?

Certains, oui, dans une certaine mesure. Des plugins comme image.to.design font tourner de l'OCR et de l'inférence de mise en page sur l'image aplatie et peuvent extraire du texte et deviner des groupes d'auto layout, ce qui est une vraie avancée par rapport au simple calque. Mais c'est une reconstruction à partir de pixels, faite après que les vraies valeurs CSS de la page ont déjà disparu, si bien que l'espacement, les teintes exactes et les métadonnées de police sont des approximations dont l'éditeur lui-même dit qu'elles peuvent nécessiter un nettoyage manuel sur des designs complexes.

Qu'est-ce qu'UnHTML fait différemment d'un outil basé sur des captures d'écran ?

UnHTML lit le DOM et le CSS en direct de la page plutôt qu'une image aplatie, si bien que les calques de texte viennent du vrai texte de la page, l'auto layout vient des vraies règles flexbox et grid de la page, et les couleurs et espacements viennent des vraies valeurs CSS de la page. Le niveau gratuit plafonne à 500 calques en positionnement absolu ; Pro supprime ce plafond et ajoute la conversion en auto layout pour 39 $ en paiement unique par éditeur.

L'import d'UnHTML est-il exact au pixel près ?

Non, et il ne le prétend pas. Les polices qui ne sont pas installées localement sont remplacées, Inter par défaut, et chaque remplacement est consigné dans le rapport d'import. Un frame qui ne peut pas reproduire la géométrie capturée bascule de lui-même en positionnement absolu plutôt que de produire silencieusement une mise en page plus mauvaise.

Conclusion

Une capture d'écran calquée, que ce soit via le Vectorize natif de Figma, un plugin de calque, ou une reconstruction par IA, vous donne de la géométrie vectorielle et, au mieux, une approximation déduite de la structure. UnHTML vous donne la structure réelle de la page telle que mappée depuis son CSS, avec les replis consignés plutôt que cachés. Lequel est le bon dépend de si vous avez besoin d'art de référence ou d'une structure que vous comptez réellement éditer et reconstruire.