Expérience d'un wiki communautaire

Bonjour,
Dans le cadre d'un projet bénévole, je suis responsable de l'implantation d'une solution informatique pour nous aider à organiser notre événement. J'ai beaucoup regardé ce qui se fait côté groupware et wiki, toutefois je n'arrive pas à me décider. J'aimerais savoir si certains d'entre vous ayant été dans une situation semblable auraient des conseils à me donner.
Je n'ai jamais travaillé sur un wiki (et probablement aucune autre de la quinzaine de personnes), donc ma plus grande interrogation est la suivante: est-ce qu'un groupware ou un wiki est plus adapté? Est-ce que des modules comme les calendriers, les todos, les messageries sont vraiment nécessaires? Peut-on les remplacer par une application wiki plus légère?
Voici quelques nécessités/contraintes :

J'ai beaucoup de questions, j'envoie un message à la mer, si jamais vous avez un retour d'expérience à raconter, je serais très intéressée à apprendre sur le fonctionnement d'un wiki. Pas vraiment le coté technique de la chose, mais plutôt de l'organisation du travail et des utilisateurs.
Merci et au plaisir!
Mélanie

PS SVP, ne me dites pas de faire une recherche sur le forum, ce n'est pas uniquement des noms de wiki que je veux, on les trouve tous sur internet, mais bien un compte rendu et/ou le post-mortem d'une expérience que vous avez vécue!

Pour quelques heures par semaine pour une quinzaine de personnes non experte un groupware ou un wiki serait peut être excessif.

Expérience en entreprise: Le groupware (bon Microsoft dans ce cas), c'est à dire mailing list, email, calendrier partagé est utile lorsqu'il faut gérer plusieurs projet/personnes/rendez-vous en même temps, (des utilisateurs ayant quelques mail par jours et quelques rendez-vous par semaine à des utilisateurs ayant plusieurs centaine de mail par jour et 3 rendez-vous par jour). L'utilisation est plutôt de plusieurs heures par jour pour que cela soit intéressant. L'administration en est très lourde.

Le wiki (ou base de connaissance), c'est utile comme foure-tout, lorsqu'il n'y a pas de catégories/outils bien prorpre pour gérer ça. Des éléments d'un livre blanc, à des fiches clients. Le "problème" est la mise à jour suivi des données, une page peut rester sans mise à jour ou ne pas être connu: un suivi des pages est possible, mais cela se situe surtout au niveau des mises à jour d'une page et un suivi fin, qui permet de faire la distinction sémantique entre 3 pages ajoutées ou une gallerie complète ou qu'une page modifié n'existe pas à ma connaissance (ces 3 modifications peuvent avoir le même contenu du point de vue de l'organisation de l'évènement) la mise en place du wiki nécessiterait de s'accorder sur un formalisme d'édition (ce qui mérite ou non une nouvelle page, règles de nomage, etc...) donc même si l'administration est plus légère, la préparation/accompagnement des utilisateurs n'est pas négligeable au préalale.

Si je suis pessimiste, c'est parce que je pars du principe que l'outil doit faire gagner du temps, et si l'apprentissage coordination sur l'outil dépasse le temps qui peut normalement être consacré au projet pour un gain minime... (Dans votre cas, si j'ai bien compris, personne ne connait ou n'a pratiqué l'utilisation de ces outils).

Une solution qui répond au critère sans être un wiki ou un collaboriciel: un journal internet (ou web log, ou blog.. :p ).

facile, très facile : à comprendre et à apprendre, c'est un projet bénévole à raison de qq heures/semaine. (et aussi à administrer pour moi, je n'ai jamais fait ça!)

Check: des adolescent tourmentés de 14 ans s'en sortent.

un système de catégories ou de tags : pour retrouver facilement ce qu'on cherche

Check: on peut mettre des catégories ou des mots clés.

dépot de fichiers accessible à tous pour consultation et rédaction

