jeudi, mai 3 2012

Motiver les participants d'un projet wiki: l'influence des rôles

Pour avoir vu fonctionner (ou ne pas fonctionner) un certain nombre de projets wiki depuis 2002, je réalise que l'influence des rôles tenus par les participants d'une plateforme wiki est souvent négligée, en particulier au sein des wikis "privés". Attention, je ne parle pas des statuts, qui donnent droit à un titre, à des responsabilités et accès à des outils techniques particuliers tel que le statut d'administrateur. Par "rôles", j'entend des types de tâches dont va s'occuper un participant, soit parce que cela lui a été imposé, soit qu'il se les est appropriées de lui même.

Le problème de bon nombre de wikis gérés par des entreprises est qu'ils ne présentent souvent que deux types de rôles.

  • le rôle de l'expert contributeur (c'est le salarié auquel on demande d'apporter des connaissances expertes métiers
  • et le rôle de l'animateur jardinier, qui fait tout le reste : le débugage, l'accueil des nouveaux, la formation, l'architecture de navigation, le petit nettoyage quotidien et j'en passe (c'est le salarié qui s'est vu attribuer cette mission au sein de l'entreprise)

Force est de constater que dans de nombreux cas, cela ne fonctionne pas très bien. L'animateur-jardinier se plaint d'être débordé et de tout faire (avec plus ou moins de succès). Quand aux experts-contributeurs, la motivation n'est pas toujours au rendez-vous et les contributions se font parfois rares. Le porteur du projet compte et recompte le nombre d'articles produits afin de mesurer le succès du projet aux nombres de fiches produites et note que ça ne marche pas bien fort. Par ailleurs, lui qui espérait "décloisonner" et susciter des relations nouvelles entre collaborateurs est assez déçu. La sauce "travail collaboratif" ne prend pas.

Voici quelques pistes de réflexion pour une autre approche.

Le rôle de l'animateur jardinier

En fait, l'erreur qui a été commise par le passé a été d'évoquer ce rôle de jardinier-animateur comme étant l'homme à tout faire, pouvant décharger les experts et leur laisser pleinement le temps de contribuer à créer du contenu expert.

En réalité, lorsque l'on observe une communauté wiki ouverte et mature, il est possible de distinguer 10 rôles différents. Mais Par exemple, un nouvel arrivant sur un projet wiki va souvent commencer par contribuer du contenu experts. Les plus actifs vont cependant avoir vite "fait le tour" et souhaiter aller plus loin. Ils vont alors s'investir dans d'autres rôles, comme l'accueil des nouveaux ou se faire plaisir en bidouillant les fonctionnalités techniques ou vont passer du temps à améliorer la catégorisation des contenus pour rendre l'expérience utilisateur plus agréable et efficace. Il est fort rare qu'un contributeur ne tienne qu'un rôle à la fois, mais leur plaisir à contribuer viendra de leur investissement pluriel. Ils vont avoir tendance à se "spécialiser" en fonction de leur disponibilité, de leurs compétences, de leurs envies, et du degré de maturité de la communauté et de leur présence au sein de celle ci.

Ceci est à rapprocher des conditions d'émergence de l'intelligence collective, qui incluent l'importance de mettre en place une structure sociale polymorphe où chaque membre prend le "lead" au fil des besoins; la cartographie des relations entre les participants se réactualise en permanence en fonction des circonstances, des expertises, de la perception de chacun, des tâches à accomplir ou des règles définies par le contrat social.

Pour autant, ce besoin de structure polymorphe est plus facile à évoquer qu'à mettre en oeuvre. Identifier les 10 rôles principaux facilite cette mise en oeuvre.

Le schéma d'Anthère

Le schéma ci dessous vise à positionner ces 10 rôles selon 4 directions.

  • A la verticale, l'axe personne/contenu souligne une spécialisation et un intérêt plus poussés vers le capital social (les autres participants ou lecteurs) ou au contraire vers le contenu proprement dit.
  • A l'horizontal, l'axe page/site souligne un focus plutôt accès sur un petit nombre d'articles ou une thématique ou au contraire une approche plus globale.

Schéma des rôles tenus sur un wiki

Le créateur expert est un participant dont l’activité consiste à ajouter du contenu expert. C’est le profil le plus “classique” et évident. Par contenu, on peut entendre du texte, mais aussi bien sûr des illustrations, des schémas, des enregistrements audios etc.

L’affineur est un participant dont l’activité consiste à remanier des pages wiki déjà existantes mais perfectibles.
Ses activités peuvent être assez diverses. Il peut s’agir de simplement corriger des erreurs typographiques, de retoucher la syntaxe, d’améliorer le style afin que l’article soit plus compréhensible et agréable à lire. Il peut aussi s’agir de restructurer le contenu pour une meilleure présentation globale, de simplifier ou au contraire compléter des points manquants, vérifier des informations ou ajouter des références.
L’affineur peut détenir une plus ou moins grande expertise sur le contenu. Même peu versé dans le sujet de la page, sa participation peut néanmoins grandement améliorer la qualité du contenu proposé. Il connait bien les règles éditoriales et sait les appliquer. Son aide est particulièrement appréciée lorsque le contributeur expert .... ne possède pas d'excellentes qualités pédagogiques ou rencontre des difficultés syntaxiques... ou ne contribue pas dans sa langue natale !

L’archiviste est un participant dont l’action consiste à améliorer la classification et l’accessibilité des contenus.
Son activité est transversale. Il imagine des modèles pour normaliser la présentation des contenus. Il les catégorise. Il participe souvent à l’amélioration de l’organisation du contenu, à travers la création de listes ou de portails thématiques ou de systèmes de navigation transverse. Il élimine les contenus redondants.
L’archiviste n’a pas forcément de compétences en matière de contenu expert (cela peut aider cependant). En revanche, il est minutieux et joue un rôle essentiel pour l’usabilité du wiki.

Le contrôleur-évaluateur est un participant dont l’action consiste à mettre en évidence les contenus manquants, incomplets, périmés ou au contraire les contenus à haute qualité afin de garantir un certain niveau de qualité au contenu global.
Il aimera mettre en place des systèmes de validation, catégoriser les contenus en fonction de leur niveau de qualité, reproduire un processus éditorial de publication. Le contrôleur-évaluateur sera aussi souvent à l’origine de la mise en place de système de concours visant à identifier le “meilleur article wiki” ou “la plus belle photo” ou “le contributeur le plus prolifique”

Le patrouilleur est un participant dont l’action consiste à suivre l’activité rédactionnelle de ses pairs afin de détecter les cas d’abus ou d’erreurs et les annuler. Eventuellement, le patrouilleur peut avoir la possibilité de protéger des pages en écriture ou bloquer des participants peu coopératifs.
Le rôle de patrouilleur a surtout un sens sur les wikis publics et largement ouverts à la participation. Il n’est pas nécessaire d’avoir une expertise sur le contenu des pages.

Le régulateur-facilitateur est un participant dont l’action consiste à observer l’activité éditoriale et les comportements des contributeurs et à proposer diverses règles et recommandations pour mieux coordonner et faciliter le processsus éditorial. Il commente souvent les règles proposées par ses pairs.
Son activité éditoriale sur les pages wiki est réduite. Il est surtout présent dans les zones de discussions. Il connait généralement les règles et processus par coeur et est incollable sur leur évolution au cours du temps. Il connait généralement bien les contributeurs et leurs compétences respectives et n’hésite pas les stimuler diversement. Selon les wikis, le “régulateur-facilitateur” peut être le “gérant” du projet wiki ou bien des personnes très impliquées et auto-nominées.

Le bidouilleur technique est un participant dont l’activité consiste à améliorer l’expérience utilisateur (lecteur ou rédacteur).
Il intervient peu sur les contenus proprement dit. Ce qui l’intéresse est plutôt d’identifier voire implémenter tout ce qui peut aider ses pairs. D’un point de vue technique, c’est souvent lui qui signale les bugs ou demande des améliorations de l’interface ou recommande l’addition de nouvelles fonctionnalités. Lorsqu’il a des compétences techniques, il aimera développer le petit outil qui facilitera la vie des autres contributeurs (outils statistiques; outils de surveillance pour les patrouilleurs etc.) et qui fera souvent de lui le héros du jour.

Le pompier médiateur est un participant qui vient en aide aux contributeurs en désaccord.
Selon les wikis, son rôle sera plutôt celui d’un arbitre qui tranche et impose arbitrairement une solution, voire des sanctions ou bien celui d’un médiateur dont le rôle est de faciliter la conversation entre protagonistes pour les aider à trouver un consensus. Sur certains wikis, il s’occupera également de la “hotline” pour répondre aux diverses demandes de lecteurs ou participants.
Il est capable de rester calme en toutes circonstances. Il connait bien les comportements requis de la part des participants par les règles de vie du wiki, ainsi que les démarches à appliquer en cas de conflit. Il a des capacités d’investigation pour comprendre les tenants et aboutissants d’un désaccord, ce qui peut impliquer des recherches. Il connait bien les participants et est capable d’identifier les racines sous jacentes des désaccords. Il est capable d’engager des conversations privées avec les participants si nécessaire et adopte un comportement discret.

L’agent d’accueil est un participant qui accueille et aide les nouveaux venus.
Il participe généralement peu à la création de contenu. Patient, amical, généreux, il aime former les nouveaux arrivants et les marrainer jusqu’à ce qu’ils soient à l’aise avec l’outil et les règles de la communauté. Il travaillera souvent à la rédaction de guide à l’usage des participants, à la création de vidéos de découverte, aux Foires aux Questions. L’agent d’accueil est tout autant nécessaire pour les wikis publics que pour les wikis privés.

Le journaliste est un participant dont l’activité consiste à documenter et reporter l’activité des participants sur le site et l’évolution du site en terme de contenu.
Il intervient peu sur les contenus proprement dits. En revanche, il est typiquement la personne qui recherche de l’information puis analyse et enfin écrit sur l’évolution du site et de l’activité des participants. Les documents produits par le journaliste peuvent être utile à la fois au sein de la communauté pour créer un esprit de corps, ou en externe pour assurer la promotion du wiki

Quelles recommandations en tirer ?

Noter avant toute chose que ces différents rôles, au delà des compétences métiers, font appel à des compétences humaines, à des savoirs-être différents. Et pas toujours compatibles. Un bidouilleur technique présente un profil social généralement très différent d'un médiateur ou d'un journaliste. Faut-il espérer que l'animateur-jardinier présente tous les profils ? Sans doute pas.

Il semble donc plus intéressant de solliciter tous les contributeurs (ceux habituellement considérés comme "experts") pour remplir ces différents rôles. Un nouveau venu dans le monde des wikis ne réalise pas d'emblée le champ des possibles. Il n'est souvent pas conscient d'être "autorisé" à faire quelque chose hors de l'ajout de contenu expert, encore moins d'être le bienvenu. Il faut donc commencer par leur parler de ces différents rôles, sans leur imposer, mais plutôt pour les aider à prendre conscience de ce qui est nécessaire pour qu'un wiki "marche".

Il faut aussi que l'animateur-jardinier soit conscient que son travail n'est pas tant de "tenir tous ces rôles" mais plutôt de "trouver les compétences adhoc pour que ces rôles soient assurés".

Enfin, il faut mesurer le succès du wiki non pas uniquement sur le nombre d'articles produits mais aussi sur l'activité des participants. Si vous mesurez actuellement l'implication de vos contributeurs par une variable du type "nombre de contributions par semaine" ou "nombre de fiches rédigées", reconsidérez.

Graphique d'évaluation des rôles sur un wikiPourquoi ne pas plutôt mettre en place un système d'auto-évaluation personnelle ? Chaque contributeur pourrait se voir donner une fiche type étoile dans laquelle il reporterait "sa" perception de ces contributions dans ses différents rôles sur une échelle de 0 à 5. On peut imaginer qu'un nouveau contributeur commencerait avec un 3/5 comme rédacteur expert et 0/5 dans les autres rôles pour progressivement évoluer vers des rôles de curation (affineur, contrôleur-valideur, archiviste) ou vers des rôles de support (accueil, bidouilleur) etc. L'avantage de cette méthode est la prise de conscience personnelle de sa propre implication.

Autre option, l'évaluation pourrait se faire en mode 360. Par exemple, chaque contributeur pourrait se voir demander d'évaluer les degrés de contributions dans ces 10 rôles de 10 participants. L'avantage de cette méthode est de pousser les participants à véritablement regarder le mode de fonctionnement d'autres contributeurs.

Ou chaque contributeur pourrait se voir demander d'identifier les 10 meilleurs contributeurs du mois dans chacun de ses 10 rôles. La compétition peut parfois être bénéfique et l'avantage de ce système est qu'elle pousse chacun à "lever les yeux du guidon" pour avoir une vue d'ensemble du wiki. Cette solution est fort probablement plutôt à choisir au sein d'une communauté mature, sollicite d'avantage l'attention des collaborateurs et peut être génante dans certains cas.

Les options sont multiples et variables: un peu de compétition ou pas. Evaluation anonyme ou pas. Auto-évaluation ou évaluation par les pairs.

Aider ses collaborateurs à s'investir dans le wiki au delà du rôle d'expert n'est pas toujours facile. Autant leur baliser le chemin au maximum.
Coté négatif: suscite parfois des réticences et requiert du temps que les participants n'ont pas toujours.
Côté positif: pousse au décloisonnement en facilitant les rencontres improbables entre "experts", souvent coincés dans leur bulle d'expertise

Et vous qui participez à un wiki, quels rôles avez vous le plus souvent tenus ?


Ajout d'un lien post publication vers un billet écrit il y a plusieurs années sur le thème du wikijardinier et de la motivation.

mardi, septembre 14 2010

Comment faire pour "tester" un logiciel wiki ?

Je donne très régulièrement des conférences au cours desquelles je présente les wikis et un exemple d'application, typiquement Wikipedia.

Une des questions que mes interlocuteurs me posent souvent à la fin des interventions est "serait il possible de tester facilement un logiciel wiki avant de l'acquérir ?" ou "à qui dois-je m'adresser pour avoir à disposition un outil wiki ?"

Plutôt que de répondre à ces questions par email à chaque fois, il me parait plus judicieux de proposer quelques offres ici-même:

Avant toute chose, pour en savoir plus sur le logiciel wiki, je vous propose de lire cet article "qu'est ce qu'un wiki".

Il faut savoir qu'il existe de très nombreux logiciels wiki,

  • certains sont open source (et téléchargeables gratuitement sur Internet), d'autres sont des logiciels propriétaires (et nécessitent d'acheter une licence);
  • certains sont très dépouillés en terme d'interface et de fonctionnalités, d'autres sont au contraire des plateformes complexes et très riches à l'usage;
  • certains sont typiquement destinés à un usage public et ne présentent pas de gestion des accès, d'autres permettent de gérer des droits d'accès extrèmement finement;

