Quel rendu vidéo choisir : navigateur, serveur ou aperçu en direct ?

Pour un produit qui génère des vidéos, le bon choix n’est pas « le rendu le plus puissant », mais le chemin qui correspond à l’action de l’utilisateur. Exporter un clip court à la demande peut rester dans le navigateur ; une série d’exports, une API ou un traitement planifié mérite un serveur ; et un aperçu direct doit servir à vérifier le document vidéo avant de produire le MP4. Avec VideoFlow, le même VideoJSON peut relier ces trois usages sans réécrire la vidéo.

Cette distinction évite deux erreurs coûteuses : envoyer chaque brouillon au serveur alors qu’un export local suffit, ou demander au poste de l’utilisateur de porter une file de rendus longue et critique. Voici une méthode de choix documentable pour une petite équipe.

Le dossier de décision en trois questions

Avant de comparer des bibliothèques, classer chaque action par son déclencheur, son volume et son niveau de contrôle. VideoJSON est le document structuré qui décrit les calques, médias, animations et temps de la vidéo ; le cœur de VideoFlow peut le produire depuis TypeScript, puis les autres composants le lisent.

Situation à traiter	Chemin à privilégier	Pourquoi	Point de vigilance
Une personne clique sur « Exporter » pour un clip bref	Navigateur	Pas d’aller-retour du projet vers un serveur	Prévoir progrès et annulation
Un tableau, une API ou un planning crée beaucoup de vidéos	Serveur et file	Le travail peut être repris, suivi et livré hors du navigateur	Concevoir les erreurs et la capacité
Une personne règle un texte, un plan ou un timing	Aperçu DOM	Elle voit et vérifie le même document avant export	Un aperçu n’est pas une preuve de livraison

Cette table n’est pas une règle d’architecture définitive. Une application peut combiner les trois chemins : aperçu pendant l’édition, export local pour un essai, puis rendu serveur après approbation. Le point stable est le VideoJSON, pas l’endroit où le premier MP4 est produit. C’est aussi la logique d’un pipeline vidéo révisable à partir de données : séparer ce qui est décidé de ce qui est calculé.

Quand l’export dans le navigateur est le bon compromis

Le renderer navigateur de VideoFlow transforme VideoJSON en Blob MP4 dans la page. La documentation indique qu’il expose une progression, peut être interrompu avec AbortController et peut déléguer le travail à un Web Worker. C’est pertinent pour un bouton d’export explicite, un prototype interne, une courte vidéo personnalisée ou une situation où l’on veut éviter d’envoyer le projet de l’utilisateur au backend.

Le critère utile n’est donc pas « sans serveur = toujours moins cher ». Il est : l’utilisateur peut-il attendre, garder son onglet ouvert et recommencer sans conséquence ? Si oui, l’export local réduit l’infrastructure à administrer. L’interface doit cependant annoncer la progression, proposer Annuler, et expliquer quoi faire si le navigateur manque de ressources.

Un test minimal est plus révélateur qu’une promesse : choisissez un vrai modèle, un appareil modeste et une connexion ordinaire ; mesurez le temps de préparation, vérifiez l’annulation, puis contrôlez le MP4 obtenu. Pour préparer l’étape de modification, une timeline vidéo modifiable dans une application SaaS apporte le bon contexte : une source mal préparée reste un problème, quel que soit le renderer.

Quand passer à une file de rendu serveur

Le renderer serveur vise le travail Node.js : il peut écrire un fichier ou fournir un Buffer, ce qui convient aux API, tâches planifiées et lots. La documentation décrit un encodage par défaut dans Chromium headless avec WebCodecs et MediaBunny, avec une voie FFmpeg optionnelle si le besoin d’encodage le justifie. Il ne faut pas en déduire que FFmpeg disparaît : il reste utile pour des besoins bas niveau. VideoFlow apporte ici une couche de composition et un format commun au-dessus du problème d’encodage.

Choisissez ce chemin quand l’export doit continuer après la fermeture de l’onglet, quand plusieurs vidéos se succèdent, quand une intégration attend une livraison, ou quand un journal d’état est nécessaire. La bonne unité de travail est un dossier qui contient :

• l’identifiant et la version du VideoJSON ;
• les URL ou identifiants des médias autorisés ;
• le format de sortie attendu ;
• une tentative, un état et une erreur lisible ;
• la destination seulement après succès.

Ce petit contrat empêche une file de devenir une boîte noire. Il rejoint la discipline présentée dans une méthode de fiabilisation des synchronisations : état observable, reprise bornée et décision explicable. Pour un premier lot, n’automatisez pas tout le catalogue. Lancez quelques cas représentatifs, dont un média long et une entrée incomplète, puis décidez si l’erreur doit bloquer, signaler ou utiliser une valeur de secours.

Pourquoi un aperçu direct mérite sa propre étape

Un aperçu ne produit pas un fichier final ; il répond à une autre question : « est-ce bien la vidéo que nous voulons rendre ? » Le renderer DOM de VideoFlow monte un lecteur manipulable avec lecture et déplacement précis à l’image. C’est particulièrement utile lorsqu’un agent, un formulaire ou un modèle fabrique le VideoJSON : on contrôle le texte, le média, l’ordre, le cadrage et la durée avant de payer un rendu plus lourd.

L’aperçu devrait être une étape de contrôle, pas une miniature décorative. Ajoutez une revue courte : vérifier les données variables, parcourir les transitions aux points de coupe, contrôler le début et la fin, puis marquer le document comme prêt. Les données et la validation arrivent avant l’exécution irréversible.

Une règle simple pour une architecture hybride

Utilisez cette règle au moment de concevoir le flux :

1. Prévisualiser tout ce qui est modifiable par une personne.
2. Exporter dans le navigateur les actions courtes, volontaires et récupérables.
3. Envoyer au serveur les travaux différés, répétés, intégrés ou contractuels.
4. Conserver le VideoJSON avec la version des données et du modèle, quel que soit le renderer.

Le composant React Video Editor est utile lorsqu’il faut donner une vraie surface de modification à l’utilisateur : il reçoit le VideoJSON, renvoie les changements par callbacks et propose une timeline multi-piste. Ce n’est pas obligatoire pour un flux purement automatique ; un aperçu DOM peut suffire. À l’inverse, une suite de montage traditionnelle reste préférable quand le travail est avant tout créatif, libre et non répétable.

Conclusion : choisir le chemin, puis garder le même document

Le navigateur, le serveur et l’aperçu direct ne sont pas trois produits concurrents. Ce sont trois responsabilités : exporter, produire et contrôler. Pour démarrer, prenez un seul modèle vidéo réel, faites-le passer par un aperçu, testez un export navigateur, puis ajoutez une file serveur uniquement lorsque le volume ou la fiabilité le réclame. Les exemples VideoFlow constituent un bon point de départ pour ce petit essai, avec un résultat concret à examiner avant d’élargir le système.