Voici aujourd’hui le 5^e et dernier article que Nicolas Vivant consacre à la dégooglisation de la ville d’Échirolles (si vous avez raté les épisodes précédents). Maintenant que les outils sont en place, il est temps d’envisager comment la mutualisation et la décentralisation conjuguées pourraient ouvrir de nouvelles perspectives aux citoyens et citoyennes de l’agglomération.

---

Le grand absent de ce récit est le travail important entamé sur la réduction de l’impact environnemental du numérique. C’est un fil conducteur permanent pour notre action. De nombreuses choses sont faites, mais d’autres décrivent beaucoup mieux que nous les enjeux, les outils et ce qu’il convient de faire pour avancer. Leur travail nous sert de guide. J’y reviendrai dans un article (modeste et) dédié.

Voir plus loin pour viser juste

Une vision pour l’avenir, ce n’est pas une prédiction, ni même une prévision. C’est simplement un axe, une direction. C’est ce qui permet, quand deux chemins existent, de faire un choix. Ce n’est évidemment pas une garantie que ce choix soit le bon mais si, à chaque carrefour, une direction existe qui aide à se déterminer, alors nous gagnons en cohérence, en rapidité de décision et, finalement, en efficacité.

Dans un monde où la dégooglisation serait une réalité, où les logiciels libres seraient dominants et où transparence et partage des données s’imposeraient comme une évidence, quel pourrait être l’étape suivante ? Et quelles pierres poser, dès aujourd’hui, qui tendraient vers cet objectif et pourraient orienter notre action ?

La décentralisation comme facteur de résilience

Historiquement, l’internet public est une architecture décentralisée. C’est même l’une des raisons de sa création : l’interconnexion de réseaux divers, dans un but de coopération. Même si le récit d’un internet construit comme un réseau permettant de résister à une attaque nucléaire est une légende urbaine, les événements récents ont permis de vérifier que la décentralisation était bien l’une des clés de la résilience des systèmes d’information.

En France, la plupart des accès résidentiels reposent sur Orange, Free, Bouygues et SFR. Quatre infrastructures qui, si elles étaient attaquées, affecteraient durablement nos communications. Une étude du RIPE a montré comment l’internet ukrainien résistait au black-out général malgré les nombreuses dégradations de l »infrastructure. Le secret ? Une structure distribuée, décentralisée, et des fournisseurs d’accès locaux partout dans le pays.

L’exemple le plus connu (et l’un des plus anciens) d’un système fédéré est la messagerie électronique. Les fournisseurs d’adresses e-mail sont innombrables mais, parce qu’ils ont choisi d’utiliser des protocoles standard, interopérables, chaque utilisateur peut échanger des messages avec tous les autres. Si l’un des prestataires techniques disparaît (c’est arrivé plusieurs fois), il ne met pas en danger l’intégralité du système. La domination d’un acteur, en revanche, parce qu’elle repose sur la centralisation des ressources (pensons à Gmail), peut fragiliser cette construction.

Mais l’angle de la résilience n’est pas le seul qu’il est intéressant d’interroger.

Décentralisation et mutualisation

Dans l’esprit de la plupart de nos décideurs, mutualisation et centralisation vont de pair, l’un des objectifs d’un effort de mise en commun des moyens étant de réaliser des économies d’échelle. Pour un certain nombre d’applications centrales, cette promesse est tenue. Cependant, quelques inconvénients sont associés à ce type de projet :

• éloignement des organes de décision
• perte d’autonomie dans les choix techniques ou politiques
• moindre connaissance de l’environnement des utilisateurs
• moindre réactivité dans la mise en œuvre des projets
• …

Comment articuler coopération (pour une plus grande efficacité dans les projets transversaux) et autonomie (pour conserver une certaine liberté de choix et d’action) ?

En coopérant, des structures indépendantes peuvent créer des réseaux au service de projets d’envergure, tout en conservant leur autonomie de gestion, d’évolution et d’action. Des moyens techniques existent, et elles sont très largement implantées dans les solutions libres. ActivityPub a été officiellement publié comme recommandation du W3C le 23 janvier 2018.

