Motivations collectives

Outre les motivations individuelles à contribuer à un projet coopératif, les résultats obtenus par le groupe constituent un motivation collective. Michel Vivant [VIV] explique que l'intelligence est "la possibilité d'utiliser un outil pour en faire quelque chose". Dans notre cas, l'outil est le groupe d'utilisateurs-contributeurs mis en place, et le but est d'utiliser l'intelligence collective pour obtenir des résultats.

Quels documents produire ?

Les résultats concrets se traduisent souvent par la production de documents. Il peut s'agir d'un document rassemblant la compréhension commune du groupe ou le bilan d'une action engagée... Dans tous les cas de figure, un groupe ne produit pas forcément le même type de document qu'une personne seule. Il faudra de préférence paralléliser au maximum les tâches et produire un ensemble de documents courts plutôt qu'un volumineux et monolithique rapport.

Les documents qui sont bien adaptés à la production collective sont :

  • Les FAQ : Foires aux Questions, un ensemble de questions-réponses sur un sujet donné.
  • Les références : Ensemble de liens vers des sites Webs sélectionnés, bibliographies...
  • Les check-lists : Listes de points à ne pas oublier lorsque l'on veut réaliser une action particulière.
  • Les guides de bonnes pratiques : Ce qu'il faut faire dans tel ou tel cas (veiller cependant à indiquer qu'il s'agit d'exemples pour ne pas figer un comportement qui au contraire doit pouvoir s'adapter aux changements).
  • Les programmes informatiques : Le logiciel libre en est un excellent exemple.
  • Les recueils d'exemples instructifs dans un domaine donné.
  • Les romans et histoires s'ils sont parallélisés (écriture collective)

Dans tous les cas de figure il faut d'abord que les concepts et les informations soient très clairs dans le groupe, la rédaction étant alors simplifiée. L'inverse (une rédaction sophistiquée sur des concepts et des données mal éclaircis) conduisent à une impasse.

Des expérimentations pour ne pas se limiter aux documents.

