Marie-Cécile Godwin Paccard est designer indépendante et chercheuse UX. Elle accompagne des personnes et des organisations dans la définition de leurs fondamentaux et objectifs, en apportant un regard systémique. Elle s’occupe de comprendre les usages en profondeur et de concevoir des outils utilisables, éthiques et inclusifs. Elle fait partie de l’équipe qui travaille sur le logiciel Mobilizon. Nous lui avons posé 3 questions pour qu’elle nous explique son rôle sur le projet.

Bonjour Marie-Cécile ! Vous avez accompagné le projet Mobilizon, afin que celui-ci corresponde, dès sa conception, aux besoins et usages des personnes qui sont vouées à l’utiliser. Pouvez-vous nous expliquer en quoi il est particulièrement important pour ce projet de prendre en compte les besoins et attentes des futur⋅es utilisateur⋅ices ?

Bonjour à toute l’équipe ! Étudier les besoins et les usages, c’est essentiel si l’on veut concevoir un logiciel, un service ou même un objet qui soit utilisable, et donc utilisé. Mobilizon a pour ambition de permettre aux personnes de s’organiser et de se rassembler, et de leur donner le pouvoir de le faire librement et respectueusement. Rien de mieux pour commencer à parler « usages » dès le début de la réflexion autour du projet ! Toute l’équipe qui travaille sur Mobilizon a le souhait que les communautés existantes s’en emparent et que de nouvelles communautés s’y créent. On ne pourra pas atteindre cet objectif si on ne fait pas l’effort d’aller à la rencontre des personnes pour comprendre ce dont elles ont besoin, quels problèmes elles rencontrent et comment elles ont fait pour y pallier jusqu’à présent.

Quand on conçoit des choses destinées à être utilisées par d’autres personnes, il est très important de ne pas se contenter de nos propres suppositions, croyances ou idées fixes et d’ouvrir notre esprit à la perception et à l’expérience d’autres personnes. Une courte phase de recherche en usages peut donner des résultats rapides et précieux et permettre d’identifier très en amont des problématiques et des objectifs auxquels on n’avait pas forcément pensé et qui vont nous aider à questionner nos présupposés de départ.

Quelle a été votre démarche pour recueillir la parole de ces utilisateur⋅ices (ou communautés) ?

D’abord, nous avons passé un temps de réflexion ensemble à bien cadrer le projet, ses ambitions, mais aussi ses implications politiques (car TOUT est politique, surtout dans le design et le logiciel, qui plus est libre !) et comment Mobilizon s’inscrivait dans la mission de Framasoft. Nous avons fait le point sur les plateformes d’organisation existantes et ce qu’elles engendraient comme problèmes qui empêchaient les gens de s’organiser librement. J’ai ensuite proposé un plan de recherche à l’équipe, pour bien définir ce vers quoi nous allions orienter la phase de recherche. Nous avons lancé une première enquête en ligne, qui a recueilli pas loin de 300 réponses. Dans cette enquête, nous demandions aux personnes répondantes comment elles s’organisaient en général pour se rassembler à l’aide des plateformes numériques, soit en tant qu’invitées, soit en tant qu’organisatrices elles-mêmes. Nous avons recueilli des informations précieuses sur les problèmes qu’elles pouvaient rencontrer, et pourquoi elles utilisaient ou pas tel ou tel outil numérique pour le faire.

Dans un deuxième temps, nous avons défini des typologies de communautés à qui nous souhaitions nous adresser. À nouveau, il fallait partir des usages : des communautés très grandes avec différents niveaux d’organisation qui créent des rassemblements publics, des communautés spécialisées qui organisent des événements thématiques, des organisations qui souhaitent assurer respect de la vie privée à elles et aux personnes qui participent à leurs événements, etc. Je suis ensuite partie à la recherche de personnes qui correspondaient à ces cas d’usages pour leur poser des questions sur leur manière de s’organiser. On ne parle pas encore de logiciel, de code ou de graphisme à ce point : on se focalise encore et toujours sur les usages, sur la réalité de l’organisation d’événements et aux problèmes bien concrets qui se posent aux personnes qui les mettent en place.

Comment ces éléments alimentent-ils la réflexion sur les fonctionnalités de Mobilizon ?

Une fois que la phase de recherche est bouclée, il est temps de tirer des conclusions sur les données recueillies. Quelle est la réalité des usages des personnes et comment concevoir un logiciel qui ira dans leur sens ? On va ensuite arbitrer nos décisions avec ces données.

Certaines choses parlent tout de suite d’elles-mêmes : si je me rends compte à travers quasiment tous les entretiens qu’une problématique revient tout le temps, cela veut dire qu’il faut la garder en tête tout au long de la conception et du développement et trouver la meilleure manière d’y répondre. Certes, il y a des problèmes très humains que Mobilizon ne pourra pas résoudre, par exemple les « no-show », les personnes qui indiquent qu’elles participeront à l’événement mais finissent par ne pas venir. Même si l’on a pas de solution logicielle pour résoudre ce souci, comprendre pourquoi il embête les organisateurs et organisatrices permet de prendre de meilleures décisions par la suite.

Mobilizon ne pourra pas être « one-size-fits-all » (taille unique). Seront couvertes en priorité les fonctionnalités que nous pensons indispensables aux petites communautés qui n’ont pas les moyens techniques de se rassembler ailleurs. On ne remplacera pas un Mattermost ou un WhatsApp, et on n’aura jamais la même force de frappe que Facebook. Mais Mobilizon proposera les fonctionnalités essentielles pour que les communautés les plus exposées au capitalisme de surveillance puissent migrer hors de Facebook, mais ne pourra pas remplacer les centaines de pads imbriqués ou les conversations vocales de Discord à plus de 30 personnes !

En ce moment, je suis en train de concevoir le « back office » de Mobilizon, et toute l’articulation de la « tuyauterie » qui va permettre de créer un événement, un groupe, d’inviter des personnes dans ledit groupe pour s’organiser en amont de l’événement, de définir les différentes identités avec lesquelles on pourra dire que l’on participe à un événement en cloisonnant son activité, de modérer les participations ou les questions et commentaires…

Avec le reste de l’équipe, nous nous posons également plein de questions sur la manière dont Mobilizon va accompagner les personnes dans la compréhension des principes de la fédération et des instances. Le but est de nous assurer que dans tous les cas, la personne qui souhaite utiliser une instance Mobilizon pour créer un événement sur le web accède simplement aux tenants et aboutissants de tel ou tel choix, pour prendre la décision qui lui convient le mieux. Cela va se traduire dans plein d’aspects de la conception du logiciel : comment va se dérouler l’inscription (« on boarding »), quels éléments vont permettre de comprendre le principe des instances dans le texte et dans l’interface, etc.

Pour en savoir plus sur le logiciel Mobilizon, c’est sur https://joinmobilizon.org/.
Vous pouvez aussi vous inscrire à la newsletter Mobilizon pour recevoir les informations sur l’évolution du logiciel.

Chaque mois le Fediverse s’enrichit de nouveaux projets, probablement parce nous désirons toujours plus de maîtrise de notre vie numérique.

Décentralisé et fédéré, ce réseau en archipel s’articule autour de briques technologiques qui permettent à ses composantes diverses de communiquer. Au point qu’à chaque rumeur de projet nouveau dans le monde du Libre la question est vite posée de savoir s’il sera « fédéré » et donc relié à d’autres projets.

Si vous désirez approfondir vos connaissances au plan technique et au plan de la réflexion sur la fédération, vous trouverez matière à vous enrichir dans les deux mémoires de Nathalie, stagiaire chez Framasoft l’année dernière.

Aujourd’hui, alors que l’idée de publier sur un blog semble en perte de vitesse, apparaît un nouvel intérêt pour la publication d’articles sur des plateformes libres et fédérées, comme Plume et WriteFreely. Maîtriser ses publications sans traqueurs ni publicités parasites, sans avoir à se plier aux injonctions des GAFAM pour se connecter et publier, sans avoir à brader ses données personnelles pour avoir un espace numérique d’expression, tout en étant diffusé dans un réseau de confiance et pouvoir interagir avec lui, voilà dans quelle mouvance se situe le projet DIFFU auquel nous vous invitons à contribuer et que vous présente l’interviewé du jour…

Bonjour, peux-tu te présenter, ainsi que tes activités ?

