Simon Willison a placé Blender sous le contrôle de Codex, mais le rendu ne raconte que la moitié de l’histoire

Simon Willison a transformé une seule invite en une scène Blender modifiable en 2 minutes et 39 secondes, sans jamais utiliser l’application par son interface visuelle. Son agent de codage a généré du Python, lancé Blender sur macOS, créé un pélican à vélo et enregistré le résultat dans un fichier .blend natif.

Cette distinction est importante. Il ne s’agissait pas d’un autre système de conversion de texte en image produisant une illustration aplatie, difficile à retoucher par la suite. L’agent a manipulé une application créative programmable, laissant derrière lui du code source et des objets 3D structurés qu’une personne pouvait examiner, modifier, restituer ou animer.

L’expérience a également mis en évidence le véritable enjeu autour des agents de codage. La séparation importante ne se situe plus entre l’écriture de code et la création de médias visuels. Elle oppose les logiciels qui proposent des contrôles programmables fiables à ceux qui restent prisonniers d’opérations manuelles via l’interface.

L’exemple de Willison est concis, fantaisiste et fondé sur l’expérience d’un seul utilisateur. Il ne constitue pas un benchmark contrôlé. Il offre néanmoins un aperçu utile de la manière dont les agents peuvent aller au-delà des dépôts de code sans attendre des intégrations sur mesure de la part de chaque développeur d’applications.

Simon Willison a fait de Blender une cible pour les agents de codage

L’événement notable n’était pas l’image du pélican. C’était le fait que Codex traite une application de bureau installée comme un outil de développement exécutable.

Dans un billet du 5 septembre, Simon Willison a décrit son utilisation de ChatGPT Codex sur son Mac pour contrôler Blender. Sa demande initiale était directe : utiliser l’application Blender installée pour restituer un pélican à vélo.

L’agent a trouvé une voie via l’exécutable en ligne de commande de Blender et son interface Python. Willison a ensuite fourni la commande plus explicite /Applications/Blender.app/Contents/MacOS/Blender --background --python scene.py, qui lance Blender sans son interface habituelle et exécute un script.

Le mode arrière-plan signifie que Blender fonctionne sans ouvrir son espace de travail graphique. Cela le rend adapté au rendu automatisé, aux tâches serveur, aux pipelines de test et aux opérations contrôlées par un agent.

Willison a indiqué que la première invite avait produit un projet .blend et un script Python après 2 minutes et 39 secondes. Il a ensuite demandé « un arrière-plan et beaucoup de panache », obtenant une autre version après 3 minutes et 51 secondes.

Une dernière demande visant à rendre le travail « beaucoup, beaucoup meilleur » a pris 5 minutes et 59 secondes. La scène de parade côtière qui en a résulté comprenait une promenade en bois, l’océan, un coucher de soleil, des cabanes de plage, des palmiers, des fleurs et un pélican plus détaillé.

La séquence complète, les invites, les fichiers de sortie et les temps d’exécution figurent dans l’expérience Blender de Willison. Ce relevé public rend l’exemple plus instructif qu’une image soignée publiée sans l’historique de sa construction.

Les fichiers générés montrent également ce que l’agent a réellement fait. Il n’a pas appelé un générateur d’images caché avant de coller le résultat dans Blender. Il a écrit des instructions de construction de scène via bpy, le module Python de Blender permettant d’accéder aux objets, matériaux, caméras, lumières, géométries, paramètres de rendu et données du projet.

Willison a publié le script final, qui compte 128 lignes dans sa dernière révision. Le code source de la scène crée et modifie des éléments individuels tels que le vélo, l’oiseau, les planches de la promenade, les nuages, les cabanes de plage, le voilier et le panier tressé.

Ces éléments de preuve précisent l’affirmation. L’expérience montre qu’un agent de codage, une configuration de modèle et une installation locale de Blender ont réalisé une scène stylisée précise. Elle n’établit pas une fiabilité générale pour des travaux 3D arbitraires.

Le flux de travail a néanmoins franchi une frontière importante. Une instruction conversationnelle est devenue du code, le code a contrôlé une application de bureau mature, et l’application a produit à la fois un projet modifiable et un rendu final.

Pourquoi Blender sur macOS était prêt pour ce moment

Blender fournissait déjà la surface d’automatisation, tandis que l’agent de codage assurait la traduction, l’itération et l’exécution.

Les agents de codage fonctionnent au mieux lorsqu’ils peuvent inspecter un système, écrire un petit programme, l’exécuter et évaluer un résultat observable. Blender prend en charge chacune de ces étapes sans nécessiter de plugin d’agent spécial.

