Tout le monde peut dire que son logiciel est solide. Voici les preuves.
Meshory est développé par une seule personne, il est payant et son code source est fermé. C'est beaucoup vous demander de me croire sur parole, alors je préfère ne pas le faire. Cette page apporte les preuves : ce qui tourne avant chaque sortie, ce que j'ai mesuré, ce que j'ai refusé d'affirmer, et ce qui manque encore.
Écrit par Petros, qui développe Meshory. En savoir plus sur la personne derrière le projet.
Rien ne sort sans être passé par tout cela
Chaque version, même les plus petites, passe par les mêmes contrôles. Aucune exception manuelle, car un contrôle qu'on peut contourner n'est pas un contrôle.
Les types doivent être valides
TypeScript compile toute l'application de bureau sans erreur avant que quoi que ce soit d'autre ne s'exécute. Une version qui ne passe pas la vérification des types n'atteint jamais l'étape des tests.
6 987 tests unitaires
578 fichiers de test qui couvrent le moteur de scan, la couche base de données, l'indexation des archives, la détection des doublons, les licences et l'interface. 52 autres sont ignorés plutôt que supprimés, et le total ci-dessus ne les compte pas.
298 tests de bout en bout
Playwright lance la véritable application empaquetée sur une vraie bibliothèque sur disque et la pilote comme le ferait une personne : scanner un dossier, y faire une recherche, ouvrir la visionneuse 3D, ajouter des tags, trouver des doublons, mettre des fichiers à la corbeille. 63 fichiers de spécifications.
Signée et notariée sur macOS
Chaque version macOS est signée numériquement et envoyée à Apple pour notarisation avant de s'approcher d'un lien de téléchargement. Si la notarisation échoue, la publication s'arrête.
Le programme d'installation passe lui aussi un test de démarrage
La CI installe l'application compilée sur une machine vierge et la démarre. Une version qui compile mais ne se lance pas est repérée à ce stade, et non par vous.
Publication en deux étapes
Les versions arrivent d'abord dans un stockage privé. Rien n'atteint la page de téléchargement ni la mise à jour automatique des utilisateurs existants tant qu'une étape de promotion distincte n'a pas été exécutée.
Je fais mes benchmarks sur ma propre bibliothèque, pas sur un dossier de démonstration
Les benchmarks d'août sur la bibliothèque complète, ci-dessous, comparent la même bibliothèque NAS sur la même machine, avant et après : 141 696 fichiers indexés répartis dans 8 448 dossiers, soit 3,3 To au moment où ces passes ont été enregistrées, le 2 août 2026. Les résultats bruts sont versionnés avec un horodatage, la version de l'app et le matériel utilisé, pour qu'un changement ultérieur qui ralentit discrètement quelque chose se remarque.
Ce nombre compte des fichiers, pas des modèles : c'est pourquoi il dépasse les 118 270 modèles cités ailleurs sur ce site. 6 997 de ces fichiers sont des archives ZIP, et les 100 874 entrées qu'elles contiennent sont indexées comme des éléments à part entière au lieu d'être laissées comme des blocs opaques. Le reste de l'écart vient des images, PDF et readme qui accompagnent les modèles. Les benchmarks comptent tout ce que le scanner doit réellement traiter.
Ces deux derniers chiffres proviennent d'une passe ultérieure sur la même bibliothèque, le 8 août 2026, car les passes du tableau sont antérieures au compteur qui les enregistre. Même corpus : les deux indiquent les mêmes 141 696 fichiers dans les mêmes 8 448 dossiers. Cette passe est aussi publiée.
vitesse
La ligne du premier scan arrête le chronomètre quand la bibliothèque est prête pour la navigation et la recherche. La génération des miniatures et des images de couverture et le calcul des hash de doublons se poursuivent ensuite en arrière-plan, et sur cette bibliothèque ils continuent longtemps après la fin du scan. Mesuré sur un Apple M4 Pro, 12 cœurs, 48 Go, avec le même partage NAS en lecture seule pour les deux passes. Vos chiffres varieront selon votre matériel et votre réseau. Ceux-ci sont ceux que je peux vous montrer. La colonne des gains est calculée à partir des mesures brutes et non des chiffres arrondis affichés à côté : elle peut donc s'écarter d'une fraction de pour cent du résultat obtenu en divisant ce qui est à l'écran. Le JSON brut de chaque ligne est publié ici, horodatages, versions de l'app et machine compris.
Moins d'attente pour les miniatures
Les dernières améliorations des miniatures réduisent le temps de traitement de 35,8 % sur un échantillon de 768 fichiers issus de ma bibliothèque NAS en filaire. Chaque image produite était identique octet pour octet avant et après.
La base de données de test conservait les 152 955 enregistrements de fichiers, tandis que la file des miniatures couvrait 500 fichiers dans des archives et 268 fichiers isolés. Les deux versions incluaient déjà les optimisations antérieures des miniatures.
vitesse
Médiane de deux exécutions par version, dans l'ordre avant/après/après/avant, avec les caches du NAS et du système d'exploitation déjà chauds, sur un Apple M4 Pro, 12 cœurs, 48 Go. Le temps mesuré comprend le démarrage des workers, les lectures, le rendu, l'écriture des images et les mises à jour de la base de données. Le scan, le tagging, les modèles STEP et l'interface ont été exclus. La bibliothèque complète n'a pas été chronométrée avec ces changements. Lire le relevé de mesures.
Ce que je ne me suis pas permis d'affirmer
Tout l'intérêt de mesurer, c'est que parfois la mesure dit non. Voici, mot pour mot, la conclusion de l'un de mes propres rapports de benchmark, à propos d'une accélération que je voulais pouvoir mettre en avant :
“Directory read aggregate increased substantially even while archive wall time fell, so these runs do not support a directory read speedup claim.”
Lors de cette même série, le premier scan est devenu environ 11 % plus rapide et le traitement des archives environ 18 % plus rapide, deux gains réels. Mais la latence des aperçus s'est dégradée sur l'échantillon, et l'un des objectifs que je m'étais fixés n'a pas été démontré par les données : il n'est donc pas démontré sur cette page non plus. Des chiffres qui ne bougent jamais que dans le sens flatteur ne sont pas des mesures, c'est du marketing.
Ce qui n'est pas encore fait
La liste que je voudrais lire si je devais décider de faire confiance ou non au logiciel de quelqu'un d'autre.
Les versions Windows ne sont pas encore signées numériquement.
Windows affiche un avertissement SmartScreen à la première installation, et certains antivirus mettent carrément le programme d'installation en quarantaine, par faux positif. Seule la signature numérique supprime l'un comme l'autre. En attendant, le SHA-256 de chaque version et un rapport VirusTotal figurent sur la page de téléchargement pour que vous puissiez vérifier le fichier vous-même. Sur macOS, l'application est déjà signée et notariée.
Le code source est fermé.
Vous ne pouvez pas lire le code : le reste de cette page explique comment j'essaie d'en faire un marché raisonnable plutôt qu'un acte de foi.
Un seul fichier très volumineux peut encore le mettre en échec.
Un seul STL de plus d'un gigaoctet environ peut épuiser la mémoire pendant le calcul des hash de doublons. C'est une limite connue, avec un seuil mesuré, pas une surprise.
Il n'y a qu'une seule personne.
Si je dors, votre message Discord attend le matin. Personne n'assure de permanence sur 24 heures, et je ne prétendrai pas le contraire.
Vous ne pouvez pas lire le code, alors voici ce que je vous dois à la place
Il fonctionne entièrement sur votre ordinateur.
Meshory n'envoie jamais vos modèles en ligne. Pas de compte, pas de synchronisation, pas de serveur entre vous et vos propres fichiers. Débranchez le câble réseau : il fonctionne exactement de la même façon.
Ce que vous avez payé vous appartient.
Un achat unique, pas un abonnement. La version que vous avez achetée continue de fonctionner, y compris hors ligne.
Le journal des modifications est précis.
Chaque version dit ce qui a réellement changé et pourquoi, y compris les corrections embarrassantes. 23 d'entre elles depuis le 8 juillet 2026
Celui qui reçoit le rapport de bug est celui qui le corrige
Les rapports de bug et les demandes de fonctionnalités arrivent sur un Discord où ils me parviennent directement, et une bonne partie finit par être livrée. Le filtrage par tag existe parce que quelqu'un l'a demandé sur Discord. La détection du slicer Snapmaker existe parce qu'un utilisateur m'a envoyé des fichiers d'exemple. La moitié des notes de version sont l'idée de quelqu'un d'autre.
Voyez-le à l'œuvre sur votre bibliothèque
Téléchargez-le, lancez-le sur votre pire dossier, et jugez-le sur ce qu'il fait de votre propre désordre.