Bonjour Framasoft. Je m’appelle Jean-Pierre Morfin, on me connaît aussi sur les réseaux sociaux et dans le monde du libre sous le pseudo jpfox. J’ai 46 ans, je vis avec ma tribu familiale recomposée dans un village ardéchois où je pratique un peu (pas assez) le vélo. Informaticien depuis mon enfance, je suis membre du GULL G3L basé à Valence, où je gère avec d’autres l’activité C.H.A.T.O.N.S qui propose plusieurs services comme Mastodon, Diaspora, TT-Rss, boite mail, owncloud…

Passionnés par le libre, Michaël, un ami de longue date et moi-même avons créé en 2010 ce qui s’appelle désormais une Entreprise du Numérique Libre nommée Befox qui propose ses services aux TPE/PME dans la Drôme et l’Ardèche principalement : réalisation de sites à base de solutions libres comme Prestashop, Drupal ou autres, installation Dolibarr et interconnexion entre différents logiciels ou plateformes, hébergement applicatif, évolutions chez nos fidèles clients constituent l’essentiel de notre activité.

Et donc, vous voulez vous lancer dans le développement d’un nouveau logiciel fédéré, « Diffu ». Pourquoi ?

Tout d’abord nous avons ressenti tous les deux le besoin de retourner aux fondamentaux du Libre, et quoi de plus fondamental que le développement d’un logiciel ? Lors de nos divagations sur le Fédiverse, les remarques récurrentes qu’on y trouve ici ou là contre l’utilisation de Medium, nous ont fait penser qu’une alternative pouvait être intéressante. De plus, l’ouverture d’un compte Medium se fait nécessairement avec un compte Facebook ou Google, c’est leur façon d’authentifier un utilisateur ; en bons adeptes de la dégafamisation, c’est une raison de plus de créer une alternative à cette plateforme.

Voyant le succès et tout le potentiel de la Fédération, il fallait que cette nouvelle solution entre de ce cadre-là, car recréer une plateforme unique de publication ou un nouveau moteur de blog avec une gestion interne des commentaires ne présente aucun intérêt. Avec Diffu, la publication d’un article sur une des instances du réseau sera poussée sur le Fédiverse et les commentaires et réactions faits sur Mastodon, Pleroma, Hubzilla ou autre… seront agrégés pour être restitués directement sur la page de l’article. J’invite les lecteurs à jeter un œil à la maquette que nous avons réalisée pour se faire une idée, elle n’est pas fonctionnelle car cela reste encore un projet.

Quant au nom Diffu, on lui trouve deux sens : abréviation de Diffusion, ce qui reste l’objectif d’une plateforme de publication d’articles. Et dans sa prononciation à l’anglaise Diff You qui peut se comprendre Differentiate yourself – Différenciez vous ! C’est un peu ce que l’on fait lorsqu’on livre son avis, son expertise, ses opinions ou ses pensées dans un article.

Il existe déjà des logiciels fédérés de publication, tels que Plume ou WriteFreely. Quelles différences entre Diffu et ces projets ?

Absolument, ces deux applications libres, elles aussi, proposent de nombreux points de similitude avec Diffu notamment dans l’interconnexion avec le Fediverse et la possibilité de réagir aux articles avec un simple compte compatible avec ActivityPub.

La première différence est que pour Plume et WriteFreely, il est nécessaire de créer un compte sur l’instance que l’on souhaite utiliser. Avec Diffu, suivant les restrictions définies par l’administrateur⋅e de l’instance, il sera possible de créer un article juste en donnant son identifiant Mastodon par exemple (pas le mot de passe, hein, juste le pseudo et le nom de l’instance). L’auteur recevra un lien secret par message direct sur son compte Mastodon lui permettant d’accéder à son environnement de publication et de rédiger un nouvel article. Ce dernier sera associé à son auteur ou autrice, son profil Mastodon s’affichant en signature de l’article. Lors de la publication de l’article sur le Fediverse, l’autrice ou l’auteur sera mentionné⋅e dans le pouet qu’il n’aura plus qu’à repartager. L’adresse de la page de l’article sera utilisable sur les autres réseaux sociaux bien évidemment.

Nous voyons plus les instances Diffu comme des services proposés aux possesseurs de comptes ActivityPub. Comme on crée un Framadate ou un Framapad en deux clics, on pourra créer un article.

Les modes de modération et de workflow proposés par Diffu, la thématique choisie, les langues acceptées, la définition des règles de gestion permettront aux administrateurs de définir le public pouvant poster sur leur instance. Il sera par exemple possible de n’autoriser que les auteurs ayant un compte sur telle instance Mastodon, Diffu devenant un service complémentaire que pourrait proposer un CHATONS à ses utilisateurs Mastodon.

Ou, à l’opposé, un défenseur de la liberté d’expression peut laisser son instance Diffu open bar, au risque de voir son instance bloquée par d’autres acteurs du Fediverse, la régulation se faisant à plusieurs niveaux. Nous travaillons encore sur la définition des options de modération possibles, le but étant de laisser à l’administrateur⋅e toute la maîtrise des règles du jeu.

Les options retenues seront clairement explicites sur son instance pour que chacun⋅e puisse choisir la bonne plateforme qui lui convient le mieux. On imagine déjà faire un annuaire reprenant les règles de chaque instance pour aider les auteurs et autrices à trouver la plus appropriée à leur publication. Quitte à écrire sur plusieurs instances en fonction du sujet de l’article : « J’ai testé un nouveau vélo à assistance électrique » sur diffu.velo-zone.fr et « Comment installer LineageOS sur un Moto G4 » sur diffu.g3l.org.

L’autre différence avec Plume et WriteFreely est le langage retenu pour le développement de Diffu. Nous avons choisi PHP car il reste à nos yeux le plus simple à installer dans un environnement web et nous allons tout faire pour que ce soit vraiment le cas. Le locataire d’un simple hébergement mutualisé pourra installer Diffu : on dézippe le fichier de la dernière version, on envoie le tout par ftp sur le site, on accède à la page de configuration pour définir les options de son instance et ça fonctionne. Idem pour les mises à jour.

Nous avons déjà des contacts avec les dev de Plume qui sont tout aussi motivés que nous pour connecter nos plateformes et permettre une interaction entre les utilisateurs. C’est la magie du Fediverse !

Vous êtes en phase de crowdfunding pour le projet Diffu. À quoi va servir cet argent ?

Tout simplement à nous libérer du temps pour développer ce logiciel. On ne peut malheureusement pas se permettre de laisser en plan l’activité de Befox pendant des semaines car cela correspondrait à une absence complète de revenu pour nous deux. C’est donc notre société Befox qui va récolter le fruit de cette campagne et le transformer en rémunération. Nous avons visé au plus juste l’objectif de cette campagne de financement même si on sait que l’on va passer pas mal de temps en plus sur ce projet mais quand on aime…

Il faut aussi mentionner les 8 % de la campagne destinés à rétribuer la plateforme de financement Ulule.

Comment envisages-tu l’avenir de Diffu ?

Comme tout projet libre, après la publication des premières versions, la mise en ligne du code source, nous allons être à l’écoute des utilisateurs pour ajouter les fonctionnalités les plus attendues, garder la compatibilité avec le maximum d’acteurs du Fediverse. On sait que le protocole ActivityPub et ceux qui s’y rattachent peuvent avoir des interprétations différentes. On le voit pour les plateformes déjà en places comme Pleroma, Mastodon, Hubzilla, GNUSocial, PeerTube, PixelFed, WriteFreely et Plume… c’est une nécessité de collaborer avec les autres équipes de développement pour une meilleure expérience des utilisateurs.

Comme souvent ici, on te laisse le mot de la fin, pour poser LA question que tu aurais aimé qu’on te pose, et à laquelle tu aimerais répondre…

La question que l’on peut poser à tous les développeurs du Libre : quel éditeur de sources, Vim ou Emacs ?

La réponse en ce qui me concerne, c’est Vim bien sûr.

Plus sérieusement, cela me permet d’évoquer ce que je trouve génial avec les Logiciels Libres, le fait qu’il y en a pour tous les goûts, que si un outil ne te convient pas, tu peux en utiliser un autre ou modifier/faire modifier celui qui existe pour l’adapter à tes attentes.

Alors même si Plume et WriteFreely existent et font très bien certaines choses, ils sont tous les deux différents et je suis convaincu que Diffu a sa place et viendra en complément de ceux-ci. J’ai hâte de pouvoir m’investir à fond dans ce projet.

Merci pour cette interview, à bientôt sur le Fediverse !

• Contribuer au financement participatif de DIFF
• Une maquette de ce que ça pourra devenir

Protocole, HTTP, interopérabilité, ça vous parle ? Et normes, spécifications, RFC, ça va toujours ? Si vous avez besoin d’y voir un peu plus clair, l’article ci-dessous est un morceau de choix rédigé par Stéphane Bortzmeyer qui s’est efforcé de rendre accessibles ces notions fondamentales.

Protocoles

Le 21 mai 2019, soixante-neuf organisations, dont Framasoft, ont signé un appel à ce que soit imposé, éventuellement par la loi, un minimum d’interopérabilité pour les gros acteurs commerciaux du Web.

« Interopérabilité » est un joli mot, mais qui ne fait pas forcément partie du vocabulaire de tout le monde, et qui mérite donc d’être expliqué. On va donc parler d’interopérabilité, de protocoles, d’interfaces, de normes, et j’espère réussir à le faire tout en restant compréhensible (si vous êtes informaticien·ne professionnel·le, vous savez déjà tout cela ; mais l’appel des 69 organisations concerne tout le monde).

Le Web, ou en fait tout l’Internet, repose sur des protocoles de communication. Un protocole, c’est un ensemble de règles qu’il faut suivre si on veut communiquer. Le terme vient de la communication humaine, par exemple, lorsqu’on rencontre quelqu’un, on se serre la main, ou bien on se présente si l’autre ne vous connaît pas, etc. Chez les humains, le protocole n’est pas rigide (sauf en cas de réception par la reine d’Angleterre dans son palais, mais cela doit être rare chez les lectrices et lecteurs du Framablog). Si la personne avec qui vous communiquez ne respecte pas exactement le protocole, la communication peut tout de même avoir lieu, quitte à se dire que cette personne est bien impolie. Mais les logiciels ne fonctionnent pas comme des humains. Contrairement aux humains, ils n’ont pas de souplesse, les règles doivent être suivies exactement. Sur un réseau comme l’Internet, pour que deux logiciels puissent communiquer, chacun doit donc suivre exactement les mêmes règles, et c’est l’ensemble de ces règles qui fait un protocole.

Un exemple concret ? Sur le Web, pour que votre navigateur puisse afficher la page web désirée, il doit demander à un serveur web un ou plusieurs fichiers. La demande se fait obligatoirement en envoyant au serveur le mot GET (« donne », en anglais) suivi du nom du fichier, suivi du mot « HTTP/1.1 ». Si un navigateur web s’avisait d’envoyer le nom du fichier avant le mot GET, le serveur ne comprendrait rien, et renverrait plutôt un message d’erreur. En parlant d’erreurs, vous avez peut-être déjà rencontré le nombre 404 qui est simplement le code d’erreur qu’utilisent les logiciels qui parlent HTTP pour signaler que la page demandée n’existe pas. Ces codes numériques, conçus pour être utilisés entre logiciels, ont l’avantage sur les textes de ne pas être ambigus, et de ne pas dépendre d’une langue humaine particulière. Cet exemple décrit une toute petite partie du protocole nommé HTTP (pour Hypertext Transfer Protocol) qui est le plus utilisé sur le Web.

Il existe des protocoles bien plus complexes. Le point important est que, derrière votre écran, les logiciels communiquent entre eux en utilisant ces protocoles. Certains servent directement aux logiciels que vous utilisez (comme HTTP, qui permet à votre navigateur Web de communiquer avec le serveur qui détient les pages désirées), d’autres protocoles relèvent de l’infrastructure logicielle de l’Internet ; vos logiciels n’interagissent pas directement avec eux, mais ils sont indispensables.

Le protocole, ces règles de communication, sont indispensables dans un réseau comme l’Internet. Sans protocole, deux logiciels ne pourraient tout simplement pas communiquer, même si les câbles sont bien en place et les machines allumées. Sans protocole, les logiciels seraient dans la situation de deux humains, un Français ne parlant que français, et un Japonais ne parlant que japonais. Même si chacun a un téléphone et connaît le numéro de l’autre, aucune vraie communication ne pourra prendre place. Tout l’Internet repose donc sur cette notion de protocole.

Le protocole permet l’interopérabilité. L’interopérabilité est la capacité à communiquer de deux logiciels différents, issus d’équipes de développement différentes. Si une université bolivienne peut échanger avec une entreprise indienne, c’est parce que toutes les deux utilisent des protocoles communs.

Seuls les protocoles ont besoin d’être communs : l’Internet n’oblige pas à utiliser les mêmes logiciels, ni à ce que les logiciels aient la même interface avec l’utilisateur. Si je prends l’exemple de deux logiciels qui parlent le protocole HTTP, le navigateur Mozilla Firefox (que vous êtes peut-être en train d’utiliser pour lire cet article) et le programme curl (utilisé surtout par les informaticiens pour des opérations techniques), ces deux logiciels ont des usages très différents, des interfaces avec l’utilisateur reposant sur des principes opposés, mais tous les deux parlent le même protocole HTTP. Le protocole, c’est ce qu’on parle avec les autres logiciels (l’interface avec l’utilisateur étant, elle, pour les humain·e·s.).

La distinction entre protocole et logiciel est cruciale. Si j’utilise le logiciel A parce que je le préfère et vous le logiciel B, tant que les deux logiciels parlent le même protocole, aucun problème, ce sera juste un choix individuel. Malgré leurs différences, notamment d’interface utilisateur, les deux logiciels pourront communiquer. Si, en revanche, chaque logiciel vient avec son propre protocole, il n’y aura pas de communication, comme dans l’exemple du Français et du Japonais plus haut.

Babel

Alors, est-ce que tous les logiciels utilisent des protocoles communs, permettant à tout le monde de communiquer avec bonheur ? Non, et ce n’est d’ailleurs pas obligatoire. L’Internet est un réseau à « permission facultative ». Contrairement aux anciennes tentatives de réseaux informatiques qui étaient contrôlés par les opérateurs téléphoniques, et qui décidaient de quels protocoles et quelles applications tourneraient sur leurs réseaux, sur l’Internet, vous pouvez inventer votre propre protocole, écrire les logiciels qui le parlent et les diffuser en espérant avoir du succès. C’est d’ailleurs ainsi qu’a été inventé le Web : Tim Berners-Lee (et Robert Cailliau) n’ont pas eu à demander la permission de qui que ce soit. Ils ont défini le protocole HTTP, ont écrit les applications et leur invention a connu le succès que l’on sait.

Cette liberté d’innovation sans permission est donc une bonne chose. Mais elle a aussi des inconvénients. Si chaque développeur ou développeuse d’applications invente son propre protocole, il n’y aura plus de communication ou, plus précisément, il n’y aura plus d’interopérabilité. Chaque utilisatrice et chaque utilisateur ne pourra plus communiquer qu’avec les gens ayant choisi le même logiciel. Certains services sur l’Internet bénéficient d’une bonne interopérabilité, le courrier électronique, par exemple. D’autres sont au contraire composés d’un ensemble de silos fermés, ne communiquant pas entre eux. C’est par exemple le cas des messageries instantanées. Chaque application a son propre protocole, les personnes utilisant WhatsApp ne peuvent pas échanger avec celles utilisant Telegram, qui ne peuvent pas communiquer avec celles qui préfèrent Signal ou Riot. Alors que l’Internet était conçu pour faciliter la communication, ces silos enferment au contraire leurs utilisateurs et utilisatrices dans un espace clos.

La situation est la même pour les réseaux sociaux commerciaux comme Facebook. Vous ne pouvez communiquer qu’avec les gens qui sont eux-mêmes sur Facebook. Les pratiques de la société qui gère ce réseau sont déplorables, par exemple en matière de captation et d’utilisation des données personnelles mais, quand on suggère aux personnes qui utilisent Facebook de quitter ce silo, la réponse la plus courante est « je ne peux pas, tou·te·s mes ami·e·s y sont, et je ne pourrais plus communiquer avec eux et elles si je partais ». Cet exemple illustre très bien les dangers des protocoles liés à une entreprise et, au contraire, l’importance de l’interopérabilité.

Mais pourquoi existe-t-il plusieurs protocoles pour un même service ? Il y a différentes raisons. Certaines sont d’ordre technique. Je ne les développerai pas ici, ce n’est pas un article technique, mais les protocoles ne sont pas tous équivalents, il y a des raisons techniques objectives qui peuvent faire choisir un protocole plutôt qu’un autre. Et puis deux personnes différentes peuvent estimer qu’en fait deux services ne sont pas réellement identiques et méritent donc des protocoles séparés, même si tout le monde n’est pas d’accord.

Mais il peut aussi y avoir des raisons commerciales : l’entreprise en position dominante n’a aucune envie que des acteurs plus petits la concurrencent, et ne souhaite pas permettre à des nouveaux entrants d’arriver. Elle a donc une forte motivation à n’utiliser qu’un protocole qui lui est propre, que personne d’autre ne connaît.

Enfin, il peut aussi y avoir des raisons plus psychologiques, comme la conviction chez l·e·a créat·eur·rice d’un protocole que son protocole est bien meilleur que les autres.

Un exemple d’un succès récent en termes d’adoption d’un nouveau protocole est donné par le fédivers. Ce terme, contraction de « fédération » et « univers » (et parfois écrit « fédiverse » par anglicisme) regroupe tous les serveurs qui échangent entre eux par le protocole ActivityPub, que l’appel des soixante-neuf organisations mentionne comme exemple. ActivityPub permet d’échanger des messages très divers. Les logiciels Mastodon et Pleroma se servent d’ActivityPub pour envoyer de courts textes, ce qu’on nomme du micro-blogging (ce que fait Twitter). PeerTube utilise ActivityPub pour permettre de voir les nouvelles vidéos et les commenter. WriteFreely fait de même avec les textes que ce logiciel de blog permet de rédiger et diffuser. Et, demain, Mobilizon utilisera ActivityPub pour les informations sur les événements qu’il permettra d’organiser. Il s’agit d’un nouvel exemple de la distinction entre protocole et logiciel. Bien que beaucoup de gens appellent le fédivers  « Mastodon », c’est inexact. Mastodon n’est qu’un des logiciels qui permettent l’accès au fédivers.

Le terme d’ActivityPub n’est d’ailleurs pas idéal. Il y a en fait un ensemble de protocoles qui sont nécessaires pour communiquer au sein du fédivers. ActivityPub n’est que l’un d’entre eux, mais il a un peu donné son nom à l’ensemble.

Tous les logiciels de la mouvance des « réseaux sociaux décentralisés » n’utilisent pas ActivityPub. Par exemple,  Diaspora ne s’en sert pas et n’est donc pas interopérable avec les autres.

Appel

Revenons maintenant l’appel cité au début, Que demande-t-il ? Cet appel réclame que l’interopérabilité soit imposée aux GAFA, ces grosses entreprises capitalistes qui sont en position dominante dans la communication. Tous sont des silos fermés. Aucun moyen de commenter une vidéo YouTube si on a un compte PeerTube, de suivre les messages sur Twitter ou Facebook si on est sur le fédivers. Ces GAFA ne changeront pas spontanément : il faudra les y forcer.

Il ne s’agit que de la communication externe. Cet appel est modéré dans le sens où il ne demande pas aux GAFA de changer leur interface utilisateur, ni leur organisation interne, ni leurs algorithmes de sélection des messages, ni leurs pratiques en matière de gestion des données personnelles. Il s’agit uniquement d’obtenir qu’ils permettent l’interopérabilité avec des services concurrents, de façon à permettre une réelle liberté de choix par les utilisateurs. Un tel ajout est simple à implémenter pour ces entreprises commerciales, qui disposent de fonds abondants et de nombreu·ses-x programmeur·e·s compétent·e·s. Et il « ouvrirait » le champ des possibles. Il s’agit donc de défendre les intérêts des utilisateurs et utilisatrices. (Alors que le gouvernement, dans ses commentaires, n’a cité que les intérêts des GAFA, comme si ceux-ci étaient des espèces menacées qu’il fallait défendre.)

Qui commande ?

Mais au fait, qui décide des protocoles, qui les crée ? Il n’y a pas de réponse simple à cette question. Il existe plein de protocoles différents et leurs origines sont variées. Parfois, ils sont rédigés, dans un texte qui décrit exactement ce que doivent faire les deux parties. C’est ce que l’on nomme une spécification. Mais parfois il n’y a pas vraiment de spécification, juste quelques vagues idées et un programme qui utilise ce protocole. Ainsi, le protocole BitTorrent, très utilisé pour l’échange de fichiers, et pour lequel il existe une très bonne interopérabilité, avec de nombreux logiciels, n’a pas fait l’objet d’une spécification complète. Rien n’y oblige développeurs et développeuses : l’Internet est « à permission facultative ». Dans de tels cas, celles et ceux qui voudraient créer un programme interopérable devront lire le code source (les instructions écrites par le ou la programmeur·e) ou analyser le trafic qui circule, pour essayer d’en déduire en quoi consiste le protocole (ce qu’on nomme la rétro-ingénierie). C’est évidemment plus long et plus difficile et il est donc très souhaitable, pour l’interopérabilité, qu’il existe une spécification écrite et correcte (il s’agit d’un exercice difficile, ce qui explique que certains protocoles n’en disposent pas).

Parfois, la spécification est adoptée formellement par un organisme dont le rôle est de développer et d’approuver des spécifications. C’est ce qu’on nomme la normalisation. Une spécification ainsi approuvée est une norme. L’intérêt d’une norme par rapport à une spécification ordinaire est qu’elle reflète a priori un consensus assez large d’une partie des acteurs, ce n’est plus un acte unilatéral. Les normes sont donc une bonne chose mais, rien n’étant parfait, leur développement est parfois laborieux et lent.

Toutes les normes ne se valent pas. Certaines sont publiquement disponibles (comme les normes importantes de l’infrastructure de l’Internet, les RFC – Request For Comments), d’autres réservées à ceux qui paient, ou à ceux qui sont membres d’un club fermé. Certaines normes sont développées de manière publique, où tout le monde a accès aux informations, d’autres sont créées derrière des portes soigneusement closes. Lorsque la norme est développée par une organisation ouverte à tous et toutes, selon des procédures publiques, et que le résultat est publiquement disponible, on parle souvent de normes ouvertes. Et, bien sûr, ces normes ouvertes sont préférables pour l’interopérabilité.

L’une des organisations de normalisation ouverte les plus connues est l’IETF (Internet Engineering Task Force, qui produit notamment la majorité des RFC). L’IETF a développé et gère la norme décrivant le protocole HTTP, le premier cité dans cet article. Mais d’autres organisations de normalisation existent comme le W3C (World-Wide Web Consortium) qui est notamment responsable de la norme ActivityPub.

Par exemple, pour le cas des messageries instantanées que j’avais citées, il y a bien une norme, portant le doux nom de XMPP (Extensible Messaging and Presence Protocol). Google l’utilisait, puis l’a abandonnée, jouant plutôt le jeu de la fermeture.

Difficultés

L’interopérabilité n’est évidemment pas une solution magique à tous les problèmes. On l’a dit, l’appel des soixante-neuf organisations est très modéré puisqu’il demande seulement une ouverture à des tiers. Si cette demande se traduisait par une loi obligeant à cette interopérabilité, tout ne serait pas résolu.

D’abord, il existe beaucoup de moyens pour respecter la lettre d’un protocole tout en violant son esprit. On le voit pour le courrier électronique où Gmail, en position dominante, impose régulièrement de nouvelles exigences aux serveurs de messagerie avec lesquels il daigne communiquer. Le courrier électronique repose, contrairement à la messagerie instantanée, sur des normes ouvertes, mais on peut respecter ces normes tout en ajoutant des règles. Ce bras de fer vise à empêcher les serveurs indépendants de communiquer avec Gmail. Si une loi suivant les préconisations de l’appel était adoptée, nul doute que les GAFA tenteraient ce genre de jeu, et qu’il faudrait un mécanisme de suivi de l’application de la loi.

Plus subtil, l’entreprise qui voudrait « tricher » avec les obligations d’interopérabilité peut aussi prétendre vouloir « améliorer » le protocole. On ajoute deux ou trois choses qui n’étaient pas dans la norme et on exerce alors une pression sur les autres organisations pour qu’elles aussi ajoutent ces fonctions. C’est un exercice que les navigateurs web ont beaucoup pratiqué, pour réduire la concurrence.

Jouer avec les normes est d’autant plus facile que certaines normes sont mal écrites, laissant trop de choses dans le vague (et c’est justement le cas d’ActivityPub). Écrire une norme est un exercice difficile. Si on laisse beaucoup de choix aux programmeuses et programmeurs qui créeront les logiciels, il y a des risques de casser l’interopérabilité, suite à des choix trop différents. Mais si on contraint ces programmeuses et programmeurs, en imposant des règles très précises pour tous les détails, on empêche les logiciels d’évoluer en réponse aux changements de l’Internet ou des usages. La normalisation reste donc un art difficile, pour lequel on n’a pas de méthode parfaite.

Conclusion

Voilà, désolé d’avoir été long, mais les concepts de protocole et d’interopérabilité sont peu enseignés, alors qu’ils sont cruciaux pour le fonctionnement de l’Internet et surtout pour la liberté des citoyen·ne·s qui l’utilisent. J’espère les avoir expliqués clairement, et vous avoir convaincu⋅e de l’importance de l’interopérabilité. Pensez à soutenir l’appel des soixante-neuf organisations !

Après

Et si vous voulez d’autres informations sur ce sujet, il y a :

• Si vous aimez le son plutôt que l’écrit, le podcast de l’APRIL a parlé de l’interopérabilité.

We have less than 60 days to finance Mobilizon. Less than 60 days to promote our project of a free and federated alternative to Facebook events ; and to know how much we need to invest ourselves in it.

Change the software of the people who change the world?

From climate walks on Facebook to free software hackathons using Meetup: to change the world, utopians (like us!) too often organize themselves on the centralized platforms of web giants.

We are not going to repeat here how clicking on « I join » in a Facebook event « Vegan Barbecue for Social Justice » raises many issues: it says much more about you than you can imagine, it gives a significant power to Facebook advertisers and locks the event community into a tool that will prevent it from being self-organized and thus from enduring. And that’s without mentioning the rules of use of these platforms, which can lead to a closing, without the least justification, from one day to the next, of a group or a communtiy, and of which the centralized structure forms a potentially unique portal for security services and pirates with bad intentions.

Mock-up of an Event page in Mobilizon

At Framasoft, we thought it was important to take the time to think about an alternative that could change the situation. We have just spent a few months, with the help of two designers (Marie-Cécile Paccard and Geoffrey Dorne) who haved interviewed many activists so as to better understand their digital practices. We looked at what a tool that would really empower individuals and groups could look like.

The tool that surveillance capitalism companies will not make

If you think about it, it’s massively constraining to create a tool that is just good for sucking up and selling data from all over the world…. As long as we do not need (or want) to track people or maintain an unfair economic model, we can imagine a tool that makes a difference.

1. A tool that, even if basic, sets us free

The last thing Meetup, Eventbrite or Facebook want is for us to do without them, take their place and create our own event publishing platform. This is the first of the freedoms Mobilizon will offer: to free people from those money-, data- and attention-grabing companies.

Of course, you might not be able to install it on a server yourself and create your own Mobilizon instance. But the fact that a community, a trade union, an NGO, a movement, a federation, that is, any collective can freely emancipate itself from data-hungry platforms, feels essential to us.

Along these lines, making the source code, the « cooking recipe » of the software, public is paramount to us: not everyone can read it, but it is a guarantee of transparency and openness. If the team that develops it makes choices that do not suit me, I can set up my own team to experiment with different design choices and another governance system.

2. A tool that emancipates by federating

But here’s the thing: if my university creates its MobilizedCollege instance on the one hand, and my climate movement creates its EcoMobilized instance on the other, do I need to create an account on each site to keep up with the planned gatherings?

No: it would be a huge strain on end-users. This is why we want Mobilizon to be federated: each instance (event publication site) powered by Mobilizon will then be able to choose to exchange with other instances, to display more events than « just its own », and to promote interactions. The federation protocol, based on the most widespread standard (called ActivityPub), will also allow, in the long term, to build bridges with Mastodon (the free and federated alternative to Twitter), PeerTube (alternative to YouTube), and many other alternative services.

However, the concept of federation is not a magic wand. On the contrary, it requires even more effort: displaying your moderation policy, communicating with the people registered on your server, choosing with whom you can federate or not, applying your legal obligations (or practicing civil disobedience)… An emancipatory Mobilizon should, in our opinion, facilitate these relationships between the people who open their instance to registrations, and those who entrust them with their data.

3. A tool that is, ideally, user-friendly

Ideally, Mobilizon not only frees us from Facebook events, but also frees us from its groups. And to have user-friendly groups, you have to imagine messaging tools, moderation tools, in short: many features that make us autonomous.

Because a user-friendly tool is a tool that gives us power, that gives us control. Thus, it is a tool that allows each group to organize itself as it wishes. Ideally, Mobilizon offers groups a space to display links to its digital collaboration tools, whatever they are, even google docs (but honestly, Framapad: it’s even better :p).

Another example of empowerment: if I want my family, who invites me to the youngest child’s birthday, to see my militant commitment (say for a pride march), but not my cultural activities (say folk dance), I must be able to control it. Ideally, Mobilizon allows each account to create multiple identities to partition its groups and activities as desired.

4. A tool that is sustainable and resilient in the long run

Software is a constantly evolving tool. Of course, producing a first stable version is a challenge in itself. But it is also the first step in a longer process, where we discover uses and practices that were not anticipated, that we can support.

There are already many possible evolutions for Mobilizon: facilitate geolocation and mapping, develop a mobile application, improve ergonomics and interfaces… What other ideas will our collective intelligence produce when Mobilizon is operational and used?

But here it is, maintaining and growing a commons requires care, time and attention. We must give ourselves the means, and at Framasoft, we hope that the support given to this project will show an enthusiastic supportive public, thanks to which we will be able to plan for the long term.

What resources are being used to produce Mobilizon?

Creating such a tool, with no other goal than to build a digital commons, requires time, involvement and resources. At Framasoft, we are convinced of the importance that Mobilizon can have, in the long term, for many communities. But we are already working on many projects and lack the time and money to do everything…. Thus, we will not get involved without a strong signal that this tool is desired.

We have just opened a collection on joinmobilizon.org. We have given ourselves less than 60 days to know how well our approach will be supported. In concrete terms, the more you give, the more we will be involved in Mobilizon‘s development in the long term.

We have defined the following budgets:

• 20 000 € – Free and basic Mobilizon, where we will cover our expenses and deliver the code and design work to the community, after the release of version 1;
• 35 000 € – Emancipatory and federated Mobilizon, where we will also be able to implement the ActivityPub federation protocol, and all the tools that go with it, including a test instance, for demonstration;
• 50,000 € – Ideal and user-friendly Mobilizon which, in addition to the rest, will directly include all the features we dream of for version 1 (groups, messaging, multi-identity, external tool displays).
• Further – Sustainable and resilient Mobilizon, which development will be maintained by Framasoft beyond the V1 release, with advanced features.

From now on, and until July 10th, any donation made to Framasoft via the Joinmobilizon.org page will be attributed to the Mobilizon project. On July 10th, depending on the amount that has been reached, we will focus on developing the Mobilizon that you have supported. We plan to release a beta version in the fall of 2019, and a version 1 in the first half of 2020.

Mock-up of a Group page in Mobilizon

You have les than 60 days to determine our involvement

So we need your help. Together, we have less than 60 days to propose and explain this project to the associative, cultural and militant communities in France and abroad. Less than 60 days to convince them of the importance of supporting Mobilizon, without falling into the trap of easy shorthand like « it will replace Facebook » or otherwise « this is a revolution ».

It will therefore be necessary to take the time to speak, to exchange, to listen… to convince without marketing bullshit or claiming to be an authority. Because Mobilizon will not be a miracle instantaneous recipe: it is a first step towards more independence, an adventure that will evolve over time, and one that we wanted to start with you.

How far will we go? It is now in your hands… let’s Mobilize!

Les technologies qui permettent la décentralisation du Web suscitent beaucoup d’intérêt et c’est tant mieux. Elles nous permettent d’échapper aux silos propriétaires qui collectent et monétisent les données que nous y laissons.

Vous connaissez probablement Mastodon, peerTube, Pleroma et autres ressources qui reposent sur le protocole activityPub. Mais connaissez-vous les projets Aragon, IPFS, ou ScuttleButt ?

Aujourd’hui nous vous proposons la traduction d’un bref article introducteur à une technologie qui permet de produire et héberger son site web sur son ordinateur et de le diffuser sans le moindre serveur depuis un navigateur.

L’article original est issu de la série Dweb (Decentralized Web) publiée sur Mozilla Hacks, dans laquelle Dietrich Ayala met le projecteur sur toutes les initiatives récentes autour du Web décentralisé ou distribué.

Traduction Framalang : bengo35, goofy

Blue Link Labs et Beaker

par Tara Vancil

Nous sommes Blue Link Labs, une équipe de trois personnes qui travaillent à améliorer le Web avec le protocole Dat et un navigateur expérimental pair à pair qui s’appelle Beaker.

Nous travaillons sur Beaker car publier et partager est l’essence même du Web. Cependant pour publier votre propre site web ou seulement diffuser un document, vous avez besoin de savoir faire tourner un serveur ou de pouvoir payer quelqu’un pour le faire à votre place.

Nous nous sommes donc demandé « Pourquoi ne pas partager un site Internet directement depuis votre navigateur ? »

Un protocole pair-à-pair comme dat:// permet aux appareils des utilisateurs ordinaires d’héberger du contenu, donc nous utilisons dat:// dans Beaker pour pouvoir publier depuis le navigateur et donc au lieu d’utiliser un serveur, le site web d’un auteur et ses visiteurs l’aident à héberger ses fichiers. C’est un peu comme BitTorrent, mais pour les sites web !

Architecture

Beaker utilise un réseau pair-à-pair distribué pour publier des sites web et des jeux de données (parfois nous appelons ça des « dats »).

Les sites web dat:// sont joignables avec une clé publique faisant office d’URL, et chaque donnée ajoutée à un site web dat:// est attachée à un log signé.
Les visiteurs d’un site web dat:// peuvent se retrouver grâce à une table de hachage distribuée¹, puis ils synchronisent les données entre eux, agissant à la fois comme téléchargeurs et téléverseurs, et vérifiant que les données n’ont pas été altérées pendant le transit.

Techniquement, un site Web dat:// n’est pas tellement différent d’un site web https:// . C’est une collection de fichiers et de dossiers qu’un navigateur Internet va interpréter suivant les standards du Web. Mais les sites web dat:// sont spéciaux avec Beaker parce que nous avons ajouté une API (interface de programmation) qui permet aux développeurs de faire des choses comme lire, écrire, regarder des fichiers dat:// et construire des applications web pair-à-pair.

Créer un site Web pair-à-pair

Beaker rend facile pour quiconque de créer un nouveau site web dat:// en un clic (faire le tour des fonctionnalités). Si vous êtes familier avec le HTML, les CSS ou le JavaScript (même juste un peu !) alors vous êtes prêt⋅e à publier votre premier site Web dat://.

Les développeurs peuvent commencer par regarder la documentation de notre interface de programmation ou parcourir nos guides.

L’exemple ci-dessous montre comment fabriquer le site Web lui-même via la création et la sauvegarde d’un fichier JSON. Cet exemple est fictif mais fournit un modèle commun pour stocker des données, des profils utilisateurs, etc. pour un site Web dat:// : au lieu d’envoyer les données de l’application sur un serveur, elles peuvent être stockées sur le site web lui-même !

// index.html
Submit message
<script src="index.js"></script>

// index.js
// first get an instance of the website's files
var files = new DatArchive(window.location)
document.getElementById('create-json-button').addEventListener('click', saveMessage)
async function saveMessage () {
var timestamp = Date.now()
var filename = timestamp + '.json'
var content = {
timestamp,
message: document.getElementById('message').value
}

// write the message to a JSON file
// this file can be read later using the DatArchive.readFile API
await files.writeFile(filename, JSON.stringify(content))
}

Pour aller plus loin

Nous avons hâte de voir ce que les gens peuvent faire de dat:// et de Beaker. Nous apprécions tout spécialement quand quelqu’un crée un site web personnel ou un blog, ou encore quand on expérimente l’interface de programmation pour créer une application.

Beaucoup de choses sont à explorer avec le Web pair-à-pair !

• Pour Beaker, suivez le guide !
• Tara Vancil en conférence au JSConf EU 2018 : (YouTube) A Web Without Servers
• Documentation de Beaker
• Documentation de DAT
• p2pforever.org – un modeste carrefour de ressources pair-à-pair sur le Web
• Beaker sur GitHub
• Installer Beaker Browser
  • et parcourir l’article ci-dessus en DAT : dat://12420d10773ccc076898b7d782263cde666112b74dff6d4e1eabf2e4bfcdb672/

Documentation plus technique

• How Dat works, un guide en anglais qui expose tous les détails sur le stockage des fichiers avec Dat
• The Dat Protocol Book, également en anglais, plus complet encore.

À propos de Tara Vancil

Tara est la co-créatrice du navigateur Beaker. Elle a travaillé précédemment chez Cloudflare et participé au Recurse Center.

Vous avez aimé Dégooglisons Internet et pensez le plus grand bien de Contributopia ? Vous aimeriez savoir en quelques mots où notre feuille de route nous mènera en 2019 ? Cet article est fait pour vous, les décideurs pressés 🙂

Cet article présente de façon synthétique et ramassée ce que nous avons développé dans l’article de lancement de la campagne 2018-2019 : «Changer le monde, un octet à la fois».

Passé

Depuis 14 ans, Framasoft a créé un annuaire du logiciel libre, écrit et traduit des milliers d’articles, diffusé le logiciel libre sur de nombreux supports.

Depuis 4 ans, Framasoft montre qu’il est possible de décentraliser Internet avec l’opération « Dégooglisons Internet ». Le propos n’est ni de critiquer ni de culpabiliser, mais d’informer et de mettre en avant des alternatives qui existaient déjà, mais demeuraient difficiles d’accès ou d’usage.

De façon à ne pas devenir un nouveau nœud de centralisation, l’initiative CHATONS a été lancée, proposant de relier les hébergeurs de services en ligne qui partagent nos valeurs.

Présent

Depuis l’année dernière, avec sa feuille de route Contributopia, Framasoft a décidé d’affirmer clairement qu’il fallait aller au-delà du logiciel libre, qui n’était pas une fin en soi, mais un moyen de faire advenir un monde que nous appelons de nos vœux.

Il faut donc encourager la société de contribution et dépasser celle de la consommation, y compris en promouvant des projets qui ne soient plus seulement des alternatives aux GAFAM, mais qui soient porteurs d’une nouvelle façon de faire. Cela se fera aussi en se rapprochant de structures (y compris en dehors du mouvement traditionnel du libre) avec lesquelles nous partageons certaines valeurs, de façon à apprendre et diffuser nos savoirs.

Cette année a vu naître la version 1.0 de PeerTube, logiciel phare qui annonce une nouvelle façon de diffuser des médias vidéos, en conservant le contrôle de ses données sans se couper du monde, qu’on soit vidéaste ou spectateur.

Avenir

La campagne de don actuelle est aussi l’occasion de de rappeler des éléments d’importance pour Framasoft : nous ne sommes pas une grosse multinationale, mais un petit groupe d’amis épaulé par quelques salarié·e·s, et une belle communauté de contributeurs et contributrices.

Cette petite taille et notre financement basé sur vos dons nous offrent souplesse et indépendance. Ils nous permettront de mettre en place de nouveaux projets comme MobilZon (mobilisation par le numérique), un Mooc CHATONS (tout savoir et comprendre sur pourquoi et comment devenir un chaton) ou encore Framapétitions (plateforme de pétitions n’exploitant pas les données des signataires).

Nous voulons aussi tenter d’en appeler à votre générosité sans techniques manipulatoires, en vous exposant simplement d’où nous venons et où nous allons. Nous espérons que cela vous motivera à nous faire un don.

Faire un don pour soutenir les actions de Framasoft

Pour en savoir plus

• Un article détaillé sur l’année 2019 de Contributopia (13mn de lecture)
• La nouvelle page d’accueil de Framasoft, pour la campagne d’appel au don de cette fin d’année

Nous voulons façonner les outils que les géants du Web ne peuvent ni ne veulent créer. Pour y parvenir, nous avons besoin de votre soutien.

Penser hors des sentiers battus par les actionnaires

Pauvre MeetUp ! Pauvre Facebook avec ses événements et ses groupes ! Vous imaginez combien c’est dur, d’être une des plus grandes capitalisations boursières au monde ? Non mais c’est que les actionnaires ils sont jamais contents, alors il faut les arracher avec les dents, ces dividendes !

Nos pauvres petits géants du Web sont o-bli-gés de coder des outils qui ne vous donnent que très peu de contrôle sur vos communautés (familiales, professionnelles, militantes, etc.). Parce qu’au fond, les centres d’intérêt que vous partagez avec d’autres, c’est leur fonds de commerce ! Nos pauvres vendeurs de temps de cerveau disponible sont trop-for-cés de vous enfermer dans leurs plateformes où tout ce que vous ferez sera retenu envers et contre vous. Parce qu’un profil publicitaire complet, ça se vend plus cher, et ça, ça compte, dans leurs actions…

