Au cours de sa présentation au Kitsu Submit 2026, Pete Draper a expliqué aux participants deux grandes étapes de sa carrière et comment Kitsu, la plateforme open source de suivi de production développée par CGWire, est devenue l’épine dorsale opérationnelle des deux.
Son histoire est un véritable cours magistral sur la façon dont une petite équipe peut utiliser le bon outil pour gérer une complexité à grande échelle sans perdre la tête.
Pete est un superviseur VFX avec près de trois décennies d’expérience dans l’industrie. Il a créé un studio en Inde en 2009 et a travaillé sur une quarantaine, voire une cinquantaine, de films, dont le célèbre blockbuster indien RRR, soumis pour la considération aux Oscars et ayant atteint la liste restreinte de 23 nommés dans la catégorie Meilleur film international.
Par la suite, il s’est orienté vers la technologie publicitaire (insertion virtuelle de produits), où il a occupé un rôle clé de responsable de production au sein d’une société appelée Ryff.
Sa conférence s’appuie directement sur ces deux expériences, mais l’essentiel de son intervention portait sur Ryff, là où les défis de production étaient sans commune mesure avec ceux auxquels les studios VFX traditionnels sont généralement confrontés.
Le problème : des centaines de projets, pas d’épine dorsale centrale
Lorsque Pete a rejoint Ryff en 2022, l’entreprise fonctionnait selon ce qu’il appelait un système de type « papier brouillon » : malgré un volume de travail important, l’infrastructure de production était fragmentée dans toutes les directions.
Il existait de nombreuses feuilles Google indépendantes, sans stockage de production centralisé ; des équipes réparties sur trois sites ; des revues effectuées sur des systèmes AWS distants, car les machines locales n’étaient pas assez puissantes ; et aucun système de métriques ou de reporting, de quelque manière que ce soit.
Comme l’a expliqué Pete : « Tout était essentiellement fait via des prestataires, des freelances et des développeurs, et rien n’était suivi en ce qui concerne le processus de production. »
Pour comprendre pourquoi cela comptait autant, il faut d’abord saisir ce que Ryff faisait réellement.
L’activité : l’insertion virtuelle de produits à grande échelle
Ryff exploitait une plateforme qui utilisait l’IA pour analyser des films et des séries, en identifiant des surfaces, des écrans et des espaces vides dans lesquels des placements de marques pouvaient être insérés numériquement après que le contenu avait déjà été tourné et diffusé. Comme un logo de marque apparaissant sur une table pendant une scène de dîner, ou un remplacement d’affiche visible à travers une fenêtre de voiture lors d’une séquence de poursuite.
La société avait deux catégories de clients : les propriétaires de contenus, qui fournissaient les émissions et les films, et les marques, qui payaient pour que leurs produits soient intégrés dans ce contenu. Le fait de faire correspondre ces deux parties donnait naissance à une matrice de production extraordinairement complexe : une seule affaire pouvait exiger 10 placements sur cinq émissions différentes, pour la même marque, mais avec une licence seulement pour des régions et des fenêtres temporelles spécifiques. Lorsqu’une licence expirait, une autre marque pouvait entrer et reprendre le même emplacement, ce qui obligeait à reconstruire entièrement le composite avec de nouveaux assets.
Au moment du départ de Pete, le stockage principal de Ryff contenait environ 46 000 titres et quelque 146 000 placements uniques.
Chaque placement pouvait correspondre à plusieurs plans, ce qui signifiait que le nombre réel de plans était exponentiellement plus élevé.
Sur une seule saison d’une émission, le World Poker Tour, l’équipe traitait environ 1 700 plans sur 34 épisodes, chacun contenant entre 40 et 100 plans, le tout avec une cadence de 24 heures par épisode.
Ce n’est pas le genre de problème que vous pouvez résoudre avec un tableur.
Découvrir Kitsu pendant RRR
Pete a découvert Kitsu pour la première fois fin 2018, pendant la production de RRR. Son équipe avait déjà testé plusieurs trackers de production : Tactic, Cerebro, Ftrack, ShotGrid, et d’autres. Aucun ne convenait.
« C’est un peu sorti de nulle part : le Kitsu de CGWire s’est révélé au cours d’une de mes recherches Google », a-t-il expliqué.
Il l’a testé, l’a montré à son équipe, et la réponse a été immédiate : « Pas seulement les gars de la production, mais aussi les artistes. C’était évident. C’était simple. Tu n’avais pas besoin d’un diplôme en informatique, par exemple, comme avec Tactic. »
La question de l’utilisabilité compte davantage qu’on ne pourrait le croire au premier abord. Dans un environnement de studio, un outil de tracking ne fonctionne que si l’ensemble de l’équipe l’utilise de manière cohérente. Un système qui déroute les artistes ou qui nécessite un onboarding conséquent crée des frictions au moment même où il ne faut pas—lorsque les délais approchent et que les plans doivent avancer vite.
Kitsu a aussi aidé pendant la pandémie de COVID. Le travail à distance est devenu plus gérable, car les artistes pouvaient recevoir des retours et consulter des versions depuis n’importe où, comme si leur superviseur était assis à côté d’eux.
Construire la chaîne Ryff sur Kitsu
Quand Pete a rejoint Ryff, Kitsu était sa première recommandation majeure. Mais il ne l’a pas simplement installé et renvoyé les gens vers lui.
Au fil du temps, lui et son équipe ont construit toute une infrastructure de production au-dessus de Kitsu, en l’utilisant non seulement comme un outil de revue et d’approbation, mais aussi comme un middleware reliant plusieurs systèmes.
1. Une bibliothèque d’assets centralisée
Le premier bloc de construction majeur était une bibliothèque d’assets partagée. En s’appuyant sur une structure de bibliothèque initialement développée par un autre contributeur à la plateforme, l’équipe a construit un référentiel pour chaque asset de marque qui passait par la chaîne : logos 2D, modèles 3D, structures d’affichage en extérieur (out-of-home) numériques, modèles de surplomb (overpass), et bien plus encore. Chaque asset était lié au stockage cloud S3 de Ryff et relié à des projets de production en cours.
La bibliothèque a atteint environ 2 317 assets. Chaque asset portait des métadonnées bien au-delà d’un simple nom et d’une miniature. Les entrées enregistraient la catégorie (cosmétiques, automobile, produits alimentaires et boissons, etc.), les sous-catégories (par exemple, alcoolique ou non alcoolique), les dimensions de l’asset en millimètres pour les objets 3D ou en pixels pour les éléments 2D, et si l’asset avait été fourni par la marque, obtenu auprès d’un artiste, ou construit en interne par Ryff.
Le champ des dimensions avait une application pratique directe. Chaque placement dans le système Ryff comportait aussi un paramètre d’espace défini. En recoupant ces deux informations, le système pouvait signaler automatiquement si un asset allait physiquement tenir dans une zone de placement donnée, éliminant ainsi une catégorie d’erreurs qui, autrement, n’apparaîtraient qu’au moment du compositing.
La bibliothèque suivait également la propriété de la marque et les licences régionales, ce qui donnait une puissante fonctionnalité de recherche à l’équipe commerciale. Comme Pete l’a souligné : « Les ventes peuvent ensuite aller : “montrez-moi tout ce que vous avez fait pour Chanel”, et elles peuvent simplement récupérer tous les plans, un par un. »
2. Gérer les clients comme des projets
Chaque contrat de marque devenait son propre projet dans Kitsu.
Ces projets suivaient non seulement les plans sur lesquels on travaillait, mais aussi quels assets avaient été affectés à quels placements, le statut actuel de chaque insertion et la façon dont cela se rattachait aux contrats dans le CRM de l’entreprise et aux outils de gestion de projet.
Relier Kitsu à Jira s’est révélé pénible. « L’API de Jira », a noté Pete, avec une exaspération à peine dissimulée. « Quelqu’un a déjà géré ça ? Oui, c’est vraiment mauvais. » La solution pragmatique consistait à copier manuellement l’identifiant de ticket Jira dans chaque projet Kitsu, afin que les deux systèmes puissent être recoupés par un humain, sans exiger une intégration en temps réel.
3. Des playlists comme contrôle de version à travers les campagnes
L’un des usages les plus élégants de Kitsu dans la chaîne Ryff impliquait des playlists : comme le même plan pouvait être retravaillé pour plusieurs campagnes de marques en parallèle, de simples numéros de version ne suffisaient pas à déterminer à quel contrat correspondait quel rendu. La version 5 d’un plan pouvait être la sortie correcte pour un client, tandis que la version 8 pouvait être la sortie correcte pour un autre client travaillant sur la même scène.
L’équipe de Pete a résolu ce problème en nommant chaque playlist Kitsu avec le numéro d’ordre d’insertion correspondant. Comme les playlists se figent sur une version spécifique au moment où l’on y ajoute un plan, et ne se mettent pas à jour automatiquement lorsqu’une nouvelle version est publiée, la playlist est devenue une trace stable de la version associée à chaque campagne. « En nommant la playlist réelle à partir du même numéro d’ordre d’insertion, on obtient une corrélation », a-t-il expliqué.
4. Automatiser la création des projets depuis Resolve
Ryff utilisait DaVinci Resolve comme outil principal de compositing. Ce choix était délibéré, car il fallait une correspondance précise du grain, une exactitude de l’espace colorimétrique et la capacité de garantir que le rendu correspondait à l’entrée à un niveau technique. Resolve prenait aussi en charge une véritable collaboration multi-utilisateurs via VPN, ce qui comptait pour une équipe à distance de 20 artistes.
Chaque piste vidéo dans une timeline Resolve représentait une seule insertion virtuelle de produit. Les pistes étaient nommées VP1, VP2, VP3, et ainsi de suite. Comme Resolve enregistre ses données de projet dans un format accessible via Python, l’équipe a écrit des scripts capables de lire la structure de la timeline et de générer automatiquement des plans dans Kitsu, sans aucune saisie manuelle de données.
Au départ, ils exportaient les informations de la timeline à l’aide d’OpenTimelineIO (un standard pour échanger des timelines éditoriales entre applications), puis ils les convertissaient en un fichier CSV mis en forme pour l’outil d’import de Kitsu.
Plus tard, ils ont remplacé cette étape intermédiaire par un script qui parlait directement à l’API de Kitsu depuis l’intérieur de Resolve. Passer de l’approche basée sur OpenTimelineIO à l’approche directe par API nécessitait environ 30 % de réajustement, mais c’était plus rapide et plus fiable.
Le script faisait bien plus que créer des plans : en un seul passage automatisé, il découpait des extraits individuels de plans dans le fichier de l’épisode maître à l’aide de FFmpeg (un outil de traitement média en ligne de commande), générait des fichiers de prévisualisation H.264 compatibles avec Kitsu pour chaque plan, créait une séquence JPEG pour le travail de matchmove, construisait la structure des dossiers sur le stockage de production, créait le projet Kitsu à partir d’un modèle préconstruit, alimentait les séquences et les plans, téléversait les clips QC conformes (conformity check), et envoyait une notification aux responsables de département indiquant que tout était prêt à être travaillé.
Le projet modèle était lui-même une innovation. Comme les mêmes artistes travaillaient sur chaque émission, et que la structure des tâches était presque identique d’un projet à l’autre, la mise en place manuelle de chaque projet représentait une perte de temps considérable. « On passait plus de temps à préparer les projets que réellement à les faire », a déclaré Pete. Le script du modèle lisait une structure de projet existante, y compris les types de tâches, les statuts des tâches et les affectations des artistes, puis la répliquait intégralement dans un nouveau projet.
Métriques de couverture et l’art de défendre une décision
L’une des métriques personnalisées les plus inhabituelles que l’équipe a intégrées dans Kitsu était ce qu’elle appelait « valeur de couverture ». Cette métrique mesurait le pourcentage du cadre qu’un placement couvrait réellement, en analysant image par image sur toute la durée du plan.
La raison était en partie technique et en partie politique. Les clients de marques demandaient souvent qu’un placement couvre un certain pourcentage du cadre afin de maximiser la visibilité. « Les ventes vont vous voir : OK, on a besoin de quelque chose qui fasse 20 %, » a déclaré Pete. « Ça a l’air d’un chiffre raisonnable. 20 % de tout le cadre à l’écran, c’est énorme. »
En calculant les pourcentages de couverture à l’aide de techniques de vision par ordinateur de base, en comparant les images d’entrée aux images de sortie et en mesurant la différence, l’équipe pouvait produire des preuves concrètes pour appuyer ou refuser les demandes des clients : si une marque voulait 20 % de couverture et que les données montraient que cela dominerait le cadre au point d’être inacceptable pour le propriétaire du contenu, Pete pouvait présenter les chiffres plutôt que d’argumenter à partir de l’intuition.
La métrique enregistrait une valeur élevée (la couverture maximale pendant un plan lorsque la caméra faisait un zoom), une valeur basse (parfois zéro, lorsque le placement sortait du cadre) et une moyenne sur l’ensemble de la durée. Les trois valeurs étaient stockées comme champs personnalisés dans Kitsu.
Reporting, notifications et le problème Microsoft
Pendant une grande partie de l’histoire de Ryff, les notifications passaient par Slack, qui s’intègre nativement à Kitsu via un webhook. Quand une tâche d’un artiste était mise à jour, un ping apparaissait sur son téléphone ou son ordinateur en quelques secondes.
Puis la direction de l’entreprise est passée sur Microsoft Teams. Slack a été supprimé. Google Drive a été remplacé par Microsoft SharePoint.
La migration a créé deux difficultés d’ingénierie distinctes. La première consistait à faire fonctionner le reporting automatisé, qui poussait auparavant les données vers Google Sheets en quasi temps réel, avec des fichiers Excel hébergés sur SharePoint à la place.
« Je pouvais m’arracher les dents et vivre une expérience plus agréable », a plaisanté Pete à propos du travail avec l’API Python de SharePoint.
La complexité supplémentaire nécessitait plusieurs étapes d’authentification juste pour se connecter, et le comportement de mise à jour en temps réel avait disparu, car Excel verrouille le fichier dès qu’une personne l’ouvre.
Le second problème, ce sont les notifications. Kitsu ne supporte pas Teams nativement.
La solution de l’équipe a été de construire un service d’écoute personnalisé qui s’exécutait sur le serveur Kitsu, surveillait les événements et acheminait des notifications individuelles vers des utilisateurs Teams spécifiques via Azure. Ils ont évité l’approche par webhook Teams, qui aurait envoyé chaque notification dans un canal partagé, submergeant tout le monde. À la place, chaque notification allait directement à la personne concernée.
Ils ont également mis en place des rappels automatisés de feuille de temps. Un script vérifiait chaque matin si un artiste n’avait pas enregistré des heures au cours des trois derniers jours, puis lui envoyait une notification personnelle via le service Teams. Faire transiter le rappel par le système de notifications plutôt que par un appel public réduisait le facteur de gêne et améliorait l’adhésion.
Les chiffres finaux
En novembre de l’année où Pete a quitté Ryff, une seule instance Kitsu détenait 543 projets actifs (sans compter séparément les épisodes TV individuels), 2 317 assets et 18 300 plans. Tout cela fonctionnait sur un seul serveur, avec les médias stockés sur un bucket S3 monté. L’équipe comptait environ 20 artistes, travaillant entièrement à distance.
Le temps de traitement pour un épisode complet du World Poker Tour, incluant la détection IA, le compositing, le contrôle qualité et la livraison, était passé d’une semaine et demie au début à 24 heures.
Points clés à retenir pour les studios d’animation
La conférence de Pete Draper était spécifique à un modèle économique quelque peu atypique, mais les enseignements s’appliquent directement à n’importe quel studio qui gère plusieurs projets, plusieurs clients, ou les deux.
Un tracker de production ne fonctionne que si tout le monde l’utilise, ce qui implique qu’il doit être accessible aux artistes, pas seulement aux superviseurs. Kitsu a réussi ce test dès le premier jour dans les deux studios de Pete.
L’automatisation supprime le coût de mise en place. Les champs standard de suivi des plans couvrent l’essentiel, mais des champs propres à votre workflow (pourcentages de couverture, offsets de timecode, dimensions des assets, identifiants d’ordre d’insertion) transforment votre système de tracking en outil d’aide à la décision plutôt qu’en simple registre administratif. Les playlists peuvent servir de journal de versions.
Et, peut-être surtout : construisez vers un système connecté. Kitsu fonctionne très bien en tant que tracker autonome. Mais il fonctionne bien mieux comme un hub qui reçoit des données d’outils de montage, envoie des notifications à des plateformes de communication, alimente des tableaux de bord de reporting et se relie au stockage des assets. Plus vous connectez de systèmes à Kitsu, plus le retour sur investissement de sa maintenance est élevé.