Ce standard, qui permet d’interfacer des solutions diverses, est présent dans plusieurs des logiciels utilisés par la ville d’Échirolles : Nextcloud (plateforme collaborative), Peertube (hébergement de vidéos), Mastodon (réseau social) et WordPress (création de sites web). Ces quatre outils sont de plus en plus utilisés par les collectivités territoriales, les ministères et les partenaires de la ville, mais les fonctionnalités de fédération sont rarement mises en œuvre, en interne comme en externe. Pourtant, les applications pourraient être nombreuses : partage d’annuaires/de dossiers entre collectivités (Nextcloud), meilleure visibilité de la communication des structures associées (Peertube), création de sites dans le cadre de projets intercommunaux (WordPress), mise en avant des actions d’un territoire (Mastodon), etc.

La fédération comme horizon

Au sein d’Alpes Numérique Libre, le collectif de DSI de la région grenobloise autour des logiciels libres, le sujet est en train de naître, sans concrétisation pour le moment. La mise en place d’une fédération des acteurs au sein d’un même territoire géographique pourrait être une première pierre posée, une expérience intéressante du point de vue de l’action publique dont nous pourrions, peut-être, tirer des enseignements plus larges.

Les EPCI (établissements publics de coopération intercommunale), comme le SITPI ou Grenoble Alpes Métropole dans notre région, pourraient jouer un rôle moteur dans ce type d’initiative : idéalement positionnés au centre des réseaux communaux, ils disposent d’une architecture parfaitement adaptée.

L’instance Mastodon colter.social, créée, hébergée et maintenue par le SITPI est, à ce titre, un précurseur intéressant de ce que pourraient être ces fonctionnements fédératifs. Mise à disposition de l’ensemble des collectivités territoriales, sa modération est assurée par les agents de collectivités qui ne sont pas forcément adhérentes du syndicat, mais qui ont choisi de coopérer. Des outils comme Zammad ou Signal (pour des instances plus importantes, pourquoi pas un serveur Matrix ?) permettent d’organiser efficacement ce travail.

Plusieurs autres systèmes de mutualisation innovants pourraient être imaginés, alliant la mise à disposition de ressources pour les petites collectivités (un serveur PeerTube partagé, par exemple) et une fédération avec les structures de taille plus importante, chacune maintenant sa propre solution.

Nous n’en sommes pas là pour le moment, et nombreuses sont les collectivités qui reposent sur des solutions hébergées (en mode SaaS), souvent chez des grands acteurs américains (Google, Microsoft, Amazon…), parce qu’elles n’ont pas les compétences ou les ressources financières permettant un autre fonctionnement.

Pas toujours très bien structurées, focalisées sur leur transformation numérique, choisie ou subie, ce type de projet peut paraître bien éloigné de leurs préoccupations quotidiennes. Mais il me semblait intéressant de faire ce travail de prospective, comme un horizon vers lequel nous pourrions, individuellement et collectivement, choisir de tendre.

→ L’épisode 1 (structuration)
→ L’épisode 2 (transformation)
→ L’épisode 3 (solutions)
→ L’épisode 4 (inclusion)
→ L’épisode 5 (vous êtes ici)

***

• Source image : https://iseremag.fr/actualites/2020-juillet-aout/echirolles-la-cite-plurielle
• Auteur : © C. Delcrampe
• Description : Vue d’Échirolles, immeubles récents avec passage du tram.

Retrouvez-moi sur Mastodon : https://colter.social/@nicolasvivant

Nous vous avons proposé déjà trois articles qui font écho à l’actualité récente autour de Mastodon en voici un 4^e, celui d’Aral Balkan, traduit pour vous par Framalang. Le héraut du SmallWeb insiste avec humour sur un point en effet crucial : la taille géante de certaines instances, due à la conception technique même du Fédiverse, risque d’être problématique…

Donc, après :

• Un article bien informé d’analyse par Olivier « Affordance » Ertzscheid Le mastodonte et l’oiseau bleu
• Un billet de Benjamin Bellamy Le Fédivers est tellement plus grand que Mastodon
• Une traduction de l’article de Hugh Rundle Mastodon, fin de (première) partie ?

