Fermes d'impression

Gestion de bibliothèque de modèles 3D pour fermes d'impression

Par Petros, qui développe Meshory · Mis à jour le 11 oct. 2026 · 9 min de lecture

Une ferme d'impression repose sur deux systèmes que l'on confond souvent en un seul. Le logiciel de gestion de ferme pilote les machines : files d'attente, routage des travaux, attribution des imprimantes, commandes, G-code. Un gestionnaire de bibliothèque de modèles répond à une tout autre question : ce que vous possédez, où cela se trouve, et laquelle des six copies est celle que vous imprimez. Le logiciel de ferme reste largement muet sur cette seconde question, et plus la bibliothèque est grande, plus ce silence se fait sentir. Cette page détaille ce que couvre chaque couche, et précise clairement où s'arrête Meshory, car c'est un outil de bibliothèque, pas un logiciel de gestion de ferme.

Deux couches, et une seule concerne les imprimantes

PrintStash, un outil de ferme auto-hébergé et donc pas non plus une partie neutre, formule bien cette distinction dans sa propre comparaison d'août 2026 : un gestionnaire de fichiers est « une couche bibliothèque au-dessus de la machine », et « l'imprimante détermine quel logiciel contrôle la machine ; elle ne détermine pas où vivent vos modèles, vos révisions de G-code et votre historique d'impression ». C'est la distinction à garder en tête pour évaluer quoi que ce soit dans ce domaine.

La plupart des fermes finissent par faire tourner les deux à la fois, et c'est la bonne réponse, pas un compromis. L'erreur est d'attendre de l'un qu'il couvre la moitié qui revient à l'autre.

Les problèmes de bibliothèque que le logiciel de ferme laisse de côté

Ces problèmes s'aggravent avec l'échelle, ce qui explique qu'ils touchent les fermes plus durement que les amateurs.

La même pièce, enregistrée six fois, sous six noms

Une ferme accumule les doublons plus vite que quiconque : retéléchargements, kit acheté deux fois dans des lots différents, pièce réexportée à une autre échelle, même modèle converti de STL en 3MF pour une autre imprimante. La plupart des outils qui annoncent une détection des doublons hachent les octets du fichier, ce qui repère une copie renommée mais rate tous ces cas, car une réexportation ne partage aucun octet avec son original. Comparer le maillage lui-même est ce qui comble cet écart, et détection par hash ou par géométrie détaille précisément quelles copies chaque méthode retrouve.

Une bibliothèque que vous ne voyez pas

Le logiciel de ferme montre les fichiers que vous y avez déjà envoyés. Il ne génère pas d'aperçu pour les 40 000 modèles qui dorment sur le NAS et que personne n'a touchés depuis l'arrivée du Kickstarter, et un opérateur qui ne voit pas un modèle le retéléchargera ou le rachètera plutôt que de fouiller. Des miniatures sur toute l'archive sont la solution la moins coûteuse à ce problème, et celle que les outils de ferme ont le moins de chances d'inclure.

Des lots que personne n'a jamais extraits

Les sorties de créateurs et de Kickstarter arrivent en ZIP, RAR et 7Z, et restent non ouvertes, ce qui rend leur contenu invisible pour la recherche et pour toute vérification des doublons. Lire à l'intérieur des archives sans les extraire fait toute la différence entre une bibliothèque que l'on peut chercher et une bibliothèque où une part importante reste une boîte noire.

Un parc mixte veut dire des fichiers de projet mixtes

Une ferme qui fait tourner du Bambu à côté de Creality ou Snapmaker se retrouve avec des projets de slicer qui ne s'ouvrent que dans le slicer qui les a créés. Le convertisseur 3MF de Meshory, en bêta sous Tools, transfère un projet Bambu Studio, OrcaSlicer, Snapmaker Orca, Creality Print, Anycubic Slicer Next ou PrusaSlicer vers l'un des autres, sous forme de nouveau 3MF, avec les plateaux et les couleurs peintes repris et l'original laissé intact. Depuis Meshory 1.10.0, les réglages d'impression que vous avez modifiés sont aussi repris. PrusaSlicer fait exception. Ses projets n'enregistrent pas les réglages que vous avez modifiés, si bien qu'une conversion vers ou depuis PrusaSlicer utilise le profil d'impression de la destination, et comme Meshory exporte un projet PrusaSlicer sur un seul plateau, seul un projet à plateau unique s'y convertit.

Ce que Meshory fait pour une ferme

Un seul métier, à l'échelle réelle d'une ferme. Il indexe les dossiers sur place, sous macOS, Windows et Linux, y compris les partages NAS et réseau, et ne déplace rien.