et j'en passe. Cela peut devenir extrèmement compliqué.

Si vous êtes assez familier avec les aspects techniques, je vous conseille de vous diriger vers Wikimatrix qui propose un comparatif entre les différentes fonctionnalités des logiciels wikis sur le marché.
Voir par exemple un comparatif entre Confluence, MediaWiki, PBwiki, PhpWiki, SocialText, TWiki et XWiki (je ne vous conseille pas d'installer PhpWiki, c'est plus pour le plaisir de comparer un wiki historique aux logiciels modernes).

L'autre avantage de WikiMatrix est qu'il vous permet d'accéder aux coordonnées de diverses sociétés d'installation, de maintenance et d'hébergement des applications.

Pour les autres: ceci dit, il y a toutes les chances pour que vous ne soyiez pas très à l'aise avec la technique et que le site WikiMatrix vous créé des aigreurs d'estomac. Si c'est le cas, quelques suggestions:

MediaWiki

Vous pouvez bien évidemment regarder dans la direction de mediawiki (le logiciel utilisé par Wikipedia).
Avantages

  • open source (téléchargement gratuit)
  • logiciel évolutif, plutôt prévu pour un usage public, pour un objectif de "gestion de la connaissance" (les wikis d'entreprises proposent d'autres types de fonctionnalités plus orientées "réseautage" ou "bavardage" ou "gestion de projet" ou "gestion des réunions")
  • interface traduite en de très très nombreuses langues

