Mettre à l’échelle la configuration de production dans Kitsu avec des imports CSV (2026)

Si créer une nouvelle série ou une nouvelle scène dans Kitsu implique de cliquer dans des formulaires, de recréer des listes d’assets et d’attribuer des artistes un par un, votre onboarding est incomplet.

Cette charge manuelle s’accumule très vite. Chaque nouvelle production répète le même rituel de configuration, chaque onboarding d’équipe devient une course au copier-coller, et chaque étape ajoute une opportunité de faire casser quelque chose. À l’échelle d’un studio, ces frictions coûtent du temps réel, de l’argent réel et de la santé mentale réelle.

Les studios les plus rapides n’utilisent pas seulement Kitsu : ils l’intègrent dans leur pipeline. Ils le traitent comme une base de données de production, en l’alimentant avec des données de studio propres et structurées pour mettre en ligne de nouvelles séries, des plans ou des départements en quelques minutes, et non en quelques jours. Les pipelines sont clonés, les équipes sont rattachées automatiquement, et Kitsu devient un moteur plutôt qu’un goulot d’étranglement.

Dans cet article, nous allons détailler un workflow pratique et éprouvé en production pour faire exactement cela, en utilisant des fichiers CSV et l’API Python de Kitsu (Gazu) afin d’automatiser l’onboarding de production et de faire disparaître le travail de configuration.

Ce que vous pouvez importer

Dans une production réelle, la quasi-totalité des données se répartissent dans quelques catégories répétables, idéales pour l’automatisation :

• Artistes - Votre équipe existe déjà quelque part ailleurs : une feuille RH, une export de paie, une table Notion. Ces données incluent généralement des noms, des e-mails et des rôles comme Animator, TD ou Supervisor. Au lieu de recréer des utilisateurs à la main dans Kitsu, vous pouvez importer cette liste en une seule passe et avoir votre équipe prête dès le premier jour.
• Assets - Personnages, accessoires, environnements… tout ce qui suit une convention de nommage s’automatise facilement. Un CSV contenant des entrées comme CHAR_RobotA, PROP_Sword_01 ou ENV_CityBlock
• Tâches - Les tâches sont aussi là où la configuration manuelle fait vraiment mal. Modélisation, Rigging, Surfacing, Animation… ces types de tâches changent rarement d’un show à l’autre. En important les tâches en masse, vous pouvez automatiquement attacher la bonne pile de tâches à chaque asset et même pré-assigner des artistes ou des départements, au lieu de cliquer dans des centaines de lignes dans l’interface.

Au-delà des bases, vous pouvez importer n’importe quel type de données orienté production que Kitsu comprend : séquences, plans, épisodes, ou même des productions entières. Cela rend trivial la duplication de la structure d’un show précédent ou le lancement d’une nouvelle saison avec la même mise en page et les mêmes règles de nommage.

La plupart des studios stockent déjà tout cela dans des tableurs. Traitez ces tableurs comme des sources de données, alimentez-les directement dans Kitsu, et laissez l’automatisation faire le travail de configuration.

Si l’interface de Kitsu prend en charge des imports basiques de tableurs, la programmation va beaucoup plus loin : avec l’API Python de Kitsu (Gazu), vous pouvez enchaîner des automatisations comme synchroniser des tâches depuis Notion, mettre en miroir votre gestionnaire d’assets, ou régénérer des listes de tâches chaque fois que le planning change.

1. Analyseur CSV

La première étape consiste à standardiser la manière dont vous lisez les données de studio. Le CSV est idéal : il est simple pour la production de l’éditer, et simple pour les scripts de le parser.

Dans ce tutoriel, nous allons nous concentrer sur le modèle de données des artistes pour plus de simplicité, mais nous pourrions faire quelque chose de similaire avec des assets stockés dans Google Drive, ou des tâches dans Trello.

def load_csv(file_path: Path) -> pd.DataFrame:
    """Load a CSV file into a pandas DataFrame."""
    return pd.read_csv(file_path)
def parse_artists(df: pd.DataFrame) -> ListDict:
"""
Expected columns:
- email
- first_name
- last_name
- role
"""
return df.to_dict(orient="records")

load_csv est le point d’entrée qui transforme un fichier CSV brut en quelque chose avec lequel Python peut travailler. Il lit le fichier depuis le disque à l’aide de pandas et renvoie un DataFrame, vous donnant une représentation structurée de type tableur que vous pouvez filtrer, valider ou transformer avant d’envoyer quoi que ce soit à Kitsu.

parse_artists prend un DataFrame représentant des données d’artistes et convertit chaque ligne en un dictionnaire contenant l’e-mail, le nom et le rôle d’un artiste. En renvoyant une liste de ces dictionnaires, vous produisez des données prêtes pour l’API qui peuvent être transmises directement à Kitsu ou Gazu pour créer des utilisateurs en masse, au lieu d’ajouter des artistes un par un.

