Gérer les révisions de fichiers Blender avec un addon de versioning Kitsu (2026)

Gérer les révisions de fichiers Blender avec un addon de versioning Kitsu (2026)
🧱
Remplacez une nomenclature chaotique par une source unique de vérité pour les révisions Blender.

Chaque projet commence avec de bonnes intentions. Vous démarrez avec un model.blend bien propre, des dossiers organisés, et la promesse que, cette fois, vous garderez tout bien rangé.

Mais quand les délais se resserrent, la tranquille entropie de la production s’installe. Très vite, votre dossier de projet commence à ressembler à un site de fouilles archéologiques d’ultimes modifications prises dans la panique :

model.blend
model_v2.blend
model_v2b.blend
model_final.blend
model_final_really_final.blend
model_FINAL_v3.blend

Vous savez comment ça se passe : quelqu’un a besoin d’un changement rapide, un autre artiste part sur une version « juste au cas où », et bientôt plus personne n’est vraiment sûr de savoir quel fichier est « le vrai ». Les commentaires dans les fils de discussion contredisent les noms de fichiers, des rendus de plans sortent à partir de versions obsolètes, et le superviseur soupire profondément.

Dans un studio d’animation, ces micro-instants de chaos s’accumulent. C’est là qu’une source de vérité adaptée doit entrer en scène.

Pour beaucoup d’équipes, cette source, c’est Kitsu. Et pour les artistes Blender, la pièce manquante est un pont automatisé qui conserve les fichiers versionnés, traçables et alignés avec les données de production du projet.

Alors vous décidez de reprendre le contrôle : vous allez faire parler Blender avec Kitsu et construire un système de versioning qui donne à votre pipeline l’impression, enfin, d’avoir votre dos.

Dans ce tutoriel, nous allons créer un addon qui gère les révisions de fichiers directement depuis Blender. Vous pourrez connecter Blender à un projet Kitsu, créer et téléverser des révisions de vos modèles 3D, consulter toutes les révisions existantes, et ramener d’anciennes révisions dans Blender.


Aperçu du workflow

Dans un workflow typique piloté par Kitsu, un artiste ouvre une scène Blender, fait son travail, atteint une étape (milestone) et téléverse une révision. Les artistes consultent, itèrent, révisent et téléversent à nouveau. Kitsu garde chaque étape bien rangée.

Mais ça ne ferait pas de mal de pouvoir simplement téléverser ou ramener des révisions d’un clic, non ?

  1. Démarrer dans Blender - Nous ouvrons notre scène de travail : modélisation, shading, rigging, bref, tout ce que la tâche exige.
  2. Créer un point de contrôle - Quand on atteint une étape (« blocking terminé », « prêt pour la relecture »), on crée une nouvelle révision dans Kitsu.
  3. Consulter l’historique - Kitsu stocke toutes les révisions, ce qui donne aux superviseurs une chronologie claire et vous permet de comparer des versions sans fouiller dans les fichiers.
  4. Ramener de nouveaux changements - Quand nous avons besoin d’une version différente, il suffit de cliquer pour ramener un asset dans notre espace de travail actuel.

C’est un workflow très basique, donc nous risquons de rencontrer des problèmes comme la façon de gérer la résolution de conflits (et si deux artistes travaillent sur le même plan et créent chacun une nouvelle révision, comment gère-t-on cela ?), mais c’est suffisant pour nous donner un addon fonctionnel que nous pourrons améliorer plus tard pour répondre aux besoins du pipeline d’animation.

💡
Vous cherchez des exemples concrets ?

Vous pouvez trouver le code source complet de l’exemple d’intégration présenté dans ce guide sur notre GitHub :

🔗 https://github.com/cgwire/blender-kitsu-versioning-addon

1. Renseigner le tableau de bord Kitsu

L’interface web de Kitsu est conçue pour que les producteurs, coordinateurs ou leads puissent rapidement mettre en place la structure d’un projet. Avant que les artistes Blender puissent publier des révisions, nous devons alimenter notre production avec des assets en cours. Dans l’instance Docker Kitsu pour le développement local :

  1. Connectez-vous au tableau de bord Kitsu.
  2. Dans la barre de navigation principale, allez dans Productions.
  3. Cliquez sur "Create production" (généralement le coin supérieur droit).
  4. Renseignez les détails de la production

La nouvelle production apparaît dans la liste, et vous pouvez l’ouvrir pour commencer à ajouter des assets.

