Entre frictions et fluidité : coordination décentralisée du programme du OuiShare Fest

Au mois de novembre dernier, nous nous lancions dans l’expérimentation d’une coordination décentralisée du programme du OuiShare Fest grâce à Backfeed. Après quelques mois, en voici la conclusion : les freins à l’utilisation d’une telle technologie sont encore immenses, tant sur le plan technique qu’humain, et les startups présentes sur le marché ne sont pas encore tout à fait matures.

Cet article vient clore une trilogie sur l’expérience de décentralisation menée au sein de OuiShare. Pour en savoir plus, vous pouvez lire le premier et le deuxième article publié sur le sujet.

Dans mon dernier article, je mettais en lumière les nombreuses questions auxquelles nous avons été confronté quand nous avons installé l’application Backfeed. Je voudrais maintenant revenir sur deux expériences concrètes que nous avons menées, et vous partager mes conclusions.

Experience Slack n°1 : évaluer les questions du programme

Comme première expérience, nous avons tout d’abord demandé aux Connectors OuiShare de proposer et d’evaluer les questions clés qui devaient selon eux figurer au programme du OuiShare Fest 2016. Pour ce faire, nous avons créé un channel Slack sur lequel nous avons activé le plugin Backfeed. Ainsi, chacun pourrait proposer et évaluer les idées des autres. Afin de garantir un haut niveau d’engagement sur un temps court, l’expérience a duré une semaine. L’objectif était de recourir à l’intelligence collective afin d’identifier les questions les plus pertinentes. Même si l’évaluation d’idées n’est pas exactement ce pour quoi Backfeed a initialement été conçu, nous cherchions dans un premier temps à nous familiariser avec l’outil. Voir les explications ici.

backfeed integration

Soumettre une contribution sur Backfeed à travers Slack

Moins de contributions… pas plus

Malgré la brièveté de cette première tentative, elle nous fit remonter des informations intéressantes : contrairement à ce à quoi je m’attendais, le fait d’être évalué n’a pas conduit les membres de l’équipe à soumettre davantage de contributions, mais moins. Chacun a participé activement aux conversations et exprimé ses idées dans le chat habituel, mais au moment de soumettre une contribution officielle à travers Backfeed, tout le monde hésitait. Quand je leur demandais pourquoi, ils répondaient la plupart du temps qu’ils préféraient attendre que leur proposition soit parfaite avant de la soumettre au groupe et qu’ils ne se sentaient pas totalement à l’aise à l’idée d’être évalués par le groupe. Comme l’explique Manuela Brito, une membre de l’équipe :

Savoir que les évaluations de l’équipe seraient visibles et auraient un impact sur ma réputation a clairement limité mon envie de contribuer.

Voir les résultats en détail de l’analyse qui a suivi cette expérience.

Expérience Slack n°2 : se regarder dans le miroir

Après cette première expérience, nous avons réalisé un second test afin d’utiliser l’outil Backfeed comme il est censé l’être : non pas pour évaluer des idées, mais un travail accompli. Pour cela, nous avons donc connecté notre outil de gestion de tâches Trello au channel Slack dédié à la gestion du programme. Ainsi, chaque tâche accomplie était automatiquement enregistrée comme une contribution à évaluer. Derrière cela, l’idée était en réalité d’intégrer Backfeed à notre quotidien de manière invisible, en minimisant au maximum le travail supplémentaire que cela représenterait pour les membres de l’équipe (ce qui a en fait été un point crucial).

Je craignais de devoir passer plus de temps à évaluer qu’à faire  David Weingartner, membre de l’équipe

Avant d’aller plus loin, j’aimerais souligner un autre point de blocage autour de l’évaluation. Lors d’une conversation avec l’équipe, il fut exprimé que non seulement les gens craignaient de soumettre des contributions, mais ils se sentaient aussi mal à l’aise à l’idée d’évaluer les contributions des autres par une simple note. Les informations manquaient, et il n’existait pas de consensus quant aux critères d’évaluation. Quelle était la bonne échelle de notation ? Quels étaient les critères ? Et que se passerait-il si nous changions d’avis après avoir soumis une évaluation ? J’avais le sentiment que nous devions d’abord nous mettre d’accord sur certains sujets clés avec le reste de l’équipe avant de commencer à l’utiliser” explique Ana Manzano. Cependant, après y avoir réfléchi, elle ajoute : “J’ai en fait réalisé que c’était une excuse pour ne pas utiliser l’outil, car je ne voulais pas reconnaître que j’avais simplement peur d’être évaluée”.

