Chez CGWire, la raison n°1 pour laquelle nous entendons les gens vouloir quitter Shotgrid, c’est son coût et sa complexité : la licence par poste, les niveaux de support entreprise, les frais de consultant et de maintenance, ainsi que les années de connaissances institutionnelles intégrées dans une plateforme contrôlée par quelqu’un d’autre. Un studio d’animation de taille intermédiaire qui tourne avec 40 postes peut facilement faire exploser le budget.
Kitsu est l’alternative qui a discrètement mûri pour devenir un outil de suivi de production solide. Il est open-source, activement maintenu par notre équipe, conçu autour d’une API REST propre, et vous appartient pour l’héberger et en garder la maîtrise. Les artistes l’aiment vraiment, ce qui n’est pas trivial quand vous leur demandez de modifier leur flux de travail quotidien.
Le problème, c’est qu’une migration de Flow vers Kitsu est un véritable projet d’ingénierie. Les studios qui planifient la migration avec autant de soin que s’ils planifiaient la livraison d’un show obtiennent des coûts plus bas, plus de contrôle, et une architecture de pipeline qu’ils comprennent de bout en bout. Ce guide vous aidera à démarrer.
Avant de toucher à un seul fichier de configuration, la première tâche consiste à comprendre exactement ce que vous avez dans Autodesk Flow.
Phase 1 : audit et évaluation
La plupart des studios ont accumulé des années de dette technique dans leur instance Flow : des champs personnalisés ajoutés pour un seul show et jamais retirés, des étapes de pipeline qui reflètent un workflow que personne n’utilise plus, et des intégrations conçues de trois façons différentes par trois TD différents. Une production de long métrage peut contenir des centaines de champs personnalisés répartis entre les entités de shot, d’asset et de task.
L’audit commence par une analyse complète de chaque type d’entité : projets, shots, assets, tâches, playlists, versions et notes. L’API Python de Flow rend ce travail scriptable, et le script est le bon choix, car le même code deviendra une partie de votre pipeline de migration à la Phase 3.
En parallèle, vous devez documenter chaque outil de pipeline qui lit ou écrit dans Flow : chargeurs, publishers, hooks de statut, intégrations de revue, et tout récepteur de webhook personnalisé. Les outils qui ont cinq dépendances aval ou plus constituent des risques prioritaires pour la migration. Un studio qui a intégré l’outil de review de Ftrack, les callbacks de statut de Deadline, et un publisher Nuke personnalisé, le tout via le système de webhooks de Flow, devra budgéter un temps de reconfiguration significatif.
L’audit implique aussi de discuter avec les responsables de département. La plupart des studios sont surpris par ce qu’ils entendent. Les responsables indiquent souvent qu’ils ont arrêté d’utiliser les outils d’enchères de Flow il y a deux productions, parce que l’interface était trop lente, ou bien que des superviseurs lighting ont construit leurs propres contournements sous forme de tableur pour suivre les versions de rendus, car la comparaison de versions de Flow n’était pas assez fiable. Savoir quelles fonctionnalités sont réellement utilisées, versus celles autour desquelles les équipes se sont adaptées, permet de déterminer où l’effort de migration doit aller pour atteindre un niveau minimal de parité fonctionnelle : nombre d’entités, volumes d’appels API par jour, cartographie des intégrations, et une liste des fonctionnalités qui comptent vraiment.
Une fois l’audit terminé, la phase de planification convertit ce que vous avez dans Flow en ce que vous construirez dans Kitsu.
Phase 2 : planification et architecture
Shotgrid et Kitsu ne partagent pas le même schéma de base de données. Donc nous devons mapper les deux architectures de plateforme.
Dans Flow, une entité Shot contient directement une grande partie des métadonnées de production. Dans Kitsu, les données équivalentes peuvent se trouver sur l’entité Shot, sur une task liée, ou sur un attribut personnalisé, selon la façon dont vous configurez l’instance. Un studio qui migre un show avec 800 shots et 12 types de tâche par shot doit définir ce mapping à l’avance.
La décision entre Kitsu Cloud et hébergement en self-hosted se prend aussi ici.
Le self-hosting donne un contrôle total, peut coûter moins cher à grande échelle, et garde les données de production derrière votre propre pare-feu, ce que certains clients exigent sur certains marchés. La contrepartie : un ingénieur DevOps doit gérer le déploiement, les sauvegardes et la disponibilité.
Kitsu Cloud supprime cette charge moyennant un abonnement mensuel et une dépendance à l’infrastructure de CGWire.
Le déploiement on-premise fait l’équilibre entre les deux : vos données restent physiquement dans vos locaux, sous vos politiques de sécurité, mais vous pouvez l’exécuter sur du matériel géré ou sur une appliance cloud privée sans repartir de zéro pour construire une expertise Kubernetes.
Toutes les intégrations / automatisations identifiées en Phase 1 donnent lieu à une décision écrite : porter, remplacer ou mettre au rebut. Les chargeurs basés sur SGTK peuvent être portés vers gazu (le SDK Python de Kitsu) ou vers un client Python Kitsu personnalisé. La fonctionnalité de review est remplacée par le moteur de review natif de Kitsu. Un récepteur de webhook qui n’a jamais servi qu’à un seul show peut être abandonné.
La liste devient le découpage du travail d’ingénierie qui pilotera le calendrier de migration. La migration est « complète » quand chaque élément de cette liste a été résolu et documenté, pas quand le dernier shot est importé avec succès.
La phase de migration des données est celle où les plans rencontrent la réalité.
Phase 3 : migration des données
La première étape consiste à construire des parcours d’export scriptés depuis Autodesk Flow pour chaque type d’entité : shots, assets, tâches, versions, notes et playlists.
Des scripts Python utilisant l’API REST de Flow fonctionnent très bien ici, et les écrire comme des jobs ETL journalisés plutôt que comme des scripts « one-off » paie lorsque vous devez les relancer après avoir corrigé une erreur de mapping. Un studio qui migre une série épisodique de 500 shots doit s’attendre à écrire des scripts d’export distincts pour chaque type d’entité, chacun avec sa propre table de mapping de champs et une étape de validation.
Les cibles d’export doivent être du JSON plutôt que du CSV, car le CSV aplatit des structures imbriquées comme les threads de notes et les liens de versions, qui sont centraux pour la migration, et vous perdez des données silencieusement. Un fichier JSON par type d’entité, accompagné d’un fichier manifeste qui enregistre le nombre de lignes et des checksums, vous donne quelque chose à valider avant que l’import ne commence.
Le mapping des statuts de tâche mérite une attention particulière : Flow et Kitsu n’utilisent pas le même vocabulaire de statuts, et le mapping est rarement « un pour un ». Un statut Flow de « rev » (pending review) peut correspondre à « wfa » (waiting for approval) dans Kitsu, mais un statut Flow de « hld » (on hold) peut ne pas avoir d’équivalent direct dans Kitsu et nécessite une décision manuelle sur l’endroit où atterrissent ces shots. Chaque statut, étape de pipeline et type de tâche doit être mappé et documenté dans un tableur partagé avant que les scripts de migration ne tournent.
Une migration pilote sur un projet unique terminé est non négociable. Lancer le pipeline d’import complet sur un projet déjà bouclé donne à l’équipe un environnement sûr pour détecter les divergences de schéma, les problèmes d’encodage, les thumbnails manquantes et les threads de notes cassés, sans aucun risque pour la production. Les projets actifs passent en dernier, une fois toute la validation terminée.
L’approche recommandée consiste à déployer une instance de test Kitsu locale via l’image Docker officielle cgwire/kitsu pour vous offrir un environnement entièrement fonctionnel en moins de dix minutes.
Pointez vos scripts d’import vers cette instance, exécutez tout le pipeline, puis utilisez gazu pour interroger le résultat et le comparer aux manifestes d’export.
Quand les données migrent correctement, c’est la couche outils qui représente la partie la plus difficile du projet.
Phase 4 : reconfiguration des outils et des intégrations
C’est ici que le pipeline de production devient encore plus complexe : le publisher Nuke qui incruste une version dans Flow à chaque soumission de rendu, le chargeur Maya qui récupère l’asset approuvé le plus récent, le callback Deadline qui change le statut d’une tâche quand un job du farm se termine… chacun de ces outils a Flow codé en dur dans sa logique d’intégration, soit via des appels de session SGTK, soit via des requêtes d’API directes.
Kitsu couvre les opérations de suivi essentielles ici, mais diffère de ShotGrid sur quelques points qu’il vaut mieux identifier avant de reconfigurer :
- Le casting et le breakdown sont natifs dans Kitsu via des vues dédiées, tandis que ShotGrid les gère via des relations d’entités qui demandent davantage de configuration.
- Le suivi de la quota et des feuilles de temps se relie directement aux calendriers et aux types de tâche dans Kitsu, ce qui simplifie la planification des charges par artiste sans la configuration sur mesure que ShotGrid nécessite généralement pour obtenir le même résultat.
- En review, Kitsu génère des URL de playlist partageables qu’un membre de l’équipe peut ouvrir et annoter. ShotGrid maintient la review à l’intérieur de l’application, avec un partage externe généralement géré par un outil compagnon.
- Les APIs diffèrent aussi : Kitsu expose une API REST avec gazu comme client Python documenté, tandis que l’API Python propriétaire de ShotGrid est bien établie en VFX, mais reste dans l’écosystème Autodesk.
- La seule capacité que Kitsu ne reproduit pas est un gestionnaire de templates de système de fichiers. La logique vit dans SGTK, et doit être reconstruite explicitement.
Les outils basés sur SGTK doivent être remplacés ou enveloppés à nouveau. Là encore, l’équipe CGWire maintient gazu pour couvrir la plupart des opérations que tk-core de SGTK gère. Un publisher qui utilisait sgtk.platform.current_bundle().shotgun.find_one() pour retrouver une entité Shot est remplacé par gazu.shot.get_shot_by_name(). La logique est similaire. Les studios qui ont construit l’ensemble de leur pipeline sur le contexte et le système de templates de SGTK devront reproduire cette logique de résolution de chemin dans leur propre code. Certains studios profitent de ce moment pour adopter une convention de chemin plus explicite et réduire la complexité cumulée des templates SGTK.
Les tests sont là où la migration gagne le droit d’aller en production.
Phase 5 : tests et validation
Des shots représentatifs passent par toute la chaîne Kitsu : création de tâches, mise à jour des statuts, publication des fichiers, upload des versions, review via playlist et livraison. « Représentatif » signifie des shots qui couvrent les cas limites, pas seulement le scénario heureux. Un projet multi-séquences avec 1 200 shots et des assets partagés mettra en évidence des problèmes de modèle de données qu’un projet de test à 50 shots ne révélerait jamais. Une séquence avec des hiérarchies d’assets imbriquées, un shot avec 40+ tâches, une version avec des annotations orientées client : ce sont de bons exemples de shots à inclure dans le test de résistance.
La vérification des données consiste à croiser un échantillon d’enregistrements migrés avec les données Flow d’origine, avec un relecteur par type d’entité. Un coordinateur confirme que les métadonnées de shot correspondent. Un TD confirme que les chemins des fichiers de version se résolvent correctement. Un superviseur confirme que les notes et annotations transférées ont la bonne attribution d’auteur et le bon horodatage. Les studios qui sautent cette étape peuvent découvrir des problèmes d’intégrité des données trois mois après la migration.
Les tests du modèle de permissions et d’accès sont souvent repoussés tard dans le processus, mais le système de rôles de Kitsu est différent de celui de Flow : Kitsu utilise un modèle d’accès plus simple avec moins de niveaux de privilèges intégrés. Cela signifie que les studios ayant des configurations complexes de permissions dans Flow devront réimplémenter une partie de cette logique via des règles de visibilité par type de tâche et l’appartenance aux projets. Un studio qui avait configuré Flow pour que les clients puissent voir mais pas télécharger les versions doit mapper ce comportement au modèle d’accès client de Kitsu. Tester cela avec de vrais comptes orientés client avant le lancement évite un incident d’accès trop large, embarrassant, lors de la première review client.
Une migration technique peut être parfaite et le déploiement peut quand même échouer si la communication avec les artistes est mal gérée.
Phase 6 : formation des artistes et déploiement
Le séquencement qui fonctionne est le suivant : superviseurs d’abord, puis une équipe pilote, ensuite un département, puis l’ensemble du studio. Annoncer la migration à tout le studio le jour 1, avant que les superviseurs aient été briefés, garantit une boîte mail remplie de plaintes confuses auxquelles ils ne pourront pas répondre.
La documentation écrite doit couvrir les dix workflows que les artistes exécutent chaque jour, rédigés sous forme d’étapes orientées tâches : « Comment vérifier le statut de votre tâche actuelle » est plus utile que « Introduction au tableau de tâches Kitsu ». Un département de compositing qui compte 15 artistes vérifiant le statut des tâches et téléversant des versions huit fois par jour a besoin d’une documentation qui correspond exactement à ce qu’ils font, en utilisant le langage de l’interface réelle de Kitsu. Des captures d’écran de l’instance Kitsu en production valent plus que n’importe quelle quantité d’explications écrites.
Vous pouvez vous référer à notre documentation produit pour des workflows courants pour les artistes, superviseurs, producteurs et clients.
Les sessions de formation doivent utiliser des données Kitsu réelles issues d’un projet effectivement migré. Montrer à un animateur ses vraies tâches, ses vraies attributions d’assets et ses vraies informations de deadline dans Kitsu supprime l’aspect abstrait qui rend souvent la formation déconnectée du travail quotidien.
Chaque département peut aussi désigner un « champion » Kitsu : quelqu’un qui a suivi la formation une semaine plus tôt, qui a résolu quelques problèmes réels, et qui peut traiter la première vague de questions avant même que l’équipe pipeline ait besoin d’intervenir. Le champion du département rigging, dans un studio de taille intermédiaire, peut résoudre 80 % des questions de la première semaine sans escalader un seul ticket, simplement parce qu’il a utilisé le système plus longtemps que tout le monde.
Pendant la période de chevauchement, à la fois Flow et Kitsu sont en service : opérationnellement c’est inconfortable, mais souvent nécessaire dans notre expérience.
Phase 7 : production en parallèle et stabilisation
Autodesk Flow reste accessible avec un ingénieur assigné, capable de diagnostiquer les problèmes et de récupérer des données si nécessaire. Les shots en livraison finale restent généralement dans Flow jusqu’au bout, parce que faire entrer un shot « en cours » dans le nouveau pipeline au milieu du flux est un risque qui se justifie rarement. Un show qui livre ses finalisations en six semaines reste sur Flow pendant ces six semaines.
Chaque problème d’intégration Kitsu est consigné dans une file dédiée et révisé chaque semaine pour repérer des schémas. Une seule artiste qui rapporte que le client Python de Kitsu expire sur les gros uploads de versions, c’est un ticket de support. Cinq artistes de trois départements qui rapportent la même chose au cours de la même semaine, c’est un problème systémique qui provient probablement d’une configuration serveur et doit passer en tête de file immédiatement.
Il vaut la peine d’imposer un gel des fonctionnalités pendant la fenêtre de transition, même quand la pression pour ajouter des éléments à Kitsu est forte. Quand un studio est à trois semaines de production en parallèle, chaque département a une liste d’envies d’ajustements Kitsu : nouveaux types de tâches, statuts personnalisés, champs de métadonnées supplémentaires. Ajouter ces ajustements pendant que le pipeline est encore en cours de stabilisation crée des cibles mobiles pour l’équipe outils et rend le débogage plus difficile.
L’annulation de l’abonnement Flow ne se fait qu’après avoir confirmé la migration de chaque projet actif, puis après archivage et validation par un relecteur.
Phase 8 : décommissionnement et documentation
Le fait que des superviseurs valident qu’un show est entièrement passé sur Kitsu n’est pas la même chose que le fait qu’un TD vérifie que les données Flow archivées sont complètes, exportables et récupérables. Les deux vérifications doivent être faites avant que quiconque touche aux paramètres d’abonnement.
Avant que l’abonnement ne prenne fin, une archive complète de toutes les données de projet d’Autodesk Flow doit être exportée dans un format portable : JSON depuis l’API, exports CSV de listes d’entités, et versions téléchargées de tout média stocké dans le système de fichiers de Flow. Un studio d’animation peut découvrir deux ans après avoir décommissionné son instance Flow qu’un client demande l’historique des versions dans le cadre d’un litige sur une livraison d’un show archivé. Si vous conservez un export JSON de toutes vos tâches Flow et de vos enregistrements de versions, récupérer cet historique sans réactiver l’abonnement est trivial. L’export prend un week-end et ne coûte rien.
La documentation du nouveau pipeline Kitsu couvre le modèle d’entités, les définitions des types de tâches, les points d’intégration et les emplacements de configuration, dans un format que peut lire un nouveau TD pipeline sans avoir besoin de reconstituer la configuration à partir du code.
Un post-mortem formel sur la migration consigne ce qui a fonctionné, ce qui a causé des retards, et ce que le studio aurait pu faire différemment. Ce document vaut la peine d’être distribué à tout le studio, car les leçons d’une migration de pipeline de production s’appliquent à chaque changement majeur de système que le studio effectuera à l’avenir.
Conclusion
Une migration de Shotgrid vers Kitsu réalisée de manière systématique produit un studio qui paie moins, comprend ses propres outils et conserve la maîtrise de ses données de production.
Les studios que nous avons vus réussir le faisaient partager une caractéristique : ils ont commencé l’audit avant d’avoir une raison urgente de partir. Quand le renouvellement de licence est à trois mois et que le devis vient juste d’arriver, la pression pour rogner sur la phase de planification est énorme. Mais supprimer ces marges, c’est exactement là que les migrations échouent.
Le meilleur moment pour démarrer l’audit, c’est maintenant : documenter les intégrations, mapper les schémas de données personnalisés et comprendre le coût réel de l’état actuel. Ce que révèle l’audit clarifiera soit que la migration est la bonne décision, soit mettra en évidence les problèmes spécifiques qui doivent d’abord être résolus.
L’équipe CGWire propose un accompagnement direct pour les migrations pour les studios qui passent de ShotGrid à Kitsu. N’hésitez pas à nous contacter avant de vous engager sur un calendrier : connaître ce qui s’est mal passé dans d’autres migrations vaut plus que la plupart du temps de planification que vous passerez sans ce contexte.
