Voici le deuxième volet du processus de dégooglisation de la ville d’Échirolles (si vous avez manqué le début) tel que Nicolas Vivant nous en rend compte. Nous le re-publions volontiers, en souhaitant bien sûr que cet exemple suscite d’autres migrations vers des solutions libres et plus respectueuses des citoyens.

---

Dégooglisation d’Échirolles, partie 2 : la transformation numérique

par Nicolas Vivant

Le numérique est en train de vivre une révolution. Disposer d’une stratégie, même étayée par des enjeux politiques forts, ne permet pas d’y échapper. Le monde change et il faut s’adapter, sous peine de passer à côté des nombreuses possibilités offertes par les dernières technologies… et de se noyer dans la masse de données que nous générons chaque jour. Les mots-clés du changement : collaboratif, transparence, ouverture. Mais qu’est ce que cela veut dire, concrètement ?

L’inévitable transformation numérique

L’informatique s’est construite, depuis les années 90, autour d’un modèle que nous connaissons toutes et tous, et qui est en train de disparaître. Le poste client repose généralement sur :

• Un système d’exploitation (généralement Windows, parfois Mac, rarement Linux)
• Une suite bureautique (souvent Microsoft, parfois LibreOffice)
• Un serveur de fichiers (avec un classement par arborescence et une gestion des droits centralisée)
• Une messagerie (avec un client lourd de type Outlook, ou via une interface web) souvent couplée à un agenda

L’évolution que l’on constate partout :

• Un système d’exploitation qui devient une simple interface de connexion
• De plus en plus de terminaux mobiles (smartphone, PC portables, tablettes)
• Des applications qui sont le plus souvent accessibles via un navigateur web
• Un logiciel intégrant les fonctions de suite bureautique, de messagerie, d’agenda, d’édition collaborative et d’échanges textuels, audio ou vidéo (souvent basé sur un « cloud »)

Le changement culturel à opérer est majeur. Les utilisateurs, aux compétences souvent durement acquises, vont devoir s’adapter et notre responsabilité est de nous assurer que cette transition ne se fera pas dans la douleur.

Des fonctionnements durablement inscrits dans notre rapport à l’informatique sont repensés, sans que la question de l’adoption par les utilisateurs se pose. Exemple : l’organisation et la recherche de l’information. Aujourd’hui, la plupart des serveurs de fichiers et des systèmes de stockage de données sont organisés sous la forme d’une arborescence. Pendant très longtemps, ce classement a été le moyen le plus efficace de retrouver de l’information. Mais la masse de données numériques a grandi, la taille (et le nombre) des répertoires est devenue énorme, et les moteurs de recherche sont souvent inefficaces/lents (cf. la fonction « recherche » de l’explorateur de Windows quand il s’agit de chercher sur un serveur).

En ligne, cette question a été tranchée depuis longtemps. Aux début de l’internet, deux moteurs de recherche dominaient le marché : Yahoo, alors basé sur un classement des sites web en arborescence, par grands domaines, et Altavista (de la société, aujourd’hui disparue, Digital), qui fonctionnait sur le même principe que Google avec un unique champ de recherche. La masse d’information à gérer ayant explosé, c’est ce dernier principe qui a prévalu.

On a parfois cru que la GED (Gestion Électronique de Documents), pouvait être une réponse. Mais l’effort à consentir pour ajouter, souvent manuellement, les métadonnées lui permettant d’être efficace était important. Ce qu’on appelle le « big data » a tout changé. Aujourd’hui, la grande majorité des métadonnées peuvent être générées automatiquement par une analyse du contenu des documents, et des moteurs de recherche puissants sont disponibles. Dans ce domaine, le logiciel libre est roi (pensez à Elastic Search) et des solutions, associées à un cloud, permettent de retrouver rapidement une information, indépendamment de la façon dont elle est générée, classée ou commentée. C’est un changement majeur à conceptualiser dans le cadre de la transformation numérique, et les enjeux de formation et d’information des utilisatrices et utilisateurs ne peuvent pas être ignorés.

S’organiser pour évoluer

Si la feuille de route des élus échirollois ne nous dit pas ce qui doit être fait, elle met l’accent sur un certain nombre de thèmes qu’il va falloir prendre en compte : limitation de l’impact environnemental, réduction de toutes les fractures numériques, gestion responsable des données, autonomie et logiciels libres. À nous de nous adapter, en prenant garde, comme toujours, à la cohérence, la sécurité et la stabilité du système d’information… et en ne négligeant ni l’effort de formation, ni la nécessaire communication autour de ces changements.

