
Après “choisir un blog“, voici un billet sur les critères de choix d’un wiki.
Le choix en la matière est plus délicat pour plusieurs raisons.
D’abord la pléthore de l’offre d’outils de wikis : le comparateur wikimatrix.org en recense près d’une centaine
Ensuite, la “fermeture” de ce type d’outil : il est relativement difficile de migrer le contenu d’un wiki à un autre. La plupart des wikis offre un langage à balises (le wiki markup) qui leur est propre : sur certains un titre de niveau 1 s’écrit comme ceci = titre 1= , pour d’autres comme cela : =titre 1, ou encore titre1 = . Pas de standard donc pour le stockage des données d’un wiki, même si on peut saluer l’initiative wikicreole qui propose un langage à balises “standard” dont la spécification 1.0 a été publiée récemment, mais seuls quelques rares outils de wiki offrent la possibilité d’utiliser le wikicreole. Deuxième difficulté, la grande majorité des wikis n’offre pas d’API qui permettent de les manipuler : il n’est donc pas aisé, en quelques lignes de programme, de récupérer le contenu d’une page de wiki ou de le modifier. Le choix d’un outil de wiki est donc très structurant.
Mais aussi la complexité du wiki : même s’il doit être simple à l’usage, le wiki offre de nombreuses fonctionnalités qui doivent être prises en compte lors d’une sélection : gestion des versions, gestion des permissions, système d’authentification, etc. Ces fonctionnalités s’appuient sur différentes briques tehnologiques qui viennent influencer le choix de l’outil. Par exemple la gestion des révisions du wiki peut s’appuyer sur une base de données, ou un système comme RCS, l’authentification peut être interne au wiki, ou être déléguée à un annuaire LDAP ou s’intégrer à un SSO tel que shibboleth, etc.
Enfin un wiki étant par un nature un outil de travail collaboratif, il est important de connaître la population qui va utiliser l’outil, et son degré de connaissance des outils informatiques. Ainsi si le wiki doit être utilisé par des non-informaticiens, la présence d’un éditeur visuel de bonne qualité est un élément clef à prendre en compte. De même si les flux RSS ne sont pas bien connus des utilisateurs, il peut être utile de disposer d’une notification des nouveautés du wiki par courriel.
Pour une entreprise le choix du wiki est conditionné par différents facteurs sur lesquels je ne m’attarderai pas ici :
- la plate-forme technologique : php ou Java, mysql ou Oracle ou SQL Server, etc.
- l’intégration dans le SI existant et notamment pour l’authentification et la gestion des habilitations
- l’existence d’un éditeur ou d’une société assurant support et formation
- le coût de la solution
- etc.
Pour un particulier qui souhaite utiliser un wiki pour créer son site web – un usage tout a fait adapté du wiki – ou même simplement pour prendre des notes, pour une petite communauté qui veut bâtir une base de connaissance, ou pour une équipe au sein d’une entreprise qui envisage de monter une maquette ou un pilote, voici une petite sélection d’outils.
pmwiki ou dokuwiki : ce sont des wikis en php qui fonctionnent sans base de données, et peuvent donc être installés chez la plupart des hébergeurs . La gestion des utilisateurs , des permissions et des plugins est plus aisée avec Dokuwiki. Le wiki de l’hébergeur gandi, ou du site sur l’asus eee pc ( wiki.eeeuser.com ) sont des instances de dokuwiki.
Si vous disposez d’une plate-forme java ( serveur de servlets tomcat ) , et d’une base de données mysql, xwiki est un très bon choix : ce wiki de “seconde génération” bénéficie d’améliorations que ne possèdent pas les outils plus anciens : une très bonne intégration d’un éditeur visuel, une bonne gestion des permissions sur les pages, un blog – simple – mais qui permet de ne pas multiplier les outils, etc. Le produit – open-source – ne dispose pas encore de beaucoup de thèmes ( skins ) , il est parfois difficile de trouver une information dans la documentation, mais c’est un outil très prometteur
Enfin , des outils un peu atypiques mais extrêmement utiles : des wikis constitués d’une seule page html — et du code javascript – qui permettent d’avoir un wiki qui tourne uniquement avec un navigateur web ( firefox par exemple ). On peut ainsi mettre le wiki – i.e. le fichier html – sur une clef USB et avoir un bloc-notes que l’on balade partout avec soi. On trouve dans cette catégorie “wiki on a stick” , et tiddlywiki , plus complet mais plus sophistiqué et un peu déroutant pour un débutant
Et wikipedia ? ou plus exactement mediawiki qui est l’outil utilisé par la célèbre encyclopédie en ligne. Après l’avoir pratiqué pendant quelques mois, mon sentiment est que son cadre d’usage est très spécifique, et s’il convient bien pour écrire une encyclopédie, il est peu adapté pour le particulier ou l’entreprise: pour le particulier, c’est un logiciel trop lourd, et un dokuwiki est bien plus facile à mettre en place. Pour l’entreprise, mediawiki présente l’inconvénient majeur d’être très pauvre pour la gestion des permissions : il est pratiquement impossible de créer des espaces pour des équipes qui seules peuvent en modifier le contenu. Mediawiki ne dispose pas “nativement” d’éditeur visuel, ce qui oblige les utilisateurs à apprendre le langage de balises. Il existe certes une initiative de fckeditor d’intégrer un éditeur visuel dans ce wiki, mais l’intégration est encore perfectible – notamment avec internet explorer – : il subsiste des bugs qui agacent les contributeurs potentiels. Pour résumer, je déconseille ce wiki , surtout si vous vous lancez dans cette aventure.