Pourquoi la même série de prises ne concorde, ni en lignes ni en ordre, d'un fichier de livraison à l'autre

Si un même lot de fiches de prise donne des nombres de lignes et des ordres différents selon les fichiers de livraison, ce n'est pas parce qu'ils puissent dans des projets différents : ils partent d'un même instantané pris d'après l'heure de création, puis chacun applique ses propres clés de tri et sa propre granularité de déploiement. Le livrable tabulaire garde l'ordre de création, la liste structurée retrie par scène, plan et prise, et le rapport journalier lisible utilise encore une autre clé de plan ; en même temps, les deux premiers se déploient par caméra, alors que le rapport journalier reste à une ligne par take.

Pour rapprocher plusieurs fichiers, la clé commune stable est l'identité de scène, de plan et de prise, et non « le numéro de ligne ».

Même point de départ, mais des règles de tri différentes ensuite

L'instantané est d'abord pris par ordre croissant de l'heure de création des relevés. Le livrable tabulaire ne retrie plus rien ensuite et garde donc, pour l'essentiel, cet ordre de création. La liste structurée, elle, trie de nouveau par numéro de scène, numéro de plan et numéro de prise, avec une comparaison en ordre naturel pour la scène et le plan. Les données viennent donc bien de la même source, mais la position des lignes a déjà quitté celle du livrable tabulaire.

Le rapport journalier lisible suit un troisième tri : après le numéro de scène, il prend le nom qualifié du plan comme deuxième clé, puis range par numéro de prise. Ce nom qualifié n'est pas le numéro de plan brut utilisé par la liste structurée, et deux fichiers qui contiennent pourtant la même série de takes n'ont donc aucune relation du type « la deuxième ligne doit correspondre à la deuxième ligne ».

Le journal de l'interface a encore un autre ordre. Il trie par chaîne de numéro de plan en ordre croissant, puis par numéro de prise. En tri de chaînes, 10 passe avant 2. Cet ordre n'est que la séquence d'affichage propre à la couche d'interface, et on ne peut pas non plus en déduire la position dans les fichiers exportés.

Des lignes en nombre différent, et la raison tient au déploiement par caméra

La liste structurée et le livrable tabulaire déploient tous les deux par caméra : une take rattachée à plusieurs caméras produit plusieurs lignes, et une take sans caméra garde quand même une ligne. Le rapport journalier lisible fait autrement, puisqu'il forme ses lignes d'après le nombre de takes, et une même take multi-caméras n'occupe donc toujours qu'une ligne.

Cela explique aussi pourquoi un même ensemble de relevés de plateau donne des totaux de lignes différents. Une take multi-caméras est éclatée dans la liste et dans le tableau, et reste une take dans le rapport journalier. Le No. du rapport, qui ressemble à un numéro d'ordre, est en fait le numéro de ligne de tout le document, et non un numéro de take : c'est encore moins une clé de rapprochement entre fichiers.

Les écarts de lignes viennent de la granularité de chaque produit ; ils ne veulent pas dire qu'un fichier « a une prise de plus » ou « a une prise de moins ».

L'identifiant de plan peut même être une chaîne différente selon le produit

Le rapport journalier lisible utilise le nom qualifié du plan, alors que la colonne de plan du livrable tabulaire utilise le numéro de plan brut. Un plan peut porter un préfixe de scène ou une forme qualifiée dans l'interface ou dans un fichier, et ne garder que le numéro le plus court dans un autre. Le destinataire doit les relire dans les relations de scène, de plan et de prise, au lieu de juger de l'identité d'une prise d'après la seule égalité d'une chaîne dans une colonne.

Ce qui est décrit ici est le mécanisme du côté de nos produits. Les preuves actuelles ne permettent pas d'affirmer en plus comment un logiciel aval désalignerait, manquerait un rapprochement ou refuserait l'importation à cause de cela. Le comportement de réception concret reste à vérifier colonne par colonne par le destinataire, d'après son propre modèle d'importation.

Quelle clé utiliser pour le rapprochement

Entre plusieurs fichiers, on verrouille d'abord le numéro de scène, puis le plan, puis le numéro de prise ; pour un relevé multi-caméras, on continue jusqu'à la caméra. Le but est de traiter la relation d'identité comme langue commune, au lieu de tenir la position de ligne apparue par hasard dans un fichier pour une clé principale.

Si deux fichiers n'ont pas le même nombre total de lignes, on demande d'abord s'ils n'emploient pas une granularité de déploiement différente ; s'ils ne sont pas dans le même ordre, on regarde ensuite s'ils n'utilisent pas une autre clé de tri des plans. Ce n'est que lorsque la relation d'identité elle-même ne raccroche pas qu'il faut revenir contrôler les relevés source, au lieu d'exiger d'abord que les produits s'alignent ligne à ligne.

Ces écarts résultent du mécanisme de génération, mais « le mécanisme est ainsi » ne dispense pas non plus de vérifier. Chaque produit a sa propre charge, et le destinataire doit encore confirmer que les champs qu'il utilise peuvent bien revenir au même relevé de plateau.

FAQ

Pourquoi le livrable tabulaire et la liste structurée ne sont-ils pas dans le même ordre ?

Parce que le livrable tabulaire garde l'ordre de création, tandis que la liste structurée retrie par scène, plan et prise. Les deux partent du même instantané de relevés, mais leurs règles de tri diffèrent ensuite.

Pourquoi plusieurs fichiers ont-ils des totaux de lignes différents en multi-caméras ?

La liste structurée et le livrable tabulaire se déploient par caméra, et une take multi-caméras y occupe plusieurs lignes ; le rapport journalier lisible forme ses lignes par take, et une même take n'en occupe donc toujours qu'une.

Le No. du rapport journalier peut-il se raccorder aux numéros de ligne d'un autre fichier ?

Il ne faut pas. Le No. du rapport est le numéro de ligne de tout le document, et non le numéro d'une take, et ne peut donc pas servir de clé d'identité entre fichiers.

Quelle clé commune utiliser pour rapprocher plusieurs fichiers ?

On utilise en priorité l'identité de scène, de plan et de prise, et l'on continue jusqu'à la caméra pour les relevés multi-caméras ; sans tenir un numéro de ligne, ni la position de tri d'un seul fichier, pour clé commune.

Axiom One LLC — SlateX. Chiffres arrêtés au 2026-09-24.