Son API Python expose les objets de la scène sous forme de données programmables. Un script peut créer des maillages, ajuster des coordonnées, attribuer des matériaux, positionner des caméras, configurer des lumières, enregistrer des fichiers de projet et lancer le rendu.

L’application accepte également des arguments de ligne de commande sur macOS. Une fois l’application de bureau complète installée, son exécutable interne peut être lancé depuis le terminal. L’agent de codage considère donc Blender comme un autre outil disponible sur la machine locale.

Cela modifie le problème d’intégration. Un développeur n’a pas besoin d’attendre un « connecteur Blender » dédié qui convertit un ensemble limité de commandes en langage naturel en actions d’interface. L’agent peut plutôt utiliser les mêmes mécanismes de script et de ligne de commande déjà accessibles aux artistes techniques.

Cette approche correspond au fonctionnement de Codex dans un environnement local. Selon la documentation de Codex, l’agent peut inspecter des fichiers, utiliser un terminal, modifier du code et exécuter des commandes dans les limites des autorisations accordées par l’utilisateur.

Blender apporte une exécution déterministe au niveau de l’application. Le modèle de langage apporte un planificateur imparfait mais flexible qui convertit une intention en Python. Aucun des deux composants ne fournit seul l’ensemble du flux de travail.

Le moment est important car les agents de codage actuels peuvent maintenir des séquences plus longues que de simples systèmes d’autocomplétion. Ils peuvent créer un script, l’exécuter, relever une erreur, réviser le fichier et répéter le processus tout en préservant l’état du projet.

Un chatbot conventionnel pourrait produire un exemple de Python pour Blender qu’un utilisateur devrait copier, déboguer et exécuter manuellement. Un agent peut combler ce fossé d’exécution en gérant ces étapes dans la même session de travail.

La sortie visuelle offre également à l’agent et à l’utilisateur un point de contrôle concret. Un rendu peut révéler plus rapidement que la lecture de chaque coordonnée du script généré des erreurs de cadrage, une géométrie manquante, un éclairage médiocre ou une composition surchargée.

Cependant, un retour visuel ne garantit pas un jugement visuel. Un agent peut parvenir à restituer une image contenant encore une anatomie maladroite, une échelle incohérente, des objets qui s’interpénètrent ou une composition faible. La réussite de l’exécution et la réussite artistique restent deux critères distincts.

C’est pourquoi l’application locale est importante. Blender préserve la géométrie et les matériaux modifiables après la génération initiale. Un artiste humain peut corriger directement les défauts au lieu de demander au modèle de régénérer une image opaque depuis zéro.

Pour de nombreuses tâches créatives, la possibilité de modification a plus de valeur qu’un premier résultat saisissant. Elle permet aux équipes de conserver les éléments approuvés, d’isoler les erreurs et de ne changer que les parties nécessitant du travail.

Le véritable enjeu oppose les API à l’automatisation de l’interface

L’expérience de Willison favorise les applications dotées de modèles internes scriptables par rapport aux flux de travail qui reposent sur des clics simulés.

Les agents d’utilisation d’ordinateur contrôlent généralement les logiciels en interprétant des captures d’écran et en manipulant une souris ou un clavier. Cette voie offre une vaste compatibilité, car presque toutes les applications de bureau disposent d’une interface.

Elle introduit aussi de l’incertitude. Les boutons se déplacent, des boîtes de dialogue interrompent la séquence, le focus de la fenêtre change, et l’agent doit déduire l’état à partir de pixels. Un clic manqué peut réorienter silencieusement l’ensemble du flux de travail.

L’API Python de Blender évite une grande partie de cette ambiguïté. L’agent peut s’adresser à un objet, une caméra, un matériau ou un paramètre de rendu par des opérations nommées. Le script résultant devient un compte rendu inspectable de ses actions.

Il ne s’agit pas d’un déterminisme parfait. Le code généré peut contenir des appels non valides, des paramètres mal choisis ou des erreurs logiques. Les versions de Blender peuvent également modifier le comportement de l’API.

Pourtant, un échec du code laisse généralement de meilleures traces qu’un échec de l’interface. L’utilisateur peut conserver le script, examiner une exception, comparer des révisions et relancer la même commande.

Le fichier .blend ajoute une autre couche de vérifiabilité. Il contient la scène structurée plutôt que ses seuls pixels finaux. Les utilisateurs peuvent ouvrir le projet et examiner ce que l’agent a créé.

