Nommer les variantes d’une série de produits

Définir les trois niveaux d’identité

Le modèle désigne la famille de conception que vous souhaitez suivre. La variante correspond à une combinaison identifiée, comme un format et une finition. La révision décrit un nouvel état documentaire ou de conception de cette combinaison.

Écrivez ces définitions dans une courte notice avec deux exemples propres au projet. Si votre équipe utilise déjà d’autres termes, conservez-les en clarifiant leur sens. L’objectif est d’éviter qu’un même code désigne plusieurs objets différents.

Limiter les informations dans le nom

Choisissez les éléments nécessaires pour reconnaître un fichier hors de son dossier. Un nom peut inclure code du modèle, variante, révision et rôle du document. Gardez les descriptions longues et les décisions dans le registre associé.

N’encodez pas toutes les caractéristiques dans une suite difficile à lire. Les noms marketing peuvent évoluer : une référence stable peut rester liée à plusieurs libellés successifs. Consignez ces correspondances pour pouvoir relire les anciens échanges.

Prévoir substitutions et abandons

Lorsqu’une combinaison change d’identité selon votre convention, ouvrez une nouvelle variante et reliez-la à la précédente. S’il s’agit d’une révision, conservez le code de variante et modifiez l’état. Documentez le critère choisi pour que l’équipe l’applique de façon cohérente.

Une référence abandonnée reste dans le registre avec son statut. Évitez de la réutiliser immédiatement pour une autre proposition : un ancien message pourrait alors pointer vers le mauvais objet. Une ligne de correspondance coûte peu et préserve le contexte.

Déployer la convention dans les échanges

Appliquez le même code dans les listes, légendes et bordereaux. Vérifiez les noms reçus d’un partenaire et gardez leur correspondance avec vos références plutôt que de les remplacer sans trace. Les deux équipes peuvent utiliser des conventions différentes.

Faites relire un petit jeu de fichiers par une personne du projet avant de renommer toute la série. Corrigez les ambiguïtés, puis figez la notice utilisée. Une convention stable aide à retrouver les pièces mais ne prouve pas à elle seule leur contenu ou leur exactitude.

Exemple fictif : série de rangements Dune

Exemple fictif à adapter à votre projet.

Référence	Lecture proposée	Document associé
DUN-V01-r1	Modèle Dune, variante 01, état 1	Vue de présentation
DUN-V01-r2	Même variante, nouvel état	Liste des changements
DUN-V02-r1	Autre combinaison, premier état	Fiche de variante

Les codes fictifs sont une proposition de méthode, sans prétention de norme obligatoire.

Avant de transmettre

• Définir modèle, variante et révision.
• Choisir les informations utiles dans le nom.
• Créer un registre des codes.
• Conserver les correspondances avec les partenaires.
• Faire relire un jeu avant généralisation.

Questions pratiques

Faut-il inclure la date dans tous les noms ?

Elle peut être utile si l’équipe sait ce qu’elle représente. Ne l’utilisez pas seule pour distinguer les variantes ; précisez aussi leur identité et la révision concernée.

Comment migrer une série déjà nommée ?

Gardez un tableau ancien nom vers nouvelle référence et commencez par les fichiers actifs. Conservez la correspondance dans les échanges plutôt que de renommer rétroactivement toutes les pièces sans explication.

Pour poursuivre

Nommer les fichiers d’un projet créatif

Préparer un dossier produit & 3D

Organiser les responsabilités dans un studio

Cette méthode aide à identifier et conserver les pièces du projet. Elle ne remplace pas sa validation technique ni l’examen des droits et engagements applicables.