OpenJutsu remplace localement jusqu’à quatre personnages dans une même vidéo

Un éditeur vidéo dans le cloud reste pratique jusqu’au moment où il faut y téléverser les fichiers sources d’un client, un clip inédit ou un enregistrement montrant de vraies personnes. OpenJutsu propose une autre voie : remplacer les personnages, les vêtements et les objets directement sur sa propre machine. Le projet reproduit l’un des principaux scénarios de Higgsfield Genjutsu, mais l’assemble à partir de composants ouverts et l’exécute via ComfyUI.

L’intérêt pratique ne se limite pas à disposer d’une alternative gratuite à un service commercial. OpenJutsu montre aux développeurs une architecture prête à l’emploi pour un éditeur vidéo moderne fondé sur l’IA : un modèle analyse la scène, un autre suit l’objet sélectionné d’une image à l’autre, un troisième redessine l’image, tandis qu’un graphe de traitement pilote toute la séquence. Un tel exemple est plus utile qu’une énième démonstration accompagnée d’une jolie vidéo : il peut être étudié, modifié et intégré à son propre produit.

Comment cela fonctionne dans un cas concret

Imaginons un clip musical réunissant quatre participants. L’utilisateur téléverse la vidéo, associe une photo distincte à chaque personne, puis lance le traitement. OpenJutsu doit conserver les mouvements, les gestes, les déplacements de caméra, le montage et la bande-son d’origine, tout en redessinant l’apparence des personnes choisies. Il ne s’agit pas seulement de remplacer un visage : le système peut modifier la coiffure, la morphologie et l’ensemble des vêtements.

Le même pipeline convient à des retouches plus ciblées. Il permet de changer la tenue d’un personnage, de remplacer un accessoire, de retirer un objet de l’image ou de modifier l’arrière-plan. Après le passage principal, des outils distincts corrigent les visages mal dessinés et atténuent un rendu colorimétrique trop dur. C’est un détail important : la génération vidéo se résume rarement à un seul clic, et OpenJutsu prévoit dès le départ une étape de finition du résultat.

Sous le capot, les tâches sont réparties entre plusieurs composants. Selon la description du projet, MiniMax H3 se charge de redessiner la vidéo, SAM 3.1 suit les personnes et les objets, Qwen3-VL interprète le contenu de la scène et ComfyUI relie les opérations dans un graphe unique. Pour un développeur, c’est un point d’entrée pratique : chaque bloc peut être étudié et remplacé séparément, sans réécrire toute l’interface ni tout le pipeline.

Une exécution locale ne signifie pas une exécution légère

Le principal avantage d’OpenJutsu est qu’il n’est pas nécessaire d’envoyer les vidéos sources vers les serveurs d’un service commercial. Cela réduit le risque de fuite de contenus confidentiels et offre davantage de contrôle sur les modèles, les paramètres et les résultats. Selon ses auteurs, le projet fonctionne sur une RTX 4060 Ti dotée de 16 Go de mémoire vidéo et sur un ordinateur équipé de 64 Go de RAM. Une telle configuration reste accessible à un petit studio ou à un développeur, mais il est encore difficile de la qualifier de grand public.

Une autre limite est plus visible : le traitement est lent. Ce projet ouvert doit être considéré comme un prototype fonctionnel et une base d’expérimentation, et non comme un remplacement garanti du produit cloud. La qualité dépendra de la vidéo source, des occultations, des mouvements de caméra, de l’éclairage et de la mémoire disponible. Les capacités annoncées doivent également être vérifiées sur ses propres contenus : la publication du projet et ses vidéos de démonstration ne prouvent pas encore sa stabilité dans toutes les scènes.

Ce que les développeurs peuvent en faire

OpenJutsu mérite l’attention des équipes qui développent des éditeurs vidéo, des outils de localisation publicitaire, des solutions d’essayage virtuel ou des systèmes de production de contenu. Le dépôt ne fournit pas une entreprise clé en main, mais une carte claire : segmentation et suivi, analyse de scène, redessin génératif, correction des défauts et orchestration. Il est possible de reprendre l’ensemble du pipeline pour un prototype ou de ne tester qu’un seul composant avec ses propres données.

Pour les fondateurs, le projet rappelle une réalité moins agréable : une interface construite par-dessus des modèles tiers protège moins efficacement un produit que des données propriétaires, la vitesse, la qualité des résultats et un workflow bien conçu. La communauté peut reproduire assez rapidement une fonctionnalité marquante lorsque celle-ci repose sur des modèles accessibles. La conclusion pratique est donc simple : les développeurs devraient tester OpenJutsu comme un laboratoire local, tandis que les équipes produit devraient évaluer quelle part de leur avantage subsistera lorsque le pipeline de base sera à la portée de tous.