Le script final de Willison illustre cette structure. Il place programmatiquement des planches de promenade, construit des feuilles de palmier, génère des lignes d’écume et ajoute des éléments individuels au panier. Il s’agit de composants adressables, et non d’une seule image fusionnée.

Cela procure un avantage pratique pour les invites itératives. « Ajouter un arrière-plan » peut modifier la scène existante sans supprimer le vélo et le pélican. « Améliorer le résultat » peut affiner des composants sélectionnés tout en conservant le travail antérieur.

La faiblesse est que le langage vague oblige toujours le modèle à faire des choix de conception non exprimés. « Mieux » peut vouloir dire davantage de détails, une composition plus claire, un réalisme accru ou simplement plus d’éléments décoratifs.

Le résultat de Willison penchait vers une illustration côtière soignée, à l’allure de jouet. Un autre utilisateur aurait pu rechercher du réalisme physique ou un style éditorial dépouillé. L’agent ne peut pas déduire de manière fiable toutes les préférences non formulées.

Cela crée une nouvelle responsabilité pour les fournisseurs de logiciels créatifs. Les produits disposant d’interfaces de script documentées, de formats de fichiers stables et d’une exécution sans interface sont plus faciles à utiliser pour les agents et à auditer pour les utilisateurs.

Les applications qui n’exposent que des contrôles visuels placent l’agent dans une imitation fragile de l’interaction humaine. Les applications qui exposent des commandes structurées permettent à l’agent de travailler au plus près de l’état sous-jacent du programme.

Blender est particulièrement bien placé parce qu’il combine l’édition visuelle, l’automatisation Python, le rendu, l’animation et les fichiers de projet natifs. Cette combinaison en fait à la fois un outil de production et un environnement d’exécution.

Le même principe s’étend au-delà des graphismes 3D. Les monteurs vidéo, les applications de conception, les outils de données et les stations de travail audio numérique deviennent de meilleures cibles pour les agents lorsque leurs projets peuvent être créés et modifiés par le code.

Cela ne rend pas les interfaces graphiques obsolètes. Cela change leur rôle. L’agent peut prendre en charge la construction répétitive, tandis que l’interface reste l’endroit où une personne examine, corrige et assure la direction artistique du résultat.

Ce que le rendu du pélican ne prouve pas

Une démonstration réussie établit la faisabilité d’un flux de travail, pas une production créative fiable.

Willison a présenté une expérience personnelle plutôt qu’un benchmark. Il n’y a pas eu d’essais répétés, d’évaluateurs indépendants, d’invites contrôlées ni de comparaisons entre modèles et versions de Blender.

Les temps rapportés constituent des observations utiles, mais ils ne doivent pas devenir des chiffres de performance généralisés. Le temps de rendu dépend du Mac, de la complexité de la scène, du moteur de rendu, de la résolution et du nombre de tentatives de l’agent.

L’exemple a également bénéficié d’un sujet indulgent. Un pélican stylisé sur un vélo peut supporter une anatomie exagérée et des proportions ludiques. La visualisation architecturale, la conception de produits, l’animation médicale et les travaux d’ingénierie imposent des exigences de précision bien plus strictes.

Une scène peut sembler convaincante tout en restant techniquement médiocre. La topologie du maillage peut être difficile à modifier. Les matériaux peuvent se comporter de manière incohérente sous différents éclairages. Des objets pourraient s’interpénétrer en dehors de l’angle de caméra sélectionné.

Rien ne prouve non plus ici que l’agent ait optimisé la géométrie pour l’animation, le rendu en temps réel ou l’exportation en aval. Une image fixe ne teste la scène que depuis un point de vue et à un instant donnés.

Le script final construit de nombreux éléments visuels de façon procédurale. Cela donne aux utilisateurs un artefact traçable, mais le code procédural généré peut devenir difficile à maintenir s’il manque d’une organisation claire.

Des invites successives peuvent aggraver ce problème. Un agent peut ajouter de nouvelles opérations au lieu de repenser une fondation instable. Le projet peut s’améliorer visuellement tout en devenant plus fragile dans sa construction interne.

La sécurité mérite une attention égale. Un agent de programmation capable d’exécuter Blender peut également exécuter du Python généré avec les autorisations disponibles dans son environnement. Les utilisateurs doivent examiner les scripts inconnus et limiter l’accès aux fichiers sensibles.

L’exécutable Blender lui-même n’est pas le risque. Le risque consiste à accorder au code généré un accès étendu sans comprendre ce qu’il lit, écrit, télécharge ou lance.

