GPT-6 Astra pour les créatifs : prompter une mission et piloter Blender

Ce qu’il faut retenir

• Astra est documenté comme un modèle de raisonnement pour le code, le computer use, la recherche et la création de documents ; il reçoit du texte et des images et produit du texte.
• Pour un logiciel 3D, le prompt doit préciser les permissions, les fichiers de sortie, les invariants, les arrêts obligatoires et le format du compte rendu.
• Trois architectures sont possibles : outil structuré ou MCP, harness d’exécution de code, puis Computer Use pour les actions d’interface et l’inspection visuelle.
• Blender expose une API Python officielle, mais aucune intégration Blender native OpenAI n’est confirmée dans les sources vérifiées : le pont doit être construit et borné par l’équipe.

Le vrai changement : le prompt devient un contrat d’exécution

Avec un modèle de raisonnement, l’enjeu n’est pas seulement d’obtenir une réponse plus intelligente. Il faut rendre l’initiative observable et réversible. Une mission bien cadrée sépare au moins six couches :

1. Le résultat attendu : par exemple un packshot 3D carré, un objet héros central et une image PNG de contrôle.
2. Le contexte disponible : version de Blender, fichier source, dossier de travail et références visuelles.
3. Les invariants : caméra, ratio, palette, objets obligatoires, nommage, format de sortie et matériau à préserver.
4. Les outils autorisés : lecture de scène, écriture d’un script, lancement de Blender, rendu, lecture du log et copie de sauvegarde.
5. Les étapes et validations : inspection, plan, exécution, rendu, comparaison, correction, validation humaine.
6. Les conditions d’arrêt : fichier absent, ambiguïté, opération destructive, erreur non résolue ou rendu qui viole un invariant.

Le prompt ne doit donc pas dire seulement « crée une belle scène dans Blender ». Il doit dire ce qui est autorisé, ce qui est interdit, ce qui doit être sauvegardé, et à quel moment l’agent doit rendre la main. Cela facilite la reprise, l’audit et la comparaison entre deux versions.

---

Les trois niveaux de contrôle d’un logiciel externe

1. Outil structuré ou MCP

Un serveur d’outils peut exposer des opérations déterministes : lire la scène, lister les objets, créer un matériau, lancer un rendu ou récupérer un rapport. C’est le niveau le plus facile à journaliser. Chaque action peut avoir un schéma, une portée et une permission distincte. Il convient aux studios qui veulent interdire les opérations destructives par construction.

2. Harness d’exécution de code

Pour Astra, la documentation Computer Use recommande l’exécution de code dans un environnement contrôlé. Dans le cas Blender, le harness écrit un fichier Python bpy, lance une copie de Blender en mode borné, récupère le code de retour, le .blend, le PNG et le log. Cette voie est plus reproductible qu’une suite de clics, à condition de conserver la version de Blender et le script exacts.

3. Computer Use et interface visuelle

Computer Use peut compléter le dispositif pour ouvrir Blender, inspecter un viewport, changer un réglage ou vérifier une vignette. C’est utile quand le signal important est visuel ou qu’une opération n’est pas encore exposée comme outil. En revanche, une action d’interface est moins déterministe qu’une opération structurée : elle doit rester bornée, confirmée pour les effets conséquents et suivie d’une vérification indépendante.

Formats acceptés, temps de travail et limites pratiques

La page modèle officielle indique que GPT-6 Astra accepte le texte et les images en entrée et renvoie du texte. L’audio et la vidéo ne sont pas pris en charge comme modalités natives de ce modèle. Cela ne signifie pas que Blender doit envoyer un fichier .blend directement au modèle : dans ce workflow, l’application extrait plutôt les informations utiles, fournit une image de contrôle ou un rapport, puis conserve les fichiers 3D dans son propre environnement.

Pour le pont Blender, on peut distinguer les formats suivants :

Objet	Format de travail	Rôle
Mission	texte ou JSON structuré	objectifs, invariants, permissions et critères d’acceptation
Scène	`.blend`	fichier de production, conservé en copie séparée
Automatisation	`.py`	script `bpy` reproductible et relisible
Preuve visuelle	`.png`	rendu de contrôle à comparer au brief
Journal	`.json` ou `.txt`	objets, version, erreurs, chemins et décisions

Il n’existe pas, dans la page modèle consultée, de durée garantie pour une mission complète. Le temps réel dépend du niveau reasoning.effort, du nombre d’appels d’outils, du temps de rendu Blender, des reprises et des validations humaines. Une tâche longue doit donc être découpée et, lorsque l’outil le permet, traitée avec des appels asynchrones. Pour une estimation de production, mesurez séparément : temps de planification, écriture du script, lancement Blender, rendu, inspection et correction.

