Le pipeline d’animation qui vous a menés là où vous êtes ne vous mènera pas forcément là où vous voulez aller.
Peut-être que votre rendu ralentit l’itération sur le lookdev. Peut-être que votre framework de rigging a été construit pour un seul film et qu’il a été maintenu à coup de contournements depuis. Peut-être que vous avez adopté USD sur le papier, mais que votre production réelle continue de fonctionner sur un patchwork d’exporteurs et de convertisseurs de formats sur mesure que personne ne comprend totalement plus aujourd’hui.
Le coût de rester sur le pipeline actuel dépasse lentement le coût de le remplacer, et la question devient : comment migrer sans mettre la production à terre.
Cet article répond à cette question : nous allons parcourir un processus étape par étape pour la migration de pipeline dans le contexte d’une production en cours, depuis l’audit initial jusqu’à la désactivation. Chaque section inclut des enseignements actionnables afin de donner aux pipeline TD et aux superviseurs VFX un cadre réaliste qu’ils peuvent réellement exécuter.
Pourquoi vous avez besoin d’une stratégie de migration
Passer à une pile de pipeline moderne libère des itérations de plans plus rapides, de meilleures conditions d’ergonomie pour les artistes, des coûts de licences plus faibles, et l’accès à un vivier de talents plus large. Par exemple, les studios qui adoptent USD comme couche commune de description de scène réduisent le nombre de scripts d’échange sur mesure qu’ils maintiennent, ce qui diminue directement la charge de l’ingénierie pipeline par production.
Mais une migration de pipeline n’est pas un projet purement technique. Vous ne pouvez pas simplement remplacer les outils, mettre à jour les scripts, puis passer à autre chose. La perte de données lors de la conversion des assets est le risque le plus visible, mais ce n’est presque jamais le plus dommageable.
Un risque plus insidieux est la résistance des artistes face à des outils inconnus, qui peut détruire silencieusement le débit sans apparaître dans un gestionnaire de bugs.
Un autre risque est de sous-estimer la profondeur des dépendances historiques. Par exemple, un studio qui migre depuis un outil propriétaire d’assemblage de plans peut découvrir en plein milieu de production que son système d’envoi de rendus, son pipeline de daily, et son relais éditorial appellent tous directement des fonctions internes de cet outil. Le remplacer signifierait réécrire les trois systèmes en même temps, sous pression de calendrier.
Une stratégie de migration n’élimine pas ces risques, mais les rend visibles assez tôt pour les gérer. La même logique s’applique lors de la migration de logiciels de suivi de production. Chez CGWire, nous avons conçu notre stratégie de migration pour Kitsu en tenant compte de cette réalité : plutôt que d’imposer une bascule brutale, nous aidons les studios à planifier la transition pour que la production continue d’avancer pendant que le changement se fait en dessous.
Phase 1 : Audit et évaluation
Avant tout, il est crucial de savoir exactement ce que vous migrez avec un inventaire exhaustif : chaque outil DCC utilisé activement, chaque script sur mesure, chaque preset de rendu, chaque outil d’envoi, et chaque plugin pipeline doit être documenté. S’appuyer sur la mémoire ou sur la connaissance d’un seul senior TD finit souvent par laisser des trous. Un sondage à l’échelle du studio, recoupé avec les logs du render farm, fera remonter les outils réellement utilisés, mais non officiellement pris en charge.
Une fois l’inventaire en main, documenter comment les pièces s’assemblent devient la priorité suivante. Quels outils écrivent dans quels répertoires ? Quels scripts supposent une version précise d’un DCC ? Quelles intégrations de gestion d’assets cassent si la structure des dossiers change ? Une cartographie des dépendances est le document qui évite les surprises les plus coûteuses. Mapper les outils comme des nœuds avec une arête orientée dessinée chaque fois qu’un outil appelle, lit ou écrit dans un autre révélera rapidement tout nœud ayant cinq entrées ou plus : ce sont des risques de migration qui méritent un plan à part entière.
Cette phase d’audit est aussi le bon moment pour passer en revue votre configuration de suivi de production. Avant que n’importe quel outil ne change de mains, vous devez avoir une image claire de vos structures de tâches actuelles, de vos hiérarchies de projet, de vos workflows de statuts, et des rôles des équipes. Lorsque les studios migrent vers Kitsu, CGWire démarre ici : examiner le setup existant en détail et le traduire vers Kitsu sans forcer des changements inutiles dans la façon dont le studio fonctionne déjà.
Chaque partie du pipeline ne mérite pas le même effort de migration. Interroger les responsables de département pour comprendre où le pipeline actuel fait perdre le plus de temps aide à définir les bonnes priorités. Un workflow de rigging qui exige trois étapes manuelles d’export avant que l’animation puisse commencer est plus prioritaire qu’un script de livraison légèrement obsolète qui ne s’exécute qu’une fois par semaine. Documenter explicitement les points de douleur garantit que la migration s’attaque d’abord aux zones à plus fort impact.
Les rigs, caches, fichiers de scène et shaders portent tous des hypothèses implicites sur le logiciel qui les a générés. Un pipeline basé sur USD aura des conventions différentes de celles d’un pipeline centré sur Maya. Identifier quels formats de données survivront à la migration nativement, lesquels nécessitent des scripts de conversion, et lesquels sont essentiellement irréparables et exigeront une reconstruction manuelle aide à définir le périmètre de l’étape 3.
Migrer pendant le pic de production est également possible, mais cela a un coût réel. La fenêtre idéale est la transition entre productions, ou pendant une phase de préproduction lorsque la pression sur les plans est plus faible et que les artistes disposent de la bande passante pour apprendre de nouveaux outils. Lorsqu’une migration en cours de production est inévitable, une approche planifiée par département est beaucoup plus sûre qu’une bascule “tout d’un coup”.
Le coût de ne pas migrer est réel lui aussi : chaque mois de retard augmente la dette technique. Les outils historiques exigent de la maintenance, les contournements s’accumulent, et l’écart entre le pipeline actuel et les pratiques standards du secteur se creuse. Intégrer explicitement ce coût quand on argumente auprès de la production pour le timing de migration fait souvent la différence.
Auditer les licences pour savoir exactement quels contrats logiciels sont repris dans le nouveau pipeline, lesquels sont abandonnés, et lesquels doivent être renégociés est une étape dont le retour sur investissement est précoce. Les coûts de licences sont fréquemment sous-estimés dans les budgets de migration. Pour les studios qui évaluent des options de suivi de production, le modèle open source de Kitsu vaut la peine d’être pris en compte ici : il peut être hébergé sur votre propre infrastructure, ce qui compte pour les studios ayant des exigences strictes de contrôle des données ou des obligations spécifiques de sécurité client.
Avant tout changement, établir des bases de référence de performance est essentiel. Selon les KPI de votre studio, mesurer les temps de rendu pour des types de plans représentatifs, le temps de cycle d’itération de l’action de l’artiste jusqu’au résultat rendu, et les temps de publication des assets produit les données nécessaires pour démontrer que le nouveau pipeline est une amélioration. Plus précisément, choisir trois archétypes de plans représentant des complexités de production faciles, moyennes et difficiles, les exécuter de bout en bout, et enregistrer le temps réel à chaque étape vous donne des critères de réussite à comparer plus tard.
Phase 2 : Planification et architecture
Avec une vue complète de l’état actuel du pipeline, l’état cible peut être conçu de manière intelligente.
« Passer à USD » n’est pas un plan. « Adopter USD comme format principal de description de scène, remplacer le rendu propriétaire par un outil livré avec un délégué Hydra natif, et retirer le format d’échange d’assets sur mesure au profit de USDZ pour la livraison finale » est un plan. La précision compte parce que des objectifs vagues ne peuvent pas être suivis, ne peuvent pas être communiqués aux artistes, et ne peuvent pas servir à évaluer si la migration est terminée. Nommer les outils, cadres et workflows spécifiques qui composent la nouvelle pile, ainsi que des métriques d’évaluation clés, rend le plan actionnable.
Une feuille de route de migration doit indiquer ce qui est migré dans quel ordre, quels sont les critères de validation pour chaque phase, et quelle est la procédure de rollback si une phase échoue. Par exemple : la phase 1 couvre uniquement le pipeline d’assets (sans plans), validée par une revue de différence visuelle sur dix assets “hero”. La phase 2 couvre lighting et lookdev pour un seul département, validée par une comparaison complète de rendus de plans. Un repli utile pour la phase 2 pourrait consister à garder l’ancien pipeline disponible pour ce département pendant quatre semaines après la bascule.
Une stratégie de “run en parallèle” maintient les deux pipelines actifs simultanément : les artistes peuvent migrer progressivement tandis que l’ancien pipeline reste disponible. Une bascule “hard-cutover” arrête l’ancien pipeline à une date définie et fait passer tout le monde au nouveau. Le run en parallèle comporte moins de risques mais coûte plus cher à maintenir, et peut permettre à la migration de stagner indéfiniment sans date de bascule imposée. La bascule hard-cutover est plus rapide, mais nécessite une grande confiance dans le nouveau pipeline et un plan de support solide pour la période de transition. Avec Kitsu, nous commençons par l’approche en parallèle : les studios peuvent le faire tourner aux côtés de leur outil de suivi de production existant, comparer les données de tâches, les rapports d’avancement et les affectations d’artistes côte à côte, et ne s’engager pleinement que lorsque tout correspond aux attentes.
Il vaut la peine de poser tôt la question : les assets créés dans l’ancien pipeline peuvent-ils être chargés dans le nouveau ? Si oui, sous quelle forme ? En lecture seule pour référence, ou entièrement éditables ? La compatibilité arrière n’est pas toujours atteignable, mais le périmètre de ce qui est compatible et de ce qui ne l’est pas doit être documenté explicitement afin que les artistes sachent à quoi s’attendre. Un studio qui découvre en cours de production que son nouveau pipeline ne peut pas charger les fichiers de cache historiques perdra un temps considérable à reconstruire des assets qui auraient dû être gérés pendant la planification.
Le même principe s’applique aux données de production : projets, listes de plans, affectations de tâches et notes de production représentent des mois de décisions et de communication. Kitsu permet l’import structuré de ces données via CSV ou API HTTP, couvrant projets, séquences, épisodes, assets, plans, structures de tâches, workflows de statuts et commentaires, afin que l’historique du studio ne soit pas abandonné lorsque l’outil change.
Tous les assets ne sont pas aussi complexes à migrer. Un simple prop avec un shader simple présente un faible risque. Un personnage “hero” avec une simulation de muscles sur mesure, un solveur de cheveux propriétaire et des poses intégrées depuis un film précédent représente un risque élevé. Attribuer à chaque grande catégorie d’asset un niveau de risque et séquencer la migration en conséquence (d’abord les assets à faible risque pour construire la confiance et faire remonter tôt les problèmes de processus, puis les assets à risque élevé avec les leçons apprises) est une méthode fiable pour gérer l’exposition.
Encore une fois, déclarer par écrit ce que signifie “migration terminée” avant le début du travail est l’une des choses les plus précieuses qu’une équipe puisse faire. Parmi les métriques concrètes à envisager : delta de temps de rendu par rapport à la base de référence (objectif : aucune régression, idéalement une amélioration), temps de cycle d’itération (objectif : réduction mesurable par rapport à la base), absence totale d’utilisation active des outils historiques en production, et publication/chargement de tous les assets propres dans le nouveau système. Sans critères de réussite convenus, les projets de migration peuvent s’étirer indéfiniment car il n’existe aucun moyen objectif de les clôturer.
Phase 3 : Conversion des données et des assets
La différence entre une migration qui réussit et une autre qui crée des mois de reprise réside dans la qualité de la couche de conversion.
Chaque type majeur de données dans le pipeline a besoin d’un chemin de conversion scripté : fichiers de scène, exports de rigs, assignations de shaders, caches de simulation, etc. La conversion manuelle à grande échelle n’est pas faisable et introduit de l’incohérence. Par exemple, lors de la migration des shaders d’un format propriétaire vers un autre, un script de conversion qui mappe chaque type de matériau historique vers son équivalent, gère explicitement les cas limites et journalise chaque asset traité avec un statut “pass/fail” fera gagner un temps considérable tout en réduisant les erreurs.
La conversion des assets rend irréversibles, à grande échelle, les décisions de nommage et de structure. Convertir dix mille assets puis découvrir un défaut dans la convention de nommage implique de repasser sur toute la bibliothèque ; donc finaliser et documenter les conventions d’abord, puis convertir, pour éviter ce scénario.
Avant d’exécuter la conversion sur toute la bibliothèque, il est conseillé de faire des conversions pilotes sur un petit ensemble d’assets qui représente toute la diversité de la complexité de production : un prop simple, un personnage de complexité moyenne, un environnement complexe avec plusieurs sous-assets, et un cas limite qui risque de poser problème, par exemple. Une revue minutieuse des résultats de ces pilotes paie largement : les problèmes trouvés sur dix assets pilotes sont peu coûteux à corriger.
Les “visual diffs” sont la norme minimale de validation. Pour les rigs, il faut valider le comportement de la déformation, l’amplitude de contrôle, et la qualité du skinning sur un ensemble standard de poses. Pour les shaders, valider l’apparence sous plusieurs conditions d’éclairage (pas seulement une sphère grise neutre) est essentiel. Pour les caches, vérifier que le timing, l’échelle et la position en espace monde sont préservés. Définir une checklist de validation par type d’asset et exiger qu’un reviewer approuve chaque asset converti avant qu’il n’entre dans le nouveau pipeline garantit la qualité tout au long du processus.
Phase 4 : Intégration des outils et des logiciels
Convertir les assets ne représente qu’une moitié du travail : les outils qui créent, publient et consomment ces assets doivent aussi fonctionner dans le nouvel environnement.
Pour chaque plugin pipeline sur mesure, l’équipe devra prendre une décision explicite : le porter dans le nouvel environnement, le réécrire depuis zéro, ou le remplacer par une fonctionnalité native du nouveau logiciel. Porter préserve le comportement mais peut entraîner une dette technique. Réécrire est plus lent mais produit un code plus propre. Remplacer est le plus rapide lorsque le nouvel outil couvre réellement le cas d’usage. La migration est une bonne opportunité pour désactiver des plugins qui n’étaient que des contournements pour des problèmes que le nouveau pipeline n’a plus, plutôt que de tout porter par défaut par habitude.
L’intégration de la gestion d’assets est le tissu connecteur du pipeline. Elle contrôle ce que les artistes peuvent charger, publier, et la manière dont le travail circule entre les départements. Cette intégration doit être construite et validée avant le déploiement auprès des artistes, pas après. Tester la boucle complète “publish-checkout-iterate” pour chaque workflow de département dans un environnement de staging, avant que le moindre artiste n’y touche, est l’approche la plus sûre. Kitsu est conçu pour s’intégrer aux pipelines existants : son API REST et son client Python permettent aux équipes techniques de le connecter directement aux outils DCC pour publier des previews, d’interfacer avec des systèmes de render farm pour suivre les sorties, et de s’adapter aux systèmes de gestion d’assets déjà en place sans forcer une reconstruction du pipeline pour accommoder le tracker.
Un nouveau renderer implique un nouvel outil de soumission et une nouvelle configuration de farm. Il est important de tester le comportement du render farm sous charge, pas seulement sur des images uniques, car les problèmes du render farm en contexte de production sont fréquents et ne peuvent souvent pas être reproduits avec quelques images de test. Lancer un test de stress de la farm avec un lot représentatif de plans avant de déclarer le pipeline de rendu prêt pour la production est fortement recommandé.
Enfin, lorsque le nouveau pipeline change la façon dont les assets sont versionnés, nommés ou stockés, les outils de publication et de checkout doivent refléter cela précisément. Tout décalage entre le comportement des outils et l’état réel du système de fichiers mène à des références cassées, à une perte de travail, ou à des écrasements silencieux.
Phase 5 : Tests et validation
Les tests sont l’endroit où les hypothèses rencontrent la réalité.
Un plan n’est pas seulement des assets et des rendus : c’est toute la chaîne depuis l’assemblage de scène jusqu’au lighting, FX, compositing et delivery. Exécuter des plans représentatifs à travers chaque étape de cette chaîne et confirmer que la sortie à chaque étape correspond aux attentes est essentiel. Toute rupture de la chaîne non détectée en test sera détectée en production au pire moment possible.
Rendre les mêmes plans avec les deux pipelines (nouveau et ancien) et faire une comparaison côte à côte est une façon fiable de caractériser les différences. Ces différences doivent être documentées et classées : différences attendues liées aux changements de renderer, différences inattendues qui indiquent des erreurs de conversion, et différences acceptables qui ont été examinées et validées. Le but n’est pas une sortie identique, mais une sortie comprise.
Mesurer les temps de rendu, les temps de cycle d’itération et les temps de publication sur les mêmes archétypes de plans mesurés au départ est important à ce stade. Si le nouveau pipeline est plus lent, comprendre pourquoi avant le déploiement est essentiel. Une migration qui améliore la capacité mais dégrade les performances fera face à une forte résistance des artistes.
Les simulations complexes, les scènes de foule, les plans avec de nombreuses couches de références imbriquées, et les plans qui poussent les limites du rig ou du renderer sont les cas les plus susceptibles de casser sous charge. Ils méritent une attention prioritaire aux tests.
Lorsque le nouveau pipeline change la structure du système de gestion des assets ou du serveur de fichiers, le contrôle d’accès doit être validé explicitement. Les migrations élargissent parfois par inadvertance les permissions de fichiers ou cassent les contrôles d’accès au niveau des départements. Un artiste capable d’écraser accidentellement les assets publiés d’un autre département représente un risque de production : auditer les permissions au préalable est une précaution utile. Pour les studios utilisant Kitsu, c’est aussi le moment de vérifier que les vues basées sur les rôles sont correctement configurées, c’est-à-dire que les artistes voient leurs files de tâches, que les superviseurs voient leurs files de review, et que les producteurs voient les plannings et données de budget, sans chevauchement non intentionnel.
Phase 6 : Formation des artistes et déploiement
Une migration techniquement correcte que les artistes ne font pas confiance ou n’adoptent pas est un échec de migration.
Les responsables de département, les producteurs et les superviseurs VFX doivent comprendre la logique de la migration, le calendrier et ce qu’on leur demande de faire avant que leurs artistes n’en entendent parler. Les surprises détruisent la confiance : un studio qui annonce une migration de pipeline aux artistes avant que les chefs de département n’aient été briefés passera des semaines à gérer la confusion et la résistance qui auraient pu être évitées.
Une documentation de référence décrivant chaque outil du nouveau pipeline est utile. Les tutoriels pas à pas couvrant les dix workflows quotidiens les plus courants sont encore plus utiles. Écrire la documentation du point de vue de la tâche, plutôt que de l’outil, sert mieux les artistes. « Comment publier un rig » est un meilleur titre que « RigPublishTool API Reference » pour un public d’artistes.
Le modeling, rigging, animation, FX et lighting ont tous des workflows différents et des préoccupations différentes. Une seule démo “all-hands” ne suffit généralement pas. Des sessions séparées pour chaque département, centrées sur les workflows que le département effectue au quotidien, fonctionnent beaucoup mieux. La pratique en conditions réelles pendant la formation, avec un asset réel et des outils réels, est nettement plus efficace que de regarder une démo. L’approche d’onboarding de Kitsu suit le même principe : les superviseurs sont formés en premier pour pouvoir guider leurs équipes, et la formation artistes se concentre spécifiquement sur les vues de tâches et les workflows de mise à jour que chaque rôle utilise tous les jours, plutôt que sur une visite générique de la plateforme.
Un “champion” est un artiste senior ou un TD dans chaque discipline, formé avant le déploiement général, qui comprend profondément le nouveau pipeline et est disponible pour soutenir ses pairs pendant la transition. Les champions sont plus accessibles que les pipeline TD, parlent la langue de leur département, et peuvent résoudre une grande proportion des questions du quotidien sans escalade. Trouver et investir dans des champions fait partie des actions à plus fort levier lors d’un déploiement de migration.
La séquence de déploiement la plus fiable est la suivante : équipe pilote d’abord, puis un département, puis tout le studio. L’équipe pilote fait remonter les problèmes de workflow que les tests n’avaient pas captés, permet d’affiner les supports de formation, et produit des histoires de succès précoces qui réduisent la résistance lors des déploiements suivants. Résister à la pression de faire une bascule complète à l’échelle du studio dès le premier jour vaut la peine, car le risque n’est généralement pas justifié par les économies de temps.
Phase 7 : Production en parallèle et stabilisation
La fenêtre de transition entre les anciens et nouveaux pipelines est la période la plus risquée de la migration.
Pendant la fenêtre de transition, des plans peuvent être en cours sur l’ancien pipeline comme sur le nouveau. Les deux doivent être fonctionnels, surveillés et supportés. Cette approche mobilise de la bande passante pour l’ingénierie pipeline, mais l’alternative est de ne pas pouvoir livrer les plans qui sont à mi-production au moment de la bascule.
Les plans en livraison finale sur l’ancien pipeline ne devraient pas être migrés à mi-parcours. Désigner un ensemble d’ingénieurs pipeline responsables du support de l’ancien pipeline pendant la fenêtre de transition, et définir clairement quand ce support s’arrête, aide à éviter toute ambiguïté et maintient les deux côtés de la transition correctement dotés. Pour le suivi de production spécifiquement, cette fenêtre parallèle est là où l’approche côte à côte de Kitsu apporte une vraie valeur : les producteurs peuvent exécuter des rapports d’avancement et comparer les données de tâches entre les deux systèmes avant de s’engager pleinement, ce qui donne la confiance nécessaire pour fixer une vraie date de bascule plutôt que de laisser la transition s’étirer indéfiniment.
Les problèmes liés à la migration doivent être suivis séparément du support normal de production, afin de garder les tendances visibles. Si cinq artistes différents signalent la même erreur de publication dans la même semaine, c’est un problème systémique, pas cinq bugs individuels.
Pendant la fenêtre de transition, le pipeline devrait changer le moins possible parce que de nouvelles fonctionnalités introduisent de nouveaux modes de défaillance à un moment où l’équipe gère déjà un risque accru. Une politique de gel des fonctionnalités, avec exceptions uniquement pour les correctifs critiques pour la production, est la bonne approche pendant cette période.
Phase 8 : Désactivation et documentation
La migration n’est pas terminée tant que l’ancien pipeline n’est pas mis à la retraite et que le nouveau n’est pas documenté de façon approfondie.
Plutôt que de supprimer l’ancien pipeline, l’archiver dans un état où il pourrait être consulté si un asset historique doit être récupéré est l’approche la plus sûre sur le long terme. Vous pouvez étiqueter tout avec la version et la date de désactivation. Des assets livrés sur un film précédent peuvent avoir besoin d’être reconstruits des années plus tard, donc le coût de stockage en vaut la peine. Comme Kitsu est open source et peut être hébergé sur votre propre infrastructure, vos données de production restent accessibles et auditables longtemps après la fermeture d’un film. Il n’y a pas de dépendance fournisseur qui pourrait laisser des enregistrements historiques “bloqués”.
Le pipeline qui n’existe que dans la tête de trois TD seniors est un risque de continuité d’activité. Documenter l’architecture du nouveau pipeline (comment les assets y circulent, ce que fait chaque outil, quelles sont les dépendances et où se trouve la configuration) est la base pour intégrer de futurs ingénieurs pipeline et planifier la prochaine migration.
Réaliser un post-mortem formel est aussi précieux : Qu’est-ce qui a fonctionné ? Qu’est-ce qui n’a pas fonctionné ? Où le calendrier a-t-il dérapé et pourquoi ? Que ferait-on différemment ? Un post-mortem est un processus structuré pour capturer la connaissance institutionnelle avant que l’équipe ne passe à la production suivante. Les conclusions doivent être écrites et rendues disponibles à ceux qui planifieront la migration suivante.
La raison la plus courante pour laquelle les studios se retrouvent à faire des migrations d’urgence plutôt que planifiées est que le pipeline a dérivé sans gouvernance. Mettre en place un processus léger de gestion des changements, où tout changement significatif du pipeline fait l’objet d’une revue, est versionné et documenté, empêche cette dérive.
Conclusion
Les huit étapes que nous avons listées ne sont pas une garantie contre les problèmes. Les migrations sont complexes, les productions sont imprévisibles, et les systèmes historiques ont une manière de vous surprendre. Mais ce qu’apporte une approche structurée, c’est de déplacer la nature des problèmes : au lieu de surprises catastrophiques qui arrêtent la production, on obtient des problèmes gérables, découverts et corrigés dans le bon ordre.
Les principes les plus importants restent valables tout au long du processus : auditer avant de planifier, planifier avant de construire, construire avant de former, et former avant de basculer. Définir le succès explicitement et mesurer par rapport à cela. Traiter l’adoption par les artistes comme aussi importante que la justesse technique. Faire tourner en parallèle pendant la transition et imposer une date de désactivation stricte.
Une migration de pipeline n’est pas un événement ponctuel. Les studios qui construisent la discipline pour migrer proprement développent un avantage structurel par rapport à ceux qui ne le font pas : ils adoptent plus vite de nouveaux outils, portent moins de dette technique, et parviennent à attirer des ingénieurs qui veulent travailler dans un système bien maintenu.
Le processus décrit ici est la manière de construire un studio qui n’est pas pris en otage par sa propre infrastructure.
Avec Kitsu, votre équipe peut suivre les tâches, réviser les assets et consigner le temps à l’intérieur de quelques heures après l’inscription. Des studios dans plus de 50 pays, des petites agences aux grandes sociétés VFX, ont fait ce changement sans mettre en pause une production en cours.
