Guide organisation

Nommer ses fichiers créatifs pour retrouver la bonne version

Nommer ses fichiers créatifs aide à retrouver une pièce sans l’ouvrir et à éviter les erreurs de version. Choisissez quelques informations stables, puis appliquez la même convention pendant les échanges.

Utilisez une référence de projet stable, le type de pièce, une version et, si nécessaire, une variante ou une destination. Séparez le nom de travail de la décision de validation. Documentez les changements dans un inventaire plutôt que tout entasser dans le nom.

DesignLockr · Révision du 16 octobre 2026

Nommer ses fichiers créatifs : fixer une convention, séparer les repères, garder la correspondance.

Nommer ses fichiers créatifs : choisir les informations utiles

Commencez par les erreurs que vous souhaitez éviter. Pour une série photo, il faut conserver l’identifiant du cliché. Pour un motif, le rapport et le coloris comptent. Pour une identité visuelle, la variante du logo et l’usage web ou impression aident à sélectionner le bon export.

Écrivez votre convention sur une ligne et testez-la avec cinq fichiers réels. Gardez le même ordre des informations, des séparateurs constants et des termes compris par le destinataire. Les noms trop longs sont aussi difficiles à lire que les noms vagues.

Un exemple à adapter à votre projet

La convention suivante est une proposition d’organisation : PROJET_TYPE_VARIANTE_v03_DESTINATION. Elle ne constitue pas une exigence de DesignLockr. Vous pouvez l’alléger si une information figure déjà dans le dossier parent et ne risque pas d’être perdue lors d’un envoi.

FichierCe qu’il permet de reconnaître
ATELIER_LOGO_HORIZONTAL_v03_WEBLogo horizontal et export pour le web
MOT07_RAPPORT_C02_v04Rapport du motif 07, coloris 02
REPORTAGE_0187_RET_v02Retouche du cliché 0187
CHEMISE42_MESURES_v05Tableau de mesures du modèle 42

Distinguer révision, variante et validation

Une version marque une évolution du travail. Une variante désigne une autre proposition ou un autre usage. La validation est une décision portant sur une pièce identifiée. Ces trois informations ne devraient pas se remplacer : le logo vertical v03 peut être validé alors que la variante horizontale reste en relecture.

Lorsqu’une modification arrive après validation, créez une nouvelle référence et expliquez le changement. Évitez d’écraser le fichier que le client a déjà reçu. Si vous ajoutez une date, adoptez un ordre année-mois-jour pour faciliter le tri et précisez dans l’inventaire l’événement concerné.

Maintenir la correspondance pendant les échanges

Une fois la référence partagée, conservez-la dans les retours client, les comptes rendus et les demandes de fabrication. Si un prestataire renomme les fichiers, demandez une table de correspondance. Le nom technique utilisé dans un logiciel peut coexister avec un nom de livraison plus clair.

Dans votre dossier DesignLockr, accompagnez les fichiers d’une note courte : contenu de la version, pièces remplacées et action attendue. Le nom facilite la lecture ; l’historique et les décisions conservent ce qu’un simple intitulé ne peut pas raconter.

EXEMPLE FICTIF

Cas fictif : remplacer une série de « logo final »

Un studio retrouve cinq fichiers de logo nommés final, final2 et final-client. Deux fournisseurs utilisent des couleurs différentes.

  1. Le studio identifie la pièce réellement approuvée et lui attribue une référence stable.
  2. Il distingue les exports web et impression ainsi que les variantes horizontale et verticale.
  3. Il transmet un inventaire de remplacement et archive les anciens envois avec leur contexte.

Chaque fournisseur reçoit la pièce correspondant à son usage. Le studio peut reconnaître l’ancien fichier sans le confondre avec la référence actuelle.

Votre checklist avant de continuer

  • Ordre des informations défini.
  • Références de projet stables.
  • Version et variante distinctes.
  • Destination d’export explicite si nécessaire.
  • Noms repris dans les échanges.
  • Table de correspondance conservée après renommage.

Télécharger cette checklist

Les questions à clarifier

Faut-il mettre la date dans tous les noms ?

Utilisez-la si elle aide à comprendre ou trier le projet. Une version stable et un inventaire peuvent suffire. Évitez une date dont personne ne sait si elle correspond à la prise de vue, l’export ou l’envoi.

Puis-je renommer un fichier déjà transmis ?

Conservez la correspondance entre l’ancien et le nouveau nom et prévenez les personnes concernées. Ne rendez pas les échanges précédents incompréhensibles.

Le mot « validé » suffit-il ?

Il aide à lire un dossier, mais doit être relié à une décision conservée et à la pièce exacte concernée.

Avant le prochain envoi, gardez une référence claire.

Rassemblez les bons fichiers et la bonne version. Préparez ensuite un partage et les usages convenus.

Nommer les fichiers pour éviter les choix ambigus

Une convention simple peut réunir projet, version et livrable : RIV-V02-affiche-web, CLA-C-plan-rdc ou LUM-V01-photo014. Le nom aide à choisir le bon fichier avant un envoi ; il ne certifie ni son contenu ni sa date. Les mots « final » et « final-corrigé » deviennent vite insuffisants lorsqu’un projet possède plusieurs retours et supports.

Gardez des références stables pour les pièces et faites évoluer l’indice ou la version selon votre méthode. Indiquez le support lorsque plusieurs exports coexistent. Avant un renommage important, conservez l’inventaire de correspondance afin de retrouver les anciens échanges. Si vous devez vérifier un fichier exact, utilisez sa référence de preuve et son empreinte : le nom seul peut être changé sans modifier ses octets.

RepèreExemple fictifContrôle à effectuer
PhotoLUM-V01-photo014-web.jpgIdentifiant et destination
ArchitectureCLA-C-plan-rdc.pdfProjet pièce et indice
GraphismeRIV-V02-affiche-web.pngVersion et livrable
Ambiguïtéfinal-final2.pdfRemplacer par une référence explicite

Avant de poursuivre

  • Choisir une convention avant la multiplication des exports.
  • Garder la correspondance après renommage.
  • Ne pas attribuer une valeur de preuve au nom seul.

Exemple fictif — Nommer les fichiers pour éviter les choix ambigus

Pour préparer la suite

Rattacher les retours client à une version

Séparer sources exports et livrables

Versions & historique