Codex peut maintenant voir son propre code — et ça change absolument tout
La semaine dernière, j'ai regardé un assistant de code IA observer un croquis sur tableau blanc — un rectangle grossier dessiné à la main avec quelques cercles ondulés et des flèches — et le transformer en un globe 3D interactif fonctionnel avec des épingles de destination cliquables, des animations fluides et des mises en page responsives pour mobile. Ensuite, il a ouvert un navigateur, pris une capture d'écran de ce qu'il avait construit, remarqué que les labels des épingles se chevauchaient sur les petits écrans, et corrigé le CSS sans que personne ne le lui demande.
C'est cette dernière partie qui m'a stoppé net. Pas la génération de code — je vois de la génération de code impressionnante depuis deux ans maintenant. La partie où l'IA a regardé sa propre production, identifié un problème visuel, et l'a corrigé de manière autonome. Ce n'est pas un assistant de code. C'est un assistant de code qui a des yeux.
Codex d'OpenAI possède des capacités multimodales depuis un moment, mais les dernières démonstrations montrent quelque chose de qualitativement différent de ce que j'ai testé auparavant. Le système exécute désormais une boucle continue : générer du code, rendre le résultat, capturer l'écran du rendu, analyser la capture pour détecter des problèmes, corriger les problèmes, recapturer. Il imite — et dans certains cas surpasse — le workflow qu'un développeur front-end humain suit naturellement : écrire du code, vérifier dans le navigateur, ajuster, vérifier à nouveau.
J'ai passé la semaine dernière à pousser ce workflow à ses limites sur trois projets. Les résultats m'ont obligé à repenser entièrement ma façon d'aborder le développement front-end. Pas parce que Codex est parfait — il ne l'est absolument pas, et je vais te montrer exactement où il échoue. Mais parce que la boucle d'auto-vérification résout le plus gros problème du code UI généré par IA : l'écart entre ce que l'IA pense avoir construit et ce qui s'affiche réellement à l'écran.
Laisse-moi te montrer à quoi ça ressemble en pratique, où se trouve la vraie magie, et pourquoi les démos impressionnantes cachent certaines limitations réelles que tu dois connaître.
Le problème que tous les outils de code IA avaient (jusqu'ici)
Voici une frustration que je vis depuis la première fois que j'ai utilisé une IA pour générer du code front-end. Tu décris une mise en page. L'IA écrit du HTML et du CSS. Tu fais le rendu dans le navigateur. Et ça a l'air... pas bon. Pas cassé-pas-bon. Subtilement pas bon. L'espacement est décalé. Les éléments se chevauchent à certaines largeurs de viewport. Un bouton qui devrait être centré se retrouve douze pixels trop à gauche. Des couleurs qui semblaient correctes dans le code paraissent ternes sur le fond réel.
Alors tu décris les problèmes. L'IA ajuste. Tu refais le rendu. Toujours pas tout à fait ça. Trois ou quatre allers-retours comme ça et tu as passé plus de temps à décrire des problèmes visuels en texte que tu n'en aurais mis à écrire le CSS toi-même.
Le problème fondamental : les outils de code IA génèrent du code à l'aveugle. Ils produisent des tokens qui représentent du HTML et du CSS, mais ils n'ont aucun modèle visuel de ce que ces tokens vont rendre. C'est comme demander à quelqu'un de peindre un portrait les yeux bandés — il connaît la théorie de l'emplacement des yeux et du nez, mais il ne peut pas voir le résultat.
Tout développeur qui a utilisé Claude, Cursor, Copilot ou n'importe quel assistant de code IA pour du travail front-end a frappé ce mur. Le code est syntaxiquement correct. La structure est raisonnable. Mais le rendu ne correspond pas à ce que tu — ou l'IA — aviez prévu. Et le seul mécanisme de feedback, c'est toi, l'humain, qui décris des problèmes visuels avec des mots en espérant que l'IA interprète correctement ces descriptions.
La boucle multimodale d'auto-vérification de Codex brise complètement ce cycle. L'IA génère du code, le rend dans un vrai environnement de navigateur, prend une capture d'écran, et utilise son modèle de vision pour analyser le rendu visuel réel. Si quelque chose cloche — éléments qui se chevauchent, mises en page cassées, composants mal alignés — elle voit le problème de la même façon que toi et le corrige avant même que tu aies besoin de le décrire.
Ce n'est pas une amélioration incrémentale de la génération de code. C'est la fermeture de la boucle de feedback qui était ouverte depuis l'apparition des premiers assistants de code IA. Et les implications pratiques sont plus importantes que ce que la plupart des gens réalisent.
Regarder Codex construire un globe 3D à partir d'un croquis sur tableau blanc
La démo qui m'a convaincu de prendre ça au sérieux impliquait une application de voyage appelée Wonderlust. L'équipe a esquissé des idées sur un tableau blanc physique — des dessins grossiers, des étiquettes manuscrites, des flèches reliant les concepts. Quelqu'un a pris une photo du tableau blanc et l'a donnée directement à Codex comme prompt.
Ce qui s'est passé ensuite a pris environ huit minutes.
Codex a analysé le croquis. Il a identifié les éléments d'interface prévus : un globe 3D pour découvrir des destinations de voyage, des épingles cliquables sur le globe pour des lieux spécifiques, un panneau de détails qui glisse quand tu tapes sur une épingle, et une navigation au clavier pour faire tourner le globe. À partir d'une photo d'un dessin sur tableau blanc.
Puis il a commencé à coder. Three.js pour le rendu du globe. Des animations CSS pour une rotation fluide. Des gestionnaires d'événements pour les interactions au clic et les entrées clavier. Une mise en page responsive qui adapte la taille du globe et la position du panneau de détails pour les écrans mobiles.
Mais voici la partie que les démos passent généralement sous silence et la partie qui compte le plus : après avoir généré l'implémentation initiale, Codex a ouvert un navigateur, rendu l'application, et pris une capture d'écran. Le globe était là. Les épingles étaient placées. Mais le panneau de détails était partiellement caché derrière le globe sur les viewports de largeur tablette. Codex a vu ça dans la capture d'écran, identifié le conflit de z-index et de positionnement, ajusté le CSS, et refait le rendu. La deuxième capture montrait une mise en page propre.
Il a détecté un bug de responsive design que moi — un développeur qui construit des mises en page responsives régulièrement — j'aurais pu rater au premier passage. Pas parce que je suis négligent, mais parce que tester chaque largeur de viewport manuellement est fastidieux et on prend tous des raccourcis. Codex ne prend pas de raccourcis parce que la vérification visuelle fait partie de sa boucle automatisée, pas une étape manuelle qu'il peut sauter.
L'implémentation Three.js en elle-même était solide. Pas optimisée pour la production — elle chargeait la bibliothèque Three.js complète plutôt que de faire du tree-shaking pour ne garder que les modules nécessaires — mais fonctionnellement complète avec un éclairage correct, une interpolation de rotation fluide, et un positionnement correct des épingles sur la surface du globe. Le genre de code qu'un développeur front-end de niveau intermédiaire produirait un bon jour, livré en quelques minutes à partir d'une photo de tableau blanc.
Je veux être précis sur ce qui m'a impressionné et ce qui ne m'a pas impressionné. La vitesse de génération de code est impressionnante mais pas unique — Claude et GPT-4o peuvent aussi générer du code Three.js rapidement. L'entrée multimodale (croquis tableau blanc vers code) est impressionnante mais existe sous diverses formes. Ce qui est véritablement nouveau, c'est la boucle fermée : générer, rendre, voir, corriger. C'est cette boucle qui transforme une "démo impressionnante" en "workflow réellement utile."
Le Journal de Voyage : là où l'auto-vérification brille vraiment
La deuxième partie de la démo a construit un écran Journal de Voyage — un tableau de bord montrant des statistiques de voyage avec des checklists interactives, des diagrammes circulaires, et un suivi de progression gamifié. Continents visités, photos prises, plats locaux goûtés, ce genre de choses.
C'est exactement le type d'interface que les outils de code IA ratent habituellement. Les tableaux de bord ont des mises en page complexes avec de multiples composants de visualisation de données, des tailles de cartes variées, une typographie mixte, et une hiérarchie d'information dense. Réussir une carte, c'est facile. Faire coexister harmonieusement douze cartes sur un seul écran, avec un espacement correct et un rythme visuel cohérent sur desktop et mobile ? C'est là que les mises en page générées par IA commencent typiquement à ressembler à un tiroir fourre-tout.
Codex a généré la mise en page initiale du tableau de bord, l'a rendue, et a pris une capture d'écran. Le premier passage présentait deux problèmes visibles : une légende de diagramme circulaire était tronquée sur mobile, et l'espacement entre les cartes de statistiques était incohérent (certaines avaient des écarts de 16px, d'autres de 24px). Codex a identifié les deux problèmes à partir de la capture d'écran, corrigé le débordement de la légende avec une mise en page flexible à retour à la ligne, standardisé l'espacement des cartes, et refait le rendu.
La deuxième capture d'écran était propre. Espacement cohérent, légendes lisibles, hiérarchie correcte. Deux problèmes visuels détectés et corrigés en moins d'une minute, sans aucune intervention humaine.
J'ai délibérément testé si l'auto-vérification était authentique ou théâtrale en donnant à Codex un prompt de tableau de bord plus complexe pour l'un de mes propres projets. Je lui ai demandé de construire un tableau de bord de visualisation de données à partir d'un croquis grossier que j'avais dessiné sur mon iPad — volontairement brouillon, avec des annotations qui se chevauchent et des tailles d'éléments ambiguës.
La première mise en page générée avait trois problèmes que je pouvais repérer : un graphique à barres était trop large pour son conteneur, un en-tête était mal aligné avec la grille, et une section défilable ne défilait pas réellement. L'auto-vérification de Codex en a détecté deux sur trois. Il a corrigé la largeur du graphique et l'alignement de l'en-tête. Il a raté le problème de défilement — la capture d'écran montrait la section à sa hauteur par défaut, ce qui ne révélait pas le problème de débordement.
Deux sur trois, ce n'est pas parfait. Mais deux sur trois détectés automatiquement, c'est deux choses de moins que j'ai dû décrire en texte en espérant que l'IA comprenne. C'est un vrai gain de temps, et il se cumule à chaque tâche front-end.
Des croquis sur serviette aux maquettes Figma : la flexibilité des entrées
L'une des capacités les plus pratiques de Codex est l'éventail d'entrées visuelles qu'il accepte. J'ai testé quatre niveaux de fidélité d'entrée pour voir comment la qualité du rendu évoluait.
Croquis sur tableau blanc — grossier, dessiné à la main, proportions ambiguës. Codex a interprété correctement la disposition générale et les types d'éléments mais a pris ses propres décisions concernant l'espacement, le dimensionnement et le style. Le résultat était fonctionnel mais nécessitait un raffinement significatif pour correspondre à une vision de design spécifique. Bon pour du prototypage rapide quand tu ne te soucies pas de la précision au pixel.
Dessin iPad avec annotations — plus propre que le tableau blanc, avec des sections codées par couleur et des étiquettes textuelles précisant des choses comme "cette section défile" ou "cartes en grille 3 colonnes." Codex a suivi les annotations fidèlement environ 80% du temps. Le codage couleur l'a aidé à distinguer les différentes sections de l'interface. Un résultat nettement meilleur que le croquis brut sur tableau blanc.
Capture d'écran de l'interface d'un concurrent — j'ai donné à Codex une capture d'écran d'un tableau de bord d'un produit SaaS et lui ai demandé de "construire quelque chose avec cette disposition mais la palette de couleurs de notre marque." La reproduction structurelle était excellente — même disposition en grille, même hiérarchie de composants, mêmes breakpoints responsives. Le style était correctement différent (il n'a pas copié les couleurs exactes ou la typographie). Ce cas d'usage — "comme ça, mais le nôtre" — est probablement l'entrée multimodale la plus utile en pratique pour de vrais projets.
Export de maquette Figma — un vrai fichier de design exporté en PNG. C'est ce qui a produit le résultat de la plus haute fidélité. Codex a reproduit la mise en page, l'espacement et la structure des composants de manière fidèle. La boucle d'auto-vérification a détecté des écarts mineurs — une carte 2px plus large que la maquette, une graisse de police qui ne correspondait pas — et les a auto-corrigés.
Le constat est clair : de meilleures entrées produisent de meilleurs résultats. Ça semble évident, mais l'implication pratique est importante. Tu n'as pas besoin d'un fichier Figma peaufiné pour obtenir un résultat utile de Codex. Un croquis rapide sur tableau blanc ou tablette t'amène à un prototype fonctionnel plus vite qu'une description textuelle ne le pourra jamais. L'entrée visuelle élimine la couche de traduction entre ce que tu vois dans ta tête et ce que tu peux articuler en mots.
Pour mon workflow, le point idéal est le dessin annoté sur iPad. Assez détaillé pour que Codex comprenne mon intention. Assez brut pour que je passe trente secondes à le dessiner plutôt que trente minutes dans Figma. La boucle d'auto-vérification comble les écarts entre mon croquis approximatif et une implémentation propre.
Visualisation de données : là où Codex excelle discrètement
La démo que j'ai trouvée la plus surprenante n'était pas le globe 3D tape-à-l'oeil — c'était la section visualisation de données. Codex a ingéré un jeu de données brut de courses de taxi de New York City (des millions de lignes) et a généré un tableau de bord interactif avec des graphiques, des filtres et des visualisations cartographiques.
Donner des données brutes et récupérer un tableau de bord analytique fonctionnel, ce n'est pas nouveau. Ce qui est nouveau, c'est que Codex a vérifié visuellement ses propres visualisations. Quand un graphique à barres s'est affiché avec des labels d'axe coupés, l'auto-vérification l'a détecté. Quand une couche de carte était partiellement transparente et difficile à lire sur un fond clair, l'auto-vérification a ajusté l'opacité.
J'ai reproduit ça avec un jeu de données client — des données de ventes anonymisées sur plusieurs régions et catégories de produits. J'ai donné le CSV à Codex et demandé un tableau de bord exploratoire. Le premier rendu avait un graphique où le label de l'axe Y entrait en collision avec le titre du graphique. L'auto-vérification l'a détecté, ajouté du padding, et refait un rendu propre.
Le cas d'usage de la visualisation de données est celui où la boucle d'auto-vérification apporte la valeur la plus constante, parce que le rendu de graphiques a tellement de modes de défaillance visuels subtils : labels qui se chevauchent, légendes tronquées, couleurs trop similaires pour être distinguées, infobulles qui débordent de leur conteneur. Ce sont des problèmes difficiles à décrire en texte mais instantanément évidents visuellement. Une IA qui s'auto-vérifie les détecte de la même façon qu'un humain — en regardant.
Pour quiconque construit régulièrement des tableaux de bord ou des interfaces riches en données, cette capacité à elle seule justifie d'évaluer Codex.
L'intégration Playwright qui relie le tout
Sous le capot, Codex utilise Playwright — le framework d'automatisation de navigateur — pour rendre les interfaces générées et capturer des captures d'écran. Ce n'est pas qu'un détail d'implémentation. Ça signifie que Codex peut interagir avec l'application générée comme le ferait un utilisateur : cliquer sur des boutons, remplir des formulaires, défiler, redimensionner le viewport.
Les développeurs front-end qui utilisent Codex avec Playwright obtiennent un pipeline de validation visuelle continue. Générer du code → rendre dans un vrai navigateur → capturer des captures d'écran à plusieurs largeurs de viewport → analyser chaque capture → corriger les problèmes → répéter. Le cycle entier est automatisé.
J'ai mis en place une version de ce pipeline pour l'un de mes projets. Codex génère un composant, Playwright le rend à trois largeurs de viewport (375px mobile, 768px tablette, 1440px desktop), Codex analyse les trois captures d'écran, et corrige les problèmes responsives sur tous les breakpoints. Les tests de responsive qui se font habituellement comme une réflexion après coup deviennent partie intégrante du processus de génération.
L'impact pratique : je n'ai pas redimensionné manuellement une fenêtre de navigateur pour tester le responsive sur un seul composant généré par Codex cette semaine. Chaque problème de responsive a été détecté par l'analyse automatisée des captures d'écran. Pas tous les problèmes de responsive — certains cas limites impliquant du contenu dynamique et des container queries sont passés entre les mailles — mais les plus évidents qui gaspillent le plus de temps de test manuel.
Là où Codex échoue (et il échoue)
C'est l'heure de la section honnête. Parce que les démos sont conçues pour impressionner, et la réalité est plus nuancée que les démos.
L'auto-vérification n'est pas exhaustive. Codex prend une capture d'écran à un moment donné, à une largeur de viewport donnée (sauf si tu configures le pipeline Playwright pour plusieurs). Il ne teste pas les états de survol, les animations en cours de transition, les retours de validation de formulaire, ou les états interactifs qui nécessitent des actions utilisateur spécifiques pour être déclenchés. Un bouton qui a l'air parfait dans son état par défaut pourrait avoir un état de survol cassé que la capture d'écran ne capte jamais.
L'analyse visuelle a une limite de résolution. Codex peut détecter un label de graphique qui est manifestement coupé. Il peine avec les problèmes plus subtils : une graisse de police à 400 quand elle devrait être à 500, une couleur à #333 quand le cahier des charges indique #2D2D2D, une hauteur de ligne légèrement trop serrée mais pas manifestement incorrecte. La capacité du modèle de vision à détecter le "pas tout à fait correct" est sensiblement plus faible que l'oeil d'un designer humain.
La qualité du code passe au second plan derrière la justesse visuelle. Codex optimise pour "est-ce que ça a l'air correct sur la capture d'écran ?" Cela signifie parfois qu'il génère des bidouilles CSS — du positionnement absolu là où du flexbox serait plus propre, des valeurs en pixels codées en dur là où des unités relatives seraient plus maintenables — parce que ces approches produisent le rendu visuel correct plus rapidement. Le code fonctionne et a l'air bien, mais un développeur senior refactoriserait la moitié pour la maintenabilité.
La gestion d'état complexe est encore faible. Les démos montrent principalement des interfaces statiques ou légèrement interactives. Quand j'ai demandé à Codex de construire un formulaire multi-étapes avec validation, champs conditionnels et états d'erreur, l'auto-vérification n'a vérifié que l'état initial. Il n'a pas testé visuellement l'état d'erreur, n'a pas vérifié que les champs conditionnels apparaissaient correctement, et n'a pas détecté un décalage de mise en page qui se produisait quand les messages de validation apparaissaient. La boucle fermée fonctionne pour la vérification visuelle statique. Elle ne gère pas encore le spectre complet des tests d'états interactifs.
La performance n'est pas prise en compte. Codex a généré un globe Three.js parfaitement fonctionnel. Il a aussi chargé 500 Ko de Three.js non minifié pour un composant qui utilisait peut-être 10% de la bibliothèque. L'auto-vérification visuelle confirme que le rendu est correct. Elle ne dit rien sur la taille du bundle, les performances de rendu ou l'utilisation mémoire. Tu as toujours besoin d'un humain (ou d'un autre outil) pour l'optimisation des performances.
Ce ne sont pas des détails insignifiants. C'est la différence entre une démo et un workflow de production. La boucle multimodale de Codex est véritablement impressionnante pour le prototypage, l'implémentation initiale, et la détection des bugs visuels évidents. Ce n'est pas encore un remplacement des pratiques rigoureuses de développement front-end.
Ce que ça signifie concrètement pour le développement front-end
Voici le changement que j'ai opéré dans mon propre workflow après une semaine avec les capacités multimodales de Codex.
Je n'écris plus le premier jet de code front-end à la main pour les nouvelles fonctionnalités. Esquisser l'interface (iPad, trente secondes), la donner à Codex avec une description textuelle de la fonctionnalité, le laisser générer et auto-vérifier l'implémentation initiale. Ensuite je passe mon temps là où ça compte vraiment : refactoriser le CSS généré pour la maintenabilité, ajouter une gestion d'état correcte, tester les flux interactifs, et optimiser les performances.
Mon rôle est passé de "écrire le code" à "architecturer le code et affiner le résultat." Le premier brouillon — qui est la partie la plus fastidieuse du travail front-end, se battre avec le CSS de mise en page et la structure de base des composants — est maintenant automatisé et vérifié visuellement.
Les gains de temps sont difficiles à quantifier précisément parce que chaque composant est différent. Mais en tendance : des tâches qui prenaient quatre-vingt-dix minutes d'implémentation initiale prennent maintenant environ vingt minutes de génération plus trente minutes de raffinement. Environ la moitié du temps total, avec un meilleur point de départ.
Ce calcul ne tiendra pas pour chaque projet ou chaque développeur. Si ton travail front-end est fortement interactif et piloté par l'état, la génération couvre un plus petit pourcentage de l'effort total. Si ton travail est orienté mise en page avec beaucoup de cartes, grilles, tableaux de bord et composants d'affichage de données — le type de travail d'interface dont beaucoup d'applications réelles ont réellement besoin — la couverture est substantielle.
La plus grande question n'est pas de savoir si Codex est utile aujourd'hui. Il l'est clairement, avec des réserves. La question est ce qui se passe quand la boucle d'auto-vérification s'améliore : analyse visuelle à plus haute résolution, tests d'états interactifs, sensibilité aux performances, vérifications d'accessibilité. Chaque amélioration côté vérification rend la génération plus fiable.
On regarde en temps réel la boucle de feedback entre génération de code IA et vérification de code IA se resserrer. Et le point d'aboutissement logique de ce resserrement — une IA qui génère, vérifie et itère jusqu'à la qualité production sans intervention humaine — n'est pas encore là. Mais on peut le voir d'ici. Tu peux voir la trajectoire.
Les développeurs qui apprennent à travailler avec cette boucle maintenant — en la dirigeant, en affinant son résultat, en comblant les lacunes qu'elle ne peut pas encore combler — auront un avantage significatif quand elle sera assez bonne pour combler la plupart de ces lacunes toute seule.
Ce changement n'arrive pas l'année prochaine. Des parties sont déjà là. Je fixe un globe Three.js sur mon écran qui était un croquis sur tableau blanc il y a vingt minutes, construit par une IA qui a vérifié son propre travail et corrigé ses propres erreurs.
Qu'est-ce que tu vas construire quand ton assistant de code pourra voir ?
Travaillons ensemble
Tu cherches à construire des systèmes IA, automatiser des workflows, ou faire passer ton infrastructure tech à l'échelle ? Je serais ravi de t'aider.
- Fiverr (builds personnalisés et intégrations) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design et branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
