L’informatique permet à tous d’accéder à de nouvelles pratiques documentaires. Les communautés du logiciel libre et de l’open source se ressemblent pour concevoir et développer de nouveaux outils qu’ils partagent au monde dans une logique d’ouverture qui commande et façonne ces logiciels. Ils ont libéré une pratique du texte numérique : le plein texte et ses nombreuses qualités, mais aussi la recherche de nouveaux outils heuristiques pour une lecture adaptée aux outils modernes et favorisant la sérendipité.

Nous allons utiliser le matériel et le vocabulaire des développeurs, des architectes du numérique, dont le travail de fond abstrait requière une « hygiène informationnelle » et un sens de la structure exemplaires. Ainsi, nous allons nous évoquer des prémisses théoriques pour la conception d’une base documentaire personnelle et évoquer de nombreux outils pour la soutenir.

Les pratiques documentaires dont il est question sont bientôt centenaires. Il faut remonter à l’entre-deux-guerres, bien avant les débuts de l’informatique, pour comprendre la démarche de logiciels développés à partie des années 1980. C’est aussi l’histoire de l’hypertexte sur lequel nous allons revenir dans un premier temps.

Nous allons évoquer ces concepts techno-documentaires et nous intéresser à une série de logiciels et d’applications permettant à chacun de créer son système, souple et robuste. À travers le prisme de ces logiciels, nous allons tenter d’adopter une vue globale sur les pratiques auto-documentaires logicielles actuelles. Nous commencerons par les pratiques d’écriture dans la deuxième partie de cet article et nous poursuivrons par les pratiques de lecture dans la troisième avant de conclure.

Hypertexte

Le mot « hypertexte » est apparu dans les années 1960, prononcé par Ted Nelson. Il s’inspire lui-même des travaux de Vannevar Bush. Il évoque « une écriture-lecture non-linéaire donnant à l’utilisateur une liberté de mouvement » au sein d’une base documentaire. Le terme de base est important puisqu’il suggère un espace fini de documents rangés (classement, indexation etc.), dédiés à la consultation (dispositifs de lecture). L’hypertexte comme concept, mais aussi comme outil, va nous permettre de nous déplacer au sein de cette base, entre les documents.

Histoire pré-informatique

L’histoire de l’hypertexte débute bien avant le Web, l’informatique, dans les années 19301. Des chercheurs travaillent à classer le monde dans une période d’entre-deux-guerres. Il s’agit notamment de deux personnes, Paul Otlet et Vannevar Bush. On leur associe à chacun une œuvre écrite majeure ; respectivement le Traité de documentation (1934) et l’essaie As We May Think (1945) ; ainsi qu’un projet concret issu de leurs recherches ; respectivement le Mundaneum et le Memex.

Systèmes documentaires

Classer avec Paul Otlet

Paul Otlet, bibliographe et pacifiste belge imagine classer le monde, ou plus précisément toutes les œuvres existantes. C’est cette démarche pluridisciplinaire qui donnera le Mundaneum, ainsi que le besoin fondamental de faire des techniques bibliotéconomiques (classement, archivistique etc.) une discipline scientifique et ainsi universelle. C’est ce qui mènera Paul Otlet à concevoir la Classification Décimale Universelle (CDU) et à imaginer un processus de documentation décrit dans le Traité de documentation.

Paul Otlet distingue y 7 étapes pour classifier la connaissance humaine partant des « choses » pour enfin obtenir des encyclopédies. C’est ce format documentaire qu’il estime optimal pour enregistrer et exploiter de la connaissance. Otlet prescrit pour les constituer des étapes préalables d’étude. D’abord l’étude scientifique, puis l’étude bibliologique, pour respectivement traiter le contenu puis sa place dans l’encyclopédie. L’encyclopédie est enfin une base documentaire réticulaire : une somme de documents inter-reliés tel qu’on conçoit aujourd’hui Wikipédia et ses nombreux liens internes.

Paul Otlet imagine également les dispositifs permettant de recueillir les informations pour constituer une encyclopédie mondiale, ainsi que les dispositifs pour le lire. Il s’agit du cosmographe et du cosmoscope, dont la combinaison permetterait à chacun d’écrire et lire dans cette « hyperdocumentation ». Le Web est la version imparfaite de cette idée évoquée par Paul Otlet, cinquante ans avant sa conception. Tim Berners-Lee avait lui-même fait le vœu d’un Web où chaque navigateur pourrait lire et écrire sur les pages web (idée actuellement incarnée par le navigateur Beaker Browser). On retrouve cette ambition dans son projet ENQUIRE, ancêtre de DokuWiki et WikiMedia, ce dernier étant le moteur de Wikipédia.

Ainsi Paul Otlet établit une méthode rigoureuse dont nous pouvons également tirer des enseignements pour un système documentaire personnel : une épreuve de l’information, des dispositifs de transcription et de lecture. Nous y reviendrons.

Chercher avec Vannevar Bush

Si Paul Otlet, pacifiste, théorise une organisation et des dispositifs mondiaux, Vannevar Bush, impliqué dans les technologies de guerre, travaille l’interface individuelle. Il veut augmenter la mémoire humaine, en taille et en pérennité. Il théorise puis conçois le Memex (MEMory EXtender). C’est un bureau pourvu d’écrans, d’une platine avec un appareil photo, de manivelles et de boutons, matériel avec lequel il est possible de visualiser une suite de documents photographiés (ancêtre de la numérisation) indépendamment de l’ordre de leur enregistrement.

Vannevar Bush suit parallèlement cette idée de documentation asynchrone de l’encyclopédie : des liens internes guident la lecture plutôt que l’ordre des pages. Le lecture débute non pas par le premier document, mais par depuis sommaire, un index des pages comme au début d’un ouvrage, comme sur une page de résultats de moteur de recherche ou encore comme sur une notice où l’on a noté la combinaison de touches (identifiant) pour accéder à un tel document du Memex. Ces différentes logiques s’appliquent à différents dispositifs pour différentes bases et on la même origine. L’auteur d’une encyclopédie, un internaute ou un utilisateur du Memex tisse le maillage interne d’une base documentaire.

