Ce qu'une scripte doit remettre à la fin du tournage d'une scène
Une scène terminée, ce que la scripte laisse n'est pas « un tableau », mais un ensemble de relevés capables de faire reconnaître aux lecteurs suivants les faits de plateau : un relevé prise par prise doit pouvoir dire de quelle scène, de quel plan et de quelle prise il s'agit, et quel état de notation et quelles notes ont été donnés sur le plateau ; les preuves de continuité doivent permettre de revenir à une entrée précise ; le rapprochement des timecodes doit dire d'où vient la position temporelle ; et la liste des fichiers livrés doit faire savoir au destinataire ce qu'il a effectivement reçu. SlateX peut aujourd'hui projeter un même lot d'enregistrements sous plusieurs formes d'échange, mais cela ne remplace pas la vérification de ces valeurs littérales par le destinataire.
Le cœur de la livraison de fin de journée n'est pas « générer un fichier », mais permettre au lecteur suivant de raccrocher chaque relevé à cette scène, à ce plan et à cette prise.
Séparer d'abord la tâche métier et les produits du logiciel
La tâche métier de la scripte est de laisser en aval l'identité, les jugements et les indices de continuité formés pendant le tournage. Le relevé prise par prise sert surtout à ceux qui doivent retrouver les médias et l'état du tournage ; les preuves de continuité servent à ceux qui vérifieront plus tard les costumes, les accessoires, le maquillage ou les relations de raccord ; le rapprochement des timecodes sert à ceux qui veulent mettre les relevés et les positions réelles des médias sur une même ligne de temps ; et la liste des fichiers livrés dit au destinataire quels fichiers contient cette livraison et quelles informations demandent un retour à la source.
Les sorties actuelles de SlateX sont des produits logiciels, et non cette tâche métier elle-même. L'app peut générer une liste structurée, un fichier tabulaire, un rapport journalier lisible et un fichier de projet de scénario. Ces produits écrivent sous des formes différentes des données déjà relevées, ce qui évite de « les recopier une fois », mais ils ne retirent pas du flux l'étape où une personne confirme que le relevé concorde bien avec le média.
Il faut donc distinguer deux niveaux quand on parle de livraison : la scripte veille à laisser assez d'information traçable, et le logiciel projette les relevés existants dans des fichiers. Le premier engage un jugement et une responsabilité, le second n'est qu'une expression des données.
Le relevé prise par prise doit laisser une identité re-reconnaissable
Un relevé doit au moins pouvoir revenir à la clé scène, plan, prise. La notation et les notes répondent à ce que le plateau a laissé comme jugement et comme information complémentaire, mais c'est l'identité qui permet de réaligner les relevés entre les différents livrables.
Ce point compte d'autant plus qu'un même lot de fiches de prise ne donne pas le même nombre de lignes ni le même ordre selon le produit. La liste structurée et le fichier tabulaire déploient les relevés multi-caméras en plusieurs lignes, tandis que le rapport journalier lisible met une ligne par take. Le tri passe aussi par ses propres règles à chacun. On ne peut donc pas faire du « numéro de ligne » une identité valable d'un fichier à l'autre ; à la réception, on continue de rapprocher par scène, plan et prise.
Les preuves de continuité doivent revenir à un relevé précis, et non laisser un tas de médias
La valeur d'une photo de continuité ou d'une autre preuve est d'être encore reliée à une prise précise. Quand l'aval regarde de nouveau ces éléments, il doit savoir à quelle prise, à quel plan ou à quel objet de continuité se rattache cette preuve, au lieu de voir seulement un album sans contexte.
Cela ne veut pas dire que le logiciel a déjà tranché le jugement de continuité à la place de la personne. Qu'une photo puisse être rattachée à un relevé et que plusieurs photos puissent être revues ensemble forment deux choses distinctes de « l'image est vraiment continue ». À la livraison, on conserve les relations traçables et on laisse le reprenant juger, sans écrire le mécanisme d'association de l'outil comme une conclusion.
Le rapprochement des timecodes doit dire au destinataire où reprendre la vérification
Une position temporelle sert à donner aux relevés écrits la possibilité d'être contrôlés sur la même ligne de temps que les médias. Mais le destinataire ne doit pas la tenir pour fiable au seul motif que le champ ressemble à un timecode légal. Certains champs de livraison viennent des enregistrements de plateau, certains sont dérivés par le logiciel, et certains, faute de valeur, reçoivent un contenu de repli.
Ce que la scripte transmet n'est donc pas seulement une chaîne de timecode, mais aussi le contexte « qui est ce relevé, et où vérifier cette valeur ». Pour ce qui est de l'usage direct en aval, le destinataire doit vérifier colonne par colonne selon son propre flux.
Un même lot de relevés devient plusieurs formes de livraison
Les quatre formes d'échange actuelles de SlateX n'assument pas le même travail. La liste structurée et le fichier tabulaire se prêtent à une lecture champ par champ ; le rapport journalier lisible ressemble davantage à une mise en page que l'on feuillette à la main ; et le fichier de projet de scénario revient à la structure du scénario elle-même. Ce ne sont pas quatre copies concordantes ligne à ligne.
Une frontière clé est le multi-caméras. Si une take est rattachée à plusieurs caméras, la liste structurée et le fichier tabulaire la déploient en plusieurs lignes ; le rapport journalier reste à une ligne par take, et cette ligne ne retient les paramètres que d'une seule caméra. Autrement dit, tous les paramètres de toutes les caméras d'une scène multi-caméras n'apparaissent pas ensemble sur la même ligne du rapport journalier.
Les livrables sont un ensemble de fichiers qui se renvoient les uns aux autres, et non des copies que l'on pourrait recoller ligne à ligne d'après un numéro de ligne.
Quand la relève reprend, on ne peut pas écrire la « passation » comme une capacité du produit
SlateX n'a actuellement aucune implémentation de « passation », de « relève » ni de modification simultanée par plusieurs personnes. Quand la relève reprend, le nouvel appareil doit encore sélectionner de nouveau le poste de travail, et le logiciel n'a aucun état que l'on pourrait présenter comme « passation terminée ».
Ce que cette page peut donc dire tient dans les informations qui doivent rester dans les relevés : l'identité de scène, de plan et de prise, le jugement et les notes de plateau, le rattachement des preuves de continuité, la position temporelle, et le contenu de la livraison. On ne peut pas pousser l'existence de ces relevés jusqu'à écrire « passation continue prise en charge » ou « collaboration multi-utilisateurs ».
Les fiches de prise demandent une réponse séparée sur « quoi consigner »
La question parente de la livraison de fin de journée s'arrête ici à « quelles familles d'information faut-il laisser, et pourquoi l'aval en a besoin ». Ce que doit contenir, en son sein, une fiche de prise fait déjà l'objet d'une page distincte, « Quelles informations transmissibles doit consigner une entrée de prise », qui continue de le développer. Cette autre question porte sur les champs et les frontières d'un relevé isolé, et ne reprend pas la forme des livrables traitée ici.
FAQ
La livraison de fin de journée se réduit-elle à exporter un tableau ?
Non. Le relevé prise par prise, les preuves de continuité, le rapprochement des timecodes et la liste des fichiers livrés ont des responsabilités différentes, et les sorties du logiciel prennent plusieurs formes : on ne peut pas tenir un seul fichier pour la livraison entière.
Pourquoi plusieurs fichiers de livraison ne se rapprochent-ils pas par numéro de ligne ?
Parce qu'un même lot de relevés adopte des modes de déploiement et de tri différents selon le produit, et qu'un relevé multi-caméras est même éclaté en plusieurs lignes dans certains produits. Le rapprochement entre fichiers se refait par identité de scène, de plan et de prise.
Le rapport journalier permet-il de voir tous les paramètres de caméra d'une take ?
Non. Le rapport journalier actuel met une ligne par take, et les paramètres de caméra de cette ligne ne viennent que d'une seule caméra ; l'information multi-caméras n'est donc pas regroupée sur la même ligne.
SlateX prend-il en charge la passation de relève ou la modification simultanée ?
Ce type d'implémentation n'existe pas aujourd'hui. Cette page peut seulement exiger que les informations clés restent dans les relevés, sans écrire ces relevés eux-mêmes comme une capacité de « passation » ou de « collaboration multi-utilisateurs ».
Axiom One LLC — SlateX. Chiffres arrêtés au 2026-09-24.