UnHTML contre Anima : dans quel sens la conversion se fait vraiment

UnHTML et Anima résolvent des problèmes opposés

UnHTML transforme une page web en calques Figma. Anima transforme une maquette Figma en code. Deux tâches différentes. On les confond parce que les deux touchent à Figma et peuvent tous deux partir d'une URL, mais la conversion se fait dans des sens opposés sur le même pipeline. Les confondre, c'est choisir le mauvais outil pour la tâche qu'on a réellement.

Cette confusion compte plus qu'il n'y paraît. Un designer qui hérite d'un site sans fichier de conception a besoin du sens page web vers Figma. Une équipe qui a déjà un fichier Figma et qui a besoin d'un front end fonctionnel a besoin du sens Figma vers code. Chercher "alternative a anima" ou "unhtml vs anima" signifie généralement qu'on s'est d'abord trompé d'outil : on a essayé d'exporter du code depuis une page qui n'a jamais existé dans Figma, ou on a essayé d'importer une page web dans un plugin qui ne lit que des fichiers Figma. Voici ce que fait chaque outil, où les deux flux de travail se recoupent réellement, et où le prix les sépare.

Ce que fait UnHTML

UnHTML prend une page web active et la transforme en calques Figma natifs et modifiables : de vrais frames, du texte, des images, des vecteurs, et un auto layout calqué sur le CSS propre de la page. Le résultat est un fichier Figma. Rien là-dedans ne produit du code.

Il fonctionne hors ligne par défaut, zéro requête réseau avec les réglages par défaut. Récupérer des ressources distantes et exécuter les scripts de la page est une option d'activation unique, désactivée sauf si on l'active soi-même, donc rien ne quitte la machine autrement.

La tarification est un achat unique, pas un abonnement. La version gratuite importe jusqu'à 500 calques en utilisant un positionnement absolu. Pro coûte 39 $ en paiement unique par éditeur, supprime la limite de calques et ajoute la conversion en auto layout. Studio coûte 119 $ en paiement unique et couvre cinq éditeurs.

L'import ne reproduit pas la page au pixel près, et il ne cherche pas à le faire. Les polices qui ne sont pas installées localement sont remplacées, par Inter par défaut, et chaque substitution apparaît dans le rapport d'import au lieu de modifier le design en silence. Les grilles complexes qui ne peuvent pas être représentées en auto layout Figma repassent en positionnement absolu plutôt que de produire une mise en page qui semble correcte jusqu'à ce que quelqu'un redimensionne un frame.

Ce qu'il ne fait pas : pas d'export de code, pas de React, pas de sortie HTML. Si l'objectif est du code front end prêt à livrer, ce n'est pas l'outil. Ce n'est pas non plus un outil de conception pour créer quelque chose de nouveau. C'est un moyen de faire passer une page existante dans un format que Figma peut modifier.

Ce que fait Anima

Le produit principal d'Anima fonctionne dans l'autre sens : une maquette Figma entre, du code sort. Le plugin Figma d'Anima exporte une sélection issue d'un fichier Figma existant vers React, HTML, CSS ou Tailwind, Vue, TypeScript, Next.js et plus encore, à partir d'un fichier déjà construit dans Figma. Anima Playground propose le même export à partir d'un lien Figma collé, pensé pour des prototypes rapides et des personnes qui ne sont pas designers.

Anima possède aussi une fonction de clonage de site web, et c'est la partie qui prête à confusion. Clone website prend une URL active, le même type de point de départ qu'utilise UnHTML, mais produit du code, HTML ou React, pas des calques Figma. Le point d'entrée se ressemble, le point de sortie est l'opposé. Si l'objectif est un fichier Figma modifiable, Clone website n'y mène pas.

Facile à manquer, puisque les deux outils peuvent techniquement partir d'"une URL". Ce qui compte, c'est ce qui sort de l'autre côté. Le discours d'Anima positionne lui-même le produit autour d'équipes qui construisent des applications complètes à partir d'une maquette Figma existante, pas autour de la recréation d'une page qui n'a aucun fichier Figma d'origine. C'est un outil de conception vers code avec un raccourci de clonage de site greffé dessus, pas un outil de web vers conception.

