Des liens entre notes qui survivent au renommage

Productivity

Quiconque tient depuis plus d’un an des notes reliées entre elles a déjà croisé ce bug.

Vous avez écrit une note intitulée Q3 planning. En huit mois, trente autres notes y ont fait référence. Puis le troisième trimestre s’est terminé, et vous l’avez renommée Q3 planning (2025), ce qui était évidemment la chose à faire.

Trente liens ont cassé. Sans bruit. Ils s’affichent toujours, ressemblent toujours à des liens, et pointent désormais vers une note qui n’existe pas. Certains outils proposent obligeamment de la créer pour vous, et vous voilà avec une seconde note Q3 planning, vide, qui hante votre graphe.

La cause : la plupart des applications de notes de type wiki stockent le lien sous forme de titre. [[Q3 planning]] est littéralement la chaîne « Q3 planning », résolue à l’affichage en cherchant une note qui porte ce nom. Le lien est une supposition qui se trouve être juste la plupart du temps.

Notez stocke l’identifiant.

Ce que [[ insère vraiment

Tapez [[ dans l’éditeur, et un sélecteur s’ouvre sur les notes de votre espace de travail. Choisissez-en une, ou créez une nouvelle note directement depuis le sélecteur, et le document reçoit un nœud qui contient deux choses :

  • noteId — l’identifiant réel de la note cible

  • fallbackTitle — le titre au moment de l’insertion

L’identifiant est le lien. Le titre de secours n’est qu’une légende de dernier recours.

À l’affichage, la pastille du lien cherche la note cible par son identifiant et montre son titre actuel. Renommez la cible, et toutes les pastilles qui pointent vers elle se mettent à jour, partout, immédiatement. Rien à réparer, pas de rechercher-remplacer en masse dans vos archives, pas de rapport de « liens non résolus » à éplucher un dimanche.

Les liens sont aussi sans ambiguïté, ce que des liens par titre ne peuvent jamais être. Deux notes peuvent avoir le même titre. Deux notes ne peuvent pas avoir le même identifiant.

Les rétroliens sont une requête, pas une fonction à entretenir

Les liens étant stockés comme de vraies références, le sens inverse ne coûte rien.

À chaque enregistrement d’une note, Notez parcourt le document enregistré, rassemble les identifiants de notes qu’il référence et compare cet ensemble à celui qu’il avait relevé la fois précédente : il insère les nouveaux liens et supprime ceux qui ont disparu. La table des liens est une fonction pure de votre contenu. Elle ne peut pas se désynchroniser de ce que vous avez réellement écrit, puisqu’elle est reconstruite à partir de ce que vous avez réellement écrit à chaque enregistrement.

Pendant ce passage, quelques éléments sont écartés, chacun pour une raison concrète :

  • Liens vers soi-même. Une note qui se référence elle-même n’est pas une relation.

  • Cibles dans un autre espace de travail. Seules les notes du même espace de travail sont conservées. C’est pourquoi un lien depuis votre espace de travail professionnel ne peut jamais révéler l’existence d’une note personnelle, non pas en vertu d’une règle, mais par construction.

  • Identifiants mal formés. Les notes issues d’un import peuvent contenir des références provisoires non résolues tant que l’import n’a pas fini de les relier. Ces références sont ignorées au lieu de faire échouer l’enregistrement.

Les rétroliens sont alors simplement la même table lue dans l’autre sens : toutes les notes dont le contenu référence celle-ci. Il n’y a pas d’index de rétroliens séparé à reconstruire, ni de mode maintenance. La section Notes liées d’une note montre les deux sens.

Deux sortes de liens, et c’est voulu

Les liens [[ dans le texte ne sont pas le seul moyen pour les notes de pointer les unes vers les autres. L’autre, c’est la propriété personnalisée Relation : un champ typé dont la valeur est une autre note. Par exemple, une propriété Client sur chaque note de réunion, qui pointe vers la note de ce client.

Les deux se ressemblent, mais sont stockés de façon totalement différente. Les liens dans le texte sont écrits dans la table des liens à l’enregistrement. Les liens de relation sont calculés à la lecture et n’y sont jamais écrits.

La raison est un bug que je préfère ne pas livrer deux fois. La réconciliation à l’enregistrement compare l’ensemble complet des liens d’une note et supprime tout ce qui n’est pas présent dans le contenu. Si les liens des propriétés Relation étaient versés dans la même table, le prochain enregistrement du contenu de cette note examinerait le document, ne les y trouverait pas et les supprimerait. Vos relations Client s’évaporeraient une note à la fois, précisément au moment où la note serait modifiée, c’est-à-dire sans que rien ne se voie, et seulement sur vos notes les plus actives.

Les deux sortes sont donc stockées séparément et réunies à la lecture. Un peu plus de travail à chaque lecture ; aucune possibilité que l’une avale l’autre en silence.

La différence pratique pour vous :

  • Les liens dans le texte relèvent de la prose. Ils ont leur place au milieu d’une phrase, là où le rapprochement est une pensée que vous avez : « cela découle du [[post-mortem sur les nouvelles tentatives]] ».

  • Les propriétés Relation relèvent de la structure. Elles ont leur place quand chaque note d’un même type porte ce même pointeur et que vous voulez filtrer et trier selon lui.

Utilisez les deux. Ils répondent à des questions différentes.

Le graphe

Dès lors que les liens sont de vraies références, une vue en graphe n’est qu’un rendu de données que vous avez déjà, et non une chose de plus à construire. La section Notes liées de n’importe quelle note s’affiche en liste ou en graphe de ce vers quoi elle pointe et de ce qui pointe vers elle.

Une réserve à formuler : une vue en graphe est réellement utile pour l’exploration locale, pour voir le voisinage d’une note ou remarquer un groupe que vous n’aviez pas prévu. Elle l’est beaucoup moins pour visualiser toutes vos archives. Dix mille notes rendues en pelote emmêlée, c’est un économiseur d’écran. J’ai construit la vue locale.

Ce que deviennent les liens dans un partage public

Partagez une note publiquement, et ses liens dans le texte se comportent avec prudence. La vue publique n’a pas accès à votre espace de travail : la pastille affiche donc le fallbackTitle enregistré au moment de l’insertion (la légende de dernier recours sert enfin à quelque chose), et ne devient un lien actif que si la note cible est elle aussi partagée publiquement.

Si elle ne l’est pas, la pastille s’affiche comme un texte grisé et inactif. Elle signale au lecteur qu’une note est référencée à cet endroit, sans révéler son titre actuel ni lui y donner accès.

C’est le bon comportement par défaut, et mieux vaut le connaître avant de partager une note : une note partagée n’entraîne pas ses notes liées avec elle dans la vue publique. Si vous voulez qu’un ensemble de notes liées soit lisible, partagez chacune d’elles.

Comment s’en servir au quotidien

Les liens font partie de ces fonctions qu’on planifie trop, puis qu’on n’utilise jamais. Ce qui marche vraiment :

  1. Créez les liens en écrivant, pas après. Le moment où vous tapez une phrase qui renvoie à quelque chose de déjà écrit est le moment où vous savez que le lien existe. Plus tard, vous ne vous en souviendrez pas.

  2. Ne liez pas tout. Une note liée depuis quarante endroits ne vous apprend rien. Les liens ne sont un signal que s’ils sont sélectifs.

  3. Consultez les rétroliens avant d’écrire une nouvelle note. Ouvrez la note sur le sujet, regardez ce qui pointe déjà vers elle, et vous découvrirez souvent que vous avez écrit l’essentiel de la nouvelle note il y a huit mois.

  4. Transformez un lien répété en propriété Relation. Si vous avez lié à la main la note d’un client depuis chaque note de réunion, ce n’est plus de la prose, c’est un champ. Faites-en un, et le filtrage et le tri viennent avec.

  5. Renommez librement. C’est tout l’intérêt. Les titres sont des descriptions, pas des identifiants, et vous devez pouvoir les améliorer dès qu’un meilleur vous vient.

Ce dernier point est l’avantage discret des liens par identifiant, et il faut un moment pour le remarquer. Dans un système qui lie par titre, on cesse peu à peu de renommer, parce que renommer a un coût et qu’on s’y est déjà brûlé. On finit avec des archives pleines de titres choisis faute de mieux.

Avec des liens qui survivent au renommage, les titres continuent de s’améliorer.

À lire aussi