R&D LAB Production de médias En service Conçu pour notre propre production
PixelForge
Notre pipeline média plutôt qu'un abonnement
Image, vidéo et audio via nos propres clés fournisseur plutôt qu'un abonnement. Le résultat n'est pas l'image, c'est la recette qui permet de la refaire.
- 21modèles au catalogue de l'application
- 6voies d'accès, dont une sur notre propre GPU
- 26préréglages en cinq groupes
- 12utilisations en production sans interface
Capture réalisée dans un profil de navigateur neuf, afin qu'aucune clé, aucune galerie et aucun travail client n'apparaisse. Les prix sont les estimations propres à l'application au 22 août 2026, et non un tarif de notre part.
Pourquoi c'est publié
Nous vendons du logiciel et de l'automatisation, et nous vendons de la production média assistée par IA. PixelForge est la preuve des deux d'un seul tenant : une chaîne que nous exploitons nous-mêmes, que nous utilisons sur de vraies commandes, et dont les résultats sortent étiquetés et traçables. Si vous voulez savoir comment nous montons une production média, vous voyez ici la version que nous avons construite pour nous.
Les interfaces par abonnement pour les médias génératifs résolvent le premier essai, pas le dixième. Elles offrent une liste de modèles figée, pas de traitement par lots, pas de compte de coûts par projet et surtout aucun moyen de relancer une image à l'identique six mois plus tard. PixelForge est un serveur local qui interroge les fournisseurs avec nos propres clés, se pilote depuis une interface comme depuis un script, et consigne pour chaque résultat la recette dont il est issu.
La décision
Le résultat n'est pas l'image, c'est la recette
Le premier prompt est toujours facile. Cela se complique au quarantième, lorsque vingt images d'une même série doivent s'accorder, qu'un personnage doit rester identique sur trois scènes, qu'une variante est demandée après validation et que personne ne sait plus avec quel modèle ni quel seed les autres ont été produites. C'est précisément là qu'une interface par abonnement cesse d'aider : elle montre des résultats, elle ne tient pas de registre.
Nous avons donc inversé le rapport. L'objet premier dans PixelForge n'est pas l'image, c'est la recette : modèle, prompt final, préréglages retenus, marque, référence de personnage, format, durée, seed, plus une copie réduite de chaque image d'entrée. L'image est ce qui sort de l'exécution de cette recette. La relancer est donc un bouton, et non une fouille dans l'historique.
De cette seule décision découle presque tout le reste. Si une commande est un objet de données, un script peut aussi la soumettre, et l'interface devient l'une des deux portes plutôt que la seule. Si c'est un objet de données, on peut la traiter par lots, la confier à une chaîne d'étapes et la rejouer sur un autre modèle : bon marché pour le brouillon, coûteux seulement pour la version validée. Et comme le fournisseur, l'identifiant de modèle et le seed sont de toute façon consignés à chaque exécution, la mention prévue à l'article 50 du règlement sur l'IA figure sur le résultat au lieu d'être ajoutée à la main plus tard.
Le prix à payer mérite d'être nommé : les clés sont chez nous, donc la responsabilité l'est aussi, et personne n'a audité de l'extérieur le coffre chiffré. L'application est monoposte ; il n'existe ni galerie partagée ni compte de coûts par personne, et rien de tel n'est annoncé ici comme à venir.
Une image qu'on ne peut pas relancer est une trouvaille, pas un outil.
Le parcours d'une commande
De la consigne au résultat documenté
- 01 Consigne Une phrase de texte, éventuellement des préréglages issus de cinq groupes couvrant caméra, lumière, style, format et mouvement, plus une marque, une référence de personnage et une image d'entrée. Le serveur en compose le prompt final et l'enregistre comme recette.
- 02 Choix du modèle Le catalogue compte vingt et un modèles pour l'image, la vidéo, l'animation et le son via six voies d'accès, dont une locale pour le matériel qui ne doit pas quitter la maison. Un modèle bon marché dessine le brouillon ; un modèle coûteux ne rend que la version validée.
- 03 Coût Avant l'exécution, une estimation figure sur le bouton ; après, une écriture au compte du projet. Ce qu'une commande a coûté en calcul est alors un chiffre et non un souvenir, exportable sous forme de tableau.
- 04 Résultat L'asset arrive dans la galerie, sa recette attachée. La même vue porte le panneau de provenance : fournisseur, identifiant de modèle, date, seed, coût estimé, mention d'un filigrane et un avis de transparence déjà rédigé, prêt à copier.
Quatre studios, un seul catalogue
Image, vidéo, animation et son sont quatre vues sur un même catalogue de modèles au sein de l'application. Chaque carte indique le fournisseur, la voie d'accès et le prix estimé que l'application porte elle-même ; le choix est une décision de coût visible avant le clic plutôt que sur une facture mensuelle.
L'intérêt de cette disposition se voit moins sur une image isolée que sur une série. Une même recette peut partir vers un modèle rapide tant que l'idée hésite, puis vers un modèle de qualité dès qu'elle tient. À l'inverse, rien n'atterrit par accident sur la voie coûteuse, car le modèle coûteux figure sur une carte à côté des autres et non derrière un réglage par défaut.
Avoir le son dans la même maison est la deuxième raison de ce découpage : le graphisme, les bruitages et la voix d'un même sujet se produisent en une seule passe, sous le même nom de projet et dans le même compte de coûts.
Ce que le changement a modifié
Avant : une interface par abonnement
- Une liste de modèles figée ; on change seulement si le fournisseur le propose.
- Un crédit mensuel, sans égard au projet qui l'a consommé.
- Un historique d'images, mais sans les paramètres qui les ont produites.
- Aucun moyen de lancer cent variantes autrement qu'à la main.
- Provenance et étiquetage arrivent après coup, si quelqu'un y pense.
Maintenant : nos propres clés
- Vingt et un modèles côte à côte, dont un sur notre propre GPU.
- Un compte par projet, alimenté par les exécutions réellement effectuées.
- Chaque résultat porte sa recette, seed et image d'entrée compris.
- Un prompt par ligne, ou un script qui appelle la chaîne de l'extérieur.
- Fournisseur, identifiant de modèle, seed et mention de l'article 50 figurent sur le résultat dès l'exécution.
Ce qui figure sur un asset terminé
Le son dans la même interface
Le son était la dernière lacune et celle où l'idée de recette paie le plus visiblement. Une voix off est rarement retenue à la première prise ; refaire une prise suppose d'avoir la voix, le modèle et le texte comme données et non comme état d'écran. La même vue fournit bruitages et nappes musicales, de sorte qu'un module explicatif se fabrique en une seule passe.
Ce qui ne figure pas ici, c'est une comparaison de prix. L'application porte des estimations qui évoluent, et le tableau de bord du projet est marqué comme devant être revérifié avant toute citation. C'est pourquoi cet article ne donne aucun coût, ni par asset ni par mois.
Ce pour quoi nous l'avons utilisé jusqu'ici
- Logotypes et icônes d'application pour nos propres produits, en plusieurs variantes au choix
- Jeux graphiques complets pour applications interactives, y compris des personnages décomposables
- Bruitages, voix off et nappes musicales pour ces mêmes applications
- Dessins conceptuels isométriques comme images explicatives pour notre communication
- Visuels de pages d'atterrissage, dans un style tenu sur toute une série
Pourquoi c'est publié
Ce que cela signifie pour votre projet
Plus du laboratoire
Méthode Event Scout Un modèle de langage lit les pages d'événements, tout le reste est du code fixe. Il reste une courte liste des journées qui valent le déplacement. 
Recherche appliquée Vellum Bords, perspective, lumière et texte sont calculés sur le téléphone. Un document ne quitte l'appareil que lorsque quelqu'un l'envoie. Avez-vous besoin de médias en série plutôt qu'à l'unité, et faut-il pouvoir les refaire à l'identique dans un an ? C'est précisément à cela que sert un pilote.
Nous contacter