Lorsque l’on souhaite développer un ou plusieurs projets un peu importants, on rassemble habituellement un certain nombre de personnes dans une structure : association, collectivité, entreprise… S’il s’agit d’un projet commercial ou d’une action de service public, on met en place un budget qui permet de payer les personnes qui réalisent les taches nécessaires. Mais lorsqu’il s’agit d’un projet d’intérêt général faisant appel à des bénévoles ou lorsque la tâche à exécuter ne fait pas partie ce pour quoi on est payé (très souvent par exemple : coopérer et développer des synergies au sein d’une entreprise ou d’une collectivité), alors les choses se gâtent…

La majorité des participants ne s’impliquent pas et on ne sait plus comment les motiver alors que nous même on manque de temps pour courir après chacun. Et en plus ceux qui participent tout de même ne s’écoutent pas et ne pensent qu’à imposer leurs idées. Cela se termine souvent en luttes de pouvoir…

Une solution originale

En 1986, une solution originale a émergé. L’IETF (Internet Engineering Task Force) est créé cette année-là pour développer les spécifications des standards de l’internet qui venait juste de naître. Mais L’IETF a une particularité… Il n’existe pas ! Ou plus exactement, il s’agit d’un simple collectif et ses participants ne sont pas membres d’une structure commune. L’IETF rassemble pourtant plusieurs dizaines de milliers de personnes qui travaillent au sein de 116 groupes de travail (au moment où j’écris ces lignes). Ils produisent ensemble les documents les plus stratégiques dans le monde de l’Internet, ceux pour lesquels beaucoup de sociétés seraient prêtes à se battre pour en prendre le contrôle. Outre l’incroyable résilience de cette « non structure » qui lui a permis de résister aux luttes de pouvoir, comment fait l’IETF pour payer des salles dans des grands hôtels pour les réunions qui réunissent plus de mille personnes ? Et comment fait-elle pour gérer les procès qui peuvent arriver sur les standards de l’internet ? L’astuce tient en trois lettres : IAB (Internet Architecture Board). Il s’agit d’une structure qui elle peut gérer un budget, des procès et d’autres contraintes. Il ne s’agit même pas d’une association mais d’un simple comité d’une association déjà existante : l’Internet Society. L’IAB qui ne comporte que douze membres (plus quelques « liaison members ») héberge le secrétariat pour l’organisation des réunions et s’occupe des différents que l’IETF n’a pu régler lui-même (ce qui n’arrive pratiquement jamais…).

Depuis, cette idée de séparer le collectif des personnes actives et la structure plutôt que de les rassembler au sein d’une même association, s’est développé à l’aube du nouveau siècle. En France, les Colibris est un mouvement citoyen créé en 2007 qui rassemble 250 000 personnes. Il s’appuie sur « l’association Colibris » qui comprend beaucoup moins de membres mais gère le budget et les salariés qui permettent d’épauler le mouvement. Open Street Map, un projet pour constituer une base géographique libre créé en 2004 rassemble plus d’un million de contributeurs dans le monde. Il est soutenu par la fondation « Open Street Map » créée deux ans plus tard. Celle-ci soutien d’ailleurs d’autres projets également. Wikipédia rassemble près de 30 millions de contributeurs simplement pour la partie anglophone et s’appuie sur la Wikimedia Foundation qui gère les serveurs et les appels à dons pour différents projets (Wikipedia, Wiktionnaire, Wikibooks, Wikispecies, Wikiversité…).

Mais pourquoi cette idée apparemment saugrenue de mettre en place deux organisations plutôt qu’une seule, semble si bien fonctionner ?

Une question d’opportunité