Comme tous les logiciels libres, vous pouvez soit l'installer sur vos serveurs, soit l'installer chez un hébergeur de sites classique. Ou bien contacter une société spécialisée pour vous seconder.

Pour "tester" facilement un wiki dérivé de mediawiki, et regarder ce qui peut être fait avec , je vous conseille de regarder vers la ferme de wiki, Wikia
Avantages:

  • création d'un wiki rapide et facile;
  • c'est gratuit;
  • l'interface est traduite en français;
  • la plateforme tourne sur une version modifié de MediaWiki, le logiciel utilisé par Wikipedia (open source et pas de dépaysement pour ceux qui utilisent déjà Wikipedia);
  • c'est directement hébergé par la société Wikia (donc aucune manipulation technique à assurer de votre côté).

Inconvénients:

  • de la publicité (c'est le modèle économique de Wikia);
  • impossibilité de faire un wiki privé;
  • la totalité du contenu publié doit être sous licence libre (pas forcément compatible avec un usage professionnel).

Pour cette raison, Wikia n'est vraiment utile que pour tester rapidemment le concept... ou pour héberger rapidemment un petit wiki associatif. Vous pouvez aussi vous promener parmi les sites hébergés par Wikia et observer les usages et les comportements.

Une autre solution, plus orientée entreprise, PBworks

Solution précédemment connue sous le nom PBwiki.

Avantages:

  • C'est gratuit pour une version de démarrage, devient payant lorsque vous demandez plus d'espaces, plus de fonctionnalités, plus d'utilisateurs (mode location mensuelle). Le prix est très raisonnable (20 dollars par employé. Les clients et fournisseurs ont un accès gratuit)
  • Tout est hébergé sur le web (et non dans l'entreprise). Ne nécessite donc pas la moindre installation de votre côté.
  • Pas de publicité
  • wiki public ou wiki privé.

Inconvénients:

  • l'interface n'est pas "localisée" (entendre "traduite". Actuellement, l'outil ne propose donc qu'une interface en anglais)

Cette solution est très utilisé par grandes et petites entreprises. C'est la plus simple à mettre en place. Le wiki est extrèmement simple d'usage.

Autre wiki d'entreprises, xwiki

Avantages

  • logiciel open source (pas de frais de licence);
  • logiciel développé par une entreprise française (contact aisé et rapide avec l'équipe de développement, support sympathique, possibilité de faire développer à façon des fonctionnalités supplémentaires);
  • logiciel développé dans une optique "entreprise".

Si vous disposez d'une équipe informatique, un de vos collaborateurs pourra facilement le télécharger et l'installer. Si vous disposez d'un système d'hébergement chez un des prestataires habituels, vous pouvez l'installer vous même (mais ce n'est pas à la portée de tout le monde).
Vous pouvez aussi le faire installer et héberger par l'entreprise xwiki SAS (auquel cas, c'est payant bien sûr):voir ici et .

Enfin, le site d'XWiki propose une solution en ferme (gratuit et site créé en 5 mn comme PBwiki)
Honnêtement, je vous le déconseille, même pour tester. La plateforme d'hébergement est hyper lente au point de générer non seulement de l'agacement mais aussi des erreurs. Testé pour vous !

Le classique des entreprises: Confluence

Avantage

  • il existe une véritable société (australienne) derrière ce wiki (possibilité de développement à façon, support etc.)
  • logiciel développé dans une optique "entreprise"

Inconvénient

  • logiciel propriétaire (donc licence à payer)

L'application peut être installé sur vos serveurs (coût à partir de 10 dollars/mois pour 10 utilisateurs) ou peut être hébergée par Atlassian (à partir de 150 dollars/mois pour 10 utilisateurs)

Bien que Confluence soit probablement le wiki professionnel le plus utilisé par les entreprises (mediawiki est également très utilisé), j'avoue ne pas être très emballée par cette solution souvent considérée comme "geeky" (c'est à dire plutôt développée avec un esprit technophile) ce qui convient à certaines populations (notamment les départements informatiques des sociétés), mais beaucoup moins à d'autres.

Autre option, hyper sociale: socialtext

Ce logiciel est développé par une société californienne, dont le Patron et co-fondateur, Ross Mayfield très sympathique et visionnaire (n'hésitez pas à visiter son blog).
Une approche très sociale contrairement à d'autres logiciels (tel que Confluence). Les tarifs commencent vers les 5000 dollars et il ne semble pas que l'interface soit traduite en français (je peux me tromper). Le logiciel ne se présente pas véritablement comme un wiki, mais plutôt comme une plateforme sociale complète proposant toute une collection d'outils (réseau social, microblogging, blog etc.). Il est possible de tester la plateforme en ligne gratuitement.

Personnellement, j'ai un mediawiki en usage totalement privé chez mon hébergeur, et j'utilise de temps en temps PBwiki.

Finalement...

Le choix final d'une solution doit être réfléchi. En fonction des fonctionnalités souhaitées, des besoins en confidentialité, de la nécessité ou non de gérer de complexes droits d'accès, certains wikis sont plus appropriés que d'autres.

Mais avant d'en venir à tout mettre en place, beaucoup souhaitent simplement "voir comment marche ce truc". Dans cet objectif, mon conseil personnel serait PBworks.

Florence

PS: si vous avez des remarques, des infos à ajouter ou des corrections, n'hésitez pas à me le signaler
RePS: je ne travaille pour aucune de ses sociétés

vendredi, juillet 23 2010

"What Working for Wikipedia Taught Me About Collaboration" de Sandra Ordonnez

Sandy ("wikiblue") était la première "Head of Communication" (salariée) de la Wikimedia Foundation lorsque celle-ci était encore à St Petersburg (Florida), embauchée par son premier directeur, Patrick Bradford. Elle a quitté la Wikimedia Foundation lorsque les locaux de cette dernière ont été déménagé à San Francisco. J'étais présidente de la Wikimedia Foundation à cette époque, et je garde un excellent souvenir de Sandy (avec laquelle je suis toujours en contact épisodique sur le fameux Facebook).

Dans un savoureux article publié sur pbs.org, elle nous relate son expérience en tant qu'employée de la Wikimedia Foundation.

At that time, Wikipedia's internal structure did not match the widespread success and attention it was beginning to enjoy. I found myself working in a thrifty "rent-by-the-month" office building with three other employees: An administrative assistant, a fundraiser/hardcore Wikipedian, and a CFO. I was told that most tasks, including the communication projects, were carried out by a large network of international volunteers.

Elle rappelle avoir commencé à travailler pour l'organisation, dans des locaux assez "cheap". Il s'agissait d'environ 4 à 5 pièces louées dans un de ses batiments réservés à l'hébergement de petites sociétés, typiquement assurances et autres travailleurs indépendants), en compagnie de trois autres employés. Bizarremment, elle a oublié un des salariés également présents dans les locaux de St Petersburg. Le Directeur, Brad Patrick, qui tenait aussi le rôle de Chief Legal Officer. Bon, la mémoire joue toujours des tours... mais il s'agissait tout de même de son "chef"... Ceci est peut être un bon signe de la confusion qui régnait à l'époque :)

