Note de l'éditeur : Ces dernières années, la compétition dans l'IA visuelle a largement tourné autour d'une question : qui génère des images plus réalistes, qui produit des vidéos plus fluides ? Les modèles de diffusion transforment des mots-clés en images, en vidéos et en scènes réalistes, amenant également le public à évaluer la capacité des modèles en fonction de critères comme « est-ce ressemblant ? » ou « est-ce beau ? ».
Cet article de a16z souligne cependant que la prochaine étape de l'IA visuelle ne consiste peut-être pas seulement à générer de plus beaux pixels, mais à générer les artefacts de code (code artifacts, fichiers structurés pouvant être édités, testés et livrés) qui se cachent derrière ces pixels.
Cette distinction peut sembler technique, mais elle détermine en réalité la capacité de l'IA à intégrer véritablement les flux de travail de production. Un designer n'a pas besoin que d'une capture d'écran d'interface utilisateur, mais de code HTML/CSS, de composants React, de calques et de fichiers livrables ; un animateur n'a pas besoin que d'une séquence vidéo, mais d'images clés, de courbes temporelles et de paramètres de mouvement modifiables ; un artiste 3D n'a pas besoin que d'une image de rendu, mais de structures géométriques, de matériaux, d'éclairages, de caméras et d'une hiérarchie de scène.
Ainsi, l'article distingue deux voies pour la génération visuelle : la génération native par pixels (génération directe d'images ou de vidéos) convient au réalisme, à l'ambiance et à l'exploration ; la génération native par code (génération de SVG, Lottie, scripts Blender, scènes USD, etc.) est mieux adaptée à l'édition, l'itération et la production. La véritable importance de cette dernière réside dans sa capacité à former une boucle fermée « code → rendu → vérification → modification ». Le modèle ne se contente plus de rééchantillonner à chaque fois, mais débogue un programme visuel vérifiable.
C'est aussi pourquoi l'auteur est particulièrement optimiste concernant la 3D. Parce qu'une image de rendu d'une chaise n'est pas une chaise, ce n'est qu'une image de chaise. Un actif réellement utilisable dans un jeu, un simulateur ou un outil 3D doit posséder une structure géométrique stable, une hiérarchie de composants, des matériaux et des contraintes fonctionnelles : une porte doit pouvoir s'ouvrir, un tiroir doit pouvoir coulisser, une roue doit pouvoir tourner. En d'autres termes, la valeur future de l'IA visuelle ne réside pas dans « ressembler à », mais dans « pouvoir être utilisé ultérieurement ».
Cet article offre un excellent cadre de réflexion : la première vague d'IA visuelle a résolu le problème de la génération, la prochaine vague doit résoudre le problème de la production. Lorsque l'IA visuelle passera de la sortie finale au code source, ce ne sont pas seulement les outils de conception qui seront transformés, mais l'ensemble de la chaîne de production de contenu visuel.
Voici le texte original :
Ces dernières années, l'IA visuelle a été largement jugée sur la base des « pixels ». Plus l'image ou la vidéo finale générée semble bonne, plus le modèle paraît puissant.
Cela n'a rien d'étonnant. Les modèles de diffusion ont d'abord transformé des mots-clés en belles images, puis se sont étendus à la vidéo, et à des mondes de plus en plus réalistes. Les gens les comparent naturellement à Photoshop ou à un appareil photo.
Mais pour de nombreuses tâches visuelles, comme la conception graphique, la conception d'interface utilisateur ou la modélisation 3D, la représentation finale dont les utilisateurs ont vraiment besoin n'est pas seulement les pixels affichés. Ils ont besoin d'un artefact qui peut être itéré en fonction des retours et des nouvelles idées. Un designer n'a pas besoin que d'une maquette (mockup), mais aussi de calques, de composants et de fichiers de livraison ; un animateur n'a pas besoin que d'une séquence vidéo, mais de courbes temporelles, d'images clés et de trajectoires de mouvement modifiables ; un artiste 3D n'a pas besoin que d'une image de rendu, mais de structures géométriques, de matériaux, d'éclairages, de caméras et d'une structure de scène.
Les outils d'IA visuelle les plus intéressants d'aujourd'hui n'essayent plus de générer directement la sortie finale. Ils commencent à générer le code source qui se cache derrière cette sortie finale. Ce changement libère l'éditabilité, la capacité d'itération et les boucles de rétroaction que les modèles natifs par pixels ont du mal à égaler.
Les deux piles technologiques de la génération visuelle
Nous pouvons comprendre la génération visuelle de deux manières principales.
La première est la génération native par pixels. Ces systèmes génèrent généralement directement des images ou des vidéos, souvent dans un espace latent. Ils excellent dans les textures, l'ambiance, l'éclairage et le réalisme. Si l'objectif est de générer une séquence cinématographique, un moodboard élégant, ou une image photoréaliste, les modèles de diffusion restent la méthode dominante.
La seconde est la génération native par code. Ces systèmes génèrent une forme de représentation, qui est ensuite exécutée ou rendue par un autre moteur. Le modèle ne génère pas directement les pixels finaux, mais génère un programme capable de générer des pixels.
Ce programme peut être un fichier SVG, une mise en page HTML/CSS, un composant React, un fichier JSON Lottie, un script Blender, un graphe de scène USD, un shader, ou une scène de moteur de jeu. La sortie visuelle finale reste des pixels, mais la véritable « source de vérité » est une représentation structurée.
Cette distinction est importante, car les flux de travail de production se soucient beaucoup de « ce qui se passe après la génération ». Une image générée peut être utilisée comme sortie, mais un programme visuel généré peut être utilisé comme artefact : il peut être édité, réutilisé, amélioré, versionné ; il peut être intégré dans une pile logicielle et validé selon des contraintes ; il peut être rendu à plusieurs reprises sous différentes conditions, et être transféré entre designers, ingénieurs et agents.
Je pense qu'un changement important est déjà en cours : pour une partie des problèmes visuels, nous allons apprendre à redéfinir les tâches de génération visuelle comme des tâches de codage, et en résolvant un problème de codage bien défini et vérifiable, nous obtiendrons des améliorations très efficaces.
Le code est un bon support pour résoudre les problèmes visuels
La manière la plus simple de comprendre la valeur de la génération de code visuel est d'observer ce qui se passe après le premier brouillon.
Supposons qu'un modèle génère un logo. Si la sortie est une image matricielle et qu'une courbe n'est pas correcte, l'utilisateur doit la masquer, la redessiner localement, la regénérer ou la redessiner manuellement. Mais si la sortie est un SVG, l'utilisateur peut directement éditer les chemins, les formes de base, les dégradés, les traits ou les éléments de texte. C'est déjà ainsi que les designers créent des logos sur Quiver.
Dans le domaine de la conception d'interface utilisateur, si la sortie est une capture d'écran, elle sert surtout d'inspiration. Mais si la sortie est du HTML/CSS ou du React, le designer peut inspecter le DOM, remplacer de vrais composants, tester les états réactifs, vérifier l'accessibilité, et le connecter à l'application.
C'est aussi pourquoi la génération de code visuel est particulièrement adaptée au calcul au moment du test (test-time compute). Dans la génération native par pixels, augmenter le calcul d'inférence signifie généralement échantillonner plus de sorties : générer 20 images, choisir la meilleure, peut-être essayer à nouveau. C'est certes utile, mais chaque essai est essentiellement un nouveau lancer de dé. Le modèle peut répondre aux retours, mais ces retours sont souvent globaux et peu précis.
Techniquement, les modèles de diffusion peuvent également bénéficier du test-time compute. Par exemple, « Inference-time Scaling of Diffusion Models through Classical Search » montre qu'une recherche pendant la phase d'inférence peut améliorer les performances des modèles de diffusion en planification, apprentissage par renforcement et génération d'images. Mais le mécanisme de boucle ici est différent. Dans les modèles de diffusion, le système recherche généralement parmi les trajectoires latentes ou les échantillons finaux. Le signal de récompense peut indiquer au modèle qu'une sortie est meilleure qu'une autre, mais il ne peut pas mapper clairement ce retour à une modification concrète et spécifique au niveau du code source.
La génération native par code crée une boucle plus précise : code → rendu → vérification → modification.
Le modèle génère l'artefact, le rend, observe ce qui ne va pas, puis corrige le fichier source. Si l'espacement est incorrect, il modifie le CSS ; si la courbe du logo est déviée, il édite le chemin SVG ; si le rythme de l'animation est trop lent, il ajuste les paramètres temporels. La clé est que chaque itération améliore l'artefact sous-jacent, et pas seulement la sortie rendue. C'est pourquoi la génération de code visuel bénéficie naturellement de la génération de plus de tokens et du test-time compute. Le modèle débogue un programme visuel dans un environnement fermé et vérifiable, au lieu de simplement échantillonner plus d'images.
Une pile technologique de génération visuelle centrée sur le code
Derrière ces exemples se trouve une pile technologique : modèle d'encodage + représentation symbolique + moteur de rendu.
Le modèle d'encodage est l'auteur et l'éditeur de l'artefact. Il est responsable de l'écriture du HTML, SVG, JSON Lottie, des scripts Blender, des scènes USD, ou des programmes personnalisés pour les actifs 3D.
La représentation symbolique est la source de vérité. C'est ce qui rend l'artefact éditable. Une interface utilisateur a des nœuds DOM, des règles de mise en page et des composants ; une animation Lottie a des calques, des formes vectorielles, des courbes temporelles, des images clés et des paramètres de mouvement ; un actif 3D a une structure géométrique, des matériaux, des articulations, des contraintes et des relations hiérarchiques.
Le moteur de rendu transforme ensuite ces structures en pixels. Le navigateur rend le HTML/CSS, le moteur de rendu SVG rend les graphiques vectoriels, le lecteur Lottie rend les animations, Blender ou un moteur de jeu rend la scène 3D, et un simulateur valide si un actif avec des articulations peut réellement se déplacer ou interagir.
OmniLottie est un bon exemple qui illustre pourquoi la représentation symbolique est importante. Lottie est un format d'animation léger basé sur JSON ; il ne représente pas l'animation comme une vidéo plate, mais utilise des formes vectorielles, des calques, des images clés et des paramètres temporels modifiables pour représenter le mouvement. OmniLottie propose de convertir le JSON Lottie brut en séquences de commandes plus compréhensibles pour les modèles, leur permettant de générer et d'éditer des animations Lottie de manière plus fiable. L'objectif de cet article n'est pas de construire une boucle d'agent complète, mais de rendre Lottie plus adapté à la génération par les modèles : il convertit le JSON Lottie brut en un ensemble compact de séquences de commandes et de paramètres. Cette action est cruciale car Lottie est déjà un format d'animation éditable. Une fois que le mouvement est représenté par des formes, des calques, du temps et des paramètres d'animation, les retours peuvent être mappés sur des modifications au niveau du fichier source. Si un objet se déplace trop lentement, ajustez le temps ; si le chemin est incorrect, modifiez le vecteur ; si la déformation est déviée, mettez à jour la séquence de formes.
Cette pile technologique correspond précisément à la boucle de test-time compute qu'un agent de codage peut utiliser pour améliorer la qualité de la sortie : à chaque cycle « code → rendu → vérification → modification », le modèle ne génère pas simplement un nouvel échantillon, mais utilise les retours fournis par le moteur de rendu pour améliorer l'artefact sous-jacent. Il peut modifier les règles CSS, ajuster les chemins SVG, corriger le timing d'une animation, ou mettre à jour des contraintes 3D, puis rendre à nouveau et continuer à améliorer.
Cela rend la convergence de la boucle possible. Dans la génération native par pixels, chaque nouvel essai produit souvent une nouvelle sortie. Dans la génération native par code, chaque essai peut améliorer l'artefact source lui-même. Le modèle ne se contente pas d'échantillonner plus d'images ou de vidéos, il débogue un programme visuel dans un environnement fermé et rendable.
Carte du marché : points d'entrée formés autour des environnements d'exécution
Le marché de la génération de code visuel s'organise autour des « environnements d'exécution », c'est-à-dire l'endroit où l'artefact est rendu ou exécuté. Dans la génération visuelle native par code, le modèle génère un artefact symbolique, et cet artefact est exécuté dans un certain environnement : navigateur, moteur de rendu SVG, lecteur Lottie, Blender, moteur de jeu ou simulateur.
Chaque environnement d'exécution formera un point d'entrée différent, car chacun possède sa propre représentation source, sa boucle de rétroaction et son flux de travail de production.
Aujourd'hui, l'application la plus évidente se situe dans le domaine de la conception 2D, notamment la conception d'interface utilisateur et le design graphique. Mais la génération de code visuel ne se limite pas aux outils de conception. Dès qu'il existe une représentation sous-jacente pour un artefact visuel qui peut être générée, rendue, inspectée et optimisée, elle peut apparaître.
Pourquoi la 3D est la prochaine frontière importante
Bien que la conception de produits et le design 2D soient les cas d'usage les plus évidents aujourd'hui, les artefacts 3D sont peut-être ceux qui bénéficieraient le plus de cette approche consistant à « redéfinir les problèmes de cohérence comme des problèmes de codage ».
Un design 2D peut parfois être utile simplement s'il a l'air correct. Mais pas un actif 3D. Une image de rendu d'une chaise n'est pas une chaise, ce n'est qu'une image de chaise. Pour que cet actif soit vraiment utilisable dans un jeu, un simulateur ou un outil d'édition 3D, il doit posséder une représentation 3D sous-jacente cohérente, comprenant une structure géométrique correcte, des matériaux, une hiérarchie de composants et un contexte de scène.
C'est pourquoi la 3D se prête naturellement à la génération de code visuel. Sa valeur ne réside pas seulement dans la génération de quelque chose qui ressemble à de la 3D sous un certain angle, mais dans la génération d'une structure 3D cohérente qui tient la route sous différents angles de vue, lors de l'édition et de l'interaction. Cela nécessite une boucle d'itération : proposer un objet, le rendre, vérifier si la structure géométrique et les composants sont raisonnables, puis modifier la représentation sous-jacente. Mais cette boucle n'est efficace que si l'agent dispose des bons outils et du bon contexte. Il ne suffit pas de lancer Blender encore et encore jusqu'à ce que quelque chose paraisse meilleur. L'agent doit pouvoir changer de vue caméra, interroger l'état de la scène, isoler des objets, comparer avec un objectif, se souvenir des tentatives précédentes, et transformer les différences visuelles en modifications au niveau du fichier source. Ce sont ces capacités qui offrent au test-time compute une chance de converger.
Pour de nombreux actifs, la cohérence visuelle n'est que la base. Les objets ont également besoin d'une sémantique de composants correcte et de contraintes fonctionnelles : une porte doit pouvoir s'ouvrir, une charnière doit pouvoir pivoter, un tiroir doit pouvoir coulisser, une roue doit pouvoir tourner. En d'autres termes, la sortie ne peut pas être seulement une forme qui semble raisonnable, elle doit aussi fonctionner comme la chose qu'elle représente.
C'est exactement ce qui rend les projets comme VIGA et Articraft3D intéressants. Nous nous attendons à voir encore plus de travaux dans ce sens cette année, y compris des projets commerciaux et open source. VIGA utilise Blender comme environnement de rendu et de rétroaction, transformant la reconstruction visuelle en une boucle « code—rendu—vérification » ; mais VIGA ne se contente pas d'exposer Blender brut à la boucle de l'agent. Il fournit à l'agent des outils sémantiques pour observer et modifier, et conserve la mémoire des tentatives passées, lui permettant d'inspecter l'objet sous un meilleur angle, de diagnostiquer les problèmes et d'apporter des modifications ciblées. Articraft3D traite plus directement la structure des actifs : il définit la génération 3D articulée comme l'écriture de programmes qui définissent les composants, la structure géométrique, les articulations et les tests.
Impacts futurs et questions non résolues
Si la génération de code visuel devient réalité, les produits qui l'emporteront ne se contenteront pas de générer de plus belles sorties. Ils maîtriseront l'ensemble de la boucle : générer l'artefact, le rendre, vérifier ce qui ne va pas, et modifier le fichier source.
Cela aura plusieurs conséquences.
Tout d'abord, les moteurs de rendu deviendront des environnements de rétroaction. Les navigateurs, les moteurs de rendu SVG, les lecteurs Lottie, Blender, les moteurs de jeu et les simulateurs deviendront les environnements où les agents testeront et amélioreront leurs œuvres, tout comme les agents de codage utilisent aujourd'hui des sandbox et des machines virtuelles.
Deuxièmement, la qualité du contexte d'itération deviendra plus importante que jamais. Pour qu'un agent entre dans une version « boucle de Ralph » pour le code visuel, la représentation intermédiaire doit être suffisamment précise pour guider l'étape suivante. Le modèle doit non seulement savoir que « quelque chose n'a pas l'air correct », mais aussi savoir quelle partie du fichier source doit être modifiée et pourquoi. De petites erreurs dans la structure, le rendu ou la rétroaction peuvent s'accumuler rapidement sur plusieurs itérations.
Troisièmement, l'avenir sera probablement hybride. Les modèles natifs par pixels resteront les meilleurs pour le réalisme, les textures et l'exploration ; les systèmes natifs par code seront plus adaptés à la structure, l'itération et la production. Les flux de travail les plus utiles combineront les deux.
Bien sûr, de nombreuses questions restent ouvertes. Quelle représentation sera finalement adoptée dans chaque domaine ? Devrons-nous recréer des moteurs et des moteurs de rendu plutôt que de continuer à utiliser les outils de la génération précédente ? Dans quelle mesure le goût visuel peut-il être capturé par des contraintes, des tests et des boucles de rétroaction ?
Mais la direction est claire : l'IA visuelle passe de la sortie finale à l'artefact de code. La première vague a facilité la génération d'images ; la prochaine vague facilitera la génération d'artefacts visuels pouvant être édités, testés, livrés et améliorés.






