Miraxy est un projet d’étude. Je m’en sers de terrain pour mon mémoire de M2, qui porte sur l’importance des logiciels de suivi de production dans une équipe d’animation. Pour en parler sérieusement, je préfère en construire un, même petit, plutôt que de ne regarder que ceux des autres.

Où j’en suis : j’ai tout repris de zéro en octobre 2026. Le serveur Rust tourne sur mon VPS avec PostgreSQL, il sert une interface web minimale (en-tête, page de connexion, page d’inscription), et les comptes, les départements, les droits et les sessions fonctionnent. Il n’y a pas encore de tâches, de publication ni de visualiseur USD. Ce qui suit décrit l’idée et les choix que je veux tester, pas un outil terminé.

Sur mes projets collaboratifs, j’ai vu qu’une petite équipe d’animation indé a les mêmes besoins qu’un studio : savoir qui fait quoi, faire circuler proprement des assets lourds, garder un pipeline cohérent des premiers assets jusqu’à la publication. Elle n’en a pas les moyens. Les outils de référence comme ShotGrid ou Kitsu sont pensés pour des structures avec un TD pipeline dédié et une vraie infra ; à trois ou cinq, ils sont lourds à déployer et à maintenir. On bricole donc avec un tableur partagé.

La question du mémoire part de là : ce que change un vrai suivi de production, et ce qui manque aux équipes qui n’en ont pas.

Le suivi passe en premier : on publie des tâches, puis le résultat des tâches effectuées. Chaque résultat est un fichier USD, et le serveur ne garde que de l’USD et ses textures. Les fichiers sources (.blend et autres) restent chez l’artiste.

Les droits sont des booléens cumulables, portés par département : être responsable FX permet de publier des tâches FX, pas des tâches de modélisation. Le projet n’a pas de taille d’équipe visée : il doit tenir à 2 comme à 2 000 personnes, ce qui impose une vraie base de données et de la pagination partout.

Le cycle de vie d’une tâche (statuts, assignation, validation avant publication) n’est pas encore tranché.

Tout passe par l’USD, d’abord pour limiter le développement. C’est un format unique capable de contenir tous les types de données à faire transiter. Un addon par DCC publiera l’asset depuis le logiciel lui-même, en passant par un daemon local. Blender et Unity sont visés en premier ; la 2D reste à réfléchir.

D’autres formats auraient demandé de traiter chaque type d’asset et chaque DCC au cas par cas, avec plus de code à maintenir. Avec l’USD, il n’y a qu’un seul chemin, ce qui garde le projet tenable pour une seule personne. Les fichiers publiés suivront une configuration commune (layering par département, normalisation à l’export) et devront être visibles dans l’interface web par un visualiseur WebAssembly, dont l’outil reste à choisir. Le traitement des shaders hors PBR classique est aussi une question ouverte.

Le dépôt est un monorepo : server/ (API, base de données), ui/ (fichiers statiques, sans build), daemon/ (agent local) et common/ (types partagés). Le serveur est en Rust avec Axum et SQLx, la base est PostgreSQL. Le daemon et common/ ne contiennent encore qu’un point d’entrée.

Les mots de passe sont hachés en Argon2id et les sessions passent par un cookie HttpOnly, dont la base ne garde que l’empreinte. Le premier compte créé devient administrateur. L’interface reprend le CSS de ma bibliothèque selixy-design. Un script de déploiement interactif met en place le serveur et sa base sur le VPS, et git push vps main construit et déploie.

J’avais d’abord imaginé faire circuler les assets en pair-à-pair, sans serveur de fichiers. J’y ai renoncé : le serveur conserve les fichiers et le daemon les télécharge en HTTP.

Miraxy is a study project. I use it as the ground for my M2 thesis, which looks at why production tracking software matters in an animation team. To talk about it seriously, I would rather build one, even a small one, than only look at other people’s.

Where I am: I started over from scratch in October 2026. The Rust server runs on my VPS with PostgreSQL, it serves a minimal web interface (header, login page, signup page), and accounts, departments, rights and sessions work. There are no tasks, publishing or USD viewer yet. What follows describes the idea and the choices I want to test, not a finished tool.

On my collaborative projects I saw that a small indie animation team has the same needs as a studio: knowing who does what, moving heavy assets around cleanly, keeping a coherent pipeline from the first assets to publishing. It does not have the means. Reference tools like ShotGrid or Kitsu are built for structures with a dedicated pipeline TD and real infrastructure; at three or five people, they are heavy to deploy and maintain. Teams end up with a shared spreadsheet.

The thesis question starts there: what real production tracking changes, and what teams without one are missing.

Tracking comes first: tasks are published, then the result of the finished tasks. Each result is a USD file, and the server keeps only USD and its textures. Source files (.blend and the like) stay with the artist.

Rights are stackable booleans held per department: being FX lead allows publishing FX tasks, not modeling tasks. There is no target team size: it has to work for 2 people as well as 2,000, which calls for a real database and pagination everywhere.

The life cycle of a task (statuses, assignment, validation before publishing) is not settled yet.

Everything goes through USD, first to keep the development small. It is a single format able to hold every data type that has to move around. One addon per DCC will publish the asset from the software itself, through a local daemon. Blender and Unity come first; 2D is still to be thought through.

Other formats would have meant handling each asset type and each DCC separately, with more code to maintain. With USD there is only one path, which keeps the project manageable for one person. Published files will follow a common setup (layering per department, normalization at export) and should be visible in the web interface through a WebAssembly viewer, whose tool is still to be chosen. How to handle shaders beyond classic PBR is also an open question.

The repository is a monorepo: server/ (API, database), ui/ (static files, no build), daemon/ (local agent) and common/ (shared types). The server is Rust with Axum and SQLx, the database is PostgreSQL. The daemon and common/ only hold an entry point so far.

Passwords are hashed with Argon2id and sessions use an HttpOnly cookie, of which the database keeps only the hash. The first account created becomes admin. The interface reuses the CSS of my selixy-design library. An interactive deploy script sets up the server and its database on the VPS, and git push vps main builds and deploys.

I first imagined moving assets peer-to-peer, with no file server. I dropped that: the server keeps the files and the daemon downloads them over HTTP.