I immediately began to review the public relations materials available to me, and almost immediately went into panic mode. There was no polished press kit, press list or, dare I say, communication strategy. In fact, the majority of individuals on the communications committee had little to no public relations training, and were more intellectual and techie than the average PR practitioner at that time.

Tout à fait. Et c'est encore largement le mode de fonctionnement des associations locales Wikimedia... A compter de l'arrivée de Sue Gartner comme nouvelle directrice, il sera souvent fait appel à des intervenants extérieurs pour "entrainer" les salariés et les membres du conseil d'adminstration sur divers points. Je me rappelle un "media training workshop" tenu par Ruth-Ellen Soles (communications consultant et anciennement CBC spokesperson), pour nous former à mieux répondre à la presse. A ce jour cependant, la majorité des bénévoles répondant à la presse demeurent sans aucune formation.

A few weeks into the job, with little training and a very primitive understanding of the wiki ethos, I encountered my first PR crisis. A hardcore and well known Wikipedian, Essjay, had lied to the New Yorker about his credentials. Not surprisingly, the years of crisis communication training I received was useless in the context I found myself in. For a brief moment, I honestly thought that my career as a PR specialist had come to an end. The New Yorker, in my mind, was the bible of the media world; there was no way that our online encyclopedia was going to survive the PR damage.

In the midst of my concerns, I soon became a believer in the power of collaboration. That crisis was the moment when the new media landscape unfolded before my eyes.

The volunteers took charge. They created a Wikipedia entry that documented the event in gruesome detail. It was honest, direct and, amazingly, had no PR spin. In fact, for most Wikipedia members, the biggest concern was that Essjay had used his false credentials in content disputes. It was apparent to me that there was never any malice or hidden agenda. Essjay himself had revealed his real credentials on his user profile when he was hired by Wikia, a company owned by Wikipedia founder, Jimmy Wales. In fact, in the months that followed, I found the community became self-correcting by encouraging the use of real names and identities. It found a way to help prevent this type of issue from happening again.

Quelques semaines après son arrivée à ce poste, Wikipedia a connu un scandale important: un wikipedien de longue souche, étudiant dans la vraie vie, avait prétendu pendant longtemps être un professeur et utilisé cet argument pour avoir plus de poids dans certaines discussions portant sur le contenu dans Wikipedia. Un exemple classique de "Appeal from Authority". Mais il avait fait encore pire... interviewé par le New York Times, il a eu la bétise de se présenter sous la casquette de ce professeur, alors même que devenu salarié de Wikia, il avait révélé sa véritable identité à ses collègues de travail. Le retour de baton ne s'est pas fait attendre et pendant plusieurs jours, le téléphone de la Wikimedia Foundation n'a cessé de sonner. La presse s'est déchainée. J'ai aussi souvenir de longues discussions internes sur la façon dont nous devions réagir. Il n'est pas peu dire que nous étions vraiment non préparées à réagir à un tel scandale et j'imagine sans peine le stress dont Sandy a été victime.

Et puis finalement, ce ne fut pas le seul scandale qu'a vécu Wikipedia. Et aucun n'a vraiment réussi à ralentir sa course. A vrai dire, les scandales ont souvent plutôt comme conséquence l'arrivée de nouveaux participants.

Sandy en a tiré quelques leçons qu'elle partage avec nous, et qui peuvent être étendues à tous les usages de wikis:

Trust the Crowd; Its Smarter than You -- The sooner you trust the group and empower it, the sooner it can produce high quality results. The group can make up for any weaknesses you may have as an individual. The idea is to bring out the strongest skills and downplay the weakest in each person.

Diversity and Creativity Are Intrinsically Connected -- Creative brainstorming is significantly improved by diversity. Individuals not only challenge each others' ideas, but they also inspire each other as well.

Collaboration is Messy -- When Jimmy Wales said "Wikipedia is like a sausage: you might like the taste of it, but you don't necessarily want to see how it's made," he wasn't kidding. Chaos, in many ways, seems to be the spark of great collaborative endeavors.

Be Open to Receiving and Giving Criticism -- When working collaboratively, it is important to let go of your ego. Learn to not take things personally and be honest about what you think without being disrespectful.

Celui qui me semble le plus important a répéter est probablement celui qui souligne que la collaboration n'est pas chose facile et qu'il faut s'attendre à devoir "mouiller le maillot". Bien loin d'être un monde de bisounours, les plateformes wikis sont souvent le théatre de conflits. Le wiki fournissant un environnement transparent, les désaccords deviennent visibles à tous. On est pas d'accord et on se le dit. Le désaccord ne reste pas cantonné à deux personnes, il peut s'étendre, chacun voulant ajouter son grain de sel. Entre ceux qui ajoutent de l'eau au moulin du débat, ceux qui essayent de jouer un rôle de médiateur, et ceux qui se posent en arbitres prêts à prendre la décision à la place des autres, le wiki devient vite un lieu assez chaud, révélateur de tensions non-dites et de conflits larvés. Les conversations se croisent, s'entremèlent, les insultes fusent parfois, de nouveaux groupes d'intérêts se créent, des cabales se rèvent. Mais c'est de cette foultitude de discussions bigarées que peut naître une solution plus innovante que toutes les solutions précédemment imaginées et que des relations plus complices se nouent.

Il faut accepter l'existence des désaccords publics sur un wiki, en essayant de se souvenir que c'est de ce foutoir qu'émerge la créativité et que la seule chose qu'il faille exiger est le respect des personnes impliquées. On peut critiquer l'idée et la position, mais pas s'attaquer à la personne.

Loin de moi l'idée de dire que le conflit n'existe pas dans les entreprises, mais il est souvent plus caché derrière les portes, murmuré et incrusté dans les non-dits. Ce refus d'oser exprimer un désaccord en public est probablement une des raisons principales pour lesquelles les wikis sont difficilement adoptés en entreprise.

L'article de Sandy, salariée, relatant sa découverte d'une communauté wiki.

jeudi, mai 27 2010

Publication d'un ouvrage sur le logiciel MediaWiki

Mes clients me demandent souvent de leur indiquer livres, blogs, sites web pouvant leur apporter une meilleure connaissance des logiciels wikis et des principes de fonctionnement des communautés wikis. Voici un livre tout juste sorti des presses, en anglais.

MediaWiki 1.1: Beginner's Guide Summary:

  • Ecrit par Jeff Orloff
  • Number Of Pages: 356
  • Publication Date: 2010-04-10
  • ISBN-10 / ASIN: 1847196047
  • ISBN-13 / EAN: 9781847196040