Vannevar Bush décrit dans As We May Think plusieurs processus de recherche très concrets pour des chercheurs, des avocats ou toute personne dont la profession implique une recherche documentaire. Il décrit des personnes qui vont s’interroger sur une problématique, consulter les bobines magnétiques de leur Memex à ce sujet, y enregistrer d’autres ressources, les relier, les annoter et enfin partager ce travail ; il suffira de dupliquer le contenu de la bobine.

Le Memex apporte à son tour de nombreuses notions utiles à nos bases documentaires individuelles : chaque document est numérisé, possède un identifiant (appelé avec les boutons), est enregistré dans un espace réticulaire dont l’interface est partagée en différentes vues. Nous y reviendrons également.

Interdiscipline

L’interdisciplinarité est au cœur de ces deux projets. As We May Think est un plaidoyer pour une meilleure cohésion entre les scientifiques de différentes disciplines et le Mundaneum est la première étape d’un projet de palais mondial qui pourrait réunir les sciences et les arts de par le monde. Ces deux hommes ont une idée transhumaniste selon laquelle nous devrions pouvoir étendre notre champ de connaissances dans des appareils qui pourraient être intégrés à notre corps.

Ces temps de guerre ont été le tremplin de nombreux projets scientifiques (parmi lesquels Internet), internationalistes et dans le cadre d’une course à la puissance. De par leur nature, ces projets nécessitent une méthode que nous éprouvons chaque jour sur le Web et dont nous pouvons tirer parti à notre échelle. Les outils documentaires que nous allons évoquer permettent un travail interdisciplinaire.

La fiche

Dans son Mundaneum, Paul Otlet a dû mettre en place des outils pour appliquer sa méthode documentaire, parmi lesquels la fiche. Pour entrer plus concrètement dans notre sujet, nous pouvons également citer Niklas Luhmann et son Zettelkasten, littéralement « boîte à fiche ». Ces deux personnes ont reconnu dans leur système un nouveau moyen d’accéder à l’information par des procédés innovants portés sur la fiche. Nous allons voir qu’elle est toujours un modèle profondément ancré dans nos usages numériques, notamment dans le domaine de la gestion de base de connaissances.

Le contenu des fiches de Otlet et de Luhmann est bien différent dans la mesure où l’un classait des documents et l’autre des idées. On retient l’intention commune de cadrer la rédaction de ces fiches en élaborant un modèle à partir d’une méthode simple et de les entreposer dans des meubles en vue de les retrouver, ainsi que les informations qu’elles contiennent.

Otlet et Luhmann profitent ainsi de ces différentes qualités documentaires de la fiche énumérées par Jean-François Bert2 :

Le Zettelkasten

La particularité du Zettelkasten est la mise en place d’un système d’identifiants sur des fiches contenant une idée ou une information brève. Chacune est identifiée par une suite de chiffres selon sa place dans la base. Une fiche est subordonnée à une autre dans la mesure où elle évoque le même sujet. Par accumulation on créer une arborescence de fiches comme présentée ci-dessous.

.
    ├── 1
    │ ├── 1/1
    │ │ ├── 1/1/1
    │ │ └── 1/1/2
    │ └── 1/2
    ├── 2
    └── 3

Les fiches subordonnées à la 1 abordent un sujet proche, qu’importe la profondeur de celui-ci.

Au bas de chaque fiche il est possible de noter l’identifiant d’autres fiches et ainsi d’inscrire des renvois. On retrouve l’idée d’une lecture asynchrone du Memex et de l’encyclopédie. À ces systèmes de rangement vertical et de relation horizontale on ajoute un système transversal (interdisciplinaire) de catégorie. Il est possible de marquer un groupe de fiches par une couleur, qu’elles soient ou non en lien ou qu’elles partagent ou non un parent.

On retrouve des systèmes de rangement de fiche dans des tiroirs dès le 16ème siècle3, mais c’est la méthode, simple et efficace, qui aura fait la différence. Même dans la version numérique que nous allons évoquer plus loin, une adaptation personnelle de la méthode Zettelkasten doit rester simple à mémoriser et à mettre en place. Sans cela, un utilisateur pourrait manquer de rigueur et ainsi perdre l’intérêt du processus.

Luhmann reconnaîtra lui-même que ce système l’a aidé dans sa rédaction prolifique : soixante-dix livres et quatre cents articles rédigés à l’aide de ses quatre-vingt-dix mille fiches issues de ses quarante années de carrière pluridisciplinaire. Ainsi, on comprend que l’intérêt d’un tel système augmente au fur et à mesure que les fiches s’accumulent.

Le site web https://zettelkasten.de/ est dédié à cette méthode, ainsi que le logiciel The Archive qui en ait inspiré. D’autres logiciels, souvent libres et gratuits, permettent de profiter de ce système.

Sérendipité

L’objectif ultime de l’hypertexte en tant qu’outil est d’entrer en synergie avec notre manière de penser. Notre esprit procède notamment par associations : on estime qu’une idée est le résultat de la combinaison d’autres idées, elles-mêmes synthèses de champs conceptuels plus ou moins larges, puisés dans une galaxie.

graph LR
        pomme((pomme))
        pomme -->|forme| ballon((ballon))
        pomme -->|concept| arbre((arbre))
        arbre -->|concept| feuille((feuille))
        ballon -->|concept| sport((sport))
        feuille -->|son| vent((vent))
        arbre -->|lieu| annimaux((annimaux))

« toute l’acquisition du langage consiste à associer des mots et des objets, à désigner des abstractions par des concepts […] tout effort intellectuel, du plus simple au plus complexe, passe par l’activation d’un réseau d’associations qui permettent à la pensée de se mettre en place et de saisir les objets et/ou les concepts qu’elle vise à appréhender »4

