Nommage et versions

Conventions de nommage et gestion des versions pour les fichiers d'impression 3D

Par Petros, qui développe Meshory · Mis à jour le 10 août 2026 · 9 min de lecture

Toute bibliothèque d'impression 3D finit par contenir un fichier nommé à peu près dragon_v2_supported_final_FINAL.stl. C'est une blague que tout le monde reconnaît, et c'est aussi un vrai échec : le nom est le seul endroit où vit l'information de version, alors il s'allonge jusqu'à devenir inutile. Ce guide présente une convention de nommage qui reste lisible, une façon de suivre les versions sans système de gestion de versions, et une méthode pour renommer la bibliothèque que vous avez déjà sans que chaque renommage crée un doublon.

En impression 3D, les noms de fichiers en font trop. Une seule chaîne doit dire ce qu'est le modèle, de quelle variante il s'agit, s'il a des supports, pour quelle imprimante il a été slicé et de quand il date. Rien d'autre dans le flux de travail n'enregistre ces informations, alors tout finit dans le nom, et le nom s'effondre sous le poids.

Comment les noms dégénèrent

Le schéma est toujours le même. Un fichier commence sous le nom dragon.stl. Vous exportez une version avec supports, et voilà dragon_supported.stl. Le créateur publie un correctif, qui devient dragon_v2.stl. Vous le mettez à l'échelle pour une imprimante plus petite et obtenez dragon_v2_small.stl. Quelque part en chemin, un fichier est marqué final, puis quelque chose change, et final_FINAL voit le jour.

Trois choses précises ont mal tourné, et elles demandent des solutions différentes :

• L'ordre est perdu. Rien dans v2, final et FINAL n'indique lequel est arrivé en dernier. Seule la date de modification du fichier le dit, et elle est détruite quand vous copiez des fichiers d'un disque à l'autre.
• Variantes et versions sont mélangées. Les suffixes supported et small désignent des variantes qui coexistent ; v2 est une version qui remplace v1. Les mettre dans la même chaîne empêche de savoir quels fichiers sont des alternatives et lesquels sont obsolètes.
• Rien ne conserve le contexte. Pourquoi v2 existe, ce qui n'allait pas avec v1, et laquelle vous avez réellement imprimée avec succès : tout cela ne vit que dans votre mémoire, et pas longtemps.

Une convention de nommage qui tient la route

Une bonne convention est courte, se trie correctement et n'a jamais besoin d'être modifiée après coup. Quatre règles suffisent :

1. 1Commencez par le nom du modèle, tel que le créateur l'a donné. C'est votre lien vers la page boutique et vers les éventuelles instructions, et c'est ce qui permet de retrouver le fichier sous le nom que les autres lui donnent.
2. 2Utilisez des dates ISO, pas des numéros de version, quand vous avez besoin d'un ordre : dragon_2026-03-14.stl se trie correctement dans tous les gestionnaires de fichiers du monde et se lit sans légende. Les numéros de version ne fonctionnent que si vous ne perdez jamais le compte, et tout le monde finit par le perdre.
3. 3Placez les variantes à une position fixe, avec un vocabulaire fixe. Choisissez supported ou unsupported, choisissez un seul mot pour l'échelle, et utilisez-les toujours dans le même ordre. dragon_supported_75pct est lisible ; dragon_75_sup_fix ne l'est pas.
4. 4N'écrivez jamais final, dernier, nouveau ou corrigé. Chacun de ces mots n'est vrai qu'au moment où vous le tapez, et devient un mensonge en moins d'une semaine.

Appliquée de façon cohérente, cette convention donne des noms comme wyrm_supported_2026-03-14.stl. Ils se trient par ordre chronologique, ils indiquent la variante, et ils auront encore du sens dans deux ans, ce qui est le seul vrai test.

Gérer les versions sans système de gestion de versions

Pour un modèle imprimé, ce que vous voulez vraiment retenir n'est pas la suite des modifications. C'est quel fichier s'est bien imprimé, sur quelle machine, avec quels réglages, et ce qui a échoué avec les autres. Cela relève de la note, pas d'un historique de commits.

C'est là que le nom de fichier doit cesser de s'allonger et qu'une couche distincte doit prendre le relais. Gardez la version réussie sous un nom stable, et notez le contexte à un endroit où il peut être recherché : ce qui a échoué, pour quelle imprimante c'était, pour quel matériau il a été slicé. Meshory conserve des notes et une attribution de filament par modèle, à côté du modèle, et des tags comme imprimé, raté ou supports-requis font du statut un critère de filtre pour toute la bibliothèque, au lieu d'une information codée dans un nom de fichier.