Le logo de MediawikiPour rappel, Mediawiki est un moteur de wiki open source. Il est développé par une communauté très active, et est utilisé par de très nombreux sites wikis très populaires, parmi lesquels Wikipedia. Ecrit en PHP, il présente de nombreuses fonctionnalités qui permettent son utilisation dans de multiples circonstances: wikis publics, wikis privés. Il est particulièrement bien adapté pour les usages "construction et gestion de grosses bases de connaissances".

Le livre s'adresse surtout aux futurs administrateurs du site wiki (web designer, administrateur système, programmeur, éventuellement community manager).

Voir http://ebook30.com/internet/internet/211164/mediawiki-1.1-beginner039s-guide.html

PS: pour ceux qui remarqueraient la ressemblance entre mon logo et le logo de Mediawiki... oui, ce n'est pas fortuit. Je suis co-auteur de ce logo avec Erik Moeller (j'ai fourni la fleur) et nous avons tous deux choisi de mettre ce logo dans le domaine public (étonnant pour un logo, hein?)

mardi, mai 4 2010

LIFT 2010 et redécouverte du Vjing

Demain, à l'heure où blanchit la campagne (non, en fait beaucoup plus tôt que cela), je vais quitter une Auvergne glaciale et trempée pour aller voir si le temps est meilleur du côté de Genève. Prudente, je vais emmener mon manteau d'hiver, des chaussettes de laine et une couverture de survie (on ne sait jamais, les monts du Forez pourraient être couverts de neige la nuit prochaine....). Bref, je vais assister pour la troisième fois à LIFT.

Cette année, LIFT a choisi de s'organiser avec workshop le matin et conférences/débats/tables rondes l'après-midi. Succès et taille des salles obligent, les workshops sont soumis à inscription. J'ai choisi de pratiquer la technique qui m'a été enseignée à Davos, ne pas oublier d'assister à des interventions hors des sujets auxquels l'on est habitué (voir choisir un thème pour lequel on est parfaitement néophyte) afin de quitter sa zone de confort et ouvrir son esprit à d'autres expériences. Dont acte...

J'ai donc choisi les trois workshops suivants:

  • VJing – from software to public space
  • iDemocracy! Do you? Open Voting and Tribe oriented Public Debate
  • Hacking Venture Capital

200px-HelsinkiVG4.jpgLe premier workshop (au sujet du VJing, le VJ ou Video Jockey, est une personne qui est à l'origine d'une animation visuelle projetée sans plus d'indications sur les techniques utilisées ou les choix graphiques effectués) évoque un thème dans lequel j'ai peu d'expérience, mais dans un contexte très connu :) (yeah ! Wikipedia !).

En fait, ma seule expérience relative au VJing remonte à ma participation à PixelAche en 2005 (Helsinki), festival de créations électroniques dont j'ai gardé de très nombreux souvenirs (ébahis) et ramené quelques (moches) images illustrant l'article actuel.

Ce qui est particulièrement intéressant est que le workshop fait en réalité parti d'un ensemble d'activités visant à produire un BON article sur le VJing dans Wikipedia. Il faut reconnaitre qu'il y a du travail. J'espère qu'ils ne vont pas juger les modestes photos prises en 2005 à PixelAche trop trop ridicules :) (si, probablement)

Le site web de l'initiative WikiSprint

dimanche, mai 2 2010

Réhabiliter les "délinquants" numériques

Je suis peut être un peu provocatrice avec ce titre mais j'observe qu'on a vite fait de traiter de "délinquant" ou de "vandale" un internaute un peu "noob" (un nouvel arrivant sur la toile), pas encore au fait des pratiques acceptables et des pratiques inacceptables.

Please bite the newbie

J'ai été assez surprise il y a quelques semaines, de recevoir un courriel de la part d'un de mes cousins, B.
(je n'indique que l'initiale non pas pour conserver son anonymat, mais pour éviter la mémoire de Google).

B. approche de la cinquantaine. Il a un long passé dans la haute finance. Une formation initiale à l'ESCP Europe. Des années d'expérience chez diverses grandes institutions de la finance. A la fin des années 90, il a aussi tenté l'aventure de la création d'entreprise (sans succès malheureusement). Il travaille aujourd'hui comme consultant pour une grande banque et est spécialisé dans les fameuses "subprimes". En bref.... un sénior, un spécialiste dans un secteur de niche, détentaire de savoirs qui ne courent pas les rues.

Pour tout wikipédien digne de ce nom, c'est un éditeur potentiel à chouchouter....

Tout début 2010, B. décide de faire ses débuts sur Wikipedia. C'est un utilisateur convaincu et il perçoit que ses connaissances propres peuvent apporter un plus à l'encyclopédie écrite par les internautes. Il faut dire que la section "finances" est tout de même assez mal lotie.

Bref, B. choisit un sujet qu'il connait bien, et crée un article sur une des sociétés dans lesquelles il a travaillé dans le passé, la société E. La société E. est un éditeur spécialisé dans les progiciels pour salles de marché; elle fusionne avec une autre société il y a quelques années, et les logiciels qu'elle maintenait et développait sont repris dans le cadre d'une nouvelle société née de la fusion. Au moment de sa fermeture, la société E. emploi tout de même 400 personnes.

B. se lance donc dans l'aventure wikipédienne. Il créé la page sur la société E. de façon anonyme (sous adresse IP) dans un premier temps. De son propre aveu, la première version de l'article est assez médiocre (pas de problème de neutralité majeur, mais une mise à page minimaliste, une approche assez historique - logique puisque la société a disparu, et bien sûr pas de sources). En toute honnêteté, pour avoir vu la création de très nombreux nouveaux articles, l'article a ses débuts est tout de même de bien meilleure qualité que la moyenne.

13 minutes après la création de l'article sur la société E., ce dernier est blanchi (motif: contenu promotionnel; assez amusant lorsque l'on songe que la société a disparu en 2002)

Wiki VampiresB. crée alors un compte utilisateur et restaure l'article, avec le sentiment d'avoir fait une erreur de manip en perdant le contenu de l'article. A partir de là, tout s'enchaine. L'éditeur ayant blanchi l'article appose alors un bandeau "page à supprimer" (2 minutes après la restauration) que B. retire en ne comprenant pas d'où il vient, et ce à plusieurs reprises. B. reçoit alors un message sur sa page utilisateur, lui apprenant qu'il est un "vandale averti". Aujourd'hui encore, la page de discussion de B. ne contient essentiellement que le texte "standard"(automatisé) d'accueil des nouveaux, plus les diverses mentions relatives à son "vandalisme".

En visitant la page de proposition à la suppression, B. découvre que l'argument principal avancé est qu'il s'agit d'un article promotionnel, mais aussi que la société (de 400 personnes) n'a aucune notoriété sur Internet.

Une heure après la création de son premier article, B. appose un message sur sa page de discussion (déjà ornée de messages peu chaleureux),

''Aidez-moi
Je ne comprends pas pourquoi remplacer une version d'un texte que j'ai créé moi-même par une version légèrement retouchée me vaut d'être qualifié de vandale. Je n'ai toujours pas compris ce qu'on attendait de moi pour valider cet article.''

__Son appel à l'aide ne recevra aucune réponse... __ A ce stade, l'utilisateur lambda laisserait probablement tomber. Heureusement, B. n'est pas un utilisateur lambda, c'est mon cousin :)
soir là, il m'envoie un email, très sobre:

''Salut Florence et bonne année !

J'ai voulu créer un article mais je ne comprends rien aux messages que je provoque. Je ne sais même pas si j'ai provoqué fortuitement une demande de suppression ou si elle a été demandée par quelqu'un d'autre. Peux-tu m'aider?

Je t'embrasse, B.''

