Wiki ou pas Wiki ?

Ce document

Votre association est sur le point de faire le pas! Mais est-ce la bonne décision ? Ce document a pour but de vous donner quelques pistes qui vous seront peut-être utiles, au-delà des aspects techniques (certes fortes intéressants, mais qui n'auront aucun impact sur le succès ou non de votre démarche).

Le travail collaboratif associatif

Résumé "executive"

POUR CEUX QUI NE VEULENT PAS TOUT LIRE, RESUME "EXEC:"

Un Wiki n'a de sens que dans une entité où les membres sont finalement intéressés à participer à la gestion organisationnelle régulière. Lors d'investissements uniquement ponctuels, l'e-mail est probablement le seul moyen électronique valable. Ce qui rend la tâche plus difficile pour les "organisateurs permanents", mais est peut-être le prix à payer pour avancer.

Travailler par e-mail ?

Tout d'abord, le problème principal de l'email est lié à la facilité d'en envoyer et de répondre (à tous?). Cela signifie que de très nombreux mails sont échangés. Vouloir retrouver une information cohérente (pas juste un numéro de téléphone par exemple) dans ce fouilli désorganisé n'est pas forcément chose facile. Surtout qu'on n'a normalement pas accès au fouilli des autres.

Un symptôme de cette désorganisation est la récurrence de questions déjà traitées, de questions et d'informations déjà données. La plupart des entités (associations, entreprises) réagissent à ce problème en créant des listes de questions-réponses (FAQ), plus ou moins maintenues plus ou moins collaborativement (fichier texte, HTML ou Wiki); voire envoi régulier par e-mail dans les cas graves.

Un autre problème est le volume: en particulier pour des tâches qui ne relèvent pas de l'activité professionnelle, plus de 4-5 mails par jour sur un sujet seront vite vu comme une agression. Alors comment combiner "facilité de réponse" avec "réfléchir avant de répondre?". Une éducation des utilisateurs est nécessaire.

Il se pose aussi, à terme, une notion de confidentialité et de "type de boîte": un membre du comité est remplacé par un autre: il n'y aura probablement pas transmission de tous les e-mails depuis N ans, ces derniers n'étant soit pas proprement archivés (indépendamment des autres mails privés reçus) ou étant considéré du domaine privé. L'information, le savoir-faire, se perd donc inexorablement. En entreprise, je recommande par exemple des e-mails "fonctionnels" (support-technique@) plutôt que personnels (Guillaume.Tell@), pour survivre aux vacances et remplacements, pour lesquels les archives sont accessibles à tous ceux qui en ont besoin.

Réflexion globale

Introduction

Une réflexion plus globale sur ces problèmes peut mener à plusieurs démarches, que j'ai pour la plupart expérimentées dans diverses associations, fondations, ligues, partis politiques et entreprises avec plus ou moins de succès: je dois avouer plutôt "moins" que "plus" (surtout car, bien souvent, je suis concerné par l'aspect organisationnel à long terme, et donc motivé à mettre en place des outils complexes, peut-être trop complexes pour ceux qui ne s'intéressent qu'à des projets ponctuels -- ceci est développé ci-dessous).

Je ne traite pas, intentionnellement, du blog, qui, à mon avis, même avec du "tagging" ne peut pas se substituer à une organisation documentaire. Je ne traite pas non plus des systèmes de suivi de tickets, qui peuvent être, avec un marteau, adaptés également au suivi des activités ponctuelles répétitives d'une association.

Personne centrale

Une personne devient de fait la mémoire des processus, savoirs et savoir-faire. Cela peut prendre diverses formes: un président très présent dans une association, une secrétaire à temps partiel est engagée, une personne est nommée organisateur et archiviste.

Cette stratégie est souvent la plus efficace au début. Elle est coûteuse en ressources, et peut mener à de graves problèmes en cas de changement de personne.

Notons également que cette personne centrale peut aussi être vue comme possédant trop de pouvoir, trop d'information, ce qui peut nuire à l'esprit collaboratif!

Exemples:
  • secrétaire à 20% à /ch/open, depuis 15 ans, fonctionne tip-top, présence aux réunions du comité, organisation générale, gestion des documents standards, etc.
  • secrétaire à 10% au GULL: échec complet après 1 an, problèmes interpersonnels entre une membre du comité et le secrétaire, principalement des griefs sur "trop de contrôle", "trop de pouvoir", "sert à rien".
  • président trop présent dans une association, lorsqu'il part, tout s'écroule (jamais vécu personnellement, mais on entend souvent!)

Centralisation des documents

Tous les documents importants, au format classique de traitement de texte (Microsoft Word, Excel, ...) sont stockés quelque part de manière centrale. Une structure standard est définie pour le classement. Toute modification d'un document doit être reportée sur le central (pas de "copies internes, privées, etc") Un suivi des changements (qui quand quoi) est mis en oeuvre, avec la possibilité de revenir en arrière (historisation).

Ce système est assez lourd: un petit mémo de 3 lignes devient un énorme document Microsoft Word non facilement cherchable. De nombreux membres ont des copies "meilleures" (plus récentes) que dans le repository central.

