Ça fait déjà trois ans que je n’ai pas publié ici… cela m’amène à réfléchir aux lacunes du blog pour l’organisation de la connaissance et aux apport des bases de connaissances.

Je pense qu’il est inutile de présenter Wikipedia, l’encyclopédie libre en ligne. Au delà de sa gratuité, quatre choses la caractérise :

• elle est participative,
• elle est simple de navigation,
• elle traite de tous les sujets,
• elle repose sur un logiciel open source.

Partant de ce principe, pourquoi n’y a-t-il pas une adoption plus importante du wiki au lieu du blog ?

Un peu de contexte

MTO, ma nouvelle activité, comporte une partie informatique puisqu’il s’agit d’un e-commerce mais aussi et surtout une énorme partie d’ingénierie électrique et mécanique puisque nous concevons des pièces (batteries, pièces plastiques, pièces d’usinage…).

Évidemment, je suis derrière la partie ingénierie et comme dans tout domaine, on se forme sans cesse. D’où cette réflexion : la nature chronologique et thématique du blog n’est-elle pas un frein à l’organisation pérenne de la connaissance ?

Comme l’équipe grandit chez MTO, j’avais un besoin d’organiser les process et données de la société. Il me fallait une documentation bien organisée que chacun puisse consulter, chaque équipe traitant de sujets très différents (documentation d’assemblage de nos pièces, référence des matériaux, process d’assemblage des batteries…)

Le blog ne me semblait pas du tout adapté, et en recherchant des solutions plus proches de mes besoins, qu’elles en adoptent le nom ou pas (knowledge base), toutes semblaient être des sortes de Wiki.

Limite du blog

Premièrement, un blog est thématique, celui-ci, dédié à l’informatique, serait dénaturé si je commençais à y poster des articles sur l’électronique ou la science des matériaux.

Deuxièmement, un blog est chronologique, mis à part la barre de recherche ou les moteurs de recherche, le contenu ancien est difficile d’accès via la navigation du site.

Ceci s’explique par la nature du blog. Comme son nom l’indique, le blog, diminutif de web log, est destiné à publier des informations de manière chronologique sur un sujet donné, c’est un journal.

Un journal, qu’il soit de bord, de voyage ou de politique, traite d’un sujet thématique et n’a pas une vocation prioritaire à être actualisé une fois l’article publié.

La connaissance, elle, est évolutive, doit être maintenue à jour (évolution de l’état de l’art, de la technologie…) et on doit pouvoir facilement et rapidement s’y frayer un chemin.

Ces problèmes ne sont pas des défauts de l’outil “blog”, ce sont des signes que l’outil est inadapté à une tâche. Le log a été précurseur dans la démocratisation de la publication de contenu, cependant, comme chaque outil à la mode, il a été adopté de manière abusive.

On suit de très nombreux blogs dans des domaines variés, néanmoins, lorsque l’on recherche une source de référence, qu’il s’agisse de Wikipedia, du MDN ou d’une documentation officielle, cela prend presque toujours la forme d’une base de connaissance ou d’un wiki (c’est un peu la même chose).

La knowledge base

Le propre du Wiki est q’il est collaboratif, je fais donc un abus de langage en utilisant ce terme, car le but recherché ici n’est pas forcément la collaboration, mais la gestion de la connaissance.

Cependant, un Wiki est juste un type particulier de base de connaissance. On peut utiliser ou non la partie collaborative et tous les outils commerciaux (Atlassian, Zendesk…) proposent la collaboration.

La connaissance est néenmoins tellement précieuse qu’il vaut mieux s’attacher à la garder ouverte et portable. Je n’ai rien contre les outils commerciaux, mais si la source est fermée et que vos besoins évoluent, mieux vaut un logiciel vous permettant de facilement tout exporter et transférer ailleurs.

D’ailleurs, le bon compromis si vous ne voulez pas vous encombrer d’héberger et de gérer votre knowledge base, c’est d’opter pour la version hébergée d’une solution open source !