C’est de là que vient le besoin de « non-linéarité », d’asynchrone, que l’on évoquait dans la définition de Thed Nelson : on ne peut saisir une idée sans saisir son champ. Lequel ne s’étend pas de manière linéaire pour mener à notre concept, mais de manière rhizomatique5 : toute idée peut réciproquement en influencer une autre, sans hiérarchie. Ainsi, un concept a une cardinalité, il est l’origine d’un ensemble de liens.

Plus il y a de fiches dans notre Zettelkasten, plus il y a de voies vers les différents concepts qu’il intègre. Ces concepts peuvent être appréhendés avec plus de nuance, de référence… de richesse. Le travail que nous nous proposons d’étudier est un long processus qui ne commencera qu’à porter ses fruits au bout de quelques années de travail. Revenir en profondeur sur ces principes c’est vous donner la possibilité d’avoir une vue d’ensemble sur nos pratiques modernes et de vous construire la vôtre pour répondre à ces enjeux.

Hypertexte numérique

HyperCard

La fiche n’est pas nécessairement blanche lors de sa complétion. Otlet et ses secrétaires complétaient des fiches standardisées 125 × 75 mm en remplissant des champs tels que décrits ci-dessous :

« Des fiches qui nécessitent aussi l’emploi d’un papier fort, qui seront perforées vers le bas, et dont la composition sera entièrement normalisée. Sur la gauche, le nom de l’auteur et son prénom entre parenthèses. À droite, un chiffre international, tiré de la CDD. Sur la seconde ligne, la date de publication, le titre de l’ouvrage in extenso. Puis viendront les indications de lieu, d’édition, d’impression »6

En informatique on utiliserait un formulaire pour générer la fiche. Aussi, par un formulaire, on pourrait automatiser un certain nombre d’opérations comme la vérification de la saisie selon un lexique limité ou bien un format, un type particulier de données.

Le logiciel grand public HyperCard (1987) d’Apple est l’un des premiers à permettre de constituer sa base de données personnelle sur ordinateur. Après avoir défini le modèle des données (champs en fonction de l’utilisation ultérieure), l’utilisateur pouvait générer des « cartes » avec des textes et images. Elles sont stockées dans une « pile » et deux flèches permettaient de les faire défiler.

HyperCard a apporté un autre outil à ses utilisateurs : un langage de programmation pour formuler des requêtes et automatiser des traitements intra-/inter-pile. C’est le langage HyperTalk dont la syntaxe est très proche de l’anglais oral. Voici une requête :

put the value of card field "typehere" into theValue

HyperCard est démarche exemplaire pour les utilisateurs de MacOS 9. N’importe qui pouvait, par exemple, concevoir un système de carnet de contact personnalisé ; le même que vous complétez en ajoutant un contact sur votre téléphone portable. Tout le monde pouvait créer, modéliser et administrer sa base de données, par une interface graphique, mais aussi au moyen d’un langage de programmation simple. C’est exactement ce vers quoi nous allons : concevoir un travail de stockage de connaissances et anticiper son utilisation par différentes interfaces.

« It’s kind of the freedom to organize the information, according to are things or associate with each other, not just according to the next in the list » Bill Atkinson, vidéo Hypercard

À l’inverse, de plus en plus de logiciels occultent ces démarches techniques complexes. Le formulaire est pré-conçu, la saisie simplifiée sinon automatique et impossible de consulter la base en détails. Certes, il est possible d’obtenir des contenus rapidement, mais on perd en contrôle et en littératie. On ne sait pas comment fonctionnent nos application, où vont les données, comment les récupérer, les réutiliser. Parler d’un système auto-documentaire comme nous le faisons, c’est aussi poser la question de notre rapport à nos données.

De la fiche à l’objet

En complétant un formulaire quelconque, on créer ce qu’on appelle en informatique un objet. Dans le vocabulaire de programmation, le formulaire est une class et l’objet, la fiche, est une instance de cette class. Soumettre le formulaire revient à instancier la fiche. Cette notion d’instance signifie héritage : une fiche hérite strictement des métadonnées prévues par le formulaire.

Compléter cent fois le formulaire permet de créer (instancier) autant d’objet sont la structure est identique (héritage commun). Ces fiches sont stockées dans un même espace : une « pile » d’HyperCard ou un SGBD (système de gestion de base de données). Un objet est un artefact indépendant. Il a une substance et un agir, respectivement des attributs (données complétées dans les champs) et des méthodes (usages de ces données). Il n’est pas palpable, mais il est une réalité, dans un espace numérique.

La fiche a également des attributs et des méthodes ; elle contient « la date de publication, le titre de l’ouvrage » etc. et elle a un usage propre, un intérêt à être consulté. De même pour la « carte » de contact HyperCard ou, plus abstrait, la ligne affichée dans l’interface type tableur du SGBD. Comme avec le Zettelkasten de Luhman, plus il y a d’objets, plus le traitement est interessant.

Une publication sur un réseau social est une fiche7 : on complète un formulaire qu’on soumet et les internautes peuvent annoter notre fiche par un like, un commentaire. C’est aussi un moyen de documentation.

L’espace numérique, celui de notre base, est formé par les relations entre ses objets. Le tout forme une structure (une encyclopédie, un tiroir de Zettelkasten, une bobine une Memex etc.) et c’est elle qui va nous permettre d’aller de fiche en fiche.

Analogique Informatique
meuble base de données
modèle class
méthode formulaire
fiche objet

Présentation explicite du parallèle entre fiche papier et la fiche comme objet numérique.

Le paradigme de la programmation orienté objet a été conçu pour contrôler précisément ce type de système avec une méthode complète pour concevoir, modéliser et programmer ce type d’infrastructure. Ce sera également notre paradigme documentaire.

Les moyens changent, le vocabulaire, les outils, mais l’intention demeure. Ainsi, l’identifiant est un élément fondamental, commun à la fiche de Zettelkasten et à l’objet. Au sein de ces systèmes documentaires, chaque fiche, chaque objet doit pouvoir être précisément nommé et localisé pour pouvoir exécuter des opérations depuis une boîte de commande, en HyperTalk, en SQL ou via l’interface graphique d’un logiciel. Nos systèmes analogiques comme numériques ne supportant pas l’ambiguïté ou tout autre forme de vide.

