Pour vendre des modèles de vault Obsidian, préparez un dossier propre contenant vos notes originales, des liens fonctionnels, les pièces jointes nécessaires et des instructions claires. Excluez les notes privées et les réglages inutiles. L'archive ZIP doit permettre de démarrer sans demander à l'acheteur de faire confiance à un ensemble inexpliqué de plugins communautaires.
Ce guide s'adresse aux créateurs de systèmes de recherche, d'écriture ou de planification. La fiche de validation ci-dessous relie un vault distribuable à la livraison de fichiers PayRequest. C'est un protocole à appliquer à votre produit, pas l'affirmation que nous avons ouvert ou testé votre vault.
Définir le modèle de vault Obsidian vendu
Choisissez un résultat reconnaissable, comme organiser des entretiens de recherche ou préparer une série de romans. Montrez un projet fictif qui explique les relations entre les notes. Une arborescence seule justifie rarement l'achat d'un système.
Distinguez une note réutilisable d'un vault complet. La documentation Obsidian sur les vaults décrit un vault comme un dossier local regroupant notes, pièces jointes et configuration. Un modèle complet peut proposer plusieurs types de notes et une page de démarrage.
Précisez le contenu de l'achat : fichiers, instructions, licence, assistance et mises à jour éventuellement définies. L'acheteur obtient Obsidian séparément. Ne laissez pas entendre qu'Obsidian Sync, un abonnement tiers ou une approbation officielle est inclus.
Un modèle Notion passe généralement par une duplication hébergée. L'acheteur Obsidian reçoit des fichiers locaux. Expliquez donc avant le paiement où les extraire et quel dossier ouvrir.
Créer une copie de distribution, pas une archive du vault de travail
Commencez dans un dossier séparé. Copiez uniquement les notes et ressources utiles à la démonstration. Remplacez noms de clients, détails de réunions, recherches inédites et annotations personnelles par des exemples fictifs. Inspectez contenu et noms de fichiers : un modèle anodin peut encore contenir une adresse réelle ou un lien privé.
Vérifiez les pièces jointes séparément. Une note peut dépendre d'une image ou d'un PDF situé ailleurs sur votre ordinateur. N'incluez que des fichiers que vous pouvez redistribuer et supprimez les dépendances aux liens cloud privés. Une référence essentielle ne doit pas nécessiter votre compte personnel.
Décidez explicitement du sort de la configuration. Obsidian conserve les réglages du vault dans le dossier caché .obsidian. Sa documentation sur le stockage distingue notes et paramètres. L'affichage habituel du gestionnaire de fichiers ne montre pas forcément tout le contenu de l'archive.
Pour un système simple, nous conseillons de livrer vos contenus et d'expliquer les quelques réglages nécessaires. Si une configuration préparée est indispensable, créez-la volontairement dans la copie de distribution et vérifiez-la. N'expédiez pas vos réglages de travail pour économiser un paragraphe d'instructions.
Annoncer les plugins nécessaires avant l'achat
Un vault dépendant de plugins communautaires exige une assistance différente d'un système utilisant les fonctions intégrées. Indiquez chaque plugin requis, son rôle, la version vérifiée et ce qui ne fonctionne pas sans lui. Séparez les améliorations visuelles facultatives des dépendances essentielles.
Les consignes de sécurité des plugins Obsidian expliquent que le mode restreint empêche par défaut l'exécution des plugins communautaires. Le désactiver implique une décision de confiance. Ne commencez pas les instructions d'un produit payant par « tout activer » sans expliquer le code exécuté et son utilité.
Pour une distribution simple, renvoyez à l'installation officielle du plugin plutôt que de fournir du code tiers ou les paramètres d'autrui. Vérifiez séparément les licences des ressources externes. Votre licence de notes ne donne aucun droit sur un plugin, un thème ou une image appartenant à un autre auteur.
Conservez un parcours sans plugin quand il remplit encore la promesse commerciale. Des notes de projet liées peuvent rester utiles sans tableau de bord dynamique. Si celui-ci constitue la promesse centrale, expliquez la dépendance et ne présentez pas le mode de secours comme équivalent.
Utiliser cette fiche de validation du vault Obsidian
Créez une fiche par version vendue. Ce modèle original d'acceptation contient des valeurs illustratives pour un vault de recherche fictif. Remplacez-les par vos observations : cocher une case sans effectuer la vérification ne constitue pas une preuve.
| Contrôle | Exemple | Condition d'acceptation |
|---|---|---|
| Identité du produit | Research-vault-1.0.zip | Offre et archive désignent la même version |
| Point de départ | Start Here.md | L'acheteur trouve immédiatement la première tâche |
| Contenu de démonstration | Projet d'entretien fictif | Aucun entretien privé, donnée client ou identifiant |
| Liens et pièces jointes | Cinq notes et deux images originales | Chaque référence locale promise s'ouvre depuis la copie extraite |
| Dépendances | Fonctions intégrées uniquement | Aucun plugin non déclaré nécessaire au parcours annoncé |
| Configuration | Paramètres préparés volontairement, ou aucun | Fichiers cachés inspectés et choix documenté |
| Compatibilité | Version de l'application et système réellement vérifiés | Plateformes non vérifiées clairement indiquées |
| Licence et assistance | Texte inclus avec moyen de contact | Droits compréhensibles et version identifiable |
Extrayez le ZIP final à un autre emplacement et utilisez « Open folder as vault » dans Obsidian. Sélectionnez le dossier contenant les notes, pas l'archive fermée ni un dossier d'emballage extérieur. Réalisez la première tâche, suivez les liens et créez une note avec chaque modèle annoncé.
Notez le résultat et les corrections nécessaires. Recommencez après avoir modifié une dépendance ou déplacé des pièces jointes. Cette discipline ressemble à celle des modèles Scrivener, mais les contrôles Obsidian ciblent les liens locaux, la configuration cachée et la confiance dans les plugins.
Livrer avec PayRequest et identifier l'étape à assister
Utilisez les produits numériques PayRequest pour vendre l'archive. Dans le service de fichiers examiné le 12 septembre 2026, ZIP est autorisé ; Markdown seul ne figure pas dans la liste des extensions directement acceptées. L'archive préserve l'arborescence et fournit un fichier produit unique.
La livraison de fichiers PayRequest distingue l'ouverture de la page de téléchargement de l'action qui télécharge réellement le fichier. Le contrôleur actuel vérifie expiration et limites ; consulter la page ne consomme pas de téléchargement. Cela protège cette étape contre les aperçus ordinaires de liens, mais ne valide pas le vault et n'empêche pas la copie après réception.
Classez les demandes d'aide en trois étapes : accès au téléchargement, extraction du ZIP, puis ouverture ou utilisation du vault. Demandez la version distribuée, la version de l'application et l'étape échouée. N'exigez pas le vault personnel complet si un exemple minimal ou une description suffit.
Définissez précisément les mises à jour. Livrer une nouvelle archive ne fusionne pas automatiquement les modifications avec les notes personnalisées de l'acheteur. Conseillez une sauvegarde et identifiez les fichiers changés. Ne promettez pas un système de migration inexistant.
Préparez votre version vérifiée, puis créez l'offre avec les produits numériques PayRequest. Consultez les tarifs pour calculer votre marge : l'offre Free n'a pas de coût mensuel et applique 2 % par paiement réussi, avec un plafond de 25 € par transaction. Les frais du prestataire de paiement sont distincts.
Note éditoriale : l'IA a assisté la rédaction et la création de l'illustration. Les comportements d'import et de téléchargement de PayRequest ont été examinés dans le code. La fiche est un outil original de préparation ; aucun test de compatibilité Obsidian ni résultat client n'est revendiqué.