Voici Is the fediverse about to get Fryed ?

Traduction Framalang :  Claire, Fabrice, goofy, Henri-Paul, jums

Le Fédiverse va-t-il stephenfrire ?

(Ou « Pourquoi chaque pouet est aussi potentiellement une attaque par déni de service »)

par Aral Balkan

 

Stephen est un gros poisson dans une petite mare (oui, j’en ai d’autres en réserve).

Attention : le Fédivers est sur le point de frire. Stephen Fry(re) bien sûr.

À la suite du récent rachat de Twitter par un milliardaire proto-fasciste immature, des gens ont fui¹ vers le Fédiverse². Parmi eux, certains avaient, au moins sur Twitter, des millions de followers, comme Greta Thunberg et, plus récemment, Stephen Fry³

— Eh bien, c’est sûrement une bonne chose, non ? Tout le monde va parler du Fédiverse, de la décentralisation, et peut-être même de ce Small Web dont tu parles tout le temps, Aral, non ?

Eh bien, oui et non… Trop de bonnes choses tue les bonnes choses. Et, dans le Fédiverse actuel, les bonnes choses seraient les « comptes populaires ». En fait, cela pourrait bien être fatal (pour les instances Mastodon). Je vais essayer de détailler dans cet article ce que je veux dire en prenant mon propre compte comme exemple.

Comment tuer un Mastodon(te)

(indice : en étant bavard quand vous êtes populaire)

Inutile de le préciser, je ne suis pas une célébrité.
Et pourtant, dans le Fédiverse, je me retrouve dans une situation un peu unique dans laquelle :

1. J’ai ma propre instance Mastodon, juste pour moi⁴.
2. Je suis suivi par pas mal de personnes. Plus de 22 000, pour être précis⁵.
3. Je suis beaucoup de personnes, et j’aime vraiment avoir des conversations avec elles (je pense que c’est ce que les jeunes branchés appellent « l’engagement »).

Malheureusement, la combinaison de ces trois facteurs a créé la tempête parfaite⁶, ce qui veut dire que désormais, chaque fois que je poste quelque chose qui suscite beaucoup d’engagement, je finis par conduire une attaque par déni de service contre moi-même.

Mastodon : déni de service en tant que service ?

Hier, c’était mon anniversaire.
Et, bien sûr, j’ai posté sur ce sujet depuis mon instance Mastodon.

J’ai eu pas mal de réponses. Et, pour être poli, j’ai commencé à répondre à tout le monde avec des messages de remerciements. Oh non, mon pauvre naïf ! Qu’est-ce que tu n’avais pas fait ?

Je vais laisser mon ami Hugo Gameiro, qui gère masto.host et héberge mon instance, expliquer ce qui s’est passé ensuite⁷ :

Vous avez beaucoup d’engagement et cela sollicite beaucoup Sidekiq⁸.

Prenez, par exemple, votre message d’anniversaire. En plus de demander à des milliers de serveurs de traiter votre demande de réalisation (on appelle ça des « jobs ») pour propager votre message (pour 23 000 abonnés, disons 3 000 serveurs), votre serveur au moment de la création de votre message va créer 3 000 jobs Sidekiq. Et comme votre Sidekiq n’a que 12 threads, traiter 3 000 jobs va prendre du temps puisqu’il ne peut en traiter que 12 à la fois.
Ensuite, pour chaque réponse à ce message, 3 000 jobs sont à nouveau créés, afin que vos abonnés puissent voir votre réponse sans avoir à changer de serveur ou aller sur votre profil. Et puis, si vous répondez à votre réponse, 3 000 jobs supplémentaires sont créés, etc.
Si vous répondez aux 100 réponses que vous avez reçues en 10 minutes (en supposant que l’estimation de mon nombre de serveurs est correcte), vous créez 300 000 jobs Sidekiq. C’est pour cela que ça bouchonne.

Mais qu’est-ce que tout cela veut bien dire, si on omet le jargon technique ?
Eh bien, que je parlais trop en étant trop connu de tous.

Voilà à quoi ressemble un embouteillage sur Mastodon.