Bien souvent ce sont les documents qui sont visibles à l'extérieur. Ceux-ci ont cependant plus de valeur s'ils sont appuyés sur des actions concrètes les mettant en oeuvre. Ainsi l'IETF (Internet Engineering Task Force) qui développe les standards utilisés dans l'Internet (des documents donc), n'approuve ses documents que s'il existe 3 mises en oeuvres compatibles développées par ses membres (l'IETF appelle cette règle le "running code", le "code qui marche") [IET].

Ce type de validation n'a pas toujours un sens, mais lorsque c'est le cas, c'est très certainement un outil indispensable. Dans le cas du logiciel libre, le code développé peut être considéré comme validé lorsque plusieurs personnes indépendantes utilisent avec succès le logiciel pour leurs besoins propres.

La première version : un tâche critique pour le coordinateur

Comme toujours, il est nécessaire de distinguer les tâches critiques (endossées par le coordinateur) des contributions accumulées par les contributeurs. La principale tâche critique dans la production d'un document est la toute première version. Sauf si celle-ci est déjà produite par ailleurs, ce sera donc au coordinateur bien souvent de rédiger la première mouture. Commenter ou critiquer un document existant même très incomplet, est toujours plus simple que de rédiger un document en partant de zéro.

Commenter un document permet de l'enrichir mais il ne s'agit plus d'une tâche critique. Aucun contributeur n'est indispensable, il suffit qu'il y en ait quelques uns. Si la personne qui avait prévu d'envoyer un commentaire ne le fait pas, cela ne remet pas en cause la production déjà faite. Ce n'est pas le cas par contre, si la personne qui s'est engagée à produire la première version ne remplie pas ses engagements. La réutilisation facilite le travail du coordinateur. Il ne s'agit pas de recopier un document existant, mais plutôt de réutiliser des contributions et des documents existants pour les intégrer dans un premier jet qui pourra alors être soumis aux commentaires.

Pour la production des documents comme pour le reste, le coordinateur doit être un "fainéant réactif" : Mis à part les parties critiques qui lui reviennent, il ne doit pas passer une trop grande partie de son temps à contribuer, mais plutôt motiver les autres à faire ce travail.

Opportunisme et redéfinition

Le coordinateur doit également être opportuniste au maximum quitte à trouver également des idées en dehors du groupe, au hasard de ses rencontres. Lorsqu'une nouvelle compréhension émerge, il ne faut alors pas hésiter à redéfinir tout ou partie du document pour l'intégrer. Pour cette raison, des documents courts sont beaucoup plus adaptés pour intégrer régulièrement les nouveaux concepts compris par le groupe.

Traitement des commentaires

Lorsqu'un commentaire est fait, il est très important d'identifier clairement les modifications entraînées. Pour cela, plutôt que d'intégrer directement les modifications dans le document et d'avoir des commentaires sans arrêt, il est plus simple de procéder autrement :

  1. Donnez un délai précis pour recevoir les commentaires.
  2. Produisez alors un document intermédiaire : "traitement des commentaires" (en anglais "Disposition of Comments"). Pour chaque commentaire, indiquez comment vous proposez de modifier (ou non) le document original.
  3. Les contributeurs peuvent alors réagir dans un deuxième tour directement sur le traitement proposé des commentaires plutôt que sur le document corrigé. Cela évite d'avoir de nouveaux commentaires sur le document de base à chaque étape.
  4. Lorsque tout le monde est d'accord sur la façon de traiter les commentaires, vous pourrez alors mettre à jour le document de base en considérant qu'il reflète l'avis du groupe.

Le surcroît de travail représenté par le "traitement des commentaires" fait gagner un temps de travail considérable dans le travail global pour obtenir un accord sur le document de base.

Diffuser à l'extérieur

Bien entendu, les utilisateurs contributeurs sont les premiers à bénéficier des résultats du groupe. Mais il peut être nécessaire de les mettre également à disposition du plus grand nombre, en ouvrant les résultats au public et en faisant la promotion afin d'avoir plus d'utilisateurs.

Nous avons vu en effet qu'il y avait deux types d'utilisateurs :

  • Ceux qui s'intéressent de près aux évolutions du projet. Ils viennent alors dans la communauté. Certains peuvent également devenir contributeurs.
  • Ceux qui utiliseront les résultats une fois finalisés. Ils ont alors besoin d'une présentation plus simple ("packagée") car ils n'ont pas suivi les différentes évolutions.

Le rôle du distributeur

Comme nous l'avons vu, cette phase peut être prise en charge par un acteur différent : Le distributeur. Il s'agit en effet de "packager" les résultats et d'en faire une large promotion. Les structures informelles et non financées, sont peu adaptées à cette phase plus "industrielle" qui demande souvent des moyens plus classiques.

La solution est souvent d'avoir une société ou même mieux plusieurs, qui assument ce rôle de distributeur. Même si le produit ou service réalisé de façon coopérative est distribué de façon gratuite, elles y trouvent leur l'intérêt dans les ventes connexes induites (par exemple la vente de services), la valorisation de l'audience générée sur un site Web ou la vente d'adaptations spécifiques. On retrouve ce schéma dans le logiciel libre [RAY2] avec l'émergence de nombreuses sociétés qui vendent des distributions de Linux et d'autres logiciels. Elles vendent en fait le service et la documentation.

Attention aux rôles mixés

Lorsque dans le développement même les méthodes coopératives et traditionnelles sont mixées, c'est souvent la structure qui abrite en son sein la coordination qui fait office de distributeur. Il sera alors d'autant plus nécessaire de bien séparer les rôles pour éviter que les utilisateurs-contributeurs n'aient le sentiment de fournir un service à une structure qui le revendrait ensuite.

La production collective de documents permet d'obtenir des résultats tangibles. Il vaut mieux plusieurs documents courts parallélisés plutôt qu'un rapport monolithique. Il vaut mieux, lorsque cela est possible, que les documents s'appuient sur des expériences concrètes du groupe ou de plusieurs membres du groupe.

Les documents adaptés à la production collective sont par exemple : FAQ, listes de références, check-lists, guides de bonne pratique, recueils d'exemples, programmes informatiques.

Quelques règles pour faciliter une production collective :

  • Avoir des concepts et des données intelligents et une rédaction simple plutôt que l'inverse
  • Le coordinateur doit produire la première version si elle n'existe pas déjà. Pour cela il peut réutiliser au mieux les informations existantes.
  • Donner un délai suffisamment long mais précis pour commenter le document.
  • Pour les commentaires, le coordinateur doit être un "fainéant réactif" qui motive les autres à faire le travail. Les contacts personnels avec certains contributeurs peuvent "amorcer la pompe".
  • Le coordinateur doit également être opportuniste, quitte à aller chercher des idées à l'extérieur.
  • A l'issu de la période de commentaires, faire approuver un document présentant le "traitement des commentaires" plutôt que la nouvelle version du document de base.
  • Le coordinateur doit maîtriser entièrement les documents fondamentaux du groupe :
    Plan de travail, annuaire des compétences, historiques et liste des résultats obtenus.

La distribution des résultats réalisés par le groupe de coopération est ensuite "packagée" et fait l'objet d'une promotion par un distributeur qui travaille avec des méthodes plus traditionnelles en vendant des produits connexes ou des adaptations spécifiques.

Parfois la distribution est assurée par la structure qui abrite la coordination. Il faut alors bien séparer les rôles pour éviter toute ambiguïté.

#produire28 Livre sur la

Répondre à cet article

Par J-M Cornu | Avant | 24/12/2004 11:34 | Après | Coopération | aucun commentaire | Lu 7398 fois | Version imprimable