Les agents locaux créent également une frontière de confiance plus complexe que les générateurs d’images hébergés. Ils peuvent accéder aux répertoires de projet, aux images de référence, aux scripts, aux rendus et à d’autres ressources sur le même ordinateur.

Les équipes ont besoin de règles explicites sur les répertoires que l’agent peut utiliser et les commandes nécessitant une approbation. Ces contrôles deviennent plus importants lorsque les projets créatifs incluent des designs non publiés ou des éléments fournis par des clients.

Les licences introduisent une préoccupation différente. Blender est distribué sous la GNU General Public License, tandis que la production artistique reste généralement la propriété de son créateur. La licence Blender ne résout pas les questions de droits liées au code généré, aux données d’entraînement, aux actifs tiers ou aux styles copiés.

Les utilisateurs doivent toujours suivre la provenance des textures, des modèles, des images de référence et des autres entrées. Une sortie modifiable est plus facile à examiner qu’une image aplatie, mais la possibilité de modification n’établit pas une provenance irréprochable.

Le contrôle qualité reste donc un travail humain. Un artiste expérimenté peut repérer des défauts anatomiques, de composition, d’éclairage et de production qu’un agent de programmation généraliste pourrait négliger.

L’interprétation la plus solide reste modeste. Le test démontre qu’un agent de programmation peut orchestrer une véritable application créative et produire un point de départ utile. Il ne montre pas que la direction artistique est devenue automatique.

Les agents de programmation obtiennent plus qu’un générateur d’images

Le changement plus profond réside dans la création d’un système de production réutilisable plutôt que d’un seul actif visuel.

Willison a terminé son expérience en demandant à Codex de créer une compétence décrivant comment utiliser l’application Blender installée. Une compétence est un ensemble d’instructions opérationnelles qui aide un agent à répéter un flux de travail spécialisé.

Cette dernière étape a transformé une session réussie en connaissances réutilisables. Les futures demandes n’avaient plus besoin de redécouvrir le chemin de l’exécutable, la commande du mode arrière-plan ou l’approche de base pour écrire des scripts de scène.

Cela compte car la productivité des agents dépend souvent des procédures conservées. Un modèle peut être capable de trouver une solution à chaque fois, mais cette redécouverte répétée fait perdre du temps et introduit des variations.

Une compétence enregistrée peut documenter la commande pour lancer Blender, les emplacements de fichiers attendus, les conventions de rendu et les étapes de validation. Elle peut aussi définir à quel moment l’agent doit enregistrer des fichiers .blend intermédiaires.

La leçon sous-jacente est familière aux équipes d’ingénierie. Un résultat ponctuel devient plus précieux lorsque son processus est consigné, révisé et réutilisé.

Les équipes peuvent appliquer le même schéma aux rendus de marque, aux maquettes de produits, aux scènes de storyboard ou aux visualisations de données récurrentes. L’agent construit dans un pipeline documenté au lieu d’improviser pour chaque projet.

Un bon flux de travail réutilisable séparerait les fichiers sources générés des sorties rendues. Il conserverait l’historique des invites, nommerait les objets de scène de manière cohérente et préserverait des points de contrôle avant les révisions majeures.

Ces pratiques facilitent l’examen du travail des agents. Elles réduisent également les dégâts causés par une demande de suivi vague qui modifie trop d’éléments.

Le dépôt public de Willison conserve une partie de cet historique. Il comprend des fichiers .blend successifs, des scripts Python et une transcription exportée, permettant aux lecteurs d’examiner le chemin entre la première demande et le rendu final.

Cet historique est plus précieux que l’image finale seule. Il montre où l’agent a utilisé du code, comment la scène s’est étendue et quels artefacts sont restés modifiables.

Les organisations qui explorent des flux de travail similaires devraient considérer les invites, les scripts, les fichiers de projet et les notes de révision comme des connaissances techniques liées. Une base de connaissances d’ingénierie consultable peut préserver les raisons de la réussite d’un flux de travail, et pas seulement l’emplacement de ses fichiers.

Cette approche modifie également l’économie des petites expérimentations créatives sans exiger de comparaison de prix. Un développeur peut tester un concept visuel avant de faire intervenir un spécialiste pour une production détaillée.

Cela ne devrait pas être présenté comme le remplacement d’un artiste 3D. Cela déplace le point de départ. Les artistes peuvent recevoir une scène structurée sommaire plutôt qu’un paragraphe, tandis que les développeurs peuvent explorer des idées qui étaient auparavant abandonnées avant le prototypage.