Les solutions open source

Je ne vais pas ici vous faire une liste exhaustive de tous les projets, il y en a de nombreux. Premièrement, si vous hébergez vous-même l’outil, c’est un plus d’en choisir un dans une technologie que vous maitrisez.

Dans mon cas, j’ai donc limité mes recherches aux langages PHP et Node.js, mais sachez qu’il en existe dans la plupart des langages web. En ce limitant à ces deux langages, on a déjà pas mal d’options.

Il ne nous reste plus qu’à faire notre choix en fonction des fonctions offertes par les différentes solutions ainsi qu’en fonction du look & feel. Autant que possible, on doit avoir du plaisir à écrire et à lire la documentation !

Solutions PHP

L’avantage du PHP c’est qu’on que c’est supporté absolument partout dans la mesure où le projet ne requiert pas des lib exotiques. Un plan mutualisé à 3€ peut faire l’affaire.

• MediaWiki le logiciel derrière Wikipedia. Il a été développé en 2002 par des scientifiques et est surement à ce jour le logiciel le plus utilisé au monde pour les sites de gestion de connaissance. Il utilise MySQL, a un riche écocystème de plugins, dispose d’une documentation complète, adopte la syntaxe de Wikipedia (ou plutôt le contraire) et est disponible dans presque toutes les langues.
• DokuWiki est ultra léger, ne nécessite pas de base de données, offre une recherche fulltext, dispose de nombreux thèmes, supporte plus de 50 langues, offre un système de contrôle d’accès ACL, possède un riche système d’extensions et adopte une syntaxe simple dérivée de Wikipedia.
• BookStack offre une interface épurée, propose un thème classique et un sombre au choix de l’utilisateur, supporte de nombreuses langues, permet la rédaction Markdown ou WYSIWYG, supporte les diagrams.net et offre un système de commentaires. Il est basé sur MySQL, offre la recherche et intègre diverses méthodes d’authentification (GitHub, Google, LDAP…). C’est mon choix pour ma documentation personnelle car BookStack adopte une catégorisation originale : le contenu est organisé en rayons, livres, chapitres et pages.

Solutions NodeJS

Les solutions NodeJS sont légèrement plus complexes à héberger. En contreprtie, elles sont puissantes et plutôt orientées entreprise (ou pour un particulier avec des besoins avancés).

• Wiki.js est une solution Wiki puissante à l’interface épurée qui permet la rédaction Markdown ou WYSIWYG. Conçue pour les entreprises (mais pas que), elle supporte PostgreSQL, MySQL, MS SQL et SQLite. Le logiciel supporte un grand nombre de méthodes d’authentification, offre un système avancé de gestion des droits, permet en option de confier la recherche à des moteurs spécialisés (Elastic, Algolia…) et offre un système de commentaires. C’est mon choix pour la documentation de MTO.
• Outline s’adresse aussi aux équipes avec une interface très léchée et dispose d’une offre hébergée cloud. Pour l’installation auto-hébergée, il faut Postgres et Redis. La rédaction se fait en Markdown et on note la possibilité de rédiger en direct de manière collaborative. Outline offre aussi une totale intégration avec Slack, le multilangue, un système de commentaires et propose des applications natives (iOS, Android, Windows & macOS).

De nouveau, comme dit en introduction, ce n’est pas une liste exhaustive. Il s’agit plutôt d’un compte rendu des solutions notables que j’ai considéré pour mes propres besoins. Cela étant dit, à moins que vous cherchiez une solution dans un language de programmation spécifique, vous devriez avoir ici l’ensemble des outils pouvant répondre à vos besoins.

Le blog est-il donc terminé ? Évidemment non ! Le blog et le Wiki coexistent, le blog est le meilleur des outils pour véhiculer des opinions ou des retours d’expérience par exemple. Je continuerai donc à me servir de ce blog pour partager mes opinions, mes expériences et partis-pris sur des sujets de dev.