Soyons clairs sur la limite : les tags indiquent qu'une version a été imprimée, pas les réglages utilisés. Les outils conçus pour cette tâche vont plus loin que Meshory. GyroidVault regroupe v1, v2 et final sous une seule fiche de modèle avec un journal d'impression, et PrintStash rattache chaque fichier slicé à son modèle source, avec les réglages du slicer extraits du fichier. Si retrouver une impression réussie six mois plus tard est la seule raison pour laquelle vous lisez ceci, commencez par là.

La répartition générale, où les dossiers portent l'emplacement, les tags les propriétés et les collections l'intention, est expliquée dans le système à trois couches. Le statut de version a clairement sa place dans la couche des tags.

Faut-il utiliser Git pour les fichiers STL ?

Pour vos propres conceptions paramétriques, parfois. Pour une bibliothèque de modèles téléchargés, non. Git stocke une copie complète de chaque version de chaque fichier binaire, donc un dépôt contenant quelques centaines de STL grossit sans limite et chaque clone embarque tout l'historique. Git ne sait pas non plus montrer ce qui a changé entre deux versions d'un maillage, alors que c'est justement ce qu'un système de gestion de versions est censé bien faire.

Il existe un cas précis où cela fonctionne : les fichiers source des modèles que vous concevez vous-même, en particulier les formats texte comme OpenSCAD, où les diffs ont un sens et où les fichiers sont petits. Gardez la source dans Git si vous le souhaitez, et traitez les STL exportés comme des artefacts de build qui vivent dans votre bibliothèque habituelle.

Renommer une bibliothèque existante

Appliquer une nouvelle convention à des milliers de fichiers existants, c'est là que les projets de nommage déraillent, car l'approche évidente crée exactement le problème qu'elle devait résoudre. Copiez un fichier sous son nouveau nom en prévoyant de supprimer l'original plus tard, et pendant un temps vous avez les deux. Oubliez une suppression, et vous avez un doublon permanent qu'aucune recherche par nom ne reliera jamais à son jumeau.

1. 1Dédoublonnez d'abord. Renommer une bibliothèque qui contient encore des copies revient à renommer plusieurs fois le même modèle, et cache les copies derrière de nouveaux noms. Commencez par une passe sur le contenu et la géométrie avec un détecteur de doublons.
2. 2Renommez sur place, ne copiez jamais pour supprimer ensuite. Un vrai renommage est atomique. Une copie est un second fichier qui existe jusqu'à ce que vous pensiez à supprimer le premier.
3. 3Renommez avec un outil qui conserve vos métadonnées. Si les tags, les notes et les miniatures sont liés au chemin, renommer les fait tous disparaître et vous repartez de zéro.
4. 4Ne touchez pas aux fichiers des créateurs sans raison. Leur nom est votre lien vers la source, et une convention personnelle justifie rarement de le perdre.

Meshory renomme le vrai fichier ou dossier sur le disque et met à jour l'entrée de la bibliothèque dans la même opération, si bien que les tags, les notes, les collections et les miniatures suivent, y compris quand vous renommez un dossier et tout ce qu'il contient. Il vérifie les noms selon les règles de chaque plateforme que touche votre bibliothèque : un nom qui poserait problème sous Windows ou sur un partage NAS est refusé pendant la saisie au lieu d'être découvert plus tard. Il refuse aussi d'écraser un fichier existant au lieu de le remplacer en silence. Les détails sont dans renommer des fichiers et des dossiers.

Que faire plutôt que renommer

Avant un renommage en masse, posez-vous la question : que cherchez-vous vraiment à corriger ? En général, vous ne retrouvez pas vos fichiers et vous ne savez pas ce qu'est un fichier. Renommer ne règle ces deux problèmes qu'indirectement, et à grand coût.

Une recherche sur les noms, les chemins, les tags et les descriptions vous permet de retrouver vos fichiers sans en toucher un seul. Les miniatures rendues identifient un modèle mieux qu'un nom de fichier ne le pourra jamais, car vous voyez le modèle plutôt qu'une description. À elles deux, elles font disparaître l'essentiel de l'envie de renommer, et la convention de nommage devient une règle que vous appliquez aux nouveaux fichiers plutôt qu'un chantier à mener sur dix mille anciens. Le système complet dans lequel cela s'inscrit est décrit dans le guide complet pour organiser une bibliothèque STL.