Il n’y a pas si longtemps, le chemin vers la création de logiciels était semé d’embûches, exigeant des heures de tutoriels de codage, la maîtrise des bases d’un langage de programmation, et d’interminables sessions de débogage pour comprendre pourquoi le code refusait obstinément de fonctionner. L’avènement du « vibe-coding », où l’on décrit son intention en langage naturel et laisse une intelligence artificielle prendre le relais, a radicalement transformé le paysage du développement logiciel. Mais au-delà de la simple génération de lignes de code en coulisses par des grands modèles de langage (LLM), ces agents IA ont fait des progrès spectaculaires dans la compréhension et la reproduction de l’aspect visuel du développement.
L’idée est séduisante : présenter à une IA une capture d’écran d’une interface utilisateur et la voir en théorie décortiquer le produit fini – identifiant la disposition, l’espacement, les couleurs, la typographie et les composants nécessaires pour le recréer fidèlement. Mais jusqu’où cette capacité s’est-elle réellement développée ? Pour le découvrir, j’ai soumis Claude Code, Codex et Google Antigravity à un défi identique : reconstruire une application entière à partir de simples captures d’écran, sans aucun code source ni fichier de conception à leur disposition. L’objectif était clair : la fidélité visuelle avant tout.
Le Choix Crucial de l’Application : Éviter la Connaissance Préexistante de l’IA
Le succès d’une telle expérience repose sur la neutralité du test. Initialement, j’avais envisagé d’utiliser une application populaire et visuellement complexe, comme Instagram, Snapchat ou Google Maps. Recréer leurs interfaces aurait certainement été un défi de taille. Cependant, un problème majeur est rapidement apparu : ces applications sont si omniprésentes que les modèles d’IA auraient très probablement déjà une connaissance approfondie de leur apparence. Le risque était grand que l’IA ne se contente pas de rétro-ingénierie à partir des captures, mais qu’elle s’appuie sur ce qu’elle savait déjà de l’application. Cela aurait faussé l’objectif principal de l’expérience, qui était de tester leur capacité à « voir » et à reconstruire, et non à « se souvenir ».
J’ai donc opté pour une approche différente, en choisissant délibérément une application de niche, peu connue du grand public : Foqos. Foqos est une application de concentration open-source, conçue pour aider les utilisateurs à bloquer les distractions et à rester éloignés de leur téléphone. Plus important encore pour ce test, elle présente une interface propre et distinctive, sans être excessivement complexe au point que la comparaison se transforme en un test d’ingénierie backend. Bien que Foqos soit open-source et que ses fichiers puissent être trouvés par un LLM ayant accès au web, une règle stricte de l’expérience interdisait toute recherche externe. Seules les captures d’écran devaient servir de référence.
Le Brief aux IA : Des Instructions Précises pour une Évaluation Juste
Pour chaque outil, le même prompt détaillé a été utilisé, afin de garantir des conditions de test équitables. Ce prompt était la pierre angulaire de l’expérience, délimitant clairement les attentes et les contraintes :
« Vous disposez d’un ensemble de captures d’écran dans le dossier de références. Recréez l’application présentée dans ces captures d’écran aussi fidèlement que possible en utilisant React. Votre objectif est la fidélité visuelle aux captures d’écran de référence. Déduisez la disposition, la typographie, les couleurs, l’espacement, le dimensionnement, les composants et la conception générale directement à partir des captures d’écran. »
Exigences :
- Construire tous les écrans affichés dans les images de référence.
- Rendre la navigation entre les écrans recréés fonctionnelle le cas échéant.
- Recréer les états d’interface utilisateur visibles et les interactions dans la mesure du possible.
- Utiliser des données locales/simulées pour tout ce qui nécessiterait normalement un backend ou une fonctionnalité au niveau du système d’exploitation.
- Ne pas redessiner, simplifier ou améliorer l’interface. Faire correspondre les captures d’écran aussi fidèlement que possible.
- Ne pas rechercher sur le web, GitHub, la documentation ou toute source externe l’application originale.
- Ne pas tenter de trouver le code source de l’application.
- Baser votre implémentation uniquement sur les captures d’écran fournies.
- Vous pouvez inspecter votre propre implémentation dans le navigateur et l’affiner si nécessaire.
- Continuez à affiner l’implémentation jusqu’à ce que vous pensiez qu’elle correspond étroitement aux références. Une fois terminé, assurez-vous que le projet fonctionne avec succès et que tous les écrans recréés sont accessibles.
J’ai utilisé la version CLI de chacun des trois outils, configurés dans des répertoires distincts avec le même ensemble d’images de référence. Pour Claude Code, j’ai utilisé Opus 5 ; pour Codex, GPT-6 Sol ; et pour Antigravity, Gemini 3.1 Pro, avec une capacité de raisonnement accrue activée pour tous.
Codex : Le Meilleur Élève, Malgré une Gaffe Hilarante
Il y a quelque temps, j’avais rédigé un article pour XDA soulignant comment Codex excellait dans presque tous les domaines, à l’exception notable du travail frontal. Cependant, OpenAI a depuis évolué vers sa nouvelle famille GPT-6 – incluant Astra, Sol et Luna – et l’amélioration dans le travail frontal est réellement perceptible. Pour ce test, j’ai utilisé GPT-6 Sol, spécialement conçu pour le codage complexe et les flux de travail basés sur des agents.
Parmi les trois, le résultat de Codex était sans conteste le plus proche de l’original. Mais avant d’aborder toutes ses réussites, il est impératif de mentionner l’erreur la plus amusante qu’il ait commise : au lieu de nommer l’application Foqos, il a inexplicablement décidé de la renommer… Fogos. Une petite touche d’humour involontaire qui rappelle que même les IA les plus avancées ne sont pas à l’abri d’une méprise.
Au-delà de cette bévue, les proportions générales, l’espacement, la forme des cartes et le placement des éléments étaient d’une précision impressionnante. Au premier coup d’œil, il était difficile de ne pas reconnaître l’application originale. Un exemple frappant concernait le bouton « Support » qui, dans mes captures d’écran, utilisait une simple icône de cœur. Codex l’a reproduit de manière à ce qu’il s’intègre parfaitement à l’interface. Claude, en revanche, l’a remplacé par un emoji de cœur rouge littéral, qui jurait immédiatement avec le reste de l’interface soignée. Antigravity se situait quelque part entre les deux sur ce point.
Cette supériorité s’étendait aux autres éléments de l’interface utilisateur. Codex a constamment mieux traité les petits détails comme de véritables composants d’interface plutôt que de simples approximations. Son icône de paramètres, ses boutons, les contours de ses cartes et sa section de profil étaient bien plus proches de la référence. Claude et Antigravity, quant à eux, avaient tendance à insérer des icônes génériques ou à réinterpréter légèrement le style. Claude, en particulier, semblait avoir une prédilection pour l’ajout d’emojis partout où c’était possible, ce qui détonnait parfois avec le design sobre de Foqos.
En termes de polices et de typographie globale, Codex s’est également avéré le plus fidèle. La taille, le poids et la hiérarchie du texte correspondaient bien mieux à l’original. Claude avait tendance à rendre certains éléments légèrement plus grands, tandis qu’Antigravity paraissait un peu plus sobre dans l’ensemble. Si aucun des modèles n’a reproduit chaque détail à la perfection, Codex était le seul dont la recréation permettait de passer de la référence à sa version sans remarquer immédiatement une divergence.
Claude Code : Un Travail Décent, mais une Créativité Malvenue
Malgré les quelques points que j’ai mentionnés précédemment, Claude a globalement réalisé un travail tout à fait honorable. Il a même été le seul des trois outils à rendre certains des contrôles recréés réellement interactifs. Les curseurs pouvaient être activés et désactivés, plutôt que de rester de simples éléments d’interface statiques, ce qui ajoutait une couche de fonctionnalité appréciable. Le placement de ses boutons était également généralement très proche de la référence, et la structure globale des écrans était logique et cohérente.
Là où Claude a vraiment pris du retard par rapport à Codex, c’était principalement dans les petits détails visuels. Le choix d’icônes lourdes en emojis était l’exemple le plus flagrant, mais il y avait aussi quelques endroits où l’espacement, la typographie et le dimensionnement semblaient légèrement décalés par rapport à l’original. Rien de dramatiquement faux, mais côte à côte avec la référence, sa version ressemblait davantage à une très bonne recréation qu’à une copie presque exacte.
Cependant, c’est aussi avec Claude que j’ai détecté une hallucination claire ! La section « Nouveaux Profils » que j’avais fournie ne comprenait que les sections suivantes : Nom, Stratégie de Blocage et Applications Bloquées. Je n’avais pas fourni de capture d’écran de la page complète. Codex et Antigravity se sont conformés aux options visibles dans la capture d’écran que j’avais fournie. Claude, en revanche, a ajouté sa propre section « Options » avec deux interrupteurs : « Activer l’activité en direct » et « Mode strict ».
Étant donné que ces options existent effectivement dans l’application réelle Foqos, j’ai été intrigué de savoir si Claude avait d’une manière ou d’une autre recherché l’application malgré mes instructions explicites. J’ai donc posé la question directement à Claude. Il a affirmé n’avoir effectué aucune recherche sur le web et que les deux lignes avaient été inventées en se basant sur les conventions courantes des applications de concentration. Selon lui, « Activité en direct » semblait être une fonctionnalité plausible pour ce type d’application, tandis que « Mode strict » est un paramètre courant dans les bloqueurs d’applications. Cette hallucination est d’autant plus fascinante : Claude a techniquement enfreint le brief en ajoutant des éléments d’interface utilisateur non visibles dans les captures d’écran, mais il a bizarrement « halluciné » des fonctionnalités qui existaient réellement dans l’application ! Cela soulève des questions intéressantes sur la manière dont les IA construisent leur compréhension du monde à partir de leurs vastes ensembles de données, même lorsqu’elles sont invitées à ne pas se référer à des sources externes spécifiques.
Antigravity : Pas de Défauts Majeurs, mais un Manque de Fidélité
Antigravity a probablement été le plus difficile à critiquer, car son résultat ne présentait pas réellement de défauts majeurs. L’application qu’il a produite semblait polie, les écrans étaient correctement structurés, et rien ne sautait immédiatement aux yeux comme étant cassé ou bizarre. Il n’y avait pas de bugs flagrants ni de choix de design grotesques. Pour une personne non avertie, l’application semblait tout à fait fonctionnelle et esthétiquement plaisante.
Le problème résidait dans le fait que, comparé à Codex et même à Claude dans certains aspects, Antigravity prenait simplement plus de libertés avec le design original. Ses cartes étaient un peu plus remplies, l’espacement était différent par endroits, et plusieurs éléments de l’interface utilisateur donnaient l’impression d’être davantage l’interprétation d’Antigravity des captures d’écran qu’une recréation directe et fidèle.
Par exemple, Antigravity a manqué certaines des nuances de couleurs plus subtiles de la référence. Là où Codex et Claude avaient tous deux remarqué que certaines parties de la grille d’activité utilisaient des teintes de violet légèrement plus claires pour distinguer certaines cellules, Antigravity a rendu cette section de manière beaucoup plus uniforme. C’était un petit détail, mais côte à côte, cela rendait sa version visiblement plus plate et moins fidèle à l’original. C’est dans ces infimes écarts que la fidélité visuelle tant recherchée s’est érodée.
Encore une fois, il n’y avait rien de fondamentalement « faux » avec le résultat d’Antigravity, mais il n’y avait pas non plus d’élément qui m’ait fait m’arrêter et penser qu’il avait véritablement reproduit la référence. Lorsque l’objectif principal de l’expérience était de déterminer quel outil pouvait se rapprocher le plus des captures d’écran, ces petites différences s’additionnaient, et c’est finalement ce qui l’a placé en dernière position. Le niveau de « presque bon » n’était pas suffisant pour rivaliser avec la précision méticuleuse de Codex.
Implications et Avenir du Développement Frontend par l’IA
Cette expérience s’est avérée extrêmement intéressante, car les trois outils ont atteint un niveau de fidélité bien plus élevé que ce que j’aurais pu anticiper. Bien qu’aucun d’entre eux n’ait produit une réplique parfaite, ils ont tous été capables de déduire une quantité surprenante d’informations à partir de simples captures d’écran. Cela inclut non seulement la disposition générale et l’espacement, mais aussi la palette de couleurs, la structure des composants, et même certaines interactions fondamentales. Cette capacité à transformer une image statique en une interface dynamique et fonctionnelle est un témoignage de l’avancée fulgurante des modèles de génération de code visuel.
Les implications pour le développement frontend sont considérables. Imaginez des designers pouvant transformer leurs maquettes graphiques en prototypes interactifs avec une facilité déconcertante, ou des développeurs pouvant accélérer considérablement les premières phases de construction de l’interface utilisateur. Bien sûr, le travail humain reste essentiel pour la finesse du design, l’optimisation des performances, l’accessibilité et l’intégration de logiques métier complexes. Cependant, l’IA semble désormais capable de prendre en charge une grande partie du travail répétitif et de la conversion initiale design-to-code, libérant ainsi les équipes pour se concentrer sur des tâches à plus forte valeur ajoutée.
L’incident de l’hallucination de Claude, qui a inventé des fonctionnalités réellement existantes, est également fascinant. Il suggère que ces modèles ne se contentent pas de reproduire ce qu’ils voient, mais qu’ils tentent de « comprendre » le contexte et la finalité d’une application, en s’appuyant sur un vaste corpus de connaissances. Cette capacité à combler les lacunes visuelles avec des éléments contextuellement pertinents, même si elle brise le brief initial, est un aperçu de la puissance de raisonnement que ces IA commencent à manifester.
En conclusion, l’ère où la création d’interfaces utilisateur à partir de visuels était une tâche laborieuse et purement manuelle touche à sa fin. Les agents d’IA, comme ceux testés ici, sont en passe de devenir des collaborateurs indispensables pour quiconque cherche à transformer des idées visuelles en code fonctionnel. La perfection n’est pas encore atteinte, mais la trajectoire est claire : l’avenir du développement logiciel sera profondément assisté, et potentiellement réinventé, par ces outils d’IA visuelle.