Cet article relate quelques pièges auxquels j'ai été confronté récemment en utilisant l'IA pour répliquer des pages. J'ai ensuite construit un workflow pour résoudre ces problèmes et organisé l'ensemble du processus pour référence.
Vous avez probablement vécu la même chose.
Parfois, vous envoyez une capture d'écran à une IA et lui demandez de créer une page basée dessus. La première version semble globalement correcte, mais à y regarder de plus près, quelque chose cloche : les cartes sont légèrement trop larges, les polices trop petites, les ombres incorrectes—juste des détails mineurs.
Ensuite, il faut décrire verbalement ce qui doit être ajusté et comment. Itérer sur plusieurs tours prend pas mal de temps.
J'ai donc pensé à chaîner le rendu, les captures d'écran, la comparaison et la modification dans un workflow, laissant le modèle se vérifier et se corriger lui-même. Cette approche semblait solide.
Mais en pratique, les choses ne se sont pas passées comme prévu. Parfois, après avoir corrigé au deuxième tour, le troisième annulait les modifications ; les résultats fluctuaient, et la page pouvait même empirer à chaque itération.
Allons droit au but.
Comment le rendre auto-correctif
Le processus n'est pas complexe :
1Capture cible ──▶ Le modèle écrit le HTML ──▶ Rendu navigateur (capture 1:1) ──▶ Génération de diff pixel par pixel2 │3Garder le meilleur historique ◀── Re-rendu ◀── Diagnostic puis édition du code par le modèle ◀── Original + Rendu + Diff
Le Diff ne corrige pas la page pour le modèle. Il transforme simplement « ça ne ressemble pas assez » en une carte visuelle des écarts spécifiques, qui est ensuite renvoyée au modèle pour qu'il décide des prochaines étapes.
Pour éviter que le modèle ne devine aveuglément à partir du Diff, avant chaque modification, je lui demande de répondre à trois questions :
- Où est le problème majeur ?
- Quel élément ou propriété CSS en est probablement la cause ?
- Comment compte-t-il le corriger ?
Ce n'est qu'après avoir répondu que nous touchons au code.
Pour ce test, j'ai utilisé Ling-3.0-flash-VL et sélectionné deux cartes pour une démo simple : une carte jaune avec un fond clair, une bordure noire épaisse et une ombre dure ; l'autre une carte sombre de tarification SaaS avec des boutons dégradés, des tags et des listes de fonctionnalités.
Je trouve que les cartes sont parfaites. Pas trop d'éléments, mais la largeur, les espaces blancs, la direction des boutons et les ombres—if l'un d'eux est désactivé, c'est immédiatement visible.
Première exécution
Commençons par la carte jaune.
Après la première version, le résultat global était en fait plutôt bon.
La structure, la palette de couleurs, le texte et les positions des boutons étaient majoritairement répliqués. Sans comparer côte à côte avec l'original, on pourrait penser que c'est suffisant.
Mais placées ensemble, des différences subtiles émergent : la carte est légèrement plus grande, les graisses de police diffèrent, et les espaces blancs/tailles des boutons ne sont pas parfaitement alignés.
J'ai ensuite renvoyé l'image originale, le résultat du premier tour et le Diff à Ling, en lui demandant d'identifier ces problèmes de détail.
Du diagnostic, il ne dit pas simplement « pas assez similaire ». Il identifie précisément des problèmes comme la taille de la carte, les polices et les boutons, puis modifie le CSS correspondant.
Comparaison sur trois tours de la carte jaune : Le tour 2 s'est amélioré, le tour 3 a régressé, donc nous avons gardé le tour 2 comme meilleur historique.
Cependant, un bon premier tour ne garantit pas une amélioration continue.
Cette vidéo capture le problème : Le tour 2 était plus proche de l'original, mais le tour 3 a légèrement glissé en arrière. Heureusement, le workflow n'a pas par défaut pris le dernier tour comme réponse finale, mais a préservé le meilleur historique du tour 2.
Donc, renvoyer le Diff ne signifie pas que le modèle devient soudainement plus intelligent. Il peut repérer beaucoup de problèmes de détail et lier ses jugements à des CSS spécifiques, mais il reste parfois confus.
Pour les détails sur le fonctionnement du workflow, regardez l'enregistrement d'écran ci-dessous.
Démo complète de la carte de tarification sombre : sélection des ressources, génération initiale, comparaison par curseur, puis exécution de deux tours d'auto-guérison.
Les changements ici n'étaient pas spectaculaires car le premier tour était déjà proche. Les tours suivants ont continué à améliorer, en se concentrant sur la taille de la carte, les coins arrondis, les boutons et les dégradés.
En comparant les deux enregistrements, on observe des tendances différentes :
La carte jaune s'est améliorée au tour 2 mais a régressé au tour 3 ; la carte sombre a montré des améliorations régulières et mineures sur les trois tours. Bien que deux enregistrements ne prouvent pas de règles statistiques, ils montrent que le même workflow ne donne pas toujours de meilleurs résultats à chaque tour.
Les problèmes évidents sont généralement corrigés lors des un ou deux premiers tours. Les itérations suivantes impliquent des ajustements fins des tailles de police, des coins arrondis et des décalages d'ombre, où corriger une chose casse souvent une autre. C'est pourquoi je sauvegarde le meilleur historique plutôt que de supposer que le dernier tour est la solution.
Que peut-il réellement faire ?
De ces résultats, la première version est un standard Screenshot-to-Code. Ce qui est intéressant, c'est qu'après avoir vu la sortie rendue, il peut identifier les problèmes jusqu'à des éléments et propriétés CSS spécifiques au lieu de dire simplement « rends-le plus similaire ».
Même sans correction automatique, cette étape de diagnostic sert de liste de contrôle utile.
Beaucoup de problèmes visuels ne déclenchent pas d'erreurs. Si le modèle peut voir la page réellement rendue par le navigateur, il a une chance de continuer à se corriger lui-même.
Un autre point pratique : ce workflow nécessite des appels répétés au modèle, donc la vitesse compte. Ma génération HTML complète d'une seule page enregistrée a pris environ 7 secondes. Les données publiques indiquent que Ling-3.0-flash-VL a 124B de paramètres totaux, activant 5.5B par inférence, avec des capacités ajoutées de compréhension visuelle et d'Agent Visuel.
Le chiffre de 7 secondes est basé sur mon interface et mes paramètres spécifiques. Je n'ai pas fait de comparaisons horizontales ni ne déduirai la vitesse/coût uniquement à partir des paramètres actifs.
Où sont les pièges ?
Le vrai gouffre temporel n'était pas la connexion au modèle, mais l'obtention d'un feedback précis. Au début, je pensais que les fluctuations signifiaient une instabilité du modèle. Après avoir vérifié les Diffs un par un, j'ai réalisé qu'une partie du problème résidait dans ma boucle de feedback.
1. Premier piège : Taille
Si l'image cible était mise à l'échelle et que le navigateur capturait l'écran à une taille différente, les images n'étaient jamais alignées dès le départ. Même avec la bonne réponse, le Diff montrait de grandes divergences.
Pour les diffs de pixels, être décalé de quelques pixels globalement crée des zones d'erreur massives.
2. Deuxième piège : Animation
Une fois, le modèle a ajouté des effets de fondu aux listes de fonctionnalités. Les captures d'écran prises en milieu d'animation laissaient le contenu transparent.
Après suppression des animations, la page semblait normale visuellement, mais les scores de comparaison automatisés se sont détériorés.
Raison : Le contenu transparent révélait l'arrière-plan, faisant croire aux algorithmes de pixels que cela « ressemblait plus ».
3. Troisième piège : Versioning
Si un tour cassait le design, continuer à patcher par-dessus du mauvais code empile les erreurs. Comme construire sur une base bancale—plus vous essayez fort, plus le désordre s'aggrave.
En résumé, Diff est un outil, pas un juge.
Si le feedback est faux, le modèle ne le remarquera pas. Il corrigera diligemment dans la mauvaise direction sur la base d'entrées défaillantes.
Conclusion
J'ai distillé les règles en trois points :
- Utilisez des dimensions identiques pour les captures originales et celles du navigateur ; aucune mise à l'échelle secondaire.
- Fixez le viewport, les polices, les états d'animation et le timing des captures d'écran.
- Continuez à partir de la meilleure version historique à chaque tour ; ne patchez pas du code dégradé.
Un code fonctionnel n'est que la première étape. Les problèmes qui ne génèrent pas d'erreurs mais semblent incorrects peuvent effectivement être vérifiés par des modèles visuels. Cependant, voir les écarts ne garantit pas des corrections correctes à chaque fois.
Donc, je ne suppose plus que plus de tours égalent de meilleurs résultats. Corrigez les problèmes évidents d'abord, arrêtez-vous quand les améliorations stagnent—cela me suffit.
Le modèle est open-source et gratuit pendant 2 semaines. Pour l'exécuter vous-même, utilisez ces liens 👇🏻 :
- Huggingface : [https://huggingface.co/inclusionAI/Ling-3.0-flash-VL
- Ling studio：https://chat.ant-ling.com/chat
- Ant Digital MaaS (Chine): https://maas.antdigital.com/models/modelservice-1788265478122001738
- Openrouter：https://openrouter.ai/inclusionai/ling-3.0-flash-vl:free
Ps : Cet article a été dicté et peaufiné par une IA, donc il a une âme ✌🏻
