Pourquoi une livraison ne peut pas rendre un chemin jusqu'aux médias
ALE, CSV, PDF et FDX peuvent échanger des enregistrements structurés, mais aucun ne remet un chemin qui résoudrait jusqu'aux médias sur la machine du destinataire. Les deux fichiers lisibles par machine portent bien une case Source File Name et une case pour le fichier source, mais ce qu'elles contiennent est du texte recopié sur le plateau : le logiciel ne scanne pas un disque pour y chercher une position, et une case que personne n'a recopiée part vide. Le chemin réel qui est dans la bibliothèque de projet n'a jamais été transmis à l'instantané d'export.
Les médias ont bien une place sur le disque dans la bibliothèque de projet ; la case du fichier de livraison est du texte recopié, et le destinataire ne peut pas raccorder un média en s'appuyant sur elle.
Pourquoi les médias locaux ont deux destinations de stockage
Les médias enregistrés localement ne suivent pas une seule règle de répertoire. Les vidéos produites depuis le formulaire d'ajout entrent dans une zone de dépôt à plat ; la prise de photos depuis la liste, le choix dans la photothèque et l'importation de fichiers entrent dans une arborescence structurée par projet, scène, plan et prise. Ces deux destinations relèvent l'une comme l'autre de la façon dont la bibliothèque de projet conserve les médias.
La frontière decisive est que ces chemins n'existent que dans la bibliothèque de projet et n'entrent pas dans l'instantané d'export. Quand l'export génère un ALE, un CSV, un PDF ou un FDX, il reçoit un instantané des enregistrements de prises et des champs associés, et non une liste de chemins de médias. Le destinataire a beau voir un numéro de bobine, un numéro de scène ou un numéro de prise, il ne peut pas tirer du fichier de livraison la position physique du fichier sur la machine locale. Le numéro de plan n'a une colonne à part que dans CSV et PDF ; l'ALE n'a pas cette colonne.
Pourquoi le nom de fichier ne remplace pas le chemin d'origine
Avant l'enregistrement du média, son nom de fichier est d'abord normalisé. Les caractères interdits sont remplacés par des tirets bas, les caractères de contrôle sont supprimés, un nom trop long est tronqué, et si la normalisation ne laisse rien d'exploitable, on retombe sur un nom de repli, constante anglaise. Autrement dit, le nom de fichier sur le disque peut déjà différer du nom porté par la source extérieure.
Les photos sont traitées de deux façons : celles prises sur le plateau ou par prise rapide sont réencodées, tandis que celles choisies dans la photothèque ou importées depuis un fichier sont enregistrées avec leurs octets inchangés. Dans les deux cas, le chemin d'origine n'est pas emporté. Même si le destinataire tombe sur un nom de fichier semblable, il ne peut pas y voir la preuve d'un « nom de fichier d'origine plus octets d'origine » : la case du nom dans le fichier de livraison est assemblée à partir du numéro de bobine et du numéro de clip, et non le nom porté sur le disque. Gestion des chemins, normalisation des noms et traitement des octets du média sont des faits de la couche de stockage locale, et ils ne deviennent pas une colonne de chemins de médias dans le fichier de livraison.
« Le chemin ne se lit pas dans le fichier de livraison » décrit une frontière du résultat d'export, et ne porte aucun jugement sur la présence ou l'absence du média dans la bibliothèque de projet locale.
Pourquoi cela borne directement le raccordement des médias
Sans chemin de média dans le fichier de livraison, il manque au destinataire le pointeur physique qui permet de passer d'une ligne d'enregistrement à une position précise de fichier sur la machine. Le numéro de bobine, le numéro de scène et le numéro de prise restent utilisables pour établir une relation d'identité, mais ce sont des identifiants, pas des chemins. Le destinataire doit mettre ces identifiants en correspondance avec son propre inventaire des médias, le nommage des fichiers et l'état réel des répertoires.
C'est exactement la raison pour laquelle « Avant d'utiliser un ALE, vérifier ces champs » renvoie le destinataire vers les médias et les enregistrements de plateau. Un fichier s'ouvre et certaines colonnes se lisent sans qu'il porte pour autant la position des médias. Si un flux de travail exige de localiser un média directement depuis le fichier de livraison, cette correspondance doit être apportée par les informations de médias déjà disponibles du côté de la réception.
Pourquoi les quatre fichiers de livraison butent sur la même frontière
ALE et CSV sont des tableaux lisibles par machine, PDF est un résumé destiné à la lecture humaine et FDX sert à l'échange de scénario. L'instantané des enregistrements de prises qui est derrière ALE et CSV porte une case Source File Name et une case pour le fichier source, et toutes deux se remplissent par la recopie sur le plateau : recopié, la case a un contenu ; pas recopié, elle reste vide. Le PDF existe pour être lu, et FDX travaille depuis un instantané du côté scénario, qui ne porte même pas les fiches de prise. Aucun des quatre fichiers ne porte une case où le logiciel aurait découvert un chemin sur un disque, et une différence de format ne change pas cette frontière. On ne peut pas déduire d'un format qui a plus de colonnes qu'il emporterait au passage les places des médias dans la bibliothèque de projet.
Par exemple, « Ce qu'un CSV apporte de plus ou de moins qu'un ALE » traite des écarts entre jeux de champs, et non d'un chemin qui surgirait de nulle part. « À la réception d'un ALE, vérifiez d'abord ces champs » passe case par case celles qui partent vides faute d'avoir été recopiées sur le plateau, et la façon dont cette case manquante ressort sur la feuille de réconciliation de fin de journée. À la réception, il faut tenir séparés « cette case, personne ne l'a remplie », « cette case porte un texte recopié » et « un pointeur qui pourrait réellement raccorder un média ». Un nom écrit dans une colonne n'est pas une position.
Comment le destinataire établit la correspondance avec les médias
Pour relier les enregistrements d'un fichier de livraison aux médias, le destinataire doit partir des identifiants visibles tels que numéro de bobine, numéro de scène et numéro de prise, et les vérifier un à un contre son propre inventaire des médias. Si le nommage côté médias, les numéros de bobine ou l'organisation des répertoires ne concordent pas avec l'enregistrement reçu, il faut revenir à l'actualité des médias et aux enregistrements de plateau, au lieu de deviner un chemin. Le fichier de livraison, lui, n'apporte pas cette liaison directe.
Ces fichiers doivent donc être compris comme des données d'enregistrements et d'échange, et non comme un inventaire ou une sauvegarde de médias. Ce qu'ils donnent est une chaîne recopiée dans une case, pas un pointeur résoluble d'un enregistrement jusqu'aux médias de la machine du destinataire, et ils ne constituent aucune promesse qu'un projet récepteur établisse automatiquement des liens de médias. En conclusion, le destinataire doit vérifier lui-même les numéros de bobine, de scène et de prise contre son propre inventaire des médias.
FAQ
Pourquoi ALE et CSV portent-ils un nom de fichier si le chemin du média manque ?
Le nom de fichier est un indice d'identité dans l'enregistrement, le chemin est l'endroit où le média se trouve réellement : ce ne sont pas la même chose. ALE et CSV portent chacun une case Source File Name et une case pour le fichier source, remplies seulement si quelqu'un les a recopiées, et la paire de l'ALE n'accepte que l'ASCII, si bien qu'un texte non latin les laisse vides. PDF et FDX n'ont aucune des deux. La chaîne recopiée nomme les fichiers du côté du tournage, pas le répertoire de la machine du destinataire, et sa présence ne reconstitue donc jamais une position que le destinataire puisse ouvrir.
Une photo importée garde-t-elle les octets du fichier extérieur ?
Pas forcément. Les photos prises sur le plateau ou par prise rapide sont réencodées, tandis que celles choisies dans la photothèque ou importées depuis un fichier sont enregistrées avec leurs octets inchangés. Dans les deux cas, le chemin d'origine n'est pas emporté.
CSV porte-t-il des chemins de médias parce qu'il a plus de champs ?
Plus de colonnes n'ajoutent pas un chemin que le logiciel aurait trouvé. Les deux cases du CSV portent du texte recopié sur le plateau, les deux cases homonymes de l'ALE n'acceptent que l'ASCII, et PDF et FDX n'ont pas ces deux cases du tout.
À quoi se fier quand il faut raccorder un média ?
Le destinataire doit vérifier lui-même les identifiants visibles tels que numéro de bobine, numéro de scène et numéro de prise, contre son propre inventaire des médias et les fichiers réels. Il ne doit pas déduire le chemin complet d'une machine locale à partir du contenu du fichier de livraison.
Axiom One LLC — SlateX. Chiffres arrêtés au 2026-09-24.