Éditorialisation

Par le biais de l’informatique, la fiche est éditorialisée, soumise à des « dispositifs technologiques qui déterminent le contexte d’un contenu et son accessibilité »8. Une fois la fiche repérée dans l’espace numérique grâce à son identifiant, ces « dispositifs » (logiciels) permettent via une interface d’apporter des modifications à une fiche en profitant d’outils puissants comme par exemple la recherche plein texte ou le remplacement de caractères grâce aux expressions régulières (regex).

Le logiciel Zettlr va jusqu’à proposer des outils d’écriture évaluant la lisibilité du texte et permettant d’entretenir son propre Zettelkasten. Il prend en charge la génération d’identifiants, aide à la liaison des fiches, à l’inscription des catégories et autres champs de métadonnées.

Zettlr est un logiciel de rédaction académique. Il propose des fonctionnalités telles que la gestion des références bibliographiques, l’export de PDF et d’autres formats de fichier, le tout en respectant le système d’édition numérique de son utilisateur. Ainsi, Zettlr s’inscrit dans un processus de lecture-écriture en reposant sur différentes dépendances. BibTeX (extension de Zotero) permet d’indexer et d’exporter les références bibliographiques et Pandoc d’exporter les fichiers. Il est nécessaire d’installer notamment ces logiciels tiers pour pouvoir pleinement utiliser Zettlr.

Nous allons étudier certaines pratiques documentaires liées à la fiche et à la base de données par le biais de logiciels comme Zettlr, sélectionnés pour leurs approches de l’organisation et de la structuration d’une base documentaire.

Cardinalités

La cardinalité exprime le caractère « multi-directionnels »9 d’un contenu hypertextuel. L’application Roam (et ou son équivalent gratuit RemNote) est intéressante s’agissant de structurer les fiches de manière externe, mais aussi de manière interne : chaque fiche présente une hiérarchie des informations qu’elle contient, et elle est reliée à d’autres.

Double maillage

Les fiches dans ce logiciel sont séquencées par des puces. Chaque puce est une information à laquelle il est possible d’ajouter d’autres puces, « sous-informations » pouvant recevoir d’autres puces etc.. Cette mise en abyme permet de hiérarchiser, d’ordonner les informations. Ce système sert typiquement à inscrire des couples terme-définition ou général-spécifique.

Les puces sont indépendantes dans la mesure où il est possible dans une fiche d’intégrer le contenu d’une puce d’une autre fiche. Ça n’est pas une liaison, mais un « appel » hypertexte noté entre doubles parenthèses. Il est également possible de mettre en place des liens hypertextes, d’une fiche à l’autre. Il ne s’agit plus d’une intégration (interne), mais d’une liaison (externe). Si dans l’une des puces (source) on inscrit un lien hypertexte noté entre doubles crochets vers une fiche (cible), la fiche d’origine est liée à la fiche cible, faisant abstraction de leurs strates internes (puces).

Ainsi on différencie deux maillages : une hiérarchie interne des fiches (verticale, en arborescence) et des liaisons externes (horizontal, rhizomatique). De cette manière, toute information est décentralisée, amovible et tout document peut être relié à un autre.

Liaisons régulières

Cette possibilité de faire circuler les « puces » est très intéressante dans la perspective de tenir un carnet de recherche ; c’est ce que proposent explicitement Roam et RemNote quand ils réservent un bouton pour créer la « daily note », la note du jour. Si régulièrement on prend le temps de rédiger une fiche concernant le déroulé de sa production, il est pertinent en phase finale de parcourir ses fiches et de faire « appel » à ces puces pour en organiser certains dans un document de synthèse. Ainsi les informations (puces) conservent leur contexte (fiche, arborescence, d’origine) et peuvent être réunies pour donner un nouveau contexte, une nouvelle vue de la base de connaissances. On évitera ainsi d’exposer dans nos fiches des informations ex nihilo, sans contexte.

Le tag est un autre moyen horizontal de parcourir les fiches, comme pour les catégories du Zettelkasten. Alors que l’identifiant est unique et isole, le tag permet de regrouper des fiches qui ne peuvent être liées directement, mais qui partagent le(s) même(s) sujet(s). C’est très utile dans une démarche pluridisciplinaire où chaque fiche aurait un tag lié à sa discipline, mais partagerait des liens hypertextes interdisciplinaires.

Logiciel documentaire

Nous souhaitons mettre en place un système documentaire souple et robuste. Souple parce qu’il doit rester ouvert à un maximum de processus d’éditorialisation et robuste parce qu’il est fondé sur un système aussi simple qu’il est possible, éliminant les erreurs et incompatibilités. Il est primordial dans une « documentation personnelle réticulaire »10 de limiter les frictions entre les nœuds tout en multipliant les liens.

« Nos outils d’écriture exercent un impact majeur sur la production des connaissances. En effet : 1. Ils influencent la structuration des contenus. 2. Ils définissent les critères d’accessibilité des contenus. 3. Ils déterminent la pérennité ou l’obsolescence des contenus. »11

Les outils numériques ne sont pas neutres et nous devons pleinement établir notre système documentaire, ses contenus, ses supports et ses dispositifs.

Imaginons ce système documentaire comme on imagine un logiciel. Ils sont généralement construits comme une arborescence de fichiers interreliés par des appels hypertextes selon des protocoles propres à chaque langage utilisé. Par leur liaison on construit un logiciel, un circuit logique d’information, dont l’atomisation en une multitude de fichiers permet d’appréhender chaque élément plus facilement pour envisager un tout. C’est le principe du réductionnisme cartésien : nous décomposons un problème complexe en « sous-problèmes » plus simples. D’un point de vue interne aux fiches cela donne les « puces » de Roam et d’un point de vue réticulaire, cela donne une arborescence de fichier.

Dé-complexifier

Cette opération de division ne vise pas à simplifier (réduire) l’information, mais à la dé-complexifier. Qu’il soit inscrit dans une arborescence plus ou moins profonde ne change rien à la finalité du code source, n’altère pas son fonctionnement, mais permet aux développeurs de créer une architecture externe. Laquelle permet de mettre en place des dépendances, une architecture heuristique et d’édition numérique.

