Chez CGWire, la raison numéro un pour laquelle nous entendons que des personnes veulent quitter Shotgrid tient à son coût et à sa complexité : la licence par poste, les offres de support pour les entreprises, les frais de consultant et de maintenance, ainsi que des 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 gérant 40 postes peut facilement faire exploser le budget.
Kitsu est l’alternative qui a, en silence, mûri pour devenir un solide outil de suivi de production. Il est open-source, activement maintenu par notre équipe, conçu autour d’une API REST claire, et fait pour être hébergé et détenu par vous. Les artistes aiment vraiment l’utiliser, ce qui n’est pas trivial lorsqu’on leur demande de modifier leur flux de travail quotidien.
Le problème, c’est qu’une migration de Flow vers Kitsu est un vrai projet d’ingénierie. Les studios qui planifient la migration avec autant de soin qu’une livraison de production sortent avec 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 même de toucher à un seul fichier de configuration, la première tâche consiste à comprendre précisément ce que vous avez dans Autodesk Flow.
Phase 1 : audit et évaluation
La plupart des studios ont accumulé des années de dette technique au sein de leur instance Flow : des champs personnalisés ajoutés pour un seul film, jamais retirés, des étapes de pipeline qui reflètent un workflow que personne n’utilise plus, et des intégrations construites par trois TD différents, de trois façons différentes. Une production de long métrage peut comporter des centaines de champs personnalisés répartis entre les entités de plans (shots), les assets et les tâches.
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 tout cela scriptable, et c’est le bon choix, car le même code deviendra une partie de votre pipeline de migration en phase 3.
En parallèle, vous devez documenter chaque outil de pipeline qui lit ou écrit dans Flow : chargeurs (loaders), éditeurs (publishers), hooks de statut, intégrations de review, ainsi que tout récepteur de webhook personnalisé. Les outils qui ont cinq dépendances en aval ou plus constituent des risques de migration prioritaires. Un studio qui a intégré l’outil de review de Ftrack, les callbacks de statut de Deadline, et un publisher Nuke personnalisé via le système de webhooks de Flow devra prévoir un temps de ré-configuration important.
Un audit implique aussi de s’entretenir avec les responsables de département. Dans la plupart des studios, on est surpris par ce qu’on apprend. Les responsables rapportent souvent qu’ils ont cessé d’utiliser les outils d’enchères (bidding) de Flow lors d’une production antérieure, parce que l’interface était trop lente, ou bien que des superviseurs lighting ont construit leurs propres solutions de contournement sous forme de tableurs pour suivre les versions de rendu, parce que la comparaison des versions dans Flow n’était pas suffisamment fiable. Savoir quelles fonctionnalités sont réellement utilisées et lesquelles ont été contournées détermine où l’effort de migration doit réellement aller pour atteindre un niveau minimum d’équivalence fonctionnelle : nombre d’entités, volumes d’appels API par jour, schéma des intégrations, et liste des fonctionnalités qui comptent vraiment.
Une fois l’audit terminé, la phase de planification traduit ce que vous avez dans Flow vers ce que vous allez construire 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 cartographier 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 tâche liée, ou sur un attribut personnalisé, selon la manière dont vous configurez l’instance. Un studio qui migre une production de 800 shots avec 12 types de tâches par shot doit définir cette cartographie à l’avance.
La décision entre Kitsu Cloud et une solution auto-hébergée se joue aussi ici.
L’auto-hébergement offre un contrôle total, peut coûter moins cher à grande échelle, et maintient les données de production derrière votre propre pare-feu, ce qui est requis par certains clients sur certains marchés. Le compromis est qu’un ingénieur DevOps doit prendre en charge le déploiement, les sauvegardes et la disponibilité (uptime).
Kitsu Cloud supprime cette charge au prix d’un abonnement mensuel et d’une dépendance à l’infrastructure de CGWire.
Le déploiement sur site (on-premise) fait la passerelle entre les deux : vos données restent physiquement dans votre structure et sous vos politiques de sécurité, mais vous pouvez les faire tourner sur du matériel géré ou sur un équipement de cloud privé, sans devoir repartir de zéro pour construire une expertise Kubernetes.
Chaque intégration / automatisation identifiée en phase 1 obtient une décision écrite : porter, remplacer ou mettre à la retraite. 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’à une seule production peut être supprimé.
La liste devient le découpage du travail d’ingénierie qui alimentera la timeline de migration. La migration est « terminée » lorsque chaque élément de cette liste a été résolu et documenté, pas lorsque le dernier import de shots réussit.
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.
Les scripts Python utilisant l’API REST de Flow fonctionnent bien ici, et les écrire comme des jobs ETL journalisés plutôt que comme de simples scripts ponctuels vaut le coup lorsque vous devez les relancer après avoir corrigé une erreur de cartographie. 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 aplati des structures imbriquées comme les fils de discussion de notes et les liens de versions, essentiels pour la migration, et vous perdrez des données silencieusement. Un fichier JSON par type d’entité, accompagné d’un fichier manifeste qui enregistre les totaux de lignes et les checksums, vous donne quelque chose à valider avant que le côté import ne commence.
La cartographie des statuts de tâches mérite une attention particulière : Flow et Kitsu utilisent des vocabulaires de statuts différents, et le mapping est rarement univoque. Un statut Flow « rev » (en attente de review) peut correspondre à « wfa » (en attente d’approbation) dans Kitsu, mais un statut Flow « hld » (en attente / en pause) peut ne pas avoir d’équivalent direct dans Kitsu et nécessiter une décision manuelle sur l’endroit où ces shots doivent atterrir. Chaque statut, étape de pipeline et type de tâche doit avoir un mapping documenté dans un tableur partagé avant que les scripts de migration ne tournent.
Une migration pilote sur un projet unique déjà terminé est non négociable. Exécuter le pipeline d’import complet sur un projet déjà « emballé » donne à l’équipe un environnement sûr pour détecter les incompatibilités de schéma, les problèmes d’encodage, les thumbnails manquants et les fils de notes cassés, sans aucun risque pour la production. Les projets actifs passent en dernier, après que toutes les validations sont terminées.
La démarche recommandée consiste à déployer une instance de test locale de Kitsu en utilisant 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, lancez le pipeline complet, puis utilisez gazu pour interroger le résultat et le comparer (diff) à vos manifestes d’export.
Quand les données migrent proprement, la couche « outils » est la partie la plus difficile du projet.
Phase 4 : ré-assemblage des outils et des intégrations
C’est ici que le pipeline de production devient encore plus complexe : le publisher Nuke qui inscrit une version dans Flow à chaque soumission de rendu, le loader Maya qui récupère l’asset approuvé le plus récent, le callback Deadline qui bascule le statut d’une tâche quand un job de ferme 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 API directes.
Kitsu couvre les opérations de tracking centrales qui comptent ici mais diffère de ShotGrid sur quelques points qu’il vaut mieux identifier avant de commencer le ré-assemblage :
- Le casting et le breakdown sont natifs dans Kitsu avec 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 quota et des timesheets est lié directement aux plannings et aux types de tâches dans Kitsu, ce qui simplifie la planification des charges par artiste sans la configuration personnalisée 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 garde la review dans l’application, et le partage externe est généralement géré par un outil compagnon.
- Les API 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 modèles de système de fichiers. La logique vit dans SGTK, et elle doit être reconstruite explicitement.
Les outils basés sur SGTK doivent être remplacés ou ré-emballés. 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’intégralité de leur pipeline autour du contexte et du 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 chemins plus explicite et réduire la complexité accumulée des templates SGTK.
Les tests, c’est là que la migration gagne son droit d’aller en production.
Phase 5 : tests et validation
Des shots représentatifs parcourent l’ensemble de la chaîne Kitsu : création des tâches, mises à jour des statuts, publication des fichiers, upload des versions, review des playlists et livraison. « Représentatif » signifie des shots qui couvrent les cas limites plutôt que de ne tester que le scénario « heureux ». Un projet multi-séquences avec 1 200 shots et des assets partagés fera remonter des problèmes de modèle de données qu’un projet de test de 50 shots n’aurait jamais révélés. Une séquence avec des hiérarchies d’assets imbriquées, un shot avec 40 tâches ou plus, une version avec des annotations orientées client : voilà des exemples de shots qui devraient entrer dans les tests de résistance.
La vérification des données consiste à recouper un échantillon d’enregistrements migrés avec les données d’origine depuis Flow, avec un responsable de review par type d’entité. Un coordinateur confirme que les métadonnées des shots 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 le sont avec 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 de permissions Flow complexes devront ré-implémenter une partie de cette logique via des règles de visibilité par type de tâche et par appartenance aux projets. Un studio qui avait configuré Flow de manière à ce que des clients puissent voir les versions mais ne pas les télécharger devra mapper ce comportement vers le modèle d’accès client de Kitsu. Tester cela avec de vrais comptes côté client avant le passage en production évite un incident embarrassant de sur-partage 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 gérée de manière insuffisante.
Phase 6 : formation des artistes et déploiement
L’ordre de déploiement qui fonctionne est : superviseurs d’abord, puis une équipe pilote, puis un département, puis l’ensemble du studio. Annoncer la migration à tout le studio le premier jour, avant que les superviseurs n’aient été briefés, garantit une boîte mail remplie de plaintes confuses qu’ils ne peuvent pas résoudre.
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 votre statut de tâche actuel » est plus utile que « Introduction au tableau des tâches Kitsu ». Un département de compositing comptant 15 artistes qui vérifient le statut des tâches et uploadent des versions huit fois par jour a besoin d’une documentation qui correspond exactement à ce qu’ils font, en utilisant le langage réel de l’interface de Kitsu. Les captures d’écran de l’instance Kitsu en conditions réelles valent plus que n’importe quelle quantité d’explications écrites.
Vous pouvez consulter notre documentation produit pour des workflows courants destinés aux artistes, superviseurs, producteurs et clients.
Les sessions de formation doivent utiliser des données Kitsu réelles issues d’un projet réellement migré. Montrer à un animateur ses vraies tâches, ses vraies affectations d’assets et ses vrailles informations de deadline dans Kitsu supprime l’aspect abstrait qui rend 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 concrets, et qui peut répondre au premier flux de questions avant que l’équipe pipeline n’ait besoin d’intervenir. Le champion du département rig d’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 utilise le système depuis plus longtemps que tout le monde.
Pendant la période de recouvrement, à la fois Flow et Kitsu sont en service : c’est inconfortable sur le plan opérationnel, 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é qui peut diagnostiquer les problèmes et extraire des données si nécessaire. Les shots en livraison finale restent généralement dans Flow pendant toute la durée, car tirer un shot en cours dans le nouveau pipeline au milieu du flux représente un risque qui ne se justifie presque jamais. Un show qui livre des finales sur six semaines reste sur Flow pour ces six semaines.
Chaque problème d’intégration Kitsu est consigné dans une file dédiée et relu chaque semaine pour repérer des schémas. Un seul artiste qui signale que le client Python Kitsu expire sur des uploads volumineux de versions correspond à un ticket de support. Cinq artistes de trois départements qui rapportent la même chose la même semaine révèlent un problème systémique qui provient probablement d’une configuration serveur et doit être remonté en haut de la file immédiatement.
Un « gel des fonctionnalités » pendant la fenêtre de transition vaut la peine d’être imposé même quand la pression d’ajouter des éléments dans Kitsu est forte. Quand un studio a trois semaines de production en parallèle, chaque département a une liste d’envies (wishlist) de personnalisations Kitsu : nouveaux types de tâches, statuts personnalisés, champs de métadonnées supplémentaires. Ajouter ces personnalisations pendant que le pipeline est encore en stabilisation crée des cibles mouvantes pour l’équipe outils et rend le débogage plus difficile.
L’annulation de l’abonnement Flow ne se fait qu’après confirmation par un reviewer que chaque projet actif a été migré, archivé et validé.
Phase 8 : mise hors service 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 avoir lieu avant que quiconque ne touche aux réglages d’abonnement.
Avant la fin de l’abonnement, une archive complète de toutes les données projet d’Autodesk Flow doit être exportée dans un format portable : JSON depuis l’API, exports CSV des 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 la mise hors service de son instance Flow que des clients demandent l’historique des versions dans un litige de livraison sur un show archivé. Si vous conservez un export JSON de toutes vos tâches Flow et de toutes vos versions, récupérer cet historique sans réactiver l’abonnement est simple. L’export prend le 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 lisible par un nouveau TD pipeline, sans devoir reconstituer l’installation à partir du code.
Un post-mortem formel sur la migration capture ce qui a fonctionné, ce qui a causé des retards, et ce que le studio aurait pu faire autrement. Ce document vaut la peine d’être diffusé dans tout le studio, car les leçons tirées d’une migration de pipeline de production s’appliquent à chaque grand changement de système que le studio fera à 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 maîtrise ses données de production.
Les studios que nous avons vus réussir en toute propreté partageaient une caractéristique : ils ont lancé l’audit avant d’avoir une raison urgente de partir. Quand un 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 rogner sur ces points est exactement là que les migrations échouent.
Le meilleur moment pour commencer l’audit, c’est maintenant : documenter les intégrations, cartographier les schémas de données personnalisées et comprendre le coût réel du statu quo. Ce que l’audit révélera clarifiera soit que la migration est le bon choix, 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 : savoir 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.
