Wikis et bibliothèques

Un article de Wiki URFIST.

(Cet article fait l'objet d'un chapitre dans l'ouvrage collectif: Le Web 2.0 en bibliothèques : quels services ? quels usages ? / dirigé par Muriel Amar et Véronique Mesguich.- Editions du Cercle de la Libraire, décembre 2009 (ISBN 13: 978-2-7654-0976-2))

Sommaire

[modifier] Wikis?

Dans le paysage des outils de gestion de contenu sur le web, l'outil "wiki" présente un cas tout à fait particulier, de plus d'un point de vue paradoxal.

Le mot "wiki" est entré dans le vocabulaire de l'internaute moyen de manière relativement récente, trois, quatre ans, en même temps que se popularisait l'expression "web 2.0" pour désigner un ensemble de nouveaux outils et de nouvelles pratiques redéfinissant les modes d'échange de l'information sur Internet, au point qu'on a pu considérer l'outil "wiki" comme un des outils phares de ce nouveau paradigme du web. Or, si la principale caractéristique de l'outil wiki correspond bien à ce que d'aucuns ont voulu reconnaître comme celle de ce nouveau web, à savoir son ouverture à l'écriture[1], l'outil wiki est nettement plus ancien[2] que le phénomène web 2.0 et ses applications les plus populaires n'utilisent pas les technologies propres à celui-ci (Ajax en particulier). De plus, si l'on excepte le cas de Wikipedia, l'outil wiki n'a pas connu, avec le web 2.0, un "boom" d'adoption, comme ce fut le cas pour les blogues ou les réseaux sociaux. S'il se popularise, c'est selon une progression moins brutale, et il reste de nombreux champs d'application inexploités, en particulier dans le domaine des bibliothèques et de la documentation.

[modifier] principe de fonctionnement

"Un wiki est un système de gestion de contenu de site web rendant ses pages web librement modifiables par tous les visiteurs y étant autorisés. Les wikis sont utilisés pour faciliter l'écriture collaborative de documents avec un minimum de contraintes." (définition de la Wikipedia française au 24.04.2009).

Parmi les caractéristiques de l'outil wiki, qu'on détaillera infra, les plus saillantes sont la perméabilité entre la fonction visiteur et la fonction contributeur ainsi que la facilité et la rapidité d'accès en édition aux pages (le nom de "wiki" signifie "rapide" en hawaïien).

[modifier] petit historique

(voir l'article de Wikipedia: History of wikis[3])

[modifier] 1994/95: WikiWikiWeb

WikiWikiWeb en nov. 1996
WikiWikiWeb en nov. 1996

L'outil wiki a été inventé par Ward Cunningham pour la communauté des développeurs utilisant la méthode de programmation objet "patron de conception" (design pattern). Il a commencé à développer son WikiWikiWeb en 1994 et l'a mis en ligne sur le domaine c2.com en mars 1995. Le nom de l'outil lui est venu de celui de la navette de l'aéroport de Honolulu: "Wiki Wiki", redoublement intensifiant du mot "wiki" signifiant "rapide" et anagramme de l'anglais quick de même signification [4]. L'interface du WikiWikiWeb est extrêmement simple et ressemblerait à une page html basique, avec un minimum de mise en forme [5], si n'était au bas de la page un lien "EditText" qui va ouvrir une interface de modification.

L'idée et la mise au point du concept "wiki" est donc ancienne. En même temps que Ward Cunningham commence à y travailler (1994), le navigateur trans-plateformes Mosaic popularise le World Wide Web (et à travers lui l'internet), c'est la même année qu'est développé à partir de Mosaic le navigateur Netscape puis l'année suivante Internet Explorer. Comme le principe de base du wiki repose sur l'idée d'hypertexte, soit la même idée qui est à la base du Web[6], on peut dire que le concept de wiki a poussé sur le même terreau intellectuel que le web lui-même, au sein duquel il représente un effort de radicalisation et d'accélération des principes.

[modifier] 1995 - 2002

Les années qui ont suivi ont vu la dissémination progressive de l'outil à partir de sa communauté d'origine en même temps que l'affinement du concept à partir de son principe initial. Cette évolution, qui n'ira pas sans controverses, se fera à la fois au sein de la communauté WikiWikiWeb et en-dehors.

[modifier] au sein de WikiWikiWeb

d'après Ward Cunningham - http://c2.com/cgi/wiki?WikiHistory
d'après Ward Cunningham - http://c2.com/cgi/wiki?WikiHistory

Petit à petit sont installées des fonctions qui deviendront classiques pour l'outil, ainsi le recours à l'historique des modifications (Page History), introduit en 1996 via la fonction EditCopy. Sont en particulier mises en place des fonctions qui permettent de gérer la communauté éditrice du wiki (RecentVisitors, PeopleIndex...). C'est que très vite le succès de l'outil entraîne des problèmes liés au périmètre de l'information déposée dans le wiki et des problèmes liés à la définition de la communauté contributrice et à ses règles de fonctionnement.

D'abord consacré à une méthode de programmation (design patterns), WikiWikiWeb voit se multiplier des articles et des contributions consacrés à une philosophie de programmation (Extreme Programming) qui excède le périmètre de départ, suscitant le mécontentement et les interventions des membres de la communauté originelle. Puis ce sont des discussions et des articles concernant le wiki lui-même, le WikiWikiWeb et l'outil wiki en soi, qui envahissent le site. On voit se développer une petite guerre entre "réductionnistes" (WikiReductionists), qui "purgent" le wiki de ce qu'ils considèrent comme du WikiSquatting, et "inclusionnistes" (WikiConstructionists), qui prônent une approche ouverte d'un wiki qui auto-construirait son objet dans le mouvement[7]. Ces tensions et certaines des solutions trouvées pour les résoudre se retrouveront plus tard, à une autre échelle, autour de Wikipedia.

Une conséquence de cette petite guerre fut la création de sites "frères" (Sister Sites) de WikiWikiWeb, destinés à recevoir des contenus rejetés du site originel parce que hors sujet: à la fois les "méta-discussions" (MeatBallWiki, fondé en 2000 par Sunir Shah) et des sujets particuliers distincts de ceux du wiki. Dans le même temps se développaient sur le modèle de WikiWikiWeb mais hors de sa communauté de nouvelles applications wiki.

[modifier] multiplication des moteurs de wiki

La multiplication des wikis entraîne la multiplication des moteurs de wiki qui vont plus ou moins s'écarter du modèle posé par WikiWikiWeb. Certains vont être développés comme des "clones" de WikiWikiWeb lorsque Ward Cunningham eut rendu Wiki Base, le moteur de celui-ci, disponible en ligne. D'autres redessinent, en Open Source souvent mais aussi comme logiciels propriétaires à destination des entreprises, sur le même principe fonctionnel mais sur des bases technologiques différentes de nouveaux moteurs.

Quelques exemples:

  • TWiki (Peter Thoeny, 1998), écrit en Perl, où les données sont stockées dans des fichiers et non gérées par un logiciel de base de données;
  • PhpWiki (Steve Wainstead, 1999), première application wiki écrite en PHP (solution appelée à un certain succès);
  • Swiki (M. Guzdal & J. Rick, 1999), "ferme" de wikis écrite en Squeak, "ferme" signifiant qu'une seule installation permet de créer un grand nombre de wikis distincts;
  • UseModWiki (Clifford Adams, 1999-2000), écrit en Perl, qui introduit la syntaxe des crochets carrés pour les liens, adoptée ensuite par de nombreux wikis, dont MediaWiki;
  • MoinMoin (J. Hermann & T. Waldmann, 2000), en Python, données en fichiers plats, un code assez simple mais autorisant de nombreuses extensions;
  • JSPWiki (Janne Jalkanen, 2001), intégré comme une des applications principales du système de serveur de Sun;
  • MediaWiki (Lee Daniel Crocker, 2002), développé en PHP et avec une base MySQL pour Wikipedia; la popularité de Wikipedia va représenter pour MediaWiki une formidable base d'utilisateurs et de développement; malgré une certaine rusticité, MediaWiki est l'un des moteurs les plus utilisés.

Après 2002, la multiplication des moteurs de wiki va se poursuivre à un rythme exponentiel: aujourd'hui le site Wikimatrix qui permet de comparer les fonctionnalités et les caractéristiques techniques des différents moteurs et applications wiki en liste 120 et il n'est pas exhaustif.

[modifier] développement et diversification des wikis

Parallèlement, entre 1995 et 2002, on voit éclore des wikis hors de la communautés des informaticiens, réalisations qui expérimentent l'utilisabilité de l'outil wiki comme ses structurations possibles.

Quelques exemples:

  • World66 (R. & D. Osinga, 1999), consacré aux voyages et qui utilise la technologie wiki pour réaliser une sorte de guide de voyage universel collaboratif, avec l'idée de rendre le site profitable grâce à la publicité;
  • MeatballWiki (Sunir Shah, 2000), issu comme on l'a vu plus haut de la communauté WikiWikiWeb, terrain de réflexion et d'expérimentation qui engendre plusieurs wikis "enfants" et établit des protocoles de communication inter-wiki;
  • Sensei's Library (M. G. Pahle & A. Hollosi, fin 2000), consacré au jeu de go;
  • Susning.nu (Lars Aronson, fin 2001), wiki en langue suédoise sans objet défini au départ (WikiConstuctionism radical);

On retrouve dans ces créations la tension qui était apparue déjà dans la communauté de WikiWikiWeb entre "réductionnisme", soit l'idée qu'un wiki doit se définir un sujet ou domaine particulier (World66, Sensei's Library...), et "constructionnisme", soit l'idée que le domaine d'un wiki se définit au fur et à mesure des contributions. Wikipedia, dont l'arrivée va restructurer le paysage des wikis, résout à sa manière cette opposition: si le projet est, à proprement parler, réductionniste, la très large extension de son domaine de pertinence ouvre le champ à une intense activité constuctionniste.

[modifier] 2001/02: Wikipedia

(voir l'article de Wikipedia: History of Wikipedia[8])

Le succès de l'encyclopédie libre Wikipedia marque un tournant dans l'histoire du wiki, il fait sortir la notion de wiki du cercle des utilisateurs avertis pour toucher le grand public du web au point que pour beaucoup encore Wikipedia et wiki sont synonymes. Pourtant au départ Wikipedia n'a pas été conçue comme un projet qui aurait sa fin en lui-même, plus exactement elle n'a pas été conçue comme un site web de publication de contenu mais comme un outil de recueil et d'élaboration d'un contenu qui devait initialement être publié ailleurs.

En mars 2000, Jimmy Wales, co-fondateur de Bomis, un portail dédié à un public masculin, lance sur le web un projet d'encyclopédie gratuite (free content), Nupedia, pour laquelle il a engagé un éditeur en chef, Larry Sanger, en janvier. Le but est d'offrir gratuitement un contenu rédigé par des experts et peer-reviewed, sous une licence particulière d'abord puis sous la licence GNU free documentation. Le projet peine à s'étoffer en contenu: après un an, 12 articles seulement sont écrits. Fin 2000, Wales et Sanger cherchent le moyen d'accélérer la création de contenu pour Nupedia. Au cours d'un repas en janvier 2001, Ben Kovitz, informaticien et participant régulier de WikiWikiWeb, explique à Larry Sanger le concept de wiki, encore ésotérique à cette date. Sanger, converti, y voit la solution et propose à Wales de créer un wiki comme outil de co-écriture pour l'alimentation de Nupedia. Le 15 janvier, Wales met en ligne ce wiki sous un nom de domaine propre: "wikipedia.com".

Wikipedia tourne d'abord sous UseModWiki, le moteur de MeatBallWiki, qui ne conserve pas d'historique, stocke les données dans des fichiers plats (et non dans une base de données) et utilise la syntaxe CamelCase pour le nom des articles [9]. En juillet 2002, Wikipedia reçoit un moteur spécialement développé pour elle en PHP et sur une base de données MySQL: MediaWiki, qui est aujourd'hui le moteur le plus utilisé.

Ce croisement du concept de wiki avec l'idée d'encyclopédie libre rencontre un succès très rapide, en termes de contenus d'abord: à l'issue de sa première année d'existence, ce sont déjà plus de 20 000 articles qui sont produits, avec un rythme de croissance accéléré, en termes de notoriété aussi: elle reçoit la consécration de la grande presse par un article du New York Times dès le 20 septembre 2001. Ce succès va être tel qu'il rendra vite superflue l'existence de l'encyclopédie "mère", Nupedia, laquelle fermera en septembre 2003.

[modifier] 2002 ->

Si Wikipedia a popularisé le mot "wiki", le concept reste difficile à appréhender et, même lorsque "wiki" n'est pas simplement pris pour un synonyme de Wikipedia, les caractéristiques de Wikipedia sont souvent prises pour les caractéristiques d'un wiki en général. Or comme on le verra plus bas, les applications wiki les plus faciles à mettre en place sont celles qui, focalisées sur un domaine précis, mobilisent un groupe lui aussi préalablement défini et de manière non publique, soit tout le contraire de Wikipedia!

Aussi si le mot "wiki" est entré dans le vocabulaire de l'internaute à partir de 2002, si le phénomène Wikipedia est devenu un élément représentatif de la nouvelle donne du web dite "web 2.0", l'adoption de l'outil wiki lui-même, bien qu'en progression constante, n'a pas connu un "boum", comme ce fut le cas pour les blogues dans les années 2003/2004 ou pour les réseaux sociaux plus récemment.

On peut estimer aujourd'hui que ce vieil outil qu'est le wiki reste un outil d'avenir et que son adoption n'a pas encore atteint la phase "plateau" où il aurait pour l'essentiel trouvé son public. C'est vrai en particulier dans le domaine des bibliothèques et de la documentation. Pour tenter de cerner en quoi il pourrait répondre à des besoins mal desservis par les outils actuellement adoptés, et avant d'examiner l'utilisation qui est d'ores et déjà faite des wikis dans notre champ, il peut être utile d'examiner de plus près les caractéristiques techniques et fonctionnelles de l'outil wiki.

[modifier] caractéristiques

L'outil wiki se place dans la famille des outils de gestion de contenu web, comme les blogues ou les content management system généralistes de type Joomla ou Drupal. Ces outils ont pour caractéristique commune de séparer la gestion de la forme de celle du contenu qui va être traité par le biais d'une base de données, permettant ainsi une ouverture à l'écriture sur le web qui en fait un des phénomènes essentiels du web 2.0 comme web inscriptible. Si un grand nombre de moteurs de wikis n'utilisent pas de logiciel de gestion de base de données (de type MySQL), les fichiers où sont stockés les contenus n'en sont pas moins structurés de façon à pouvoir être utilisés comme des bases de données.

Dans cette famille, les wikis sont en quelque sorte symétriques des blogues et on peut décrire leurs caractéristiques principales par opposition à celles des blogues, mieux connus.

[modifier] organisation du contenu

Alors que le contenu essentiel d'un blogue est organisé sous forme d'un flux de billets publiés en ordre chronologique inverse, le plus récent venant se placer sur le haut de la page principale, le contenu d'un wiki est organisé sous forme de réseau d'articles, de façon donc beaucoup moins pré-contrainte. Ce mode d'organisation est, après tout, celui du web lui-même (et l'on a vu dans l'historique comment à son origine l'idée du wiki vise à exploiter au maximum les caractéristiques de l'hypertexte et du web) et de ce point de vue ce qui va différencier le wiki, c'est la facilité avec laquelle on pourra y créer des liens internes[10]. Pour bien des moteurs de wiki, la façon la plus simple et la plus naturelle de créer un nouvel article est de créer d'abord, depuis un article existant, un lien vers l'article à venir. Ce lien peut subsister un certain temps sans article lié, assumant alors un rôle programmatique et, à la différence de ce qui se passe généralement sur le web pour les liens morts, un clic sur ce lien va non pas ouvrir une page d'erreur mais une page d'édition qui incitera à créer l'article manquant.

Le mode d'organisation principal par liens internes permet toutes sortes d'organisations secondaires: hiérarchique (sous forme d'arbre), rhizomatique, voire chronologique, etc.. Différents modes d'organisation secondaires peuvent coexister à l'intérieur d'un même wiki, de manière spontanée ou concertée, on peut aussi appliquer à l'ensemble d'un wiki une organisation secondaire, cela exige alors une coordination attentive du travail coopératif (ce soin nécessaire à apporter à la coopération est une caractéristique wiki).

[modifier] nature des unités

On parlera plutôt de "billet"[11] ou de "note" (en anglais post) pour une unité de contenu dans un blogue. Pour un wiki on parlera de "page", ce qui souligne l'homologie de structure entre le wiki et le web lui-même, ou d'"article", en analogie avec un article d'encyclopédie ou de dictionnaire, pour souligner le caractère d'unité de connaissance de la page. La technique même qui permet de faire des liens internes dans un wiki pousse à donner aux pages des titres simples et descriptifs, analogues aux entrées d'encyclopédie ou de dictionnaire, autorisant ainsi le placement de ces liens dans le corps du texte des articles liants.

Daté, un billet de blogue ne vise pas à la pérennité de la validité de son contenu informatif, sa forme (son contenu textuel) en revanche n'est pas appelée à changer[12]. Tout au contraire, et symétriquement un article de wiki vise à rester valide dans le temps quant à son contenu informatif, ce qui entraîne une mise à jour constante de sa forme matérielle (de son contenu textuel). L'impermanence du contenu textuel des articles d'un wiki est un indice de sa vitalité. Cette impermanence pose un problème de citabilité. Lorsque la fonction "historique" est implémentée par le moteur, il est possible de tourner cette difficulté en citant non pas l'article lui-même, impermanent, mais sa version à la date de la consultation telle qu'elle est conservée dans l'historique.

[modifier] mode de rédaction

Même dans le cas où un blogue est collectif, chaque billet est le résultat d'une rédaction individuelle[13]. A l'inverse un article de wiki est ouvert à l'intervention de l'ensemble de la communauté auteur de celui-ci. La succession des interventions sur un même texte tend à effacer tout caractère personnel que pouvait posséder la première rédaction de cet article et c'est une des critiques les plus pertinentes adressées à Wikipedia qu'on n'y entend pas de "voix" ou que la multiplicité des voix intervenant sur les mêmes articles y produisent un style incohérent et morne.

L'interface d'écriture d'un wiki, dans son ergonomie, pousse à cette multiplicité d'interventions. Elle se distingue le moins possible de l'interface de lecture, à la différence des autres content management systems où elle est intégrée dans un back office. Et ce faisant le wiki tend à effacer la distinction entre lecteur et producteur de contenu. La coïncidence entre communauté de lecture et communauté d'écriture n'est pas obligatoire[14], on peut paramétrer un wiki en sorte de réserver l'écriture à certaines catégories d'utilisateurs, cependant les caractéristiques fonctionnelles de l'outil poussent à cette coïncidence et dans le cas où un lecteur n'est pas autorisé à intervenir sur le contenu il est plus dans la position de spectateur d'un work in progress que dans celle de consommateur d'un produit fini.

[modifier] caractéristiques fonctionnelles

Pour être défini comme wiki, un outil de gestion de contenu web, outre d'organiser son contenu sous forme de réseau de pages, possèdera les fonctions suivantes:

  • la gestion de l'accès simultané en rédaction à la même page, fonction essentielle pour l'écriture collaborative;
  • la rapidité de passage de la lecture d'un article à son édition, la perméabilité ergonomique entre la fonction lecture et la fonction écriture.

A ces deux fonctions "essentielles", faute desquelles on ne saurait parler de wiki, il faut en adjoindre deux autres:

  • la gestion de l'historique des rédactions: on a vu que l'existence de cette fonction est une condition de la citabilité d'un wiki, elle rend surtout beaucoup plus libre la rédaction, en ce qu'elle permet de revenir en arrière,
  • le langage de balisage simplifié (lightweight markup language, LBS), qui permet de mettre en forme le contenu de manière plus simple et en préservant mieux la lisibilité directe de celui-ci que par l'encodage html; ce type d'encodage, qu'on retrouve dans des outils comme SPIP, date d'avant la généralisation des petits éditeurs html WYSIWYG<What You See Is What You Get: qui fait apparaître dans l'éditeur le contenu tel qu'il sera sur le site.</ref> enchâssés dans les pages web (ainsi dans les interfaces d'édition des blogues); devant la nécessité d'apprentissage de ce langage simplifié et en l'absence, de surcroît, d'un standard, on est généralement tenté d'en faire l'économie et d'utiliser un moteur qui autorise le WYSIWYG, ce qui peut être dommage (voir plus loin).

[modifier] syndication

Le mode d'organisation de l'information au sein d'un wiki rend celui-ci beaucoup moins apte à la "syndication" (fils RSS ou Atom) que ne l'est un blogue. La nature du flux de syndication (succession dans le temps de fichiers XML décrivant le contenu d'une page html et son évolution dans le temps) lui permet de correspondre parfaitement à une information organisée en flux, ce qui n'est pas le cas du contenu principal d'un wiki. Cependant certaines pages d'un wiki sont organisées selon un flux et une accumulation chronologique d'interventions: nouvelles pages, modifications récentes, historiques des pages. Ces pages peuvent générer un flux de syndication. Leur syndication permet de surveiller l'activité sur un wiki ou sur une page particulière à travers son agrégateur RSS. Les flux générés n'offrent pas grand chose à lire en termes de contenu et fonctionnent plutôt comme des alertes.

(Certains moteurs de wikis permettent, dans l'autre sens, de syndiquer des fils de syndication sur des pages de wiki. Cette fonction est particulièrement intéressante lorsqu'on utilise un wiki pour organiser une information collectée au sein d'une veille utilisant des outils dédiés, comme delicious par exemple, générant des fils de syndication sélectifs.)

[modifier] Wikis et bibliothèques

Les premières réalisations notables dans le domaine des bibliothèques n'apparaissent que fin 2004 (voir l'article "Petite histoire des gros bibliowikis"[15] sur le blogue de David Liziard "Bruits et Chuchotements"). Il semble que dans les années suivantes, 2005 et 2006, l'outil wiki ait fait l'objet d'expérimentations multiples dans les bibliothèques, américaines essentiellement, sans cependant que ça se traduise par une adoption massive comme ce fut le cas pour les blogues et si le mot "bibliowiki" a été forgé sur le modèle de "biblioblog" il ne désigne pas un phénomène aussi massif ni aussi homogène.

Nous allons examiner quels types de wiki et quelles finalités on trouve dans le monde des bibliothèques.

[modifier] recensions

On trouve sur le web un certain nombre de recensions, non exhaustives, de ces "bibliowikis":

Si l'on tente, de faire une synthèse de ces recensions[22], on arrive à une centaine d'exemples, de natures très diverses. On peut parmi eux distinguer entre les wikis liés à une institution, bibliothèque universitaire ou de lecture publique, centre de documentation ou association et ceux nés d'initiatives personnelles, wikis thématiques générant leur propre communauté voir wikis individuels[23]. C'est parmi les premiers, et spécifiquement ceux visant le public des usagers, qu'on trouvera les réalisations les plus spécifiques à côté d'applications plus classiques.

[modifier] Wikis en bibliothèques

[modifier] à destination du public

L'outil wiki peut servir à bâtir le site web de la bibliothèque elle-même, mais le cas est rare: un exemple recensé[24]. Le wiki de la bibliothèque est plutôt conçu comme un espace parallèle et moins formel. Ses fonctions les plus couramment rencontrées sont:

  • un guide d'usage de la bibliothèque, qui en bibliothèque universitaire peut s'élargir en guide de l'étudiant,
  • une présentation des ressources (éventuellement intégrée au guide),
    • sous forme d'une liste de matières (subjects guide), éventuellement comme point d'entrée au catalogue,
    • ou comme un répertoire des ressources, documentation électronique en particulier,
  • un espace de dialogue avec les lecteurs (à qui sont alors ouvert les droits en écriture sur le wiki).

Le guide du service de la référence, s'il est plutôt conçu à l'intention des personnels de ce service, lorsqu'il est public, comme c'est généralement le cas, peut servir de FAQ pour les usagers.

Un usage particulier en lecture publique est l'usage d'un wiki comme support d'animations: atelier d'écriture ou clubs de lecture.

[modifier] à destination de l'équipe

Les usages dans ce domaine sont moins spécifiques. L'outil wiki est utilisé pour:

  • la gestion et la diffusion de l'information interne
  • la gestion de projet ou de groupe de travail
  • la gestion d'évènements
  • le support de formations

[modifier] utilisations "classiques" de l'outil wiki

[modifier] "intranets"

Dans la fonction de gestion et de diffusion de l'information interne le wiki peut remplacer avantageusement des outils spécifiques de gestion collaborative de documents du types Google docs. On l'appelle généralement "intranet" mais une des particularités de cette utilisation dans les bibliothèques est qu'elle est souvent librement consultable, du moins en partie par le public. La coexistence d'une information interne mais publique avec une information strictement réservée au personnel voire à une certaine partie de celui-ci, si elle est parfaitement gérée par certains moteurs, tel Confluence, onéreux et conçu principalement pour cette utilisation dans le cadre de l'entreprise, l'est difficilement dans le cadre d'un même wiki sur d'autres moteurs, Mediawiki en particulier. La solution en ce cas est de créer plusieurs wikis réglés différemment et éventuellement d'établir entre eux des liens interwikis.

[modifier] Gestion de projet

La gestion de projet est l'utilisation la plus évidente et la moins problématique de l'outil wiki et remplace l'usage, encore trop courant, du courriel, source de confusions et de détours innombrables (versionnages des textes en particulier).

[modifier] Gestion d'évènements

S'agissant de la préparation d'une conférence, d'un colloque ou d'un congrès, l'utilisation d'un wiki est le cas particulier de la précédente. Le wiki peut être également utilisé pour la diffusion des interventions et résultats de l'évènements, ce fut même l'une des premières utilisations de l'outil dans le domaine des bibliothèques (ALA Chicago 2005). Néanmoins le wiki présente quelques inconvénients pour la publication d'un contenu qui n'a pas vocation à être réélaboré: sa moindre adaptation à la syndication (cf. supra) peut nuire à la visibilité de son contenu sur le web et par ailleurs on peut souhaiter un design plus personnalisé, ce qui peut conduire à choisir un outil distinct pour la publication[25].

[modifier] pour la formation

L'utilisation des wikis pour la formation est multiple:

  • Elle permet la publication des programmes de formations et des supports de formations externes de façon facile à tenir à jour,
  • Un article de wiki peut être lui même un support de formation[26]: il peut ainsi être constamment renouvellé en fonction du feed-back des formations réalisées et de l'évolution du contenu de la formation, il offre aux personnes formées les liens inclus dans la formation sous une forme beaucoup plus confortable que depuis une présentation de type PowerPoint et il offre au formateur une plus grande liberté de navigation sur son support.
  • Enfin les personnes formées, spécialement des groupes d'étudiants, peuvent intervenir elles-mêmes sur un wiki, pour élaborer leurs travaux et pour se former au travail collaboratif. Un cas particulièrement intéressant est celui de l'utilisation de Wikipedia comme lieu de rendu de travaux universitaires.

[modifier] projets wikis en bibliothèque, pourquoi et comment

A parcourir les recensions listées ici plus haut, on rencontre un nombre significatif de liens morts ou de sites sans contenu ou au contenu lacunaire et incohérent, on rencontre un nombre encore plus important de pages d'accueil peu informatives sur le contenu et l'objet du site qu'elles ouvrent (souvent centrées sur la présentation de l'outil wiki en général). C'est que plus que d'autres outils de gestion de contenu, l'outil wiki demande pour sa mise en place une réflexion et une formulation préalable du projet, et une fois mis en place il demande un soin particulier pour sa croissance harmonieuse en termes d'accroissement du contenu, certes, mais surtout en termes de sophistication de son organisation, et tout cela est particulièrement vrai lorsque le projet est institutionnel.

[modifier] en amont

Si l'on veut formuler de la façon la plus synthétique possible quelle est la finalité d'un wiki, on devrait arriver à quelque chose comme:

"Extraire, expliciter et / ou organiser[27]
l'ensemble, implicite et / ou potentiel, pérenne ou transitoire, de connaissances (ou savoir)
d’une communauté organisée ou virtuelle."

La première question à se poser porte sur les deux éléments notés en gras ci-dessus: quelles connaissances et quelle communauté? La réponse à cette question devrait être portée sur la page d'accueil de tout wiki. Elle va orienter les choix en matière d'outil (de moteur) et de gestion dans le temps.

La réponse quant aux connaissances, en particulier sur à la durée de vie de l'outil, va permettre d'arbitrer entre la facilité de prise en main et la puissance de traitement de l'information.

La réponse quant à la communauté va entraîner une sophistication plus ou moins grande de la gestion des rôles sur le wiki.

Détaillons-la:

  • questions sur la structure de la communauté:
    • le wiki sera-t-il public ou en accès réservé? ou bien devra-t-il comporter une partie publique et une partie réservée? Et dans ce cas réservée à qui?
    • la communauté des lecteurs se confond-elle, au moins en droit, avec la communauté des intervenants, des producteurs? Ou bien est-elle plus large que cette dernière?
    • en ce cas les simples lecteurs constituent-ils la cible principale du wiki ou sont-ils simplement admis à prendre connaissance d'un work in progress dont ils ne sont pas la finalité ou seulement indirectement?
  • questions sur la nature de la communauté:
    • dans le cas où les "simples lecteurs" sont la cible principale: quel type d'environnement graphique leur correspond-il?
    • de qui sera composée la communauté éditrice du wiki?
    • est-elle définie dès le départ et fermée ou bien est-elle évolutive selon un processus d'adhésion?
    • quel est le niveau de maîtrise de l'outil qu'on peut attendre des membres de cette communauté? éventuellement après des actions spécifiques visant à élever ce niveau de maîtrise?

Les dernières questions sont particulièrement importantes dans la mesure où un projet implique une appropriation de l'outil par sa communauté éditrice. Lorsque celle-ci est, au moins partiellement définie au départ, il est souhaitable de l'associer au choix du moteur, qui devrait faire l'objet d'un travail commun préalable, au risque de voir contester des options évidentes pour le porteur de projet.

[modifier] choix du moteur

[modifier] 5 questions

Comment choisir parmi plus d'une centaine de moteurs de wiki aux caractéristiques très diverses? Il existe sur le web un outil précieux pour s'orienter dans cette jungle, Wikimatrix, qui permet de comparer 120 moteurs[28]. Il propose un wizard qui va guider dans le choix en posant les questions essentielles dans leur ordre de priorité.

  1. Veut-on une gestion des historiques des pages? Nous avons vu plus haut que sans cette fonction un wiki mérite à peine ce nom. Si le projet penche plutôt vers la publication d'un contenu pré-existant que vers l'élaboration d'un contenu, on peut ne pas exiger cette fonction.
  2. Veut-on un éditeur WYSIWYG? Question très importante, l'alternative au WYSIWIG étant le langage de balisage simplifié (LBS). La tentation est forte de simplifier la vie des intervenants mais ce choix n'est pas sans prix: l'exigence d'un éditeur WYSIWYG élimine près de la moitié des moteurs et parmi eux certains des plus puissants en terme de fonctionnalités, d'autre part l'apprentissage du LBS n'est pas très lourd et à la différence du WYSIWIG focalise l'attention de l'écrivant sur l'essentiel: la structure de la page et les liens. La réponse à cette question dépend d'une part de l'évaluation que l'on va faire du niveau de maîtrise qu'on peut attendre des membres de la communauté éditrice (dernière question supra) et d'autre part de l'ambition que l'on a pour le wiki en termes d'organisation du contenu et de pérennité. Un wiki de gestion de projet, appelé à fermer à l'achèvement du projet, ne justifiera pas le même investissement en apprentissage et acquisition de compétences qu'un projet d'encyclopédie et justifiera le choix d'un moteur rapidement utilisable et donc doté d'un éditeur WYSIWYG.
  3. Veut-on un support commercial? Un support commercial suppose évidemment que le moteur choisi est lui-même un produit commercial, onéreux (éventuellement très onéreux). Les produits dans ce créneau sont généralement destinés aux (grosses) entreprises. Un tel choix peut être justifié dans le cas d'un wiki chargé de gérer l'ensemble de l'information d'une grosse structure, avec zones publiques et zones réservées, etc..
  4. Veut-on une interface non-anglophone, dans la langue nationale? Il s'agit bien de la langue de l'interface, le contenu pouvant être dans une langue différente de celle de l'interface. Le wizard de Wikimatrix propose un nombre impressionnant de langues mais il faut savoir que parmi les moteurs triés figure MediaWiki qui bénéficie des développements linguistiques destinés à Wikipedia. Le choix d'une langue rare limitera drastiquement le choix.
  5. Veut-on un wiki hébergé sur un serveur distant (in the clouds) ou un moteur à installer sur un serveur local (celui de l'université ou de la bibliothèque par exemple)? Deuxième question difficile. L'installation locale permet une liberté et une maîtrise beaucoup plus grande, en termes de paramétrages et d'implémentation de fonctionnalités spécifiques, il permet de plus une parfaite maîtrise du patrimoine informationnel, mais par ailleurs elle suppose la mobilisation de compétences spécifiques, compétences informatiques professionnelles pour l'implémentation et le dépannage (compétences dites AMP: Apache, MySql et PHP, pour Mediawiki par exemple), familiarité avec la manipulation des fichiers pour l'administration régulière du wiki. Le choix ici dépendra d'une part de l'ambition du projet, comme pour la deuxième question, et d'autre part de la disponibilité de compétences informatiques de voisinage[29]. On peut vouloir commencer à tester un projet wiki sur une plateforme d'hébergement avec l'idée de migrer en local lorsque l'intérêt et la viabilité du projet se confirment. Etant donné l'inexistence d'un standard de LBS, on devra choisir alors un moteur existant sous les deux formes, hébergé et installable en local.

A ce stade on s'est posé les questions essentielles[30], dont deux (2 et 5) supposent de véritables choix stratégiques. Cette suite de questions débouche cependant sur des nombres de moteurs qui restent importants. Une autre méthode peut être d'examiner les choix faits pour des réalisations existantes.

[modifier] MediaWiki et PBWorks (ex-PBWiki)

Si l'on examine les choix de moteurs faits pour les "bibliowikis" listés dans les recensions citées supra, on trouve une vingtaine de moteurs différents mais très inégalement utilisés: le plus utilisé, nettement, est MediaWiki qui fait tourner 40% des wikis examinés (36 sur 90), ensuite vient PBWorks (anciennement PBWiki) avec 22% (20), puis assez loin derrière 2 moteurs avec 5 ou 6 utilisations (Seedwiki et PMWiki), 5 moteurs utilisés 2 fois, 12 ne sont utilisés qu'une fois.

Sur les questions discriminantes (2: éditeur WYSIWYG et 5: hebergé ou installable), PBWorks et Mediawiki représentent des choix opposés: PBWorks offre un éditeur WYSIWYG et est une plateforme d'hébergement, Mediawki, en version normale, est à installer sur un serveur local et ne propose pas d'éditeur WYSIWYG.

PBWorks[31] est un service commercial d'hébergement de wikis fonctionnant selon le principe dit freemium: il offre gratuitement un service de base et toute une gamme de services supplémentaires payants. PBWorks peut ainsi être utilisé comme un wiki-intranet d'entreprise pour un coût correspondant à ce type de produit (comme Confluence).

Comme on l'a déjà vu, Mediawiki est le moteur de Wikipedia, il a été développé spécialement pour l'encyclopédie et il est offert en open source. Il bénéficie des développements réalisés pour celle-ci et bénéficie d'une base d'utilisateurs quantitativement inapprochable par les autres moteurs. Il est modulable, c'est-à-dire qu'aux fonctions de base on peut ajouter des fonctions spécifiques correspondant à l'usage particulier qu'on fait du wiki: lecteurs RSS, audio ou flash, lecteur de cartes heuristiques, gestionnaire de références bibliographiques, sémantisation, etc.. Il n'est pas le seul moteur à fonctionner ainsi mais il possède sans aucun doute la base d'extensions possibles la plus importante. Il utilise une base de données MySQL ou PostgreSQL et des scripts PHP. L'installation est relativement simple: ouverture d'une base de données, copies de fichiers sur le serveur et lancement d'un script d'installation mais l'administration du moteur (l'administration technique du site) ne dispose pas d'interface ergonomique et se fait par transfert de fichiers et écriture sur un fichier. Enfin Mediawiki permet l'installation de "fermes" de wikis, c'est-à-dire de faire tourner plusieurs wikis distincts sur une même installation du moteur[32].

Les deux moteurs les plus populaires, dans notre domaine au moins, représentent donc bien l'alternative qu'on rencontre au moment de faire le choix d'un moteur. Pour simplifier on pourrait dire:

  • Vous avez un projet à court terme (gestion de projet ou d'évènement), impliquant des personnes n'ayant pas de compétence informatique particulière, et / ou vous ne disposez pas d'un support informatique facilement mobilisable et / ou vous ne visez pas une organisation complexe ou innovante du contenu déposé dans le wiki: chosissez PBWorks.
  • Vous avez un projet à long terme, centré sur l'organisation des données, sur la gestion des connaissances, impliquant des personnes prêtes à investir un peu de temps pour acquérir quelques compétences supplémentaires, vous disposez d'un support informatique disponible (compétences AMP) ainsi que d'un espace serveur utilisable: choisissez Mediawiki.

Bien entendu cette simplification, qui permettrait de passer de plus de 120 alternatives à 2, est un peu excessive. Des besoins particuliers justifient le choix d'autres moteurs, par exemple:

  • 'Dokuwiki, qui ressemble à MediaWiki, en particulier qui permet l'installation d'extensions (en moins grand nombre cependant), mais qui stocke ses données dans un fichier plat et donc peut être installé avec un simple accès au serveur sans avoir besoin d'autorisation sur un gestionnaire de bases de données.
  • Un moteur comme Confluence, s'il a déjà été acquis par l'établissement pour son intranet, en particulier lorsque le projet est plutôt orienté "équipe" (gestion de projets...).

On peut en particulier vouloir bénéficier des fonctionnalités puissantes de Mediawiki, être prêt à former les compétences de la communauté éditrice et ne pas disposer des pré-requis informatiques, en compétences et en matériels, nécessaire à l'installation d'un wiki Mediawiki ou souhaiter ne les mobiliser que dans un deuxième temps, lorsque la viabilité du projet aurait été confirmée. La possibilité d'utiliser Mediawiki en mode hébergé est alors intéressante: il existe plusieurs fermes de wikis gratuites tournant sous Mediawiki. Wikia est la plateforme hébergée "officielle" de la fondation MediaWiki. L'ouverture d'un wiki n'y est pas automatique, elle doit faire l'objet d'une demande motivée par un projet (assez facilement accepté). Evidemment la gestion du wiki sur la plateforme va subir de fortes limitations, en particulier on se trouve restreint aux extensions qui sont déjà installées - les extensions les plus importantes sont installées, cependant, et l'administration de la plateforme tient compte des demandes de la communauté des utilisateurs. Il existe d'autres fermes gratuites mais qui ne présentent pas les mêmes garanties de pérennité. Parmi elles, l'une est notable: Referata où sont installées les extensions "wiki sémantique" de Mediawiki.

Enfin, il faut faire un sort particulier à WikIndx qui un wiki spécialisé dans la gestion de références bibliographiques ou, si l'on veut, un logiciel de gestion de références bibliographiques wikifié. Il correspond donc à un besoin très spécifique, il possède des filtres qui permettent de l'interfacer avec MediaWiki ou Dokuwiki.

[modifier] accompagnement

Une fois le projet défini et l'outil choisi pour le mettre en oeuvre, un wiki continue à demander un soin constant. Pour l'installation et le paramétrage, bien sûr, mais ensuite il faut sans cesse s'assurer de l'engagement de la communauté éditrice et de l'harmonisation de ses pratiques. C'est sans doute vrai pour tout site web mais ce l'est particulièrement et à un degré supérieur pour un site collaboratif, dont l'organisation va en grande partie s'inventer dans sa croissance[33], et ce le sera d'autant plus qu'on aura plus d'ambition en termes d'organisation du contenu.

Alors que pour d'autres outils de gestion de contenu, des erreurs de choix, un soin trop distrait, peuvent avoir pour conséquence une réalisation médiocre, ils peuvent faire avorter un wiki. C'est qu'un wiki a pour vocation de devenir pour l'objet qui est le sien, pour l'ensemble de connaissances qu'il vise, un "guichet unique", l'endroit où sa communauté de destination va venir trouver l'information pertinente sans avoir besoin de la chercher ailleurs, sinon pour l'y faire venir. Dire cela, c'est dire aussi que la réussite, quand elle advient est à la hauteur de l'exigence et du risque.

[modifier] des wikis pour (et par) les bibliothécaires

Quelques wikis thématiques sont devenus ainsi, sinon des "guichets uniques", du moins des outils de référence pour les bibliothécaires.

[modifier] Quelques incontournables

A commencer par quelques "incontournables", issus de la communauté des professionnels de la documentation, consacrés aux sciences de l'information et des bibliothèques en général. On en retient ici trois en français et deux en anglais[34].

  • Bibliopedia, l'encyclopédie collaborative francophone de référence, créée en 2006 par David Liziard, d'abord sur la plateforme Wikia puis migrée sur une installation Mediawiki propre.
  • Le portail des sciences de l'information et des bibliothèques de Wikipedia, animé par Alain Caraco, plus axé que la précédente sur la bibliothéconomie classique.
  • DokuPedia, site universitaire, associant plusieurs universités, pour la plupart ibériques.
  • LisWiki, la première encyclopédie wiki consacrée aux sciences de l'information et des bibliothèques, créé en juin 2005 par John Hubbard.
  • LibSuccess, créée en juillet 2005 par Meredith Farkas, dans une optique plus pratique (recenser les "bonnes pratiques") que la précédente.

(Ces 5 encyclopédies de référence tournent sur Mediawiki.)

[modifier] D'autres wikis thématiques

Quelques wikis à thématiques plus précises:

  • WikiPoldoc, issu du groupe "Poldoc" de l'Enssib et consacré à la politique documentaire.
  • ALA Professionaltips, les conseils des membres de l'American Library Association.
  • ALPHABib, sur l'accueil des handicapés en bibliothèques, hébergé par la BPI.
  • the Blogging Libraries Wiki, qui se veut un répertoire des blogues de bibliothèques.

[modifier] Wikipedia ?

Un dernier (ou premier!) incontournable est Wikipedia. Ce n'est pas le lieu ici de rapporter et encore moins d'évaluer les polémiques dont l'encyclopédie gratuite a fait l'objet[35] mais peut-être de rappeler que Wikipedia est venu souvent occuper la place, dans les bibliothèques et hors d'elle, qui était celle des grandes encyclopédies généralistes dont le coût faisait que pour beaucoup elles n'étaient consultables qu'en bibliothèque. S'il est indispensable de développer et d'encourager une appropriation critique des puissants outils du web que sont Google et Wikipedia encore faut-il que cette approche soit vraiment critique et non seulement négative et qu'elle soit une véritable démarche d'appropriation et non de rejection, au risque sinon de voir s'installer une schize entre les pratiques effectives et les discours sur ces pratiques, voire entre les pratiques "légitimes", dans le cadre des études par exemples, et les pratiques privées. Un modèle de pédagogie à l'appropriation critique de Wikipedia est le travail que Martha Groom a fait faire à ses étudiants de l'Université de Washington[36].

[modifier] Quel futur pour les wikis dans les bibliothèques ?

La complexité de l'outil wiki, la diversité de ses applications possibles font qu'il est imprudent de se risquer à prévoir l'évolution à venir de son utilisation. On peut néanmoins proposer quelques pistes.

Dans l'état actuel de la technologie wiki, la réserve d'adoptions à venir se situe vraisemblablement du côté des usages les plus humbles. Dans les années 2005 - 2006, on a vu, dans la lancée du succès de Wikipedia, une floraison de projets wiki, d'abord dans les bibliothèques américaines puis, avec peu de décalage, en Europe. De ces tentatives, certaines ont débouché sur de belles et utiles réalisations, nous en avons listées quelques unes ici, mais il y a eu beaucoup de déchets et l'on trouve encore sur le web de ces wikis avortés, déséquilibrés, plein de trous et en déshérence. Beaucoup de ces projets, peut-être parce qu'ils avaient Wikipedia en ligne de mire, ont péché par excès d'ambition et par sous-estimation du soin que requiert un projet de knowledge management collaboratif. Et cependant l'outil wiki reste peu employé dans des domaines où sa mise en oeuvre est la plus simple: trop souvent pour la gestion de projet ou d'évènement on continue d'avoir recours à l'échange par courriel de documents Word[37] là où un wiki simple apporterait sans trop de souci facilité, rapidité et sécurité. Parmi les réalisations tournées vers les usagées, les wikis mis en place par Marlène Delhaye pour l'Université Paul Cézanne d'Aix-Marseille, sous PBWiki, montrent qu'à condition de définir assez précisément l'objet et le contenu du wiki et d'utiliser un outil simple à mettre en oeuvre la technologie wiki permet de faciliter et donc d'accélérer la publication d'une information mouvante.

De l'autre côté du spectre des utilisations possibles de l'outil wiki, du côté de la gestion d'un ensemble complexe de connaissances, les wikis sont aujourd'hui au centre d'un grand nombre d'expérimentations tournées vers le prochain paradigme du web, ce que l'on appelle parfois le "web 3.0", ou le web de données ou encore le web sémantique. Wikipedia en particulier est à la fois source de données pour des projets expérimentaux comme DBpedia et une référence de comparaison pour d'autres comme Freebase ou Wolfram Alpha. Pour le moteur de Wikipedia lui-même, MediaWiki, des extensions sont développés qui permettent de sémantiser son contenu. On peut attendre de ces expériences de nouveaux développements de l'outil wiki, ou à partir de lui, qui pourront rencontrer les besoins les plus spécifiques des bibliothèques et du monde de la documentation[38], ce qui ouvrirait de nouveaux champs d'adoption[39].

Ainsi le vieil outil wiki, préfigurateur du web 2.0, pourrait bien lui survivre et se retrouver au coeur du prochain paradigme, au prix peut-être de métamorphoses qu'on ne peut qu'essayer d'imaginer.

[modifier] bibliographie


[modifier] Notes

  1. "Web inscriptible" / Hervé Le Crosnier, "ReadWriteWeb",...
  2. 1995, voir infra
  3. consulté le 16.04.09
  4. Voir les explications de Ward Cunningham sur l'origine du mot "wiki".
  5. La plus ancienne version de la page d'accueil sur Internet Archive
  6. On retrouve à l'origine des premiers outils du web, l'héritage du logiciel HyperCard qui permettait, sur Mac seulement, d'organiser les données selon le principe de l'hypertexte. Ce même logiciel fut une des sources d'inspiration de Ward Cunningham, comme de Robert Cailliau, collaborateur de Tim Berners-Lee pour la conception du WWW. En amont on reconnait généralement l'influence visionnaire de Vannevar Bush et de son "Memex" (1945).
  7. At its core, a Wiki is an empty room, devoid of furniture and decoration. Visitors bring the personality and mission, turning the Wiki into a library, a party or a conference room. Anick Jesdanu: 'Wikis' provide window on the wisdom of groups USA Today, September 26, 2004
  8. consulté le 5.05.09
  9. qui ne connaît pas la technique des crochets carrés pour les liens internes et impose des contraintes lourdes à l'intitulation des articles
  10. selon le principe du CamelCase d'abord, où la forme du titre des articles est contrainte: une chaîne de caractères continue comprenant une majuscule au début, puis au moins une minuscule puis une majuscule, éventuellement suivie de minuscules, puis selon le principe des free links, utilisant - dans le cadre du lightweight markup language ou langage de balisage simplifié utilisé (cf. infra) - le plus souvent des crochets carrés
  11. en analogie avec le billet d'un éditorialiste dans la presse, pour souligner le caractère d'intervention datée de l'unité
  12. au point que la modification d'un billet de blogue après sa parution, si elle n'est pas explicitement signalée, est vue comme un manquement éthique
  13. Il est bien sûr possible de publier dans un blogue un texte collectif mais dans ce cas le blogue fonctionne comme moyen de publication d'un contenu élaboré en amont.
  14. L'exemple de Wikipedia pousse à le croire. Sur Wikipedia même ce n'est pas le cas en fait, même si ce l'est en droit: seule une petite minorité des utilisateurs de Wikipedia interviennent dessus.
  15. consulté le 3.04.09. L'article est de juin 2006.
  16. consulté le 2.04.09
  17. consulté le 2.04.09
  18. consulté le 17.05.09
  19. consulté le 17/05.09
  20. consulté le 2.04.09
  21. consulté le 3.04.09. L'article est de juin 2006.
  22. J'ai essayé de le faire ici: article Bibliowikis.
  23. Si le blogue correspond mieux à l'expression individuelle, on trouve quelques wikis personnels de bibliothécaires ou professionnels de la documentation. Ils servent alors à organiser une information complexe, parfois déposée d'abord sur un blogue, souvent aussi des formations.
  24. USC Aiken Gregg-Graniteville Library
  25. Ce qui a été fait par exemple pour la journée nationale "Evaluation et validation de l'information sur Internet" organisée par le réseau des Urfist début 2007: alors que la journée avait été préparée à l'aide d'un wiki ouvert au seul comité d'organisation, la communication publique sur la journée et la publication des résultats a été faite au moyen d'un blogue: http://urfistreseau.wordpress.com/
  26. Formations Urfist Pacac
  27. C'est volontairement que j'omets "publier" ou "diffuser", bien qu'on puisse trouver cette finalité: on peut la considérer comme un cas limite d'"expliciter" et de toutes façons, pour des raisons déjà évoquées, l'outil wiki n'est pas forcément alors le mieux adapté et ses capacités propres se trouvent sous-employées.
  28. consulté le 17.05.2009
  29. Pour ce qui est des compétences, la question se pose de façon que pour la question 2: les compétences à mobiliser ou à acquérir sont nettement plus pointues mais concernent moins de monde.
  30. Le wizard pose encore quelques questions, plus techniques ou spécifiques, différentes selon le choix fait à la question 5.
  31. "PB" est pour peanut butter, le sandwich au beurre d'arachides étant considéré aux Etats-Unis comme le repas le plus simple à faire, PBWiki, le nom original du service signifiait "un wiki aussi simple à faire qu'un sandwich au beurre d'arachides". Le changement de nom indique une évolution vers un produit moins étroitement identifié comme wiki: "While wiki technology is a core foundation for PBworks, it's only part of the solution. Our goal is to give you ways to solve your collaboration problems, regardless of the underlying technology."
  32. pour la plupart les plateformes hébergées fonctionnent selon ce principe.
  33. Voir sur l'exemple de Wikipedia le développement des modèles de pages, des règles d'utilisation des catégories, etc.
  34. Selon la supposition que les professionnels de la documentation francophones peuvent lire ces deux langues. Dans d'autres langues on peut citer BuechereiWiki en allemand ou UDK 02 en croate.
  35. Voir par exemple l'article de Jaron Lanier publié dans Edge, http://www.edge.org/3rd_culture/lanier06/lanier06_index.html DIGITAL MAOISM: The Hazards of the New Online Collectivism| (30.05.2006, dernière consultation 19.05.2009).
  36. Students Find That Wikipedians Are Tougher Graders Than Their Professor / Jeffrey R. Young.- The Chronicle of Higher Education, 26.10.2007. Voir aussi la Revue de projets pédagogiques sur le site de l'INRP.
  37. Pour l'écriture collaborative d'un document unique, il existe des sortes de wiki éphémère à page unique, propsé en ligne par des fermes comme WriteBoard, qui sont mis en place instantanément et qui meurent une fois le document rédigé.
  38. Voir déjà le développement spécifique que représente Wikindx.
  39. Il faut noter parallèlement, dans le domaine scientifique, l'utilisation du wiki pour la publication de données expérimentales: projet UsefulChem, question qui est au coeur de la problématique d'évolution de la production scientifique.
  40. consulté le 2.04.09