On compte également sur une architecture interne à chaque fichier (formulaire) qui figure typographiquement au sein des différentes fiches. C’est le YAML FrontMatter du Markdown (liste de métadonnées), une suite et hiérarchie de titres, ou simplement une liste si on reprend l’exemple précédant des fiches Roam et leurs « puces ».

Ainsi nous devons imaginer deux dimensions (cardinalité) :

Ces deux dimensions nous permettent d’anticiper une seconde étape de relecture, de remise en question du contenu de la base ou plus particulièrement d’une fiche : l’épreuve de la souplesse de notre méthode. Mais toujours, restons simples. Une méthode trop exigeante intellectuellement ou en équipement logiciel (dépendances) risque de faillir et la base, les milliers de fiches, avec elle.

Ouverture

Écriture pérenne

Plein texte

Pour être souple, notre système devrait débuter sur une base saine, une base libre, le plein texte ou texte brut. Il est fondamental sur nos ordinateurs, permet d’écrire les programmes informatiques, compose entre autres une grande partie de nos fichiers ainsi que les pages web. Ces fichiers sont omniprésents sans que l’on puisse s’en rendre compte et peuvent contenir des textes de toute sortes, pour tous les usages, pour les humains, pour les machines, pour les deux.

Il est le matériau principal des développeurs qui recourent à des logiciels appelés « éditeurs de texte » comme Notepad++ (Windows), BBEdit (MaxOs), Atom ou VSCode pour produire ces fichiers. Les logiciels de traitement de texte comme Word ou Writer produisent également ce type de fichier, mais remplis d’un code complexe fractionné dans une arborescence compressée. D’où la nécessité d’utiliser ces logiciels comme intermédiaires, à la fois pour la lecture et l’écriture.

« Plutôt que rapprocher l’écrivain du document final en diminuant le nombre de médiations, l’approche de Word implique une multiplication de médiations invisibles à l’utilisateur mais structurantes sur le contenu »12

Les éditeurs de texte permettent à l’inverse de contrôler précisément le contenu de nos fichiers. C’est essentiel dès lors que l’on veuille contrôler un système documentaire et donc le contenu de ses composants.

Mardown

En plein texte, il n’y a pas de police : la typographie, la taille, la couleur et l’espacement des caractères etc. sont contrôlés par le logiciel de lecture/écriture. Cela rend la lecture de ces fichiers monotone tant que l’on ne donne pas d’indice sémantique à l’interface. Le langage Markdown permet très simplement d’indiquer entre autres les titres, citations, listes, une chaîne en italique ou gras. Ainsi, les logiciels de lecture/écriture interprétant le Markdown prévoient un affichage particulier pour ces éléments.

Contrairement à des codes documentaires lourds comme les différentes applications du XML, le Markdown est simple et léger. Sa syntaxe est facile à mémoriser et elle ne concurrence pas votre ponctuation. Ainsi le caractère # précède un titre, le caractère > précède une citation, le caractère - précède un élément de liste et le caractère * succède et précède à une chaîne en italique (il est doublé pour du gras).

Certains logiciels comme Zettlr, déjà évoqué, offrent une éditorialisation très confortable de ces fichiers plein texte. Les typographies sont élégantes et les éléments bien distincts. Zettlr propose une lecture/écriture mêlant code et police : vous voyez en direct l’effet de votre syntaxe Markdown au fur et à mesure de la saisie. Pas besoin de lourds logiciels de traitement de texte pour lire et écrire confortablement ; vous pouvez tout aussi bien le faire avec pour résultats des fichiers légers et ouverts.

Édition numérique

Vos fichiers Markdown sont nativement supportés par des logiciels comme Pandoc ainsi que de nombreux autres paseurs (Parsedown, Showdown, Python-Markdown etc.) capables d’interpréter la nature des composants de votre texte et de la transformer. Pandoc est le plus polyvalent puisqu’il vous permet de compiler vos fichiers Markdown en PDF, HTML, EPUB, en fichiers Word et bien d’autres. Markdown permet de se « réapproprier ses données et [d’en] faciliter une diffusion ultérieure »13.

Après compilation, des outils comme LaTeX ou PageJs vous permettent de réaliser des mises en pages destinées à l’impression papier. Pour le web, des outils comme Hugo ou Jekyll vous permettent de générer des sites web. Vous avez l’opportunité de contrôler entièrement l’édition numérique de vos connaissances, de l’écriture à la publication, en passant par la visualisation.

« Dans un environnement où les écritures et les publications se multiplient et se concurrencent, les documents riches en données sont susceptibles d’une meilleure visibilité et accessibilité »14

Revenir sur des pratiques aussi fondamentales de l’informatique avec le plein texte, c’est aussi devoir travailler avec ses logiciels les plus fondamentaux et avoir conscience de certaines notions qui sont habituellement gérées automatiquement et donc occultées.

« Nous avons donc perdu progressivement la capacité d’écrire dans un langage interprétable par la machine. »15

La condition pour retrouver une autonomie numérique est de retrouver une littératie et de prendre en main des outils comme le terminal (MacOs, Linux) ou l’invite de commande (Windows). Ces interfaces peuvent faire peur sans un premier temps. Elles affichent une quantité importante d’information, de manière brute. Elles nécessitent de connaître des commandes, dont certaines peuvent avoir de lourdes conséquences sur l’intégrité des données. Pandoc, Hugo et d’autres outils demandent de saisie quelques commandes toutes indiquées dans leurs documentations respectives.

Métadonnées

Une grande partie des éditeurs Markdown supportent le YAML Front Matter. Il s’agit d’un entête disposée en début de fichier, encadré par la chaîne ---. Cet entête peut contenir toutes sortes de métadonnées sur le fichier et son contenu, par exemple le titre complet, la date de création, de modification, l’auteur·e, ses coordonnées etc.. Les métadonnées se présentent sous forme de couples clés/valeur, un par ligne, soit par exemple date: 02/07/2020.