En 2000, j’ai cherché à faire la synthèse de ce que j’avais pu apprendre dans mes différentes expériences coopératives sous la forme d’une méthodologie que chacun pourrait réutiliser facilement. J’ai été très inspiré par un texte « la cathédrale et le bazar » écrit par Éric Raymond peu de temps auparavant. Cet essai tentait d’expliquer pourquoi Linus Torvalds avait réussi à créer un système d’exploitation complet, nommé Linux, avec plus de mille personnes sans même avoir le début d’une structure ou d’un budget… Le mode d’organisation semblait étonnant (le « bazar » plutôt qu’une organisation de type « cathédrale ») mais m’a offert plusieurs clés pour comprendre ce qui avait marché ou pas marché dans mes différentes expériences. En compilant le tout sous la forme d’un premier livre en ligne « la coopération nouvelles approches » je me doutais bien que ma méthode de gestion de projets coopératifs serait bien différente des méthodes de gestion de projets classiques. Mais quel ne fut ma surprise à la fin de constater que l’approche n’était pas différente mais… exactement opposée ! Linus Torvalds se qualifie parfois de fainéant (il faudrait plutôt dire qu’il délègue…), la gestion est opportuniste… Tous des termes qui sont normalement connotés négativement.

Mais il restait un chapitre où je ne m’en sortais pas : « Comment mixer les méthodes coopératives et traditionnelles ». Tout ce que j’avais réussi à y mettre était de réduire les contraintes ou bien de revenir à une gestion de projet plus traditionnelle… C’est à ce moment-là que j’ai été invité pour intervenir dans un séminaire Franco-Finlandais à Helsinki. Un des autres intervenants était le philosophe Michel Serres et pour nous remercier de notre venue, l’ambassade de France nous a offert une petite croisière à travers le golfe de Finlande pour aller déjeuner à Tallinn en Estonie. L’occasion était trop belle et pendant la traversée j’ai posé à Michel Serre la question la plus complexe que je puisse trouver : comment réconcilier la gestion de projet classique et l’approche coopérative qui semblent si antinomiques. Sa réponse m’a stupéfaite de simplicité : « Je suis un ancien marin gascon. Dans tous les bateaux il y a deux chefs – le chef de quart et le chef de pont - L’un punit, l’autre récompense ». Il existe des cas de figure où un membre de l’équipage doit faire quelque chose d’interdit pour sauver le bateau. Dans ce 

cas, il est important qu’il soit récompensé, sinon la prochaine fois il ne sauvera pas le bateau. Mais il est également important qu’il soit puni, sinon chacun risque de ne plus respecter les consignes et le bateau se retrouve également en danger. Lorsque l’on doit gérer à la fois des contraintes et des opportunités il faut faire appel simultanément à des approches différentes qui peuvent sembler antagonistes.

Effectivement, dans le cas du logiciel libre, les contraintes sont parfois ignorées. La sortie d’une nouvelle version se fait « quand elle peut ». Dans ce cas, l’approche collaborative est parfaite et permet bien mieux que de lourdes organisations de saisir les opportunités. Mais il peut être opportun, comme le font de plus en plus de grands réseaux, de séparer la communauté des personnes qui réalisent les projets avec une approche participative d’un côté, et la structure qui gère les contraintes budgétaires, légales et autres avec une approche représentative de l’autre.

Quatre étapes pour savoir quoi faire

Pour optimiser la gestion de vos opportunités comme de vos contraintes, il va dans un premier temps vous falloir distinguer ce qui relève de l’un ou de l’autre. Ce n’est pas toujours facile car certains aspects semblent relever des deux. Pour vous aider voici quelques indications : les aspects financiers et les salariés (s’il y en a) relèvent de la gestion de contraintes, de même que la gestion de locaux, les aspects juridiques, la représentation légale ou les liens contractuels avec des donneurs d’ordres. Par contre l’implication bénévole du plus grand nombre de personnes possibles dans les différents actions et projets ne relève pas des contraintes contrairement à ce que l’on pense d’habitude (on ne peut pas contraindre des bénévoles à agir) mais se gère très bien avec une approche coopérative sans avoir à « payer tout le monde » (voir le guide de l’animateur). De même, la visibilité à l’extérieur (contrairement à la représentation légale) peut être abordée par une approche par opportunités. C’est enfin également bien sûr le cas de la créativité et de l’innovation (on ne décide pas à l’avance de ce que l’on va inventer mais on peut le favoriser). Vous devrez faire cela pour le projet global (avoir une grande communauté, la visibilité commune…) mais aussi les projets spécifiques gérés par un plus petit nombre de personnes.