Et nous, internautes prétentieuses, on voudrait qu’ils nous fassent en plus un outil complet, éthique et pratique pour nous rassembler…? Mais on leur en demande trop, à ces milliardaires du marketing digital !

Comme on est choubidou chez Framasoft, on s’est dit qu’on allait leur enlever une épine du pied. Oui, il faut un outil pour organiser ces moments où on se regroupe, que ce soit pour le plaisir ou pour changer le monde. Alors on accepte le défi et on se relève les manches.

On ne changera pas le monde depuis Facebook

Lors du lancement de la feuille de route Contributopia, nous avions annoncé une alternative à Meetup, nom de code Framameet. Au départ, nous imaginions vraiment un outil qui puisse servir à se rassembler autour de l’anniversaire du petit dernier, de l’AG de son asso ou de la compète de son club d’Aïkido… Un outil singeant les groupes et événements Facebook, mais la version libre, qui respecte nos sphères d’intimité.

Puis, nous avons vu comment les « Marches pour le climat » se sont organisées sur Facebook, et comment cet outil a limité les personnes qui voulaient s’organiser pour participer à ces manifestations. Cliquera-t-on vraiment sur «ça m’intéresse» si on sait que nos collègues, nos ami·e·s d’enfance et notre famille éloignée peuvent voir et critiquer notre démarche ? Quelle capacité pour les orgas d’envoyer une info aux participant·e·s quand tout le monde est enfermé dans des murs Facebook où c’est l’Algorithme qui décide de ce que vous verrez, de ce que vous ne verrez pas ?

L’outil dont nous rêvons, les entreprises du capitalisme de surveillance sont incapables de le produire, car elles ne sauraient pas en tirer profit. C’est l’occasion de faire mieux qu’elles, en faisant autrement.

Nous avons été contacté·e·s par des personnes des manifestations #OnVautMieuxQueÇa et contre la loi travail, des Nuits Debout, des Marches pour le climat, et des Gilets Jaunes… Et nous travaillons régulièrement avec les Alternatiba, l’association Résistance à l’Agression Publicitaire, le mouvement Colibris ou les CEMÉA (entre autres) : la plupart de ces personnes peinent à trouver des outils permettant de structurer leurs actions de mobilisation, sans perdre le contrôle de leur communauté, du lien qui est créé.

Or « qui peut le plus peut le moins » : si on conçoit un outil qui peut aider un mouvement citoyen à s’organiser, à s’émanciper… cet outil peut servir, en plus, pour gérer l’anniversaire surprise de Tonton Roger !

Ce que MeetUp nous refuse, MobiliZon l’intègrera

Concevoir le logiciel MobiliZon (car ce sera son nom), c’est reprendre le pouvoir qui a été capté par les plateformes centralisatrices des géants du Web. Prendre le pouvoir aux GAFAM pour le remettre entre les mains de… de nous, des gens, des humains, quoi. Nous allons nous inspirer de l’aventure PeerTube, et penser un logiciel réellement émancipateur :

• Ce sera un logiciel Libre : la direction que Framasoft lui donne ne vous convient pas ? Vous aurez le pouvoir de l’emmener sur une autre voie.
• Comme Mastodon ou PeerTube, ce sera une plateforme fédérée (via ActivityPub). Vous aurez le pouvoir de choisir qui héberge vos données sans vous isoler du reste de la fédération, du « fediverse ».
• L’effet « double rainbow » de la fédération, c’est qu’avec MobiliZon vous donnerez à vos événements le pouvoir d’interagir avec les pouets de Mastodon, les vidéos PeerTube, les musiques de FunkWhale…
• Vous voulez cloisonner vos rassemblements familiaux de vos activités associatives ou de vos mobilisations militantes ? Vous aurez le pouvoir de créer plusieurs identités depuis le même compte, comme autant de masques sociaux.
• Vous voulez créer des événements réellement publics ? Vous donnerez le pouvoir de cliquer sur « je participe » sans avoir à se créer de compte.
• Il faut lier votre événement à des outils externes, par exemple (au hasard) à un Framapad ? Vous aurez le pouvoir d’intégrer des outils externes à votre communauté MobiliZon.

La route est longue, mais MobiliZon-nous pour que la voie soit libre !

Nous avons travaillé en amont pour poser des bases au projet, que nous vous présentons aujourd’hui sur JoinMobilizon.org. Au delà des briques logicielles et techniques, nous avons envie de penser à l’expérience utilisateur de l’application que les gens auront en main au final. Et qui, en plus, se doit d’être accessible et compréhensible par des néophytes.

Nous souhaitons éprouver ainsi une nouvelle façon de faire, en contribuant avec des personnes dont c’est le métier (designeurs et designeuses, on parlera très vite de Marie-Cécile et de Geoffrey !) pour œuvrer ensemble au service de causes qui veulent du bien à la société.

Le développement se fera par étapes et itérations, comme cela avait été le cas pour PeerTube, de façon à livrer rapidement (fin 2019) une version fonctionnelle qui soit aussi proche que possible des aspirations de celles et ceux qui ont besoin d’un tel outil pour se mobiliser.

Voilà notre déclaration d’intention. La question est : allez-vous nous soutenir ?

Car pour avancer vers la concrétisation de MobiliZon, et prolonger l’ensemble de nos projets, il n’y a pas de secrets : nous avons besoin de dons. Des dons qui, on le rappelle, restent déductibles des impôts (pour les contribuables français·es).

Pour notre campagne de dons de cette année, nous avons fait le choix de ne pas utiliser des outils invasifs qui jouent à vous motiver (genre la barre de dons qu’on a envie de voir se remplir). On a voulu rester sobre, et du coup c’est pas super la fête : on risque d’avoir du mal à ajouter MobiliZon dans notre budget 2019…

Alors si MobiliZon vous fait rêver autant que nous, et si vous le pouvez, pensez à soutenir Framasoft.

Faire un don pour soutenir les actions de Framasoft

Mastodon a déjà deux ans, et il est toujours vivant, n’en déplaise aux oiseaux de mauvais augure. Il est inadéquat de le comparer aux plateformes sociales, et Peter 0’Shaughnessy nous explique bien pourquoi…

Pourquoi Mastodon se moque de la « masse critique »

par Peter O’Shaughnessy, d’après son billet publié le 10/11/2018 sur son blog : Why mastodon is defying the critical mass

C’est une erreur de juger la Fediverse comme s’il s’agissait d’une startup de la Silicon Valley.

Mastodon a maintenant plus de deux ans et (pour emprunter une expression à Terry Pratchett), il n’est toujours pas mort. D’une manière ou d’une autre, il a réussi à défier les premiers critiques qui disaient qu’il « ne survivrait pas » et qu’il était « mort dans l’œuf ». Même certains de ceux qui postaient sur Mastodon à ses débuts doutaient de sa longévité :

Pari : le lien vers ce tweet ne fonctionnera plus dans deux ans – @jaffathecake@mastodon.social

Plus récemment, un article sur l’écosystème plus vaste qui comprend Mastodon, appelé La Fediverse, a fait la une de Hacker News : Qu’est-ce que ActivityPub, et comment changera-t-il l’Internet ? par Jeremy Dormitzer. C’est un bon argument en faveur de l’importance de la norme ActivityPub, sur laquelle reposent Mastodon et d’autres plateformes sociales. Cependant, il commet toujours la même erreur que ces premiers prophètes de malheur :

Le plus gros problème à l’heure actuelle, c’est l’adoption par les utilisateurs. Le réseau ActivityPub n’est viable que si les gens l’utilisent, et pour concurrencer de manière significative Facebook et Twitter, nous avons besoin de beaucoup de gens pour l’utiliser. Pour rivaliser avec les grands, nous avons besoin de beaucoup d’argent…

Des arguments similaires ont été présentés dans de nombreux articles au cours des derniers mois. Ils impliquent :

• que la valeur du réseau n’est proportionnelle qu’au nombre d’utilisateurs ;
• que ce ne sera vraiment un succès que s’il devient un remplacement massif pour Twitter et Facebook ;
• que si vous ne le rejoignez pas, il ne survivra pas.

Mais tout cela est faux. Voici pourquoi…

1. La Fediverse n’est pas une startup

