Propriétés ou mots-clés ? Que choisir? Tuto Obsidian

Dans Obsidian, le choix entre **propriétés** et **mots-clés (tags)** n’est pas une question de goût : c’est une décision de structure. Les propriétés servent à organiser des informations “de fiche” dans un format propre et exploitable, tandis que les tags servent à marquer des éléments repérables n’importe où dans une note. La différence devient vite concrète dès qu’on cherche à garder une base lisible, éviter les erreurs et faciliter les vues et recherches.

Le tutoriel commence par montrer comment les **propriétés** s’affichent sous forme de mini-tableau dans la note. En mode Source, elles reposent sur une zone de **front matter** au début du fichier, délimitée par trois tirets, avec une syntaxe inspirée de **YAML**. Cette structure permet de définir des champs typés (par exemple un texte, un nombre, ou une liste) et d’obtenir une saisie plus guidée : Obsidian peut corriger le type attendu (passer d’un champ “texte” à une “liste”, par exemple). Les propriétés peuvent aussi être masquées pour conserver un rendu plus “clean”, tout en gardant la donnée exploitable.

À l’inverse, les **mots-clés** sont présentés comme une logique plus souple mais plus limitée. Un tag ne tolère pas n’importe quel format : un espace peut être interprété comme la création de plusieurs tags, ce qui oblige à utiliser des séparateurs (comme un tiret) pour représenter un libellé composé. Le tutoriel illustre aussi un risque majeur : si chaque caractéristique devient un tag distinct, la liste de tags peut exploser et devenir ingérable.

Pour résoudre ce dilemme, l’auteur propose une ligne de conduite basée sur la **portée** de l’information. Si une information concerne la note dans son ensemble — par exemple le **type** d’une note (“film”) ou le **genre** — les propriétés sont plus adaptées : elles donnent un cadre stable, réduisent les erreurs et permettent de regrouper proprement les valeurs. Si, au contraire, un mot-clé sert à souligner un élément présent dans le texte (par exemple relier une appréciation à un acteur mentionné), les tags sont plus pertinents car ils peuvent être placés “au bon endroit” dans la note.

Le tutoriel compare aussi deux façons de gérer le genre : soit via des tags hiérarchiques (avec une structure de type “genre → sous-genres”), soit via des propriétés qui peuvent elles-mêmes contenir des tags. Dans les deux cas, les tags se retrouvent dans le champ spécial **tags**, mais les propriétés offrent un avantage de présentation : elles peuvent alimenter des vues type tableau et rendre les données plus “base de données”, notamment pour des recherches ultérieures.

Enfin, un point clé relie ce choix à **DataView** : les propriétés, structurées comme des champs, facilitent la construction de tableaux et de requêtes plus agréables. Les tags, eux, restent plus libres et plus faciles à placer, mais moins adaptés à une présentation “tableau” quand le volume augmente. Le message final ne tranche pas de manière dogmatique : il encourage à choisir selon l’usage — fiche globale (propriétés) versus repérage dans le texte (tags) — et à réfléchir à la façon dont on veut interroger ses notes ensuite.