Dans ma commune, c’est le rôle de la direction de la stratégie et de la culture numériques (souvent appelée, ailleurs, « direction de la transformation — ou de la transition — numérique ») en lien étroit avec la DSI, qui dispose des compétences opérationnelles.

Conjuguer autonomie et déploiement de logiciels libres a un coût : celui de l’expertise technique. Sans compétences techniques fortes, le nombre de prestations explose nécessairement et vient contredire l’objectif d’un système d’information maîtrisé, aussi bien en termes de responsabilités qu’au niveau financier. Hébergement, installation, paramétrage, sécurisation, maintenance et formation doivent pouvoir, autant que possible, être assurés en interne. Le DSI lui-même doit pouvoir faire des choix sur la base de critères qui ne sont pas seulement fonctionnels mais également techniques. La réorganisation du service est donc inévitable et l’implication de la direction des ressources humaines indispensable. Vouloir mettre en œuvre une politique autour du libre sans compétences ni appétences pour le sujet serait voué à l’échec.

À Échirolles, la grande proximité entre DSCN et DSI a permis de décliner la stratégie numérique en méthodologies opérationnelles qui, mises bout à bout, permettent de s’assurer que nous ne perdons pas de vue l’objectif stratégique. Pour chaque demande d’un nouveau logiciel exprimée par un service, par exemple, nous procédons comme suit :

• Existe-t-il un logiciel en interne permettant de répondre au besoin ? Si oui, formons les utilisateurs et utilisons-le.
• Si non, existe-t-il un logiciel libre permettant de répondre au besoin ? Installons-le.
• Si non, existe-t-il un logiciel propriétaire ? Achetons-le.
• Si non, en dernier recours, créons-le.

On mesure immédiatement ce que ce fonctionnement implique au niveau du recrutement et de l’organisation : il nous faut une équipe capable de gérer cette procédure de bout en bout et donc, forcément, une compétence en développement. Nous avons donc créé un « pôle applicatif » en charge de ce travail, et recruté un développeur. Et puisque la question de la contribution se pose également, nous avons décidé que 20% du temps de travail de ce poste serait consacré à des contributions au code de logiciels libres utilisés par la ville.

À chaque mise en place d’une solution technique, la question de l’interopérabilité se pose. Partant du principe que le « cloud » deviendra central dans l’architecture future du système d’information, nous nous sommes penchés sur les logiciels libres qui permettraient de remplir cette fonction et nous avons fait le choix, très tôt et comme beaucoup, de Nextcloud, associé à Collabora pour l’édition collaborative des documents. Nous nous assurons donc, depuis, que tout nouveau logiciel installé dans la collectivité sera correctement interopérable avec ce logiciel quand, dans quelques années, la transition sera achevée.

Mais nous parlerons de logiciels dans la troisième partie de ce récit.

→ Retour vers l’épisode 1 : la structuration.

***

• Source image : https://commons.wikimedia.org/wiki/File:Eug%C3%A8ne_Delacroix_-_Le_28_Juillet._La_Libert%C3%A9_guidant_le_peuple.jpg
• Auteur : Erich Lessing Culture and Fine Arts Archives via artsy.net
• Description : Tableau d’Eugène Delacroix « La Liberté Guidant le Peuple », commémorant la révolution des Trois Glorieuses (27-28-29 juillet 1830) en France.
• Licence : Domaine public

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

Installer 16 services en ligne sur des serveurs, c’est une chose. Assurer leur sécurité, leurs mises à jour, leur sauvegarde, en est une autre. Si on ajoute à cela un travail sur l’accueil, les réponses aux questions de chacun·e et l’accompagnement vers d’autres hébergeurs de confiance… Alors cela représente un effort quotidien de multiples personnes.

Héberger un service en ligne, ce n’est pas juste appuyer sur un bouton. C’est plusieurs personnes qui appuient sur de nombreux boutons, toute la journée. Car si on veut proposer des services en lesquels vous pouvez avoir confiance, il faut forcément mettre des humain·es derrière les machines.

Accueil des services

Nous entreprenons actuellement une campagne de mise à jour des pages d’accueil des services que nous proposons. La page d’accueil, c’est LA page de référence qui doit vous donner les bons accès et les explications que vous recherchez au premier coup d’œil.

