vox-director : une skill d'agent qui produit une vidéo collage à partir d'un sujet
Turn one topic into a finished Vox-style paper-collage explainer/ad video — automated end to end on Atlas Cloud + ffmpeg. An agent skill.
En bref
- De quoi s’agit-il ?
- Un pipeline Python et ffmpeg piloté par une skill d'agent, qui transforme une phrase en vidéo explicative de style collage papier. Deux points de contrôle humains, quatre modèles Atlas Cloud, et une dépendance forte à la qualité du poster généré.
- À qui s’adresse-t-il ?
- vox-director convient à une personne qui travaille déjà dans un agent de code, possède une clé Atlas Cloud et accepte de valider un beat map puis un style avant toute génération lourde. Il ne convient pas à une production sans supervision, ni à un usage hors ligne, ni à un rendu qui exige une précision de mouvement au niveau de l'objet.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 36 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : la vidéo explicative éditoriale coûte une équipe, pas un prompt
Le style collage papier popularisé par les explainers Vox repose sur une chaîne de métiers : direction artistique, découpe, composition, animation image par image, voix, montage son. Un modèle de génération vidéo seul ne couvre pas cette chaîne. Il produit une image qui bouge, pas un poster composé puis animé.
vox-director prend le problème par l'autre bout. Le README décrit la vidéo comme un enchaînement de beats, chacun matérialisé par un poster de collage terminé, texte incrusté compris. C'est le point que la documentation met en avant : le rendu se joue à l'étape image, et si le poster n'est pas un collage dense, aucune étape en aval ne le rattrape. Le projet s'adresse donc à quelqu'un qui veut ce style éditorial précis, avec un narrateur, une musique et des sous-titres, sans écrire lui-même les prompts de chaque plan.
Le public visé est étroit : une personne qui dispose déjà d'un agent de code capable de lire un workflow et d'exécuter des scripts. Le dépôt cite Claude Code et Codex. Ce n'est pas un outil qu'on lance depuis un terminal vide.
beats.json comme unique source de vérité
Le README présente le flux comme une suite d'étapes traversées par un seul fichier par projet, beats.json. Tout part d'un sujet, et le premier script écrit ce fichier, qui contient la carte narrative. Les étapes suivantes le relisent : génération des posters, animation, voix, musique, assemblage.
Ce choix a une conséquence pratique. Le beat map est modifiable avant que le moindre appel de génération coûteux n'ait lieu, et c'est exactement là que se trouve le premier point de contrôle. Le second intervient juste après : le style bake-off rend le même beat dans trois ou quatre thèmes, et l'utilisateur choisit à l'œil. Le README parle de deux gates humains, et de tout le reste automatisé.
La documentation ne détaille pas le schéma de beats.json, ni les clés exactes qu'il accepte. C'est une lacune réelle : on sait que le fichier pilote le pipeline, on ne sait pas avec quelle granularité on peut éditer un beat à la main sans casser les étapes suivantes.
Trois modalités d'entrée pour un même moteur
Le flux décrit plus haut est appelé B-roll : un sujet entre, tout est généré. Le dépôt documente deux autres entrées qui réutilisent le même moteur.
En A-roll, une vidéo de talking-head existe déjà. Elle est segmentée en beats par ASR, puis restylée en collage tout en conservant le visage, le lip-sync et les gestes image par image. Le modèle cité est google/gemini-omni-flash/video-edit, avec un retry automatique sur seedance-2.0/reference-to-video.
En C-roll, une seule photo sert d'ancrage, selfie ou visuel produit. Le sujet est découpé en sticker photographique et jamais redessiné, puis chaque poster est généré autour de lui via google/nano-banana-2/edit. La narration peut être clonée dans la voix du sujet avec bytedance/seed-audio-1.0.
C'est la partie la plus intéressante du projet. Elle reconnaît qu'un visage réel ne survit pas à une régénération complète, et elle contourne le problème au lieu de le nier.
Deux chemins d'animation, avec un compromis explicite
Par défaut, un modèle vidéo anime le poster entier. Le README appelle cela le chemin du poster vivant. Le modèle dépend du contenu : google/gemini-omni-flash/image-to-video pour le non-réel, kwaivgi/kling-video-o3-pro/image-to-video quand des personnes réelles ou des marques apparaissent.
Un second chemin, optionnel et local, découpe le poster en parties et les pilote image par image. Le dépôt le justifie par deux arguments : pas de filtres de contenu, et une précision au pixel près. Il le recommande pour les personnes réelles.
Ce n'est pas un détail cosmétique. Le chemin local suppose une segmentation fiable du poster, et la documentation ne dit pas comment cette segmentation est obtenue ni ce qui se passe quand elle échoue. Le chemin par modèle vidéo, lui, délègue tout au réseau et perd le contrôle du détail. Les deux options existent parce qu'aucune ne couvre tous les cas, et le README ne prétend pas le contraire.
Installation et clés de configuration
Deux voies d'installation sont documentées. La première clone le dépôt directement dans le dossier de skills de Claude Code :
git clone https://github.com/Alisa0808/vox-director.git ~/.claude/skills/vox-director
La seconde passe par le fichier vox-director.skill, à installer depuis l'interface de skills. Ensuite, une seule variable d'environnement est requise :
export ATLASCLOUD_API_KEY="sk-..."
Les prérequis listés sont un agent de code, une clé Atlas Cloud, ffmpeg et ffprobe (brew install ffmpeg), ainsi que Python 3 avec Pillow pour les incrustations de sous-titres et de filigrane. Le déclenchement se fait en langage naturel, par exemple demander une vidéo collage de 15 secondes en 16:9 sur la street food mexicaine. La sortie est écrite dans out/<project>/final.mp4.
Un point mérite attention : le README précise que les identifiants de modèles dérivent, et que la skill récupère la liste à jour via GET https://api.atlascloud.ai/api/v1/models avant de tourner. C'est une protection utile, mais elle signifie aussi que le tableau des modèles du dépôt n'est pas la référence contractuelle.
Ce que la documentation ne couvre pas
Aucune release n'est publiée, et le dépôt ne fournit pas de version épinglée des modèles. Le comportement du pipeline dépend donc de ce que l'API Atlas Cloud expose au moment de l'exécution. Une modification de google/nano-banana-2/text-to-image se répercute directement sur le rendu, sans qu'une version de vox-director ne change.
Le coût n'est pas chiffré. Le flux B-roll enchaîne, par beat, une génération de poster, une animation, puis une narration et une musique au niveau du projet. Un style bake-off rend le même beat trois à quatre fois avant même la production finale. Le README ne donne aucun ordre de grandeur, et il n'y a pas de mécanisme de reprise documenté en cas d'échec au milieu d'un projet.
La licence est MIT, ce qui autorise la réutilisation et la modification. Elle ne couvre évidemment pas les conditions d'utilisation des modèles Atlas Cloud appelés, ni les droits sur les voix clonées. Le dépôt ne traite pas ce dernier point, qui reste à la charge de l'utilisateur.
Face à un pipeline génératif assemblé à la main
L'alternative la plus directe n'est pas un autre outil, c'est un assemblage manuel : générer les posters dans un modèle d'image, les animer dans un modèle vidéo, synthétiser la voix, puis monter dans ffmpeg. C'est exactement ce que fait vox-director, mais réparti entre plusieurs sessions et plusieurs interfaces.
La différence tient à trois choses. D'abord le fichier beats.json : l'état du projet vit dans un artefact unique et relisible, au lieu d'être dispersé dans un historique de conversation. Ensuite les deux gates : la validation du beat map et le choix du style sont des étapes imposées par le workflow, pas des bonnes intentions. Enfin le chemin local d'animation par découpage, qui n'a pas d'équivalent simple en manuel.
En contrepartie, l'assemblage manuel laisse choisir chaque modèle indépendamment et ne dépend d'aucune API unique. vox-director concentre le risque : une indisponibilité côté Atlas Cloud arrête l'ensemble de la chaîne, y compris les étapes purement locales comme ffmpeg.
Conclusion éditoriale
vox-director convient à une personne qui travaille déjà dans un agent de code, possède une clé Atlas Cloud et accepte de valider un beat map puis un style avant toute génération lourde. Il ne convient pas à une production sans supervision, ni à un usage hors ligne, ni à un rendu qui exige une précision de mouvement au niveau de l'objet. Avant de l'adopter, vérifiez trois choses concrètes : que ffmpeg et ffprobe sont bien présents sur la machine, que le modèle google/nano-banana-2/text-to-image produit un poster réellement chargé en éléments de collage, et que votre budget Atlas Cloud absorbe un bake-off de 3 à 4 thèmes avant le rendu final.
Notes de la communauté