J’illustrais dernièrement mon propos sur les réseaux sociaux par le traitement des bugs de Diaspora*. J’aurai pu prendre d’autres exemples qui montre les limites d’une structure dite participative.

Dans ce que je remontais, je voyais qu’il existait une liste de bugs avec des classements par Tags/étiquettes. Pourtant, il manquait pour moi deux éléments de classement important : La redondance du bug et son importance pour l’ensemble des utilisateurs. Ces deux élements permettent ensuite de prioriser le traitement des bugs. Car en l’état, si chaque développeur ou participant au projet prend une liste brute, il va prendre ce qui le motive, ce qu’il sait faire, mais cela risque d’être orienté sur des bugs mineurs ou faciles à régler. Car l’autre élément permettant de prioriser est aussi la facilité de trouver une solution. Il faut pour cela qu’un collège d’experts puisse juger de cette facilité, et là on peut vite atteindre les limites du système du logiciel libre.

Je lisais récemment la bio de saint Richard… On voit justement l’illustration de ce problème dans ce qu’il a pu accomplir (et ne pas accomplir…). Certains projets ont pris trop de temps parce qu’une personne pensait faire tout, toute seule, à sa manière. La création de GNU Linux tient pour beaucoup à quelques personnalités providentielles aussi et qui ont fait bifurquer les choses dans diverses directions. Le relationnel entre développeurs n’a pas permis de trancher sur des solutions à adopter et n’avoir qu’une voie. Aujourd’hui encore, on voit des projets persister avec lenteur ou péricliter, malgré de bonnes idées. Et parfois on a pu aller sur des fausses pistes ce qui aboutit, dans le domaine du libre, à des forks, donc à une division des forces de création. On atteint donc les limites du système aussi à cause de l’humain. Il y a besoin donc d’une autorité, chacun en conviendra, pour donner des orientations. Mais si cette autorité devient dictatoriale, ça ne marche pas. Si au contraire, elle est influençable, ça ne marche pas non plus. Il s’agit véritablement d’une capacité à fédérer et manager, ce qui n’est pas donné à tout le monde et pour tous les types d’intervenants.

J’ai participé bien des fois à des projets de traduction sur diverses plateformes. Là encore, il y a une structure à respecter et chaque participant va proposer une traduction sur une partie du texte, selon ses capacités. On peut vite atteindre des incohérences entre les paragraphes si on travaille avec des oeillères. Certains passages plus complexes ou techniques ne seront même pas traduits. Il y a des interprétations ou différentes possiblités de traduction selon le contexte. Si chaque traducteur bosse dans son coin, on atteint un mauvais résultat qui devra être relu par une autre/d’autres personne(s). Ces personnes devront alors trancher sur les incohérences et sont donc réputées comme les référentes. Leur retour doit aussi être connu des participants afin de ne pas reproduire les mêmes erreurs, voir débattre de la solution adoptée. La plupart du temps, la possibilité d’un tel retour n’est pas possible. Mais il existe pourtant des solutions qui marchent pas mal, comme par exemple chez Duolingo sur les textes proposés, qui servent à la fois d’entraînement mais aussi à proposer des variantes linguistiques sur des articles de Wikipedia. Le système fonctionne en fait sur une répartition des rôles et une structure hiérarchique. Thierry parle aussi de la confiance nécessaire dans le logiciel…ce que l’on peut étendre ailleurs. Effectivement, il faut en avoir à l’intérieur du projet, quel qu’il soit, tout comme la transmettre aux utilisateurs/lecteurs.

En politique, on pourrait parler du système d’écriture d’une constitution, un thème très à la mode. Chaque citoyen peut participer, sur le papier. Mais dans l’écriture, dans l’architecture d’une constitution, il y a des attendus, des manières de rédiger, de contourner les interprétations. Il y a besoin d’une ligne directrice, d’une animation. Ils sont l’objet de référents, de sages, mais cela peut aussi amener à orienter un peu trop le projet. On l’a vu récemment en Tunisie, par exemple. Pourtant, bien des projets participatifs peuvent fonctionner sur une échelle plus réduite, avec un bon animateur qui sait rester neutre tout en se gardant d’avoir de trop fortes personnalités. Toutefois, sur ce même sujet politique, wikipedia a parfois du mal à apporter une vision factuelle et neutre sur des périodes historiques récentes.

En entreprise, il y a aussi des actions qui appellent la participation de chacun. Cela peut être un projet pour réaliser un prototype, ou simplement le rangement d’un atelier et son organisation. Je suis, par exemple, confronté à cette problématique pour un constat mensuel sur la propreté d’un local partagé par une dizaine de personnes. J’ai effectivement le choix entre faire tout tout seul, sans concertation, afficher le constat et attendre que ça se passe, demander à chacun de prendre une action, ou nommer carrément les gens. Je vous laisse deviner ce qui marche ou ne marche pas, ou comment la solution peut différer selon les personnalités.

Le problème central reste l’humain et la conscience de chacun de travailler pour les autres plutôt que pour soi-même, de regarder le besoin dans son ensemble et pas seulement dans son périmètre connu. Comme pour toute décision à prendre, il n’y a pas de recette miracle. Dans le logiciel libre, on a eu de nombreux clashs autour de décisions d’une communauté de développeurs, et c’est loin d’être fini. Mais cela ne tient pas seulement au sujet du libre, mais simplement aux personnes qui sont dans le projet. J’y vois donc des limites, ce qui n’empêche aucunement d’en voir les bienfaits. Reste à voir finalement ce qui l’emportera dans chaque branche. Comme un arbre, il y aurait besoin d’élaguer avant qu’il ne s’écroule.

PS : notez la création de Wallabag.it par les créateur de cette alternative à Pocket en libre. Pour 9 euros/an (ou 12 plus tard) vous aurez un service hébergé avec un excellent support du développeur. J’ai pu l’expérimenter sur l’appli android…