Le transfert devient particulièrement utile lorsque les objets générés sont clairement nommés et regroupés. Un professionnel peut alors remplacer une géométrie faible, ajuster les matériaux ou reconstruire le rig sans devoir recréer toute la scène.

Les agents de programmation peuvent également relier Blender aux outils environnants. Ils peuvent préparer les données d’entrée, générer des scripts de scène, organiser les rendus et appeler des utilitaires multimédias pour traiter les sorties.

Willison a noté que les agents peuvent rendre des séquences d’images et les assembler avec FFmpeg. Cela étend le schéma d’une image fixe à un pipeline d’animation automatisé, bien que son exemple de pélican se soit concentré sur la scène rendue.

La valeur plus large réside dans l’orchestration. L’agent n’a pas besoin de devenir le meilleur modélisateur, moteur de rendu ou encodeur vidéo. Il doit coordonner des outils spécialisés tout en préservant des artefacts que les humains peuvent examiner.

Ce qu’il faut surveiller après le test Blender de Simon Willison

Trois signaux détermineront si ce schéma dépasse le stade d’une impressionnante démonstration personnelle.

Le premier signal est la reproductibilité entre les modèles, les machines et les versions de Blender. D’autres utilisateurs devraient pouvoir fournir des invites comparables et obtenir des scripts valides, des fichiers de projet modifiables et des rendus réussis.

Les tests répétés devraient suivre bien plus que la simple apparition d’une image. Ils devraient examiner les taux d’erreur, les nouvelles tentatives, l’organisation des scènes, la cohérence des rendus et la capacité du projet à résister à des modifications ultérieures.

Si ces résultats restent stables dans différents environnements, l’argument en faveur des agents de programmation pour Blender deviendra plus solide. Si la réussite dépend d’une configuration de modèle particulière et d’invites de sauvetage soigneusement formulées, le flux de travail restera expérimental.

Le deuxième signal est de savoir si les professionnels de la création adoptent les scènes générées par des agents comme actifs de départ exploitables. Leur jugement compte car ils peuvent évaluer la topologie, les matériaux, l’éclairage, le nommage, la composition et la compatibilité en aval.

Un flux de travail professionnel doit tolérer les révisions. La scène doit rester compréhensible après plusieurs invites, se transférer proprement entre les personnes et prendre en charge des changements allant au-delà du point de vue initial de la caméra.

Des preuves d’artistes affinant des fichiers .blend générés renforceraient l’affirmation selon laquelle les agents peuvent participer à la production. Un flux de rendus attrayants mais jetables l’affaiblirait.

Le troisième signal est la manière dont les éditeurs de logiciels créatifs améliorent l’accès programmable. Blender expose déjà une interface Python mature et une exécution sans interface graphique. D’autres applications pourraient répondre par de meilleurs scripts, des API de projet structurées, une documentation spécifique aux agents ou des modèles d’autorisations plus sûrs.

Si les éditeurs investissent dans ces surfaces, la concurrence s’éloignera du simple contrôle d’interface. Les agents exploiteront de plus en plus les applications au moyen de commandes explicites et d’un état inspectable.

Si les éditeurs privilégient les interfaces fermées, les agents continueront de s’appuyer sur l’interprétation de captures d’écran et des clics simulés. Cette voie peut couvrir davantage de logiciels, mais elle reste plus difficile à reproduire et à auditer.

L’exemple de Simon Willison offre aujourd’hui aux développeurs un test pratique. Choisissez une scène délimitée, conservez chaque script et révision du projet, et évaluez le résultat modifiable plutôt que le seul rendu final.

Demandez-vous si l’agent a créé un fichier qu’une autre personne peut comprendre. Vérifiez si l’invite suivante améliore la scène sans endommager le travail précédent. Examinez le Python généré avant de lui accorder un accès plus large.

Plus important encore, jugez le flux de travail à la qualité du transfert. Une délicieuse image de pélican attire l’attention, mais une scène modifiable, un script lisible et une procédure répétable créent une valeur durable.

C’est le conflit que cette expérience met en lumière. Les agents de programmation peuvent désormais aller bien au-delà des dépôts de code source, mais seuls les logiciels dotés de contrôles accessibles leur offrent un chemin fiable.

Les prochains exemples décisifs ne seront pas les plus extravagants visuellement. Ce seront ceux où un humain pourra ouvrir le projet, comprendre les choix de l’agent, corriger ses erreurs et poursuivre le travail en toute confiance.