Les assets sont les éléments de base de votre projet : personnages, props, environnements, véhicules… tout ce qui doit être tracé dans la production.

  1. Allez dans Productions → le nom de votre production.
  2. Ouvrez l’onglet Assets à l’intérieur de la production.
  3. Cliquez sur "Create Asset".
  4. Renseignez un Asset Name (par ex. « RobotHead ») et un Asset Type (Character, Prop, Set, etc.)

Votre asset existe désormais et possède 3 tâches qui lui sont assignées. 

Les tâches définissent les étapes du workflow (Modélisation, Shading, Rigging, etc.) que les artistes effectueront sur chaque asset.

Nous avons maintenant tout ce qu’il faut pour tester notre addon.


2. Lier le projet Blender actuel à une tâche Kitsu

Nous commençons par une déclaration d’addon minimale qui définit l’emplacement de l’interface, charge gazu, et prépare les données que nous exposerons dans les menus déroulants :

bl_info = {
    "name": "Model Versioning (Production/Task/Asset/Revisions)",
    "author": "cgwire",
    "version": (1, 0, 0),
    "blender": (2, 80, 0),
    "location": "View3D > Sidebar > ModelVersioning",
    "description": "Browse productions, tasks, assets, and manage revisions (list/create/load)",
     "category": "3D View",
}

import sys

sys.path.append("~/.local/lib/python3.11/site-packages")

import os import tempfile

import bpy import gazu from bpy.props import EnumProperty, PointerProperty from bpy.types import Operator, Panel, PropertyGroup

Notez que sys.path.append("~/.local/lib/python3.11/site-packages") nous permet d’utiliser notre installation Python locale pour accéder à des packages externes comme gazu. Par défaut, Blender exécute sa propre installation Python, donc installer des packages peut être fastidieux. Pour résoudre ce problème, on indique simplement à Blender d’aller regarder nos modules locaux. Mettez ce chemin à jour pour qu’il corresponde à la configuration de votre système.

Avant de pouvoir automatiser le versioning, Blender doit savoir dans Kitsu appartient le modèle actuel. Cela signifie d’identifier le projet, l’asset, la tâche, et finalement les révisions qui y sont associées.

La première étape est simple : s’authentifier auprès de Kitsu, récupérer les productions disponibles, et laisser l’artiste choisir le contexte directement depuis l’interface de la Sidebar.

Une fois l’addon chargé, on s’authentifie et on pointe l’addon vers l’hôte de l’API Kitsu :

gazu.set_host("<http://localhost/api>")
user = gazu.log_in("admin@example.com", "mysecretpassword")

temp_dir_path = tempfile.gettempdir()

Cela établit la session que nous utiliserons pour parcourir les productions, trouver des tâches, et finalement créer des révisions.

À partir de là, nous pouvons commencer à exposer la structure de la production. Avec des fonctions d’assistance pour la recherche de projet, d’asset, de tâche et de révision, nous remplissons chaque menu déroulant de manière dynamique :

def find_project(name):
    return gazu.project.get_project_by_name(name)

def find_asset(project, name):     return gazu.asset.get_asset_by_name(project, name)

def find_task(asset, type_id):     return gazu.task.get_task_by_name(asset, type_id, "main")

Chaque rappel de EnumProperty récupère des données fraîches depuis Kitsu :

def enum_projects(self, context):
    items = 
    projects = gazu.project.all_projects()
    for p in projects:
        items.append((p"name", p"name", ""))
    if not items:
        items.append(("NONE", "--- no productions ---", ""))
    return items

Les assets, tâches et révisions suivent le même schéma :

def enum_assets(self, context):
    project = find_project(context.scene.mv_state.project)
    items = 
    if project:
        assets = gazu.asset.all_assets_for_project(project)
        for t in assets:
            items.append((t"name", t"name", ""))
    if not items:
        items.append(("NONE", "--- no tasks ---", ""))
    return items

def enum_tasks(self, context):     project = find_project(context.scene.mv_state.project)     asset = find_asset(project, context.scene.mv_state.asset)     items =     if asset:         tasks = gazu.task.all_tasks_for_asset(asset)         for t in tasks:             items.append((t"task_type_id", t"task_type_name", ""))     if not items:         items.append(("NONE", "--- no tasks ---", ""))     return items