Pour cette nouvelle version, nous avons conçu une page d’accueil qui vous permet une découverte progressive du service, au fur et à mesure de votre défilement sur la page. Le premier bandeau vous accueille avec le nom, la description, et une magnifique illustration du service… mais surtout avec de gros boutons pour l’utiliser directement. Puis des onglets vous exposent ses fonctionnalités principales, avant que l’on précise les limitations et les règles qui régissent son utilisation.

Ensuite la page d’accueil détaille comment et pourquoi nous hébergeons ce service. C’est avant tout un acte politique qui nous motive à poursuivre ce travail, et nos intentions n’étaient souvent pas bien comprises ni même connues des bénéficiaires de nos services. Désormais, nos motivations sont clairement affichées.

Ces pages d’accueil se concluent par une présentation de Framasoft et notre formulaire de don, car c’est bel et bien grâce aux dons des personnes qui soutiennent Framasoft que ces services sont utilisés gratuitement par plus d’un million de personnes chaque mois. L’objectif n’est ni de culpabiliser ni de pousser au don, mais bien de montrer concrètement que le « gratuit » est toujours financé, d’une manière ou d’une autre.

Infrastructure

On vous le confirme : le cloud, c’est loin d’être vaporeux ! Il s’agit d’ordinateurs très concrets, toujours allumés et toujours connectés (des serveurs), qu’il faut bichonner constamment.

Parce que Framasoft, c’est 43 serveurs physiques et 4 serveurs de stockage, avec des sauvegardes réparties sur 2 sites géographiques, pour éviter que les données ne soient perdues en cas d’un problème physique (incendie, inondation, séisme, etc.).

Sur 11 de ces serveurs sont installées 48 machines virtuelles, alors que les 32 autres serveurs sont utilisés directement. Virtuelles ou physiques, cela fait donc 91 machines, chacune avec son système d’exploitation, qu’il faut tenir à jour, mettre à niveau, etc.

Ces serveurs abritent les logiciels qui font tourner les services (et vous envoient vos emails de notification, etc.). Ces logiciels sont monitorés (on surveille si l’activité est normale, pour savoir quand ça rame ou quand ça surchauffe, par exemple), régulièrement mis à jour, et migrés sur une autre machine lorsqu’il y en a besoin.

Derrière ces logiciels, ces machines virtuelles, ces serveurs et cette infrastructure, il y a une petite équipe de 3 personnes (dont une à temps plein) qui se relaient et se décarcassent pour que tout fonctionne au mieux. Car si l’informatique a facilité l’automatisation, l’humain reste indispensable pour servir les serveurs.

Support

S’il y a bien un travail dont on n’imagine pas l’ampleur avant d’ouvrir un service en ligne au grand public, c’est le nombre de demandes d’aide auxquelles il faut répondre. Enfin, quand nous disons qu’ « il faut », c’est plutôt un choix : notez que les géants du Web font tout pour être injoignables et ne pas répondre à vos demandes (sauf si vous payez cher un service de support).

Or nous avons les ressources d’une petite association pour affronter des problèmes de géants. Avec un million de personnes qui utilisent nos services chaque mois, et 37 membres dans notre association (dont un salarié à plein temps sur les réponses à vos demandes), l’astuce est de trouver comment vous autonomiser au maximum.

Depuis près d’un an, nous avons remodelé notre seule et unique page de contact (vraiment, si vous voulez une réponse fiable par la personne concernée, ne nous interpellez pas sur les médias sociaux, mais bien sur contact.framasoft.org !).

Cette page a été conçue pour vous rendre indépendant·e :

• avec un accès direct aux réponses les plus courantes sur le sujet qui vous concerne (dans 90 % des cas, votre réponse se trouve déjà là) ;
• avec un lien vers le forum d’entraide où toute une communauté est présente pour vous répondre ;
• avec le formulaire de contact si votre demande ne peut pas être publique (données personnelles, invitation, etc.).

Grâce à ces outils d’autonomisation, nous sommes passé·es de 450 à 200 demandes à traiter par mois (sans compter les spams, sinon il faut doubler). Cela permet de ne pas perdre d’énergies à vous copier-coller les réponses de notre Foire aux Questions, pour mieux se consacrer aux échanges, éclaircissements, investigations, tests, etc. qui permettent de répondre à vos besoins parfois très spécifiques.

Alternatives à Framasoft

Dès le lancement de la campagne Dégooglisons Internet, nous savions que Framasoft ne pourrait pas répondre à elle seule à tous les besoins qui existent pour s’émanciper dans ses usages numériques. C’est pourquoi, sur le site degooglisons-internet.org, il y a une page qui recense des alternatives dans et hors Framasoft : des alternatives à Google Chrome, à BlablaCar ou à Gmail par exemple.

On parle souvent du travail que c’est de construire un projet, par exemple lorsqu’on ouvre un nouveau service. Mais déconstruire demande aussi un effort non négligeable, surtout lorsqu’on essaie de le faire proprement. Ainsi, pour chaque service que nous avons fermé, nous avons créé une page permettant de recenser des alternatives, souvent le même outil, proposé par des hébergeurs de confiance.

Lister, recenser et mettre en valeur des alternatives, c’est un travail régulier, car il faut se tenir à jour, répondre à ceux qui signalent leur nouvelle alternative, voir si celles qui sont présentées sont toujours pertinentes.

C’est cependant un effort logique : si l’on veut promouvoir la décentralisation, si l’on ne veut pas que tout le monde aille chez le même hébergeur et crée un nouveau géant du Web, alors il faut présenter la diversité des propositions.

C’est d’ailleurs en cela que le site entraide.chatons.org, qui avait été ouvert en urgence pour répondre aux besoins nés de la pandémie, reste une ressource très utile : 9 services en ligne, 0 compte à créer, le choix d’hébergeurs qui tourne automatiquement, pour décentraliser sans y penser.

Découvrez tout ce qu’est Frama !

Voilà qui conclut le focus de cette semaine. Vous pourrez retrouver tous les articles de cette série en cliquant sur ce lien.

Sur la page Soutenir Framasoft, vous pourrez découvrir un magnifique jeu de cartes représentant tout ce que Framasoft a fait ces derniers mois. Vous pourrez ainsi donner des couleurs à l’ensemble des activités que vous financez lorsque vous nous faites un don. Nous espérons que ces beaux visuels (merci à David Revoy !) vous donneront envie de partager la page Soutenir Framasoft tout autour de vous !

En effet, le budget de Framasoft est financé quasi-intégralement par vos dons (pour rappel, un don à Framasoft de 100 € ne vous coûtera que 34 € après défiscalisation). Comme chaque année, si ce que nous faisons vous plaît et si vous le pouvez, merci de soutenir Framasoft.

Pour aller plus loin

• Voir la nouvelle page d’accueil sur Framaforms
• Contacter Framasoft
• Notre foire aux questions
• Le forum d’entraide
• Les alternatives de Dégooglisons Internet
• Les alternatives aux services de Framasoft
• Les services sans inscriptions des CHATONS
• Illustrations : CC-By David Revoy
• Soutenir Framasoft

Cet article fait écho à mon précédent article sur le pouvoir de nuisance des silos de mail.

Dans cet article, je pestais contre le pouvoir ahurissant que confère une grosse base d’utilisateurs à certains fournisseurs de mail (Gmail, Yahoo, etc).

En effet, il est quasiment impensable pour quiconque envoie des mails de passer outre leurs façons de faire, sous peine de se couper d’une grande partie des internautes.

Quand bien même on se conforme à leurs desiderata, quand bien même on met en place toutes les bonnes pratiques existantes, certains fournisseurs de mail ne font pas leur travail correctement…

Nota Bene : Framasoft n’est pas la seule structure à rencontrer les problèmes décrits ci-dessous. Des universités aux entreprises en passant par les google groups, on trouve des témoignages un peu partout sur le Web de mails qui n’arrivent pas à destination, et les administrateurs systèmes échangent souvent entre eux pour savoir si ça vient d’eux ou du serveur d’en face (vous aurez déjà deviné, d’après le titre de cet article, d’où vient généralement le problème).

Florilège

À tout seigneur, tout honneur, commençons par laposte.net.

laposte.net

La Poste avait tout pour fournir un service de mail propre et performant : son histoire dans les communications remonte à loin (on peut faire remonter sa généalogie au XVe siècle avec la première poste d’État de Louis XI) et si nous avons tous eu une lettre ou un colis qui s’est perdu dans les méandres des centres de tri, force est de constater que ça fonctionnait quand même très bien. En 2000, la Poste, encore entreprise publique, devait pouvoir fournir une adresse électronique à tous les Français⋅e⋅s.