---

Coûts : distinguer le modèle du pipeline 3D

Au 12 septembre 2026, la page de tarification OpenAI affiche pour GPT-6 Astra, en standard et sur le palier court : 10 $ par million de tokens en entrée, 1 $ par million de tokens mis en cache, 12,50 $ par million de tokens écrits en cache et 50 $ par million de tokens en sortie. Au-delà de 272 000 tokens d’entrée, la page modèle indique une tarification majorée pour la requête complète : taux d’entrée et de cache doublés, sortie à 1,5 fois le tarif standard. Batch et Flex sont affichés à 50 % du standard ; le Fast mode à 2 fois le tarif applicable.

Ce prix ne couvre pas automatiquement le reste du pipeline. Il faut aussi comptabiliser le temps machine de Blender, le stockage des .blend et des rendus, les appels éventuels à des outils, l’hébergement du harness ou du serveur MCP, ainsi que le temps humain de validation. Le bon indicateur n’est donc pas le coût d’un prompt isolé, mais le coût d’un livrable accepté : modèle + outils + rendu + corrections + contrôle humain.

Pas à pas : utiliser Astra pour piloter une mission Blender

Étape 1 — Choisir une copie de travail

Ne donnez pas à l’agent un accès implicite au fichier source. Créez un dossier de mission, copiez le .blend, fixez la version Blender et déclarez les chemins autorisés. La première règle est simple : aucun écrasement du fichier original.

Étape 2 — Écrire le brief en invariants et variables

Séparez ce qui ne doit pas bouger de ce qui peut être exploré. Pour le packshot exécuté ici, la caméra, le ratio carré, l’objet héros central, la palette cuivre/teal et le format PNG étaient invariants. La forme exacte des accents et la densité du décor restaient variables.

Étape 3 — Demander un plan avant l’action

Le premier tour doit retourner une proposition de structure, les fichiers qui seront écrits, les opérations qui seront exécutées et les points de blocage. Si le brief est ambigu ou si une opération est destructive, l’agent s’arrête et pose une question.

Étape 4 — Produire un script relisible

Le script doit nommer les objets, fixer les unités utiles, créer ou réutiliser les matériaux, configurer la caméra et enregistrer la scène dans un nouveau fichier. Il doit aussi écrire un rapport : version Blender, moteur, résolution, objets et chemins de sortie.

Étape 5 — Lancer Blender dans un environnement borné

Le harness exécute la version attendue avec le script exact, capture stdout/stderr et vérifie le code de retour. Il ne suffit pas que le fichier .blend existe : le rapport doit confirmer que les objets et invariants attendus sont réellement présents.

Étape 6 — Rendre une vignette de contrôle

Un premier rendu rapide rend les erreurs visibles. Comparez la caméra, le ratio, la lisibilité de l’objet, la palette, les ombres et le nommage. Un rendu techniquement réussi n’est pas encore une image artistiquement validée.

Étape 7 — Corriger seulement l’écart observé

La correction exécutée dans ce guide est volontairement étroite : le premier rendu était lisible, mais le nom de l’objet disparaissait en petite vignette. Le script de correction a ajouté un texte ASTRA éditable sur le socle, sans changer la caméra ni le matériau héros. Cette discipline évite qu’une correction locale dérègle toute la scène.

Étape 8 — Conserver les preuves et demander la validation humaine

Livrez le .blend corrigé, le PNG, le script, le rapport JSON et la raison de la correction. L’humain tranche ensuite sur la direction artistique, la conformité de marque et l’usage en production. L’agent ne doit pas transformer une absence de message d’erreur en autorisation de publier.

Prompt : contrat de mission Blender

Modèle et mode vérifiés :

gpt-6-astra, Responses API, reasoning.effort: high, outil d’exécution de code dans un environnement isolé. Le Computer Use visuel reste un complément éventuel, pas le mécanisme principal.

Objectif :

Mission : construire un packshot 3D carré à partir du brief ci-dessous.
Environnement : copie de travail Blender 5.2.1 LTS ; source = [blend_source] ; sortie = [output_dir].
Outils autorisés : lire la scène, écrire [script_path], lancer Blender dans l’environnement isolé,
produire [preview_path], enregistrer [blend_output] et [report_path].
Invariants : caméra dédiée ; objet héros central ; palette cuivre/teal ; rendu PNG 768 x 768 ;
fichier .blend séparé ; aucun écrasement de [blend_source].
Procédure : inspecte d’abord la scène ; retourne un plan court ; attends une confirmation si une
opération est destructive ou si un invariant est ambigu ; exécute ; rends une vignette ; vérifie
les objets, les chemins et les invariants ; corrige seulement l’écart observé ; retourne un rapport.
Arrêt obligatoire : fichier absent, permission manquante, erreur Blender non résolue, rendu non
conforme, ou demande d’écraser la source.
Sortie finale : statut, objets créés/modifiés, erreurs, chemins, écarts au brief et prochaine action.

