Pourquoi?

Je suis pas certain que cet article aura beaucoup de sens pour mes amis non-informaticiens même si une base de connaissances peut servir pour toutes sortes de processus créatifs.

Pour les programmeurs et autres techniciens de la nuit, je suis sûr qu'on a tous connu cette situation où on réouvre du code qu'on a écrit nous-mêmes et qui est juste impossible à comprendre parce qu'on a TOUT oublié.

Il en va de même pour des solutions logicielles complètes où des procédures qui vous évoquent quelque chose du genre "il me semble que j'ai déjà dû effectuer exactement la même opération par le passé mais là je dois tout refaire en partant de zéro".

Il ressort assez vite qu'on pourrait gagner du temps et consolider la connaissance en rassemblant des notes quelque part.

Je crois que le lien entre l'écriture et la mémoire est prouvé (SOURCE???), moi c'était ma méthode principale pour étudier: re-construire/écrire tout le cours en entier.

Peut-être ça marche pas pareil chez tout le monde.

Dans tous les cas, pour les amoureux de la connaissance, si vous arrivez à vaincre votre flemme et prendre note de ce que vous faites ou avez appris à un moment donné, ça peut être une substantive valeur ajoutée.

C'est aussi là que le bas blesse parce que nous, les humains, on est EXTREMEMENT NULS pour apprécier quelque chose qui sera bénéfique plus tard ou aura des conséquences néfastes dans l'avenir.

D'où la tendance à boire trop et se retapper une gueule de bois qu'on-avait-dit-la-dernière-fois qu'on s'arrêterait plus tôt, ou encore considérer sérieusement le changement climatique ou étudier bien à l'avance pour un examen — C'est contre-nature pour tout le monde d'investir dans l'avenir.

Selon votre niveau de psychose perfectionniste, ces notes peuvent être courtes et pas nécessairement correctes à 100%. L'important est d'avoir une aide mémoire efficace.

Tout ne doit pas non plus être de la technologie. J'ai des recettes, des infos sur des jeux vidéo (j'oublie toujours les contrôles), des cheat sheets en tout genre, des listes, des blagues de beauf, mes règlages de BIOS, des instructions de montage de machins, ...

On trouve par exemple cette incroyable liste de surnoms pour quelqu'un qui s'appelle Dan:

Ben ouais ça peut toujours servir.

Etape 1: le rudimentaire

J'utilise beaucoup des cahiers et bloc notes physiques pour préparer un projet, étaler les différentes possibilités, réfléchir à quel chemin prendre.

Je le fais parfois pour des articles de ce même blog. Les autres gens de la salle s'attente du dentiste me regardent comme un alien écrire frénétiquement (et mal) de gros murs de texte dans un petit carnet.

Suis-je un écrivain? Un humoriste? Un sociopathe à besoins spéciaux? Peut-être les trois à la fois.

L'évolution naturelle du carnet pour la prise de note électronique est UN GROS TAS DE FICHIERS TEXTE.

Ce qui ressemblait à ça:

Pour le partager sur plusieurs machines, j'en arriverai à tout pousser sur un serveur SVN qui est, pour ceux qui sont nés après 1990, un système de gestion de sources comme git mais centralisé (donc pas comme git) qui est vieux et nul comme une Jupiler qu'on aurait oublié au soleil pendant 1 an.

Problèmes:

• La recherche c'est pas génial, parce qu'à l'époque j'étais nul en outil ligne de commande de type grep et la recherche Windows c'est un peu tout pourri;
• Comme on le voit sur la capture d'écran plus haut, j'avais 130 fichiers texte à l'époque, à plat dans un mono-répertoire, c'est très difficile de s'y retrouver sans utiliser de recherche (manque de catégorisation);
• Pas d'historisation (jusqu'à ce que j'ajoute SVN) bien que perso je trouve pas ça très important;
• Compliqué d'ajouter des images;
• Créer des liens internes vers d'autres documents de la KB c'est compliqué parce que le nom de fichier pourrait changer;
• J'écrivais mon texte en pur brut avec un peu d'ASCII art de temps en temps mais aucun formattage formel du genre de Markdown, par ex.