Alors, quelle est la solution ?
Eh bien, il n’y a qu’une chose à faire quand vous vous retrouvez dans ce pétrin : agrandir votre instance Mastodon⁹. Le problème ? Ça commence à coûter cher.
Avant la dernière migration de Twitter¹⁰, je payais environ 280 €/an (un peu plus de 20 €/mois) pour mon instance Mastodon grâce à un partenariat que j’avais avec Hugo depuis le début. Cette semaine, je l’ai agrandie avec un plan à 50 €/mois. Et ce n’est toujours pas assez, comme le montre mon message d’anniversaire, donc Hugo a gentiment suggéré de me proposer un plan sur mesure.
Le problème n’est pas résolu pour autant, il est juste repoussé (sauf si cet article énerve tout le monde, bien sûr).
Heureusement, comme j’ai ma propre instance, la seule personne pénalisée par cette dépense supplémentaire, c’est moi. Mais que se serait-il passé si j’étais sur une instance publique gérée par quelqu’un d’autre ?

Tu déconnes, Elon ?

Si Elon Musk voulait détruire mastodon.social, l’instance phare de Mastodon, il lui suffirait de s’y inscrire¹¹.
Heureusement, Elon n’est pas assez intelligent pour ça.

Je plaisante, bien sûr… Eugen bannirait très probablement son compte dès qu’il le verrait. Mais ça illustre un problème : Elon est facile à bannir. Stephen Fry l’est beaucoup moins. C’est un véritable trésor national pour nous tous. On ne le bannit pas comme ça.
Et pourtant, Stephen peut lui aussi (bien qu’involontairement) coûter très cher aux gens qui gèrent des instances Mastodon, simplement en rejoignant l’une d’elles¹²..
La solution, pour Stephen tout du moins, est simple : il devrait gérer sa propre instance personnelle.
Ou demander à quelqu’un de le faire à sa place, comme je le fais¹³.
Gérer sa propre instance apporterait aussi à Stephen un autre bénéfice : il serait automatiquement vérifié. Après tout, si vous parlez à, mettons, @stephen@social.stephenfry.com, vous pouvez être certain que c’est bien lui parce que vous savez qu’il gère son propre domaine.

Des instances personnelles à la rescousse

Mon discours au Parlement européen sur les problèmes avec la Big Tech et les approches différentes que proposent Mastodon, le Fédiverse, et le Small Web.

— Attends, je suis largué… Tu ne viens pas de dire que les instances personnelles étaient une partie du problème ?
— Oui et non : elles le sont et elles ne devraient pas l’être.

Si ActivityPub (le protocole) et Mastodon (un serveur qui adhère à ce protocole) avaient été conçus pour promouvoir la décentralisation, alors avoir plus d’instances sur le réseau ne serait pas un problème. En fait, ça serait même le signe d’un réseau décentralisé sain.
Cependant, ActivityPub et Mastodon ont été conçus de la même manière que la Big Tech / Big Web : pour encourager des services qui hébergent le plus d’utilisateurs¹⁴ possible.
Cette architecture est à la fois complexe (ce qui la rend difficile et coûteuse à héberger) et très efficace pour la Big Tech (où les choses sont centralisées et passent à l’échelle verticalement, et où le but est d’avoir / de contrôler / d’exploiter autant d’utilisateurs que possible).
Dans la Big Tech, le coût initial pour passer à l’échelle est subventionné par de nombreuses sociétés de capital-risque (des personnes riches investissant dans de nouveaux business d’extraction et d’exploitation – ce que la Silicon Valley appelle des startups – dans le but de devenir encore plus riches), et ça mène à ces silos géants¹⁵ que sont aujourd’hui les Google, Facebook et Twitter.
Toutefois, à la différence de la Big Tech, le but avoué du Fédiverse est de décentraliser les choses, pas de les centraliser. Du coup, comment pourrions-nous atteindre l’opposé des buts de la Big Tech en adoptant leurs architectures de base ?
Lorsque vous adoptez le design de quelque chose, vous héritez aussi des critères de réussite qui ont mené à ce design. Si ces critères de réussite ne correspondent pas à vos objectifs, vous avez un sacré problème.
Pour le dire plus simplement :
N’adoptez pas les critères de réussite de la Big Tech, sinon vous deviendrez la Big Tech.