Variables à adapter :

• `[blend_source]` : copie du fichier source, jamais le master.
• `[output_dir]` : dossier isolé avec droits d’écriture limités.
• `[script_path]` : script versionné et conservé avec le rendu.
• `[preview_path]` et `[blend_output]` : noms de fichiers déterministes.
• Les invariants de cadrage, de marque, de matière, de résolution et de nommage.

Pourquoi cette structure :

Elle transforme une intention visuelle en états que l’on peut inspecter : le modèle sait ce qu’il peut faire, Blender sait où écrire, l’équipe sait quand arrêter, et le livrable est accompagné de preuves. La séparation invariants/variables évite de confondre exploration créative et régression technique.

Limites :

Le pont proposé n’est pas un connecteur natif OpenAI-Blender. Les noms d’outils, permissions, paramètres d’API et temps de rendu doivent être adaptés à l’infrastructure réelle.

Validation :

La structure du prompt a été vérifiée le 12 septembre 2026 contre la page modèle, le guide GPT-6 Astra, la documentation du raisonnement et la documentation Computer Use. Le protocole doit être testé sur un compte et un environnement autorisés avant usage en production.

Prompt : correction ciblée après rendu

Modèle et mode vérifiés :

gpt-6-astra, Responses API, reasoning.effort: medium, entrée texte + image de contrôle, outil Blender borné.

Objectif :

Inspecte [preview_path] et [report_path]. Compare uniquement les invariants suivants : caméra,
ratio, objet héros, palette et lisibilité du nom. Si un invariant est en défaut, propose une
correction minimale et localisée. Ne change ni la caméra ni le matériau héros sans confirmation.
Après accord, exécute la correction dans une copie, rends [preview_v2], sauvegarde [blend_v2] et
retourne un diff lisible entre v1 et v2. Si aucun écart n’est démontré, arrête-toi sans modifier la scène.

Variables à adapter :

• `[preview_path]`, `[report_path]`, `[preview_v2]` et `[blend_v2]`.
• La liste exacte des invariants et les changements explicitement interdits.
• Le niveau de raisonnement et le seuil à partir duquel une validation humaine est demandée.

Pourquoi cette structure :

Elle empêche la « correction créative » de devenir une réécriture silencieuse. La comparaison porte sur un défaut observable, le diff est conservé et l’absence d’écart devient une issue valide.

Limites :

L’inspection visuelle ne remplace pas une vérification de géométrie, de nommage ou de compatibilité de fichier dans Blender.

Validation :

La correction du cas réel a été exécutée avec Blender 5.2.1 LTS et non avec l’API Astra : un premier rendu a été comparé, une correction de texte éditable a été appliquée et un second rendu a été inspecté. L’écart entre ces deux niveaux d’exécution est volontairement documenté.

---

Cas pratique : repartir d’une affiche 4:5 pour construire un monde 3D animé

Une affiche verticale sert de référence visuelle ; elle devient une scène 3D éditable, puis une boucle muette de 15 secondes, 864 × 1080 pixels, 24 images/s.

Périmètre : la reconstruction et l’animation ont été exécutées localement dans Blender 5.2.1 LTS avec EEVEE. Aucun appel à l’API Astra, aucun plugin vidéo et aucun service de génération vidéo externe n’ont été utilisés. Les volumes, profondeurs et faces invisibles sont une interprétation construite à partir de l’affiche approuvée ; ce n’est pas une conversion automatique pixel-vers-maillage.

Étape 1 — Figer le brief et les critères d’acceptation

Le brief fixe le ratio 4:5, une durée exacte de 15 secondes, 24 images par seconde, une boucle sans coupe, une palette terre cuite/pétrole/ivoire, un titre lisible au départ et une scène modifiable. Le point de départ et le point de retour doivent coïncider : l’image 361 sert au contrôle du raccord, mais l’export contient uniquement les images 1 à 360.

Étape 2 — Traduire l’affiche en volumes

Les grandes arches rectangulaires deviennent des maillages extrudés, et non une texture plaquée. Les escaliers, passerelles, supports arqués, bassin longitudinal, soleil suspendu et sphère lointaine sont construits comme des objets séparés. Les couleurs deviennent des matériaux nommés ; le titre, le sous-titre et le bandeau inférieur restent des objets texte Blender.

Étape 3 — Composer la caméra et protéger la lisibilité