def enum_revisions(self, context):     project = find_project(context.scene.mv_state.project)     asset = find_asset(project, context.scene.mv_state.asset)     task = find_task(asset, context.scene.mv_state.task)     items =     if task:         revisions = gazu.files.get_all_preview_files_for_task(task)         for r in revisions:             items.append((str(r"revision"), str(r"revision"), ""))     if not items:         items.append(("NONE", "--- no revisions ---", ""))     return items

Enfin, nous stockons toutes les sélections de l’interface dans un unique objet d’état :

class MV_State(PropertyGroup):
    project: EnumProperty(
        name="Project", description="Select project", items=enum_projects
    )
    asset: EnumProperty(name="Asset", description="Select asset", items=enum_assets)
    task: EnumProperty(name="Task", description="Select task", items=enum_tasks)
    revision: EnumProperty(
        name="Revision", description="Select revision", items=enum_revisions
     )

Voici la base de notre intégration au pipeline : Blender sait maintenant parcourir Kitsu et se lier à la tâche exacte sur laquelle l’artiste travaille. À partir de là, nous pouvons commencer à travailler sur le cycle de vie des révisions.


3. Créer un bouton « Nouvelle révision »

Nous pouvons commencer à automatiser la partie avec laquelle les artistes interagissent le plus : la création de nouvelles révisions. Dans un workflow manuel classique, vous exportez votre fichier puis vous le téléversez dans Kitsu sur la tâche correcte. Notre addon simplifie tout cela en une seule pression de bouton à l’intérieur de Blender.

Kitsu gère les nouvelles révisions via publish_preview(). Cet appel envoie à la fois le fichier et les métadonnées :

temp_file_path = os.path.join(temp_dir_path, "new_version.glb")

bpy.ops.export_scene.gltf(filepath=temp_file_path, export_format="GLB")

(comment, preview_file) = gazu.task.publish_preview(     task,     task_status,     revision=new_revision,     comment="increment revision",     preview_file_path=temp_file_path, )

os.remove(temp_file_path)

Dans notre addon, on déclenchera cela depuis un bouton dans la Sidebar.

L’opérateur effectue trois étapes principales : récupérer les sélections de l’utilisateur depuis l’état de l’addon, calculer le prochain numéro de révision, puis téléverser le fichier exporté comme nouvelle révision :

class MV_OT_create_revision(Operator):
    bl_idname = "mv.create_revision"
    bl_label = "Create Revision"

    def invoke(self, context, event):         wm = context.window_manager         return wm.invoke_props_dialog(self, width=400)

    def execute(self, context):         project = find_project(context.scene.mv_state.project)         asset = find_asset(project, context.scene.mv_state.asset)          task = find_task(asset, context.scene.mv_state.task)          revision = context.scene.mv_state.revision          new_revision = int(revision) + 1

        task_status = gazu.task.get_task_status_by_name("todo")

        temp_file_path = os.path.join(temp_dir_path, "new_version.glb")

        bpy.ops.export_scene.gltf(filepath=temp_file_path, export_format="GLB")

        (comment, preview_file) = gazu.task.publish_preview(             task,             task_status,             revision=new_revision,             comment="increment revision",             preview_file_path=temp_file_path,         )

        os.remove(temp_file_path)

        self.report({"INFO"}, "Revision created")         return {"FINISHED"}


4. Importer une révision dans Blender

Le versioning n’est pas seulement une question de publication de votre travail : il s’agit aussi de pouvoir revenir en arrière. Que vous révisiez des étapes précédentes, compariez la topologie, ou récupériez un détail depuis une itération antérieure, vous avez besoin d’un moyen rapide et fiable pour charger de nouvelles révisions et d’anciennes révisions dans Blender.

Une fois qu’une tâche est sélectionnée, importer une révision depuis Kitsu devient une opération simple en deux étapes : télécharger le fichier d’aperçu associé à la révision sélectionnée, puis l’importer dans Blender.

Après avoir récupéré tous les fichiers d’aperçu pour la tâche en cours, nous pouvons cibler la révision via son index et apporter l’asset directement dans Blender :

temp_file_path = os.path.join(temp_dir_path, "new_version.glb")

preview_file = preview_filesint(revision) - 1 gazu.files.download_preview_file(preview_file, temp_file_path) bpy.ops.import_scene.gltf(filepath=temp_file_path)

os.remove(temp_file_path)

Cela nous donne une façon cohérente de récupérer les assets tels qu’ils étaient exactement à ce moment de la production.