Dans un deuxième temps, cherchez à réduire au maximum les contraintes ou bien à voir si elles peuvent être prises en charge par une structure déjà existante. Vous allez devoir faire preuve d’imagination : peut-on vous mettre à disposition des locaux lorsque nécessaire ? Ces tâches peuvent elle être faites par des bénévoles (tant mieux si ça marche) ou par des salariés (pas le droit à l’échec, il faut impérativement que ça marche). Il y a des façons de minimiser les risques d’échec par la réduction des tâches critiques. Je mets dans l’encadré ci-dessous un exemple tiré de mon premier livre en 2001.

L'exemple de l'Internet Fiesta

Dans l’Internet Fiesta 2000 [INT], nous avions prévu au départ d’assurer 3 jours non-stop d’émission de télévision sur Internet pour mettre en valeur tous les événements réalisés dans le monde. Cela laissait peu le droit à l’erreur : Un trou dans la grille et nous n’aurions pas rempli nos objectifs. Un participant défaillant suffit à faire échouer le projet. Finalement, nous avons opté pour une formule où nous avons mis en ligne le plus possible de vidéos présentant les événements. A certains moments, il n’y avait rien et à d’autres des personnes travaillaient sur plusieurs émissions en même temps. Dans ce cas, personne n’est indispensable. Certaines émissions n’ont pas abouti mais toute personne qui a apporté un programme vidéo supplémentaire a enrichi le projet... et a gagné en estime en fonction de la qualité de ce qu’il a apporté. Pour que le projet réussisse, il suffisait qu'un certain nombre d'émissions aboutissent, sans qu'aucune ne soit critique pour le projet.

Si à ce stade vous avez réussi à n’avoir plus que des opportunités, bravo ! Il vous suffit, de lancer une communauté pour gérer vos projets (ce qui rappelons-le est tout de même contre-intuitif car la démarche est opposée à celle de la gestion de projets classiques). Mais s’il vous reste des contraintes, alors il vous faut une troisième étape : dans quelle structure placer ces contraintes ? Pouvez-vous utiliser une ou plusieurs structures participantes de la communauté pour héberger ces contraintes comme le font maintenant de nombreux groupes de coop-group, un écosystème rassembleur des porteurs de projets dans le domaine de l’innovation sociale. Ou bien devez-vous créer une structure spécifique pour gérer les contraintes restantes ? Nous avons très souvent tendance à créer une structure avant même de savoir si celle-ci est VRAIMENT nécessaire. Par ailleurs, si votre communauté se trouve au sein d’une structure (collectivité ou entreprise) et n’a pas vocation à s’ouvrir à l’extérieur, alors la même question se posera entre ce qui doit être placé dans la hiérarchie pour prendre en compte les besoins (les « chefs de quart ») et dans une animation transverse pour saisir au mieux les opportunités (les « chefs de pont »)

La quatrième et dernière étape consiste à bien séparer les rôles. Ainsi par exemple, la Wikimedia Foundation s’est interdite d’intervenir dans le contenu de l’encyclopédie Wikipédia et se concentre sur le financement et la mise à disposition des moyens dont cette dernière a besoin. A ce stade, la structure soutient les actions de la communauté mais ce positionne plutôt comme un secrétariat que comme une structure « chapeau » qui coordonnerait tout. Cela évite bien des guerres de pouvoir !

A vous de jouer !

Si vous souhaitez monter ou accueillir un ou plusieurs projets avec une communauté qui rassemble le plus grand nombre possible de participants, je vous recommande de faire ce petit travail (de préférence collectivement) pour être sûr que les contraintes n’empêcheront pas de saisir les opportunités. Il en va de même si vous avez déjà une structure ou une communauté et que vous souhaitez la réorganiser pour permettre de sortir « la tête du guidon ». Dans la métaphore de savoir s’il faut avoir le beurre ou l’argent du beurre (ce qui sous-entend que l’on ne peut avoir les deux), une solution consiste à avoir le maximum de beurre mais de garder un peu d’argent pour acheter le pain sur lequel le tartiner. Ainsi on peut avoir beaucoup de beurre et en même temps un peu d’argent du beurre !

Alors à vous de jouer… Et n’hésitez pas à témoigner sur l’analyse de vos groupes que vous a permis ce billet dans les commentaires ci-dessous.

Répondre à cet article

Par Jean-Michel Cornu | Avant | 23/01/2017 11:18 | Après | Coopération | aucun commentaire | Lu 5739 fois |