La caméra est d’abord réglée pour retrouver la composition de l’affiche. La première inspection a montré une scène trop compacte ; deux corrections bornées ont rapproché la caméra, réduit l’angle plongeant et agrandi les arches centrales. Le texte et le bandeau restent liés à la caméra puis sortent progressivement du cadre pendant l’immersion, afin de préserver la lecture au départ.

Étape 4 — Animer une trajectoire qui se referme

La trajectoire avance vers les arches, atteint une immersion maximale au milieu de la boucle, puis revient vers le cadrage initial avec un léger décalage latéral. Le mouvement est périodique et progressif : il n’y a ni coupe, ni morphing, ni génération d’images intermédiaires par un modèle vidéo. Le fichier Blender conserve les clés d’animation et les objets restent modifiables.

Étape 5 — Rendre les points de contrôle

Avant le rendu complet, cinq images sont examinées : 1, 91, 181, 271 et 361. Elles permettent de contrôler le cadrage, la profondeur, les collisions de caméra, la sortie de la typographie et le raccord. La vue ci-dessous correspond à l’immersion intermédiaire ; elle sert de preuve visuelle du volume réellement rendu dans Blender.

Étape 6 — Rendre et encoder la boucle

blender --background --factory-startup --python build_portail.py
blender --background portail-4x5.blend -o //frames/portail_ -s 1 -e 360 -a
ffmpeg -framerate 24 -start_number 1 -i frames/portail_%04d.png -frames:v 360 -c:v libx264 -crf 18 -pix_fmt yuv420p -movflags +faststart portail-4x5-15s.mp4

Étape 7 — Ouvrir la scène et reprendre la production

Ouvrir portail-4x5.blend dans Blender 5.2.1 LTS ou une version compatible, passer en vue caméra, puis modifier les matériaux Terre cuite, Pétrole et Pierre ivoire ou les textes. Les arches sont de vrais maillages et la référence est embarquée dans le fichier hors rendu. Pour reconstruire la scène depuis zéro, lancer build_portail.py avec reference-affiche.png dans le même dossier.

L’archive jointe regroupe les sources de production disponibles dans la médiathèque. Elle permet de reprendre le script, la scène, les aperçus et les vérifications ; une image PNG seule ne conserverait ni la géométrie ni les clés d’animation.

Ce que le cas démontre — et ce qu’il ne démontre pas

Il démontre qu’une référence visuelle peut devenir une scène 3D structurée, animée et vérifiable : brief, construction, caméra, rendu, contrôle du raccord et livraison des sources sont conservés ensemble. Il ne démontre pas qu’Astra a écrit le script ou piloté Blender dans ce run. Pour passer à une intégration réelle, il faudrait brancher ce contrat à une instance API autorisée, journaliser les appels et conserver la même validation humaine.

---

Grille de contrôle avant livraison

• Le fichier source est-il intact et la copie de travail identifiée ?
• La version Blender, le moteur et la résolution sont-ils consignés ?
• Les invariants sont-ils vérifiés dans le fichier et dans le rendu ?
• Le script, le `.blend`, le PNG et le rapport sont-ils conservés ensemble ?
• La correction est-elle minimale, justifiée par un écart observable et reproductible ?
• Une personne a-t-elle validé la direction artistique, la marque et la conformité finale ?

---

Méthodologie et limites

Les pages officielles OpenAI ont été vérifiées le 12 septembre 2026 : page modèle GPT-6 Astra, guide de démarrage, raisonnement, Computer Use et tarification. L’API Python officielle de Blender a été utilisée comme référence d’intégration, sans présenter Blender comme un connecteur natif OpenAI. Le cas local a été exécuté avec Blender 5.2.1 LTS en mode headless, puis inspecté sur ses rendus initial et corrigé. Les coûts sont datés et doivent être revérifiés avant un achat ou une mise en production. Toute scène destinée à être publiée ou livrée à un client exige une validation humaine.

Sources et références

Sources officielles consultées et vérifiées le 12 septembre 2026 :

• GPT-6 Astra — page modèle OpenAI : modalités, contexte, sorties, endpoints, outils et prix affichés.
• Using GPT-6 Astra : Responses API, appels d’outils asynchrones, pilotage en cours de tour et changements de niveau de raisonnement.
• Computer Use — documentation OpenAI : exécution de code recommandée pour Astra, intégrations structurées et garde-fous.
• Reasoning models — documentation OpenAI : niveaux de raisonnement et conduite des appels d’outils.
• Pricing — documentation OpenAI : tarifs standard, cache, longues entrées, Batch, Flex et Fast mode.
• API Python de Blender : référence de l’API Python utilisée pour construire l’intégration côté production.