Ce que le FDX exporté ne fait pas revenir

Un FDX écrit depuis SlateX et ramené dans l'app ne réinstalle pas le projet original tel quel. Au niveau du fichier, le nom du projet est écrit ; au niveau des scènes, l'échange porte sur le numéro de scène, INT/EXT, le nom de la scène, le jour/nuit, les huitièmes, la couleur de révision, le marqueur d'omission, le numéro de page et les éléments de scénario. Les données de l'app qui ne sont pas dans ce périmètre d'écriture ne peuvent pas revenir par ce fichier. Et surtout, même à l'intérieur du périmètre écrit, certaines valeurs subissent après un « export puis importation » des réécritures que les codes des deux côtés permettent de dériver directement.

Ce qu'un FDX peut faire revenir est d'abord borné par le périmètre d'écriture ; une valeur qui est dans ce périmètre ne revient pas forcément mot pour mot.

Le périmètre écrit fixe le plafond de ce qui peut revenir

En prenant ensemble le niveau fichier et le niveau scène, le côté écriture conserve le nom du projet ainsi que le numéro de scène, INT/EXT, le nom de la scène, le jour/nuit, les huitièmes, la couleur de révision, le marqueur d'omission, le numéro de page et les éléments de scénario. Les plans, les fiches de prise, les caméras, le timecode, les chemins de médias, et d'autres enregistrements de plateau du même type, ne font pas partie de la structure d'écriture de ce FDX ; ces enregistrements ne peuvent donc pas être restaurés à partir de ce fichier.

C'est aussi la répartition entre « Ce que FDX sert à échanger, et ce qu'il perd » et cette page. La page parente expose le périmètre de l'échange ; ici on regarde seulement ce qui change, à l'intérieur de ce périmètre, quand un même fichier d'échange de scénario part puis revient, et ce qui n'a aucun support de retour.

Trois contenus sont réécrits de façon déterministe après un aller-retour

Le premier, c'est l'empilement du titre de scène. Pour une scène importée depuis un FDX, le nom de la scène conserve le titre original complet, tandis qu'INT/EXT et le jour/nuit en gardent chacun une copie ; à un nouvel export, le côté écriture remonte le titre de scène comme « préfixe INT/EXT + titre original complet + séparateur + jour/nuit d'origine », si bien que le titre et le jour/nuit se superposent une fois de plus. Une scène créée à la main dans l'app se comporte autrement sur ce point, parce que ces trois parties sont déjà stockées séparément et n'offrent pas la même source de superposition.

Le deuxième, c'est le doublon de point. Le côté lecture conserve le point avec un préfixe comme INT., et le côté écriture ajoute un point après INT/EXT : un aller-retour peut donc produire deux points. Il s'agit ici du résultat des deux règles juxtaposées, pas d'une supposition sur le comportement d'un logiciel tiers.

Le troisième, c'est le remplacement du résumé. À l'importation, les contenus de type Notes ou résumé peuvent entrer dans le résumé de la scène, et quand il n'y a pas de résumé de ce type en attente d'écriture, le paragraphe d'action ou le paragraphe ordinaire du début peut aussi servir de résumé ; le résumé peut donc contenir le texte intégral du paragraphe d'action, et non un résumé de l'intrigue. Le côté écriture ne reporte pas le résumé de la scène sur un attribut correspondant, de sorte qu'à la réimportation cette place peut de nouveau être prise par le paragraphe d'action ou le paragraphe ordinaire du début.

Trois autres changements de retour à examiner séparément

Quand les huitièmes d'une scène valent 0, le côté écriture n'écrit pas d'attribut de longueur ; à la relecture, une longueur absente est traitée comme 1/8 de page, donc « 0 ou absent » devient 1/8 de page. À la réimportation, l'état de la scène est écrit comme « non tournée », et l'état de tournage antérieur ne peut pas être restauré par le FDX. Les paragraphes de type Notes ou résumé ne reviennent pas comme éléments de scénario à leur place d'origine, et l'ordre des éléments de scénario est renuméroté.

Ces changements ne veulent pas dire que le fichier est dégradé ; ils disent que « ce que ce format écrit » et « comment les objets sont créés à la relecture » ne sont pas la même question. « Les quatre formes d'une valeur vide dans un fichier de livraison » aide à distinguer chaîne vide, attribut absent et valeur de remplissage, mais on reste ici limité à l'aller-retour FDX lui-même.

Frontière dure : dérivable du code, mais pas validé en aller-retour tiers

L'empilement du titre, le doublon de point et le remplacement du résumé se déduisent directement en combinant les règles d'écriture et de relecture des deux côtés. Nous n'avons pas encore parcouru dans son ensemble le cycle « ouvrir, enregistrer sous, puis réimporter » avec de vrais logiciels de scénarisation tiers, alors la seule chose établie ici tient en une phrase : un aller-retour ne garantit pas une fidélité mot pour mot.

Cette frontière borne aussi la portée des extrapolations. On ne peut pas écrire ces comportements déterministes du code comme « un logiciel tiers fera forcément ainsi », et on ne peut pas davantage présenter un aller-retour réel non parcouru comme validé ; le destinataire doit vérifier lui-même le fichier d'échange effectif ainsi que, après relecture, le titre de scène, la longueur, le résumé et l'état.

Un aller-retour ne garantit pas une fidélité mot pour mot ; le code établit que les chemins de réécriture existent, mais l'ouverture, l'enregistrement sous et la réimportation dans un vrai logiciel tiers restent à vérifier fichier par fichier.

FAQ

Le FDX peut-il faire revenir les plans et les fiches de prise ?

Ces objets de plateau ne peuvent pas être obtenus à partir de la structure d'écriture actuelle. Ils sortent du périmètre d'échange de ce FDX, et une réimportation ne les recréera pas à partir de rien.

Pourquoi le titre de scène peut-il gagner un préfixe et un jour/nuit de plus ?

Une scène importée conserve à la fois le titre original complet, INT/EXT et le jour/nuit, puis un nouvel export assemble les trois. Une scène créée à la main se comporte différemment sur ce point, parce que les trois parties sont conservées séparément à l'origine.

Pourquoi le résumé peut-il devenir du texte d'action ?

Quand aucun contenu de type Notes ou résumé n'est en attente d'écriture, le paragraphe d'action ou le paragraphe ordinaire du début peut être pris comme résumé, et le résumé n'a pas de chemin d'écriture en retour. À la réimportation, cette place peut donc être reprise par le texte intégral du paragraphe d'action.

Ces conclusions signifient-elles qu'un logiciel de scénarisation tiers a réussi un aller-retour ?

Non. Nous n'avons pas achevé de validation complète de l'aller-retour avec de vrais logiciels tiers, et le destinataire doit donc vérifier lui-même les fichiers effectifs ; la frontière publique reste « un aller-retour ne garantit pas une fidélité mot pour mot ».

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