En gros, je n'étais pas le meilleur technologiste à l'époque et entasser des fichiers .txt était ma meilleure solution initiale.

Etape 2: Le wiki

Les wiki c'était trop la mode quand je suis sorti des études: des applis écrites en PHP pas très sexy qui permettent de colaborer sur des articles avec une syntaxe de formattage bien spécifique avec des fonctions d'historisation très puissantes (visualisation de la différence de révisions, facilité de revenir dans le passé, ...).

Le plus connu est le moteur de Wikipedia: MediaWiki.

Déjà à l'époque MediaWiki sentait trop le sérieux et le vieux. Je rappelle tout de même qu'il n'a pas de MODE SOMBRE facilement accessible en 2023, exactement comme chauves.be.

De plus, il faut une base de données type serveur et moi je voulais quelque chose qui soit le plus léger possible.

Dokuwiki

Autre projet PHP, Dokuwiki ressemble à MediaWiki (ben tiens) avec une mise-en-page plus simple et épurée.

Ce qui m'intéressait le plus, c'est qu'il ne faut pas de base de données du tout. Les données sont sous forme de fichiers .txt, exactement comme ma première base de connaissance foireuse avec en plus une structure de répertoire pour organiser par catégories.

L'historique de modification est conservée compressée dans un répertoire à part et il y a un genre d'index de recherche que je ne comprends absolument pas mais qui fonctionne assez bien.

Lier des articles entre-eux en interne est simple, c'est possible d'ajouter des images et il y a un langage de formattage interne qui n'a rien à voir avec le Markdown (qui n'était pas très populaire à l'époque) mais reste assez simple.

J'aurais préféré qu'il y ait une option pour tout passer en Markdown parce que beaucoup d'autres notes que je prends sont aujourd'hui en Markdown dans des pages de documentation officielles ou autres README.md de réposit...oires (??) sur Github.

Un plugin permet de copier coller du Markdown, ce n'est pas parfait mais je l'utilise régulièrement.

Au final le principal inconvénient de Dokuwiki, c'est que c'est centralisé, il faut un serveur PHP qui héberge toutes les données et media et historification etc.

S'il y a bien une trace qu'aura laissé le crypto-boom dans l'inconscient collectif, c'est que centralisé = PAS BIEN.

Alors, je pense qu'on pourrait développer cette idée mais disons que je suis plus ou moins d'accord dans les grandes lignes.

La navigation sur Dokuwiki n'est pas excellente non plus, il faut utiliser la recherche ou le sitemap (qui est asez bien foutu il faut le dire).

J'ai quelques liens rapides sur ma page d'accueil qui ressemble un peu à rien:

L'idéal

Ce qui serait trop bien ce serait d'avoir:

1. Un système décentralisé: autorise les modifications sans accès internet, copie facilement tout localement et possède un moyen de synchroniser avec un serveur quelque part (et peut-être des backups);
2. Un moyen de lire, modifier et chercher sur mobile ou sur une machine tierce;
3. Se formatte en Markdown, au minimum;
4. Autorise des liens vers les articles locaux;
5. Possède un puissant système de recherche (qui peut juste être grep ou rg sous Windows);
6. Permet de stocker et lier des fichiers... Quelque part.

Remarquez que je ne demande aucune interface graphique; En fait tout devrait pouvoir se réaliser en ligne de commande.

Le point 1 s'aligne très bien avec une bande de fichiers markdown, éventuellement organisés en répertoires, qui formeraient un répo git synchronisé sur Github, Gitlab ou un serveur privé.

Ce n'est pas requis pour moi personnellement mais on peut même imaginer pouvoir collaborer à plusieurs sur une base de connaissance vivant sur Github ou Gitlab (et les autres). Git offre aussi gratuitement l'historisation, même si ce n'est de nouveau pas requis pour moi personnellement.

Le point 2 est plus compliqué. Il faudrait pouvoir lier une interface graphique — laquelle fournirait également une puissante fonction de recherche — aux données des fichiers markdown.

