A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

index.md 16KB

4 vuotta sitten
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114
  1. title: Commoniser les prestations
  2. url: http://unisson.co/fr/wiki/prestation/
  3. hash_url: 817d232d98ee6c2e5f266582c3c47628
  4. <h1 id="contexte-et-enjeux">Contexte et enjeux</h1>
  5. <blockquote>
  6. <p><strong>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.</strong></p>
  7. </blockquote>
  8. <p><strong>Par exemple :</strong>
  9. 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.</p>
  10. <h2 id="pourquoi">Pourquoi ?</h2>
  11. <p>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".</p>
  12. <h3 id="interets-pour-les-parties-prenantes">Intérêts pour les parties prenantes</h3>
  13. <p><strong>Commanditaire de la prestation (Porteur d'un projet ayant une "commande", collectivité, entreprise, etc...)</strong></p>
  14. <ul>
  15. <li>Trouvez rapidement des ressources pertinentes</li>
  16. <li>Evitez de financer un travail déjà réalisé</li>
  17. <li>Evitez de re-inventer ce qui est déjà disponible</li>
  18. <li>Inspirez vous des autres, copiez sereinement</li>
  19. <li>Vous pourrez à votre tour valoriser votre savoir-faire développé.</li>
  20. </ul>
  21. <p><strong>Prestataire (Personne répondant à la commande de type consultant, Coordinateur, pilote d'une réponse)</strong></p>
  22. <ul>
  23. <li>Coopérez avec d'autres en amont de la réponse</li>
  24. <li>Trouvez les personnes et les ressources les plus pertinentes</li>
  25. <li>Instaurez un climat de confiance entre la prestation et son environnement</li>
  26. <li>Facilitez la coopération entre les acteurs</li>
  27. <li>Concentrez-vous sur votre seul rôle d'accompagnateur, de coordinateur ou d'animateur.</li>
  28. </ul>
  29. <p><strong>Commoners (Acteurs du terrain, Contributeurs d'initiatives ayant acquis un savoir-faire à partager et ayant à disposition des ressources)</strong></p>
  30. <ul>
  31. <li>Positionnez vous sur des missions même sans grande notoriété</li>
  32. <li>Favoriser le financement du "commun" et de votre savoir-faire</li>
  33. <li>Favorisez le partage de votre savoir faire et facilitez la duplication d'initiatives</li>
  34. <li>Garantissez les processus de production de biens communs</li>
  35. <li>Connectez les initiatives entre elles, avec les réseaux, les collectifs</li>
  36. <li>Favoriser l'appropriation de la question des communs par les commanditaires</li>
  37. <li>Mettre le commanditaire dans la voie de l'utilisation de communs. Une fois l'usage d'un "commun" enclenché, le commanditaire apprend à l'utiliser potentiellement pour le long terme.</li>
  38. </ul>
  39. <h3 id="les-differents-roles-pour-organiser-laccompagnement-par-un-collectif-de-commoners">Les différents rôles pour organiser l'accompagnement par un collectif de commoners</h3>
  40. <p>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.</p>
  41. <h3 id="le-role-de-garant-de-la-methodologie-et-de-connecteur">Le rôle de garant de la méthodologie et de connecteur</h3>
  42. <p>Il s'agit d'octroyer tous les moyens à la prestation pour qu'elle puisse s'organiser dans des logiques de "commun".</p>
  43. <p><strong>Sa raison d'être :</strong> Identifier les "communs" adaptés aux enjeux de la prestation et s'assurer de la bonne application de la méthodologie.</p>
  44. <p><strong>Son domaine de contrôle :</strong> l'identification des "communs" et la méthodologie du projet.</p>
  45. <p><strong>Ses redevabilités :</strong></p>
  46. <ul>
  47. <li>Identifier les "communs" et leurs "commoners" sur lesquels se baser pour répondre au prestataire.</li>
  48. <li>Jouer le médiateur entre les "commoners" et le prestataire/commanditaire afin d'instaurer un climat de confiance.</li>
  49. <li>Rôle pédagogique : Faire comprendre et transmettre les logiques de "communs libres" et leur fonctionnement (voir les 10 briques)</li>
  50. </ul>
  51. <h3 id="le-role-des-commoners-aidant">Le rôle des "commoners aidant"</h3>
  52. <p>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.</p>
  53. <p><strong>Sa raison d'être :</strong> 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.
  54. <strong>Son domaine de contrôle :</strong> la connaissance du "commun"
  55. <strong>Ses redevabilités :</strong><br/>
  56. - être transparent sur son action auprès de sa communauté.
  57. - identifier par rapport aux problématiques ou enjeux du projet la manière d'articuler le "commun"
  58. - 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...).
  59. - connecter sur le long terme l'initiative accompagnée avec les acteurs et communautés de "commoners" qui lui correspondent.</p>
  60. <h3 id="le-role-de-coordinateur-assure-par-le-consultant-le-prestataire">Le rôle de coordinateur (assuré par le consultant, le prestataire)</h3>
  61. <p>Il s'agit d'articuler les contributions entre elles et d'effectuer le suivi du projet tout le long de la mission.</p>
  62. <p>Le coordinateur n'est pas un rôle spécifique à la méthodologie Unisson. </p>
  63. <p><strong>Sa raison d'être :</strong> organiser la réalisation de la mission.
  64. <strong>Son domaine de contrôle :</strong> la coordination, la compréhension des enjeux de la prestation
  65. <strong> Ses redevabilités :</strong>
  66. - Comprendre les enjeux de la mission et les remonter pour permettre d'identifier les "communs" sur lesquels se baser.
  67. - effectuer les tâches rédactionnelles
  68. - gérer l'organisation spacio-temporelle
  69. - jouer l'interlocuteur avec le commanditaire</p>
  70. <h3 id="qui-peut-devenir-garant-connecteur">Qui peut devenir "garant-connecteur" ? &gt;</h3>
  71. <p>Toute personne connaissant très bien les "communs", leur fonctionnement, et ayant bien compris la méthode décrite ici. </p>
  72. <p>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.</p>
  73. <h3 id="qui-peut-devenir-commoners-aidant">Qui peut devenir "commoners aidant" ? &gt;</h3>
  74. <p>Toute personne ayant une expérience forte sur un "commun" utilisé durant la prestation.
  75. Outre cette stricte règle, l'intervenant "commoners aidant" peut s'auto-déterminer.</p>
  76. <p>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</p>
  77. <h3 id="quels-prestataires-peuvent-demander-a-faire-appel-a-cette-methode">Quels "prestataires" peuvent demander à faire appel à cette méthode ?</h3>
  78. <p>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. </p>
  79. <p>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". </p>
  80. <h3 id="quel-est-le-statut-des-intervenants-unisson-garant-ou-acteur-du-terrain">Quel est le statut des intervenants Unisson (garant ou acteur du terrain) ? &gt;</h3>
  81. <p>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.</p>
  82. <h3 id="etre-remuneree-s">Etre rémunéré(e-s)</h3>
  83. <p>Actuellement les rémunérations se discutent pour chaque projet. Cette question devra être complétées au fur et à mesure des expériences.</p>
  84. <h1 id="point-de-depart">Point de départ</h1>
  85. <h3 id="le-commoner-un-usager-plutot-quun-entrepreneur-au-sens-classique">Le "commoner", un usager plutôt qu'un entrepreneur au sens classique</h3>
  86. <p>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.</p>
  87. <h3 id="la-difficulte-dintegrer-des-sachant-faire-ou-commoners-et-leurs-communs-dans-les-prestations">La difficulté d'intégrer des "sachant faire" ou "commoners" et leurs "communs" dans les prestations</h3>
  88. <p>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 :</p>
  89. <h4 id="1-contributeur-benevole">1 - Contributeur bénévole</h4>
  90. <p>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 :</p>
  91. <ul>
  92. <li>Les acteurs accompagnés pourraient avoir l'impression d'un manque de sérieux car le travail sera fait "rapidement". </li>
  93. <li>Alors que ce savoir faire est crucial et a besoin d'être répliqué ou diffusé, il ne sera pas transmis et restera dans les mains des commoners. </li>
  94. <li>Les commoners n'auront pas le temps de veiller à ce que leurs conseils soient bien compris, avec le risque que des idées comme "il faut des lieux partagés pour fabriquer ensemble" soient transformées en "il faut des imprimantes 3D dans chaque
  95. foyer".</li>
  96. </ul>
  97. <h4 id="2-des-non-commoners-repondent-sans-se-baser-sur-les-communs">2 - Des "non commoners" répondent sans se baser sur les communs</h4>
  98. <p>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). </p>
  99. <h4 id="3-des-commoners-se-positionnent-en-consultants">3 - Des commoners se positionnent en "consultants"</h4>
  100. <p>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. </p>
  101. <p>La solution que nous soutenons est que ceux qui répondent au missions de conseil expliquent qu'ils vont, une fois sélectionnés, <strong>se baser et soutenir le développement des "communs"</strong>, en adoptant une méthodologique qui le permet vraiment, en associant les <strong>commoners</strong>.</p>
  102. <p>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 <a class="wikipath" href="http://unisson.co/fr/wiki/financement/">financement</a> et partenariat <a class="wikipath" href="http://unisson.co/fr/wiki/public/">public</a></p>
  103. <h2 id="outil-dorganisation-des-prestations">Outil d'organisation des prestations</h2>
  104. <p>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.
  105. Voir à ce sujet le tableau suivant :
  106. <a href="https://docs.google.com/spreadsheet/ccc?key=0AjUW0ZSBFWPedDFtYzZod29DZUdwQTVPT0hNaTdjY1E&amp;usp=drive_web#gid=0" target="_blank"><span class="icon-external-link"/><span> https://docs.google.com/spreadsheet/ccc?key=0AjUW0ZSBFWPedDFtYzZod29DZUdwQTVPT0hNaTdjY1E&amp;usp=drive_web#gid=0</span></a></p>
  107. <p>Exemples de réponses dans des AAP ou Appels d'offres : <a class="wikipath" href="http://unisson.co/fr/wiki/prestation/modele/">Page de modèles</a></p>
  108. <h1 id="exemples-du-logiciel-libre">Exemples du logiciel libre</h1>
  109. <p>Alexandre Poltorak</p>
  110. <p>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é.</p>
  111. <p>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.</p>
  112. <p>Autres discussions sur ce sujet : <a href="https://docs.google.com/document/d/1DOZpkJvzfa32cbSOpWlw3dp4m9fN1cLJ-SkV0tkFDJs/edit#" target="_blank"><span class="icon-external-link"/><span> https://docs.google.com/document/d/1DOZpkJvzfa32cbSOpWlw3dp4m9fN1cLJ-SkV0tkFDJs/edit#</span></a></p>