Le système à trois niveaux

Le système à trois couches : dossiers, tags et collections

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

La plupart des arborescences STL échouent de la même façon : elles commencent propres, puis chaque modèle qui entre dans deux catégories impose un arbitrage, et en moins d'un an l'arborescence compte dix niveaux et plus personne ne se souvient des règles. La solution : cesser de demander aux dossiers de faire trois choses à la fois. Les dossiers disent où se trouve un fichier, les tags disent ce qu'il est, et les collections disent à quoi il sert. Ce guide met en place les trois couches, avec un exemple concret et une méthode de migration pour une bibliothèque existante.

Tout système de classement de fichiers d'impression 3D finit par se heurter au même mur. Vous construisez une arborescence, elle fonctionne pour quelques centaines de modèles, puis arrive un fichier qui a sa place à deux endroits à la fois. Un dragon articulé reçu dans un bundle Patreon, qui est aussi un cadeau pour votre neveu : va-t-il dans Créatures, sous le nom du créateur ou dans Noël ? Choisissez-en un, et les deux autres recherches échoueront pour toujours.

Ce n'est pas un problème de discipline, mais de structure. Une arborescence est une hiérarchie unique, alors qu'une bibliothèque de modèles a au moins trois axes indépendants. Le système à trois couches les sépare pour qu'aucune couche n'ait à porter plus qu'elle ne peut.

Pourquoi une seule arborescence ne suffit jamais

Un dossier ne peut exprimer qu'une seule relation : l'inclusion. Un fichier se trouve dans un seul dossier, et ce dossier a un seul parent. Toute question posée à votre bibliothèque qui ne prend pas la forme d'une inclusion doit être forcée dans cette structure, et c'est ce forçage qui produit les arborescences à dix niveaux.

Regardez les questions que vous vous posez vraiment quand vous vous apprêtez à imprimer quelque chose :

• « D'où vient ce fichier, et ai-je le reste de ce bundle ? » C'est une question d'inclusion. Les dossiers y répondent bien.
• « Montre-moi tous les modèles articulés que je possède. » C'est une question de propriété. Elle traverse créateurs, bundles et dates, et les dossiers y répondent mal.
• « Qu'est-ce que j'imprime pour le salon du mois prochain ? » C'est une question d'usage. Elle est temporaire, elle mélange des modèles sans rapport, et les dossiers y répondent le plus mal.

Trois questions, trois formes, trois couches. Donnez à chacune son propre outil et aucune n'a à faire de compromis.

Couche 1 : les dossiers donnent à chaque fichier une place unique

La couche des dossiers a une seule mission : chaque fichier a un emplacement prévisible, et vous n'avez jamais à réfléchir à l'endroit où ranger quelque chose. L'arborescence doit donc être peu profonde, sans surprise, et organisée selon le seul axe qui ne change jamais après le téléchargement.

Pour presque toutes les bibliothèques, cet axe est l'origine. La provenance d'un modèle est un fait qui reste vrai pour toujours. On peut débattre de ce qu'est un modèle, pas de qui l'a publié. Une structure qui fonctionne :

• La racine de la bibliothèque est un seul disque ou un seul partage NAS. Pas cinq. Tout se trouve en dessous.
• Un niveau pour le type de source : Patreon, Thingiverse, Printables, MyMiniFactory, Kickstarter, Achats, Créations perso.
• Un niveau pour le créateur ou le bundle, exactement tel qu'il a été publié. Gardez les noms choisis par le créateur.
• Arrêtez-vous là. Deux niveaux sous la racine suffisent. Si vous avez envie d'en ajouter un troisième, c'est la couche des tags qui demande à exister.

Notez ce que cette structure ne fait délibérément pas. Elle ne trie ni par sujet, ni par imprimante, ni par matériau, ni selon que vous l'avez imprimé ou non, ni par projet. Ce sont toutes de vraies questions que vous voudrez poser, et chacune appartient à une autre couche.

Couche 2 : les tags disent ce qu'est un modèle

Les tags portent les propriétés qui traversent les dossiers. Un modèle peut avoir autant de tags que nécessaire, et c'est exactement la souplesse que les dossiers ne peuvent pas offrir. Le risque avec les tags est l'inverse de celui des dossiers : au lieu d'un excès de structure, vous obtenez un vocabulaire tentaculaire où articulé, modèle-articulé et flexi veulent tous dire la même chose.

Gardez un vocabulaire restreint et organisé en groupes. Quatre familles couvrent la plupart des bibliothèques :

Deux règles gardent le vocabulaire sain. Utilisez toujours le singulier, et ne créez jamais un tag pour ce qu'un dossier indique déjà. Si tout ce qui se trouve dans le dossier Patreon devait recevoir le tag patreon, ce tag n'apporte rien et dilue les autres.

Taguer des milliers de modèles à la main est l'étape où la plupart des systèmes meurent, et c'est pourquoi la couche des tags est celle qui mérite d'être automatisée. Meshory génère des tags à partir de règles sur les noms de fichiers et d'une analyse des couleurs, et avec votre propre clé OpenRouter, il peut examiner chaque modèle et rédiger une description de ce qu'il est vraiment, prise en compte par la recherche : un fichier nommé dragon_v2_final.stl devient ainsi trouvable comme dragon articulé. Vous acceptez ou refusez ses suggestions, et vous pouvez ajouter ou retirer n'importe quel tag à la main. Tous les détails sont dans collections ou tags.