J'ai donc pris un peu de temps pour regarder ce qui s'était passé, lui expliquer sur sa page de discussion, et le conseiller sur la suite des évènements par email.

Deux jours après, B. créé un deuxième article, qui est à nouveau listé sur les pages à supprimer, pour motif "tentative de contournement de la demande de suppression du premier article écrit par cet utilisateur". Dans la plus pure tradition wikipédienne, cela relève de "Assume good faith". Ou plutôt le contraire ?

Finalement, les deux articles ont été conservés.

Mon objectif n'est en aucune façon de porter un jugement sur l'admissibilité ou non de cet article - j'ai la modestie de penser que je n'y connais vraiment rien du tout en logiciels de gestion financière. Je regrette un peu que des personnes ignardes sur ce sujet s'estiment être capables de juger ou non de la notoriété d'un produit ou d'un service spécialisé, mais j'admet le fait que notre modèle éditorial permet difficilement d'éviter ce travers.

En revanche, je suis assez déçue de la façon dont un nouvel arrivant est accueilli, alors que ce nouvel arrivant

  • n'est visiblement pas un chargé de com ayant reçu comme mission de faire la pub de sa société
  • est poli
  • s'exprime en des termes appropriés
  • montre visiblement une expertise sur un sujet assez mal traité sur l'encyclopédie

Conserver mais travailler la NPoV

Honnêtement, je me serais attendue à ce que mon cousin arrête là son expérience de participant à Wikipedia.

Et bien non !

Le week-end dernier, B. est passé déjeuner à la maison. Bien sûr, nous avons évoqué son expérience malheureuse de "vandale averti" (il n'est visiblement pas près d'oublier ce label, même s'il en parle avec un grand sourire paisible). Et à ma grande stupéfaction, B. s'est accroché. En dépit du caractère extrèmement inamical de ses premiers contacts sur le projet, il est devenu un wikipédien ! Il a évoqué avec un peu d'auto-dérision le fait que son premier article était vraiment loin d'être parfait, mais qu'il avait désormais beaucoup appris et travaillait à améliorer le contenu. Très fièrement, il m'a même annoncé qu'il faisait partie du "projet finances".

J'avoue en être restée sidérée. Je suis allée jeter un coup d'oeil sur ses contributions.... Voici la modification qui m'a convaincue :)

# {{Conserver}} mais travailler la NPoV.

Recruter des nouveaux, conserver les anciens, analyser les départs

Au delà de cette expérience vécue, il faut savoir que le taux de nouveaux arrivants sur Wikipedia stagne voire décroit (selon les langues) depuis 2008. Cela a été mentionné à moult reprises, voir par exemple ce blog sur Infodisiac à ce sujet. Plusieurs hypothèses ont été avancées, parmi lesquelles les quatre me semblant les plus solides sont:

  • pour les langues les plus développées, comme la wikipédia en anglais, en allemand ou en français, la difficulté à participer en raison de la quantité et de la qualité de l'information déjà disponible sur Wikipedia;
  • le développement majeur des réseaux sociaux type Facebook depuis début 2008 (j'ai pu observer que les anciens wikipédiens eux-même passent un temps non négligeables sur ces réseaux sociaux, temps qui pourrait être consacré à écrire ou améliorer un article;
  • la difficulté technique à éditer le projet (le logiciel n'étant pas des plus user-friendly)
  • les relations sociales parfois dégradées entre éditeurs (et en particulier un accueil des nouveaux assez peu chaleureux, comme mon cousin a pu en faire les frais)

La Wikimedia Foundation et les associations locales comme Wikimedia France travaillent activement sur le sujet de la stagnation voire la diminution des nouveaux arrivants. Dans cette optique, un sondage a été réalisé auprès de 1200 personnes ayant participé à Wikipedia, puis abandonné, afin d'identifier les raisons de l'abandon.

Les résultats peuvent être trouvés ici

Le fichier attaché à ce blog donne des résultats un peu plus détaillés que ceux sur les pages listées ci-dessus.

lundi, avril 26 2010

Un wiki public hébergé par la ville de Clermont Ferrand

C'est par Emilie Ogez (xwiki), elle-même en relai de lamontagne.fr que j'ai découvert ce matin l'ouverture d'un "wiki" de consultation pour le futur aménagement de la place du Mazet.

Dixit lamontagne.fr:

Les administrés de Clermont-Ferrand proposent depuis peu aux internautes (en particulier les internautes Clermontois, puisqu'ils sont les premiers concernés) de proposer des projets d'aménagement pour la place du Mazet.

Un projet qui a pour but de donner la parole aux Clermontois et de les impliquer davantage.

L'article de lamontagne.fr : http://twurl.nl/38jbmu

Le wiki concernant la place du Mazet : http://www.clermont-ferrand.fr/mazet/index.php/Accueil


Wiki ville de Clermont Fd Mazet

Je viens de le visiter rapidemment et je suis ravie. Tout d'abord, le wiki tourne sous MediaWikile logiciel utilisé par Wikipedia), dont l'interface a été très agréablement relookée aux couleurs de la ville et surtout simplifiée pour l'utilisateur. Tout au plus pourrait-on se plaindre de ce que la barre d'édition soit un peu minimaliste (impossible de faire des listes ou des titres). Les utilisateurs avancés de mediawiki ne seront pas troublés, mais les nouveaux utilisateurs risquent d'être un peu étonnés de ses limitations.

La page d'accueil est certes protégée (ce qui est tout à fait raisonnable), en revanche, le reste du wiki est ouvert à partir du moment où un compte a été créé (seules entrées obligatoires, "nom d'utilisateur" et "mot de passe"). Le log des modifications récentes n'a pas été discrètement caché (comme cela se produit parfois malheureusement). Donc bien.

Du côté noir de la force, une petite boulette fonctionnelle: l'utilisateur lambda n'a pas le droit de créer de nouvelles pages.... Dans l'espace rédactionnel "principal", ce n'est pas forcément dramatique. En revanche, ne pas pouvoir "ajouter de commentaires" car l'on est pas autorisé à créer une page de discussion, c'est un peu couillon quand même.... Mais bon, ce n'est qu'erreur de jeunesse. Souhaitons bonne vie à ce joli nouveau wiki !

mercredi, juin 4 2008

De la motivation...

Depuis que j'ai décidé d'utiliser ma passion pour les outils du web collaboratif pour évoluer dans la sphère professionnelle, je m'interroge doublement sur les aspects de motivation, chez l'adulte en particulier.

L'usage d'un wiki s'est révélé particulièrement réussi pour la construction d'une encyclopédie telle que Wikipédia, mais l'usage des wikis dans le monde de l'entreprise et des collectivités est encore très peu répandu (en particulier en France). Pour autant, il est intéressant d'analyser les facteurs limitants à la mise en place de ce type d'outil. En général, les usagers du wikis s'accordent pour dire que la mise en place technique d'un wiki n'est pas un problème. Toute équipe informatique est parfaitement capable de le faire, la principale question technique étant généralement "quel wiki" (il en existe de très nombreux, voir l'excellent site de comparaison Wikimatrix).
Plus souvent, la limitation dans l'adoption est tout simplement due au manque d'information, beaucoup s'imaginant qu'un wiki ne peut être utilisé QUE pour créer des encyclopédies (à l'image de Wikipédia), ou d'autres s'imaginant qu'un site wiki ne peut marcher qu'à la condition d'avoir une communauté d'au moins une centaine de personnes. Pour ceux là, les priorités sont de leur présenter les différents usages du logiciel (gestion de projet, création de documents en commun, préparation de réunions etc...) et leur citer des exemples de réussite de wiki plus modestes en taille que Wikipedia.

Mais en réalité, pour tous ceux qui ont 1) réalisé l'intérêt potentiel de l'outil wiki et 2) une équipe informatique capable d'en assurer la mise en place et la maintenance, la plus grande difficulté est en fait de faire vivre, se développer le site wiki. Il existe plusieurs facteurs pour assurer la réussite du projet et parmi ceux ci, le facteur motivation.

Même sur le plus grand wiki du monde, disposant probablement de la plus grande communauté collaborative sur internet, je suis régulièrement confrontée à cette problématique de la "motivation". Pas plus tard qu'il y a deux jours, je convie les wikipédiens français à venir participer au wiki des Assises du Numérique, opportunité unique de relayer nos besoins et nos propositions au gouvernement français actuel sur le futur numérique de la France. L'outil est disponible, tout wikipédien sait utiliser un logiciel wiki, l'environnement est favorable (ouvert à tous...), l'objectif est précisément de nous permettre de nous exprimer etc...On pourrait donc imaginer qu'un certain nombre de wikipédiens convaincus se précipitera pour participer à ce brainstorming virtuel.

Il n'en est rien ! Après mon appel, la SEULE réaction obtenue est un laconique "Connaitront elles le même destin que les Cahiers de doléances ?" J'avoue avoir de la peine à concevoir un tel manque de motivation, ou du mal à concevoir qu'aucun wikipédien n'ait l'envie de faire une petite proposition...

Pourquoi les gens font-ils certaines choses ? Et non d'autres ? Pourquoi de cette façon ci et non de cette façon là ? Si l'idée fondamentale est que l'on ne peut pas changer la nature des gens, autant malgrès tout essayer de voir comment construire une organisation où les gens travaillent plus, mieux et avec plaisir.

Le fait est qu'on peut entretenir la motivation, mais on ne peut pas la créer. L'idée est donc d'identifier ce qui motive un individu (et un groupe d'individu), mettre en place une structure qui satisfasse à la fois les besoins de l'individu et ceux de l'organisation, et comprendre les mécanismes de stimulation et de blocage de la motivation.


Comme beaucoup d'internautes, je connais la célèbre Pyramide de Maslow (également appelée pyramide des besoins). Constituée de strates successives, elle identifie (au moins) cinq types de besoins (il existe des versions plus complexes)

  • les besoins primaires ou physiologiques (par exemple, le salaire, permettant de payer nourriture, chauffage et toit)
  • les besoins de sécurité (anticipation de sa retraite, prévention pour les cas de maladie)
  • les besoins sociaux (interactions avec autrui, communication)
  • les besoins d'estime (reconnaissance, status)
  • les besoins d'épanouissement (envie de progresser, de se développer, d'apprendre).