Dans une association, nous avons expérimenté ce modèle depuis 2000 via un repository CVS contenant principalement du texte et des PDF. Les problèmes rencontrés ont été:

  • tout le monde ne sait pas utiliser les outils de synchronisation standard (CVS, ...)

  • tout le monde ne sait pas utiliser de simples fichiers textes ou, "pire", du LaTeX

En conséquence, le comité s'est séparé en deux "équipes": une équipe capable de maîtriser l'outil; et une équipe générant des documents archivés chez soi. Parfois même avec des doublons.

Notons que cela a très très bien marché, vu que les deux personnes qui ont fait ces dernières années toute la correspondance de l'association sont celles qui maîtrisent l'outil. Conséquence ou cause ? Matière à réflexion.

Système collaboratif sous la forme d'un Wiki

L'idée est très similaire au modèle 2, en essayant d'apprendre des faiblesses et d'accentuer le côté "coopératif" (accessibilité):

  • utiliser le client Web standard sans plug-in particuliers (résoud le problème "d'installation")

  • stocker le moins possible de documents au format classique, perçus comme lourds et difficilement gérables: avoir le plus possible d'information visible en HTML

  • promouvoir l'interaction avec le plus de membres possibles par des outils techniques (tables éditables facilement, liens pouvant être suivis, recherches) et non techniques (classement par thèmes multiples, etc).

  • mettre en place des outils de dynamisation (calendrier et rappels par e-mail) du système vers l'utilisateur.

L'expérience faite dans une association montre que ce sont quasiment toujours les mêmes personnes qui savaient utiliser les outils du point précédent (dépôt central) qui utilisent le Wiki.

Le simple fait d'avoir un login/password semble bloquer beaucoup de membres. Certains membres déposent des documents complexes en format zip ce qui déjoue les fonctions de recherche, l'archivage et les versions, et la transparence. Donc personne ne les lit (ni ne les trouve).

Diverses tentatives de restructuration des documents n'amènent pas à plus de lecteurs -- ou de modificateurs.

Les séances de formation n'amènent à rien, sinon tous les six mois une demande de nouveau mot de passe car on "a oublié l'ancien".

Enfin, le rappel d'événement est vu comme agressif et inutile.

Synthèse

L'expérience faite ailleurs montre que les personnes qui sont déjà fortement impliquées dans l'aspect ORGANISATIONNEL d'une association saluent avec soulagement la venue d'un Wiki, dans l'espoir de les délester de beaucoup de tâches répétitives. Elles ont aussi l'espoir que la disponibilité aisée de l'information diminuera leur travail communicationnel. Le coût élevé de mise en place et de maintenance (technique, structure, contenu) est acceptable si l'outil est véritablement utilisé.

Par contre, les personnes qui ne s'occupent que ponctuellement de gérer des événements ou activité ne voient pas l'avantage: elles ont l'impression qu'elles doivent APPRENDRE un nouvel outil qui ne leur sera utile qu'une fois par an.

Le principe même d'un Wiki (pouvoir modifier rapidement des informations tout en ayant la possibilité de voir l'historique de celles-ci, ceci de manière collaborative) est donc violé: le système devient un simple système "en lecture seule", et les membres (re)deviennent passifs.

En conséquence, tous les efforts conséquents de wikisation faits par les "personnes organisationnelles" sont inutiles: elles peuvent revenir à leur pratique antérieure (e-mail, dépôt de document), car ce sont elles qui ont besoin des informations et les gèrent elles-mêmes.

Avec certains inconvénients ...

Recommandations

Avant de se lancer dans la Wikisation des documents d'une association:

  1. déterminer le flot actuel des documents (qui est responsable, quels documents sont maintenus, où et par qui)
  2. déterminer si la valeur ajoutée d'un Wiki (collaboration, historisation, classement et recherche, simplification des formats des documents) a une véritable valeur pour l'association
  3. déterminer si les membres sont prêts à changer leurs habitudes (e-mail, Microsoft Word ou Excel, copies privées de document, investissement en temps d'apprentissage)
  4. déterminer qui va maintenir l'outil informatique (y compris les sauvegardes!) et comment gérer la transition éventuelle

Rappelons que si l'association n'a pas de réelle dynamique collaborative en particulier dans sa gestion organisationnelle, un Wiki ne va vraisemblablement pas fonctionner.

Quelques astuces du domaine du social:

  • pour s'approprier l'outil, les membres doivent avoir une raison impérieuse d'aller sur le Wiki très régulièrement, ne serait-ce que pour lire quelque chose (écrire serait encore mieux!)
  • insister sur l'aspect d'historisation pour casser le mur social qui empêche chacun de contribuer
  • insister sur le fait que de garder des infos chez soi est contre-productif: amener à la confiance dans l'outil par des exemples pratiques
  • maintenir sur le long terme une dynamique collaborative

Si le système est bien géré, la plupart des utilisateurs non techniques verront bientôt que les avantages dépassent largement les inconvénients. Il suffit d'attendre la prochaine corruption de leur système Microsoft alors qu'ils n'ont pas de sauvegarde récente.

Références

-- MarcSCHAEFER - 09 Feb 2011
Topic revision: r2 - 22 May 2011, MarcSCHAEFER
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback