Lors du Kitsu Submit 2026, Guilhem Compain, développeur principal chez Wizz Studio, est monté sur scène pour présenter un défi que beaucoup de studios plus modestes connaissent bien : gérer une variété de projets répartis entre des techniques d’animation radicalement différentes, avec une petite équipe et des délais très serrés.
Sa conférence a couvert les choix techniques réalisés par Wizz ainsi qu’un guide pratique pour tout studio souhaitant 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 inclut également Quad Film, Quad Drama et d’autres entités de production.
Ce qui rend Wizz particulier, c’est l’incroyable diversité des techniques avec lesquelles il travaille : animation 2D image par image, 3D, stop-motion, motion design et médias mixtes, le tout 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 à autre un projet de fiction.
Cette diversité entraîne une complexité opérationnelle. Wizz travaille avec de nombreux outils logiciels, notamment TVPaint, Photoshop, Nuke et Blender, entre autres. Chaque production peut sembler entièrement différente de la précédente, et les productions ne durent que rarement plus de quelques mois : la vitesse et la clarté ne sont donc pas optionnelles.
Guilhem a été très direct sur le contexte dans lequel tout cela se déroule : l’équipe de développement de Wizz se compose de deux personnes exactement. Il a rejoint le studio il y a environ un an, et l’autre membre, pipeline TD Hadrien Farre, est au studio depuis quatre ou cinq ans. Cette échelle a un impact 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 une influence sur ce que nous pouvons produire et mettre en place dans nos pipelines."
C’est une situation familière pour beaucoup de studios de taille intermédiaire. Le défi n’est pas de comprendre à quoi ressemble un bon pipeline, mais de le construire et de le maintenir avec des ressources limitées, tout en continuant à livrer du travail.
Le rôle de Kitsu chez Wizz
Kitsu sert de l’un des deux piliers centraux dans l’infrastructure de Wizz. L’autre est QuadPype, leur outil interne de pipeline construit comme une dérivation (fork) de l’OpenPype open-source (désormais connu sous le nom d’AYON dans sa quatrième version). Ensemble, Kitsu et QuadPype agissent, comme le dit Guilhem, comme une couche d’abstraction : au lieu de permettre à différents outils logiciels 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 données importantes. Tous les logiciels se connectent à lui. Cela empêche les logiciels de parler directement les uns aux autres."
Pour les studios qui ont déjà vécu le chaos des dépendances inter-outils non documentées ou la perte de données de production quand une application dans une chaîne tombe en panne, ce type de centralisation ressemble à une solution évidente. Kitsu devient la source de référence de ce qui existe, de ce qui a été validé et de ce qui reste à faire.
Guilhem a souligné que l’utilisation de Kitsu chez Wizz est volontairement simple. Ils ne tirent pas parti de toutes les fonctionnalités de la plateforme. À la place, ils s’appuient sur Kitsu comme outil de visualisation et de suivi : un endroit où les coordinateurs, les réalisateurs et les équipes de production peuvent voir l’état d’un projet d’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 de manière plus souple que le sens traditionnel du mot en animation : chez Wizz, une séquence peut représenter tout ce qui est lié aux colorboards, ou elle peut aussi servir à distinguer le travail pour la bande-annonce du projet principal.
La structure s’adapte à la manière dont la production est réellement organisée, sans être contrainte dans un cadre rigide. Les déclinaisons (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 conférence s’est ensuite penchée sur la façon dont les données de Kitsu alimentent QuadPype pour l’automatisation.
Wizz fait tourner 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 qu’un changement intervient sur la plateforme : une mise à jour de statut, un nouveau commentaire, une tâche assignée. La boucle de synchronisation capture ces événements, les filtre pour ne conserver 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."
Une amélioration notable que l’équipe a ajoutée, au-delà de ce que OpenPype proposait directement, 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 fonction de ce qui a été casté dans Kitsu. Cela supprime une étape manuelle qui, autrement, retomberait sur les artistes : se souvenir de faire la bonne chose et l’exécuter correctement à chaque fois.
À partir de là, les données alimentent le launcher, qui est en pratique 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. Lorsqu’un artiste publie son travail, le module de publication récupère directement la configuration depuis Kitsu : début de frame, fin de frame, et tout autre paramètre pertinent défini pour ce plan. Des contrôles de cohérence sont lancés 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 que la publication ne soit finalisée.
La fonctionnalité finale mise en avant par Guilhem 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 débutent sur un nouveau plan, cela élimine une quantité importante de configuration manuelle.
Le problème difficile : les artistes 2D et la culture du pipeline
Guilhem a passé du temps sur quelque chose que les discussions autour des pipelines contournent souvent : l’écart culturel entre la production 2D et 3D.
"En 2D, il existe cette notion selon laquelle un pipeline 2D devrait être 'organique'", a-t-il dit. "Autrement dit, l’artiste doit être libre de faire ce qu’il veut sans contraintes. En revanche, un pipeline 3D cherche plutôt à restreindre réellement 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 eux-mêmes l’organisation de leurs fichiers et leurs conventions de nommage. Introduire un outil de pipeline, c’est demander à ces artistes de changer des habitudes qui, de leur point de vue, ont toujours très bien fonctionné. La résistance n’est pas déraisonnable.
Guilhem a décrit des points de friction précis chez Wizz. Par exemple, les artistes sous Windows ont tendance à copier-coller des fichiers avec des caractères accentués dans les noms de fichiers, ce qui crée des problèmes en aval dans le pipeline. Plutôt que de bloquer totalement l’action, Guilhem défend une correction silencieuse : laissez passer le fichier, mais renommez-le automatiquement. "L’objectif, c’est un cadrage sans que cela soit visible", a-t-il dit.
Le processus d’adoption est encore en cours. "Je ne pense pas qu’il y aura un jour où tout le monde sera satisfait", a-t-il reconnu.
La recommandation qu’il a formulée est moins technique qu’organisationnelle : commencez par parler aux gens. Comprenez comment travaillent réellement différents artistes, impliquez-les dans les décisions concernant les contraintes qui ont du sens, et faites en sorte que les outils suivent cette compréhension plutôt que l’inverse.
La suite
Guilhem a conclu avec une liste d’améliorations que l’équipe souhaite mettre en place : filtrer la vue du launcher pour n’afficher que les tâches assignées à un artiste donné (une fonctionnalité déjà présente dans le dépôt d’AYON et adaptable à QuadPype), ajouter des notifications dans l’application lorsque les statuts ou commentaires Kitsu changent, et importer directement les commentaires Kitsu dans le logiciel afin que les artistes n’aient pas à changer de contexte vers un navigateur.
Il a également évoqué une ambition plus large : la possibilité d’écrire une fois quelque chose dans QuadPype et de le faire fonctionner automatiquement sur toutes les intégrations logicielles. "C’est là que les outils de pipeline comme QuadPype, OpenPype ou AYON brillent vraiment", a-t-il dit. "Vous pouvez écrire une chose une fois, et elle fonctionnera avec tous les logiciels, puisque chaque intégration vit quelque peu en dehors du logiciel lui-même, même si elle communique avec lui."
Pour les studios qui suivent une trajectoire similaire, le pipeline Wizz est disponible sur GitHub à l’adresse quadproduction/QuadPype.
Points clés à retenir pour les studios
L’histoire de Wizz offre une vision concrète de ce que signifie construire autour de Kitsu dans un environnement réel, compliqué et multi-techniques de production. Quelques points se démarquent pour les studios dans une situation similaire :
- Vous n’avez pas besoin d’utiliser toutes les fonctionnalités de Kitsu pour en tirer de la valeur. Wizz utilise Kitsu principalement comme 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 lorsque 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 maîtrisable. Wizz a construit leur couche de synchronisation sur le système d’événements propre à Kitsu, qui se prête bien à ce type d’usage.
Le défi le plus difficile est organisationnel : amener les artistes à faire confiance à un système et à l’utiliser de manière suffisamment constante pour que ses données restent fiables.
Et si vous dirigez un studio hybride, la fracture culturelle 2D/3D autour de la discipline du pipeline vaut la peine d’être reconnue directement. Les outils ne sont aussi bons que les habitudes qui les entourent.