Si vous souhaitez mettre en place un Zettelkasten, le YAML Front Matter vous permet de donner un identifiant à votre fichier. Lequel pourra être inséré dans une autre fiche entre doubles crochets pour dresser un lien hypertexte entre vos deux fichiers. Zettlr intègre particulièrement bien ce principe et va jusqu’à compléter vos liens en affichant le titre complet de la fiche pointée à côté du lien.

Les métadonnées sont en effet essentielles pour pouvoir mettre en place des visualisations de votre base documentaire comme nous allons le découvrir dans la troisième partie.

Intégration

Nous allons également devoir être attentifs à l’encodage. Certains éditeurs anglo-saxons encodent les caractères selon des tableaux d’encoding ne supportant par les caractères avec accents. La référence mondiale est l’UTF-8 et il faut donc dans la mesure du possible aller chercher dans les paramètres du logiciel si c’est bien l’encodage utilisé. Les logiciels présentés dans cet article l’utilisent par défault.

L’UTF-8 vous permet de diposer de tous caractères unicode. Vous pouvez écrire dans presque toutes les langues et utiliser des caractères « dessin » comme les flèches, notes de musique etc.. N’hésitez pas à utiliser ces caractères pour structurer vos documents, dessiner des formes (ASCII Art). Le site https://unicode-table.com/ liste tous les caractères de l’encoding.

Certains éditeurs Mardown comme Zettlr et Obisidian intègrent MermaidJs. C’est une bibliothèque JavaScript permettant de dessiner différents types de schémas complexes à partir de texte. Vous êtes assurés si vous perdez la visualisation grâce à votre logiciel de conserver le sens de votre schéma par son inscription.

Stockage libre

Ensuite, il est utile de stocker ces fichiers dans l’espace d’un répertoire plutôt que dans l’espace d’un logiciel. Cela limite les exports/imports, trop souvent nécessaires pour une réutilisation des données entre plusieurs logiciels. Zettlr et Obsidian opèrent sur une base issue d’un répertoire cible d’où ils puisent les fichiers. Ils permettent d’effectuer des liaisons et recherches plein texte dans cet espace. Il est donc possible d’utiliser les deux logiciels simultanément sur un même fichier, tout est assurant un versionnement avec Git ou une synchronisation dans le cloud. Le logiciel Notable propose cette même ouverture tout en gardant la simplicité des logiciels de note comme Notes d’Apple ou Google Keep. Le jour où ces logiciels disparaissent, vos fichiers sont toujours là, bien lisibles, et tant qu’il vous reste un ordinateur.

TiddlyWiki est également un outil de prise de note très intéressant. Il a l’avantage de la portabilité, de la pérennité et de la démultiplication : il s’agit d’un seul et unique fichier HTML contenant vos notes, sécurisées et inter-reliées, avec la possibilité d’ajouter des extensions pour augmenter ses fonctionnalités. Le logiciel JavaScript qu’il intègre repose sur une gestion particulièrement poussée des métadonnées. Vous pouvez réaliser des imports et exports massifs de tiddlers (fiches TiddlyWiki) en JSON et CSV pour réutiliser ce qui constitue une véritable base de données.

Rigueur

Idées orphelines

Lorsque l’on étend le champ de connaissances, que l’on complète la base, il faut toujours garder en tête l’objectif initial : bâtir un réseau de connaissances et ainsi éviter les idées « orphelines ». Une idée qui ne serait pas liée à une autre, isolée, sortirait du système, impliquant que nous serions nous-mêmes sorti temporairement de notre champ, que nous ayons « perdu le fil » — la liaison graphique. Il est important de limiter voire d’empêcher cela.

Le logiciel DokuWiki est un garde-fou très simple. Aucun bouton « nouvelle page ». Il n’est possible de créer un fichier (plein texte) qu’à condition d’inscrire un lien sur une page source vers ce qui deviendra l’identifiant de la page cible. Suivre ce lien entraîne la création de la cible. C’est exactement le système inventé par Tim Berners-Lee pour son logiciel de documentation collaborative ENQUIRE.

Ce qui est un impératif technique sur DokuWiki, dû à sa construction, peut devenir une règle dans l’extension de votre base de connaissances. Sur Obsidian et Zettlr, il est possible d’inscrire dans la fiche source un lien mort, pointant vers un fichier (cible) inexistant. Cliquer sur ce lien créera le fichier cible vous permettant de l’éditer. Ainsi, vous êtes certain d’avoir un cheminement au moins linéaire vers une idée.

Instance

Une instance est la reproduction d’un modèle, d’un pattern. L’objet qui résulte d’une instance hérite des propriétés du modèle d’origine et, dans le cas d’une fiche, de ses champs de métadonnées et de sa construction interne. Nous prenions comme exemple les fiches formatées de Paul Otlet.

L’application Notion permet de préparer des fiches modèles. Lesquelles pourront être dupliquées facilement et complétées. Ainsi, tout le travail de disposition des éléments, de création des champs de métadonnées peut être reproduit en un clic ; il reste qu’à compléter. S’il est simple de reproduire ce système en dehors de l’application, en dupliquant des fichiers textes préparés à cet effet (disposition des champs, titres, séparation etc.), la force de Notion est de permettre très simplement de gérer et interconnecter de véritables bases de données.

Les champs de métadonnées qui sont intégrés aux fiches (échelle unitaire) permettent de les trier (échelle réticulaire), cacher, ordonner. Les modèles permettent de retrouver une disposition jugée optimale à l’utilisation, mais aussi de garantir une continuité (héritage) dans le développement de la base de connaissances.

Vues

Notre base de données est une « cité savante » au sens de Franck Cormerais. Il évoque et représente dans un tableau16 l’intérêt de la valorisation dans le domaine de l’ingénierie des systèmes d’information, comme avec notre système de fiche. Ainsi, la valorisation constitue l’ « expérience de la praticabilité » de notre système. C’est par l’« adoption d’un système de valeurs et de ses représentations » que nous obtenons le moyen d’appréhender nos objets numériques, nos fiches : elles n’ont véritablement de sens que dans la structure et dans la représentation (typo)graphique. Ces « représentations » sont appelées « vues ». Il est pertinent d’en adopter plusieurs, voire de les combiner pour appréhender complètement une « pile » de fiche.