Couche 3 : les collections disent à quoi sert un modèle

La troisième couche est celle que l'on saute, et c'est elle qui rend une bibliothèque vraiment utilisable. Les collections sont des groupes constitués à la main, liés à une intention plutôt qu'à une identité : une file d'impression, une commande client, une liste de cadeaux, les modèles destinés à un salon maker. Elles sont temporaires, ce que les tags ne sont pas, et mélangent des modèles qui n'ont rien d'autre en commun.

La distinction qui empêche les deux couches de se confondre : un tag décrit quelque chose de vrai en permanence sur un modèle, une collection décrit quelque chose de vrai en ce moment sur vos projets. Un dragon est articulé pour toujours. Il est dans la file d'impression de l'anniversaire pendant trois semaines.

• File d'impression : la collection dont presque tout le monde a besoin en premier. Ce qui passe ensuite sur le plateau, dans l'ordre.
• Collections par projet pour une commande client, une campagne de jeu de table, un stand de marché. Supprimez-les quand le projet se termine.
• Collections de référence pour les modèles que vous réimprimez souvent : pièces de calibration, benchmarks, impressions de test.

Dans Meshory, une collection peut contenir des modèles individuels ou des dossiers entiers, sans rien modifier sur le disque : le regroupement vit dans l'index, et vos fichiers restent exactement là où ils sont.

Un exemple concret

Prenons un vrai fichier : un dragon articulé issu du bundle de mars d'un créateur, que vous comptez imprimer en résine pour l'anniversaire d'un ami et que vous avez déjà imprimé une fois en PLA.

1. 1Dossier : Bibliothèque / Patreon / LoothighCreations / 2026-03-dragons. Un seul emplacement, choisi en deux secondes, jamais remis en question.
2. 2Tags : dragon, articulé, résine, imprimé. Quatre propriétés, toutes vraies en permanence, toutes interrogeables dans tous les dossiers de la bibliothèque.
3. 3Collections : Cadeaux d'anniversaire. Le modèle en est retiré une fois le cadeau remis, sans toucher au fichier ni à ses tags.

Désormais, chaque question se règle en une étape. « Qu'y avait-il dans ce bundle de mars ? » : un dossier. « Montre-moi tous les modèles articulés que je peux imprimer en résine » : deux tags. « Qu'est-ce que j'imprime ce mois-ci ? » : une collection. Aucune couche n'a dû être tordue pour répondre à une question qui ne lui correspondait pas.

Migrer une bibliothèque existante

Si vous partez de dix mille fichiers répartis sur quatre disques, ne commencez pas par réorganiser les dossiers. Réorganiser avant de dédoublonner, c'est déplacer le même modèle trois ou quatre fois, et c'est la raison la plus fréquente pour laquelle ces projets s'enlisent.

1. 1Indexez tout là où c'est. Pointez un gestionnaire de bibliothèque vers chaque emplacement avant de déplacer le moindre fichier, pour avoir d'abord une vue d'ensemble. Meshory lit les dossiers sur place et ne déplace, ne renomme ni n'envoie jamais rien en ligne.
2. 2Dédoublonnez d'abord. Des années de téléchargements laissent des copies qu'aucune recherche par nom de fichier ne relie. Le détecteur de doublons les regroupe par contenu et par géométrie pour que vous ne rangiez chaque modèle qu'une fois.
3. 3Aplatissez ensuite la couche des dossiers. Réduisez les arborescences profondes à la source et au créateur. C'est un travail ponctuel, et il est bien plus léger après le dédoublonnage.
4. 4Taguez en masse, pas en une seule séance. Laissez le tagging automatique faire une première passe, puis corrigez au fil de votre navigation. Les tags sont la seule couche qui s'améliore progressivement sans pénalité.
5. 5Créez les collections en dernier, et seulement pour ce que vous imprimez réellement en ce moment. Une collection créée « au cas où » est une collection que vous n'ouvrirez jamais.

Si votre point de départ est surtout une pile de téléchargements jamais triés, le guide plus spécifique est que faire de plus de 1 000 fichiers STL téléchargés. Et avant de renommer quoi que ce soit en masse, lisez conventions de nommage et gestion des versions, car des renommages faits dans le mauvais ordre créent des doublons plutôt que de l'ordre.

Où vit chaque couche

Cette dernière colonne compte plus qu'il n'y paraît. Dans un système fait uniquement de dossiers, renommer un fichier ou réorganiser un répertoire détruit tout le sens que portait l'ancien chemin. Quand les deux couches supérieures vivent dans un index lié au fichier plutôt qu'à son chemin, vous pouvez réorganiser le disque librement : les tags, notes et collections suivent. C'est exactement pour cette raison que Meshory suit les fichiers à travers les renommages et les déplacements, et sa recherche et ses filtres interrogent les trois couches à la fois. Ce système est l'étape 2 du guide complet pour organiser une bibliothèque STL, qui couvre les étapes de dédoublonnage, de miniatures et de NAS qui l'entourent.