Ce que FDX sert à échanger, et ce qu'il perd
Ce que FDX assume dans SlateX est un échange de structure de scénario : épisodes, scènes, titres de scène, marques jour/nuit, nombre de pages, éléments de texte et couleurs de révision peuvent entrer dans ce chemin ; les plans, les fiches de prise, les jours de tournage, les paramètres de caméra et l'état de plateau laissés par le tournage ne font pas partie des objets que cette importation crée. Autrement dit, FDX peut apporter la structure du scénario, mais « importation réussie » ne veut pas dire « le projet de tournage est déjà construit », et ne veut pas davantage dire que tout revient mot pour mot après un aller-retour.
Ici, FDX est un support d'échange de la structure du scénario, et non un conteneur des résultats du tournage.
Ce que l'importation crée réellement
Le chemin d'importation actuel de SlateX ne crée que trois familles d'objets métier : les épisodes, les scènes et les éléments de scénario. Les plans ne sont pas créés avec l'importation, pas plus que les fiches de prise, les jours de tournage ou les paramètres de caméra. Les préréglages d'équipe de production tels que le groupe, le réalisateur ou le directeur de la photographie n'ont pas non plus de point d'écriture sur ce chemin, et doivent être traités à part dans le produit.
Cette frontière décide directement à quelles questions FDX peut répondre. Il convient pour découper un scénario en scènes et en structure de texte lisibles, afin que les enregistrements ultérieurs aient une base de scénario ; il ne convient pas pour le décrire comme « une fois importé, le plan de tournage et les enregistrements de plateau sont prêts ». Qu'une structure existe dit seulement que cette structure est entrée dans le modèle de données.
Ce qui précède le premier titre de scène lisible ne forme pas de texte de scène
L'analyse actuelle prend le titre de scène lisible comme point de départ de la création des scènes. Un paragraphe situé avant le premier titre de scène lisible n'a aucune scène déjà existante auquel se rattacher, et n'entre donc pas dans le texte des scènes après importation. Des contenus apparentés aux entrées d'ouverture tombent hors de cette frontière.
Si le texte du titre de scène est vide lui-même, la scène correspondante n'est pas créée non plus. Il ne faut pas y lire une quelconque « intention » du produit ; la formulation exacte est celle-ci : l'étape qui crée les scènes exige un texte de titre de scène disponible, et, quand cette condition de support manque, aucun objet de scène n'a où s'écrire.
« Analyse réussie » peut aussi ne donner aucune scène
Il existe un autre cas facile à mal lire : un FDX bien construit qui ne contient aucun titre de scène lisible peut malgré tout renvoyer une analyse réussie et ouvrir l'écran de sélection de scènes comme d'habitude, avec une liste vide et sans indication supplémentaire.
Cela veut dire que « le fichier a été analysé avec succès » et « du contenu a été importé » forment deux contrôles différents. Le premier dit seulement que le processus d'analyse a atteint la branche de succès ; le second demande encore de voir si des scènes apparaissent réellement dans la liste de sélection, et si les éléments de scénario correspondants ont bien été créés après l'importation.
Un état d'importation qui dit succès ne veut pas dire que des scènes sont déjà entrées dans le projet ; on regarde d'abord la structure réellement créée.
Plusieurs réécritures certaines se produisent à l'aller-retour
En combinant les codes des deux côtés, lecture et écriture, de SlateX, on dérive plusieurs réécritures certaines. Une scène importée depuis un FDX puis réécrite voit sa construction de titre de scène raccorder une fois de plus le titre et l'information jour/nuit déjà contenus dans le titre d'origine. Le préfixe du titre de scène conserve son point à la lecture, et le côté écriture en ajoute un, si bien qu'un aller-retour peut produire un doublon comme INT...
Le champ du résumé n'est pas non plus symétrique dans les deux sens. Le résumé peut être lu, mais le côté écriture ne le reporte pas sur le même champ de résumé ; à une nouvelle importation, le résumé de la scène est de plus remplacé par le contenu du premier élément de texte. Quand le nombre de pages vaut zéro, le côté écriture n'écrit pas d'attribut de longueur, et le côté relecture traite une longueur absente comme 1/8 de page. L'état de tournage ne suit pas, lui non plus, cet aller-retour de structure, et une réimportation ramène la scène à l'état « non tournée ».
Il ne s'agit pas d'une supposition sur le comportement d'un logiciel tiers, mais du résultat obtenu en combinant les codes des deux côtés d'écriture et de relecture de SlateX. La frontière doit être écrite en même temps : nous n'avons pas encore mené d'acceptation d'aller-retour « ouvrir, enregistrer sous, puis réimporter » avec de vrais logiciels de scénarisation tiers, et la seule chose qui puisse être dite publiquement est qu'un aller-retour ne garantit pas une fidélité mot pour mot, sans l'écrire comme validé par une quelconque acceptation externe.
Quelles informations de tournage ne sont pas du tout dans cet échange
Les plans, les fiches de prise, les jours de tournage, les paramètres de caméra, le timecode, la notation et les chemins de médias ne font pas partie du périmètre que le FDX actuel peut porter. Le chemin d'importation ne crée pas ces objets, et le côté écriture ne glisse pas ces enregistrements de plateau dans la structure du scénario.
Ainsi, quand une information ne revient pas, la bonne question est « cette couche a-t-elle un champ ou un objet capable de la porter », et non un motif inventé à la place du produit pour expliquer « pourquoi elle serait perdue ». Pas de chemin d'écriture, voilà ce que cela veut dire, sans autre explication.
Un aller-retour non fidèle ne veut pas dire que le fichier est inutile
FDX reste adapté à l'échange de la structure du scénario. Il peut apporter dans SlateX des structures telles que les scènes, les titres de scène, le jour/nuit, le nombre de pages et les éléments de texte, et peut aussi réécrire dans un fichier la structure de scénario du projet courant. Seulement, cet échange doit être compris aujourd'hui comme une livraison de structure, et non comme une boucle de brouillon que l'on éditerait dans les deux sens sans qu'aucun caractère ne change.
Si le destinataire veut continuer à s'en servir, il vérifie la structure réellement présente dans le fichier, et ne tient pas « cela s'ouvre » ou « cela se réimporte » pour une preuve de fidélité du contenu.
Deux questions que cette famille doit encore traiter séparément
Cette page ne répond qu'à ceci : quelles structures FDX sert à échanger, et quels contenus ne sont pas conservés sur ce chemin. Deux questions méritent encore d'être développées à part : « quelles informations ne reviennent pas », en disant, point par point, s'il manque un champ, un objet ou un chemin d'écriture de sortie ; et « que crée réellement l'importation », en séparant les épisodes, les scènes et les éléments de scénario des objets de tournage qui ne sont pas créés.
FAQ
L'importation d'un FDX crée-t-elle automatiquement les plans et les fiches de prise ?
Non. L'importation actuelle ne crée que les épisodes, les scènes et les éléments de scénario, et ne crée ni plans, ni fiches de prise, ni jours de tournage, ni paramètres de caméra.
Une analyse réussie veut-elle dire que des scènes ont été importées ?
Pas forcément. Un fichier bien construit sans aucun titre de scène lisible peut encore atteindre l'analyse réussie et ouvrir une liste de sélection de scènes vide, si bien qu'il faut vérifier les scènes réellement créées.
Un aller-retour FDX conserve-t-il les titres de scène mot pour mot ?
On ne peut pas le garantir ainsi. Les deux côtés, lecture et écriture, produisent des réécritures certaines comme l'empilement du titre et du jour/nuit ou le doublon de point au préfixe, et la seule chose publiable reste « un aller-retour ne garantit pas une fidélité mot pour mot ».
Pourquoi certaines informations de tournage ne reviennent-elles pas par FDX ?
Parce que le chemin d'échange FDX actuel n'a ni objet ni champ pour les porter. Il faut décrire le chemin d'écriture ou d'écriture de sortie qui manque, et ne pas expliquer cette absence par une intention du produit.
Axiom One LLC — SlateX. Chiffres arrêtés au 2026-09-24.