<!--{{{-->
<div class="toolbar" macro="toolbar +saveTiddler -cancelTiddler deleteTiddler">
<span class='gotoTiddler' macro='gotoTiddler insert'></span>
</div>
<div class='titleInput' macro='edit title'></div>
<div class='editor' macro='edit text'></div>
<div class='tagsInput' macro='edit tags'></div>
<div macro='annotations'></div>
<!--}}}-->
<div id='leftSidebar'>
<img id="logo-horizontal" alt="Logo Co-org" src="co-org_logo_210x70.jpg" />
[[Co-orgSidebar]]
</div>
<div id='rightSidebar'>
<div id='tBar'></div>
</div>
<div class='toolbar'>
<span class='gotoTiddler' macro='gotoTiddler insert'></span>
<span class='newReference' macro='newReference'></span>
<span macro='toolbar references deleteTiddler > fields syncing permalink closeOthers'></span>
</div><div class='titleContainer' onclick='config.titleLeftClick(this)' oncontextmenu='config.titleRightClick(this, event)'><span class='title' macro='view title'></span></div><div class="viewer" macro="view text wikified"></div>
Les utilisateurs peuvent être déroutés au premier abord par le wiki. Certains d'entre-eux retardent alors le moment où ils commenceront à l'utiliser, voire même s'opposent activement à cette ''nouvelle façon de travailler''.
Afin de prévenir ce risque, il est important d'accompagner les utilisateurs dans leur découverte du wiki. Pour cela, la meilleure approche est d'inciter les utilisateurs expérimentés à ''aider leurs collègues'' dans leurs premiers pas. Quelques conseils :
* préférer l'accompagnement ''en présence'', à côté du nouvel utilisateur devant son ordinateur ;
* le laisser se familiariser eux-mêmes avec le wiki, en n'intervenant que ''verbalement'' et seulement lorsque nécessaire ;
* limiter la visite guidée aux fonctionnalités de base et à un ''usage simple''.
L'accompagnement peut éventuellement se faire en petits groupes si les utilisateurs sont trop nombreux pour le faire en individuel. Dans tous les cas, la séance doit être courte et ''ne pas ressembler à une formation'' : le wiki doit être perçu comme simple et intuitif.
En complément, d'autre éléments peuvent être mis en place :
* une ''section dédiée'' aux nouveaux venus dans le wiki, mis en évidence par un lien sur la page d'accueil ;
* une ''assistance téléphonique'' ou par messagerie instantanée ;
* des ''vidéos d'écran'' (screencasts) : facile à réaliser avec un logiciel adéquat et idéal pour montrer comment se manipule l'interface.
Les utilisateurs réguliers peuvent également avoir besoin d'un accompagnement pour apprendre à utiliser les ''fonctionnalités avancées'' du wiki.
<<refreshDisplay>><<newTiddler>><<saveAndReload>><<autoRefreshCSS>><<generateSEOFiles>><<saveChanges>>
Les animateurs sont de simples utilisateurs déterminés à faire du wiki un espace collaboratif répondant aux ''besoins de ses usagers''. Dans l'idéal, ils sont :
* ''volontaires'' et cooptés de manière informelle, sans sélection imposée d'en haut ni privilège associés,
* ''appréciés'' et estimés par leurs collègues dans l'organisation,
* ''nombreux'' et redondants, de manière à alléger la charge de chacun d'entre-eux.
Le rôle des animateurs peut être divisé en quatre grandes fonctions :
* ''montrer l'exemple'' en contribuant au contenu du wiki,
* [[promouvoir le wiki|Promouvoir un wiki]],
* [[accompagner les utilisateurs|Accompagner les utilisateurs d'un wiki]],
* et [[stimuler la contribution|Stimuler la contribution à un wiki]].
Leur ''attitude'' a un impact important sur les motivations des utilisateurs. L'impression donnée à l'un d'entre-eux peut ''circuler'' rapidement et influencer la communauté toute entière. Les animateurs veilleront donc à être toujours ''à l'écoute'' des utilisateurs, et à intervenir de façon :
* ''réactive'', répondant sans attendre à chaque demande, chaque problème et opportunité d'amélioration ;
* ''non directive'', laissant chaque utilisateur libre de contribuer à son rythme sans le culpabiliser, et de s'approprier l'outil y compris pour des usages non planifiés ;
* ''amicale'', cultivant une atmosphère conviviale qui donne envie de s'impliquer.
L'efficacité de leur action se fera sentir ''à long terme'', car les habitudes de travail dans une organisation évoluent lentement et de façon systémique.
!![[Guide pratique du wiki]]
*[[Derniers articles]]
*[[Sources, références et liens externes]]
!![[Qu'est-ce qu'un wiki ?]]
*[[Les wikis facilitent la collaboration]]
*[[Les wikis facilitent la structuration de l'information]]
*[[Les wikis permettent une communication asynchrone]]
!![[Démarrer un wiki]]
*[[Impliquer la direction de l'organisation dans un wiki]]
!![[Animer un wiki]]
*[[Promouvoir un wiki]]
*[[Accompagner les utilisateurs d'un wiki]]
*[[Stimuler la contribution à un wiki]]
*[[Encourager la co-rédaction des articles dans un wiki]]
*[[Entretenir des pages méta dans un wiki]]
*[[Encourager les pages personnelles dans un wiki]]
*[[Organiser des sessions d'édition collectives dans un wiki]]
!![[Vianney Stroebel]]
<div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>
<div id='actionBar' refresh='content' force='true' tiddler='ActionBar'></div>
<div id='mainMenu' refresh='content' force='true' tiddler='Co-orgMenu'></div>
Ce comparatif s'adresse aux personnes qui connaissent déjà Médiawiki et qui utilisent ou envisagent d'utiliser [[eGroupware|http://www.egroupware.org]], un excellent logiciel collaboratif incluant de nombreux modules (gestion des contacts, calendrier partagé, gestion de tickets d'incident, gestion de projet, création de site web, et d'autres encore.)
Attention, les critiques formulées ici concerne uniquement le ''module wiki'' d'eGroupware, qui reste à mon avis le meilleur logiciel collaboratif "tout en un" en PHP, à l'heure actuelle.
!! Présentation du module wiki d'eGroupware
Le module wiki d'eGroupware est en fait un moteur de wiki indépendant d'eGroupware, qui a été ajouté après les autres modules.
Il s'agit de WikkiTikkiTavi, un moteur de wiki dont le développement a été abandonné en mars 2005. La version de WikkiTikkiTavi utilisée par eGroupware est encore plus ancienne : elle date de février 2002. Le module d'eGroupware n'a apparemment fait l'objet d'aucun développement depuis cette époque.
WikkiTikkiTavi n'est manifestement plus utilisé sur le web : je n'ai jamais rencontré un seul wiki basé sur ce logiciel et il n'est pas cité dans http://www.wikimatrix.org, qui est la référence mondiale pour la comparaison des moteurs de wiki (la totalité des 97 moteurs actuels y sont référencés).
!! Fonctionnalité de WikkiTikkiTavi
WikkiTikkiTavi (WTT) est dépourvu de la plupart des fonctionnalités modernes des wikis.
Liste (non exhaustive) des fonctionnalités ''qui font défaut'' dans le module wiki d'eGroupware, par rapport à [[Médiawiki]] :
* Notification des modifications des pages par e-mail.
* Édition des sections d'une page (WTT : il faut faire défiler une longue page une deuxième fois pour retrouver le paragraphe que l'on veut éditer),
* Résultats de recherche triés par pertinence.
* Impression d'une page en pdf.
* Comparaison ''performante'' de deux versions d'une page (WTT : il y a des bugs, comme souvent dans les wiki de cette époque).
* Comparaison ''pratique'' de deux versions d'une page (WTT : les modifications sont difficiles à repérer, alors que c'est une fonction qu'on utilise tout le temps dans un wiki).
* Gestion des conflits d'édition efficace (i.e. modification simultanée par plusieurs utilisateurs de la même page).
* Sous-pages (i.e. hiérarchisation des pages).
* Distinction des modifications majeures/mineures (WTT : une correction d'orthographe y compte autant que l'ajout d'une page, ce qui encombre la liste des dernières modifications, très utilisée dans un wiki).
* Indication du nombres de caractères modifiés dans l'historique de la page (WTT : il est difficile de repérer les ajouts ou suppressions importants) .
* Affichage de listes de pages selon certains critères.
* Table des matières automatique en haut des pages.
* Page de discussion attachée à chaque page (i.e. distinguer le ''contenu'' et la ''discussion sur le contenu'').
* Renommage des liens vers une page lorsqu'on renomme la page.
* Raccourcis divers, tels que la signature de l'utilisateur dans le texte d'une page.
* Export (pour divers usages) et import des pages en XML.
* Préservation de la syntaxe wiki par l'éditeur wysiwyg (voir plus bas).
Ces fonctionnalités sont déterminantes pour que le wiki soit ''utilisé'', d'une part, et ''bien utilisé'' d'autre part, surtout par des non-informaticiens, qui ont besoin que l'interface réponde à leurs besoins courants sans devoir "bidouiller".
!! Intégration de WikkiTikkiTavi avec les autres modules d'eGroupware
L'intégration de WikkiTikkiTavi avec les autres modules d'eGroupware est limitée, et n'inclut pas la dimension qui aurait été la plus utile (voir plus bas).
Les fonctionnalités qui ont été intégrées à eGroupware sont :
* la catégorisation des pages,
* la gestion des droits d'accès,
* l'édition wysiwyg.
L'intégration des ''catégories'' d'eGroupware n'est utile que si la catégorisation mis en place est tellement complexe qu'on ne souhaite pas la dupliquer ailleurs. Par ailleurs, l'utilisation de catégories est une pratique à éviter dans un wiki. Elle correspond à une logique opposée à celle des wikis, qu'est l'hypertexte. [[Médiawiki]] donne néanmoins la possibilité de catégoriser les articles.
L'intégration de la ''gestion des droits d'accès'' n'est utile que si la structure est fortement compartimentée (en différents services, par exemple), et que les droits d'accès doivent être séparés de façon identique pour le wiki et pour les autres modules d'eGroupware. [[Médiawiki]] donne par ailleurs la possibilité de configurer les droits d'accès à volonté (avec une extension).
L'éditeur ''wysiwyg'' d'eGroupware est le même que [[Médiawiki]] (FCKeditor). Par contre, dans eGroupware les pages perdent leur syntaxe wiki et sont stockées en html (ce qui pose de nombreux problèmes) alors que dans [[Médiawiki]] la syntaxe est préservée.
Enfin l'aspect le plus important de l'intégration avec un wiki ''n'a pas été mis en place''. Il s'agit de faciliter les liens hypertextes entre les pages du wiki et les autres contenus d'eGroupware. Tout le principe du wiki repose sur cette facilité à créer des liens, et c'est la seule intégration qui aurait été vraiment utile à Port Parrallèle (pour pouvoir facilement créer un lien vers un élément de l'agenda ou du carnet d'adresse, par exemple). [[Médiawiki]] et WikkiTikkiTavi sont donc a égalité sur ce point : il faut copier-coller l'url d'un élément dans une page pour créer automatiquement un lien vers un élément d'eGroupware.
!! Adaptabilité de WikkiTikkiTavi
Un des aspects les plus important pour un logiciel de gestion de contenu est la possibilité de le faire évoluer en fonction des besoins, qui augmentent toujours avec le temps.
C'est une dimension déterminante car après quelques mois d'utilisation, tout changement de logiciel implique un coût rédhibitoire :
* une difficulté de migration des contenus telle, qu'il est en général préférable de la faire à la main (un copier-coller de chaque article et un reformatage manuel de la syntaxe)
* une perte de contenu qui résulte du point précédent (en pratique, on ne migre pas la totalité des article),
* un changement des habitudes de tous les utilisateurs, qui souvent ont déjà eu du mal à les acquérir,
* une forte perturbation de l'activité de l'organisation pendant le temps de la migration (à moins de recruter des personnes extérieures pour s'en occuper, si on en a les moyens).
Pour WikkiTikkiTavi, l'adaptabilité est la plus faible qui soit :
* Absence totale des fonctionnalités avancées qui permettent à un administrateur d'adapter facilement le logiciel aux besoins (options, templates, macros et extensions). Mêmes celles du WikkiTikkiTavi originel ne sont pas présentes dans le module wiki d'eGroupware.
* Aucune API, ce qui exclue tout possibilité de développer des fonctionnalités sous forme d'extension sans toucher au coeur du logiciel (une voie périlleuse).
* Communauté de développeurs inexistante (pas de développement depuis 2002 sur ce module), ce qui en fait une application morte.
Pour ces trois points, Médiawiki est un des wikis les plus avancés.
!! L'avis de la communauté d'eGroupware
La communauté d'eGroupware, qui devrait logiquement utiliser son propre logiciel de wiki, tend à lui préférer [[Médiawiki]].
(Cliquer sur les numéros pour lire les messages correspondant.)
* Plusieurs messages de la communauté d'eGroupware plaident en faveur du remplacement de WikkiTikkiTavi par un autre moteur de wiki, et [[Médiawiki]] est le plus cité : [[1|http://www.nabble.com/future-of-egroupware-tf4086338s3741.html]], [[2|http://www.nabble.com/Installing-Mediawiki----p9536131.html]], [[3|http://www.nabble.com/Re%3A-Installing-Mediawiki----p9536560s3741.html]], [[4|http://www.nabble.com/Better-Wiki-engine--p5483266s3741.html]], [[5|http://www.nabble.com/Re%3A-Better-Wiki-engine--p5552283s3741.html]], [[6|http://www.nabble.com/MediaWiki-p3231868s3741.html]], [[7|http://www.nabble.com/Installer-un-autre-Wiki---p8922172s3741.html]]
* L'équipe de développement d'eGroupware envisage de remplacer le module wiki actuel par [[Médiawiki]] pour la version 2 d'eGroupware : [[8|http://www.nabble.com/road-to-eGroupWare-2.0-tf3363541s3741.html]], [[9|http://www.nabble.com/Re%3A-road-to-eGroupWare-2.0-p9358925s3741.html]]
* Pour un logiciel libre, eGroupware souffre d'une documentation particulièrement déficiente, ce qui est en grande partie dû au fait qu'elle utilise WikkiTikkiTavi. Les développeurs d'eGroupware envisagent d'utiliser [[Médiawiki]] en interne pour la documentation du code : [[10|http://www.nabble.com/How-to-write-code-for-eGroupWare-in-the-future-%28part-I%29-tf3385654s3741.html]]
* Enfin, les développeurs du module d'eGroupware pERP (Project ERP) ont franchi le cap et utilisent [[Médiawiki]] : [[11|http://www.projecterp.org/mediawiki/index.php/Main_Page]]
[[Guide pratique du wiki]]
!! 8 janvier 2008
* [[Accompagner les utilisateurs d'un wiki]]
* [[Animer un wiki]]
* [[Démarrer un wiki]]
* [[Encourager la co-rédaction des articles dans un wiki]]
* [[Entretenir des pages méta dans un wiki]]
* [[Les wikis facilitent la collaboration]]
* [[Les wikis facilitent la structuration de l'information]]
* [[Les wikis permettent une communication asynchrone]]
* [[Promouvoir un wiki]]
* [[Qu'est-ce qu'un wiki ?]]
* [[Sources, références et liens externes]]
* [[Stimuler la contribution à un wiki]]
!! 30 décembre 2007
* [[Organiser des sessions d'édition collectives dans un wiki]]
!! 17 décembre 2007
* [[Encourager les pages personnelles dans un wiki]]
!! 9 décembre 2007
* [[Guide pratique du wiki]]
!! 29 novembre 2007
* [[Impliquer la direction de l'organisation dans un wiki]]
!! 28 novembre 2007
* [[Comparatif entre Médiawiki et le wiki d'eGroupware]]
Le lancement d'un wiki ne se limite pas aux aspects techniques. Changer les habitudes de travail dans une organisation est une mission de longue haleine, de même qu'un feu de camp ne s'allume pas juste avec une allumette. Cette analogie peut d'ailleurs aider à en retenir les étapes. Examinons donc les conseils du //Petit manuel de l'aventurier perdu dans la jungle//, alors que la nuit tombe...
* //Pactiser avec les chefs de la tribu locale// : [[impliquer la direction|Impliquer la direction de l'organisation dans un wiki]] de la mise en place du wiki.
* //Examiner l'humidité et le bois sec dans la forêt// : étudier les contraintes et les opportunités dans l'organisation ainsi que les besoins des futurs utilisateurs.
* //Trouver une clairière// : choisir une plate-forme de wiki, sous la forme d'un service en ligne ou d'un logiciel à installer.
* //Ramasser le bois et le mettre de côté// : réunir les futurs utilisateurs du wiki pour leur en présenter les avantages et recueillir leurs souhaits (sans définir les contenus et les usages futurs).
* //Aménager un foyer// : préparer un environnement familier dans le wiki (interface graphique, fonctionnalités, pages d'aide...)
* //Choisir quelques brindilles bien sèches// : identifier un petit groupe des personnes, parmi les plus intéressées par le wiki.
* //Assembler un petit fagot et l'allumer// : répondre à un besoin précis et immédiat de ces premiers utilisateurs (par exemple, un projet simple sur le point de commencer).
* //Attiser pour obtenir un incandescence élevée// : se concentrer sur la réussite de cette expérience pilote.
* //Ne pas étouffer les braises// : donner le temps aux utilisateurs de s'approprier l'outil en éliminant les contraintes et échéances.
* //Disposer les branches de manière à propager les flammes// : une fois le wiki amorcé, [[attirer|Promouvoir un wiki]] progressivement de nouveaux utilisateurs, les [[accompagner|Accompagner les utilisateurs d'un wiki]] dans leur apprentissage, et [[stimuler leur contribution|Stimuler la contribution à un wiki]] au wiki.
* //Veiller à ce que le brasier s'auto-entretienne// : identifier et coordonner des [[animateurs|Animer un wiki]] pour le wiki.
Pour ''stimuler'' la participation à un wiki, il est important d'encourager la ''co-rédaction'' des auteurs sur les mêmes articles.
* Plusieurs auteurs travaillant sur un thème commun vont potentiellement produire un contenu de plus grande qualité et/ou en plus grande quantité. Chacun éprouve alors la satisfaction de participer à une ''oeuvre plus riche'' que ses propres écrits personnels.
* Après avoir contribué à un article, un participant va le voir modifié par d'autres. Ils vont peut-être en changer ou en supprimer certains éléments (une pratique normale dans un wiki), mais vont généralement en laisser une partie intacte. Cette ''partie préservée'' de son travail va rester dans la version publiée de l'article avec l'approbation de tous ceux qui y ont contribué. Une approbation forte puisqu'ils co-signent tous l'article et ont une légitimité, parfois une expertise, dans le sujet traité. Cette ''reconnaissance par les pairs'' est bien plus valorisante que les compliments de lecteurs que l'on peut espérer lorsqu'on écrit seul.
* Un wiki propose généralement une fonctionnalité bien utile : la notification des changements, appelée aussi "liste de suivi". Grâce à elle, chaque auteur d'un article peut être prévenu d'une nouvelle modification, qui devient alors une ''incitation'' pour tous les autres contributeurs à poursuivre à leur tour la construction de l'article. La ''dynamique collective'' est par ailleurs renforcée par des discussions qui s'engagent habituellement entre les participants (dans le wiki ou par d'autre moyens) et stimulent les apports des uns et des autres à l'article.
Les pages personnelles font ''exception'' aux principes du wiki. Elles n'ont qu'un seul auteur et sont consacrées à tout ce qui lui est propre, à la manière d'un blog :
* ses contributions au wiki, ses ébauches de travail ;
* son identité, ses coordonnées et moyens de contact ;
* ses réflexions et commentaires informels sur le wiki ;
* sa vie, ses centres d'intérêt, ses liens favoris ;
* ses relations avec les autres participants ;
etc.
Encourager les pages personnelles peut sembler contradictoire avec la raison d'être du wiki. En pratique, elles contribuent à son ''bon fonctionnement'' :
* Elles offrent une opportunité pour les nouveaux arrivants de se ''familiariser'' avec l'interface.
* En permettant l'expression libre et individuelle dans un ''espace délimité'', elles préservent l'approche collective dans le reste du wiki.
* Elles favorisent un esprit ''convivial'' et une ''émulation'' entre les participants.
Les ''pages d'aide'' du wiki devraient inclure une rubrique sur les pages personnelles : recommandations, suggestions, liens vers des pages personnelles bien fournies, etc.
Les pages //méta//, consacrées au wiki lui-même, permettent aux utilisateurs d'organiser leur activité :
* définir les règles d'utilisation du wiki ;
* fournir une assistance et des conseils, rédiger des tutoriels et un recueil de bonnes pratiques ;
* répertorier les tâches de contribution prioritaires ;
* évaluer la progression du travail collectif ;
* résoudre les problèmes détectés par les utilisateurs ;
* arbitrer les conflits éventuels au sujet du contenu ;
* recueillir les idées et les remarques de chacun ;
* délibérer et prendre des décisions au sujet du wiki ;
* [[organiser des sessions d'édition collectives|Organiser des sessions d'édition collectives dans un wiki]].
Les pages méta forment l'espace central du wiki. Elles doivent être alimentées et consultées fréquemment par l'ensemble des utilisateurs pour assurer le bon fonctionnement du wiki et donner aux visiteurs l'impression d'une communauté dynamique.
Ce site est un ''hyperlivre'', c'est-à-dire un livre structuré en hypertexte. Comme un livre, il nécessite un long travail de recherche, de rédaction et de structuration. De nombreux articles seront ajoutés dans les prochains mois. Un flux de syndication ainsi qu'une liste de diffusion seront bientôt disponibles pour vous tenir informé des mises à jour.
L'habillage graphique a été conçu dans un souci de ''lisibilité'' et d'''utilisabilité'', à la manière d'une application de bureau et contrairement à la plupart des sites web qui privilégient l'esthétique ou la charge visuelle.
Le logiciel utilisé pour le publier ([[TiddlyWiki| http://tiddlywiki.com/]]) facilite la ''lecture non linéaire'' des articles :
* La ''liste des articles'' que vous consultez s'affiche dans la colonne de droite. Vous pouvez ainsi revenir rapidement aux articles précédemment ouverts pour poursuivre leur lecture.
* Pour ''fermer un article'', cliquez avec le bouton droit de la souris sur son onglet à droite, ou sur son titre s'il est à l'écran. Vous pouvez également ''réordonner les onglets'' avec un glisser-déposer.
* L'affichage des articles est très ''rapide'' car le site entier est chargé dans votre navigateur et fonctionne ensuite sans aucune requête auprès du serveur.
Du fait de ces particularités, ce système ne donne pas la possibilité au lecteur de contribuer au site. N'hésitez donc pas à m'envoyer vos ''réactions, questions et propositions'' à contact@czo-org.com. Je publierai les commentaires intéressants.
Notez également que les [[liens vers d'autres sites|http://fr.wikipedia.org]] (en ''rouge'') s'ouvrent dans une nouvelle fenêtre et que l'''url'' dans la barre d'adresse de votre navigateur ne change pas automatiquement à chaque article. Des outils complets seront bientôt disponibles pour mettre les articles dans vos ''favoris'' et dans les services de ''signets sociaux''.
Dans une organisation structurée hiérarchiquement, il est nécessaire d'''impliquer la direction'' dans la stratégie de développement du wiki. En particulier, les responsables doivent :
* ''expliquer'' aux utilisateurs l'intérêt du wiki pour l'organisation et pour eux-mêmes ;
* prendre des décisions ''en accord'' avec les intérêts des utilisateurs ;
* avoir ''confiance'' en la capacité des participants à utiliser correctement le wiki ;
* avoir conscience du ''temps d'apprentissage'' inhérent à ce type de logiciel ;
* ''rassurer'' les participants qui pourraient craindre d'être réprimandés à la moindre erreur commise ;
* redéfinir des ''processus de travail'' en y intégrant l'usage du wiki (par exemple, pour les comptes-rendus de réunions) ;
* prendre en compte le ''temps de travail'' nécessaire pour animer et contribuer au wiki ;
* ''rappeler'' aux collaborateurs réfractaires d'utiliser le wiki (lorsqu'un compte-rendu de réunion est envoyé en pièce jointe d'un e-mail, par exemple),
* ''montrer l'exemple'' en utilisant le wiki pour leur propres besoins.
Sans wiki, travailler à plusieurs sur les mêmes documents est difficile.
Lorsqu'ils ne disposent pas d'un dossier partagé sur un réseau, les collaborateurs doivent s'envoyer par e-mail des fichiers en pièces jointes, ce qui requiert de nombreux allers-retours et des manipulations fastidieuses sur des logiciels de messagerie. Chacun doit enregistrer le fichier sur son ordinateur pour le modifier, en donnant un nom différent pour chaque version (”cr reunion final fr V2 Fred OK print.doc”). Dans le meilleur des cas, une personne se charge de repérer les modifications éparpillées dans autant de fichiers qu'il y a de personnes et dans autant de versions qu'il y a eu d'allers-retours. Ces modifications doivent être fusionnées dans un seul document, en gérant les éventuels désaccords, redondances, conflits de version... et susceptibilités. Le plus souvent, cela représente une telle quantité de travail (rébarbatif) que cette mise en commun, si importante, n'est pas faite correctement.
Lorsqu'un lecteur partagé est disponible, il contient généralement des milliers de dossiers et de fichiers, dans un dédale d'arborescences. Un fichier ouvert par l'un des collaborateurs ne peut être modifié par aucun autre, sans qu'il soit possible (le plus souvent) de savoir qui l'a ouvert. Si chacun en fait une copie locale pour pouvoir le modifier tranquillement, la situation est équivalente à celle décrite au paragraphe précédent.
Avec un wiki, quel que soit le nombre d'utilisateurs, chacun d'entre-eux a un accès total et immédiat à la dernière version du document. Les conflits d'édition (modifications simultanées) sont gérés automatiquement. Un historique des modifications permet de visualiser en deux clics les suppressions et ajouts apportés par chacun.
Dans les systèmes de gestion de contenu reposant sur une architecture rigide, la structuration du contenu est ''planifiée'' à l'avance ou ''contrainte'' par le logiciel. Elle prend généralement la forme d'une arborescence de catégories ou de dossiers (une taxonomie), contenant des articles ou des fichiers triés de façon automatique.
Dans un wiki, la structuration du contenu repose sur l'''hypertexte'' : les pages sont connectées par des hyperliens ajoutés par les utilisateurs au fur et à mesure qu'ils créent et modifient les pages. Le wiki se structure ainsi ''progressivement'', comme un organisme vivant en gestation, en s'adaptant aux besoins réels des utilisateurs.
L'hypertexte offre des avantages majeurs par rapports aux anciennes approches :
* Il permet de définir des ''parcours multiples'' du contenu selon différents angles d'approche. La navigation dans le wiki peut être ainsi simplifiée pour chaque type d'utilisateur et chaque centre d'intérêt.
* Chaque page peut être ''référencée dans de nombreuses pages'', ce qui augmente considérablement ses chances d'être trouvée par un utilisateur lors d'une recherche.
* Les hyperliens peuvent être ''contextualisés'' par une brève description, un nom de lien différent de la cible, un emplacement approprié dans la page, etc.
* L'''ordre'' d'apparition des liens dans une page est défini par les utilisateurs selon une ''logique appropriée'' au contenu, contrairement aux tris automatisés (alphabétique ou chronologique).
* Lorsqu'il créé une nouvelle page, l'utilisateur n'a pas besoin de décider du meilleur ''emplacement'' dans une arborescence de rubriques, ce qui s'apparente généralement à un casse-tête.
Lorsqu'une arborescence de pages est néanmoins nécessaire, il est toujours possible d'utiliser des //sous-pages// ou des //espaces de noms// dans un wiki.
La //synchronie// d'un mode de communication est la relation temporelle entre l'émission et la réception du message. Une rencontre physique, un appel téléphonique et une discussion par //chat// sont des exemples de communication ''synchrone'' : émission et réception sont presque simultanées. Une lettre postale, un message sur un répondeur téléphonique et un courrier électronique sont des exemples de communication asynchrone, mais gardant néanmoins un ''certain degré de synchronie'' : le moment de la réception garde une contrainte de début (une certaine attente est nécessaire avant de recevoir le message) et de fin (passé un certain délais, le message est périmé, inaccessible ou détruit).
Même les moyens de communication plus pérennes, comme les livres et les articles de blogs, ne sont pas totalement ''asynchrones'' : le moment où ils sont publiés détermine dans une certaine mesure l'intervalle de temps pendant lequel ils pourront être lus. En effet, il vient toujours un temps (sauf exception) où un livre n'est plus disponible et où un article est enfoui dans les archives. Par ailleurs, ces supports sont rarement ''mis à jour'' et perdent de leur ''actualité'' au cours du temps.
Les wikis, par contre, ont la plus grande ''asynchronie'' possible : une information déposée dans un wiki peut-être lue immédiatement, mais également plusieurs années après si elle a été jugée suffisamment ''pertinente'' pour ne pas être effacée, et si le wiki existe encore. D'ailleurs, il est probable que les wikis compte parmi les supports de communication les plus ''pérennes''. En effet, un wiki a peu de raisons d'être abandonné tant que l'émetteur (sa communauté de contributeurs) et le récepteur (son lectorat) existent, particulièrement si son contenu est sous licence libre ou au sein d'une organisation.
Bien que le wiki soit une technologie éminemment [[asynchrone|Les wikis permettent une communication asynchrone]], il peut être utile d'organiser régulièrement des sessions d'édition simultanées. Il s'agit de prendre ''rendez-vous'' avec le plus grand nombre possible de participants à une date et à une heure donnée pour développer le wiki dans une ''ambiance conviviale'', à la manière d'un jeu de société ou d'un sport collectif.
!! Pourquoi ?
Ces événements s'avèrent particulièrement féconds pour :
* faire opérer au wiki un ''saut quantitatif ou qualitatif'',
* ''coordonner'' la construction du wiki en un ensemble cohérent.
Ils permettent également d'impulser ou de relancer une ''dynamique'' en stimulant les ''interactions'' entre les participants pour :
* se transmettre leur ''enthousiasme'' et entretenir l'émulation, dépasser les réticences et le manque de confiance en soi ;
* apprendre, ''s'entraider'' et prendre de bonnes habitudes, ''discuter'', réfléchir et résoudre les problèmes ;
* tisser des liens avec les autres participants, renforcer le ''sentiment d'appartenance'' à la "communauté".
!! Comment ?
La réunion pourra être ''virtuelle'' (en ligne) en utilisant des outils de communication synchrone : voix sur ip (téléphone}, chat, webcams... Lorsque c'est possible, il est plus convivial d'organiser une ''vraie rencontre'' dans une salle informatique suffisamment grande, avec de quoi boire et manger.
L'événement devra être ''bien préparé'' pour être une réussite :
* Définir les ''priorités'' : augmenter la quantité de contenus sur certains thèmes ou améliorer la qualité générale ? créer de nouvelles pages ou se concentrer sur celles qui existent déjà ? etc.
* Planifier l'''organisation générale'' : comment les participants communiqueront et se coordonneront, comment les animateurs faciliteront leur action.
* ''Préparer le wiki'' : consacrer quelques pages à l'événement avec les éléments des deux point précédents et les liens appropriés, réviser les pages du wiki qui seront utilisées pendant la session (aide en ligne...)
* ''Faire connaître'' l'événement de manière à y attirer le plus de participants possible.
Le moteur de wiki utilisé doit pouvoir gérer les ''conflits d'édition'' sans difficulté, car l'édition simultanée des mêmes articles sera fréquente pendant la session et ne doit pas générer une perte de contenu ou une surcharge de travail pour fusionner des versions.
Une fois l'opération terminée, il est important de ''capitaliser'' :
* sur ses réussites : mettre en valeur la ''satisfaction'' des participants (en citant leurs réactions) et les ''résultats concrets'' sur le wiki (avec quelques statistiques).
* sur ses échecs : inciter les participants à contribuer sur une page d'évaluation dans le wiki, détaillant les ''points à améliorer'' pour la prochaine session.
Afin de ne pas perdre la dynamique engendrée, il peut être utile de proposer des espaces sur le wiki pour ''poursuivre'' les réflexions ou les projets qui auront pu émerger, et de commencer sans attendre à préparer la ''session suivante''.
L'adoption d'un wiki dans une organisation se propage de façon ''virale'', au fur et à mesure que les utilisateurs l'utilisent comme ''moyen de communication'' avec leurs collègues. Le processus ''prend du temps'' car il est généralement freiné par des obstacles (résistance au changement, rivalités internes, etc.) Peu à peu, les nouveaux utilisateurs réalisent qu'il s'agit d'une façon efficace de collaborer, et abandonnent progressivement leurs anciennes méthodes de travail.
Ainsi, le seul moyen de populariser un wiki à long terme est d'en faire ''un outil pratique'' proposant un ''contenu de qualité'', non disponible ailleurs. Les pages les plus visitées sont généralement celles qui sont utiles au quotidien (annuaire téléphonique...) ou qui ont une dimension informelle (photos d'événements...)
Mais la meilleure manière d'attirer rapidement de nouveaux utilisateurs est la plus directe : l'''invitation par des collègues'' à contribuer au wiki.
!! Comment inviter ?
Plus l'invitation est ''personnalisée'', plus elle est efficace. Une ''discussion'' de vive voix a plus d'impact qu'un appel téléphonique, qui lui-même est préférable à un e-mail. Dans ce dernier cas, un message personnel envoyé par une personne que l'on connaît vaut mieux qu'un envoi en nombre impersonnel. La discussion doit partir des ''attentes'' du futur utilisateur vis-à-vis du wiki et amener à réfléchir à la façon dont il peut l'''intégrer'' dans son quotidien, sans aborder les aspects trop techniques.
Pour amener la personne sollicitée à contribuer, il faut lui ''faciliter'' la tâche par tous les moyens possibles :
* en lui suggérant des ''éléments concrets'' à apporter au wiki dans son ''domaine de spécialité'' ;
* en l'impliquant ''progressivement'', par petites étapes : commentaire, correction d'un texte, ajout d'une information...
* en lui fournissant des liens vers les ''ressources'' dédiées aux débutants (tutoriels, pages d'aide simplifiées...) ;
* en lui proposant un ''accompagnement'' pour ses premiers pas, en présence ou à distance.
On veillera cependant à ne pas ''lasser'' les futurs utilisateurs par une promotion excessive ou inappropriée.
!! Qui inviter ?
Dans la phase de lancement du wiki, il faut ''cibler en priorité'' les personnes :
* ''intéressées'' par le wiki ou susceptibles de le devenir ;
* ''influentes'' et en contact avec beaucoup de gens au quotidien, sans forcément avoir une position hiérarchique élevée ;
* ''comprenant'' bien le fonctionnement de l'organisation et comment l'information y circule.
Par la suite, lorsque l'usage du wiki devient courant dans l'organisation, ce sont les ''récalcitrants'' qu'il faut réussir à convaincre, avant qu'eux-mêmes ne dissuadent leurs collègues.
!! Quand inviter ?
Pour éviter d'agacer un contributeur potentiel, il est préférable de ne pas le relancer ''trop souvent''. Il est donc important de bien choisir pour chacun le moment optimal de l'invitation.
De fait, les utilisateurs ont tendance à considérer la contribution à un wiki comme une tâche non prioritaire, éternellement remise au lendemain. Il faut alors voir l'invitation comme un ''événement déclencheur'' pour les procrastinateurs, lorsque toutes les conditions sont réunies par ailleurs pour qu'ils contribuent. Notamment, il est préférable qu'ils aient :
* déjà ''consulté'' des documents sur le wiki ;
* perçu l'''intérêt'' d'y participer (les motivations peuvent être variées) ;
* ''entendu'' parler autour d'eux ou vu sur le wiki des contributeurs avec qui ils peuvent s'identifier.
L'expression "publication signée" est utilisée dans cet hyperlivre pour désigner toutes les formes de publication autres que les wikis. Il s'agit des livres, des blogs, des forums, des lettres et de tout écrit dans lequel le ou les ''auteurs'' d'un article sont identifiés et ont une importance.
L'importance donnée à "la personne qui écrit" est cependant plus ou moins grande selon le type de publication signée. Dans un ''message'', par exemple, la première personne est souvent utilisée (ou implicite), alors qu'un ''article'' est davantage centré sur le sujet que sur l'auteur.
Un wiki est un site (web ou intranet) qui facilite la [[collaboration|Les wikis facilitent la collaboration]] et le ''partage du savoir'' en privilégiant la ''simplicité d'utilisation''. Dans un wiki, les utilisateurs contribuent sur les ''mêmes pages'' et les [[connectent|Les wikis facilitent la structuration de l'information]] les unes aux autres par des liens ''hypertextes''. L'information est ainsi ''mise à jour'', [[organisée|Les wikis facilitent la structuration de l'information]] et ''disponible'' en permanence pour les utilisateurs, au lieu d'être enfouie dans des fichiers, des boîtes e-mail, des archives de forums ou des bases de données fermées.
Dans un wiki, la modification d'une page est simple et ''immédiate'', sans les [[contraintes|Les wikis permettent une communication asynchrone]] posées par les processus habituels de rédaction et de publication collectives.
Une grande liberté peut être laissée aux utilisateurs en toute sécurité, car chaque page conserve un ''historique des modifications'' et il est facile de rétablir une version précédente. Par ailleurs, des outils sont mis à disposition pour ''surveiller'' les pages sensibles.
Bien que les wikis les plus connus soient des ''sites publiques'' (tels que [[Wikipédia|http://wikipedia.org]]), les wikis sont utilisés par de nombreuses organisations comme ''outils d'intranet''. Les moteurs de wikis actuels offrent d'ailleurs tous des fonctionnalités utiles pour un usage interne, comme une gestion granulaire des droits d'accès.
<<gotoTiddler>><<search>>
Le présent //hyperlivre// est une ''synthèse'' des expériences de l'auteur et de ses recherches sur le web. Les idées énoncée sont toutes issues d'une pensée ''collective'' émergeant de centaines d'articles et de discussions disséminées dans des wikis, des blogs et leurs commentaires. Il serait donc illusoire d'en rechercher les origines.
Quelques points de départ vers de nombreux exemples et réflexions sur les wikis (tous en anglais sauf le premier) :
* http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil : les [[pages méta|Entretenir des pages méta dans un wiki]] de l'encyclopédie Wikipédia en français.
* http://en.wikipedia.org/wiki/Wikipedia:Community_Portal : [[pages méta|Entretenir des pages méta dans un wiki]] de la version anglaise.
* http://meta.wikimedia.org : [[pages méta|Entretenir des pages méta dans un wiki]] de la fondation Wikimédia qui gère plusieurs projets basés sur des wikis, dont Wikipédia.
* http://en.citizendium.org/wiki/CZ:Home : [[pages méta|Entretenir des pages méta dans un wiki]] de Citizendium, un nouveau projet d'encyclopédie lancé par un des fondateurs de Wikipédia.
* http://blog.citizendium.org : le blog de Citizendium.
* http://www.wikipatterns.com : un wiki sur les bonnes pratiques dans les wikis, notamment sur les intranets d'organisations.
* http://www.ikiw.org : le blog de l'initiateur de Wikipatterns.
* http://blogs.atlassian.com/news : le blog collectif d'Atlassian, proposant un wiki d'entreprise sous licence propriétaire.
* http://many.corante.com : un blog collectif sur les logiciels sociaux (rechercher les articles contenant le mot //wiki//).
* http://en.wikipedia.org/wiki/List_of_wikis : exemples innombrables de wikis publics. Les wikis d'intranet sont par nature cachés, mais de nombreux wikis à usage d'organisation sont accessibles sur la Toile, notamment pour coordonner le développement de logiciels libres.
Pour stimuler la contribution à un wiki, les animateurs doivent avant tout la ''faciliter'', en éliminant tous les freins à la participation :
* imposer le ''minimum de règles et de structure'' et faciliter la réorganisation du contenu ;
* autoriser les usages du wiki ''non planifiés'' et non professionnels (par exemple, pour les loisirs au sein de l'organisation) ;
* encourager les ''micro-contributions'' (écrire quelques mots, reformuler une phrase, déplacer des lignes...) : l'engagement volontaire est très souvent progressif, comme le savent bien les commerciaux ;
* ''ensemencer'' les pages : si les utilisateurs sont intimidés par des pages blanches, ajoutez-y quelques phrases ou quelques titres leur indiquant par où commencer, à la façon d'un échafaudage ;
* éviter que quelques animateurs ou utilisateurs ''trop zélés'' ne règnent sur le wiki en intervenant partout ;
* ''simplifier'' l'interface : l'apprentissage doit pouvoir se faire sans manuel ni formation pour la majorité des utilisateurs ;
* veiller à une bonne entente entre les utilisateurs : promouvoir des relations ''cordiales'' en toutes circonstances et ''résoudre les conflits'' liés au contenu en faisant intervenir des médiateurs (les plus neutres possible) ;
* ne pas stigmatiser les ''erreurs'' et les utilisations perçues comme incorrectes, voire contre-productives ;
* identifier les ''blocages'' peu visibles (tels que la réticence à modifier les contenus ajoutés par quelqu'un d'autre, ou les craintes liées à la hiérarchie) et prendre des mesures concrètes pour les résoudre.
D'autres moyens permettent d'orienter les efforts des utilisateurs et de promouvoir les bonnes pratiques :
* [[Encourager la co-rédaction des articles|Encourager la co-rédaction des articles dans un wiki]].
* [[Entretenir des pages méta dans un wiki]].
* [[Encourager les pages personnelles|Encourager les pages personnelles dans un wiki]].
* [[Organiser des sessions d'édition collectives|Organiser des sessions d'édition collectives dans un wiki]].
Je suis consultant-formateur indépendant en wikis, outils de collaboration et de gestion de la connaissance. J'interviens sur la mise en place de plates-formes collaboratives, à Paris et en province, auprès d'entreprises, d'administrations et d'organisations de l'économie sociale.
!! Conseil
* stratégique : étude des besoins, conception du projet dans toutes ses dimensions ;
* opérationnel : rédaction du cahier des charges, planification de la mise en oeuvre ;
* technique : choix de la plate-forme logicielle et du prestataire, assistance à la maîtrise d'ouvrage.
!! Formation
Accompagnement des animateurs de la plate-forme collaborative pour en stimuler l'utilisation, coordonner les contributions des utilisateurs et diffuser les bonnes pratiques.
<br>==vianney@czo-org.com==
==N'hésitez pas à me contacter pour me demander conseil.==
©2007 Vianney Stroebel