Nommer, ranger, retrouver : une convention de nommage qui survit à un projet de six mois
This article is currently available in French only. The page chrome is translated, the article body is not — yet.
Un projet de motion design qui dure six mois, c'est rarement le même animateur du début à la fin. On y croise des freelances qui entrent et sortent, des réviseurs qui reprennent un fichier deux mois après l'avoir quitté, et des chefs de projet qui cherchent désespérément la composition « version finale bonne » parmi dix-sept comps portant ce nom. La convention de nommage n'est pas une formalité administrative : c'est l'infrastructure invisible qui détermine si le projet reste manœuvrable ou s'effondre sous son propre poids.
La plupart des studios rédigent une charte de nommage en début de projet, puis l'abandonnent silencieusement à la troisième semaine quand la pression monte. Cet article ne propose pas une charte de plus à afficher dans le Notion du studio. Il propose une mécanique concrète, testée sur des projets éditoriaux, des séries d'identité TV et des campagnes publicitaires multi-versions, qui reste applicable même quand personne ne pense à l'appliquer.
Poser les fondations : le préfixe de projet comme passeport universel
Toute convention durable commence par un identifiant de projet court, unique et systématiquement placé en tête de chaque élément nommé. Un préfixe de trois à cinq caractères majuscules suffit. Pour une campagne pour une marque automobile lancée en automne, on écrira AUT24 plutôt que « AutoCampagne_Automne_2024 ». Ce préfixe précède absolument tout : les dossiers de projet AE, les fichiers .aep, les compositions, les prérendus, les exports, les fichiers sources.
L'intérêt n'est pas esthétique. Quand un animateur travaille simultanément sur trois projets, ses fichiers temporaires, ses exports de test et ses prérendus portent tous le même préfixe. Le Finder ou l'Explorateur Windows ne devient plus une jungle. Mieux : quand ce fichier atterrit sur le poste d'un autre animateur six semaines plus tard, il sait immédiatement à quel projet il appartient sans ouvrir le moindre fichier. Le préfixe fonctionne comme un passeport : il identifie l'origine sans ambiguïté, même hors contexte.
Anatomie d'un nom de composition : les six blocs qui structurent tout
Un nom de composition bien construit suit une séquence de blocs séparés par des underscores. L'ordre des blocs n'est pas arbitraire : il correspond à l'ordre dans lequel on cherche une comp dans le Project Panel. On va du général au particulier, puis on ajoute les métadonnées de version.
Les six blocs sont les suivants. Premier bloc : le préfixe de projet (AUT24). Deuxième bloc : le module ou la scène (INTRO, SCENE03, PACKSHOT). Troisième bloc : le type de composition (MASTER pour la comp de sortie, ANIM pour une comp d'animation isolée, PRE pour un precomp, GFX pour un élément graphique autonome). Quatrième bloc : la variante ou la langue si applicable (FR, EN, VERSION_A). Cinquième bloc : le format de sortie si la comp est dupliquée pour plusieurs formats (16x9, 9x16, 1x1). Sixième bloc : le numéro de version (v01, v02, v03).
Un nom complet ressemble alors à AUT24_SCENE03_MASTER_FR_16x9_v04. C'est long, mais c'est lisible d'un seul coup d'œil. En deux secondes, on sait de quel projet il s'agit, quelle scène, que c'est la comp de sortie, en français, pour le format horizontal, et qu'on est à la quatrième version. Aucune de ces informations ne nécessite d'ouvrir quoi que ce soit.
La hiérarchie des dossiers dans le Project Panel : miroir de la structure du fichier
La convention de nommage des compositions n'a de sens que si la structure de dossiers dans le Project Panel la reflète. Un Project Panel à plat, sans dossiers, est ingérable au-delà de cinquante compositions. La hiérarchie recommandée suit quatre niveaux maximum : au-delà, on perd plus de temps à naviguer qu'on n'en gagne à organiser.
Premier niveau : des dossiers fonctionnels immuables, nommés en majuscules avec underscore de tête pour qu'ils remontent en haut du panel : _MASTERS, _PRECOMPS, _SOURCES, _RENDERS, _GARBAGE. Le dossier _GARBAGE est non négociable — il donne un endroit légitme où mettre les comps abandonnées sans les supprimer, ce qui évite les suppressions accidentelles et les « je ne retrouve plus la comp d'avant ».
Deuxième niveau : à l'intérieur de _PRECOMPS et _MASTERS, des sous-dossiers par scène ou par module (SCENE01, SCENE02, PACKSHOT). Troisième niveau : à l'intérieur de _SOURCES, des sous-dossiers par type de source (VIDEO, AUDIO, IMAGES, ILLUSTRATOR, FONTS). Quatrième niveau : uniquement si le projet est vraiment massif, un sous-dossier par langue ou par format dans les sources vidéo.
Une règle simple : si on ajoute un cinquième niveau, c'est que le projet devrait être scindé en plusieurs fichiers .aep distincts, pas consolidé dans un seul fichier de plus en plus lourd.
Versionner sans se perdre : la différence entre version de fichier et version de rendu
La plus grande source de confusion dans les projets longs vient de la collision entre deux systèmes de versioning qui coexistent sans se parler : la version du fichier .aep et la version du rendu exporté. L'animateur ouvre AUT24_MAIN_v07.aep et exporte un fichier qu'il appelle AUT24_EXPORT_FINAL.mp4. Trois semaines plus tard, personne ne sait lequel des douze fichiers portant FINAL dans leur nom correspond à quelle version du projet.
La règle est simple et doit être gravée dans la charte : le numéro de version du rendu correspond toujours au numéro de version du fichier .aep au moment de l'export. Si on exporte depuis AUT24_MAIN_v07.aep, le rendu s'appelle AUT24_SCENE03_MASTER_FR_16x9_v07.mp4. Pas FINAL, pas OK_CLIENT, pas BONNE_VERSION. Le mot FINAL n'existe pas dans une convention de nommage sérieuse.
Pour les exports de révision intermédiaires qui ne méritent pas d'incrémenter la version principale, on ajoute un suffixe de sous-version : v07a, v07b. Cette sous-version signale qu'il s'agit d'un ajustement mineur dans la même session de travail, pas d'une révision formelle validée. Quand le client valide, on incrémente le chiffre principal et on archive les sous-versions.
Nommer les calques : ce que le timeline raconte à quelqu'un qui n'était pas là
Le nommage des calques est l'aspect le plus souvent négligé parce qu'il est invisible depuis l'extérieur du fichier. Pourtant, c'est là qu'on perd le plus de temps : retrouver quelle shape layer contient le masque de fond, comprendre pourquoi il y a trois calques nommés « Solid 1 », « Solid 2 » et « Solid 3 », identifier à quelle scène appartient un précomp nommé « Precomp 14 ».
La règle minimale : chaque calque est nommé par sa fonction, pas par son type. On ne dit pas « Shape Layer 1 », on dit « BG_Gradient_Ciel ». On ne dit pas « Precomp 14 », on dit le nom exact de la composition qu'il contient — After Effects le fait automatiquement si on n'a pas renommé le calque à la main, à condition que la comp source soit bien nommée.
Pour les calques de contrôle (expressions, null objects, guide layers), on préfixe avec CTRL_ ou NULL_. Pour les calques d'adjustment, avec ADJ_. Pour les calques de fond, avec BG_. Pour les calques de texte dynamiques liés à des expressions, avec TXT_. Ces préfixes permettent de grouper les calques par fonction dans le timeline même quand ils ne sont pas physiquement regroupés, et de comprendre immédiatement le rôle d'un calque sans l'ouvrir.
Une astuce de production : activer le label de couleur de façon cohérente avec le type de calque. Les nulls en jaune, les adjustment layers en rouge, les solides de fond en violet. Couplé au nommage, la couleur crée une double redondance visuelle qui accélère la lecture du timeline même sur un écran réduit.
Faire vivre la convention : intégration dans le onboarding et les outils d'automatisation
Une convention que personne ne lit ne sert à rien. La vraie question n'est pas comment rédiger la charte, mais comment faire en sorte que chaque nouveau collaborateur, freelance ou interne, l'applique dès son premier jour sur le projet sans avoir à la mémoriser.
La première étape est le template de projet. Un fichier .aep vide, correctement structuré, avec les dossiers du Project Panel déjà créés, les comps de départ nommées selon la convention, et un calque texte dans la comp principale qui rappelle les règles de nommage en commentaire d'expression. Ce fichier template est la première chose qu'on remet à un nouveau collaborateur. Il ne peut pas démarrer sans suivre la structure.
La deuxième étape est l'automatisation partielle. Des scripts simples — réalisables en ExtendScript ou via des outils comme KBar — permettent de créer automatiquement une nouvelle composition avec le bon nom en demandant à l'utilisateur de renseigner le module, le type et le numéro de version. L'animateur n'a jamais à taper le préfixe de projet à la main, donc ne peut pas l'oublier ou le mal orthographier.
La troisième étape est la revue de projet hebdomadaire. Pas une réunion supplémentaire : simplement une habitude de cinq minutes où le lead animateur ouvre le Project Panel, filtre les comps sans préfixe correct, et les renomme ou les déplace avant que l'entropie ne s'installe. Une convention de nommage ne se maintient pas seule — elle se maintient par friction faible et correction précoce.
ConclusionConclusion
Une convention de nommage n'est pas un document qu'on rédige une fois et qu'on oublie : c'est un protocole vivant qui se renforce par l'outillage, la répétition et la correction rapide des écarts. Sur un projet de six mois, la différence entre un studio qui livre proprement et un studio qui passe ses dernières semaines à retrouver des fichiers tient souvent à ces choix faits en début de production — un préfixe cohérent, six blocs dans le bon ordre, un dossier _GARBAGE, et l'interdiction définitive du mot FINAL dans un nom de fichier.
Questions fréquentesFrequently asked questions
Faut-il une convention différente pour les projets en équipe et les projets solo ?
La convention en solo peut être plus légère — pas besoin du préfixe de projet si vous ne travaillez que sur un projet à la fois — mais les blocs de type, de variante et de version restent utiles. Vous vous remercierez vous-même six mois plus tard quand vous rouvrez un fichier.
Que fait-on quand un freelance rejoint le projet à mi-parcours avec ses propres habitudes de nommage ?
On ne négocie pas la convention : on lui remet le template de projet, on lui montre un exemple de comp correctement nommée, et on précise que ses livraisons seront refusées si elles ne respectent pas la structure. La clarté en amont évite la friction en aval.
Comment gérer les fichiers sources renommés par le client qui arrivent avec des noms incohérents ?
On ne renomme jamais les fichiers sources originaux — cela casse les liens si le client envoie une mise à jour. On crée un dossier SOURCES_CLIENT dans lequel on place les fichiers tels quels, et on documente dans un fichier texte ou un commentaire de comp le lien entre leur nom original et leur usage dans le projet.
Le système de blocs avec underscores fonctionne-il dans tous les systèmes d'exploitation ?
Oui. L'underscore est un caractère sûr sur Windows, macOS et Linux. On évite les espaces, les accents, les parenthèses et les caractères spéciaux comme & ou # qui peuvent générer des erreurs dans les chemins de fichiers ou les scripts.
Comment nommer les renders intermédiaires de test qu'on ne garde jamais longtemps ?
On préfixe avec TEST_ suivi du nom de la comp source et d'un horodatage court (TEST_AUT24_SCENE03_v04_1512 pour 15h12). Ces fichiers vont dans un dossier RENDERS_TEST séparé qui est purgé chaque semaine. Ils n'entrent jamais dans le système de versioning officiel.
Faut-il inclure la date dans le nom des fichiers .aep ?
Non. La date dans le nom du fichier crée une fausse piste : elle indique quand le fichier a été créé ou renommé, pas son état réel. La version (v01, v02...) est un indicateur bien plus fiable. La date reste utile dans les dossiers d'archive, pas dans les noms de fichiers actifs.
Que se passe-t-il quand un projet change de nom en cours de route, ce qui invalide le préfixe ?
On garde le préfixe d'origine jusqu'à la fin du projet. Changer de préfixe en milieu de production brise la cohérence et peut casser des liens si des scripts ou des systèmes de render farm utilisent ce préfixe comme identifiant. Le préfixe est interne, il ne doit pas refléter le nom commercial du projet.
Comment gérer les déclinaisons d'un même projet pour différents clients ou marchés ?
On traite chaque marché comme une variante dans le cinquième bloc du nom de composition (FR, DE, UK), mais on maintient un seul préfixe de projet. Si les déclinaisons sont très divergentes — typographies différentes, durées différentes, logiques d'animation différentes — il vaut mieux créer un fichier .aep distinct par marché avec le même préfixe suivi d'un suffixe marché : AUT24_FR et AUT24_DE.
Est-il utile de nommer les expressions et les scripts liés au projet selon la même convention ?
Oui, surtout pour les scripts de gestion de projet ou les presets d'animation réutilisables. Un preset nommé AUT24_BounceIn_v02.ffx est immédiatement identifiable comme appartenant à ce projet, à cette version. Cela évite de polluer la bibliothèque globale du studio avec des presets non documentés.
Comment convaincre un directeur artistique ou un client que cette organisation vaut le temps investi ?
On ne vend pas la convention comme un investissement abstrait. On la présente comme une réduction concrète du coût des révisions : quand le client demande à modifier la version d'il y a trois semaines, on retrouve le fichier exact en trente secondes au lieu de passer une demi-heure à reconstituer l'historique. Sur un projet de six mois, ce gain se compte en jours, pas en minutes.