• Chaque modèle visible : miniatures automatiques pour STL, 3MF, OBJ, FBX, GLB, PLY, STEP, Rhino 3DM, Fusion F3D/F3Z et Lychee LYS (expérimental), et une vraie visionneuse 3D, y compris pour les projets Bambu multi-plateaux.
• Doublons détectés de quatre façons : contenu du fichier, géométrie du maillage, dossiers entiers et chevauchement de dossiers, si bien qu'une réexportation ou une conversion de format se regroupe quand même avec son original, qu'un dossier contenant le même ensemble de modèles se réduit à un seul résultat, et qu'un bundle contenu dans un autre est signalé au lieu de passer inaperçu.
• Archives lues sur place : ZIP, RAR, 7Z et TAR/TGZ parcourues comme des dossiers, avec une miniature pour chaque modèle qu'elles contiennent, pris en compte dans la détection des doublons.
• Recherche, tags et collections sur toute la bibliothèque, avec un tagging par IA optionnel via votre propre compte chez un fournisseur ou un modèle Ollama local, jamais via un serveur Meshory.
• Droit vers le slicer : 16+ slicers installés détectés automatiquement, en un clic depuis la bibliothèque, plus le convertisseur 3MF pour un parc mixte.
• Une clé de licence, pas de compte : une licence est active sur 5 postes de travail au maximum à la fois ; une ferme qui a besoin de davantage peut écrire à support@meshory.com, et nous relèverons la limite.

Sur l'échelle, un chiffre plutôt qu'un adjectif : il a été conçu et éprouvé sur une bibliothèque de 118 270 modèles et 3,5 To, sur un seul partage NAS, avant sa sortie, et scanner un dossier NAS détaille comment les sources réseau sont gérées.

Ce que Meshory laisse aux logiciels de ferme

• Aucun contrôle des imprimantes : il ne se connecte pas aux imprimantes, ne distribue pas de tâches, ne planifie pas la production et ne surveille rien. Sa page Print queue, ajoutée dans Meshory 1.11.0, est la liste d'impression d'un maker : des lots nommés pour un marché ou une série de cadeaux, chacun avec une date d'échéance facultative, et un tableau avec une colonne pour chaque imprimante que vous ajoutez à la main ou à partir des préréglages de votre slicer.
• Aucune commande, SKU ou client : il n'y a ni catalogue de produits ni lien entre un modèle et ce que vous vendez.
• Aucun suivi du G-code : il ne versionne pas le G-code, ne conserve pas de G-code validé en regard d'une révision de modèle et d'un profil, et n'extrait pas les réglages du slicer d'un fichier déjà tranché.
• Aucun relevé de tâches côté imprimantes : rien n'est relu depuis une imprimante. Sur une liste d'impression, c'est vous qui marquez chaque impression comme imprimée ou échouée, et les chiffres de durée et de filament sont des estimations, enregistrées par le slicer, calculées par OrcaSlicer ou saisies par vous, pas une consommation mesurée. Un filament peut être associé à un modèle, et le suivi des bobines figure sur la feuille de route plutôt que d'être livré.
• Aucun compte, permission ou journal d'audit : c'est une application de bureau mono-utilisateur. Plusieurs personnes peuvent chacune la faire tourner sur le même partage NAS, mais il n'y a pas d'état partagé entre elles, pas de rôles, et aucune trace de qui a changé quoi.

Ce sont des tâches de gestion de ferme, et un logiciel de ferme fonctionne à côté d'une bibliothèque plutôt que de la remplacer. Le tableau en haut de page montre quel système fait quoi, et la page de comparaison met Meshory face aux dossiers, aux sites de modèles et aux serveurs auto-hébergés.

Ce que couvre un logiciel de gestion de ferme

Les imprimantes, les files d'attente et les commandes relèvent de cette couche, et chacun de ces outils en couvre une partie.

Comment les deux couches s'articulent

1. 1La bibliothèque reste là où elle se trouve déjà, sur le NAS ou le disque partagé. Rien n'est migré vers un nouvel emplacement.
2. 2Un gestionnaire de bibliothèque l'indexe sur place, génère les aperçus, et élimine les doublons avant que quoi que ce soit en aval n'ait à s'en occuper.
3. 3Un opérateur trouve le modèle, convertit le projet si l'imprimante cible a besoin d'un autre slicer, et l'ouvre dans le slicer.
4. 4Le logiciel de ferme prend le relais à partir de là : trancher, mettre en file d'attente, router vers une imprimante, enregistrer le résultat en regard de la commande.

Dédoublonner en premier mérite d'être fait dans cet ordre. Chaque doublon que vous emportez dans un système de production devient un SKU en double, une tâche en double, ou un opérateur qui imprime la mauvaise révision.