Comment numéroter ses versions de document ??
NOTE : aide pré-version 2023.
Pour donner des numéros de versions pertinents aux documents de travail, on peut s’inspirer de l’utilisation qu’en font les développeurs informatiques qui ont recours à une numérotation assez stricte, en tout cas performante, de leurs applications.
Cette numérotation s’appuie sur trois chiffres, par exemple 12.4.356.
On peut n’indiquer pour un document que le numéro de version majeur (par exemple “v3”), ou le numéro de version majeure et de version mineure sans le numéro de “patch” (par exemple, v3.12) — notez le “v” minuscule).
Le tout premier document peut porter le numéro de version 1 mais peut aussi, si l’on souhaite suggérer un premier jet, ou une version pas encore “lisible porte ouverte” (comme le dirait Stephen King), on peut utiliser le numéro 0 (les développeurs l’utilisent pour indiquer une version encore incomplète, en développement).
Notons pour commencer que pour les versions majeures et mineurs, les changements sont parfois subjectifs, pas toujours évidents à déterminer.
On peut appliquer quelques règles simples pour appliquer de “bons” numéros de version.
v1. Il s’agira en fait de la version 1.1.1. Si on abrège 12.4, il s’agira de 12.4.1. Noter que c’est utile seulement lorsque l’on numérotera la version ou sous-version suivante.QDF a été modifiée. Lorsqu’un nouveau personnage important a été introduit. Et tout autre changement “majeur”.12.4.13. Dans ce cas, on corrige la faute et on renomme la version 12.4.14.Comme vous le savez, un projet peut comporter de nombreux documents : synopsis, pitch, structure, scénier ou scénario (pour le roman), manuscrit, continuité dialoguée, etc.
Pour les numéroter, pour pouvez adopter deux méthodes.
2.4 de votre synopsis et que vous attaquez la continuité dialoguée, cette continuité portera le numéro v0 ou v0.1.1. L’avantage de cette méthode est que le numéro de chaque document correspond vraiment au travail qui a été effectué sur lui, au nombre de modifications majeures et mineures qu’il a subi. Le désavantage, c’est qu’il est plus difficile de retrouver la correspondance entre les différents document. Ici, comment savoir que la version v.0.1.1 du scénario correspond à la version v2.4 du synopsis ?v2.4 de votre projet, c’est-à-dire que vous avez un pitch_v2.4.4, un synopsis_v2.4.123 et que vous attaquez pour la première fois le scénario, vous numérotez le scénario : scenario_v2.4. Noter que dans cette façon de faire, on ne tient pas compte du numéro de patch. L’avantage, c’est qu’il sera facile de retrouver les documents correspondant à une version quelconque (ici la 2.4). Le désavantage, c’est que le numéro de version du document ne sera pas significatif de son développement. Ici, la toute première version du scénario portera le numéro 2.4, donc laissera supposer que c’est une seconde version, 4e sous version.Vous le voyez, aucune solution n’est parfaite.
La meilleure méthode consiste peut-être à adopter une fusion des deux précédentes :
Pour terminer, je ne saurais trop vous suggérer d’avoir, à la racine de votre dossier de développement, un fichier qui pourrait s’appeler “Dernieres-versions.txt”. À l’intérieur de ce fichier, vous pouvez tenir à jour le numéro de dernière version de tous vos documents du projet. Cela permet, notamment pour le manuscrit ou le script final, de toujours bien transmettre la dernière version.
Ce fichier peut ressembler à :
Pitch : v13.5.247
Synopsis complet : v4.12.300
Scénario : v8.34.199
Ou, si l’on a adopté la meilleure méthode de numérotation :
Version 3
-Pitch : v2.3
-Synopsis : v2.1.123
Scénario: v3.45.8
Version 2
Pitch : v2.3
Synopsis : v2.1.123
Scénario : v2.67.2
Version 1
Pitch : v1.4.12
Synopsis : v1.8
Noter que l’ordre est inverse, la dernière version est toujours au-dessus.
Noter les “-” qui précèdent certains documents, qui indiquent qu’ils n’ont pas “bougé” de la version précédente. Ils gardent le même numéro.
Une excellente habitude, si l’on veut être sûr de parler du même document avec un lecteur, un co-auteur, un producteur ou autre, est d’être très strict à partir du moment où le document doit “sortir” de son bureau de travail.
C’est le cas par exemple d’un manuscrit ou d’un scénario. Imaginons un… scénario pour montrer les bonnes habitudes.
Imaginons que j’aie achevé mon manuscrit de roman et qu’il porte le numéro de la version v5.2.
(je consigne cet envoi dans mon historique — un fichier à la racine de mon projet, où je note toutes mes actions, avec la date et l’heure) :
HISTORIQUE
25/4/2020 - ENVOI v5.2 du scénario à A
25/4/2020 - ENVOI v5.2 du scénario à B
25/4/2020 - ENVOI v5.2 du scénario à C
20/4/2020 - FIN DE LA RELECTURE DE v5.2 du scénario
...
dans mon fichier de dernière version, j’ajoute :
DERNIÈRES VERSION
Scénario : 5.2
je corrige la faute dans le nouveau document et j’incrémente son numéro de patch. Le document porte désormais la version v5.2.2 (pour rappel, la version v5.2 est la version complète v5.2.1),
HISTORIQUE
26/4/2020 - Correction (<- B)
25/4/2020 - ENVOI v5.2 du scénario à A
25/4/2020 - ENVOI v5.2 du scénario à B
25/4/2020 - ENVOI v5.2 du scénario à C
20/4/2020 - FIN DE LA RELECTURE DE v5.2 du scénario
...
dans mon fichier de dernière version, j’ajoute :
DERNIÈRES VERSIONS
Scénario : 5.2.2
5.2.2 et je corrige la duplication,v5.2.3,dans mon fichier de dernière version, j’ajoute :
DERNIÈRES VERSIONS
Scénario : 5.2.3
… et ainsi de suite, avec la certitude que la dernière version — celle qui a le numéro le plus élevé — est toujours la dernière.