Miraxy vient de ce que j’ai vécu sur mes projets collaboratifs : 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), mais sans ses 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 trop lourds à déployer et à maintenir. On bricole donc avec un tableur partagé, ou on se tourne vers des outils de studio.

Miraxy est l’outil que je voudrais avoir pour ma propre équipe. C’est d’abord un outil de suivi de production, où l’on suit l’avancement de chaque tâche. C’est aussi un pipeline léger qui se branche sur n’importe quel DCC, où chaque asset est publié et versionné.

Le suivi de production passe en premier : une production y est un ensemble de tâches reliées entre elles et placées dans un planning. Chacun voit ce qui lui revient, dans quel ordre, ce qui dépend de lui et ce qui bloque. Les assets sont publiés dans le pipeline et versionnés, au lieu de circuler par mail ou par Discord, et chacun récupère la bonne version sans avoir à la demander.

L’outil doit rester simple à mettre en route pour une équipe de trois ou cinq. Il n’y a pas de serveur de fichiers à héberger : les assets circulent directement entre les postes de l’équipe, en pair-à-pair. Miraxy fait passer les données d’un DCC à l’autre sans que personne ait à devenir TD pipeline.

Tout passe par l’USD avant tout pour limiter le développement à ma charge. C’est un format unique capable de contenir tous les types de données dont j’ai besoin de faire transiter. Mes intégrations se limitent à un bouton « exporter » dans chaque DCC, sous forme de plugin, qui publie directement l’asset dans le flux de Miraxy. Miraxy le distribue ensuite aux membres de l’équipe.

J’aurais pu partir sur d’autres formats, mais il aurait fallu gérer du cas par cas selon le type d’asset et le DCC d’origine. Ce serait moins uniforme, avec plus de code à maintenir et plus d’endroits où ça peut casser. Avec l’USD je n’ai qu’un seul chemin, ce qui rend l’outil tenable pour une personne seule.

Miraxy comes from what I saw on my collaborative projects: 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 all the way to publishing), but none of its 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 too heavy to deploy and maintain. So teams hack something together with a shared spreadsheet, or turn to studio tools.

Miraxy is the tool I would want for my own team. It is first a production tracking tool, where you follow the progress of every task. It is also a lightweight pipeline that plugs into any DCC, where every asset is published and versioned.

Production tracking comes first: a production is a set of tasks linked to one another and placed in a schedule. Everyone sees what is theirs to do, in what order, what depends on them and what is blocked. Assets are published into the pipeline and versioned, instead of going around by email or Discord, and everyone pulls the right version without having to ask.

The tool has to stay simple to set up for a team of three to five. There is no file server to host: assets travel directly between the team’s machines, peer-to-peer. Miraxy moves the data from one DCC to the next without anyone having to become a pipeline TD.

Everything goes through USD mainly to keep the development on my side to a minimum. It is a single format able to hold every data type I need to move around. My integrations then come down to an “export” button in each DCC, as a plugin, that publishes the asset straight into Miraxy’s flow. Miraxy then distributes it to the team members.

I could have gone with other formats, but that would have meant handling each case separately depending on the asset type and the source DCC. It would be less uniform, with more code to maintain and more places where things can break. With USD I only have one path, which keeps the tool maintainable for a single person.