Nous encapsulons ce workflow dans un opérateur qui reproduit la structure du bouton « Create Revision » :

class MV_OT_load_revision(Operator):
    bl_idname = "mv.load_revision"
    bl_label = "Load Revision"

    def execute(self, context):         project = find_project(context.scene.mv_state.project)         asset = find_asset(project, context.scene.mv_state.asset)         task = find_task(asset, context.scene.mv_state.task)         revision = context.scene.mv_state.revision         preview_files = gazu.files.get_all_preview_files_for_task(task)

        temp_file_path = os.path.join(temp_dir_path, "new_version.glb")

        preview_file = preview_filesint(revision) - 1         gazu.files.download_preview_file(preview_file, temp_file_path)         bpy.ops.import_scene.gltf(filepath=temp_file_path)

        os.remove(temp_file_path)

        self.report({"INFO"}, "Opened Revision")         return {"FINISHED"}

Cet opérateur permet aux artistes de parcourir et charger n’importe quelle version stockée dans Kitsu sans quitter Blender.


5. Enregistrer l’addon

Le panneau relie maintenant l’ensemble du workflow de révision :

  • Sélectionnez le projet
  • Choisissez l’asset
  • Choisissez la tâche
  • Parcourez les révisions
  • Créez ou chargez des versions en un seul clic
class MV_PT_panel(Panel):
    bl_label = "Model Versioning"
    bl_idname = "MV_PT_panel"
    bl_space_type = "VIEW_3D"
    bl_region_type = "UI"
    bl_category = "ModelVersion"

    def draw(self, context):         layout = self.layout         scene = context.scene         mv = scene.mv_state

        layout.label(text="Project")         layout.prop(mv, "project", text="")         layout.separator()

        layout.label(text="Asset")         layout.prop(mv, "asset", text="")         layout.separator()

        layout.label(text="Task")         layout.prop(mv, "task", text="")         layout.separator()

        layout.label(text="Revision")         layout.prop(mv, "revision", text="")         layout.separator()

        row = layout.row(align=True)         row.operator("mv.create_revision", text="Create Revision", icon="ADD")

        layout.operator(             "mv.load_revision", text="Load Selected Revision", icon="IMPORT"         )

Enfin, nous enregistrons les opérateurs, le panneau et l’état pour que Blender sache comment construire l’interface :

classes = (
    MV_State,
    MV_OT_create_revision,
    MV_OT_load_revision,
    MV_PT_panel,
)

def register():     for c in classes:         bpy.utils.register_class(c)     bpy.types.Scene.mv_state = PointerProperty(type=MV_State)

def unregister():     for c in reversed(classes):         bpy.utils.unregister_class(c)     if hasattr(bpy.types.Scene, "mv_state"):         del bpy.types.Scene.mv_state

if name == "main":     register()

À ce stade, le workflow de versioning des modèles est entièrement bidirectionnel : vous pouvez publier de nouvelles révisions depuis Blender et récupérer instantanément les révisions précédentes.


Conclusion

Avec seulement quelques opérateurs de l’API Blender et la commodité du SDK Gazu, nous avons construit un workflow de versioning pratique (mais basique) qui vit directement dans Blender et reste synchronisé avec Kitsu. Les artistes peuvent lier leur scène Blender à un projet Kitsu, un asset et une tâche, créer de nouvelles révisions en un seul clic, parcourir l’historique complet des révisions pour n’importe quelle tâche, puis ramener d’anciennes versions directement dans Blender chaque fois qu’ils doivent comparer ou récupérer un travail.

Ce workflow n’est qu’un début. Ensuite, vous pourriez étendre l’addon avec des exports automatisés, des rendus de vignettes ou de turntable, la prise en charge de plusieurs formats de sortie, des outils de revue pour les superviseurs, voire des connexions vers un render farm.

Pour vous lancer, assurez-vous de cloner notre repository Github pour cet addon de versioning et testez-le par vous-même !

📽️
Pour en savoir plus sur le processus d’animation, envisagez de rejoindre notre communauté Discord ! Nous échangeons avec plus d’un millier d’experts qui partagent des bonnes pratiques et qui organisent parfois des événements en personne. Nous serions ravis de vous accueillir ! 😊

Vous appréciez cet article ?

Abonnez-vous à notre newsletter pour plus d'analyses, de tutoriels et d'actualités du secteur.