Un studio d’animation TV qui exporte des listes d’équipe depuis Google Sheets peut simplement les enregistrer en CSV, par exemple. La production conserve la responsabilité des données, tandis que les TD automatisent l’ingestion sans demander des changements de format à chaque show.

2. Auth Kitsu

Avant de téléverser quoi que ce soit, vous devez vous authentifier auprès de votre instance Kitsu :

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

En pratique, les studios utilisent souvent un compte pipeline ou admin dédié pour l’automatisation. Cela évite les problèmes de permissions et maintient les journaux d’audit propres lorsque des scripts créent ou modifient des données.

Pour les tests locaux, il est conseillé de utiliser l’installation kitsu-docker.

3. Chargement des données

Les artistes sont généralement le premier goulot d’étranglement pendant l’onboarding. Vous devez collecter des e-mails, envoyer des invitations, les assigner à des tâches… automatiser leur création supprime des heures de travail manuel pour les coordinateurs de production.

def upload_artists(artists: ListDict):
"""
Create artists if they do not already exist.
"""
existing_users = {
user"email": user
for user in gazu.person.all_persons()
}
for artist in artists:
    if artist["email"] in existing_users:
        print(f"Artist exists: {artist['email']}")
        continue

    gazu.person.new_person(
        artist["first_name"],
        artist["last_name"],
        artist["email"],
    )
    print(f"Created artist: {artist['email']}")

Cette fonction prend une liste de dictionnaires d’artistes et les synchronise dans Kitsu tout en évitant les doublons.

Elle commence par interroger Kitsu pour tous les utilisateurs existants et construire une table de recherche indexée par e-mail, ce qui permet de vérifier rapidement si un artiste existe déjà.

Ensuite, elle parcourt les données d’artistes entrantes et, pour chaque entrée, compare l’e-mail avec cette table de recherche : si une correspondance est trouvée, le script ignore la création et journalise le fait que l’artiste existe déjà. Si aucune correspondance n’est trouvée, il crée un nouvel utilisateur dans Kitsu en utilisant le nom et l’e-mail de l’artiste via l’API Gazu, puis affiche une confirmation.

Le résultat est une étape d’import « idempotente » que vous pouvez relancer sans risque : les nouveaux artistes sont ajoutés, les artistes existants restent inchangés.

Lors d’un ramp-up pour un long-métrage, un studio pourrait importer des centaines d’artistes depuis les données RH en moins d’une minute. Les embauches tardives peuvent être ajoutées simplement en mettant à jour le CSV et en relançant le script sans dupliquer des utilisateurs ni faire de vérifications manuelles.

4. Tout relier ensemble

Le point d’entrée principal assemble tout :

if name == "main":
gazu.set_host("http://localhost/api")
user = gazu.log_in("admin@example.com", "mysecretpassword")
artists_df = load_csv(Path("artists.csv"))

artists = parse_artists(artists_df)

upload_artists(artists)

Ce bloc ne s’exécute que lorsque le fichier est lancé directement, et non lorsqu’il est importé par un autre module.

Après l’authentification, il charge le fichier artists.csv dans un DataFrame pandas, convertit ces lignes en une liste de dictionnaires d’artistes via parse_artists, puis récupère une production existante dans Kitsu par son nom.

Enfin, il appelle upload_artists, qui se charge d’itérer sur ces données préparées et de créer les comptes d’artistes dans Kitsu, en complétant l’étape d’onboarding automatisée sans aucun travail manuel dans l’interface.

En pratique, les studios versionnent ces scripts avec leurs outils de pipeline. Un nouveau show devient une commande répétable, pas une checklist.

À présent, vous pouvez vous reconnecter à votre tableau de bord Kitsu et voir le résultat final :

Jetez un œil à notre dépôt Github correspondant pour un exemple fonctionnel que vous pouvez facilement fork afin de l’adapter à vos besoins !

Conclusion

Dans le meilleur des cas, l’automatisation de Kitsu permet aux directeurs techniques de reprendre le contrôle sur la manière dont les productions naissent. Lorsque votre pipeline peut se créer lui-même à partir de données propres, l’onboarding ne devient plus une corvée. En important directement les artistes, les assets et les tâches dans Kitsu, vous éliminez le travail redondant, réduisez les erreurs humaines et rendez l’onboarding de production prévisible. Cette approche s’adapte des petites équipes aux studios produisant plusieurs shows.

Voici quelques fonctionnalités supplémentaires que vous pourriez ajouter pour rendre votre pipeline d’importation encore plus intéressant :

• assigner automatiquement les tâches aux artistes en fonction de leur rôle
• remplir les départements pour le suivi de production
• générer des estimations de départ et des calendriers spécifiques à chaque département à partir de contraintes budgétaires
• transformer un script en liste de découpage pour chaque plan et l’utiliser pour pré-générer des assets

La liste pourrait continuer, mais il suffit de commencer petit !