Comment fonctionne réellement la conversion de l'auto layout

La raison pour laquelle une conversion de page web vers Figma tient la route vient du fait que le moteur d'auto layout de Figma reflète désormais très fidèlement le CSS. Le guide de Figma sur l'utilisation de l'auto layout en pensant au CSS Flexbox décrit le padding, le gap et le dimensionnement en fill container comme suivant le modèle CSS border-box. Un élément avec du padding conserve l'espace dont il a besoin plutôt que d'être compressé, et les enfants réglés en fill container répartissent l'espace selon leur zone de contenu plutôt que selon leur propre taille, exactement comme fonctionne le dimensionnement border-box en CSS.

L'espacement correspond aussi. Les valeurs d'auto-spacing de Figma Between, Evenly et Around correspondent directement aux valeurs CSS space-between, space-evenly et space-around. La propriété gap de CSS est elle-même un raccourci pour row-gap et column-gap sur les conteneurs flex et grid, et c'est cette propriété, lue directement dans la feuille de style de la page, qui est traduite dans la valeur de gap d'un frame Figma.

Là où une mise en page ne peut pas être reproduite fidèlement, grilles complexes, empilements non standard, le repli se fait vers le positionnement absolu plutôt que de deviner une structure. Une limite délibérée, pas un bug : un repli honnête vaut mieux qu'une mise en page qui semble correcte et se casse dès que quelqu'un y touche.

Cette limite explique aussi pourquoi les deux outils ne peuvent pas simplement échanger leurs rôles. Le plugin d'Anima lit les réglages d'auto layout propres à un frame Figma et les réécrit en CSS flexbox, une traduction qui fonctionne parce que Figma stocke déjà la mise en page de façon structurée et consultable. Aller dans l'autre sens signifie lire le CSS calculé d'une page déjà rendue et reconstruire quels réglages d'auto layout la reproduiraient. Lire des données structurées et écrire du CSS est un problème plus restreint que lire les styles rendus d'une page active et en reconstruire la structure. Une partie de la raison pour laquelle ce sont devenus deux produits séparés plutôt qu'un seul capable des deux.

Prix : paiement unique contre abonnement

La page tarifaire d'Anima dévoile les plafonds quotidiens du niveau gratuit et le seuil d'Enterprise, mais ne publie pas de prix fixe par poste pour une offre payante standard à la date de rédaction. Ce chiffre reste non vérifié plutôt que deviné.

La répartition pratique : quelqu'un qui importe une page occasionnellement paie une fois avec UnHTML et c'est réglé. Une équipe qui exporte du code en continu porte un abonnement qui évolue selon l'usage, quel que soit le plan précis choisi.

Quand utiliser vraiment les deux

Les deux flux de travail s'enchaînent dans un seul sens. Importer une page existante dans Figma avec UnHTML, la repenser là-bas, puis remettre le fichier Figma terminé à Anima pour exporter la version repensée sous forme de code. Un parcours réel et courant : démonter, repenser, publier. Une équipe qui reconstruit une ancienne page, ou qui démonte la page d'un concurrent pour voir comment elle est faite, obtient un point de départ modifiable sans redessiner chaque frame à la main, puis remet le résultat à l'outil d'export de code que l'équipe front end utilise déjà.

Aller dans l'autre sens, de Figma vers le code puis retour vers Figma, n'a pas de sens. Cela ne fait que réimporter ce qui existait déjà. Si une maquette vit déjà dans Figma, il n'y a rien qu'UnHTML puisse convertir, et lancer un import sur une page rendue à partir de ce même fichier Figma ne ferait que reconstruire une copie d'un fichier que l'équipe possède déjà.

Le sens est toute la réponse

UnHTML et Anima ne se disputent pas la même tâche. L'un transforme une page web en fichier Figma modifiable, l'autre transforme un fichier Figma en code. Choisissez le premier quand la destination est Figma. Choisissez le second quand la destination est du code prêt à livrer. La plupart des projets qui ont besoin des deux les utiliseront dans cet ordre, pas comme des alternatives l'un à l'autre.