Niet: pas plus de 2Mo souvent (à moins que vous n'administriez completement le serveur, cela tient de la configuration de PHP).
En pratique, même dans des grands groupes, le doc envoyer par courriel à une liste de personnes est encore ce qui se fait le plus facilement.

galerie d'images

Presque: il faudra installer un plugin (pour éviter d'administer quelque chose en plus: une gallerie flickr privée avec un plugin pour faire le lien).

notification RSS ou email, étant donné que les utilisateurs ne consulteront pas en continu le site

Presque, par rapport à ce qu'il y a plus bas, un flux RSS non accessible publiquement demanderait une authentification, et les clients RSS ne sont pas très pratique dans ce domaine (et je ne suis pas sûr que beaucoup d'outils le gère). Pour la notification par courriel paramètrage ou extension.

permissions de groupe : je pensais séparer les utilisateurs en "cellules régionales" afin d'éviter trop d'informations non-pertinentes, mais est-ce vraiment un problème??

Presque, avec l'utilisation des catégories, cela permet de faire un tri (sinon, une petite doc sur les filtres dans les clients mail/rss).
Sinon, les gestions de groupes sont souvent lourdes, pour 15 personnes c'est excessif.

accessible sur internet (mais pas visible publiquement)

Check: il est souvent possible de ne rendre visible que certains articles

coté technique : pas besoin qu'il y ait plein de fonctions high tech qui ne servent à rien, mais fiable et sécuritaire. J'ai accès à un serveur.

Quoi comme serveur? un serveur DNS, web, mail, webdav? une machine dédié? un domaine? un hébergement mutualisé? Les solutions sont différentes dans ces cas.

Bon je suis cruel, vu la formulation je pars du principe que vous parlez d'un hébergement mutualisé (accès FTP, répertoire apache avec mod php) avec nom de domaine.

Donc fiable et sécuritaire (gnii?), si vous êtes fiable et sécuritaire, c'est bon... (je suis encore un peu cruel), plus sérieusement, beaucoup d'outil web protège mal les mot de passe (authentification en clair, mot de passe non salé: wordpress), et certains sont pété de failles (phpBB), au delà de ça la fiabilité et la sécurité se gère par l'administration et la formation (suivi des anomalie/faille: abonement au mailing list de sécurité du produit et mise à jour rapide, surveillance de l'activité du serveur web (journaux de connexion, pour filtrer/bloquer les connexions d'attaque et ou pourriel). A savoir que la sécurité est une fonctionalité, et que pour l'avoir cela réclame souvent temps et argent.

Sur l'utilisation sur un projet un journal internet permet à plusieurs utilisateurs de participer, de rediger des notices, choisir des catégories, d'en modifier (mais sans historique, l'avantage du wiki), et de suivre les nouvelles publications facilement. Si vous pensez au journal comme au journal d'activité d'un capitaine de navire avec les informations passé, et les plans avenir, cela devrait s'intégrer plus naturellement au processus d'organisation d'un évènement qu'un wiki ou groupware qui risque de détourner du temps.

Beaucoup d'extensions vous permettent d'ajouter des calendriers ou d'autres gadget facilement, et la possibilité d'ajouter des pages statiques facilement vous permet d'avoir des éléments plus statique, justement, au sein du même site.

Une recommandation: http://www.framasoft.net/article1955.html dotClear la communauté est francophone, donc pour vous trouverez facilement de l'assistance.

Le Linux Pratique de ce mois-ci explique comment mettre en place un filtre anti-pourriel pour dotClear, pratique si vous comptez rendre public certains articles (et ou l'accès au commentaires, outils utile au niveau collaboratif). (et globalement, vous trouverez souvent des articles dans Linux Pratique recommandant tel ou tel plugin pour dotClear).

voili, voilou pour mon expérience des différents outils (et le journal internet, cela vient de l'expérience d'un petit groupe de personnes travaillant sur un projet avec un journal internet et des mails, quelques heures par semaine, en utilisant les liens entre les différents articles, une interface facile pour l'édition sans balise, et une organisation simple).

Bonjour,
merci de la réponse et désolée pour le délai. Je n'avais pas du tout considéré l'utilisation de blogue pour un tel usage. Je croyais naivement que cela servait principalement à la publication de contenu, ce qui n'est pas du tout mon cas.
Votre analyse semble assez juste sauf pour ce point:

En pratique, même dans des grands groupes, le doc envoyer par courriel à une liste de personnes est encore ce qui se fait le plus facilement.

C'est justement afin d'éviter des envois massifs de plusieurs courriels, les fichiers étant constamment modifiés. L'an passé, nous nous y retrouvions plus tellement de versions circulaient.
Pour le serveur, c'est effectivement un hébergement mutualisé.
Je vais regarder ça, merci. Si jamais d'autres personnes ont des commentaires, ne vous gênez pas!
Mel

Se connecter

Expérience d'un wiki communautaire

Qui est en ligne ?