Lors du Kitsu Submit 2026, Guilhem Compain, lead developer chez Wizz Studio, est monté sur scène pour présenter un défi bien connu de nombreuses petites structures : gérer une variété de projets avec des techniques d’animation radicalement différentes, avec une petite équipe et des délais très serrés.
Sa présentation portait sur les choix techniques que Wizz a faits, ainsi que sur un guide pratique pour tout studio cherchant à structurer un pipeline hybride sans perdre la flexibilité que le travail créatif exige.
Une petite équipe de développeurs avec un grand mandat
Wizz est un studio d’animation basé à Paris, fondé en 2004, qui compte environ 20 employés et 40 artistes permanents. Il fait partie du groupe Quad, qui regroupe également Quad Film, Quad Drama et d’autres entités de production.
Ce qui rend Wizz particulier, c’est l’ampleur des techniques avec lesquelles le studio travaille : l’animation 2D image par image, le 3D, la stop-motion, le motion design et les médias mixtes cohabitent sous le même toit. Le studio produit principalement de courtes séries, des bandes-annonces, des teasers et des clips musicaux, avec de temps en temps des projets de fiction.
Cette diversité génère une complexité opérationnelle. Wizz travaille avec de nombreux outils logiciels, dont TVPaint, Photoshop, Nuke et Blender, entre autres. Chaque production peut être totalement différente de la précédente, et elles ne durent généralement pas plus de quelques mois : vitesse et clarté ne sont donc pas des options.
Guilhem a été très direct sur le contexte dans lequel tout cela se produit : l’équipe de développement de Wizz ne compte que deux personnes. Il a rejoint le studio il y a environ un an, et l’autre membre, pipeline TD Hadrien Farre, est là depuis quatre ou cinq ans. Cette échelle pèse ensuite sur tout ce qui suit.
« Nous avons une équipe de développement assez petite, a noté Guilhem. Nous sommes deux, et cela a forcément un impact sur ce que nous pouvons produire et mettre en œuvre dans nos pipelines. »
Cette situation est familière pour beaucoup de studios de taille intermédiaire. Le défi ne consiste pas à comprendre à quoi ressemble un bon pipeline, mais à en construire et en maintenir un avec des ressources limitées, tout en livrant le travail.
Le rôle de Kitsu chez Wizz
Kitsu constitue l’un des deux piliers centraux de l’infrastructure de Wizz. L’autre est QuadPype, leur outil interne de pipeline, développé comme une variante (fork) de l’OpenPype open source (désormais connu sous le nom d’AYON dans sa quatrième version). Ensemble, Kitsu et QuadPype jouent, comme le dit Guilhem, le rôle d’une couche d’abstraction : au lieu de permettre aux différents outils de communiquer directement entre eux, tout passe par l’un de ces deux systèmes.
« Cela nous donne une certaine souveraineté sur nos données, a expliqué Guilhem. Seul Kitsu, principalement, détient les informations importantes. Tous les logiciels s’y connectent. Cela empêche les logiciels de communiquer directement entre eux. »
Pour les studios qui ont déjà connu le chaos des dépendances entre outils non documentées, ou la perte de données de production lorsqu’une application de la chaîne casse, ce type de centralisation ressemble à une évidence. Kitsu devient la source de référence qui dit ce qui existe, ce qui a été validé, et ce qui doit encore être amélioré.
Guilhem a insisté sur le fait que l’usage de Kitsu chez Wizz est volontairement simple. Ils ne tirent pas parti de toutes les fonctionnalités offertes par la plateforme. À la place, ils s’appuient sur Kitsu comme outil de visualisation et de suivi : un endroit où les coordinateurs, les directeurs et les équipes de production peuvent voir l’état d’un projet en un coup d’œil, sans avoir à fouiller dans un système de fichiers ou à demander directement à un artiste.
Les assets sont suivis via des tâches, des commentaires et des reprises (retakes). Les plans suivent la même logique.
Les séquences sont utilisées plus librement que le sens traditionnel du mot en animation : chez Wizz, une séquence peut représenter tout ce qui concerne les colorboards, ou bien distinguer le travail pour les bandes-annonces du projet principal.
La structure s’adapte à la manière dont la production est réellement organisée, plutôt que d’être forcée dans un cadre rigide. Les breakdowns gèrent le casting, qui alimente ensuite en aval les outils de pipeline. Les playlists génèrent des montages rapides « à la volée » que les réalisateurs peuvent consulter et annoter directement.
Où Kitsu se connecte au pipeline
La présentation a ensuite expliqué comment les données de Kitsu remontent vers QuadPype pour l’automatisation.
Wizz exécute un service de synchronisation sur un serveur dédié. Ce service écoute le système d’événements de Kitsu, qui déclenche un événement chaque fois que quelque chose change sur la plateforme : une mise à jour de statut, un nouveau commentaire, une tâche qui est attribuée. La boucle de synchronisation capture ces événements, les filtre pour ne garder que ceux qui sont pertinents, puis écrit les résultats dans une base de données locale que QuadPype interroge.
« Chaque fois que vous faites quelque chose dans Kitsu, cela déclenche un événement que tout le monde peut écouter, a expliqué Guilhem. Nous filtrons toutes les actions capturées pour ne garder que celles qui nous intéressent, et pour chaque événement pertinent, nous exécutons du code qui ajoute, modifie ou supprime des données dans la base de données. »
Une fonctionnalité notable que l’équipe a ajoutée, au-delà de ce que proposait OpenPype « out of the box », a été d’inclure les informations de casting dans cette synchronisation : lorsqu’un artiste ouvre une scène, QuadPype peut désormais charger automatiquement les bons assets, props et éléments en se basant sur le casting défini dans Kitsu. Cela supprime une étape manuelle qui, autrement, incomberait aux artistes : se souvenir de le faire et l’exécuter correctement à chaque fois.
À partir de là, les données alimentent le launcher, qui agit essentiellement comme le gestionnaire d’assets de QuadPype. Les artistes voient leurs projets, assets et plans directement extraits de Kitsu. Ils peuvent voir en un coup d’œil quels fichiers existent sur le système de fichiers et lesquels ont été publiés. Ils sélectionnent leur plan, choisissent leur tâche, puis l’ouvrent dans le logiciel approprié.
La publication suit une logique similaire. Lorsque un artiste publie son travail, le système de publication récupère la configuration directement depuis Kitsu : le frame start, le frame end et tous les autres paramètres pertinents définis pour ce plan. Des contrôles de cohérence (sanity checks) s’exécutent automatiquement, vérifiant que le fichier de l’artiste correspond à ce que spécifie Kitsu. Si la plage de frames ne correspond pas, le système le signale avant même que la publication ne se termine.
La fonctionnalité finale que Guilhem a mise en avant est ce qu’ils appellent « Build First Workfile ». Cet outil lit les informations de casting depuis Kitsu, puis génère automatiquement une scène de départ, organisée selon une structure prédéfinie, avec tous les bons éléments déjà chargés. Pour les artistes qui commencent à travailler sur un nouveau plan, cela supprime une quantité importante de configuration manuelle.
Le problème difficile : les artistes 2D et la culture du pipeline
Guilhem a consacré du temps à un point que les discussions sur les pipelines évitent souvent : le fossé culturel entre la production 2D et la production 3D.
« En 2D, il y a cette idée que le pipeline 2D doit être “organique”, a-t-il dit. Cela signifie que l’artiste doit être libre de faire ce qu’il veut, sans contraintes. D’un autre côté, un pipeline 3D vise à vraiment limiter ce que les artistes peuvent faire afin d’éviter des problèmes techniques plus tard. Évidemment, la bonne réponse se situe quelque part entre les deux. »
Cette tension est bien réelle dans la pratique. Les workflows 2D se sont historiquement développés dans des environnements plus petits et plus informels, où les artistes gèrent leur propre organisation des fichiers et leurs conventions de nommage. Introduire un outil de pipeline revient à demander à ces artistes de changer des habitudes qui, de leur point de vue, ont toujours fonctionné. La résistance n’est donc pas déraisonnable.
Guilhem a décrit des points de friction précis chez Wizz. Par exemple, les artistes sur Windows ont tendance à copier/coller des fichiers avec des caractères accentués dans les noms de fichiers, ce qui provoque des problèmes en aval dans le pipeline. Plutôt que de bloquer complètement l’action, Guilhem plaide pour une correction silencieuse : laisser le fichier passer, mais le renommer automatiquement. « L’objectif, c’est d’encadrer sans que cela ne soit visible », a-t-il dit.
Le processus d’adoption se poursuit encore. « Je ne pense pas qu’il y ait un moment où tout le monde sera satisfait », a-t-il reconnu.
La recommandation qu’il a donnée tient moins du côté technique que de l’organisation : commencer par parler aux gens. Comprendre comment travaillent réellement des artistes différents, les impliquer dans les décisions sur les contraintes qui ont du sens, puis laisser les outils découler de cette compréhension, plutôt que l’inverse.
Et ensuite
Pour conclure, Guilhem a dressé une liste d’améliorations que l’équipe souhaite mettre en place : filtrer la vue du launcher pour n’afficher que les tâches attribuées à un artiste donné (une fonctionnalité qui existe déjà dans le dépôt d’AYON et qui peut être adaptée pour QuadPype), ajouter des notifications dans l’application lorsque les statuts ou les commentaires Kitsu changent, et faire remonter les commentaires Kitsu directement dans les logiciels afin que les artistes n’aient pas besoin de changer de contexte vers un navigateur.
Il a aussi pointé une ambition plus large : la capacité d’écrire une fois dans QuadPype et d’avoir le résultat fonctionner automatiquement avec chaque intégration logicielle. « C’est là que des outils de pipeline comme QuadPype, OpenPype ou AYON brillent vraiment », a-t-il dit. « On peut écrire quelque chose une fois, et cela fonctionne avec tous les logiciels, car chaque intégration vit quelque peu en dehors du logiciel lui-même, même si elle communique avec lui. »
Pour les studios engagés sur un chemin similaire, le pipeline de Wizz est disponible sur GitHub, à l’adresse quadproduction/QuadPype.
À retenir pour les studios
L’histoire de Wizz offre une vision concrète de ce que représente le fait de bâtir autour de Kitsu dans un environnement réel, complexe et multi-technique. Quelques points ressortent pour les studios dans une situation comparable :
- Vous n’avez pas besoin d’utiliser toutes les fonctionnalités de Kitsu pour en tirer de la valeur. Chez Wizz, Kitsu sert surtout de couche de visualisation et de suivi, et rien que cela apporte un bénéfice important aux coordinateurs et aux réalisateurs.
- La valeur augmente encore quand Kitsu devient la source de données de référence pour les outils en aval. Plages de frames, casting, statut des tâches : tout ce que vous enregistrez dans Kitsu peut servir à configurer, valider et automatiser le travail ailleurs dans le pipeline.
- Le défi technique de l’intégration est réel, mais gérable. Wizz a construit sa couche de synchronisation sur le propre système d’événements de Kitsu, qui est bien adapté à ce type d’usage.
Le défi le plus difficile est plutôt organisationnel : amener les artistes à faire confiance au système et à l’utiliser de manière suffisamment régulière pour que ses données restent fiables.
Et si vous gérez un studio hybride, il vaut aussi la peine de reconnaître directement la fracture culturelle 2D/3D autour de la discipline du pipeline. Les outils ne sont aussi bons que les habitudes qui les entourent.