Simplifier

Nous parlions au début du chapitre précédent de de-complexifier l’information en atomisant sa saisie. Simplifier est une tout autre approche, pertinente dans le cadre des vues. Ainsi, l’ensemble des modules (fiches) forme une arborescence complexe et quasi illimité si l’on considère que nos fiches ne « pèsent » que quelques kilo-octets. Nos interfaces sont à l’inverse limitées. D’abord en taille, celle de nos différents écrans, et ensuite en charge cognitive ; une interface trop complexe ne peut être la médiatrice d’un outil quotidien censé accompagner une réflexion et non la stresser par de trop nombreuses possibilités.

Il n’est pas pertinent de présenter toute l’information. Bien qu’elle soit effectivement inscrites dans la base de connaissance, il faut équilibrer la quantité d’information quitte à la séquencer en plusieurs vues. Cela vaut aussi bien pour la lecture que l’écriture. Chacune sera l’occasion d’appréhender une quantité limitée d’informations, la difficulté étant de fluidifier le passage d’une vue à l’autre, ce que réalise parfaitement le logiciel Notion.

Vue multiplies

L’application Notion permet de structurer une arborescence complexe de manière très simple. Elle fonctionne essentiellement sur la notion de base de données et de vues. Ainsi, ce qui apparaît sur les fiches comme une liste, un tableau, un calendrier ou un tableau kamban est une seule et même base de fiches. Selon les métadonnées des fiches, elles vont pouvoir être rangées par date sous forme de calendrier, par étiquette sous forme de tableau kamban, par tag sous forme de tableau ou de liste et avec à chaque fois la possibilité de sélectionner des critères de tri, d’affichage de la base.

Il est également possible de changer de vue à tout moment, de passer de la liste au calendrier : les mêmes données changent simplement de disposition visuelle (représentation) et donc contextuellement de sens.

Vue unitaire

C’est la vue interne des fiches. C’est par elle que l’on voit les modifications à apporter, les fiches à (de)connecter. Régulièrement il faut parcourir sa base et questionner ses choix.

Cette vue varie selon éditeurs et lecteurs Markdown. Zettlr va afficher les fiches « in code » : vous pouvez voir simultanément la syntaxe Markdown et son résultat. TiddlyWiki, DokuWiki et Notable fonctionnent selon deux modes édition et lecture, le second mode occultant la syntaxe pour ne laisser que son effet. Obsidian propose les deux.

C’est une question de littératie. La syntaxe Markdown est suffisamment légère pour se fondre avec le texte, mais certains éditeurs comme Typora assistent l’utilisateur lorsqu’il écrit des blocs de code en Markdown.

Tous ces logiciels proposent un sommaire, un index des titres de la fiche avec un lien sous forme d’ancre. Ainsi, l’architecture interne peut être complexe et faciliter le parcours du document. En cela le rendu typographique, notamment des titres, est important. Un bon éditeur doit proposer une hiérarchie visuelle du texte suffisante.

Pour les développeurs, de nombreux éditeurs proposent également la coloration syntaxique du code. D’autres ne vont pas interpréter les notes en bas de page ou même les hyperliens.

C’est par cette vue qu’on appréhende l’hypertexte comme outil : une référence (ancre) inscrite en un point (nœud source) et dirigeant vers un autre point (nœud cible)17. Obsidian et Zettlr proposent une vue « backlink ». Pour une fiche (son identifiant) donné, ils vous permettent de retrouver toutes les autres fiches qui lui font référence. Ainsi vous pouvez vous déplacer de manière asynchrone, non linéaire.

Vue réticulaire

Il s’agit d’adopter une vue graphique et entière de la base. Chaque fiche est un nœud relié à d’autres selon les liens hypertextes effectifs entre elles.

Par cette vue on ne pourra appréhender les liaisons, mais aussi étudier les épicentres, la densité, constater que des fiches sont plus isolées voire orphelines et ainsi (re)penser la place réticulaire des fiches plutôt que leurs liaisons directes :

« [l’intérêt de la vue graph] ne réside pas dans ce qu’elle suggère des connexions entre les savoirs représentés (qui sont éphémères), mais dans sa valeur réflexive. En me donnant une vision d’ensemble, elle m’aide à passer d’une représentation mentale limitée (liens note à note) à une conscience plus globale de la structure documentaire que je suis en train de produire. Par exemple, je constate qu’il existe déjà des notes qui servent de passerelle entre différents champs de savoirs, et cela m’aide à voir l’aménagement qu’il faudrait faire (ouvrir à certains endroits, fermer à d’autres). »18

L’hypertexte redevient ici une notion plus qu’un outil : le lien importe moins que la structure et le travail réticulaire.

Modularité

Le logiciel Obsidian permet aisément de passer de la vue « fiche » à la vue « réseau », voire de les utiliser côte à côte. L’interface de ce logiciel fonctionne avec des fenêtres. Il est possible d’en afficher quatre sur l’espace central (soit potentiellement une vue « réseau » et trois vues « fiche »), mais aussi de les disposer dans deux panneaux latéraux, à gauche et à droite. Ces panneaux à la surface variable fonctionnent par onglet et il est possible d’y disposer astucieusement les vues.

Obsidian recourt à la bibliothèque SigmaJs pour afficher son graphe ; Zettlr repose sur la bibliothèque ChartJs pour afficher la courbe de progression journalière, sur CodeMirror pour interpréter le Markdown inscrit dans les fichiers et proposer une vue « in code », où en inscrivant la syntaxe on peut obtenir un rendu visuel ; avec Notable ils reposent sur MermaidJs pour afficher des schémas ainsi que sur ShowdownJs pour interpréter le Markdown. Les vues de ces logiciels reposent sur des programmes externes (dépendances), partagés, open source. Ils reposent tous sur ElectronJs. L’avantage avec ces logiciels, c’est que les fichiers restent à disposition pour être utilisés par d’autres. Zkviz est un petit logiciel Python permettant de visualiser son Zettelkasten en graphe.