Le mérite de Maslow est d'avoir identifié les types de besoins. Par contre, le modèle en strate (selon lequel on ne peut pas passer à une strate supérieure tant qu'une strate inférieure n'est pas satisfaite) s'est révélé complètement erroné. En effet, nous pouvons avoir des besoins très différents selon notre époque de vie, et donner plus ou moins d'importance à une strate, quelle soit inférieure ou supérieure (par exemple, certains artistes ayant un énorme besoin de reconnaissance ont vécu dans la misère la plus crasse). La conclusion essentielle que l'on peut tirer de Maslow est qu'il existe différents types de besoins.

C'est une première piste de réflexion pour comprendre les besoins de collaborateurs. En effet, un wiki est par définition extrèmement labile, une des priorités à sa création est d'identifier le ou les objectifs du site. On ouvre pas un wiki pour le plaisir d'ouvrir un wiki. Espace peu structuré, il est important de définir dès le départ, objectif(s) et un minimum de règles de vie. L'objectif primaire du site sera lié à l'organisation, mais les objectifs peuvent inclure un aspect de revitalisation de groupes de travail. Dans tous les cas, il faudra étudier à la fois le besoin de l'entreprise et les besoins des futurs participants.

A posteriori, un certain nombre d'études ont été publiées pour comprendre la motivation des wikipédiens. On trouvera quelques pistes sur ce blog. En résumé, les principaux facteurs de motivation relevés sont

  • fun (c'est amusant)
  • compréhension/apprentissage
  • social (travail collaboratif, interactions sociale)
  • valeurs altruistiques, idéologie
  • carrière (construction d'une réputation)
  • égo

Comme on pouvait s'y attendre, les motivations sont essentiellement placées dans la sphère du social, de l'estime et du besoin d'épanouissement. Les résultats complets de l'étude peuvent être trouvés ici. Il est intéressant de noter que les deux facteurs les plus notés sont l'amusement et l'idéologie. Personnellement, après avoir suivi cette communauté pendant plus de 6 ans, je pense qu'il y a un peu de "delusion" sur ces données, mon impression étant que le facteur idéologique pourrait être (assez largement) sur-représenté. J'imagine que le sondé se sent plus confortable à penser qu'il agit dans un objectif de "valeur" (la connaissance pour tous) plutôt que par "solitude" (il est émotionnellement beaucoup plus enrichissant de passer une soirée à inter-agir avec d'autres wikipédians qu'à regarder la télé). A noter, cette étude a été faite uniquement sur la communauté anglophone, et les motifs varient probablement selon les cultures. On notera également que l'échantillonnage laisse à désirer, puisque la participation au sondage est choisie par l'internaute et surtout, n'a touché que la population ayant une page utilisateur.
Il est évident qu'un wiki professionnel ferait beaucoup plus référence à des critères physiologique, ou de sécurité ou de partage de connaissances.


Herzberg a proposé une autre approche, qui est intéressante
Il différencie les facteurs d'hygiène et les motivants.

Les facteurs d'hygiène sont tout ce qui est nécessaire pour ne pas être démotivé. Il peut s'agir du salaire, des relations entre collègues, de l'autonomie dans le travail etc... Ces facteurs d'hygiène n'apportent en fait pas réellement de facteurs de motivation, mais si les choses dérapent, ils peuvent démotiver la personne.

Les motivants sont ce qui permet de se projeter dans le temps (par exemple, la perspective de nouvelles responsabilités, une prime spécifique, une formation...)

Les deux constituent la carotte et le baton. Les motivants doivent changer, car une fois acquis, ce ne sont plus des motivants, mais deviennent des facteurs d'hygiène. Par exemple, une femme qui souhaite passer à 80% du temps de travail pour avoir plus de temps libre verra la satisfaction de cette demande comme un facteur motivant. Mais 6 mois plus tard, il ne s'agira plus que d'un facteur d'hygiène. La suppression de cet avantage créera de la démotivation. Pareil pour la prime lié à un chantier exceptionnel (motivant), versus la prime "par défaut" en fin d'année (13 eme mois), qui ne motive plus, mais démotive grandement l'année où elle n'est pas touchée. Le challenge devient alors d'être capable de "fournir" régulièrement de nouveaux motivants.

Les spécialistes remettent un peu en cause cette approche, estimant qu'un facteur donné peut en fait agir à la fois sur la motivation et la démotivation. Ce qui parait important toutefois est de noter que certains besoins ne sont pas des facteurs de motivation.

Un des problèmes que l'on rencontre typiquement sur les wikis est le fait que personne ne soit généralement "en charge" de quelque chose. Donc, si à moment donné, il n'y a personne de motivé pour remplir une certaine tache... cette tache est tout simplement négligée. C'est la raison principale pour laquelle un wiki est aussi toujours un "work in progress". Sur Wikipedia et d'autres wikis, différents systèmes ont été mis en place pour

  • identifier les taches orphelines non prises en charge et informer des participants de leur existence (cela est souvent suffisant)
  • pousser les participants à prendre la responsabilité de ces taches.

La problématique étant d'identifier les "motivants" et de les maintenir dans la catégorie "motivants" (plutôt que facteurs d'hygiène)

Sur mediawiki par exemple, on identifiera typiquement les taches orphelines dans les pages spéciales. Par exemple

Mais d'autres méthodes ont aussi été utilisées avec plus ou moins de bonheur

  • La mise en place de statuts (eg, administrateur, bureaucrate...) (permet la mesure d'une certaine réputation)
  • la création d'une banque virtuelle (bourse aux échanges, de services, de bons procédés)
  • la décerne de décoration (médaille pour service rendu. Attention, le service rendu doit être identifié pour plus d'effet). On constate que ce système fonctionne bien dans le milieu anglosaxon, mais colle mal à la culture française
  • sélectionner un jour dans l'année et le qualifier de "jour de EditeurX" (pour services rendus, exemple, Brion's day)
  • identifier la photo du jour
  • distribuer des récompenses à valeur éthique pour la personne ayant fait le plus d'ajout (eg, gain de points KIVA chez CapGemini)
  • ou le barnraising, activité collective à durée limitée dans le temps et objectif final clairement défini (teambuilding)

Mais toutes ces techniques montrent leurs limitations en ceci qu'elles ne fonctionnent que SI il y a motivation. Parfois aussi, il semble que la personne puisse être motivée, mais pour autant, ne passe pas à l'acte. Il est donc nécessaire de non seulement stimuler la motivation, mais aussi d'identifier ce qui bloque la motivation proprement dite.


Une troisième approche m'était encore récemment inconnue, l'approche de VROOM.

Cette théorie ne se concentre pas sur les "besoins", mais sur les "outcomes", ce qui est particulièrement intéressant dans le cas d'un wiki (l'objectif primaire étant généralement le fonctionnement correct du site, et non la satisfaction des participants).

Vroom s'est interrogé sur le fonctionnement de la motivation et a défini la théorie V.I.E. (valence, instrumentalité, expectation)

  • Expectation (ou attente) (suis-je capable de faire cela ?). Par exemple, il s'agira d'avoir les bonnes resources disponibles (le temps, les outils), d'avoir les bonnes compétences pour faire le travail, et d'obtenir le soutien nécessaire pour faire le travail (eg, soutient explicite de la part d'un supérieur hiérarchique)
  • Instrumentalité (est-ce-le bon moyen pour moi ? si je fais ceci, alors est-ce que j'obtiendrais cela en retour ?). Ceci requiert la compréhension de la relation existant entre la performance et le résultat (ie, les règles de récompense), la confiance dans les personnes prenant les décisions aboutissant à la récompense, et bien entendu, la transparence du mécanisme de distribution des récompenses.
  • Valence (est-ce important pour moi ?)

Si les trois points remportent l'adhésion, il y a motivation. Si la réponse à une seule de ces trois questions est NON, cela annule la motivation.
Par exemple, si l'augmentation de l'effort n'augmente pas la performance, il n'y aura pas motivation.
Si l'augmentation de la performance ne va pas augmenter la récompense, il n'y aura pas motivation.
Si il n'y a pas d'intérêt de la personne envers les récompenses, il n'y aura pas de motivation.

Selon la théorie, il est nécessaire que les trois points soient positifs pour qu'il y ait motivation.

En tant qu'animateur, on peut envisager assez facilement d'agir sur l'expectation ou l'instrumentalité.

De façon très pragmatique, je peux désormais identifier la (les) sources de manque de motivation des mes compatriotes face au wiki des Assises du Numérique. On peut faire l'hypothèse que certains n'aient pas la capacité à rédiger une proposition d'action (manque de recul, difficulté à la rédaction etc...). J'espère ne pas me tromper en affirmant que tous les participants jugeraient la rédaction de suggestion IMPORTANTE. Ce qui pose le plus problème est très probablement de l'ordre de l'instrumentalité. Le wikipédien a le sentiment que cela ne changera RIEN (d'où la référence aux cahiers de doléances). La solution idéale pour moi est de pouvoir trouver un champion (au moins) pour rédiger le conseil et, dans le cas où notre recommandation serait acceptée par le gouvernement, faire très ample battage autour de ce succès.

En terme d'expectation, il est possible de motiver l'individu en le convaincant de sa capacité à faire une certaine tâche (voire en l'aidant, en l'accompagnant, en le formant, en le coachant). L'individu peut obtenir du temps disponible si certaines de ses autres tâches sont prises en charge par autrui. Le participant devra avoir le sentiment d'un soutient de sa hiérarchie etc...

En terme d'instrumentalité, il est possible de motiver l'individu en montrant l'intérêt du wiki en terme d'organisation du travail, de partage de savoir etc... certains wikis professionnels n'hésitent pas à laisser la place à des activités ludiques (eg, création de base de données restaurant, ou publication des résultats du dernier match de tennis inter-entreprise). La clé du succès étant probablement la souplesse, la faible structuration, permettant à tout un chacun de s'approprier l'outil. L'animateur devra être attentif à rester relativement en retrait, favorisant les initiatives porteuses de résultats concrêts.

Par contre, il est vraiment difficile d'influer la valence.

Au final, Maslow peut être utilisé pour décrire les motivations des participants (il sera possible de batir le modèle sur les attentes et les motivations), et Vroom aide à identifier s'ils vont réaliser ou non une tâche spécifique et pourquoi.

''If a worker sees high productivity as a path leading to the attainment of one or more of his or her personal goals, he or she will tend to be a high producer. Conversely, if he or she sees low productivity as path to the achievement of his or her goals, he or she will tend to be a low producer. -- Vroom ''


Les utilisateurs de wikis ont adopté un certain jargon pour parler de la culture wiki, jargon s'inspirant des activités de jardinage. On parle par exemple de wikijardinier pour définir celui qui s'occupe de tâches légères de maintenance (eg, supprimer les pages sans intérêt, tagguer des pages selon des catégories, accueillir les nouveaux arrivants). Sur la plupart des wiki publiques, le rôle de wikijardinier est assuré par tous les participants au site. Mais sur un wiki professionnel et privé, il est préférable de structurer d'avantage ce rôle. Il semble que ce rôle de wikijardinier ou wiki animateur soit souvent confié à un jeune geek, fanatique de wiki. Ce qui n'est pas toujours très bien compris est que ce rôle d'animateur n'est pas tant le rôle d'un administrateur au sens technique du terme, mais devrait plutôt être confié à une personne ayant une formation en psychologie et/ou une expérience en management, afin de ne pas (seulement ou principalement) travailler sur le nettoyage des pages, mais surtout sur la motivation des participants et la dynamique du groupe. Le prix du succès.

J'ai un peu fouillé sur le web pour trouver des références à ce "rôle".

Quelques vagues allusions sur c2.com, craowiki, ou wikipatterns.com pas très convaincantes.

Un lien supplémentaire sur la motivation.

mardi, octobre 26 2004

Estimer son taux de participation à Wikipédia

Compteur d'édit Certes, la qualité de la contribution ne se mesure pas en nombre de click sur le bouton "sauver" (sinon, je serais bien évidemment gagnante... comment ça... ma cheville va beaucoup mieux depuis samedi merci... le gonflement est parti), mais il est toujours amusant de mesurer notre wikipédiholisme à cette aune. Essayez ! anthere

samedi, octobre 23 2004

Un ouvrage sur les wikis

Un ouvrage sur les wikis - Jérôme Delacroix (sortie prévue janvier 2005)