Produire les sprites sans les dessiner

Je ne sais pas dessiner. Pas de faux modeste : zéro compétence en pixel art, et aucun pixel artist dans un studio d'une personne. Idle Orbit, mon idle game de station spatiale, a pourtant besoin d'assets : sept modules de station à représenter, une scène qui se construit au fil de la progression du joueur.

La génération locale était exclue d'office : ma carte plafonne à 8 Go de VRAM, déjà à l'étroit pour tout le reste. Restait l'abonnement à une API externe spécialisée pixel art, PixelLab en l'occurrence. Sauf qu'un abonnement ne résout rien tout seul. Il déplace le problème : je ne dois plus savoir dessiner, je dois savoir passer commande. Et ça, je l'ai appris en payant.

Mon premier protocole générait des assets isolés en 64x64, composés ensuite en trois tiers visuels par module (T1, T2, T3) : chaque bâtiment devait évoluer graphiquement. Le deuxième visait une méga-scène ambitieuse, cumulative, avec des tiers visuels qui s'empilaient. Les deux sont partis à la poubelle pour les mêmes raisons : trop de crédits consommés, trop de variance entre les générations. Chaque asset supplémentaire était une occasion de plus pour l'IA de dévier du style.

Le protocole v3, celui qui a tenu, est brutalement plus simple : un seul asset par module, sept assets pour toute la zone. Pas de tier visuel, pas d'évolution. L'asset apparaît sur la scène quand le joueur acquiert le module, point. La leçon est arrivée avant la première ligne de prompt engineering : réduire la surface de génération rapporte plus que d'optimiser les prompts.

Le protocole par module commence par ce qui ne coûte rien : un brief court, 500 à 1500 caractères de description, moins de 200 pour la palette. Ces bornes ne sont pas du zèle, ce sont les limites dures de l'API : au-delà de 2000 caractères de description ou 200 de palette, elle renvoie un HTTP 422. Le brief décrit la silhouette, la position attendue sur la base, les contraintes spatiales, la palette du jeu. Et il est validé avant de dépenser le moindre crédit.

Ensuite seulement : un appel payé, un seul. La sélection se fait sur une grille comparative zoomée x6 des huit dernières versions. Si le résultat est raté, un retry maximum, plafond strict. Côté budget, mon runner maison refuse tout appel payant sans deux flags explicites, --live et --confirm-spend, le token restant en variable d'environnement. Résultat à ce stade de la production : environ 160 crédits dépensés, zéro accident budgétaire.

L'API affiche une estimation de 30 à 90 secondes par génération. Le réel : 3 à 8 minutes. Ce n'est pas dramatique, mais tout workflow calé sur l'estimation officielle s'écroule, et on apprend à occuper l'attente autrement.

Plus coûteux : les tuiles générées sortent avec un bord sombre qui les rend inutilisables posées en grille, elles dessinent un quadrillage sur toute la carte. Et le canvas dérive : demander un élément principal de 52x52 pixels ne garantit pas d'en recevoir un. Ma contre-mesure tient en deux pièces : une table de calibration qui fixe la règle 60/40 (l'élément principal occupe environ 60 % de la bounding box cible, l'accessoire 40 %), injectée dans chaque brief, et un auto-crop après génération qui recadre le contenu effectif à la taille cible. Le commentaire dans ma doc résume l'esprit : garantir la règle même si l'IA ne la respecte pas.

La composition finale ne passe jamais par l'API. Chaque asset sélectionné est posé à la main dans GIMP, sur une anchor map qui fixe les coordonnées précises de chaque module et des zones interdites : les fenêtres de l'habitat, par exemple, qu'aucun asset ne doit couvrir. C'est lent, c'est manuel, et c'est exactement le genre de décision spatiale que je ne délègue pas à un modèle.

L'autre gros morceau est procédural : un script Python d'environ 600 lignes de PIL qui compose les variantes de tiers à partir d'une template de base, sans un seul appel IA. Économie mesurée : environ 120 crédits par module à tiers. Le paradoxe m'amuse encore : la pièce la plus rentable de mon pipeline de génération IA est celle qui n'en contient pas.

La génération était la partie facile. Le livrable réel de ce projet, ce sont les documents et les scripts autour : un brief validé avant chaque crédit, un plafond de retry écrit noir sur blanc, deux flags qui verrouillent la dépense, une table de calibration qui compense la dérive du modèle, et une composition finale qui reste humaine.

Un abonnement de génération remplace le coup de crayon, pas le métier. La direction artistique, l'arbitrage budgétaire et le contrôle qualité ne se sont pas externalisés : ils ont juste changé de forme. Si vous partez sur ce chemin, écrivez le protocole avant de payer le premier crédit. C'est lui, l'asset le plus précieux du pipeline.