Il faut énormément de maturité, d’auto-critique et de détermination pour faire face aux défaut des autres et travailler quotidiennement dans un tel système

Et voilà où réside le véritable défi. Evaluer ses contributions et celles des autres est un immense défi, particulièrement sur le plan psychologique. Il faut énormément de maturité, d’auto-critique, et de détermination pour faire face aux défauts des autres et travailler quotidiennement dans un tel système. Des expériences de nouvelles pratiques de management qui intègrent une remise en question constante (par exemple l’holacratie ou les méthodes agiles) nous ont montré que ce type de système demande beaucoup d’efforts sur le plan individuel et ne convient pas à tout le monde. Depuis 2013, au sein de OuiShare, nous avons par exemple testé un système appelé value accounting pour distribuer les rémunérations. Cela a souvent été source de tensions, car le processus révèle des déséquilibres au sein du groupe.

Me voici donc partagée : d’un côté, je ne vois pas comment nous pouvons faire autrement que nous évaluer les uns les autres si nous voulons nous affranchir d’un système où cette autorité est le privilège d’une minorité installée en haut de la pyramide. Paradoxalement, à considérer le frein que représente le simple fait de tester l’outil dans ma propre équipe, il me semble vraiment compliqué de construire un système où chacun s’évalue sans en imposer les critères… de façon autocratique.

Entre frictions et fluidité

Mais revenons à cette question de la fluidité de l’expérience utilisateur. Puisque l’équipe avait exprimé sa peur de passer son temps à saisir des contributions dans le système, je faisais en sorte de rendre cette étape “invisible”. Aujourd’hui, le flux de contributions est automatique et indolore. Alors que les gens avaient initialement peur de contribuer, voilà qu’ils se sont retrouvés à le faire sans même s’en rendre compte, en continuant à travailler comme ils l’avaient toujours fait. Est-ce à dire que cela réduit leur degré de liberté, dans la mesure où il n’y a pas de consentement explicite au moment de la contribution ? La fluidité est elle prioritaire pour utiliser un outil de ce genre ? Quel est le bon niveau de friction ?

Une expérience utilisateur fluide est-elle indispensable pour ce genre d’outil ?

Evidemment, nous acceptons tous les jours des Conditions d’utilisation de sites internet que nous ne lisons pas et partageons nos données sans même le savoir. Comme l’explique Alexandre Stachtchenko de Blockchain France : “Bientôt, la plupart des applications blockchain fonctionneront sans que nous en ayons conscience ni que nous sachions quoi que ce soit de la technologie que nous utilisons.” Mais nous avons toujours le choix quant à la configuration initiale du système.

La décentralisation n’est pas neutre

Pour le moment, voici donc ma conclusion : les outils de coordination décentralisée reposant sur blockchain sont encore trop peu fiables et loin d’être prêts à l’emploi. Nous n’avons pas pas réussi à véritablement les utiliser de façon opérationnelle pour plusieurs raisons, parmi lesquelles l’immaturité de la technologie, le manque de temps, mais surtout le facteur humain. Les craintes de l’équipe le démontrent clairement : la décentralisation n’est pas une démarche neutre. D’une certaine manière, elle est même politique. Le fait d’utiliser un outil plutôt qu’un autre vous force à choisir une certaine façon de mesurer les échanges et la valeur créée. Dans ce cas précis, peut-être n’est-ce tout simplement pas ce que nous voulions.

Les conclusions de cette expérimentation montrent à quel point il est difficile de mettre sur pied un système de gouvernance adapté à un groupe tel que le nôtre. Peut-être est-ce l’une des raisons qui ont conduit l’équipe de Backfeed à remettre à plus tard le développement de cette application pour se concentrer sur d’adaptation de leur protocole à leur magazine ainsi qu’à une librairie décentralisée.


Read Part 1 and Part 2 of this article series.

The post Entre frictions et fluidité appeared first on OuiShare FR - Itinéraires pour une Société Collaborative by Francesca Pick.

Via un article de Francesca Pick, publié le 1er juin 2016

©© a-brest, article sous licence creative common info