Les moyens documentaires utilisés aujourd’hui datent du début du 20ème siècle. La rigueur et les intentions universalistes de nos aînés ont construit l’informatique moderne, l’ont façonnée, dans la mesure où les informaticiens se retrouvent dans certaines problématiques des documentalistes : la gestion d’une base d’information et d’une variété de contenus, l’adressage des requêtes, les interfaces d’usage et la richesse du partage.

Revenir à des pratiques informatiques pour gérer sa base documentaire demande de revenir critiquer de nombreux usages, voire un écosystème logiciel entier. Pourtant c’est l’occasion d’entreprendre une conception et un usage sain et pérenne de sa base de connaissances et ainsi retrouver les intentions des théoriciens du document et de l’hypertexte. Ce sont eux qui ont fourni le terreau qui permet à des logiciels comme Zettlr ou DokuWiki d’apparaître pour fournir à tous des moyens auto-documentaires aboutis.

BERT, Jean-François, 2019. Une histoire de la fiche érudite [en ligne]. Villeurbanne : Presses de l’enssib. [Consulté le 2 juillet 2020]. Papiers. ISBN 978-2-37546-078-8. Disponible à l'adresse : http://books.openedition.org/pressesenssib/6211

DEHUT, Julien, 2018. En finir avec Word ! Pour une analyse des enjeux relatifs aux traitements de texte et à leur utilisation. L’Atelier des Savoirs [en ligne]. 23 janvier 2018. [Consulté le 3 mai 2020]. Disponible à l'adresse : https://eriac.hypotheses.org/80Critique des modalités du traitement de texte et des applications qui y sont liées. Invitation à recourrir au balisage léger, aux applications de conversion pour un texte source fluide et contrôlé.

EBERLE-SINATRA, Michael et VITALI-ROSATI, Marcello (éd.), 2014. Pratiques de l’édition numérique [en ligne]. Parcours numériques. Montréal : Les Presses de l’Université de Montréal. [Consulté le 7 juin 2020]. Parcours numériques. ISBN 978-2-7606-3202-8. Disponible à l'adresse : http://parcoursnumeriques-pum.ca/introduction-20Histoire de l’édition et enjeux de l’écriture numérique en passant par l’éditorialisationOCLC: 870269451

ERTZSCHEID, Olivier, 2002. Les enjeux cognitifs et stylistiques de l’organisation hypertextuelle : le Lieu, Le Lien, Le Livre [en ligne]. phdthesis. Université Toulouse le Mirail - Toulouse II. [Consulté le 26 juin 2020]. Disponible à l'adresse : https://tel.archives-ouvertes.fr/tel-00006260

LE DEUFF, Olivier, 2014. Le temps de humanités digitales. FYP. ISBN 978-2-36405-155-5. Recueil d’essais sur les humanités numériques en trois parties et onze chapitres portant sur l’histoire ayant mené à cette discipline, ses pratiques actuelles et son évolution.

LE DEUFF, Olivier, 2019. La fiche entre économie informationnelle et attentionnelle The index card between informational and attentional economy. [en ligne]. 4 avril 2019. [Consulté le 23 juin 2020]. Disponible à l'adresse : https://archivesic.ccsd.cnrs.fr/sic_02093324La fiche est ici étudiée sous ses aspects informationnels et de plus en plus attentionnels dans les interfaces numériques. En montrant son évolution historique puis sa transformation actuelle dans les réseaux sociaux notamment, il s’agit de se demander si la fiche peut encore présenter un intérêt en ce qui concerne l’organisation des connaissances au travers d’un projet de recherche en humanités digitales sur Paul Otlet.HAL Id: sic_02093324

PERRET, Arthur, 2020. Visualisation d’une documentation personnelle réticulaire. Arthur Perret [en ligne]. 25 juin 2020. [Consulté le 3 juillet 2020]. Disponible à l'adresse : https://arthurperret.fr/2020/06/25/visualisation-documentation-personnelle-reticulaire/Applications, notamment graphique, de la méthode du Zettelkasten.

SERRES, Alexandre, 2015. Hypertexte : une histoire à revisiter. [en ligne]. 24 juillet 2015. [Consulté le 22 juin 2020]. Disponible à l'adresse : https://archivesic.ccsd.cnrs.fr/sic_01180259HAL Id: sic_01180259

VITALI-ROSATI, Marcello, SAURET, Nicolas, FAUCHIÉ, Antoine et MELLET, Margot, 2020. Écrire les SHS en environnement numérique. L’éditeur de texte Stylo. Revue Intelligibilité du Numérique [en ligne]. 2020. N° n°1|2020. [Consulté le 7 juillet 2020]. Disponible à l'adresse : http://intelligibilite-numerique.numerev.com/index.php/numeros/n-1-2020/13-vie-de-la-recherche/18-ecrire-les-shs-en-environnement-numerique-l-editeur-de-texte-styloRésumé : L’écriture et l’édition scientifiques en contexte numérique sont relativement peu interrogées ou remises en cause. Quelques outils, qui…


  1. Serres (2015)↩︎

  2. Bert (2019)↩︎

  3. Bert (2019)↩︎

  4. Ertzscheid (2002)↩︎

  5. Ertzscheid (2002)↩︎

  6. Bert (2019)↩︎

  7. Le Deuff (2019)↩︎

  8. Eberle-Sinatra, Vitali-Rosati (2014)↩︎

  9. Ertzscheid (2002)↩︎

  10. Perret (2020)↩︎

  11. Vitali-Rosati et al. (2020)↩︎

  12. Vitali-Rosati et al. (2020)↩︎

  13. Dehut (2018)↩︎

  14. Vitali-Rosati et al. (2020)↩︎

  15. Dehut (2018)↩︎

  16. Le Deuff (2014)↩︎

  17. Ertzscheid (2002)↩︎

  18. Perret (2020)↩︎