Github fait exactement ça. Son éditeur en ligne est de surcroit très impressionnant, et sa recherche est très efficace.

Le point 4 est le plus embêtant quand on travaille avec un groupe de fichiers texte, comment qu'on peut les référencer?

Par leur nom? Quid de si le nom est un peu ambigu ou si je veux le changer? Je dois search & replace tous les fichiers et tout changer.

J'ai déjà vu quelqu'un utiliser des IDENTIFIANTS uniques, créés à partir de la date et l'heure de création.

C'est pas la mer à boire comme ma mère disait, mais c'est pas génial non plus. Enfin, moi ça me gène.

Une idée courante est de copier des systèmes d'organisation plus... Rustiques. Comme ces tiroirs organisateurs remplis de fiches.

Je me souviens qu'il y en avait un à ma bibliothèque locale et ça me fascinait... Toutes ces fiches de différentes couleurs tapées à la machine et classées par ordre alphabétique.

Il est possible de donner à chaque article une ou deux lettres puis un chiffre comme si on le classait dans une armoire, un tiroir et une autre subdivision interne éventuelle.

C'est cool sauf qu'on perd une grande partie voire toute l'info sur le sujet de l'article dans le nom du fichier. Il est absolument nécessaire de systématiquement lancer une recherche pour trouver quoi que ce soit.

Avec les tiroirs et les fiches c'est un peu pareil, il faut ouvrir le bon tiroir et parcourir les fiches au bon endroit jusqu'à tomber sur ce qu'on cherche.

On voit parfois passer l'idée de la technique Zettlekasten (littéralement ARMOIRE à NOTES je crois c'est boite à notes mais c'est plus rigolo armoire, j'aime bien le mot armoire) avec tout un tas de recommandation sur la longueur des notes et comment les catégoriser et les lier.

Je trouve ça trop compliqué mais si vous voulez vous inspirer d'une technique de classement d'armoire inventée par un vieil allemand je vais pas vous arrêter.

Au nivau technique, j'ai aussi pensé à une DB fichier comme SQLite (OU ACCESS LOL) que je pourrais copier sur un serveur (ou Drive ou truc du genre) avec une commande. Le problème étant qu'il faut trouver tout un plan pour l'édition sur téléphone ou sur une machine inconnue qui n'aurait qu'un navigateur d'installé.

Il faudrait que je développe une interface graphique plus ou moins rudimentaire à coller sur tout ça.

Les notes éphémères

J'aime bien aussi avoir un bloc note spécial pour les petits prises de notes rapides, petits détails à ne pas oublier, tâches du jour à effectuer, ce genre de choses.

J'ai tendance à en bourrer une bonne partie sur la page de démarrage de mon Dokuwiki et j'en arrive rapidement à une TRèS LONGUE PAGE qui a plutôt tendance à uniquement s'allonger.

Je me suis rendu compte un jour que ça joue un rôle similaire aux 15000 onglets que certains gardent ouverts dans leur navigateur en se disant "waw c'est chouette ça je vais le garder ouvert et regarder plus tard" mais évidemment jamais vous allez le regarder plus tard en fait et c'est totalement inutile mais c'est trop difficile de se séparer de trucs et machins parce que ça nous rappelle la nature éphémère et fragile de notre existence.

Ou un truc du genre.

Du coup j'ai aussi un fichier sur mon bureau qui s'appelle deleteme.md. Ouais. Et je l'efface jamais donc c'est un petit peu un mensonge sauf que la règle c'est que je dois pouvoir accepter que le contenu de ce fichier soit perdu ou limité au seul ordinateur où il se trouve. Je peux pas le copier quelque part. Enfin, je peux, mais je m'impose cette règle. C'est pas du tout bizarre.

J'ai même un script pour ouvrir ce fichier juste en tapant "n" dans la console:

Conclusion?

Je n'ai aucune idée de par quoi remplacer mon vénérable Dokuwiki, que je backup avec rsync et peut lancer en local via Docker en cas de catastrophe avec le serveur central.

Vous en pensez quoi, vous? C'est quoi votre technique de prise de notes?