Comment ne pas lui faire confiance ? Nous-mêmes, libristes avons, pendant longtemps, conseillé laposte.net à qui nous demandait un fournisseur de mail « propre », qui n’espionne pas les conversations, ne met pas de publicité…

Les choses ont bien changé.

Le prestataire de la Poste (ah bah oui, c’est un sous-traitant, vous n’imaginiez quand même pas que la Poste allait avoir des compétences en interne à l’heure des suppressions de postes de fonctionnaires ?) semble être, excusez le terme, un vrai branquignol : nous avons souvent des messages d’erreur comme 421 4.3.2 All server ports are busy (les serveurs ne sont pas correctement dimensionnés), 550 5.5.0 Service refuse. Veuillez essayer plus tard. service refused, please try later. LPN007_510 (« nope, on veut pas, revenez plus tard ») ou mon préféré, 451 4.7.1 Service unavailable – try again later (tout est vautré).

Ça fait des mois que les serveurs de laposte.net plantent régulièrement, avec en point d’orgue une panne qui a duré plusieurs jours en avril et une communication qui a mis plusieurs jours à arriver (un message pour dire qu’il y a un problème serait-il un aveu de faiblesse pour eux ?).

Résultat :

• les mails s’accumulent sur nos serveurs, et comme on retente de les envoyer pendant quelques jours, eh bien ça ralentit le traitement des autres mails (bon, maintenant, j’ai mis en place des mailqueues séparées, mais ce n’est pas quelque chose que je devrais avoir à mettre en place !) ;
• les utilisateurs ne reçoivent pas leurs mails de confirmation d’inscription à nos services ;
• qui les utilisateurs contactent-ils ? Ah bah non, pas le support de la Poste, ce serait trop simple. Non, non, c’est nous. Et c’est usant. Non pas de vous répondre, mais le fait que ce soit 95 % du temps la faute à votre fournisseur de mail qui ne fait pas correctement son boulot.

Orange (wanadoo)

Ah, Orange. Tout un poème…

L’opérateur historique qui, lui aussi, a bénéficié de son aura d’ancien service public pour capter une grande majorité des internautes français lorsque vint l’heure de se choisir son premier FAI. Du coup, beaucoup de personnes ont encore une adresse wanadoo. Et comme Orange est le FAI majoritaire en France, encore plus de personnes ont une adresse orange.

J’avais déjà parlé dans mon précédent article de sa sale manie de ne pas accepter qu’on lui envoie trop de mails en une seule connexion. Imaginez un quidam qui refuse que son facteur lui apporte plus de trois lettres par tournée. Le facteur doit donc se représenter plusieurs fois s’il a plus de trois lettres à délivrer. C’est débile. Orange fait ça, mais pour le mail.

C’est le seul fournisseur que je connaisse qui impose ce genre de limite (qu’on ne vienne pas me dire que c’est pour lutter contre le spam : comment font les autres ? Hein ? Orange n’aurait pas les capacités financières et techniques de lutter plus proprement contre le spam ?).

Heureusement, ça se règle facilement, mais tout de même.

Et puis, de temps en temps, pouf, il rejette nos mails à coup de 550 5.2.0 Mail rejete. Mail rejected. ofr_506. Pourquoi ? Va savoir. Et ça se débloque tout seul au bout d’un temps.

Free

Après l’opérateur historique, voici celui qu’on surnomme le trublion du net. De temps en temps, celui-ci semble modifier les règles de son antispam, et nous voilà avec des mails 550 spam detected, quand bien même c’est le 300e mail quasi identique que nous envoyons de la journée. Et puis ça s’en va et ça revient.

Pareil avec 451 too many errors from your ip, ça bloque de temps en temps et ça repart comme c’est venu… alors qu’il s’agit majoritairement de mails de notification (framapiaf, framasphere, framagit…) et donc que les adresses ont été vérifiées ! Certes, il peut y avoir des erreurs, mais tellement peu dans le volume de mails que nous envoyons à Free… Ça arrive vraiment de façon aléatoire. Grmpf.

Facebook

On l’oublie, mais Facebook, en 2010, a proposé d’avoir une adresse mail @facebook.com (bon, ils ont arrêté les inscriptions en 2014, ce qui explique l’oubli). Et certaines personnes utilisent encore ces adresses.

Nos mails étaient bloqués de temps à autre avec un code 554 5.7.1 POL-P4 Connection refused, ce qui veut dire en gros « Revenez dans 24 ou 48 heures ». En soi, ce n’était pas forcément délirant, si jamais nous avions, pour une raison ou pour une autre, envoyé beaucoup de mails d’un coup à leurs serveurs. Mais depuis quelques semaines, il n’y a plus de déblocage : nos mails ne partent plus pour facebook.com, même en les faisant partir d’un autre serveur ou en diminuant la vitesse d’envoi.

---

Voilà pour les fournisseurs de mails qui font n’importe quoi avec leurs serveurs. Ils présentent tout de même l’avantage de nous permettre de comprendre pourquoi les destinataires n’ont pas reçu leurs mails, fût-ce pour de stupides raisons. Mais il y en a de plus vicieux…

Ceux qui n’amènent pas les mails à leurs destinataires (ou qui les cachent)

On ne les connaît pas bien, ce n’est que lorsque l’on nous contacte pour et que nous voyons que le mail est bien parti qu’on les repère : les fournisseurs de mails qui acceptent nos mails mais, pour une raison ou pour une autre, les envoient rejoindre le grand rien.

Eh oui, nos mails disparaissent parfois sur le serveur de votre fournisseur de messagerie. Vous ne les trouverez dans aucun dossier, pas même dans les spams.

Il s’agit le plus souvent de choix algorithmiques du fournisseur : l’antispam est vraiment sûr que ce message est frauduleux ? Bah, pas la peine d’embêter l’utilisateur, on le jette ! (ce qui est stupide car ne permettant pas la correction des faux positifs par les utilisateurs).

Encore mieux, Gmail. Comme expliqué dans notre FAQ, si vous recevez un mail identique à un que vous avez envoyé, comme un message à une framaliste à laquelle vous êtes inscrit, Gmail cachera le mail reçu de la liste. Vous l’avez envoyé, vous en connaissez le contenu, non ? Ah, vous vouliez voir quand le message arriverait, histoire d’être sûr qu’il a bien été traité par notre serveur de listes ? Pas de bol.

Ceux qui proposent une application pourrie

Les personnes qui utilisent l’application de mail Orange sur leur téléphone ont des soucis pour envoyer des messages à des framalistes. Après investigation, nous nous sommes rendus compte que l’application met l’adresse de la liste (enfin un dérivé, elle met l’adresse dédiée à la réexpédition des mails reçus par la liste) dans l’en-tête Sender.

Que cela veut-il dire et pourquoi est-ce un problème ? Cela fait croire que le mail provient du serveur des framalistes. Comme notre serveur n’est pas stupide, voyant un mail provenant soit-disant de lui-même mais passant par un serveur non-autorisé à envoyer des mails framalistes, celui-ci refuse le mail. Tout simplement. C’est une des techniques classiques de lutte contre le spam que d’agir ainsi.

Conclusion

Les problèmes face aux gros silos de mail sont nombreux, et sont loin d’être tous dus à une mauvaise configuration de votre serveur mail que vous chouchoutez vous-même (ou de ceux que nous configurons… Non vraiment, c’est pas nous qui pondons de telles bouses ! D’où ce joli hache-tague : c’est #PasMonCaca).

Je pense personnellement et sincèrement qu’il y a une part d’incompétence de la part de ces silos dans un certain nombre de cas. Si tout le monde jouait le jeu correctement, le mail ne serait pas aussi compliqué qu’aujourd’hui.

Que pouvez-vous faire ? Eh bien, à part changer de fournisseur de mail (connaissez-vous les CHATONS ?), vous pouvez contacter le support de votre fournisseur actuel, lui expliquer la situation et lui dire que ce n’est pas normal. Nous pouvons vous fournir, le cas échéant, les codes d’erreur retournés par son serveur pour les mails que nous vous envoyons. Peut-être qu’en étant suffisamment nombreux à râler, la situation évoluera.

Fun fact : combien des fournisseurs de mail évoqués dans cet article permettent de contacter leur serveur de mail en IPv6 ? Un seul — je vous laisse chercher lequel 😁

(Et si vous vous posez la question, oui, les serveurs de framasoft.org et framalistes.org sont accessibles en IPv6, comme toute l’infrastructure de Framasoft. Quand on veut, on peut.)

Image d’en-tête par barefootcollege, source.