Ce n’est pas la taille qui compte

Aujourd’hui, il y a une équivalence entre la taille de mastodon.social (l’instance gérée par Eugen) et le succès de Mastodon (le logiciel créé par Eugen). C’est très dangereux. Plus mastodon.social grossit, plus il va ressembler à Twitter.
Je peux presque vous entendre crier : « Mais Aral, c’est fédéré ! Au moins, il n’y a pas de verrous sur mastodon.social ! ».
Et c’est vrai.
Vous savez ce qui est également fédéré ? L’e-mail.
Avez-vous déjà entendu parler de cette petite et vieille instance appelée Gmail ? (Ou peut-être les termes « adopte, étend, étouffe » ?)
Savez-vous ce qui arrive à votre e-mail si Google déclare (à tort ou à raison) que vous êtes un spam ? Personne ne voit votre e-mail.
Vous savez ce qui se passe si mastodon.social bloque votre instance ? Des centaines de milliers de gens (bientôt des millions ?) ne pourront plus décider d’afficher ou non vos messages.
Que se passe-t-il quand votre instance bloque mastodon.social ? Absolument rien.
C’est un réel déséquilibre des puissances.

La décentralisation commence par soi-même

Mastodon est non-lucratif, et je n’ai pas de raison de croire qu’Eugen n’ait pas les meilleures intentions du monde. Et pourtant, la décentralisation commence par se décentraliser soi-même.
C’est dans l’intérêt du Fédiverse que mastodon.social donne le bon exemple en limitant sa taille volontairement.
En fait, ça devrait même être intégré au logiciel. Les instances Mastodon devraient être empêchées de croître au-delà d’une certaine taille. Les instances qui sont déjà trop grosses devraient avoir des moyens d’encourager les gens à migrer vers des plus petites.
En tant que communauté, nous devrions aborder les grandes instances comme des tumeurs : comment pouvons-nous les détruire pour qu’elles ne soient plus un danger pour l’organisme ?
En poussant ce raisonnement, on arrive au concept du Small Web, un internet où nous possédons et maîtrisons notre propre lieu (ou nos propres lieux).

Cliquez sur l’image pour voir une vidéo (sur aperi.tube, une instance PeerTube) : Aral expliquant ce qu’est pour lui le Small Web

Small is beautiful ! (Petit c’est mieux) (octobre 2022) : Qu’est-ce que le Small Web et pourquoi en avons-nous besoin ?

 

Cui-cui ?

Je ne dis pas que les protocoles et applications actuels du Fédiverse peuvent, vont, ou même devraient évoluer vers le Small Web¹⁶. Pour l’instant, le Fédiverse est un palliatif inestimable qui fournit un lieu plus sûr que les fosses septiques centralisées de la Silicon Valley.

Le temps que durera le palliatif dépendra de notre capacité à résister à la centralisation. Les designs des serveurs et des protocoles qui incitent au passage à l’échelle vertical ne rendront pas forcément cette tâche plus facile. Et pourtant, il y a des moyens de pression sociaux que nous pouvons utiliser pour contrer leurs effets.

La dernière chose qu’on souhaite, c’est qu’une poignée de Zuckerbergs au petit pied gouvernent le Fédiverse. Ou pire encore, que vous deveniez vous-même un de ces mini-Zuckerbergs.

J’aime le fait que le Fédiverse existe. Et j’ai le plus grand respect pour les efforts gargantuesques qui lui sont dédiés. Mais je suis aussi très préoccupé par les décisions prises en termes d’architecture qui incitent à la centralisation, et non à la décentralisation. Je nous implore de reconnaître cela, pour limiter les risques du mieux que nous le pouvons, pour nous efforcer d’apprendre de nos erreurs, et pour faire encore mieux demain.
Gens d’ActivityPub et de Mastodon :
Considérez-moi comme votre canari dans une mine de charbon…
« Cui-cui ! Cui-cui ! Cui-cui ! »

 

*Si vous souhaitez soutenir la Small Technology Foundation, qui est sans but lucratif : https://small-tech.org/fund-us