Permettre à des acteurs publics et privés de s'appuyer sur les communs pour développer leurs projets, tout en soutenant ces communs et leurs collectifs.
Par exemple : Permettre aux consultants de répondre aux besoins d'une mission de conseil, d'un appel à projet, d'un appel d'offre ou d'un accompagnement de projet en s'appuyant et en soutenant les "communs" et les collectifs qui les produisent.
La méthode proposée permet de mettre en lien et de coopérer avec les "communs" et les "commoners" les plus pertinents selon les besoins d'une mission de conseil, d'un appel à projet, d'un appel d'offre ou d'un accompagnement de projet. Elle facilite la mise à disposition du temps de contribution de communautés de commoners et de leurs ressources. Elle favorise une relation "bénéfique" à la fois pour les commoners et leurs communs, les "consultants réalisant la prestation" et les "commanditaires de la prestation".
Commanditaire de la prestation (Porteur d'un projet ayant une "commande", collectivité, entreprise, etc...)
Prestataire (Personne répondant à la commande de type consultant, Coordinateur, pilote d'une réponse)
Commoners (Acteurs du terrain, Contributeurs d'initiatives ayant acquis un savoir-faire à partager et ayant à disposition des ressources)
La méthodologie Unisson conçoit l'accompagnement comme un ensemble de rôles à remplir. Chaque rôle correspond à un objectif, des tâches particulières et un domaine de responsabilité. Les rôles sont à différencier des personnes. Les rôles peuvent être distribués entre plusieurs personnes ou non.
Il s'agit d'octroyer tous les moyens à la prestation pour qu'elle puisse s'organiser dans des logiques de "commun".
Sa raison d'être : Identifier les "communs" adaptés aux enjeux de la prestation et s'assurer de la bonne application de la méthodologie.
Son domaine de contrôle : l'identification des "communs" et la méthodologie du projet.
Ses redevabilités :
En tant que personnes disposant d'une expérience sur un "commun" utile à la réalisation de la prestation, il intervient à la fois en témoin et en connecteur au "commun" (au code du logiciel, à la plateforme, au lieu), à ses ressources (documents, outils, recettes, etc...) et à la communauté de commoners. Chaque situation étant différente, on considère son intervention non pas comme une expertise mais comme un partage.
Sa raison d'être : faire bénéficier de son expérience autour du "commun", de son fonctionnement, de sa manière d'y contribuer sainement et en accord avec la communauté de commoners.
Son domaine de contrôle : la connaissance du "commun"
Ses redevabilités :
- être transparent sur son action auprès de sa communauté.
- identifier par rapport aux problématiques ou enjeux du projet la manière d'articuler le "commun"
- Aider la réussite de la prestation en partageant sa connaissance du "commun" (code du logiciel, plateforme web, fonctionnement d'un lieu) et des ressources liées (documents, outils, recettes, etc...).
- connecter sur le long terme l'initiative accompagnée avec les acteurs et communautés de "commoners" qui lui correspondent.
Il s'agit d'articuler les contributions entre elles et d'effectuer le suivi du projet tout le long de la mission.
Le coordinateur n'est pas un rôle spécifique à la méthodologie Unisson.
Sa raison d'être : organiser la réalisation de la mission. Son domaine de contrôle : la coordination, la compréhension des enjeux de la prestation Ses redevabilités : - Comprendre les enjeux de la mission et les remonter pour permettre d'identifier les "communs" sur lesquels se baser. - effectuer les tâches rédactionnelles - gérer l'organisation spacio-temporelle - jouer l'interlocuteur avec le commanditaire
Toute personne connaissant très bien les "communs", leur fonctionnement, et ayant bien compris la méthode décrite ici.
Devenir "garant-connecteur Unisson" fait l'objet d'un contrat moral. Unisson met à disposition toutes les ressources nécessaires pour incarner ce rôle. En échange, la personne s’engage à respecter la méthode Unisson. Outre cette stricte règle, l'intervenant Unisson s’auto-détermine et rien ne lui est interdit.
Toute personne ayant une expérience forte sur un "commun" utilisé durant la prestation. Outre cette stricte règle, l'intervenant "commoners aidant" peut s'auto-déterminer.
Ainsi, dans la mesure où la méthode Unisson est appliquée le rôle de cet intervenant peut être augmenté à souhait. Par exemple, même si il n’est pas "prestataire ou consultant", la personne peut toutefois intégrer ces fonctions à son intervention si elle le souhaite (a fortiori si il a été missionnée pour ses compétences dans ce domaine). Unisson incite cependant fortement les partenaires à bien définir et délimiter le cadre d’intervention de chacun dès le début de la mission
Tout prestataire ou consultant qui souhaite répondre à une mission de prestation (appel à projet, appel d'offre, etc...) en se basant sur des "communs" existants ou à construire. Pour demander à être accompagné par la méthodologie, envoyez un mail à prestation@ulists.org (mail public sur une liste de discussion) ou à défaut, prestation@unisson.co (mail non public non archivé). Une plateforme permettra bientôt d'organiser cela.
Le contrat qui lie le "prestataire" est un contrat moral qui sera assuré par une transparence de sa contribution à des "communs" durant la mission. La personne s’engage à respecter la méthode Unisson et bénéficie alors de l'aide d'un "garant-connecteur".
Unisson ne salarie personne. Par conséquent, les intervenants (garant-connecteur ou commoners aidant) utilisent leurs statuts d’origine ou en créent un nouveau. Des solutions pourront se développer à ce sujet avec l'aide de CAE partenaires sur le territoire.
Actuellement les rémunérations se discutent pour chaque projet. Cette question devra être complétées au fur et à mesure des expériences.
Les personnes autour d'un commun sont "contributeurs" au développement du commun mais pas dédiées à la multiplication du commun, à sa réplication ou diffusion. Ils ne sont pas des "entrepreneurs" souhaitant vivre du développement du "commun" mais usagers du "commun" souhaitant répondre à leur usage par cet acte de contribution. Cela change le rapport vis à vis d'initiatives classiques et explique pourquoi il va être difficile d'avoir du temps disponible de la part des "commoners" pour le dédier à aider des collectivités, des chercheurs ou des consultants à répliquer le "commun" dans d'autres environnements ou territoires. Même si c'est souvent avec plaisir que les contributeurs à des communs partageront leur ressources (par exemple via des recettes sur movilab.org), le temps de contribution bénévole à la construction d'un commun est souvent déjà très considérable. Leur demander en plus de conseiller une collectivité, de répondre à des travaux de recherche, ou d'aider un consultant missionné, c'est risquer d'épuiser les commoners et le commun qu'ils développent.
Si un acteur public ou privé (prestataire ou commanditaire) souhaite comprendre les fonctionnements d'un commun en vue de sa réplication, il faut trouver des modes de faire qui puissent permettre de faire cela sereinement. Sans une méthodologie particulière, trois types de cas semblent se dessiner :
Les commoners feront ce travail de manière rapide et bénévole, sans pouvoir donner assez de temps pour partager leur expertise. Cela limite alors la véritable duplication du modèle ou sa diffusion. Les risques sont multiples :
Les "commoners" ne souhaitent pas faire du conseil, considérant que ce n'est pas leur rôle/travail. Ce sont alors des acteurs éloignés du sujet et qui ne seront pas basés sur des communs qui organiseront le conseil (par exemple, une entreprise qui n'a pas expérimenté le coworking qui fera du conseil sur le coworking). Un acteur public ou un organisme souhaitant développer une initiative se retrouvera à financer des personnes qui viendront expliquer comment fonctionne un commun sans y avoir contribué ou sans l'avoir expérimenté... Sans non plus enrichir le commun avec les nouveaux savoirs développés une fois la mission de conseil terminée. Cela amène souvent à la mise en place de projets non adaptés, n'ayant pas bénéficié de la richesse des communs. Ces projets se retrouvent parfois en conflit avec les communautés de commoners qui ne sont pas en phase avec l'initiative développée, bien que reprenant le concept (par exemple, des coworkings qui se créent qui n'ont rien à voir avec les exemples sur lesquels ils ont été initiés).
Dans le cas d'un appel à projet ou appel d'offre qui met en compétition plusieurs propositions, chaque "commoners" va se sentir légitime pour répondre. Des consultants sachant par ailleurs faire pourraient alors être sélectionnés. C'est la meilleure des 3 configurations. Néanmoins, le risque est de voir tous les "commoners" perdre plusieurs journées pour répondre à ces appels d'offres, avec une mise en compétition plutôt qu'avancer sur nos communs.
La solution que nous soutenons est que ceux qui répondent au missions de conseil expliquent qu'ils vont, une fois sélectionnés, se baser et soutenir le développement des "communs", en adoptant une méthodologique qui le permet vraiment, en associant les commoners.
La méthode proposée dans cette "brique prestation" vise à avancer à la résolution de ces 3 cas. Cette brique est aussi très liée à la brique financement et partenariat public
Un début de travail doit permettre la constitution d'un petit outil permettant de facilement mettre en place cette méthodologie lors d'appel d'offres ou d'appels à projets. Voir à ce sujet le tableau suivant : https://docs.google.com/spreadsheet/ccc?key=0AjUW0ZSBFWPedDFtYzZod29DZUdwQTVPT0hNaTdjY1E&usp=drive_web#gid=0
Exemples de réponses dans des AAP ou Appels d'offres : Page de modèles
Alexandre Poltorak
Dans le libre c'est très souvent que l'on paye une formation par des contributeurs connus et actifs du projet. Pour des logiciels déjà très répandus comme Drupal, nous allons souvent vers des développeurs locaux qui sont très compétents, beaucoup moins coûteux que l'entreprise qui édite Drupal et ils sont à proximité.
L'exemple Drupal illustre bien à mon avis que même pour l'éditeur de ce logiciel il est bon d'avoir des compétences locales qui ont leur modèle économique (des fois ça commence par un consultant très propriétaire et qui ne sait juste pas comment contribuer), mais dans l'ensemble l'écosystème Drupal fonctionne et ces compétences locales même si elle n'apportent pas de revenus direct augmentent la reconnaissance de l'éditeur, sa porté et son prix horaire.
Autres discussions sur ce sujet : https://docs.google.com/document/d/1DOZpkJvzfa32cbSOpWlw3dp4m9fN1cLJ-SkV0tkFDJs/edit#