Nous sommes tellement conditionnés de nos jours par le monde du capital-risque et des startups que nous pensons intuitivement que toutes les nouvelles entreprises technologiques doivent réussir ou faire faillite. Mais ce n’est pas la nature du modèle économique qui se cache derrière le Fediverse, qui est déjà durable, tout en continuant de fonctionner comme si de rien n’était.

Nous devons cesser de juger la Fediverse comme s’il s’agissait d’une startup de la Silicon Valley en concurrence avec Twitter et Facebook.

Jeremy a raison de dire que la plupart des instances sont  « créées et administrées par des bénévoles avec des budgets minuscules », mais il implique que cela doit changer, alors que la plupart des administrateurs et utilisateurs de Mastodon que je connais sont très satisfaits de ce modèle, qui nous libère des intérêts acquis et contradictoires des régies publicitaires.

C’est facile à dire pour moi, car je n’héberge pas ma propre instance et mon administrateur a gentiment refusé les offres de dons jusqu’ici. Cependant, dans la plupart des cas, il semble que tout se passe très bien, la plupart du temps grâce au financement participatif. Même si certaines instances ont été fermées à un moment donné (et c’est malheureusement le cas), il y en a d’autres qui se présentent à leur place. Malgré les fortes fluctuations à chaque nouvelle vague d’utilisateurs venant de Twitter, la trajectoire globale est à la hausse, et c’est ce qui importe — pas la vitesse de la croissance, ni l’atteinte d’un certain niveau de masse critique. Michael Mahemoff l’a bien dit :

« Mastodon est déjà « assez bon » dans sa forme initiale pour satisfaire plusieurs besoins de niche (les personnes qui veulent plus ou moins de modération ou des critères différents de modération, celles qui ne veulent pas de publicités, celles qui veulent des participant⋅e⋅s qui sont libres d’innover, celles qui veulent posséder et/ou héberger leur propre contenu, etc.). Comme Mastodon a un modèle de mécénat durable, il peut se développer au fil du temps et être capable de continuer à innover. »

En fait, si Mastodon se développait trop rapidement, cela pourrait avoir des conséquences plus négatives que positives. La croissance progressive permet aux instances existantes de mieux faire face à la charge et permet à de nouvelles instances d’émerger et de faire face à une partie du flux.

2. C’est aussi une question de qualité (d’expérience), pas seulement de quantité (d’utilisateurs et utilisatrices)

Lorsque j’ai rejoint Mastodon pour la première fois, j’ai été enthousiasmé par chaque nouvelle vague d’utilisateurs et utilisatrices venant de Twitter. Je voulais prêcher à ce sujet à autant de gens que possible et essayer d’amener autant d’amis que possible à « déménager ». Au bout d’un moment, j’ai pris conscience que je me concentrais trop sur la comparaison avec Twitter et que j’essayais d’en faire un remplaçant de Twitter. En fait, j’avais déjà un réseau précieux là-bas et suffisamment de raisons de le visiter régulièrement, même si j’ai continué à utiliser Twitter aussi.

Mastodon s’articule autour des communautés. Ces communautés peuvent être des réseaux spécialisés selon les  sujets qui vous intéressent. Vous n’avez pas besoin de tous vos amis pour être au sein de ces communautés, pour trouver des gens intéressants, du contenu utile et des interactions intéressantes.

Comme Vee Satayamas l’a noté, si vous êtes un utilisateur de Twitter, vous le trouverez peut-être utile même si peu de membres de votre famille ou d’amis réels sont présents. Vous n’avez pas besoin que tout le monde soit disponible sur chaque réseau. J’ai récemment quitté Facebook et j’ai quand même pu entrer en contact avec mes amis, par courriel ou par texto. Ce serait bien mieux si davantage de mes amis étaient sur Mastodon, mais ce n’est pas un gros problème.

En réalité, il y a quelque chose de positif dans la petite taille de mon réseau sur Mastodon. Je peux suivre ma chronologie, mon « fil »,  sans me sentir dépassé. C’est moins stressant d’y poster, comparé à Twitter, où chaque message que vous envoyez risque d’être republié par une horde géante ! Je suppose que c’est comparable à l’effet ressenti par les YouTubers, tel que détaillé dans cet intéressant article du Guardian, qui cite Matt Lees :

« Le cerveau humain n’est pas vraiment conçu pour interagir avec des centaines de personnes chaque jour… Lorsque des milliers de personnes vous envoient des commentaires directs sur votre travail, vous avez vraiment l’impression que quelque chose vous vient à l’esprit. Nous ne sommes pas faits pour gérer l’empathie et la sympathie à cette échelle. »

Pour moi, Mastodon offre un moyen terme heureux entre les conversations intimes des groupes WhatsApp, par exemple, et le potentiel sans limites de Twitter pour découvrir de nouvelles personnes et de nouveaux contenus.

D’après mon expérience, la plupart des utilisateurs actifs de Mastodon ne veulent pas qu’il ressemble davantage à Twitter — et ne ressentent pas le besoin que tous ceux qui sont sur Twitter les rejoignent. Par exemple, ces personnes apprécient le fait qu’il n’y a pas de publicitaires et très peu de marques. Pour les gens qui ne s’inquiètent que de leur « influence », alors c’est sûr, Mastodon n’aura pas autant de valeur. Mais la plupart de celles et ceux qui sont sur Mastodon ne regretteront pas trop de ce genre de personnes venues de Twitter !

Nous devons cesser de considérer Mastodon comme un substitut potentiel de Twitter. C’est différent, et c’est délibéré. Je comprends qu’on se plaise à imaginer que la Fediverse pourrait un jour écraser Twitter et Facebook, mais je ne pense pas que ce soit réaliste (du moins pas dans un avenir proche). Je pense que ce sera toujours l’outsider et c’est très bien ainsi, d’une certaine façon.

3. C’est un écosystème ouvert

La Fediverse ne gagne pas seulement de la valeur à partir de la quantité d’utilisateurs, elle en gagne aussi à partir de la quantité de services. S’appuyer sur le standard ActivityPub implique que nous pouvons utiliser Mastodon, PeerTube (un service semblable à YouTube), PixelFed (un service semblable à Instagram) et beaucoup d’autres, qui peuvent tous interopérer. Cela donne à la Fediverse un avantage d’échelle par rapport aux plateformes propriétaires closes. C’est un point que l’article de Jeremy a bien fait ressortir :

« Parce qu’il parle le même « langage », un utilisateur de Mastodon peut suivre un utilisateur de PeerTube. Si l’utilisateur de PeerTube envoie une nouvelle vidéo, elle apparaîtra dans le flux de l’utilisateur Mastodon. L’utilisatrice de Mastodon peut commenter la vidéo PeerTube directement depuis Mastodon. Pensez-y une seconde. Toute application qui implémente ActivityPub fait partie d’un réseau social étendu, qui conserve le choix de l’utilisateur et pulvérise les jardins propriétaires clos. Imaginez que vous puissiez vous connecter à Facebook et voir les messages de vos amis sur Instagram et Twitter, sans avoir besoin de compte Instagram ni de compte Twitter. »

Cela signifie également que si nous avons l’impression que le service que nous utilisons ne va pas dans la direction qui nous convient (coucou, utilisateurs de Twitter 👋), alors nous pouvons passer à une autre instance et conserver l’accès à l’écosystème global.

La Fediverse s’accroît et c’est une bonne chose. Mais elle n’a pas besoin de davantage d’utilisatrices. Transmettre l’idée qu’on pourrait échouer sans une migration massive à partir d’autres plateformes sociales est une perspective trompeuse. Et défendre cette idée donnerait aux gens la fausse impression, lorsqu’ils rejoindront ce réseau social, qu’on devrait rechercher la quantité d’utilisateurs et utilisatrices, plutôt que la qualité de l’expérience.

Alors ne comptons pas trop le nombre d’inscrit⋅e⋅s sur Mastodon. Allons doucement en le comparant à Twitter. Arrêtons de le traiter comme s’il s’agissait d’une situation à la Highlander où « il n’y a de la place que pour un seul ». Et commençons à profiter de la Fediverse pour ce qu’elle est — quelque chose de différent.

Merci à Jeremy Dormit d’avoir été très gentil avec moi en critiquant cette partie de son billet de blog (qui m’a beaucoup plu par ailleurs) – voici sa réponse à mon pouet qui a mené à ce billet. Merci aussi à mes anciens collègues de Samsung Internet qui ont jeté un coup d’œil à une version antérieure de ce post.