En fin d’année 2024, on a fait notre deuxième IndieCamp de 2024. Les IndieCamps c’est des moments qu’on prend 2 fois par an pour se retrouver en physique ce qui est très rare pour notre équipe parsemée aux 4 coins de la France, et où on établit notre stratégie collective.

Ce dernier camp était l’occasion pour nous de nous rappeler notre vision et nos objectifs collectifs. En ce début de nouvelle année, c’est un bon moment pour vous en dire un peu plus sur les ambitions du collectif et notre feuille de route pour y parvenir.

Pour des communs numériques humains

Ce n’est pas un secret, nous oeuvrons à un numérique libre au service des besoins et des personnes qui utilisent ces outils. Pour cela nous essayons de construire des communs numériques.

Plus concrètement, notre objectif à horizon 3 ans (plus ou moins), c’est d’arriver à fédérer différent.es acteur.ices autour d’une sélection d’outils numériques libres intégrés entre eux et qui répondent aux usages remontés par les personnes qui les utilisent. En bref, c’est l’évolution de notre produit liiibre à un niveau supérieur.

Pour autant, l’idée n’est pas d’industrialiser une suite d’applications à la google. Notre objectif n’est pas non plus de centraliser et de faire UNE plateforme unique.

Au contraire nous sommes attaché.es à notre collectif à taille humaine, aussi bien dans notre équipe que dans le dimensionnement de nos outils. Plutôt que de grossir trop, nous préférons nous entourer. Ce vaste écosystème du libre est rempli de personnes talentueuses et engagées avec lesquelles on discute déjà (ou pas encore… envoyez nous un message alors!). C’est avec ces autres personnes et leurs spécialités que nous arriverons à créer et gérer ces communs numériques libres et humains.

Pour être soutenable, notre ambition et notre échelle c’est de viser 50 000 personnes qui utilisent les outils que nous hébergeons et développons en commun.

Avec ce chiffre et cette échelle raisonnable, nous serions en mesure de faire vivre l’ensemble des personnes derrières les outils. C’est à dire les personnes qui vous répondent en cas de problèmes, celles qui font les mises à jour et entretiennent les serveurs et l’infrastructure technique où les logiciels sont déployés, celles qui debug le logiciel, celles qui en développent de nouvelles fonctionnalités, celles qui forment et accompagnent aux usages…

Notre ambition c’est simplement de pouvoir rétribuer à leur juste valeur toutes ces personnes et de redistribuer au milieu du libre et aux nombreuses personnes qui développent parfois toutes seules des morceaux de code repris pour des fonctionnalités essentielles dans de gros logiciels que nous hébergeons.

Évidemment ça c’est nos objectifs plus lointains et notre idéal (pour autant ni utopique ni inaccessible et pas si lointain en fait). Pour y parvenir, plusieurs étapes à plus court terme sont dessinées pour cette année 2025.

Priorisation à court terme.

En octobre 2024, nous vous avions partagé un questionnaire pour que vous nous partagiez vos retours, problèmes et idées sur nos outils. Merci beaucoup à tous ceux et celles qui ont pris le temps de répondre.

Nous sommes parti.es de vos réponses pour établir et prioriser notre feuille de route lors de notre séminaire IndieCamp de novembre. Voici les différents chantiers qui nous attendent en 2025:

Consolider l’existant

Pour une édition vraiment collaborative

On sait que notre outil d’édition collaborative actuel basé sur OnlyOffice n’est pas idéal. Parfois la page devient blanche, parfois le texte saute…. C’est une de nos priorités d’améliorer ce point qui est parfois frustrant pour vous. A très court terme on vous propose deux choses:

• Mettre en place un autre logiciel d’édition: Collabora que certain.es ont peut-être déjà essayé car on l’a déployé dans le passé. Cependant, ce logiciel comprend encore quelques bugs et incompatibilités pour certains formats de fichiers.

• On prévoit donc d’activer la possibilité d’avoir plusieurs outils d’édition en même temps et de pouvoir choisir selon les usages et documents à éditer. On vous accompagnera au mieux pour identifier l’outil qui répond le mieux à l’usage afin qu’il soit le plus fluide possible.

• En parallèle, nous allons aussi déployer d’autres outils non intégrés au nuage comme un Etherpad (ou HedgeDoc qu’on déploie actuellement) notamment pour la partie rédaction collaborative en ligne qui sont mieux optimisés pour cet usage de rédaction longue à plusieurs simultanément.

Chouchouter Matrix

Cette année on a passé quelques temps et quelques neurones sur Matrix et Element surtout avec la migration depuis Rocket.Chat mais aussi dans le cadre d’autres projets (il faut qu’on vous en parle bientôt). On est assez content de cet outil qui se révèle bien robuste et fiable à l’usage et lors des mises à jour et donc plaisant de travailler avec.

Puisque c’est un outil dans lequel nous pouvons avoir confiance, en 2025 on a envie de s’occuper et développer cet outil car il reste encore quelques choses à améliorer.

Pêle-mêle dans la liste d’améliorations sur Element et Matrix: la fédération entre différentes instances (notamment la découverte d’instances), la gestion admin d’une instance, les sondages, le parcours de chiffrement…

Une meilleure gestion des utilisateur.ices

On vous en a brièvement parler dans le précédent journal de bord, un des projets qui nous a aussi beaucoup mobilisé en 2024 c’est le développement de SCIM. C’est un protocole pour simplifier la gestion des utilisateur.ices et ressources entre différentes applications. Ce projet a été possible grâce au financement de NGI. Notre candidature remonte déjà à 2022, et c’est donc un bon projet qui est en train d’aboutir. En effet, dans les prochaines semaines, nous allons finaliser son déploiement ce qui va faciliter la gestion des utilisateur.ices notamment pour la création et suppression de comptes ou pour le partage de fichiers. Nous avons d’ailleurs fait un petit site explicatif pour celles et ceux qui souhaiteraient en savoir plus.

Créer le futur

Déshabiller Nextcloud

La mise à jour de Nextcloud vers la version 28, avec tous les bugs que cela a amené, a renforcer l’idée que nous avions depuis quelques temps déjà de sortir de Nextcloud! (Pas de panique ça ne va pas être tout de suite).

En effet nous ne sommes plus en accord avec la manière dont Nextcloud est développé actuellement notamment les priorités de développements (entre autre le développement autour de l’IA) et le modèle économique (qui entraîne des versions moins stables comme la dernière que nous avons mise à jour). Si aujourd’hui Nextcloud remplit de nombreux usages, les applications rattachées comme le chat ou la visio interne sont pourtant souvent moins pratiques et efficaces comparées à d’autres outils pour le même usage.

Ce changement ne va pas arriver de sitôt. Pour l’heure nous n’avons pas d’alternatives pour tous les usages que Nextcloud couvre mais nous posons cette intention ici afin de commencer à investiguer et préparer la sortie future de cet outil pour d’autres applications.

Plus concrètement, nous allons donc déployer différents outils en phase de test au départ, pour essayer de trouver des alternatives robustes pour chacun des usages de Nextcloud. Si des personnes souhaitent voir ces alternatives et participer aux tests on vous tiendra au courant dès qu’une nouvelle application est déployée pour avoir vos retours.

De nouveaux services

Avant de parler des nouvelles applications que nous prévoyons, nous allons mieux communiquer sur les applications que nous hébergeons déjà. Plusieurs personnes nous ont remonté ne pas connaître toutes les applications que nous proposons. Nous allons sûrement revoir quelques choses sur notre site et dans nos newsletters. Si vous n’êtes pas encore abonné.es, c’est l’occasion d’ailleurs car nous allons communiquer pas mal de nouveautés cette année.

En effet, nous allons lancer prochainement plusieurs nouvelles applications en phase de test au départ. Puis en fonction des retours nous les déploierons totalement en les intégrant avec les autres outils voire à l’offre Liiibre (ou même d’autres suites d’applications). Très prochainement, nous vous annoncerons donc le lancement du “labo IndieHosters”. Et pour vous donner encore plus d’impatience, on vous l’annonce, on travaille actuellement sur une offre de mails!!! Nous y travaillons depuis quelques temps en partenariat avec une autre structure libre et chouette nommée Algoo qui sait gérer efficacement l’envoie de mail. Tout ça devrait arriver assez rapidement!

Pour faciliter l’expérience dans ces différentes applications, nous travaillons aussi sur un portail où retrouver à un seul endroit toutes les applications qui sont hébergées et accessibles pour vous. Sans attendre quelque chose de révolutionnaire, ce endroit accessible en un clic permettra on l’espère de mieux se retrouver et naviguer en fonction de vos usages.

Continuer à s’entourer

Comme pour les mails, cette année 2025 sera très sûrement l’année des rapprochement avec d’autres personnes et organisations qui oeuvrent à un numérique libre et humain. En réalité ces rapprochements sont effectifs depuis quelques temps déjà comme avec OSP dont on racontait notre aventure dans cet article de blog. Mais cette année on pourra enfin vous dévoiler ce que ces échanges et mutualisations avec d’autres permettent de créer!

Pour résumer en quelques mots, c’est avec plein d’enthousiasme et d’idées qu’on aborde cette année 2025. En 2024 le collectif a doublé et nous sommes maintenant 8 personnes chez IndieHosters avec de nouvelles énergies. En 2025 on va ainsi pouvoir continuer à héberger le plus fidèlement possible les outils qui vous correspondent et construire ensemble les communs numériques dont nous avons besoin!

Bonne année à toutes et à tous!

On vous souhaite plein de collaborations dans vos projets et on espère que les communs auxquels vous contribuez et participez se porteront du mieux possible cette année et au-delà!

Voici le deuxième chapitre de notre journal de bord qui continue la dynamique de transparence relancée cet été.
Pour rappel, il s’agit de quelques lignes dans lesquelles on vous raconte ce qu’il s’est passé et ce qu’on a fait dans le collectif IndieHosters ce trimestre. On reprend pour ça l’exercice de compte rendu trimestriel interne que l’on fait au sein de Libre Entreprise (LE) pour informer les autres membres du réseau de l’avancée de tout le monde.

Pour celleux qui trouvent ça bizarre ou à l’inverse trop bien de partager ces journaux régulièrement, on vous renvoie au premier journal de bord où on explique en détail pourquoi cela nous tient à cœur de vous partager ces lignes.

De notre côté, on est bien content·es de réussir à trouver un peu de temps (ce qui n’est jamais simple) et d’arriver à maintenir cette dynamique pour cette deuxième édition. En espérant qu’on tienne cette plume régulière encore longtemps!

Compte-rendu de ce 3ème trimestre 2024

💶 côté finance et juridique 💶

Renouvellement gros contrat

Dans le chapitre précédent, on vous racontait qu’on avait enfin réussi à rapatrier un de nos gros contrat historique chez IndieHosters, et bien…. En septembre on a appris que notre Appel d’Offre pour son renouvellement a été accepté! Il y avait un peu de pression au moment de poser le dossier, notamment sur la formulation et l’évolution de notre offre et de nos prix. Et aussi car c’est pour nous un gros contributeur historique et qu’il nous serait difficile de nous passer de ce contrat en l’état actuel des choses. Mais c’est une happy end et un gros soulagement.

IH va se transformer en SCOP

Ça fait un bout de temps qu’à IndieHosters on se pose la question de notre évolution, jusqu’ici on hésitait encore entre passer en SCOP ou en SCIC… C’est décidé, ce sera une SCOP! Et on a même arrêté une période concrète… avril/mai 2025.

L’accompagnement avec l’URSCOP commencera à partir d’octobre. En réalité pas de changement brusque à venir dans notre manière d’être et de faire car niveau gouvernance et fonctionnement nos pratiques actuelles sont déjà compatibles avec les statuts d’une Scop.

Au programme des prochains mois: régler les détails juridiques (qui est associé·e? Quel est le montant du capital pour entrer? Qui seront les premier·ères mandataires sociaux·les? …) Et revoir notre offre pour pouvoir améliorer notre prévisionnel.

Discussion qui tombe à pic avec l’arrivée de nouveaux membres dans l’équipe!

Et la SCIC?

Notre passage en SCOP ne remet pas en question notre ambition évoquée dans le dernier journal de bord: fédérer différent·e·s acteur·ices du numérique libre pour mutualiser des moyens et services et établir une offre commune. La SCIC est donc toujours d’actualité.

Le projet avance aussi de ce côté, petit à petit, quelques rencontres et des discussions avec d’autres camarades de conditions et de convictions. On fera une annonce avec des tambours au moment opportun!

♥️ côté humain ♥️

Recrutement

Là aussi, on vous en parlait dans la première édition du journal de bord, on a recruté de nouvelles personnes au sein du collectif IndieHosters. Comme vous l’avez peut-être vu, on a enlevé les offres de recrutement sur notre site, car en effet on a “fini” nos recrutements (techniquement, le dernier recrutement a commencé en octobre donc on vous en parlera la prochaine fois). Au final, 2 personnes nous ont rejoint ce trimestre.

Il s’agit de:

• Thibault avec un profil sysadmin à mi-temps.
• Arnaud un profil product-owner / tech à temps plein pour nous aider sur le support notamment.

C’est assez chouette de voir le collectif d’IndieHosters s’agrandir et accueillir de nouvelles têtes. Ça faisait longtemps! Être plus nombreux·ses permet de parler des sujets sur lesquels on est déjà depuis quelques années avec des énergies nouvelles et des visions différentes.

📚 Organisation de notre travail chez IH 📚

Ce trimestre, on n’a pas grand chose à dire sur ce point (ce qui est pour nous plutôt une bonne nouvelle. )
Comme évoqué dans la dernière fois, l’outil Planka que nous utilisons maintenant au quotidien semble nous convenir tout comme nos différentes réunions et leur récurrences

Grâce aux efforts de stabilisation et de respect de nos process de travail et de nos temps de réunion, ce trimestre a été l’occasion de tester et éprouver notre organisation par rôles (au passage merci Yaal pour l’inspiration et les discussions!) et de mieux les définir.

Évidemment on fait encore des ajustements mais ils sont assez marginaux et l’équipe commence à bien s’approprier les temps et les outils.

La conséquence directe, c’est que l’intégration de nouvelles personnes s’est faite en douceur, et la nouvelle répartition des rôles au sein de l’équipe aussi. On a même créé des nouveaux rôles, et pour l’instant ça tourne plutôt bien!

🍄 Mycelium 🍄

Assez peu de rencontres formelles notables ce trimestre (c’était l’été donc plus de rencontres en vacances!)

• TimG et TimJ ont participé au NEC à Chambéry en septembre, l’occasion de voir pas mal d’acteur·ices engagé·es dans un numérique libre.

🤖 côté opérationnel 🤖

SCIM

Le projet SCIM a pas mal avancé. On ne sait plus si on vous en a déjà parlé. Dans le doute, voici un petit récapitulatif. SCIM c’est un projet lancé il y a quelques temps (et années), puis financé par NGI l’année dernière, qui permet de gérer plus efficacement les identités entre différentes applications. Grâce au travail et contributions de plusieurs dev (Yaal, CodeLutin, Florent, Peter Bouda…) plusieurs modules sont opérationnels et on va bientôt les déployer sur nos instances.

On a aussi fait un petit site pour expliquer l’intérêt de SCIM: https://scim.libre.sh/

Dashboard Grafana

Dès son arrivée, Arnaud a amélioré et mis en place un meilleur dashboard Grafana pour suivre les erreurs et incidents sur nos clusters.

Le problème de nettoyer et améliorer ce tableau qui remonte les erreurs, c’est que du coup, on les voit mieux et elles semblent plus nombreuses. Mais au moins maintenant on est plus nombreux·ses à pouvoir les voir et à intervenir.

En parlant d’erreurs, passons au prochain point…

Migration sur NC.28

C’est peut être un peu méchant de parler de Nextcloud l’un des principaux outils que nous déployons seulement sous l’angle des problèmes et des erreurs.

Et en même temps… 2 mois après le passage en version 28, qui aurait pu prédire qu’on en serait encore à traîner des bugs et à devoir faire du correctif? pas nous! Problèmes de partage de dossier, suppression de fichiers, erreurs des clients de synchronisation… Pas mal de temps et d’énergie passés sur cette version, pourtant normalement la plus stable encore disponible et supportée.

On ne va pas vous parler de la v29… vraiment… mieux vaut ne pas ouvrir le dossier.

La morale de cette histoire, c’est que la question de notre dépendance à cet outil et son besoin de développement, interroge de plus en plus. D’autant plus vis à vis de notre modèle économique qui repose en grande partie sur ce logiciel.

Questionnaire de satisfaction de nos contributeur·ices

Enfin, on a envoyé un questionnaire à nos contributeur·ices pour savoir ce qu’iels pensent de nos outils, de leur stabilité, qu’est-ce que qu’il leur manque… Ce questionnaire nous permettra d’établir une feuille de route plus précise sur ce qu’il faut qu’on améliore et les besoins de nos contributeur·ices.

Il nous permettra aussi d’améliorer nos relations avec nos contributeur·ices et d’identifier certaines frustrations. On n’avait pas fait ça depuis longtemps, mais on a hâte de voir le résultat. On vous en reparle bientôt!

Merci de nous avoir lu jusqu’ici.

C’est déjà la fin de ce déjà deuxième compte rendu trimestriel partagé ici. On espère qu’il vous aura intéressé. Si vous avez des suggestions pour nous permettre de l’améliorer ou que vous souhaitez discuter avec nous, RDV sur notre canal Matrix ( salon #IndieHosters:liiib.re).
On se donne rendez-vous dans 3 mois, pour voir comment tout cela à évolué.

Comme nous le disions déjà dans un précédent article de blog ☞, au vue des directions prises par l’entreprise Rocket.Chat, nous avons migré les instances de chat Rocket.chat que nous hébergions vers un nouvel outil: Matrix ↗ (et Element ↗). Facile à dire dans un article de blog mais pas si simple à réaliser dans la vraie vie. Cet article de blog revient sur l’aventure de cette migration (voire même cette épopée).

:::info Dans cet article, nous ne revenons pas sur ce qu’est Matrix ni la distinction Element / Matrix, mais pour en savoir plus, rendez-vous sur cet autre article de blog ☞. :::

D’abord, l’annonce de la migration

Pompier·ères face à l’urgence

Tout a commencé en septembre 2023, en rentrant de vacances. A notre retour, encore détendu·es de notre été, un mail nous attendait sur notre bureau. Rocket.Chat nous informait qu’avec le passage de leur logiciel à Rocket.Chat v6, certaines fonctionnalités n’étaient plus disponibles, et ce dès octobre, soit le mois suivant!

Un peu chamboulé·es et paniqué·es, nous nous pressons d’envoyer un mail d’annonce ↗ à toustes nos contributeur·ices (c’est le mot que nous employons pour parler des organisations qui font appel à nos services, dans ce cas précis: l’hébergement d’une instance Rocket.Chat). Avec ce brusque changement de calendrier imposé par Rocket.Chat, nous nous précipitons aussi et avec le recul, notre communication un peu alarmiste n’était sans doute pas la meilleure manière de communiquer un tel changement. Une fois que nous avons informé nos contributeur·ices, et que nous leur avons au passage, aussi un peu transmis notre stress, malheureusement, nous prenons le temps de nous poser et de réfléchir pour établir une stratégie. Dit comme ça, c’est effectivement sans doute la première étape par laquelle nous aurions dû commencer. Nous présentons encore toutes nos excuses à nos contributeur·ices pour cette réaction trop précipitée.

Malheureusement, cette urgence arrive au milieu de plusieurs autres projets, notamment de gros projets qui mobilisent déjà beaucoup de nos ressources et de notre temps. Toutefois, et heureusement, depuis quelque temps déjà toutes les nouvelles instances de chat que nous déployons, sont sous le protocole Matrix via le client Element. Ainsi, pour le déploiement simple d’une instance de chat Matrix from scratch (à partir de rien), nous savons faire. En revanche, la migration depuis une instance Rocket.Chat (avec le transfert des données d’un chat à l’autre), ce n’est pas la même chose. A ce moment-là, nous n’avions pas encore d’expérience, ce qui rendait cette migration aussi soudaine un peu prématurée.

Une surprise pas si surprenante

En fait même si ce brusque changement de calendrier nous a surpris, ce changement et cette perte de fonctionnalité étaient déjà connus. Nous savions déjà que ce moment arriverait au vu des évolutions de l’entreprise Rocket.Chat. C’est d’ailleurs pour cela (entre autres) que nous avions déjà décidé de ne plus déployer que des chats sous Matrix Element.

Cette migration est aussi un bon moyen de nous rappeler notre certaine dépendance aux outils que nous hébergeons. Et justement, l’un des (nombreux) avantages de Matrix c’est qu’il s’agit d’un protocole, d’un standard, dont la gouvernance est gérée par une fondation. Cela signifie que nous pouvons avoir un pouvoir de décision sur son évolution en étant membre de la fondation (IndieHosters fait parti de la fédération Matrix depuis l’année 2024) et que d’autres serveurs et d’autres clients peuvent être plus facilement substitués si ceux actuels (Synapse et Element) ne conviennent plus.

A terme, cela nous invite également, à nous entourer de développeur·euses afin d’être en pleine maîtrise des outils que nous déployons, ou a minima, d’être plus résilient·es face à nos dépendances.

Puis, tout faire pour limiter l’angoisse du changement d’outil

Notre choix d’Element?

Depuis le début de l’article nous parlons d’Element comme client - comme interface utilisateur·ice pour notre outil de chat - comme d’une évidence. Cependant, ce choix de notre part n’est pas anodin et n’a pas été au goût de tout le monde.

Depuis le lancement de notre offre liiibre, nous avons fait le choix de n’utiliser qu’un seul outil de chat afin de faciliter son déploiement et sa maintenance. En parallèle, nous avons testé et déployé Matrix sous Element. Initialement, il s’agissait d’un laboratoire car nous savions qu’il nous faudrait un jour, un autre outil que Rocket.Chat et nous étions convaincus par le projet politique et technique derrière (plus de détails sur notre choix d’Element ici ☞). Ainsi, lorsque l’urgence de la migration est arrivée, nous n’étions pas en mesure de proposer une autre alternative à cet outil dont nous étions familier·ères.

Jusqu’alors, ce parti pris d’Element depuis notre position était presque invisible pour l’utilisateur·ice final·e… mais avec cette soudaine migration, ce choix est devenu alors bien visible avec un changement d’interface qui a pu provoquer quelques réticences.

Les réticences à Element

Des différents retours que nous avons eu, la crainte la plus récurrente, c’est qu’Element est associé à un univers plus technique, un imaginaire plus “hacker avec capuche”. Et ce, car Element est associé (à juste titre) au chiffrement avec lequel beaucoup de nos contributeur.ices ne sont pas acculturés. Les possibilités de fédérations, autre fonctionnalité phare d’Element, bien qu’utiles dans nos écosystèmes sont aussi perçues comme un changement amenant forcément son lot de complexité. Au moment de la migration, un autre point n’a pas aidé non plus. Certaines personnes avaient déjà essayé (avant) Element dans ses versions beta plus expérimentales et moins accessibles (avec des bugs de notifications, de mails, des problèmes de clés…) ce qui a renforcé leurs craintes face à la prise en main de ce nouvel outil. A noter également que certaines organisations avaient aussi connaissance d’autres outils, voire utilisaient déjà ces autres outils qui leur semblaient donc naturellement plus facile à prendre en main dans ce moment de bascule.

Faciliter l’adoption d’Element

Pour le chiffrement, nous avons donc désactivé le chiffrement par défaut afin de ne pas embêter les personnes non intéressées avec ces histoires de clés publiques et privées et nous avons activé la possibilité de générer une phrase de passe à la place de clés pour faciliter la marche. Pour autant, c’est un arbitrage plus qu’une solution optimale car même si c’est un peu plus clair, il y a une étape en plus. A voir dans le futur si nous revenons sur ce processus pour le fluidifier.

Nous avons aussi fait des moments de présentations de Matrix et d’Element en visio à nos contributeur·ices . Pour celles et ceux qui préféraient l’écrit nous avons rédigeait des articles, pour expliquer nos choix ou vulgariser le fonctionnement de l’outils. Et nous avons aussi déployé une instance de tests pour acculturer les organisations à ce nouvel outil avant de faire la migration réelle.

Et enfin… déménager des instances de chat

Une première petite vague pour s’acclimater

Dans un premier temps, nous avons décidé de lancer une première vague de migration entre octobre et novembre 2023. Elle concernait les quelques organisations dont la continuité et l’historique des messages n’étaient pas nécessaires et qui ont accepté de redémarrer une instance de chat à zéro. (Ainsi que celles assez disponibles pour nous répondre en si peu de temps). Avec cette première vague, une poignée d’organisations sont migrées sur ce nouvel outil et nous avons pris le temps de former quelques personnes clés de ces organisations pour assurer la transmission et la distribution de cette prise en main.

Pour les autres organisations, nous avons bidouillé comme nous pouvions en bon pompier·ères pour que la perte de fonctionnalité soit la moins impactante possible. Notre objectif était ainsi de nous laisser un peu (trop peu) de temps pour élaborer un processus de migration des messages de Rocket.Chat à Matrix Element. Nous envisagions alors cette deuxième vague de migration en janvier/février 2024.

Une difficile planification

Si depuis quelques années nous estimons être des pompier·ères plutôt robustes et résistants, et que nous commençons à avoir une bonne expérience pour travailler dans l’urgence, pour ce qui est de savoir planifier et estimer les délais, il faut reconnaître que nous ne sommes pas encore très avisé·es.

Nous avions annoncé au tout départ, une deuxième vague de migration en janvier et février, mais à cette date, nous n’étions pas prêt·es de notre côté pour faire la migration. C’est à peu près à ce moment-là que nous avons recruté une nouvelle personne afin d’essayer d’y voir plus clair et de se libérer du temps, et notamment pour gérer la communication avec les contributeur·ices et assurer une meilleure transparence sur nos délais.

Nous avons réalisé un premier calendrier, aussi bien pour nous aider à visualiser et cadrer ce qui nous restait à faire et pour informer les contributeur·ices. Mi février, notre plan était de migrer dans un mois, début avril… Autant le dire tout de suite, nous n’avons pas tenu ce délai. Finalement, la migration a eu lieu entre mi-mai et fin juin en fonction des disponibilités des organisations.

Quelques détails

C’est le moment de rentrer un peu plus précisément dans le détail de ce que nous avons mis en place. Car depuis le début, nous savions que c’est possible de faire une migration bien jolie avec tous les messages, les canaux, l’historique… afin de n’avoir qu’un simple changement d’interface pour nos utilisateur·ices. Mais il a bien fallu façonner ce processus de migration qui n’existait pas directement, et pas spécifiquement applicable à notre contexte de déploiement.

Une des complications que nous avons aussi rencontré, c’est que la configuration d’un chat Matrix et Rocket.Chat n’est pas la même, il fallait donc changer certains paramètres de la zone DNS, une manipulation relativement simple pour qui l’a déjà faite mais tout de suite plus difficile pour des personnes qui n’ont pas l’habitude, ce qui était le cas ici car ces manips sont à faire par nos contributeur·ices. Nous avons donc mis en place une documentation interactive qui affiche des informations pertinentes en fonction des paramètres, des outils et des configurations techniques des contributeur·ices. En plus de ce guide interactif étape par étape ↗ pour réaliser les configuration nécessaire, nous avons aussi pris du temps avec les technicien·nes de ces organisations pour les accompagner sur ces manipulations.

Pour la partie purement technique, nous avons repris le script de Verdigado ↗ que nous avons modifié, testé et amélioré. Nous avons rencontré quelques problèmes car certains concepts de Rocket.Chat n’existent pas réellement sur Matrix. Par exemple sur Rocket.Chat, il y a des admins d’instance ce qui n’existe pas sur Matrix et empêche une correspondance exacte des rôles entre les deux outils. Nous avons aussi dû changer certains noms d’utilisateur·ices car certains caractères autorisés sur Rocket.Chat ne le sont pas sur Matrix. Si vous voulez voir le détails de toutes les différences, nous les avons rassemblés dans un pad des limitations de la migrations ↗

Finalement, après quelques semaines de travail, un bon week-end à perdre des points de vie pour essayer en vain de tenir nos délais, et quelques messages de report de migration, tout semblait prêt, pour une migration le 21 mai.

Dans le processus final mis en oeuvre, nous avons réalisé la migration en 2 fois, afin de limiter le temps d’inaccessibilité des chats pour les organisations:

• D’abord, lorsque les configurations techniques ont été faites par les organisations, nous déployions les instances sur nos serveurs mais sous un autre nom de domaine.
• Puis nous faisions une première migration de tous les messages et les comptes depuis Rocket.Chat.
• Puis nous vérifiions manuellement que tout avait bien été migré (rôles des participant·es, types de salons, pièces jointes…)
• Enfin, lorque tout était bon, nous fermions l’instance Rocket.Chat des organisations pour qu’il n’y ait pas de messages non migrés.
• Puis nous réalisions une deuxième migration pour les messages et événements envoyés depuis la première migration.
• Et enfin, le chat était déplacé sur le nom de domaine où se trouvait le Rocket.Chat quelques minutes avant.

Le 21 mai, nous appuyions donc sur le boutons pour lancer la deuxième migration des 9 organisations disponible à ce moment-là… Et… Evidemment tout ne s’est pas passé aussi simplement que prévu. Par exemple, la dernière boucle censée vérifier les membres d’un salon, a exclu tous les membres des salons entre 2 personnes. Et évidemment, comme c’était la dernière étape, une simple vérification automatique, nous ne l’avions pas vérifié manuellement avant de passer en prod… Du coup nous avons dû refaire la migration (par chance, à chaque fois le bug était constaté rapidement.)

Au-delà des premiers bugs inévitables rapidement corrigés, la migration s’est globalement plutôt bien passée, même si elle n’était pas aussi propre que nous l’espérions.

Evidement, après la migration des instances, nous avons organisé des temps de prise en main et de formation et nous avons partagé notre tuto sur Matrix ↗). Finalement, peu de personnes ont assisté à ces temps, mais des retours que nous avons eu, la prise en main était assez facile, passée la première connexion et la première appréhension de l’interface. La plus grosse différence qui a parfois déstabilisé, concernait l’administration des canaux (car il n’y a pas de super-admin d’une instance sur Matrix contrairement à Rocket.Chat). Mais cela ne concernait en pratique qu’une poignée de personnes par organisations et nous avons donc pu prendre un peu plus de temps pour ré-expliquer plus en détail ce fonctionnement.

Premier bilan et quelques chiffres

• Au total, près d’une vingtaine d’organisations sont parties vers d’autres outils de chat (essentiellement Teams et Mattermost) ou ont abandonné l’usage d’un chat. Cette migration à au moins été l’occasion de clarifier l’usage de nos outils pour nous comme pour nos contributeur·ices.
• Moins d’une dizaine d’organisations ont recommencé un chat à zéro.
• Et pour finir, cette migration de chat de Rocket.chat à Matrix Element représente finalement une vingtaines d’organisations soit plus de 2 500 comptes, près de 6 000 canaux et plus de 800 000 messages migrés/

Évidemment, il reste encore plusieurs détails et fonctionnalités à régler sur Element et Matrix dont certaines sur lesquelles nous avons déjà avancé. Par exemple, nous nous sommes rendus compte après coup que la fédération n’avait pas été activé dans le script de migration (ce qui est assez logique puisque les canaux Rocket.Chat ne l’étaient pas initialement). Nous avons donc développé une commande pour “/upgrade” un salon non fédéré en salon fédéré. Nous souhaitons aussi déployer un panneau d’administration pour certaines organisations, ou des bridge pour d’autres applications…

Si la fonctionnalité de chat est toujours bien là et opérationnelle, l’amélioration des fonctionnalités est sans fin, et c’est l’attention que nous portons à IndieHosters, de garantir une qualité de service et de continuer à l’améliorer.

Ce que nous avons essayé de transmettre à travers cette migration c’est qu’au-delà d’un outil qui peut changer en fonction de ses évolutions, nous nous donnions pour missions de garantir l’usage numérique que nos contributeur·ices ont besoin ici le chat, l’envoie de message entre elleux.

Pour finir, merci d’avoir lu jusqu’ici et surtout, merci de nous avoir suivi dans l’aventure d’une migration d’outils, et merci de nous faire confiance.

En tant qu’hébergeur·euses de logiciels libres, nous souhaitons rejoindre l’appel initialement publié par les petites singularités en signant à notre tour cette lettre ouverte qui alerte sur le risque de la fin du programme de financement européen aux logiciels libres.

Si vous souhaitez signer cette lettre ouverte, merci de la publier sur votre site et de compléter le tableau des signataires.

Lettre ouverte à la Commission Européenne

Depuis 2020, les programmes Next Generation Internet (NGI), sous-branche du programme Horizon Europe de la Commission Européenne financent en cascade (notamment via les appels NGI0 Commons Fund) le logiciel libre en Europe. Cette année, à la lecture du brouillon du Programme de Travail de Horizon Europe détaillant les programmes de financement de la commission européenne pour 2025, nous nous apercevons que les programmes Next Generation Internet ne sont plus mentionnés dans le Cluster 4.

Les programmes NGI ont démontré leur force et leur importance dans le soutien à l’infrastructure logicielle européenne, formant un instrument générique de financement des communs numériques qui doivent être rendus accessibles dans la durée. Nous sommes dans l’incompréhension face à cette transformation, d’autant plus que le fonctionnement de NGI est efficace et économique puisqu’il soutient l’ensemble des projets de logiciel libre des plus petites initiatives aux mieux assises. La diversité de cet écosystème fait la grande force de l’innovation technologique européenne et le maintien de l’initiative NGI pour former un soutien structurel à ces projets logiciels, qui sont au cœur de l’innovation mondiale, permet de garantir la souveraineté d’une infrastructure européenne. Contrairement à la perception courante, les innovations techniques sont issues des communautés de programmeurs européens plutôt que nord-américains, et le plus souvent issues de structures de taille réduite.

Le Cluster 4 allouait 27 millions d’euros au service de:

• “Human centric Internet aligned with values and principles commonly shared in Europe” ;
• “A flourishing internet, based on common building blocks created within NGI, that enables better control of our digital life” ;
• “A structured eco-system of talented contributors driving the creation of new internet commons and the evolution of existing internet commons”.

Au nom de ces enjeux, ce sont plus de 500 projets qui ont reçu un financement NGI0 dans les 5 premières années d’exercice, ainsi que plus de 18 organisations collaborant à faire vivre ces consortia européens.

NGI contribue à un vaste écosystème puisque la plupart du budget est dévolu au financement de tierces parties par le biais des appels ouverts (open calls). Ils structurent des communs qui recouvrent l’ensemble de l’Internet, du matériel aux applications d’intégration verticale en passant par la virtualisation, les protocoles, les systèmes d’exploitation, les identités électroniques ou la supervision du trafic de données. Ce financement des tierces parties n’est pas renouvelé dans le programme actuel, ce qui laissera de nombreux projets sans ressources adéquates pour la recherche et l’innovation en Europe.

Par ailleurs, NGI permet des échanges et des collaborations à travers tous les pays de la zone euro et aussi avec les widening countries ¹, ce qui est actuellement une réussite tout autant qu’un progrès en cours, comme le fut le programme Erasmus avant nous. NGI est aussi une initiative qui participe à l’ouverture et à l’entretien de relation sur un temps plus long que les financements de projets. NGI encourage également à l’implémentation des projets financés par le biais de pilotes, et soutient la collaboration au sein des initiatives, ainsi que l’identification et la réutilisation d’éléments communs au travers des projets, l’interopérabilité notamment des systèmes d’identification, et la mise en place de modèles de développement intégrant les autres sources de financements aux différentes échelles en Europe.

Alors que les États-Unis d’Amérique, la Chine ou la Russie déploient des moyens publics et privés colossaux pour développer des logiciels et infrastructures captant massivement les données des consommateurs, l’Union Européenne ne peut pas se permettre ce renoncement. Les logiciels libres et open source tels que soutenus par les projets NGI depuis 2020 sont, par construction, à l’opposée des potentiels vecteurs d’ingérence étrangère. Ils permettent de conserver localement les données et de favoriser une économie et des savoirs-faire à l’échelle communautaire, tout en permettant à la fois une collaboration internationale. Ceci est d’autant plus indispensable dans le contexte géopolitique que nous connaissons actuellement. L’enjeu de la souveraineté technologique y est prépondérant et le logiciel libre permet d’y répondre sans renier la nécessité d’œuvrer pour la paix et la citoyenneté dans l’ensemble du monde numérique.

Dans ces perspectives, nous vous demandons urgemment de réclamer la préservation du programme NGI dans le programme de financement 2025.

1. Tels que définis par Horizon Europe, les États Membres élargis sont la Bulgarie, la Croatie, Chypre, la République Tchèque, l’Estonie, la Grèce, la Hongrie, la Lettonie, la Lituanie, Malte, la Pologne, le Portugal, la Roumanie, la Slovaquie et la Slovénie. Les pays associés élargies (sous conditions d’un accord d’association) l’Albanie, l’Arménie, la Bosnie-Herzégovine, les Îles Feroé, la Géorgie, le Kosovo, la Moldavie, le Monténégro, le Maroc, la Macédoine du Nord, la Serbie, la Tunisie, la Turquie et l’Ukraine. Les régions élargies d’outre-mer sont: la Guadeloupe, la Guyane Française, la Martinique, La Réunion, Mayotte, Saint-Martin, Les Açores, Madère, les Îles Canaries. ↩

Dans quelques semaines, cela fera 1 an que nous sommes aspirant postulant au réseau Libre Entreprise (LE), un groupement de personnes et d’organisations qui font des trucs numériques un peu comme nous, librement. Une des pratiques de ce réseau, est l’édition d’un compte rendu trimestriel de ce qui s’est déroulé au sein de chaque collectif/entreprise durant la période écoulée.

Cet article s’inscrit dans une nouvelle dynamique de partage et sera la première entrée de notre journal de bord et on l’espère d’une longue série (mais bon… ne nous emballons pas trop quand même). Ici on va d’abord exposer pourquoi il nous semble utile de vous en parler. Ensuite on partage ce qu’on a raconté dans ce compte-rendu.

Pourquoi ce journal de bord?

Avant de rentrer dans le vif du sujet, un petit détour s’impose afin d’ exposer pourquoi il nous semble utile de vous en parler. Pour les plus pressé.es la deuxième partie raconte ce qu’il s’est passé chez IndieHosters au cours des 3 derniers mois.

Transparence

Parmi les chouettes valeurs que nous pouvons partager avec les membres de LE, il y a la transparence. Cette valeur recoupe une suggestion qui nous avait été fait il y a quelques mois par un membre des CHATONS, qui ressemblait à:

“le site est cool. Mais ça serait encore mieux si on en savait un peu plus sur le nombre de contributeur, où vous en êtes, ce que vous faites …”.

Le souci n’étant pas tant le fait de vouloir partager, que prendre le temps de documenter et de le faire… Alors, en attendant une section spéciale sur notre site, nous avons décidé de partager ici une partie des comptes rendus que nous envoyons aux membres du réseau libre entreprise.

Partage, échanges et coopérations

Faire les choses c’est bien. Les documenter c’est encore mieux. Les partager avec les autres, c’est pépite. Pourquoi?

Parce qu’il y a fort à parier, que l’obstacle sur lequel je bute, quelqu’un d’autre s’y soit déjà confronté, y ait déjà réfléchi et donc si je peux profiter de son expérience pour nourrir ma réflexion et trouver ma solution, ça me fera gagner un temps précieux.

Parce qu’en lisant ce que les autres ont vécu, j’apprends de leur erreurs, de leurs victoires, de leurs échecs, et je peux anticiper un futur projet, ou connaître certains points de vigilance à avoir.

Parce que si je prends le temps de communiquer sur ce que je fais. Je multiplie les chances de pouvoir créer des synergies avec d’autres personnes sur les mêmes thématiques. Et nous la coopération, on adore ça!

Documentation de la vie du collectif

Connaître l’histoire d’une organisation, permet aussi de mieux comprendre son fonctionnement. Savoir ce qu’on a testé, et ce qui n’a pas fonctionné sur le moment, tracer comment on en est arrivé là… Tout un tas d’informations qui sont largement sous-côtées et qui sont trop souvent négliger.

Lors de l’arrivée d’une nouvelle personne, avoir cet historique quelque part, permettra de faciliter son arrivée et sa compréhension du collectif et donc son intégration. Pouvoir disposer de cette ressource de façon écrite, lui permettra de pouvoir intégrer à sa guise, et à son rythme en autonomie l’histoire du collectif. Et ce, en complément de ce que chaque personne a gardé en mémoire et lui transmet directement.

Quand on raconte pour la 5eme fois une même histoire, il y a fort à parier qu’elle se déforme, et aussi que cela commence à nous saouler. La 5eme transmission n’est plus aussi qualitative que la première fois. Et pourtant, elle est toute aussi importante.

Et sans parler d’une autre personne. Pour nous-même. Pour se rappeler comment telle ou telle chose s’est produite. Quelle solution nous avions trouvé à telle problématique il y a 2 ans, si la question se pose à nouveau.

Bilan et introspection

Malgré toutes ces bonne intention, quand on a la tête dans le guidon, il est assez difficile de la relever. chez IndieHosters, nous avons essayé plusieurs formats. Des réunions mensuelles de review, des réunions hebdomadaires, des newsletter, des articles de blog… bref on a testé un certain nombre de choses, mais force est de constater, que nous avons toujours fini par nous faire déborder par le quotidien.

Et pourtant, on sait à quel point c’est important. Regarder dans le rétro, se poser, analyser pour pouvoir mieux imaginer l’avenir. Ce compte-rendu c’est un peu notre excuse pour faire ce qu’on souhaitait faire depuis longtemps, mais qu’on ne prenait pas le temps de le faire; C’est un engagement que nous avons pris auprès des autres membres du réseau, qui prennent elleux aussi, le temps de faire cet exercice.

Avec le partage de compte rendu, nous essayons de répondre à ces différentes problématiques et d’élargir le nombre de personnes qui pourront bénéficier de ce partage, et venir nourrir nos réflexions. C’est le 2eme compte-rendu que nous rendons, et nous espérons bien réussir cette fois à garder le rythme. Nous espérons tout autant, réussir à garder le rythme de publication afférente ici.

Journal de bord de ce 2eme trimestre 2024

💶 côté finance 💶

On a enfin réussi à rapatrier notre gros contrat historique! Avant, on passait par la CAE où était salarié Tim G car le contrat était historiquement signé et porté par elle. Ce changement a des implications côté finance (forcément) mais aussi côté humain. Côté finance, le contrat n’étant plus hébergé dans la CAE, on ne paye plus de commission à un intermédiaire.

On a aussi apprécié d’avoir un prévisionnel un peu structuré. Notamment lors des discussions sur le recrutement pendant notre camp, même s’il y a encore des questions en suspens par rapport à l’évolution de relations avec certains de nos partenaires.

😺Pour rappel, un camp c’est un moment que l’on prend 2 fois par ans pour se retrouver en vrai et parler de notre stratégie (et aussi faire “un peu” la fête)(la dernière fois qu”on en a parlé c’était le deuxième dans cet article, en 2022… depuis on en a fait 4 autres … oups, on se note d’y revenir plus fréquemment).

On est sur la fin des galères avec notre logiciel CRM. En mars/avril, il y a eu une grosse mise à jour du logiciel, entraînant une refonte des process de facturations et d’abonnement. Toute la partie automatisation s’est vu bouleversée. Un certains nombre de contributeur.ices ont été facturé.es en mars avec plusieurs mois d’avance, des factures ne sont pas parties, d’autres n’ont pas été éditées… bref une joyeuse pagaille… Le gros du travail a été fait, il reste encore quelques couacs à la marge et ça devrait se solutionner au fil du temps.

♥️ côté humain ♥️

Suite à la migration du gros contrat, Tim G a enfin pu quitter Oxalis et nous rejoindre. Nous sommes donc depuis le 1er juin , 4 salarié.e.s chez IH . Soit 3,75 ETP salariés auxquels s’ajoute le temps de travail de Tim J pour arriver environ au global à 4.25 ETP pour notre structure.

Par le passé, certaines personnes étaient vraiment réfractaires à se salarier, et souhaitaient garder leur indépendance. Notre expérience de cela, c’est qu’entre les mutuelles des uns, les cotisations des autres … trouver des équivalences en terme de rémunération était un vrai casse-tête. Le fait de pouvoir aligner les statuts des personnes qui nous rejoignent est un vrai confort. On a longtemps réfléchi à la possibilité d’avoir des statuts différents au sein de la même structure.

Fin juin, nous avons fait notre camp (qui fera l’objet d’un article prochainement), l’occasion de mettre à plat la stratégie des prochains mois, de discuter des futurs recrutements, de passer du temps ensemble et d’aplanir les tensions. Nous nous sommes réunis tous les 5, pendant 3 jours du côté de Rive-de-Gier dans un charmant gîte, trouvé à la dernière minute. C’était aussi l’occasion de dire au revoir à Cécile, notre accompagnatrice en intelligence collective, qui nous suivait depuis plusieurs années et dont la mission est arrivé à son terme. Ce temps de cohésion va donc évoluer dans les prochains mois.

🦾 Besoin de bras 🦾

Vous l’avez peut être vu passé sur les réseaux ou sur notre site internet. Nous sommes en plein processus de recrutement depuis quelques semaines.

Après de longues heures de réflexions, plusieurs entretiens, quelques rebondissements de dernières minutes,encore de nombreuses heures de réflexions, on voit le bout du tunnel!

Avec le prévisionnel nous étions partis sur une base de 2 ETP pour nous rejoindre. Nous avons reçu beaucoup de CV, beaucoup beaucoup beaucoup de CV.

Assez rapidement, nous avons finalement décidé de ne pas prendre de personne en alternance. Le coût humain et financier par rapport aux premières missions définies semblait trop important.

Finalement fin juin, une candidature de dernière minute sur une autre fiche de poste que celle initialement imaginée, a retenu toute notre attention. Après 2 entretiens, nous avons peut être trouvé notre alternante! (spoiler du prochain CR, on l’a bien trouvé)

Concernant les posts junior et/ou expert, les candidatures reçues étaient très variées, et il a fallu brainstormer à de nombreuses reprises pour savoir un peu plus précisément ce que nous recherchions et voulions. Spoiler alert: On sait un peu mieux (on s’oriente vers des profils déjà expérimentés), mais on n’est toujours pas fixé à 100% (qui? combien de temps? sur quel projet?). Pour l’instant 3 profils ont été retenus. Mais les bases de notre prévisionnel risquant de changer finalement dans les prochains mois, les cartes sont à nouveau rebattues.

Cette expérience a été très riche, c’est la première fois que nous lançons un recrutement, chez IndieHosters. Avant cela, l’effectif grossissait plutôt par cooptation. On a beaucoup appris. La plus grosse leçon est sans aucun doute que nous avions largement sous évalué la charge de travail que nécessite un recrutement et la charge émotionnelle qui va avec (devoir dire non, alors qu’on aimerait dire OUI à tout le monde… n’est pas une sinécure).

Notre demande étant assez large pour ne nous fermer aucune possibilité et être sur de pouvoir avoir des candidates et candidats. A ce moment-là, nous pensions que nous allions avoir très peu de retour. Des profils variés se sont présentés. Ce qui a généré de nouvelles discussions sur de nouveaux besoins. Le tout nécessitant de prendre notre temps, tout en devant respecter un certain calendrier pour soulager notre besoin de nouveaux bras.

📚 Organisation de notre travail 📚

Pour l’organisation de notre travail hebdomadaire et avoir une vue globale, on est passé à Planka. Et on a réussi à maintenir nos points d’équipe hebdomadaires!

Pour rompre l’isolement, on remet également en place une pause café hebdomadaire à heure fixe le mardi matin. On teste cette nouvelle récurrence.

🍄 Mycelium (notre vocable pour le réseau) 🍄

Projet SCIC

Peut-être qu’on ne vous en a jamais parlé aussi directement… alors disons qu’on sème juste des graines dans cet article avant d’officialiser notre ambition (mais n’hésitez pas à nous contacter si ça vous intéresse). En tout cas, ça avance. On a eu plusieurs réunions avec d’autres acteurs du monde du liiibre, autour de notre projet de SCIC. Le temps avançant, le projet évolue et se précise. De notre côté l’évolution vers une SCIC ou avec un passage par une SCOP est toujours en discussion.

Avec la SCIC l’idée serait de proposer une offre autour d’un produit construit et géré collectivement par les différents acteurs de la SCIC. Les modalités sont encore floues, et les discussions se poursuivent

Se retrouver en vrai lors du camp pour y réfléchir ensemble à d’ailleurs permis de poser quelques briques de plus. On commence à mieux définir ce qu’on souhaite construire collectivement avec d’autres personnes et organisations, mais aussi ce qu’on peut apporter de notre côté.

GRIST

Le projet avance également. Peut-être que vous entendez ce nom pour la première fois. Mais c’est quoi ça? GRIST est un outil de base de données sur lequel nous nous penchons sérieusement depuis quelques mois. Au cours des dernières semaines, il est apparu que plusieurs collectifs/entreprises de notre réseau, avançaient également sur ce projet. De-là est né l’envie de créer une association qui regrouperait les acteurs souhaitant développer la communauté GRIST en France. Les discussions se poursuivent pour la structuration de cette communauté, et des échanges avec la maison mère de GRIST ont déjà eu lieu.

🤖 côté tech 🤖

SCIM

Migration du cluster Louise Michel vers Ada Lovelace

La migration est finie! Louise va bientôt être débranchée, ça nous fait un pincement au coeur, mais il fallait vraiment qu’elle prenne sa retraite.

Migration RocketChat vers Matrix

On a migrés tous nos Rocket.Chat vers des instances Matrix. Le process ne fut pas aussi fluide et rapide qu’on l’aurait souhaité mais au bout du compte la migration a été effectuée et semble convenir aux usager.ères.

On a perdu quelques contributeur·ices au passage mais cela nous à tout de même permis de faire un point sur les usages car c’est essentiellement des personnes qui n’utilisaient pas leur chat

Pour faciliter au mieux la migration nous avons organisés plusieurs moments pour former nos contributeur·ices à Element Matrix, corriger quelques points sur notre base documentaire et écrit un nouvel article de blog, illustré cette fois, pour expliquer simplement mais avec détails le chiffrement sur matrix.

Merci de nous avoir lu jusque ici.

C’est tout pour ce premier compte rendu trimestriel partagé ici. On espère qu’il vous aura intéressé. Si vous avez des suggestions pour nous permettre de l’améliorer ou que vous souhaitez discuter avec nous, RDV sur notre canal Matrix ( salon #IndieHosters:liiib.re). On se donne rendez-vous dans 3 mois, pour voir comment tout cela à évoluer.

Voici un article de blog illustré pour tenter d’expliquer plus en détail le chiffrement sur Element et Matrix.

Comprendre les bases: Matrix, Element, Synapse?

Pour commencer, parcourons les différents éléments qui composent le système de chat:

Element le client

Element c’est le client, c’est-à-dire l’interface pour faciliter la communication avec le serveur (pour ne pas communiquer en ligne de commande). C’est l’application sur votre ordinateur ou téléphone qui dialogue avec les serveurs de chat pour vous connecter ou pour envoyer des messages.

Matrix: le protocole

L’ensemble des techniques utilisées pour le déploiement, la communication serveur, certaines requêtes du client, le chiffrement… constitue un protocole, c’est le protocole Matrix.

Synapse: le serveur

Le serveur c’est l’endroit où est déployé l’instance de chat. Derrière, la technologie utilisée par IndieHosters c’est Synapse (mais il existe d’autres manières de déployer un serveur de chat compatible au protocole Matrix comme Conduit, Construct…). Sur ce serveur, quelques informations sont stockées notamment certaines informations liées au comptes et les salons créés sur le serveur (pas forcément les messages). Les messages reçus et non lus sont forcément stockés sur le serveur de réception (du destinataire du message).

L’envoi d’un message non chiffré

Commençons par le plus simple, l’envoi de messages non chiffrés. Par exemple Alex sur le serveur A (nom d’utilisateur.ice: @Alex:serveurA) veut parler avec Sacha sur le serveur S (@Sacha:serveurS). Dans cet exemple, le serveur A et le serveur S ne sont pas chiffrés.

Initialisation

Alex se connecte à Element avec son identifiant et son mot de passe. Element fait ensuite une requête à son serveur, :serveurA pour valider la connexion et récupérer les informations comme les paramètres des ses salons, s’il y a des messages en attente…

Envoi du message

0. Ecriture

Alex écrit son message

1. Copie

Le message est ensuite copié puis stocké sur le client Element d’Alex, soit localement soit sur son espace cloud dédié. Cela permet par la suite à Alex d’avoir accès à ses messages sans faire de nouvelles requêtes inutiles.

2. à 5. Envoi du message et chiffrement

Lorsqu’Alex appuie sur “envoyer” son client fait une requête depuis son serveur A vers le serveur de Sacha (serveurS) pour avoir l’autorisation d’envoyer le message. Si l’autorisation est accordée, le message est envoyé sur le serveur S.
Le message est chiffré lors de cet envoi via une requête sécurisée (via le protocole MatrixSSL). Cela permet d’éviter les potentielles interceptions de messages pendant le transfert, néanmoins, le message est accessible et lisible sur les serveurs où il transite et où il est stocké.

Réception du message

Le message est reçu sur le serveur S. Il est déchiffré et donc lisible par les administrateur.ices notamment. Il est stocké sur le serveur en attendant d’être lu.

1. et 2. Récupération du message

Sacha se connecte à son client Element avec son identifiant et son mot de passe (voir la phase d’initialisation). Element fait donc une requête à son serveur, :serveurS pour valider la connexion et récupérer les informations sur ses salons et pour vérifier les nouveaux messages.
S’il y a un nouveau message, alors celui-ci est envoyé via une requête sécurisée (chiffrement du message lors de la transmission via MatrixSSL) sur le client Element de Sacha.

3. Lecture et copie

Le message est maintenant sur le client Element de Sacha qui peut donc le lire sur son interface. Le message est copié sur son client (localement ou espace dédié).

Cet exemple reste identique si Alex et Sacha sont sur le même serveur. Il n’y a alors qu’un seul serveur de connexion et le serveur est à la fois serveur d’envoi et de réception.

Ici il s’agit d’un exemple d’envoi de message privé non chiffré entre 2 personnes mais c’est la même chose pour des salons non chiffrés entre plusieurs personnes.

Le chiffrement

Maintenant, comment cela marche-t-il avec des serveurs où le chiffrement est activé (par défaut ou volontairement) ?
Le chiffrement E2E (end to end encryption) signifie chiffrement de bout en bout. Ce protocole permet de rendre les messages d’Alex indéchiffrables dès l’envoi du message depuis son ordinateur jusqu’à la réception par Sacha sur son ordinateur (ou téléphone).

D’abord, les clés, publique et privée

Dès que le chiffrement est activé sur un serveur (ou sur un salon chiffré) alors Element génère des clés de chiffrement aux participant.es des salons. Une paire de 2 clés est générée. La combinaison de plusieurs clés (au moins 2) permet de chiffrer ou déchiffrer un message.

La clé publique

Elle est publiquement accessible, envoyée et stockée sur le serveur de la personne qui crée ses clés. Donc sur le serveur A pour Alex et le serveur S pour Sacha. Il suffit de faire une requête au serveur pour avoir accès à la clé.
La clé publique d’une personne est nécessaire lors de l’envoi d’un message par une autre personne pour chiffrer le message. Autrement dit, Alex a besoin de la clé publique de Sacha pour lui envoyer un message.

La clé privée

La clé privée est… privée, c’est-à-dire qu’elle ne doit pas être partagée. Elle est donc stockée coté client, donc sur Element, soit localement soit dans son espace cloud dédié. La clé privée est nécessaire lors de l’envoi pour chiffrer son propre message et lors de la réception pour déchiffrer un message qu’une autre personne a chiffré avec notre clé publique. Autrement dit:

• Sacha a besoin de sa clé privée pour chiffrer n’importe quel message qu’iel souhaite chiffrer, donc pour envoyer un message chiffré à Alex.
• Mais Sacha a aussi besoin de sa clé privée pour déchiffrer un message chiffré qui lui est adressé, par exemple les messages chiffrés qu’Alex lui envoie.

L’envoi d’un message chiffré

Initialisation: récupération des clés publiques

Lorsque Sacha se connecte à un salon chiffré (voir l’étape d’initialisation], Element envoie une requête au serveur du salon pour récupérer les clés publiques des membres des salons.

Envoi d’un message chiffré

0. Ecriture du message

Sacha écrit son message sur son client Element (donc en local). Le message est lisible.

1. Stockage du message

Le message écrit (et non encore chiffré) est alors stocké sur Element (localement ou sur son espace cloud dédié). Le stockage en local permet, là aussi, de ne pas avoir de protocole supplémentaire pour relire son message.

2. Copie du message

Le message est ensuite copié.

3. Chiffrement E2E du message

C’est cette copie du message de Sacha qui est chiffrée puis envoyée.
Pour chiffrer le message, il lui faut la clé privée de la personne qui envoie le message (Sacha) et la clé publique de la personne qui reçoit le message (Alex). La clé publique d’Alex a été récupérée lors de la connexion. Avec la combinaison de ces 2 clés, sa clé privée et celle publique d’Alex, Sacha chiffre son message pour Alex.

Dans un salon chiffré où il y a plusieurs personnes, les clés publiques sont récupérées lors de la connexion au salon. Les messages sont alors chiffrés avec l’ensemble des clés publiques des personnes présentes dans le salon et la clé privée de la personne qui envoie le message.

4. Sécurisation supplémentaire

En plus du chiifrement, Matrix déploie un autre procole appélé MLS afin de surveiller, garantir et protéger le chiffrement de bout en bout du message (via des systèmes d’autentification, de signature, de détection…).

5. et 6. Envoi du message

Comme pour les messages non chiffrés, une requête est faite via le serveur S de Sacha vers le serveur A d’Alex afin d’autoriser l’envoi du message. Si l’autorisation est accordée, la copie du message chiffré est alors envoyée via une requête sécurisée (toujours via matrixSSL) qui vient chiffrer le message une seconde fois.

Réception du message

1. Sécurisation supplémentaire

Le message de Sacha, chiffré par le protocole E2E et “surveillé” par MLS, est stocké sur le serveur A en attendant d’être lu. Il est donc indéchiffrable par les administrateur.ices ou autres personnes ayant accès au serveur.
Ce protocole MLS est continu depuis le départ du message du client de Sacha jusqu’a ce qu’il arrive sur le client d’Alex. De la même manière que pour l’envoi du message, le chiffrement lors de la réception du message est aussi garanti et protégé via le même procotole MLS.

2. Récupération du message

Alex se connecte à son serveur A via son client Element. Comme il y a un nouveau message, ce message chiffré est envoyé puis reçu sur le client Element d’Alex via une requête sécurisée qui chiffre le message.

3. Déchiffrement

Le message reçu, toujours chiffré, est copié sur puis enfin déchiffré. Pour déchiffrer le message, il faut:

• la clé publique de la personne qui a envoyé (et chiffré) le message (Sasha). Celle-ci a été récupéré lors de la connexion au serveur.
• la clé privée de la personne qui a reçu (et veut déchiffrer) le message (Alex). Celle-ci est stockée sur son client Element, elle est accessible sans nouvelle requête. Avec cette combinaison de ces 2 clés, le message est déchiffré localement et lisible par Alex.

4. Copie du message

Une copie déchiffrée du message est finalement copiée localement (ou sur un espace cloud dédié) sur le client d’Alex.

Simplification

Le processus décrit ici est en fait très simplifié. Il y a, comme expliqué, 3 niveaux de chiffrement:

• MLS qui assure que les communications sont chiffrés
• MatrixSSL qui chiffre les messages lors de sa transmission du client au serveur, entre les serveurs et du serveur au client.
• Et enfin le protocole de chiffrement de bout en bout E2E qui est appelé protocole Olm (pour les messages entres 2 personnes) et MegaOlm (pour les messages de groupes)

En réalité, les protolcoles de chiffrement Olm et MegaOlm ne chiffrent pas les messages avec seulement 2 clés.

En fait, il y a un mécanisme de génération et de changement de clés en permanence ce qui permet de renforcer la sécurité. Le principe reste identique, le chiffrement d’un message est réalisé par la combinaison d’une clé privée et d’une clé publique (ou plusieurs pour les groupes). Cependant, une personne n’a pas qu’une seule clé privée et une seule clé publique.
Le chiffrement se fait via un systéme de clés temporaires, de clés de signature et d’identification… (privée et/ou publique), elles-mêmes générées à partir de plusieurs combinaisons de ces clés ou encore d’autres clés temporaires.

Tout ces mécanismes de génération de clés et de transmission de nouvelles clés permettent de garantir qu’une personne non autorisée qui parvient à déchiffrer un message ne puisse accéder qu’à ce seul et unique message donc ni aux anciens messages, ni aux messages suivants.

Voici quelques liens pour aller plus loin sur ces protocoles de chiffrement:
-> Elment: End-to-end encryption
-> Matrix: End-to-End Encryption implementation guide
-> Matrix spec: messaging-algorithms
-> Matrix git: Olm, A Cryptographic Ratchet
-> Matrix git: Signature keys and user identity in libolm
-> Matrix git: Megolm group ratchet
-> NccGroup: Olm Cryptographic Review

Les sessions

C’est quoi?

On pourrait définir une session comme un “espace actif de connexion” avec son serveur Synapse. Lorsque qu’il y a une déconnection, la session est terminée et il faut ouvrir une nouvelle session.
Ainsi, il y a une session par moment et par manière d’accéder au serveur. Le nombre de sessions varie en fonction de l’endroit depuis lequel on se connecte (via Element notamment).

Autrement dit:

• Une connexion depuis l’application mobile Element, une session
• une connexion depuis l’application desktop sur ordi, une autre session, même si on est aussi connecté.e depuis l’application mobile en même temps
• une connexion via l’interface web depuis Firefox, encore une autre session,
• une connexion via l’interface web depuis le navigateur Chromium, là aussi, une nouvelle session…

Il est donc possible d’avoir plusieurs sessions connectées en même temps. Cela renforce même la sécurité en permettant une double authentification. Si une session est corrompue, il est possible de le voir via ses autres sessions ouvertes.

Sauvegarde

Comme dit précédemment, dans le cas du chiffrement, Element génère une paire de clé publique et privée (plus exactement, un jeu de clé publique et privée réactualisé en permanence pour chaque salon).

En réalité, il y a un jeu de clés par session. Cela signifie qu’un message est chiffré lors d’une session et donc avec la clé privée de cette session pour ce message. Ce message n’est ni déchiffrable ni lisible par les clés d’une autre session.
Pour permettre la lecture entre ses différentes sessions, il faut donc permettre l’accès aux différentes clés entre les sessions.
Pour cela, Element propose de sauvegarder ses clés lors de sa première connexion ou avant de fermer une session.

Lorsque l’on sauvegarde ses clés, Element déploie un “coffre fort” où les différentes clés sont sauvegardées. Ce coffre est protégé par une phrase de passe ou une clé personnelle unique (en réalité la phrase de passe est utilisée pour générer une clé personnelle unique).
Pour déchiffrer les messages il suffit maintenant d’avoir accès aux clés des autres sessions ce qui est possible en accédant à son coffre fort via sa phrase de passe ou sa clé unique.

Il est également possible d’accéder à la clé de chiffrement d’un message en synchronisant sa session avec la session qui a chiffré le message. Pour cela il faut vérifier les sessions.

Vérification

Pour synchroniser les différentes sessions entre elles, il est possible de vérifier une session avec une autre session. Cette double authentification garantit que la personne derrière la session est bien la bonne personne. Cette vérification est alors notifiée sur les messages via un bouclier vert (voir le tuto pour vérifier ses sessions).

Ainsi Sacha peut vérifier depuis une de ses sessions si ses autres sessions sont corrompues. De même Sacha peut effectuer une vérification depuis sa session sur son ordi avec Alex pour être sûr.e qu’il s’agit d’Alex, et ainsi renforcer la sécurité de l’échange.

Voici un petit article dans lequel nous parlons de messageries instantanées et évidemment de logiciel libre. Nous avions déjà écrit un article en juin 2022 ou nous comparions différents services chat (Matrix, Rocket.Chat et Nextcloud Talk). Il est temps de mettre à jour nos observations et expérimentations sur ce type de service.

Au revoir Rocket.Chat

Cela fait maintenant presque 8 ans, que nous déployons et hébergeons le logiciel Rocket.Chat pour différentes organisations (10353 personnes au total sont passées par nos instances). Après ces années de bons et loyaux services nous ne proposons plus ce logiciel aujourd’hui dans notre service liiibre.

Pourquoi nous quittons Rocket.Chat?

Tout à basculé un soir d’août, ou plutôt un matin de septembre en rentrant de vacances. Dans notre boite mails nous avons reçu les informations sur la dernière mise à jour de leur logiciel Rocket.Chat (version v6). Cette nouvelle version s’accompagne d’une modification radicale dans la disponibilité des fonctionnalités. Concrètement il n’est plus possible par exemple de faire du multi-instances et donc de mettre en place un chat haute disponibilité avec plus de 100-200 utilisateurs en simultanés. D’autres fonctionnalités à la marge ne sont aussi plus disponibles dans la version communautaire (non propriétaire) comme des fonctionnalités pour le live chat, l’application mobile…
Avec ces derniers développements de Rocket.Chat et le modèle économique qui a été choisi par l’entreprise, la dépréciation des fonctionnalités disponibles, et leur mise sous modèle open-core (c’est-à-dire propriétaire), les valeurs soutenus par Rocket.Chat ne sont plus en accord avec les nôtres. Nous ne pouvons donc plus maintenir l’usage de ce logiciel.

Une migration des outils de chat est donc inévitable. Cette migration était envisagée depuis plusieurs mois, mais nous ne savions pas que RocketChat allait changer si brusquement son calendrier. Ce qui a bouleversé le nôtre (et celui de nos organisations contributrices) par la même occasion. Mais vers où aller?

Bref aparté sur Mattermost

Mattermost est en effet un service de messagerie instantanée et donc une alternative à Rocket.Chat, avec globalement le même type d’usage. Cependant, Mattermost se rapproche aussi de Rocket.Chat sur un autre point moins souhaitable, il s’agit du même modèle économique open-core. C’est-à-dire que certaines fonctionnalités sont libres dans la version communautaire, mais d’autres restent propriétaires. Par exemple, il n’y a pas de SSO (service d’authentification de session et d’utilisateur) dans la version communautaire de Mattermost ce qui est malheureusement essentiel pour nous afin d’optimiser le déploiement et faciliter les connexions. Pour nous, l’alternative Mattermost présente donc le même risque de perte de disponibilité que Rocket.Chat. Nous ne voyons actuellement pas les garanties qui (r)assurent que les fonctionnalités restent ouvertes. Mais pas de panique, d’autres alternatives existent!

Pourquoi aller sur [Matrix] Element

Depuis quelque temps déjà, nous essayons en interne un autre logiciel de chat baptisé Element. Nous avons opté pour cette solution puisque c’est une solution open source et même libre (une évidence pour nous) et surtout car le logiciel est basé sur Matrix.

Mais qu’est-ce que Matrix?

Matrix c’est un projet qui vise à créer un protocole standardisé pour l’envoie de messages instantanés. Son objectif principal est l’inter-opérabilité.

Un exemple d’interopérabilité bien connu aujourd’hui est l’envoi de mails. Il n’est pas nécessaire de savoir si l’envoie de mail passe par google gmail, protonmail, gandi ou privianet (notre super prestataire mail:) ), pour recevoir un mail. Matrix vise à créer la même chose pour les messages instantanés; un réseau standardisé pour communiquer avec les différents services de messagerie instantanée.

Le super pouvoir de la fédération

Un autre avantage que permet le protocole Matrix, c’est la fédération. Étant un protocole, Matrix permet de construire un réseau de communication décentralisé et utilisé par plusieurs logiciels et organisations. Dans la grande majorité des services de chat, comme Rocket.Chat, Discord, Mattermost…, les messages sont centralisés sur un serveur unique, propriétaire de l’entreprise qui déploie et maintient le logiciel. A l’inverse Matrix, permet justement de communiquer entre plusieurs serveurs fédérés. Ainsi chaque communauté peut choisir la configuration de sa propre instance (chiffrement des messages, modération, sauvegardes des messages…) et continuer de communiquer avec d’autres communautés. Cette fonctionnalité nous semble importante dans nos écosystèmes où la collaboration entre collectifs est importante. La fédération permet de maintenir son indépendance (propriétaire de son serveur) tout en étant interdépendant avec son écosystème (plusieurs serveurs fédérés).

Sortir d’une vision centrée logiciel

Ces deux fonctionnalités, l’inter-opérabilité et la fédération, permettent aussi de repenser un peu l’usage de nos outils, ici la messagerie instantanée. De la même manière qu’aujourd’hui nous voyons les emails comme un usage d’envoie de lettres électroniques, Matrix vise à faciliter de manière plus général l’usage qu’est l’envoie de messages instantanés. Le logiciel d’envoie n’est alors qu’un outil ou une option à choisir en fonction de ces préférences; une interface pour faciliter un usage et non un logiciel à apprendre, imposé par son organisation. De la même manière, pas besoin de séparer ses comptes en fonction de la communauté à laquelle on adresse le message, un seul compte permet de dialoguer sur les différents chats.

Et Element dans tout ça

Vous l’aurez compris, Element utilise le protocole Matrix et par extension, permet les différentes fonctionnalités expliquées plus haut. Element est en fait le principal logiciel qui utilise Matrix. C’est-à-dire le plus stable, mature et utilisé. Récemment une version Element X est sortie permettant entre autres d’optimiser et d’accélérer le chargement et l’envoie de message.

Un autre avantage que nous voyons dans Element, c’est le chiffrement. Contrairement à Rocket.Chat, Element permet la sécurisation des messages par le chiffrement de bout en bout. Element offre en effet la possibilité de sécuriser ses messages avec une authentification par double clés (publiques et privées). Sans entrer dans les détails techniques (qui donneront peut-être lieu à un deuxième article), cela signifie que les messages échangés sur Element sont (très) difficilement accessibles à un tiers personnes non désirées. De plus, même en cas d’un piratage ou d’une corruption qui permettrait d’accéder à un message, cela ne serait valable que pour ce message déchiffré. Même si le chiffrement peut sembler complexe à première vue et qu’il peut être désactivé, il nous semble important, dans nos contextes actuels de se sensibiliser collectivement le plus tôt possible à ces enjeux de sécurisation de nos moyens de communication.

LA solution parfaite n’existe pas (encore?)

Pour être tout à fait honnêtes et transparent.es, il nous semble important de signaler que Matrix comme Element ne sont pas des solutions parfaites.

D’abord, concernant la sécurité, même si Element permet le chiffrement, cela n’est pas forcément une garantie permanente. En effet, puisqu’Elément permet aussi la fédération avec d’autres instances, les configurations de sécurité peuvent changer. De manières générales, la fédération avec d’autres serveurs inconnus amoindri forcément la sécurité des communications. Il est donc nécessaire de connaître les règles et configurations avant de se fédérer à un serveur, encore plus lorsqu’il est accessible publiquement.

Concernant l’entreprise Element (anciennement New Vector), il serait faux de dire que qu’Element est à l’abri de toute dynamique propriétaire ou open Core qui nous pousse à ne pas choisir Mattermost et à quitter Rocket.Chat.

L’organisation Element a d’ailleurs récupéré les dépôts de code de leurs implémentations et a aussi ajouté l’obligation de signer un contrat d’engagement pour les contributions à leur code libre (CLA). De plus, actuellement, Element est le principal financeur de Matrix ce qui peut entraîner un position de monopole ou de pouvoir sur ce protocole de réseau décentralisé.

Néanmoins,

Le protocole Matrix sur lequel se base Element a pour vocation à être standardisé par IETF (organisation oeuvrant pour la standardisation des proces sur Internet) ce qui implique donc d’être utilisé, documenté et accessible très largement. Ainsi, même dans l’hypothèse de privatisation d’Element, il nous semble plus facile de repartir du protocole Matrix que de repartir de zéro. Il y a par ailleurs déjà aujourd’hui d’autres logiciels qui utilisent le protocole Matrix comme FluffyChat par exemple (> voir la liste complète). De la même façon côté serveur plusieurs options sont possibles (Synapse pour le plus connu, mais il existe aussi Conduit, Dendrite…)

Et enfin, de grandes institutions et acteur.ices privés et publiques se mettent à utiliser Matrix. C’est notamment le cas de l’Administration publique qui a sorti Tchap son service de messagerie instantanée pour les plus de 400 000 agents public, qui utilise … Matrix.

Gouvernance & Matrix

Pour clôturer cet article, il nous semble important de parler brièvement de la gouvernance de Matrix. Le projet Matrix est maintenu par la fondation Matrix.org. Cette fondation anglaise a été lancée en 2018 et est garante de la gouvernance ouverte du projet Matrix. Cette dernière est financée par les contribueteur.es et donateur.ices, comme Elment notamment. A IndieHosters, nous avons aussi fait le choix de soutenir et de rejoindre la fondation Matrix en tant que silver member. (nous attendons leur réponse). Dans tous les cas, nous rejoignons le projet Matrix, en privilégiant une messagerie basée sur Element à présent dans notre offre Liiibre.

Quand IndieHosters rencontre OpenSourcePolitics

Aujourd’hui, nous revenons vers vous avec un article un peu spécial. Depuis quelques mois déjà, nous travaillons sur un projet d’une assez grande envergure et qui nous sort de nos habitudes. D’ordinaire, on vous parle de Liiibre, notre outil se basant sur Nextcloud. Toutefois IndieHosters ne se résume pas à Liiibre, nous avons d’autres cordes à notre arc ou plutôt d’autres projets dans nots cartons. Libre.sh est l’un d’entre eux. Mais comme pour toute envie et/ou tout projet, les ressources en temps, en moyens et en humains peuvent être des facteurs assez limitants. Et quand on est limité, on n’avance pas aussi vite qu’on le voudrait… C’est exactement ce qui s’est passé pour ce projet resté un peu trop longtemps en attente.

C’est à ce moment qu’entre en scène Open Source Politics, et le fait que nous décidions de travailler ensemble. C’est pourquoi nous nous réjouissons tellement de ce partenariat. Dans cet article, nous allons donc vous parler de cette coopération et de notre histoire commune, du projet qui nous relie et sur lequel nous travaillons. Parce qu’on aime documenter, et que le partage des pratiques de travail, ça fait aussi partie des communs, nous allons aussi parler de notre façon de travailler ensemble.

Open Source Politics et IndieHosters un crush professionnel dans le milieu du Liiibre

Ce titre est peut être un peu trop romantique… Mais en même temps… Une rencontre autour de valeurs communes, l’envie de travailler ensemble, mettre en action cette envie, un peu, beaucoup… Et enfin saisir l’opportunité de nouer une relation professionnelle nourrie et dans le dialogue sur le long terme…

Afin de vous parler de ce partenariat, nous avons décidé d’écrire des articles croisés avec OSP. Cet article est sur notre blog, et nous le rédigeons, alors on a trouvé ça intéressant que ce soit Valentin Chaput, cofondateur d’OSP, qui nous raconte leur vision de notre histoire.

Est ce que tu pourrais nous présenter OSP?

Open Source Politics est une équipe de près de 30 personnes qui met en œuvre des outils numériques éthiques pour accompagner des démarches participatives qui ont du sens. Depuis sept ans, nous avons accompagné plus de 170 clients, très majoritairement des acteurs publics de la petite commune aux institutions européennes, autour de deux champs de compétences indissociables: une palette de services techniques et un accompagnement méthodologique permettant de mener une démarche de démocratie numérique de bout en bout. Nous travaillons principalement autour du logiciel libre Decidim, au développement duquel nous contribuons depuis plusieurs années.

Et Decidim?

Decidim est un logiciel libre initié par la Mairie de Barcelone en 2016. C’est une boîte à outils modulaire permettant depuis un même portail de créer des espaces de concertation, de délibération, de collecte de pétitions en mobilisant une dizaine de fonctionnalités participatives (questionnaire, propositions libres, votes…). Utilisé par plus de 500 organisations dans le monde entier, Decidim est un logiciel de référence dans son domaine autant qu’un modèle de commun numérique: une communauté d’acteurs publics et privés se rassemblent autour de l’association Decidim et de la plateforme meta.decidim.org pour contribuer à la gouvernance, la feuille de route et le financement du logiciel.

Comment ça a commencé l’histoire avec IndieHosters?

Nous connaissons IndieHosters depuis l’été 2019, grâce à des contacts communs. Nos premiers échanges visaient à mettre en place des outils de documentation pour l’événement Numérique en commun[s]. Pierre et Tim ont ensuite formé notre équipe technique sur les avantages de Kubernetes. Un pilote a été réalisé à l’été 2022 avec la migration réussie de l’instance de pétitions du Sénat, qui est la plateforme Decidim avec le plus d’utilisateurs dans le monde. Cette nouvelle infrastructure s’est adaptée à des pics de charge par nature imprévisibles. Suite à ce succès, nous avons décidé d’aller plus loin pour améliorer la performance de nos services, et commencer à en imaginer de nouveaux ensemble.

Qu’est ce que cette collaboration apporte à OSP?

Tout d’abord des compétences techniques que nous n’avions pas et qui auraient été difficiles à trouver et former. Cela se traduit très concrètement en matière de qualité de service pour nos clients. Au-delà de cette première motivation qui était déjà suffisante, nous avons pu au cours des derniers mois réfléchir ensemble à un horizon de mise à disposition d’une suite d’outils libres permettant notamment aux institutions publiques et aux associations de sortir de la dépendance aux GAFAM et aux prestataires propriétaires. Decidim vient ajouter une brique démocratique aux Nextcloud, OnlyOffice, Rocket Chat et Jitsi déjà déployés par IndieHosters. D’autres outils suivront, avec l’accompagnement mutualisé de nos deux structures.

Et ce partenariat il consiste en quoi exactement?

Voici la version illustrée

Pour celleux qui voudraient aller un peu plus loin, et que les «gros mots» de la tech ne mettent pas en PLS la suite est faites pour vous. Et pour celleux qui sont curieux de savoir comment un projet de cette envergure s’organise et se met en place, rendez-vous en 3eme partie d’article.

Il était une fois une plateforme nommée libre.sh

Libre.sh qu’est ce que c’est? C’est un projet un peu fou. Le projets de 3 administrateurs système, de créer une plateforme libre et open source, qui permet d’économiser des ressources en terme de capacité de serveurs, tout en permettant une mise à disposition en haute disponibilités des API qui seraient hébergées dessus.

Cette plateforme se base sur Kubernetes. Un système qui permet l’automatisation et le déploiement à grande échelle d’application containeurisées.

A ce moment-là de la lecture, celleux qui sont calés en technique ont compris. Mais pour les autres, voici une explication un peu plus vulgarisée en prenant l’exemple de Decidim et d’OSP.

Illustration grâce au partenariat avec OSP

Il y a des organisations qui souhaitent utiliser Decidim. Pour simplifier, nous dirons que chaque organisation a sa propre instance Decidim. Et il y a OSP qui déploie et maintient ces instances et qui les héberge sur un serveur. Maintenir et déployer des instances est un travail en soi (faire les mises à jour, corriger des bugs, entre autres…)

Mais dans cette équation se cache une autre dimension dont on n’a pas forcément conscience: un autre niveau de technologie, qui concerne la gestion de ces instances vis à vis du serveur. Cette autre dimension est un métier à part entière et c’est là qu’entre en jeu IndieHosters avec Libre.sh.

Un serveur est une machine physique avec des capacités et des ressources. Suivant les capacités des serveurs et des besoins, il peut falloir en regrouper plusieurs, ou bien en diviser. Il va ensuite falloir faire communiquer et travailler tout ce petit monde ensemble. Faire en sorte par exemple, que s’il y a des pics d’activités au niveau des applications (dans notre cas une instance Decidim), et qu’un serveur «lâche», un autre puisse prendre le relai immédiatement sans aucun impact ni que ce soit visible pour l’utilisateur.ice final.e (c’est à dire le citoyen qui aura décidé de signer une pétition contre la chasse des blaireaux par exemple #truestory). (Cette histoire serait un peu trop longue à raconter dans cet article, mais un jour si vous le voulez, on vous la racontera).

En résumé, il va falloir mobiliser et optimiser les ressources du ou des serveurs en fonction des spécificités des applications et de leur utilisation, afin d’en tirer la meilleure performance pour que ce soit complètement invisible pour l’utilisateur·ice final.e et qu’il se dise «Tient ça marche bien! » Et c’est Libre.sh qui permet cette bonne communication et cette optimisation des ressources.

Chaque instance de Decidim est mise dans une boîte (un containeur linux), et les containeurs sont rangés sur la plateforme libre.sh. La plateforme gère les containeurs, leurs dispositions, les ressources qui leur sont alloués selon leurs besoins, leur mise en disponibilité ou en indisponibilité, leur duplication en cas de sauvegarde etc. Elle ne gère pas ce qui se passe dans le containeur, toutefois, la façon dont ils sont rangés a également une répercussion sur ce qui se passe dedans.

Précisons bien évidemment, qu’il ne suffit pas simplement de «coder» la plateforme et puis ça roule tout seul. Il faut ensuite vérifier que les adaptations dans ce contexte précis sont optimales, maintenir la chose, contrôler, améliorer, et réagir en cas de défaillance technique pour remettre le tout en disponibilité. Même si c’est de l’informatique, cela repose sur des machines physiques, et même le plus parfait des codes peut avoir des failles. Tout cet équilibre est donc solide, mais doit tout de même être résilient.

Pour celleux qui voudraient aller un peu plus loin dans leur compréhension

Les éditeurs de logiciel (comme OSP) savent produire des conteneurs docker et les configurer, mais pas forcément comment les déployer sur des serveurs, ainsi que leurs dépendances.

K8s (Kubernetes) sait très bien déployer des conteneurs sur plusieurs machines, les connecter, les garder disponibles (en haute disponibilité), partager les ressources (cpu/ram), les mettre à l’échelle en cas de pic d’activité… mais il est relativement compliqué à configurer.

Ainsi pour déployer une instance, il faut une personne (un opérateur) qui connaisse à la fois l’application, ses dépendances (base de données, etc) et k8s.

Ensuite, il faut faire des sauvegardes et donc des fois restaurer, et des mises à jour et donc suivre les changements dans l’application pour adapter la configuration dans k8s. Une personne peut gérer manuellement quelques instances, mais ni à grande échelle ou avec une grande diversité d’applications.

C’est là que libre.sh entre en jeu et nous aide. Il va abstraire la complexité de k8s et la connaissance de l’application en une interface simple (API). Et ensuite permettre une gestion à grande échelle en standardisant le déploiement des dépendances, la manière de sauvegarder et restaurer, et en mettant à jour automatiquement. L’objectif est de minimiser les connaissances requises pour déployer une instance et limiter les opérations manuelles en mutualisant nos connaissances des applications et de Kubernetes dans des opérateurs logiciels (et non humain).

J’en profite pour dire merci à Hugo pour la rédaction de ce paragraphe et ce travail de co-création.

Mise en place d’un projet de grande envergure

La migration d’autant d’instances et la mise en place d’une telle infrastructure, est un projet qui mobilise de nombreuses personnes et demande des compétences pluridisciplinaires.

Nous nous abstiendrons ici d’évoquer la mise en place du travail sous Git, qu’il s’agisse de code ou de management de projet, qui sont largement connus et documentés (Si vous voulez qu’on vous parle de comment on procède chez nous, dites le nous, ça pourrait faire un chouette article).

Ce travail a également nécessité une concertation sur le plan juridique, et sur le plan de la communication.

Très rapidement nous avons convenu la mise en place d’un point bimensuel (tous les 15 jours pour celleux qui ont toujours un doute) d’1h, avec dispatching de tâches à accomplir et de livrables pour le point suivant. Durant chacun de ces points, les thématiques sont abordées selon leur degré d’importance. Les points plus techniques sur les décisions d’architectures faisant l’objet de points de synchronisation entre les équipes à part. Ce rythme a vocation à perdurer jusque dans les premiers mois de mise en place définitive, puis de basculer sur un point mensuel, qui sera l’occasion de faire le point sur les process mis en place au niveau de la tech, les retours clients et les réponses aux incidents.

Sur le plan juridique et réglementaire

Sur le plan juridique, il y a la phase d’avant-contrat, où il a fallut déterminer en amont du projet: les contours techniques, et ce mêmes s’ils n’étaient pas complètement fixés, l’estimation de la charge de travail de la prestation, les conditions de la prestation… Pour cela, plusieurs réunions précisant les différents points à aborder et négocier. C’est peut-être l’une des phases les plus critiques, car c’est d’elle que découle tout le reste.

Puis vient la phase de rédaction du contrat. Quel outil pour ce travail? Nous sommes IndieHosters, nous avons donc utiliser OnlyOffice. La possibilité de faire des commentaires et d’écrire à plusieurs mains en simultané (ou non), lors de réunions est un avantage indubitable.

Et enfin, qui dit traitement informatique de données, dit également RGPD et obligations réglementaires. Établir les responsabilités et les rôles de chacun. Les process à mettre en place pour qu’ils soient conformes avec la norme.

Dans un deuxième temps, pour OSP, c’est la mise à jour des documents contractuels avec leurs clients qu’il a fallu reprendre, vérifier avec IndieHosters ce qui avait un impact sur ses documents ou non, et procéder à leur modification si besoin sous la forme d’avenant.

Sur le plan de la communication

Il a fallut en parallèle travailler sur la communication, qu’elle soit en interne, auprès des équipes de chacun, auprès de leurs clients pour OSP, et aussi vers l’extérieur pour annoncer cette coopération.

Pour cette partie, établir les besoins et les personnes destinataires des différentes communications.

En support à cette communication, un travail d’identité visuelle a été demandé à Thibault Daumain. Et pour rendre intelligible l’objet de la collaboration, un travail de facilitation graphique à été demandé à Yoann Le Chevalier.

Enfin un plan de communication a été établi, afin de préparer le terrain de l’annonce de la nouvelle depuis le mois de décembre. Se basant sur:

• des communications au sein d’infolettres
• de courriels explicatifs pour les personnes concernées par la mise en place de cette nouvelle infrastructure
• d’informations sur les réseaux sociaux, sur des articles de blog (comme cet article ou celui d’OSP), ou de communiqué de presse
• et l’organisation d’un webinaire pour répondre aux questions des utilisateur.ice.s

Si vous avez des suggestions de ce côté, n’hésitez pas à les partager en commentaire.

Illustration de l’article: Thibault Daumain

Ah l’automne… Ses couleurs orangées, ses couchés de soleil et ses feuilles qui tombent avec panache. Et biensûr… ses mises à jour!

On passe à Nextcloud 23

Un profil dans votre nuage

Votre nuage est utilisé par de nombreuses personnes? Avec les profils, vous allez pouvoir maintenant renseigner des informations à propos de vous et ainsi permettre aux autres personnes de votre équipe de mieux vous connaître voire leur indiquer les différentes manière de vous contacter si besoin.

Pour régler votre profil, cela se passe dans le menu Paramètres de votre compte sur le nuage.

Evidemment cette fonctionnalité a été pensée dans le respect de la vie privée et vous avez pleinement la main sur la visibilité de chaque information constituant votre profil et vous pouvez même le désactiver.

 Cette nouveauté est activé par défaut. Si vous êtes admin d’une instance dédiée de Liiibre, vous pouvez la désactiver si besoin dans les Paramètres du nuage puis, dans la section Administration, aller dans Paramètres de base.¹

Partager l’accès à certaines sections de l’administration du nuage

Nouveauté utile pour les administrateur·ice d’instance dédiée: il est maintenant possible de donner l’accès à certaines sections des paramètres d’administration de votre nuage.

Cela peut être utile si par exemple vous souhaitez permettre à un·e membre de votre structure de personnaliser l’apparence du nuage sans pour autant lui donner accès à toutes les autres options d’administration.

Ça se passe dans les Paramètres de votre nuage puis section Administration et aller sur Privilège d’administration.

Note: les droits s’allouent par groupe et non pas par utilisateur·ice. Donc vous aurez éventuellement besoin de créer un groupe. (cf. centre de documentation si besoin)

Deck passe en stable

Deck a fait son apparition sur le nuage depuis plus d’un an maintenant. Cette application permet de gérer des projets dans une interface présentant des tableaux façon kanban, un usage rendu célèbre par Trello.

Nous l’utilisons maintenant depuis un an en interne au sein de l’association. Elle répond globalement à tous nos besoins et sa stabilité n’est plus à prouver depuis ces dernières mises à jour qui ont fixé pas mal de bugs. Nous la passons donc en dans notre page Apps et vous encourageons à en profiter pleinement. 🙌

Quelques autres évolutions

Du côté de la suite bureautique

Mode sombre!

La nouvelle mise à jour introduit un mode sombre pour vous permettre de travailler plus au calme sans vous éblouir.

Arrêt du support de l’édition sur mobile

C’est une nouvelle moins enthousiasmante, la version “community” (sous licence libre) de OnlyOffice² ne propose plus le support de l’édition de vos documents sur mobile.

 À noter cependant que c’est l’édition collaborative depuis votre navigateur mobile qui n’est plus disponible. Si vous souhaitez simplement éditer un document de votre nuage depuis votre mobile, rien ne vous empêche d’utiliser l’application mobile Nextcloud (cf notre centre de documentation) pour récupérer le document et de l’éditer ensuite avec l’application OnlyOffice.

Si vous êtes administrateur·ice d’une instance Liiibre dédiée et que vous souhaitez néanmoins permettre l’édition mobile à votre organisation, discutons-en.

Du côté de l’app Mail

 Pour rappel, IndieHosters ne fournit pas de compte email pour le moment mais il est par contre possible d’activer un client mail dans votre nuage pour les y retrouver et les gérer au même endroit que le reste.

Création d’événement depuis un message

Petite nouveauté, il est maintenant possible de créer un événement sans bouger de l’application, directement à partir du menu d’actions d’un message. Pratique lorsqu’on veut se noter un rdv ou un rappel par exemple.

Visioconférence toujours plus stable

Pas de fonctionnalité majeure à annoncer de ce côté un bon nombre de bugs fixés et un hébergement toujours plus optimisé.

That’s all folks!

Et voilà pour ces mises à jour et leur cortège de nouveautés! Et pour suivre au plus près les prochaines phases de mise à jour, ça se passe dans la section Maintenance de notre forum.

Au plaisir de lire vos commentaires et remarques.

Et prenez soin de vous! 🤗🌺

1. Attention, cela prendra effet pour les nouveaux comptes mais pas les anciens présents avant la désactivation. Si besoin de désactiver les profils pour tous les comptes, il est nécessaire de nous contacter. (Merci tcit pour l’info!) ↩

2. OnlyOffice est la suite bureautique intégrée dans Liiibre qui vous permet d’éditer vos documents, tableaux, présentations. ↩

C’était il y a deux ans… IndieHosters dévoilait Liiibre et son tout nouveau mode de fonctionnement.¹ Nourrie par l’énergie particulière du confinement, une nouvelle étape s’enclenchait². Depuis, le collectif a beaucoup évolué, un peu plus de 80 organisations utilisent Liiibre au quotidien, et nous avons énormément appris. Profitons de ce moment spécial pour jeter un œil dans le rétroviseur et vous raconter vers où l’aventure se dirige.

Structuration et gouvernance

D’où on vient

La première étape décisive fut de structurer le collectif en association, puis d’écrire son statut et son code social³. Ceci s’accompagnant de la constitution du collège responsable de la structure.

Rétrospectivement, il est clair que ce code social a constitué une sorte de boussole qui nous a fortement aidé à nous diriger ensemble. Et même si c’est un écrit qui a vocation à évoluer, notre fonctionnement actuel dans les faits s’y retrouve en bonne partie, deux ans plus tard.

Une petite victoire dont nous sommes fier·es, car pouvoir grandir sans rompre avec ses idées et valeurs originelles n’est pas toujours aisé dés lors qu’un projet est lancé dans le grand bain de la société contemporaine. Cela demande une réflexivité permanente et une exigence collective, c’est aussi ce qui fait le sel de notre activité et qui participe à lui donner du sens, pour nous comme pour vous. Et sans vous, sans votre confiance et votre désir d’ouvrir la voie à une autre manière de faire du numérique, en commun et respectueux de ses usager·es, ce ne serait pas non plus possible. Alors un premier⁴ merci!

Où on va

Le statut d’association commence à montrer ses limites. À ce jour, chacun·e de nous au sein du collectif œuvre selon des modalités variées⁵ qui pourraient gagner à être revues vers un statut plus sécurisant et stable. Par ailleurs, nous aimerions permettre aux organisations qui contribuent à IndieHosters d’avoir plus de champs d’action dans leur manière de contribuer aux ressources en commun qui nous lient ensemble.

Nous étudions en ce sens d’autre modèles de structures, telles que les SCIC, SCOP, SAPO… C’est encore balbutiant et il y a pas mal de discussions et de travail devant nous pour y parvenir mais nous sommes convaincu·es qu’une telle mutation est à anticiper pour continuer de grandir tout en parvenant à honorer les engagements que nous avons pris dans notre code social.

Pour nous aider notamment en ce sens, nous avons eu la chance de pouvoir constituer ces derniers mois notre Conseil des Communs constitué de Yaël Benayoun, Sébastien Broca, Bernard Brunet, Aurèle Cordier, Sylvia Friederikson et Alain Mille, chacun·e provenant d’horizons riches de sens et partageant un regard aiguisé et nourri sur la question des communs. Une à deux fois par an, nous prendrons ensemble un temps de réflexion pour nous assurer que le collectif reste fidèle à ses engagements et imaginer ensemble comment aller plus loin encore. La première édition a eu lieu à Lyon chez nos ami·es de La Myne le 2 septembre dernier.

Un collectif plus vivant que jamais

D’où on vient

Du duo Pierre et Timothée, IndieHosters a accueilli entre temps de nouvelles forces vives. Vous pouvez maintenant compter sur un pôle technique de trois personnes à temps plein (Pierre, Tim et Hugo) et un pôle accueil, accompagnement et formation de quatre personnes oscillant entre quart-temps, mi-temps et temps plein (Anne-Sophie, Paul, Maroin et Maxime). Nous sommes également aidés de Cécile qui nous aide à la facilitation de nos prises de décisions collectives et la tenue de nos Indie Camp⁶. Il y a aussi Patricia qui nous assiste sur la partie administrative. Sans oublier les contributions occasionnelles de Thibault côté illustration, David côté RGPD, et enfin Eric, Benoit et David côté calcul empreinte carbone.⁷

Où on va

Vous le savez, nous ne cherchons pas à grossir indéfiniment. Nous aimons l’idée selon laquelle il faut savoir rester petit pour que chacun·e au sein du collectif garde une prise directe avec chaque décision et pour favoriser une diversité de CHATONS sur le territoire plutôt qu’une entité centralisatrice.

Notre première volonté est donc que chacun·e au sein du collectif puisse contribuer autant qu’il ou elle l’estime nécessaire pour la bonne tenue du commun, ceci étant porté notamment par un travail de prospection qui vise à faire bénéficier de Liiibre à plus de monde et élargir le cercle des organisations contributrices.

Le collectif est également ouvert à des contributions ponctuelles sur des projets bien définis comme vous pouvez le retrouver dans la section Nous Rejoindre de notre site.

Côté Liiibre

D’où on vient

Liiibre est né de l’idée qu’il ne suffit pas d’héberger des outils pour les rendre accessibles aux organisations. Nous avons senti le besoin d’un agencement apte à produire une cohérence globale qui invite à faire le pas de côté nécessaire pour sortir des GAFAM et se lancer dans le monde libre. D’où l’idée de concevoir une expérience qui rassemble des outils variés tels que Nextcloud, OnlyOffice, Rocketchat, Jitsi Meet, Discourse, Hedgedoc… et y donne accès via un compte unique.

Avec le recul de ces deux années, on peut voir Liiibre comme le fruit d’une veille continue, d’une écoute des besoins, remarques et difficultés rencontrées par nos organisations, de design et développements en interne mais également d’une participation aux différentes communautés de développement de chaque outil pour tenter de faire entendre au mieux votre voix. En chiffres, ça donne environ 4800 tickets résolus sur notre support email, et un peu plus de 5000 contributions⁸ sur les forges du collectif, de Libre.sh et des outils intégrés dans Liiibre.

Où on va

Il y a tant à faire! Notre petite équipe étant avant tout sollicitée par des problématiques d’hébergement plus que de développement, nous devons faire des choix ciblés et restreints.

Outre le suivi et l’installation des mises à jour des outils qui composent Liiibre⁹, on peut compter plusieurs voies d’exploration en passe de se concrétiser prochainement.

Côté messagerie instantanée nous avons initié en interne une phase de test de Element. Cet outil de communication est basé sur le protocole Matrix connu pour être robuste, sécurisé et taillé pour la décentralisation. Nos tests sont globalement concluants et nous allons prochainement lancer une phase beta avec quelques organisations partantes. À l’issue de cette phase, nous espérons pouvoir proposer à toutes les structures le désirant d’avoir le choix entre Rocketchat ou Element.¹⁰

Côté bureautique, nous avons développé une solution permettant de faire cohabiter OnlyOffice et Collabora sur un même nuage. Ceci pour les organisations qui éditent de nombreux fichiers à la fois odt, ods, odp et docx, xlsx, ppts et qui souhaitent bénéficier du meilleur outil d’édition pour chaque type de document.

Enfin côté communautés, nous l’avions déjà évoqué dans notre point d’étape suite au Indie Camp #2, nous sommes ouverts à nous lancer dans une phase beta avec des structures qui souhaiteraient mettre à disposition une instance Mobilizon auprès de leur membres pour facilité la création et la gestion d’événements.

Côté accompagnement et formation

D’où on vient

Au cœur de la démarche IndieHosters depuis ces deux années, nous prenons soin de fournir un accompagnement permettant à toute organisation, quel que soit le “niveau” en informatique de ses membres, de profiter pleinement de Liiibre. Concrètement, ça représente près de 500 rendez-vous d’accompagnement effectués par le collectif (!) À cela s’ajoute une bonne vingtaine de sessions de formations à distance/présentiel, les ateliers Indie Kafé et de nombreuses fiches dans notre centre de documentation…

Où on va

Paul repart pour une nouvelle saison Indie Kafé tout prochainement, et un centre de documentation flambant neuf est en préparation. Avec Anne-Sophie qui nous a rejoint cette année, les rangs de la parcelle¹¹ accompagnement s’agrandissent et nous sommes prêt·es à accueillir plus de demandes et gérer des projets d’envergure plus importante encore.

Notre souhait pour la suite serait de mettre en place des conditions aptes à favoriser l’émergence de liens entre les organisations utilisant Liiibre au quotidien. Ceci dans l’espoir de favoriser la création de ressources de documentation au sein même de cette communauté étendue. En ce sens, nous prévoyons une refonte de notre forum et sa meilleure mise en avant directement au sein de nos outils.

Nous prévoyons également de revoir le parcours de support pour vous permettre de gagner en autonomie et vous faire découvrir notamment comment déposer un ticket de bug directement auprès des contributeur·ice·s des outils intégrés à Liiibre.

Côté techniques et Libre.sh

D’où on vient

Si on vous dit qu’on a migré notre infrastructure de ceph vers minio, qu’on a ajouté un serveur de backup à Helsinki, qu’on a migré vers Kubespray puis k0s, qu’on s’est retrouvé sur le podium des hackatons de Jitsi Meet pour notre opérateur k8s et Nextcloud pour notre prototype de module SCIM ou encore qu’on a mis en place des tableaux de bord avec prom/grafana/loki… Ça vous parle? On ne va pas rentrer dans les détails dans cet article mais en gros: on continue notre progression vers toujours plus de stabilité, de sécurité et d’automatisation.

Ceci dit, on peut comprendre que certain·es parmi vous puissent avoir envie de rentrer dans les détails pour mieux comprendre les rouages de la machine et on adorerait prendre ce temps avec vous. On vous propose de remplir ce formulaire et si vous êtes assez nombreux·ses, on organisera un stream de 2h en mode questions/réponses spécialement dédié au sujet de la tech chez IndieHosters.

Et le grand changement au sein du collectif qui nous a permis d’accélérer fortement côté technique? C’est bien sûr la venue de Hugo! Arrivé en 2021 pour son stage de fin d’année, il est finalement resté:)

Où on va

Depuis quelques mois, le projet de développement qui nous occupe et que nous espérons finaliser prochainement devrait faciliter la vie des admins d’instance Liiibre.

Son objectif: synchroniser en temps réel les informations des comptes entre les applis et le gestionnaire d’authentification. Ceci se ferait à travers l’implémentation du protocole SCIM.¹² Nous avons pu avancer sur un premier prototype reliant Keycloak et Nextcloud à l’occasion de leur dernier hackaton et nous cherchons maintenant les ressources pour finaliser ce projet et l’étendre à Rocketchat. Une demande de fonds à été déposée en ce sens auprès de l’initiative NGI. On croise les doigts!

Et tout ça, c’est grâce à vous!

Oui, grâce à vos contributions! Ce n’est pas une exagération que de le dire. Nous n’avons aucune autre source de financement que celle provenant des organisations qui bénéficient de Liiibre. Et sans la liberté que vous nous offrez de pouvoir nous consacrer à créer, maintenir et faire évoluer les ressources communes qui émergent de IndieHosters, nous serions bien obligés de trouver d’autres moyens de subsistance et rien de tout cela n’existerait.

Alors oui, nous aimerions aller plus loin et (un peu) plus vite encore pour réaliser ces projets que nous évoquions plus haut… et d’autres encore, ensemble! Nous sommes en bonne voie mais ce serait encore mieux de parvenir à doubler le nombre d’organisations qui bénéficient de Liiibre d’ici l’année à venir.

Pourquoi? Eh bien déjà, ça ferait plus de monde libéré des GAFAM! Par ailleurs, avec une plus grand diversité d’organisations, nous augmentons la résilience du commun et donc sa pérennité. Nous pourrons aussi reverser de l’argent ou du temps de développement aux outils libres intégrés dans Liiibre et l’ensemble du collectif actuel pourrait passer à temps plein.

Ce serait nourrir la preuve qu’il est possible de faire autrement dans le milieu du numérique. Pour montrer ensemble qu’il est possible d’agir en commun en faveur d’outils émancipateurs qui respectent leurs usager·ères et protègent leur vie privée.

Pour montrer aussi qu’il est possible d’inventer et faire évoluer des outils suivant une écoute attentive et des échanges conviviaux entre humains. Sans vous pister donc, ni faire analyser des montagnes de meta-données par des processus coûteux en énergie et à l’empreinte écologique considérable, mais en prenant soin des liens que nous tissons ensemble.

Et pour atteindre cet objectif, nous allons lancer une grande campagne de marketing cross-platform 360° sur Facebook, Instagram, Snap et TikTok portée par des influenceurs de premier plan…

… Ou pas, rassurez-vous! C’est grâce à vous que nous allons y arriver!

Cette histoire, on l’écrit ensemble. Alors, à toutes celles et ceux autour de vous qui sont prêt·es à faire un pas de côté vers des outils numériques plus éthiques et responsables, parlez-leur d’IndieHosters et montrez-leur Liiibre. On compte sur vous!

Et vous pouvez compter sur nous pour les accueillir avec enthousiasme et détermination!

1. cf ce tout premier article sur notre blog pour la séquence émotion. ↩

2. Et si l’on remonte aux origines de IndieHosters, nos premiers pas datent d’octobre 2014 (!) ↩

3. Chose qui n’aurait pas été possible sans la précieuse aide de Maïa Dereva. ↩

4. “Premier”, car il va y en avoir quelques uns;) ↩

5. Auto-entrepreneur, indépendant en eurl, salarié de CAE… ↩

6. Nous nous retrouvons 1 à 2 fois par an en présentiel durant une semaine pour faire le point et préparer la suite. Nos compte-rendus sont disponibles sur notre blog. ↩

7. Nous l’évoquions dans ce précédent article, nous sommes en train d’œuvrer à une première estimation de l’empreinte carbone d’un de nos outils. Nous vous en parlerons tout prochainement. ↩

8. Tickets, pull request et commits ↩

9. Un article arrive prochainement à ce propos d’ailleurs, suite à de nombreuses mises à jour appliquées cet été. ↩

10. Et si vous vous posez la question de Nextcloud Talk, nous avons écrit un article à ce propos. ↩

11. En référence à notre jardin. ↩

12. SCIM? Kezako? Ça peut peut paraître un peu obscur comme ça mais promis, on vous en parlera plus en détail dans un prochain article:) Et si vous ne souhaitez pas attendre et ne craignez pas le jargon tech, c’est par là. ↩

Dans cet article, nous allons parler logiciels libres et plus précisement messageries instantanées. De plus en plus d’organisations s’y sont mises ces dernières années pour fluidifier leur communication interne et en finir avec les boucles d’emails à n’en plus finir. Avec l’accélération du travail à distance liée à la pandémie de COVID, la messagerie instantanée est devenu un outil crucial pour le bon fonctionnement de nombreuses structures. Dans le monde anglo-saxon, on dit que ces outils sont au coeur du digital workplace.¹

Il était une fois…

Loin de constituer un nouvel usage, les conversations en ligne par “chat” remontent déjà à 30 bonnes années avec le bien nommé IRC conçu en 1988². Utilisé au départ entre initié·es, le concept se popularise au grand public avec ICQ, MSN Messenger, Caramail, etc. Puis avec WhatsApp, Messenger, Telegram, Signal, toutes nos conversations rentrent désormais dans notre poche… avec leurs bons et mauvais côtés.

En parallèle, le concept s’est immiscé dans le monde professionel avec notamment l’arrivée de Slack en 2014. Porté par une adoption fulgurante dés ces premiers jours, il fait encore office de leader dans sa catégorie. Un autre bien connu et massivement adopté ces derniers temps est Teams de chez Microsoft.

Le problème avec Slack, Teams et Discord.

Slack, Teams, Discord — pour ne citer que les plus connus — sont des logiciels propriétaires proposés en mode SaaS³. Leur utilisateur·ices n’ont donc pas le contrôle sur l’outil, ni sur leurs données. Encore moins sur les entreprises qui les fournissent. Iels sont contraint·es de leur faire confiance et d’accepter les évolutions à venir du produit.

Heureusement, il existe maintenant des alternatives sous licence libre! Performantes et sécurisés, elles permettent aux organisations engagées pour un numérique plus éthique, ouvert et en commun de reprendre la main sur leur données et leur outil de communication interne sans perdre en efficacité et confort d’usage!

Rocketchat, intégré dans Liiibre

Liiibre est dotée d’une messagerie instantanée basée sur Rocketchat. Inspirée de Slack, son interface intuitive et puissante a été adoptée par des milliers d’organisations à travers le monde.

Canaux de discussion publics et privés, fils de discussions, notifications push, applis bureau et mobile, annuaire, transferts de fichiers… Rocketchat est une messagerie instantanée puissantes et bardée de nombreux paramètres qui lui permet de s’adapter entièrement aux contours de votre organisation. En tant qu’administrateur·ice, vous pouvez personnaliser son apparence, ses emails de notifications, configurer des webhooks et bien d’autres choses encore en quelques clics.⁴

Matrix, en beta interne

Nous sommes fans de Rocketchat mais ça n’empêche qu’il y a un reproche qu’on peut lui faire. Il a été principalement taillé pour être utilisé au sein d’une organisation. Là où cela représente une grande qualité dans la majorité des cas, lorsqu’il s’agit de communiquer entre différentes organisations qui chacune aurait son instance Rocketchat, c’est plus compliqué.

On parle ici de fédération: c’est à dire la capacité de pouvoir interconnecter des instances entre elles pour que leur usager·ères respectif·ves puissent interagir ensemble de manière fluide. C’est une promesse de Rocketchat depuis quelques années déjà mais cela n’a jamais encore pleinement fonctionné. Dernièrement, un regain d’espoir est permis ceci dit car Rocketchat a commencé à implémenter le protocole Matrix.

Venons-en donc à Matrix. Justement, c’est un protocole avant d’être un outil. C’est à dire qu’à l’origine de ce projet, initié en 2014 (déjà), l’idée était bien de définir un standard de la messagerie instantanée en ligne, à l’instar d’autres protocoles comme IRC ou encore XMPP.

Matrix intègre donc dès ses origines l’exigence d’une messagerie interopérable, c’est à dire qui pourrait être à même de relier et faire interagir ensemble différentes plateformes de messagerie instantanée. Dotée d’une fondation dont l’objectif est de garantir l’ouverture du protocole, de financements conséquents et ayant réussit à convaincre de grands groupes ou même des administrations telle que l’État français avec Tchap, Matrix s’annonce comme un projet très solide.

Autant de raisons de tenter l’aventure! Cela faisait un bon moment maintenant que nous suivions l’affaire mais son usage a longtemps été réservé à des initié·es. Plus récemment, des efforts certains ont porté leur fruits et Element — le client de référence basé sur Matrix — n’est plus très loin du confort de Rocketchat.

Ainsi, depuis maintenant un mois nous avons basculé sur Matrix au sein du collectif.⁵ Ceci pour tester plus concrètement son usage et voir dans quelle mesure nous pourrions en faire bénéficier les organisations qui contribuent à Liiibre. Pas d’inquiétude si vous êtes sur Rocketchat, nous n’allons rien couper!

Il s’agit dans un premier temps d’une phase expérimentale. Nous vous partagerons cet automne notre retour à ce propos. Et si vous souhaitez tenter l’aventure au sein de votre organisation, n’hésitez pas à nous écrire à ce propos.

Et NextCloud Talk alors?

Nextcloud est la meilleure alternative libre à des outils de stockage en ligne tels que Google Drive, Dropbox, etc. à ce jour. Nous en sommes convaincu·es et c’est pourquoi cet outil est au coeur de Liiibre. Mais Nextcloud fait bien plus encore grâce à son côté extensible qui le dote d’une importante bibliothèque d’applications. Parmi elles, une messagerie instantanée a fait son chemin, il s’agit de Talk.

Développée principalement par l’équipe de Nextcloud⁶, si son avantage réside dans son intégration transparente au sein de la plateforme Nextcloud, pour le reste il est encore difficile de miser dessus. Nous l’avons testé et beaucoup de fonctionnalités manquent encore à l’appel comparé à Rocketchat ou Matrix. Par ailleurs, sa communauté et les moyens investis restent bien moindres en comparaison de Rocketcht et Matrix. Talk a encore beaucoup de chemin à faire pour espérer rattraper ses concurrents et étant donné que la messagerie instantanée ne constitue pas le coeur de Nextcloud il est probable que cela ne sera jamais vraiment le cas.

Autant de raisons qui expliquent pourquoi nous ne proposons pas Talk au sein de Liiibre et ne recommandons pas cet outil de manière générale en l’état.

Enfin, en ce qui concerne l’intégration, plusieurs améliorations ont été élaborées au sein de Liiibre pour permettre une fluidité d’usage entre Nextcloud d’un côté pour la partie nuage et Rocketchat de l’autre côté pour la messagerie instantanée. L’authentification unique permet de se connecter aux deux outils sans interruption, on peut naviguer de l’un à l’autre en un seul clic et bientôt l’appartenance à des groupes sera synchronisée en temps réel selon le protocole SCIM⁷.

Le tableau comparatif!

On n’allait pas vous laisser sans un beau tableau pour comparer point par point ces différents outils!

Si vous pensez à des critères de comparaison que vous souhaiteriez qu’on ajoute, n’hésitez pas à nous le faire savoir en commentaire.

Conclusion

En se plaçant à la fois dans la perspective d’un·e utilisateur·ice moyen·ne côté usage et à la fois dans celle d’un·e administrateur·ice d’instance, compte tenu des critères de notre tableau de comparatif, nous penchons plus pour Rocketchat à ce jour car il reste la solution la plus confortable, réactive et puissante en terme d’interface et d’administration. Matrix n’est pas loin derrière et augure de belles perspectives d’avenir. Enfin, Nextcloud Talk peine à rejoindre le duo en tête.

Nous espérons que cet article vous aura permis d’obtenir un bon panorama du côté des messageries instantanées libres et alternatives à Slack, Teams et Discord.

Pour toutes les organisations souhaitant reprendre le contrôle sur leurs outils et données, nous proposons donc Rocketchat au sein de Liiibre et sommes ouverts à discussions côté Matrix!

1. Kamoulox! Ok fallait le placer pour le référencement;) ↩

2. Source Wikipédia ↩

3. Software as a service: autrement dit, vous n’avez pas la main sur l’outil et encore moins son hébergement. Vous payez pour accéder à un service, c’est tout. ↩

4. Tout est rassemblé dans sa documentation (en anglais). ↩

5. C’est par là pour nous rejoindre: j’ai déjà un compte Matrix - je dois me créer un compte ↩

6. Depuis ses premiers jours, 4 employés de Nextcloud y ont contribué selon son dépôt Github. ↩

7. Actuellement en beta interne, mise en production visée pour la rentrée. Nous l’évoquions dans notre article précédent. ↩

Depuis l’été dernier, notre collectif décentralisé tient un rythme d’un séminaire en physique (ou Indie Camp) par semestre. Début mars 2022 a eu lieu l’Indie Camp n°2, dans lequel nous vous embarquions en immersion récemment avec l’article de Cécile.

Alors, qu’avons-nous fait les six mois précédents et que reste-t-il dans les cartons pour les six suivants? Au fil de notre mandala stratégique, voyons plus en détail les sujets que nous y avons abordés…

Et comme IndieHosters est un grand jardin, procédons parcelle par parcelle.

Parcelle Tech

Tout d’abord, que se passe-t-il dans le coeur technique du projet, notre infrastructure?

Évaluation de l’empreinte carbone de Liiibre: en cours!

IndieHosters souhaite proposer des outils numériques éthiques, et donc écologiquement responsables. A notre petite échelle, on ne peut pas réaliser une analyse de cycle de vie complète, mais nous nous donnons pour objectif actuel une première évaluation de l’empreinte carbone d’une instance de Liiibre.

C’est principalement Pierre et Maxime qui s’en occupent. Un article vient justement de sortir sur le sujet, et un deuxième est en préparation.

Email: Un sujet houleux et pas encore résolu

Nous utilisons trois types d’email:

• Transactionnel (notifications: chat, nuage, login unique, forum…)
• Personnel (quand vous nous contactez à contact@indiehosters.net ou support@indiehosters.net)
• “Bulk” (la newsletter, abonnez-vous 😉️)

L’email n’est pas notre coeur de métier mais il occupe donc une part importante de notre travail.

Or les technologies de l’email sont saturées par les problématiques de spam et particulièrement difficiles à administrer. Aujourd’hui, nos emails sont détectés comme indésirables par Microsoft…! Nous essayons de résoudre ce problème mais c’est un peu comme dans Le Procès de Kafka, sauf que la Justice, ici, c’est un algorithme qui a décidé que nous sommes des spammeurs, et qu’il n’y a aucun humain pour répondre à nos requêtes… Si vous voulez en savoir plus, il y a ce fil de discussion chez les CHATONS (attention, technique inside).

Un autre membre des CHATONS, David Mercereau, devrait nous apporter son concours pour mettre en place une infrastructure de “proxy” mail plus résiliente.

Diverses améliorations techniques

Une meilleure authentification unique: en cours!

Pour que nos utilisateurs n’aient à se connecter qu’à un seul compte sur tous nos outils, nous utilisons le gestionnaire d’authentification Keycloak. Ce dernier permet de créer des comptes et des groupes d’utilisateurs-trices dans Nextcloud et Rocket Chat, mais les changements à venir intéresseront les administrateur.ices d’instance dédiée!

Par exemple, l’ajout dans un groupe ne se fait qu’au moment où le premier utilisateur du groupe se connecte sur le logiciel, “à la volée”. Un des problèmes de ce comportement, c’est que les administrateurs-trices ne peuvent pas agir sur le groupe (lui accorder des droits, etc.) avant la première connexion d’un-e utilisateur-trice. Autre inconvénient, les utilisateur.ices ne peuvent pas commencer à discuter avec quelqu’un qui ne s’est pas encore connecté.

Le développement d’une liaison (SCIM) qui permettra ce genre de synchronisation est actuellement en cours:

• côté Keycloak et Rocket Chat: avec Hugo aux manettes, on est en phase de beta-test.
• côté Nextcloud: Pierre et Hugo ont participé au Hackaton Nextgov, auquel on avait participé l’an dernier pour Jitsi (on vous en parlait ici) et nous sommes arrivé 3èmes! On vous en reparle prochainement!

On est heureux de travailler sur ce projet conjointement avec Fairkom qui est un hébergeur d’outils libres basé en Autriche.

Migrations et harmonisations: terminées!

Stockage de médias en haute disponibilité

On est passés de Ceph à MinIO. C’est là où sont stockés:

• les fichiers de vos nuages,
• vos pièces jointes dans vos chats,
• vos images dans vos pads et forums,
• bref: tous les fichiers accessibles par nos outils.

Un article dédié à ce sujet est prévu.

Nouveau cluster Kubernetes & migration des applications

Kubernetes est une plateforme de déploiement de containers applicatifs, une abstraction au-dessus des machines physiques pour faciliter la gestion des serveurs. Pour la compréhension, un cluster est donc plus ou moins assimilable à un ensemble de serveurs virtuels.

Avant, nous avions 4 clusters Kubernetes: 3 pour de la production, et 1 pour du beta test. Avec l’arrivée d’Hugo dans l’équipe, nous avons supprimé le cluster beta, pour n’avoir plus que des clusters que nous pouvons utiliser à la demande pour développer. Et nous venons de nous séparer de notre premier cluster historique, qui s’appelait standard. Aujourd’hui, il nous reste 2 clusters de production qui correspondent à deux version de notre logiciel libre.sh:

• Louise Michel (basé sur kubespray)
• Ada Lovelace (basé sur k0s)

Pour la petite histoire (ou plutôt la grande), Louise Michel est une anarchiste de la Commune de Paris, et Ada Lovelace une pionnière de la science informatique.

Là aussi, un article de blog plus détaillé est à venir.

Harmonisation du SSO

Bientôt 100% de nos organisations seront en authentification unique.

Page d’erreur

Que se passe-t-il si vous allez sur une page qui n’existe pas? Ces pages d’erreur et de maintenance personnalisées sont désormais gérées par le logiciel Teapot. Encore une victoire de canard théière!

Voilà pour la parcelle Tech, continuons notre tour du jardin IndieHosters!

Parcelle Contributeurs

L’infrastructure permet de fournir des services qui bénéficient à nos organisations contributrices: les structures qui utilisent Liiibre et contribuent financièrement à IndieHosters en retour. Comment nous occupons-nous d’elles pour consolider ce commun ensemble?

Soin de la communauté

On s’occupe de vous et on cultive notre lien:

Formation: on continue!

Prendre soin des usager.e.s, c’est aussi les former: pour que l’usage des outils libres se normalise, il est nécessaire d’accompagner les utilisateur.rices néophytes. C’est le but des Indie Kafés, qui ont terminé leur saison en 7 épisodes de septembre à avril.

Pour la suite, Paul sonde les organisations et prépare un plan de bataille. Un article de rétrospective et de projection verra le jour bientôt!

Amélioration de l’expérience de support: à venir!

Aujourd’hui, lorsqu’un.e usager.e rencontre un problème avec Liiibre, il/elle nous écrit un email à support@indiehosters.net. Nous souhaitons améliorer notre support:

• en réorganisant le forum et en favorisant une entraide communautaire,
• en permettant de rapporter des bugs directement depuis l’interface Liiibre,
• en guidant les rapports de bug (screenshot, comportement attendu, etc.)

Suivi du volume d’activité d’une organisation: à venir!

Le montant de la contribution financière d’une organisation dépend de son activité en terme de nombre de comptes actifs. Pourtant, puisque nous avons à coeur de ne pas pister nos uagers.ères, nous n’avons pas une idée précise de l’activité réelle d’une instance dédiée. Quels outils éthiques mettre en place pour assister cette évaluation? Ou encore, comment mieux évaluer la part à laquelle chaque organisation doit contribuer? C’est un travail de fond que nous avons juste commencé.

Développement de la communauté: chantier prioritaire!

L’activité d’IndieHosters a bien évolué ces derniers temps avec une équipe qui s’agrandit et qui est de plus en plus présente pour répondre à l’évolution des démandes grandissantes. Pour atteindre l’équilibre, nous avons identifié qu’il nous fallait davantage d’organisations qui contribuent financièrement. Nous allons donc lancer différentes opérations de prospection et communication pour tenter de gagner en visibilité.

Nous en profitons pour passer un appel aux personnes désireuses de nous soutenir en promouvant IndieHosters autour d’elles et dans leur propre organisation si elle n’est pas déjà bénéficiaire de Liiibre!

Le Produit

Nous avons passé en revue les parcelles Tech et Contributeurs. A la jonction entre ces deux parcelles, il y a la courroie du Produit¹: que proposons-nous à nos usager.ères et comment? “Notre offre” vous est sûrement familière: une mixture de Nextcloud, OnlyOffice, Jitsi et Rocket Chat… Mais êtes-vous sûr-e-s d’en connaître les détails et les évolutions?

Cette vue est la plus parlante pour le public, il est donc nécessaire de la formaliser un peu. C’est principalement le domaine de Maxime.

Montée en niveau de la visioconférence: à acter!

De plus en plus, nos organisation contributrices commencent à nous demander des prestations particulières de vidéoconférence, pour des séminaires à plusieurs centaines de personnes, avec un support technique, une diffusion en direct (livestream)… C’est le cas notamment du Réseau Ingenium et du CNAM. Après avoir effectué avec succès quelques prestations de ce style, nous avons décidé de préparer prochainement une page sur notre site à propos de cette solution afin que plus d’organisations puissent en bénéficier.

Développement d’un centre de documentation: presque fini!

Notre plus grosse organisation contributrice nous a demandé un centre de documentation avec des didacticiels écrits et vidéos pour pouvoir étendre l’usage de Liiibre à toute la structure. Si tout va bien, ce centre devrait être open-source, et pourra donc bénéficier in fine à toustes! On vous en reparle prochainement…

Bientôt Matrix dans Liiibre?

Vous le savez, notre outil de discussion instantanée actuellement, c’est Rocket Chat. Néanmoins, on peut constater que les problèmes des silos de communication et de la multiplication des applications (untel utilise Whatsapp, unetelle Telegram, telle orga Rocket Chat et telle autre Mattermost) n’est pas résolu par la seule mise en place d’outils libres puisqu’ils peuvent aussi se “concurrencer” les uns les autres. La démarche de long-terme permettant de résoudre cela est l’interopérabilité, c’est-à-dire la possibilité de communiquer entre différentes applications avec un protocole standardisé: de cette manière chacun garde son application favorite, communique avec tout le monde et les vaches sont bien gardées.

Actuellement, il existe des ponts (“bridges”) entre certaines applications (pour qu’une personne utilisant Rocket Chat puisse parler à une autre utilisant Telegram par exemple), mais ce sont des développements logiciels spécifiques au cas par cas.

C’est là qu’intervient Matrix, une initiative soutenue par une fondation britannique qui permet une architecture décentralisée, fédérée et interopérable. Nous avons déjà bien avancé sur l’investigation de cette solution et nous pensons la proposer prochainement dans Liiibre. Le but n’est pas de faire passer tout le monde de Rocket Chat à Matrix dès demain, mais dans un premier temps de soutenir ce projet qui nous semble le plus émancipateur, et de préparer la transition sur le long-terme (si tout se passe bien).

Bientôt Mobilizon dans Liiibre?

Mobilizon est un logiciel de réseau social orienté évènements développé par la communauté de Framasoft. Il propose une alternative décentralisée aux évènement Facebook et consorts: idéal pour les tiers-lieux, les Coopératives d’Activité et d’Emploi, etc. qui organisent des évènements pour nourrir leur commmunauté.

C’est peut-être ce qui manquait à Liiibre: une gestion d’évènements publics. Alors on est prêt.e.s à se lancer et héberger un serveur Mobilizon. Et vous? Vous voulez l’essayer? N’hésitez pas à nous contacter!

Parcelle Bordures

Chez l’humain comme dans les collectifs, un organisme existe surtout dans le lien qu’il a avec l’extérieur. Alors, où en sont nos relations avec les autres acteurs du libre, les institutions et le grand public?

CHATONS: consolidation

Si vous l’ignoriez, IndieHosters fait partie des CHATONS. Maxime et Hugo ont d’ailleurs participé au dernier “CHATONS Camp”, une expérience galvanisante. Le semestre précédent, nous nous étions déjà donné pour objectif de participer davantage à la vie de ce collectif d’hébergeurs éthiques, mais il est difficile de trouver le bon angle de collaboration. Lors de l’Indie Camp 2, nous avons précisé notre volonté avec deux axes sur lesquels Paul vient prêter main forte:

• Favoriser et assister le bénévolat dans le projet CHATONS
• Améliorer la grille de lecture des CHATONS pour aider les personnes intéressées à s’orienter dans la galaxie du libre.

Podcasts: ça repart!

Vous n’aimez pas lire? Bravo d’être arrivé-e jusqu’ici alors! 😊️ Pour vous récompenser, nous vous signalons l’arrivée prochaine de nouveaux épisodes audio réalisés par Anne-Sophie, pour donner la parole à nos organisations contributrices.

Et pour vous mettre un peu de son dans vos oreilles en avance, on vous rappelle le premier épisode, réalisé par Zineb avec Télécoop.

Rencontrons-nous au festival Alternatiba!

Connaissez-vous Alternatiba? Ce mouvement pour la justice climatique et sociale a choisi nos services depuis déjà plusieurs années.

Le dernier Indie Camp nous a permi de planifier notre prochain rendez-vous IRL (In Real Life) et on espère vous y voir: nous avons décidé d’être présent-e-s au Festival Alternatiba, le festival du climat, le 8, 9 et 10 juillet 2022. Prenez vos places, on vous y attend! ;) Et spoiler: nous ferons très certainement un article sur le sujet!

Parcelle Organisation interne

“Mais bon sang”, nous direz-vous des étoiles dans les yeux, “comment arrivez-vous à être aussi doué-e-s, performant-e-s et engagé-e-s (et modestes 😁️) ?” C’est une bonne question et nous vous remercions de nous l’avoir posé. Pour conclure ce tour d’horizon, voyons ce qui se passe en interne.

Transition vers Dokos: terminée!

Pour la gestion de nos organisations usagères et des demandes entrantes, les logiciels libres Zammad et Invoice Ninja que nous utilisions pour la gestion des organisations ont récemment cédé place au logiciel intégré Dokos dans les buts de:

• pouvoir automatiser des tâches liés aux abonnements,
• avoir une gestion cohérente des factures associées aux abonnements. Nous conservons Zammad pour la gestion du support et des incidents.

Durant le séminaire, Maxime nous a fait une démonstration de l’usage de Dokos. Le gros du travail? Migrer nos contacts de Zammad et Invoice Ninja dans Dokos, un processus difficile à automatiser! Ce fut long mais à l’heure actuelle, on touche à la fin.

Un remerciement chaleureux à Charles-Henri Decultot de chez Dokos qui nous a accompagné avec beaucoup de soin durant cette transition d’outil!

Administratif et juridique: on dépoussière!

Chez IndieHosters, on apprend à marcher en marchant. Nous avons besoin de mettre à jour nos statuts juridiques pour être conforme à notre vision: un chantier qui reste devant nous. Les compétences d’Anne-Sophie, de Tim et de Cécile ne seront pas de trop!

Pour cette tâche, plusieurs chantiers ont été identifiés durant le Camp, à développer et creuser durant les prochains mois. Notamment des réponses aux questions sur les responsabilités au sein de l’association, une possible évolution statutaire, une grosse réflexion sur la forme que pourrait prendre le travail au sein de notre structure… Et puis bien sûr, LE fameux RGPD et une nouvelle rédaction de notre agrément de traitement des données.

Conseil des Communs: lancement!

Nous avons formalisé l’idée d’avoir un Conseil des Communs qui jouerait le rôle d’un Conseil de Surveillance (une terminologie qui ne nous convient pas du tout comme vous vous en doutez), ou encore d’un CA: des personnes bénévoles qui veille à ce que notre collectif ne perde pas de vue ses objectifs et sa raison d’être.

Nous avons déjà réfléchi aux personnes qui devraient le constituer, à parité hommes/femmes, et la première réunion devrait avoir lieu incessamment.

Bénévolat

La question du bénévolat est délicate chez IndieHosters. D’un côté, nous sommes conscient.e.s de la force indispensable d’une communauté bénévole pour défendre nos valeurs que le libre marché a plutôt tendance à défavoriser (pour rester poli), mais d’un autre, nous avons à coeur de rémunérer le travail et de créer le moins possible de précarité et encore moins d’exploitation.

Il nous est donc difficile de faire cohabiter de la rémunération et du bénévolat dans notre collectif… Nous avons finalement pris le parti de ne pas accepter de bénévoles sur le projet actuellement, mais de tenter de favoriser une dynamique bénévole au niveau des CHATONS pour aider à l’inclusion des personnes désireuses d’apprendre, d’échanger et de contribuer aux communs, ce qui bénéficierait à la communauté du libre tout entière.

On reviendra sur ce sujet dans quelques temps, quand nos réflexions se seront affinées et nos actions auront progressé!

Conclusion

Que ce soit côté infra, communauté, bordure ou organisation interne, nous avons bien avancé depuis l’Indie Camp de juillet 2021, et la route est encore longue, mais nous avons consolidé notre commun. Pendant ce temps, environ une trentaine d’organisations ont rejoint Liiibre, et on espère que la dynamique va continuer.

Nous adressons un grand remerciement à toutes les orgas qui font partie de l’aventure, et à celles et ceux qui nous suivent de près ou de loin… Et nous vous laissons avec la vidéo du déballage d’un colis rempli de miel et d’infusions, par Art Bati, une ferme collective et résidence artistique qui bénéficie de Liiibre! En espérant que cette contribution non-financière vous inspirera. :)

1. Nous ne sommes pas vraiment satisfait du terme de “produit”, si vous avez des idées d’alternative, n’hésitez pas! ↩

En septembre 2020, IndieHosters dévoilait Liiibre à destination des organisations conscientes qu’avoir une activité plus éthique et responsable passe aussi par l’usage d’outils numériques véritablement émancipateurs. Le fonctionnement de notre collectif, qui s’inspire de l’esprit des communs, vise notamment à assurer la pérennité des ressources que nous mettons à disposition de ses organisations contributrices.

Depuis, vous êtes de nombreuses organisations à avoir rejoint le mouvement en nous faisant confiance ou en faisant appel à une autre structure membre des CHATONS.

Mais l’hébergement de ces outils libres, outre le temps humain mis à contribution pour assurer leur fonctionnement, n’est pas neutre. Derrière, il y a des machines qui «les font tourner». Leur fabrication, activité et fin de vie a un impact écologique.

Jusqu’à maintenant nous évoquions simplement le fait que «Notre infrastructure technique est basée dans un datacenter alimenté à 100% en énergies renouvelables et nous privilégions l’usage de machines de seconde main. » sur la page d’accueil de notre site.

Cet article a donc pour objectif de rentrer un peu plus dans le vif du sujet ensemble, voir ce que nous avons appris depuis, et vous dévoiler ce qui évolue et vers où nous allons.

Une réflexion qui ne cesse de grandir

La question écologique est centrale pour chacun·e des membres du collectif IndieHosters. Nous partageons une conscience commune des enjeux liés à l’anthropocène et ses conséquences sur les conditions d’habitabilité des êtres qui constituent le vivant dont nous faisons partie.

En tant qu’hébergeur d’outils en ligne, aussi libres et éthiques soient-ils, dans quelle mesure l’activité d’IndieHosters participe-t-elle à un futur désirable sur le plan écologique?

Sachant qu’en 2020, le numérique est responsable de 2,1 à 3,9% des émissions mondiales de gaz à effet de serre, et que cette part devrait atteindre au moins 6% d’ici 2025¹, il est tout à fait légitime de se poser la question. ²

À vrai dire, elle nous obsède régulièrement car si nous n’avons aucun doute quant à l’importance (et l’urgence!) de se doter d’outils numériques émancipateurs — de se libérer des GAFAM et du capitalisme de surveillance pour le dire plus clairement — nous cherchons aussi à mieux articuler notre action conjointement à la lutte contre le changement climatique.

Pour mieux comprendre l’empreinte liée au secteur numérique, la lecture de cet article écrit par Gauthier Roussilhe (qui est d’ailleurs un usager de Liiibre dans le cadre du projet Plateaux Numériques) constitue une bonne introduction récapitulative.

Et s’il est vrai que ces réflexions sont longtemps restées limitées à un petit cercle, ce temps est maintenant révolu.

Si l’on en croit cette récente étude³ menée en mai 2021 par Harris Interactive et relayée par Green-IT, 45% des français·es estiment que le numérique a un impact négatif sur l’environnement. Parmi les différentes causes que l’on peut y attribuer, 57% estiment que le stockage sur le cloud participe de cet impact négatif. Enfin, 71% déclarent être prêt·es à réduire l’impact de leur comportement sur le numérique en ce qui concerne leur utilisation personnelle d’outils numériques.

Quelque part, la lecture de ces chiffres est rassurante, cela indique que cette prise de conscience est de plus en plus partagée. Cela nous engage à redoubler d’effort et à constamment garder à l’esprit l’impact écologique des décisions prises au sein du collectif.

Voici donc un premier tour d’horizon de nos actions qui vont en ce sens.

 Avertissement pour mieux situer d’où l’on parle: nous ne sommes pas expert·es, nous nous inscrivons dans une démarche mêlant l’acquisition de connaissances scientifiques en parallalèle d’actions concrètes et transformatrices. C’est un sujet complexe, nous en appelons à votre bienveillance et vous invitons à nous écrire en commentaire toute remarque et suggestion qui vous semblerait utile pour nourrir ce travail en cours.

Un centre de données «alimenté à 100% en énergies renouvelables»

Spoiler: ce n’est pas si simple. C’est ce qu’on a découvert progressivement au fil de nos interrogations et prises de conscience successives.

L’approche “market based”

Du point de vue du marché de l’énergie (approche dite «market based»), cette affirmation est correcte. Hetzner, le centre de données qui héberge nos serveurs, paie bien 100% de sa facture électrique à des fournisseurs d’énergie renouvelable d’après les certificats d’origine présents sur son site.

Plus précisément encore, une garantie d’origine est «un certificat électronique qui garantit que pour un MWh électrique soutiré (par l’acheteur de la garantie) sur le réseau électrique, un MWh d’électricité renouvelable a été injecté sur un réseau».⁴

La formule pourrait laisser entendre que l’énergie qui alimente le centre de données proviendrait à 100% d’un barrage hydraulique en direct pour celui en Allemagne et à 50% éolien / 50% hydraulique pour celui en Finlande. Or on peut se douter qu’il n’est pas connecté directement au générateur relié au barrage mais plutôt au réseau national. Les électrons ne se déplacent pas⁵ et on ne peut pas les «trier» entre ceux qui seraient issus d’un fournisseur renouvelable de ceux d’un fournisseur au charbon.

L’approche “local based”

En fait, une représentation plus correcte de l’électricité (et donc de son empreinte écologique) qui alimente le centre de données est donnée par le «mix électrique» du pays dans lequel il est localisé (approche dite «local based»). L’Allemagne et la Finlande dans le cas de nos serveurs. En 2019, d’après Eurostat la part en renouvelable représente 14,5% du mix énergétique de l’Allemagne et 35,4% de celui de la Finlande — pour la France nous sommes à 11%⁶.

Mais alors, quelle utilité à passer par un centre de données qui paye sa facture à un fournisseur d’énergie renouvelable?

Première chose: cet argent participe à maintenir une installation électrique fournissant une énergie renouvelable. Encore trop peu de centre de donnéess s’y engagent et avec la hausse récente des prix de l’énergie la situation risque de ne pas évoluer tout de suite.

De l’importance de veiller aux pratiques de son centre de données

Pour la petite histoire, en début d’année nous avons remarqué avec étonnement que la section sur les engagements écologiques de Hetzner avait disparu de leur site. Je leur ai écrit le 23 janvier:

Le lendemain, je recevais cela:

We can no longer continue to absorb the rising electricity costs». «As soon as the markets allows, we will return to using 100% green energy».

Une réalisation âpre qui ne m’a pour autant pas arrêté en chemin:

Le lendemain, Hetzner nous écrivait pour nous dire que la section à propos de leur engagement en matière d’écologie était à nouveau disponible sur leur site, accompagné d’un certificat de garantie d’origine renouvelé concernant leur centre de données en Allemagne.

Celui pour la Finlande ne l’était pas, ils avaient simplement laissé celui pour 2021. Je leur ai également fait remarquer et après quelques relances il a été renouvelé le 18 mars.

L’histoire ne dit pas si ces échanges ont réellement eu un impact en interne chez Hetzner ou si ce n’est qu’une pure coïncidence, pour autant j’espère que vous la partager contribue à vous inciter à interpeller votre hébergeur / centre de données ainsi. Ce n’est jamais du temps perdu.

Atouts et limites des certificats de garantie d’origine

Pour revenir à notre question sur l’utilité d’un certificat de garantie d’origine, l’inconvénient est qu’il ne nous assure pas nécessairement que cet argent participe à construire de nouvelles installations en renouvelable afin d’augmenter sa part dans le mix électrique. En l’occurrence pour le centre de données en Allemagne il est question d’énergie d’origine «hydraulique», il est donc probable que l’argent participe à maintenir un barrage déjà en place depuis quelques décennies.

Autre exemple en France, «seules 1% des garanties d’origine émises en 2017 en France correspondent à des installations construites après 2015. »⁷ C’est pourquoi une notion plus correcte serait de dire que Hetzner a plutôt opté pour une «stratégie d’atténuation» en l’état et fait le pari qu’en achetant ces certificats le marché s’oriente vers plus d’investissements pour les énergies renouvelables. Encore faut-il que tout le monde joue le jeu.

À cela s’ajoute d’autres effets pervers liés à ce dispositif comme par exemple lorsqu’on découvre qu’un pays comme l’Islande vend des certificats de garantie d’origine à des pays européens alors que son réseau électrique est insulaire. Plus ubuesque encore, le mix électrique de l’Islande — au sens contractuel et non localisé — comprendrait alors par conséquent du nucléaire alors qu’il n’y pas une seule centrale sur l’île.⁸

Donc pour s’inscrire dans une dynamique de réduction, il faudrait s’assurer que les fournisseurs d’énergie d’Hetzner, c’est à dire NaturEnergie (Allemagne) et Oomi (Finlande), participent à la construction de nouvelles sources d’énergies renouvelables⁹. Ou mieux encore, que Hetzner opte plutôt pour l’achat d’énergie verte en direct du producteur (voir PPA) plutôt que de certificats.¹⁰

Bref, on comprend que passer par un centre de données qui opte pour l’achat de certificats de garantie d’origine reste un bon premier pas mais comporte des non-dits qui s’avèrent importants à connaître. Pour celles et ceux qui souhaitent creuser, ce rapport et webinaire du cabinet Carbone 4 ainsi que cette vidéo du Réveilleur nous ont beaucoup aidé à mieux comprendre le sujet.

Pour notre part, difficile d’en demander plus à Hetzner. On pourrait éventuellement migrer chez un autre centre de données plus exigeant de ce point de vue mais nos recherches de ce côté n’ont pas donné grand chose pour le moment.¹¹ Par ailleurs, Hetzner se démarque par d’autres engagements complémentaires comme son marché de machines d’occasions que nous aborderons plus loin.

Reconnaissons également que nous restons un petit acteur avec une poignée de serveurs. Pour l’heure, nous avons revu les formulations sur notre site pour intégrer cette prise de conscience.

Tout n’est pas perdu, il existe d’autres voies pour aller dans le sens de la réduction des émissions de gaz à effet de serre. D’une part, nous pouvons revoir les outils intégrés à Liiibre d’une manière à ce que leur usage soit plus sobre, et d’autre part nous pouvons agir sur la manière dont nous les hébergeons pour éviter de solliciter plus de machines (serveurs) que nécessaire. Enfin, on réfléchit à l’intérêt de participer à des initiatives de recapture du CO2 s’appuyant sur de la reforestation par exemple.

Inciter à une certaine sobriété dans les usages

Une instance Liiibre mutualisée pour les petites organisations.

Déployer une instance complète nous paraît démesuré dans le cas de petites organisations de moins de dix personnes. C’est pourquoi dans ce cas nous proposons systématiquement de rejoindre notre instance Liiibre mutualisée. À l’heure actuelle, une trentaine d’organisations en font usage ainsi que quelques centaines de micro-entrepreneur·euses et particuliers. Ce sont donc autant d’instances que nous avons évité de déployer en choisissant la voie de la mutualisation.

10 Go d’espace de stockage

Lors de notre lancement, nous avons proposé dés le départ que chaque compte sur Liiibre soit pourvu de 10Go d’espace de stockage. 1 an et demi plus tard, on remarque que ça n’a pas posé de souci, c’est même plutôt bien accueilli la plupart du temps.

Seules 2-3 organisations nous ont demandé d’augmenter ce quota mais cela était directement lié à leur métier impliquant de gros volumes (l’une travaillant dans la post-production audiovisuelle par exemple).

Une autre mesure complémentaire mise en place consiste à voir l’espace de stockage comme un bien mutualisé au sein de l’organisation. Ainsi, pour une organisation de 10 personnes possédant 100 Go de stockage découpés en tranches de 10, l’administrateur·ice de l’instance est libre de redistribuer l’espace différemment selon les besoins réels des un·es et des autres.

Enfin, dans un autre cas, nous avons pu voir que cette mesure a incité à préserver l’usage d’un NAS local pour de l’archivage et ne mettre sur Liiibre que les fichiers les plus récents. Si nous les avions dotés de plusieurs To, comme le font classiquement les GAFAM (qui ont tout intérêt à emmagasiner un maximum de données) il est fort probable qu’iels auraient tout téléversé sur leur instance et auraient mis au placard un équipement pourtant fonctionnel.

Visio mutualisée et qualité plafonnée à 720p

Liiibre intègre une solution de visio basée sur Jitsi Meet. Là aussi, nous avons choisi la voie de la mutualisation en priorité. Une seule instance est déployée pour servir toutes nos organisations, y compris celles avec une instance Liiibre dédiée.

En effet, rares sont celles qui ont besoin de faire de la visio tout au long de la journée, la charge se répartit assez naturellement et nous observons une satisfaction globale plutôt bonne. Et lorsque le contexte de certaines organisations le nécessite nous proposons une instance Jitsi dédiée, mais cela représente une minorité chez nous.

Enfin, Jitsi Meet permet notamment d’échanger en haute définition 1080p. Il y a quelques années, on aurait pu voir le déploiement d’une telle qualité comme un défi technique, aujourd’hui on a plutôt décidé de régler nos instances pour qu’elles ne dépassent pas une résolution de 720p. Et le résultat est tout à fait suffisant pour ce cas d’usage.

En terme de mesure, passer de 1080p à 720p a pour effet de diviser par deux la sollicitation du réseau (6Mbps vs 3Mbps).

Côté serveurs, une question d’équilibre

Outre la possibilité de s’y connecter, quelle est la seconde qualité la plus importante pour l’usager·ère lorsqu’iel accède à un outil en ligne? Son temps de réponse.

Le temps de réponse, c’est la durée qui s’écoule entre le moment où l’on fait une action et son résultat. Dans notre cas, on pourrait partir du temps qui s’écoule entre le moment où l’on tape l’adresse de son nuage dans son navigateur et le moment où l’on peut commencer à interagir avec.

Et cela n’est pas qu’une question d’outil en ligne, c’est relatif à toute interface sur ordinateur. Des recherches portaient déjà sur le sujet en 1984¹² (et même plus tôt encore).

Or améliorer le temps de réponse influe sur l’impact écologique d’un outil en ligne. De nombreux facteurs entrent en jeu, les premiers auxquels on pense: la vitesse de connexion (celle-ci étant liée aux infrastructures, l’impact n’est pas le même pour une connexion filaire, wifi, 3g, 4g, 5g), la quantité de données à transférer, les performances de sa machine et sa façon de l’utiliser (ce n’est pas pareil selon le système d’exploitation, le nombres d’applications lancées, etc), le navigateur.

Mais aussi… Le nombre de serveurs derrière pour fournir le service, leur performance et la façon dont ils sont gérés et dont les services sont hébergés…

En tant qu’hébergeur, ce sont sur ces derniers éléments que nous pouvons principalement agir pour influer sur le temps de réponse de vos outils au sein de Liiibre.

Mais jusqu’où aller? Si gagner quelques dixièmes de seconde implique de notre côté de mobiliser plus de ressources et donc d’augmenter l’empreinte écologique de votre instance Liiibre, jusqu’où cela en vaut-il la peine?

Pour aborder cette question à ce jour, notre approche pourrait se résumer ainsi:

• Faire preuve de réserve lorsqu’on déploie nos services en favorisant le minimum de ressources sollicitées avant tout
• Améliorer en continu nos méthodes pour optimiser au mieux l’usage de nos machines
• Mobiliser de nouvelles machines en dernier recours et privilégier du matériel d’occasion
• Évaluer si le temps de réponse nous semble correct à l’usage (en tentant autant que possible de faire preuve d’objectivité) et être à l’écoute de nos organisations (et la grande majorité sont satisfaites en l’état).

Et si on tentait d’évaluer l’empreinte de tout ça?

À ce jour, l’ensemble des services mis à disposition par IndieHosters mobilise 17 machines physiques¹³ (14 achetées d’occasion et 3 neuves dont on va se séparer prochainement) et 29 machines virtuelles (6 dont on va se séparer prochainement) réparties entre Falkenstein et Helsinki pour bénéficier à environ 64 organisations, soit quelques 14 000 usager·ères inscrit·es.¹³

Pour aiguiser notre réflexion et l’enrichir de données tangibles, nous avons entrepris de mesurer l’empreinte carbone liée à l’hébergement d’une instance Liiibre — en suivant une approche «local based» évidemment. Une tâche qui s’avère plus complexe qu’elle n’y paraît au premier abord tant on manque de données dans le secteur (étonnamment!). Heureusement, nous avons l’immense chance d’être épaulés par Eric Fourboul et Benoit Petit qui oeuvrent chez Hubblo et co-animent ensemble Boavizta et également par Julie Orgelet (DDemain).

Nous vous ferons part de ce projet et de ses résultats dans le prochain article!

Et si vous souhaitez aller plus loin en attendant, nous ne pouvons que vous recommander cet excellent article (certes un peu ardu il faut dire) justement de nos ami·es de chez Boavizta dans lequel iels ont déplié leur méthodologie pour tenter de calculer l’empreinte de la fabrication d’un serveur.

Merci à David Ekchajzer (Hubblo) et Gauthier Roussilhe pour leur relecture attentive et leurs remarques.

1. Chiffres provenant de chez nos amis de Boavizta. ↩

2. Nous n’omettons pas que l’empreinte carbone n’est qu’une dimension et qu’il faudrait notamment prendre en compte l’impact sur les ressources en minerais et la biodiversité. Ce n’est pas l’envie qui manque mais difficile de tout faire en même temps dans notre petit équipe. Si vous êtes chercheur·euse sur le sujet et que vous souhaitez contribuer, n’hésitez pas à nous contacter. ↩

3. Enquête Harris Interactive: Développement du numérique et enjeux environnementaux: une possible cohabitation? ↩

4. Carbone 4: Electricité “verte” : un outil pertinent pour les entreprises? ↩

5. Cette vidéo est particulièrement instructive sur la façon dont l’électricité «irait» du générateur à la prise de nos machines. Néanmoins tout le monde ne semble pas d’accord avec cette vidéo au sein de la communauté scientifique, bref c’est compliqué. ^^ ↩

6. On pourrait élargir aux énergies non carbonés mais pour éviter d’ouvrir le débat sur le nucléaire, dont on ne cherche pas à s’échapper mais qui n’est pas encore bien clair au sein même du collectif, on se concentre sur les énergies renouvelables pour le moment. ↩

7. Carbone 4: Electricité “verte” : un outil pertinent pour les entreprises? ↩

8. Ça vous paraît fou? Pourtant c’est très bien expliqué dans cette vidéo du Réveilleur. ↩

9. Difficile d’obtenir une telle information, j’ai tenté ma chance en leur écrivant par email. Si j’obtiens des réponses, je ne manquerai pas de vous en reparler dans ce blog. ↩

10. Pour information, Enercoop semble déterminé à favoriser la démocratisation des contrats PPA. ↩

11. Si vous avez des pistes de centre de données localisés en France et alimentés en direct par énergies renouvelables (donc à priori Enercoop en fait) nous sommes preneurs! ↩

12. Ben Shneiderman - Response time and display rate in human performance with computers: DOI ↩

13. Plus précisément, nous louons nos machines à Hetzner. Parmi ces machines, nous pouvons choisir si elles sont d’occasions ou neuves. Et lorsqu’on se «sépare» d’une, on arrête de la louer et celle-ci est mise aux enchères pour d’autres clients. Plus d’infos à ce propos par là: https://www.hetzner.com/sb ↩ ↩²

 Indie quoi? Depuis septembre 2021, Koweb et IndieHosters s’associent pour vous proposer des ateliers gratuits de formation aux outils libres. Pour en savoir plus et retrouver les replays des sessions précédentes, c’est par ici.

Être plus efficace avec Rocket Chat

Dans l’atelier précédent, nous avons vu les bases de Rocket Chat. Dans celui-ci, le dernier de la saison, nous passons au niveau supérieur.

Être efficace avec un outil de chat, c’est par exemple ne pas se laisser déborder par les notifications, tout en ne ratant pas l’essentiel. Quelles fonctionnalités sont à nos commandes pour cela? Pour le savoir, rendez-vous le mardi 19 avril 2022 à 11h.

Inscription

Il est nécessaire de s’inscrire en remplissant ce court formulaire. Si le nombre de place maximal est atteint, pas de panique: vous pourrez suivre en live sur https://live.liiib.re!

Rediffusion de l’atelier

L’enregistrement de la session sera disponible ici début mai.

Et les ateliers suivants?

L’Indie Kafé 7 conclut la première saison de ces ateliers de formation libres et gratuits. Nous réfléchissons actuellement à la suite à donner à ce projet qui correspond le mieux aux besoins de nos utilisateurs et utilisatrices. Les infos sont à retrouver par ici.

Pour ne pas rater les prochains évènements, les options foisonnent:

• Suivre IndieHosters et Koweb sur les réseaux sociaux (Mastodon, Twitter, LinkedIn)
• S’inscrire à l’infolettre d’IndieHosters (sur notre page d’accueil) et/ou à celle de Koweb.
• S’inscrire sur le Koweb Kafé, un forum d’échange entre animateurs de groupe autour des outils numériques.

A bientôt dans les sessions Indie Kafé!

Qu’il est bon de se retrouver de visu après six mois d’interactions à distance!

Dissiper la brume, révéler le chemin

Après un premier IndieCamp en juillet 2021, prototype d’un séminaire interne version déconfinée, le collectif s’est retrouvé du 1er au 4 mars du côté de Charleville-Mézières dans une étonnante bâtisse surplombant la ville.

Il a fait froid, il a fait beau, et l’électricité a souvent manqué en raison d’un contrat d’abonnement spécifique qui a forcé un peu plus la question de la sobriété énergétique pour IndieHosters… !

Ce rendez-vous s’inscrit dans les agendas tous les six mois. C’est le moment de se retrouver, de nouer plus fort les relations, dénouer les tensions, et harmoniser les élans d’action.

Peut-être l’aviez-vous lu dans l’article précédent, le collectif travaille quasi exclusivement en distanciel, avec des rendez-vous synchrones hebdomadaires pour assurer la bonne tenue des services et soigner la communauté des contributeurs. S’offrir une petite semaine de cohabitation semble être la manière la plus naturelle pour celleux qui font Indie Hosters d’ancrer leurs pratiques collaboratives dans un terreau de curiosité pour l’autre, et de convivialité.

Depuis l’été, la membrane du collectif a évolué, avec des mouvements planifiés et d’autres plus spontanés! Hugo a officiellement créé son activité, Paul a lancé les Indie Kafé, Maroin s’est extrait pour répondre positivement à une sollicitation professionnelle qu’il ne pouvait pas décemment refuser, Tim a accueilli un enfant et profité de son congé, Anne-Sophie est arrivée par une porte dérobée… Là, c’est Cécile qui raconte: je suis l’accompagnatrice du groupe sur ces IndieCamps.

Jour 1 - Intégrer et célébrer

Ainsi, après une demi-journée de gestion logistique et une soirée passée à jouer, le collectif composé de Tim, Max, Anne-Sophie, Paul, Hugo et Pierre s’est laissé embarquer par la proposition d’animation concoctée par mes soins. Au programme de cette première journée de travail: l’intégration des nouveaux et nouvelles, et la rétrospective des six mois passés.

Paul n’avait pas pu participer aux journées de travail de juillet dernier, Anne-Sophie, elle, a intégré le collectif cet hiver; il s’agissait donc de prendre soin de leur partager les informations dont ils pouvaient avoir besoin pour contribuer aux réflexions stratégiques à suivre.

Nous avons commencé par ouvrir une séquence de partage « Petite Histoire Grande Histoire», une animation issue des pratiques de l’éducation populaire qui place l’intime et le politique au centre des discussions. C’est un exercice qui, en demandant à chaque participant·e de raconter des jalons importants de son parcours intellectuel et/ou militant, permet de mettre à jour les représentations individuelles et de saisir avec sensibilité ce qui fait qu’on est là ensemble, réunis pour créer et porter quelque chose qui nous ressemble.

Si ce qui s’est dit n’a pas vocation à être exposé en dehors de la membrane de l’équipe, on peut tabler sur le fait que l’identité du collectif s’est renforcée à mesure que chacun·e se reconnaissait dans les partages des autres.

Après cette séquence riche, nous avons entamé notre rétrospective semestrielle. Il s’agit d’une pratique déjà bien ancrée dans le collectif depuis novembre 2020, à l’époque où Maïa et Maroin animaient cette séquence à distance. Elle permet de célébrer les réalisations et de mesurer les chantiers abandonnés ou suspendus en cours de route. C’est le temps de l’observation et de l’appréciation… L’analyse se fera plus tard.

Après un moment solo pour rassembler ses idées, des sous-groupes se forment par métier pour mettre en commun et préparer une restitution qui présente: ce qui a été accompli / ce qui n’a pas été réalisé / ce que ça leur fait.

Clap, clap, clap, c’est le doux son de la célébration… On laisse filer le passé petit à petit, et les sujets critiques pour la suite commencent à pointer leur nez.

Il reste encore à aborder un sujet plus personnel, les projections à moyen/long terme dans le collectif. Anne-Sophie a dû rejoindre ses pénates, déjà, engagée dans d’autres activités professionnelles qui contraignaient, pour cette fois, sa participation pleine.

La suite se passe au grand air, dans un champ avec vue… Un peu de perspective visuelle pour soutenir la réflexion personnelle et le partage potentiellement vulnérable qui peut se présenter. Organisation du travail, rémunération, craintes et espoirs. La confiance est suffisamment présente pour que chacun ose livrer ses projets pour lui-même. Dans un collectif de travail, l’interdépendance est forte et souhaitée, elle suppose par conséquent de cultiver la transparence et l’authenticité afin de réduire les incertitudes, celles sur lesquelles on a la main…

Jour 2 - Libérer et discuter

Voilà le groupe plein d’élans pour se projeter dans l’avenir. La journée démarre en imaginant les accomplissements de l’équipe dans deux ans, à la façon de la méthode Souvenir du futur. L’exercice permet à chacun de contribuer et de livrer sa vision personnelle sur les quatre parcelles du jardin IndieHosters: organisation collective, bordures, tech, contributions.

Dans ma posture d’animatrice, cette journée ressemble à un exercice de funambule: le processus prévu pour soutenir la mise en débat est volontairement léger car le collectif est très mature dans sa capacité à débattre de sujets chauds et/ou politiques. Le plus délicat, comme pour la plupart des collectifs qui cultivent l’horizontalité, c’est d’atterrir et décider.

Parcelle après parcelle, on déplie les sujets, on observe, on prend note de là où ça tire, là où c’est fluide. Cahin-caha, la parole se libère, la pensée se développe jusqu’à toucher par moments, la fatigue aidant, l’incompréhension.

L’organisation en tant que collectif de travail, les transactions symboliques et réelles qui fondent la question de la contribution, le soin à la communauté liiibre et du logiciel libre en général, les envies, les limites…. A tant creuser les sujets, on a accès aux profondeurs… En interrogeant les développements possibles de Liiibre, le service offert par IndieHosters, le collectif considère son adhésion à la philosophie des Communs, son souci de cohérence, ses interdépendances, ses envies de piraterie (pardon? eh bien oui). Le sens politique de leurs décisions ne leur échappe pas, c’est même le ferment, me semble-t-il, de leur collaboration. Le collectif et l’activité grandissant, il s’impose à eux de réinterroger leurs orientations stratégiques, et d’examiner ceux de leurs positionnements qui seraient devenus obsolètes.

Le temps presse et les conditions ne sont pas réunies pour trancher. Il est décidé de mettre en débat plus largement les sujets qui divisent en faisant appel au fraîchement nommé Conseil des Communs qui se réunira pour la première fois en 2022.

Or ne pas décider, c’est déjà décider! Le report à plus tard, avec une vraie préparation, permettra à tout le monde de préciser sa vision et ses arguments. Vivement ce moment.

Les esprits quelque peu échauffés n’en fournissent pas moins des propositions de qualité: au fil de la journée, nous voyons affleurer les tâches et chantiers à ouvrir… Le lendemain, nous remplirons le mandala stratégique qui structure les activités pour les six mois à venir, il faudra encore préciser, trier, prioriser…ce par quoi commencer.

Une visite au village pour faire le plein de gluten sous toutes ses formes nous permet de souffler et goûter aux charmes d’un village ardennais aux prémisses du printemps.

Jour 3 et 4 - Converger

La fin de l’accompagnement est proche, c’est le jour de l’atterrissage… Il reste une parcelle à examiner: la Tech. Il se dit qu’il y aurait moins de dissensus sur cette parcelle-là. Les trois développeurs/admin sys s’attellent à la mise en mots des développements souhaités pour les deux années à venir. Dehors, le soleil brille. On n’y résiste pas.

Après des discussions à horizon deux ans, il convient - et c’est une gymnastique en soi, de transformer ces projections en actions concrètes à réaliser dans les 6 prochains mois. C’est la seconde fois que le collectif balise son chemin de la sorte en remplissant un canevas: le fameux « mandala stratégique». Tous les mois, les activités sont repilotées grâce à un tableau de bord collaboratif en ligne sur l’app deck ce qui donne de la visibilité sur tous les chantiers en cours.

Le niveau de dialogue demandé par la mise à jour du mandala est exigeant: métier par métier, les activités sont précisées et triées. Cette séquence de convergence s’appuie sur la capacité du groupe à affirmer des orientations et processer ses dissensus. Cela est rendu possible par le temps relativement long consacré la veille à la mise en débat des diverses perspectives.

Dans un environnement aussi incertain que celui de mars 2022, nous ne travaillons pas à définir classiquement des objectifs mais nous tâchons de cerner les directions pertinentes pour la pérennité de la structure et de son offre. L’exercice permet à chacun·e de renforcer son engagement grâce au partage sincère et transparent des réalités métier. En filigrane, ping pong et pizzas détendent les dernières crispations que le collectif traverse en ce jour 3.

Après un temps de relâche, le groupe se remet au travail lors d’une session autour de Dokos: leur nouveau système de gestion interne mis en en place fin 2021. Cette dernière soirée tous ensemble était bien méritée!

Le lendemain et dernier jour, il faut encore remettre l’ouvrage sur le métier: le collectif a testé l’an passé d’évaluer le temps requis par chaque action (= « ticket») pour mieux prioriser et se répartir le travail. Si cela avait demandé de longs échanges la première fois, cette fois-ci l’expérience a permis de formuler des hypothèses plus rapidement, et de se quitter avec une conscience aiguë du travail attendu, et de la clarté sur ce que chacun doit prendre en charge.

Sans compter les ventres repus et les souvenirs joyeux qui font que cet IndieCamp v2 valide aussi bien la fréquence choisir que le format. On se quitte pour 6 mois, et je me demande déjà quelle sera la tonalité de notre prochaine semaine ensemble. Hâte!

 Indie quoi? Depuis septembre 2021, Koweb et IndieHosters s’associent pour vous proposer des ateliers gratuits de formation aux outils libres. Pour en savoir plus et retrouver les replays des sessions précédentes, c’est par ici.

Discuter en équipe(s) avec Rocket Chat

Les messageries instantanées, ou chats, palliant les lourdeurs et les incertitudes des emails, sont devenues quasiment incontournables pour échanger fluidement et rapidement, entre ami-e-s… mais aussi au sein des organisations.

Connaissez-vous la différence entre des chats pour les individus (Signal, Telegram, WhatsApp…) et des messageries d’équipes (Mattermost, Zulip, Slack… et Rocket Chat) ? Comment augmenter l’efficacité de vos équipes avec ces dernières? Quelles sont les fonctionnalités-clés de Rocket Chat?

Nous le découvrirons le jeudi 24 mars 2022 à 11h.

Inscription

Il est nécessaire de s’inscrire en remplissant ce court formulaire. Si le nombre de place maximal est atteint, pas de panique: vous pourrez suivre en live sur https://live.liiib.re!

Rediffusion de l’atelier

Aussi dispo sur YouTube si besoin.

Et les ateliers suivants?

Le planning est à retrouver par ici.

Pour ne pas rater l’ouverture des inscriptions, les options foisonnent:

• Suivre IndieHosters et Koweb sur les réseaux sociaux (Mastodon, Twitter, LinkedIn)
• S’inscrire à l’infolettre d’IndieHosters (sur notre page d’accueil) et/ou à celle de Koweb.
• S’inscrire sur le Koweb Kafé, un forum d’échange entre animateurs de groupe autour des outils numériques.

A bientôt dans les sessions Indie Kafé!

 Indie quoi? Depuis septembre 2021, Koweb et IndieHosters s’associent pour vous proposer des ateliers gratuits de formation aux outils libres. Pour en savoir plus et retrouver les replays des sessions précédentes, c’est par ici.

Animer une réunion à distance avec Jitsi

Avec la généralisation du télétravail, ces deux dernières années ont vu les visioconférences se démocratiser et les exigences du public ont grimpé en flèche. Côté logiciel libre, Jitsi se démarque particulièrement. C’est la solution qu’Indie Hosters a sélectionné pour la visioconférence de notre suite Liiibre.

Vous avez très certainement déjà participé à des visioconférences. Mais maîtrisez-vous l’outil à 100% ? Venez découvrir les fonctionnalités de Jitsi côté utilisation et côté modération.

Inscription

Comme précédemment, il est nécessaire de s’inscrire en remplissant ce court formulaire. Si le nombre de place maximal est atteint, pas de panique: vous pourrez suivre en live sur https://live.liiib.re!

Rediffusion de l’atelier

L’enregistrement de la session n’est pas encore disponible pour des raisons techniques.

Et les ateliers suivants?

Le planning est à retrouver par ici.

Pour ne pas rater l’ouverture des inscriptions, les options foisonnent:

• Suivre IndieHosters et Koweb sur les réseaux sociaux (Mastodon, Twitter, LinkedIn)
• S’inscrire à l’infolettre d’IndieHosters (sur notre page d’accueil) et/ou à celle de Koweb.
• S’inscrire sur le Koweb Kafé, un forum d’échange entre animateurs de groupe autour des outils numériques.

A bientôt dans les sessions Indie Kafé!

Hormis les rendez-vous du Indie Kafé, il est vrai que cela faisait un petit moment que nous n’avions pas pris le temps de vous écrire un article à propos de Liiibre. Et pour cause, ça bouge pas mal chez IndieHosters! On a de belles organisations qui nous ont rejoint ces derniers mois et nous nous sommes concentré·e·s à honorer leur besoins du mieux que nous pouvons avant tout.

Nous prendrons le temps prochainement de vous partager ici un peu plus les évolutions au sein du collectif, mais pour l’heure voyons déjà ce qui se passe côté Liiibre.

C’est simple, pratiquement tous les outils sur lesquels notre solution se base sont impactés. Nous hébergeons maintenant Nextcloud en version 21, Rocketchat en version 4, OnlyOffice en version 6.4, Jitsi en version 6726-2, etc.

 Pour rappel, tout le détail des versions est disponible comme d’habitude sur cette page.

Bon… On sent bien que cette énumération a peu de chance de vous parler, sauf si éventuellement vous êtes très impliqué·e·s et suivez par ailleurs l’évolution de ces outils sur leur dépôt de code officiels.

Outre une stabilité toujours améliorée, des éventuelles failles de sécurités résorbés, et des bugs fixés, ces nouvelles versions apportent leur lot de nouvelles fonctionnalités.

En voici quelques unes qui ont retenu notre attention et qui sont donc maintenant disponibles dans Liiibre pour votre organisation.

Attacher des fichiers de votre nuage aux cartes dans Deck

Pour celles et ceux qui utilisent Deck au sein de leur nuage pour organiser leurs projets sous forme de Kanban, cette nouveauté est bien pratique pour faire référence à des éléments de votre nuage.

Petite note de vigilance: si rien ne se passe lorsque vous essayez d’attacher un élément spécifique c’est peut-être que vous n’avez pas les droits de partage pour le fichier en question.

 “Mais je n’ai pas Deck sur mon nuage” - En effet, cette application n’est pas activée par défaut. On explique tout par là.

Organiser ses canaux de discussions par équipes

Le concept est arrivé il y a déjà un petit moment dans Rocketchat mais comme nous n’avions pas eu l’occasion de l’évoquer dans notre blog, ça semblait être le bon moment:)

Concrètement, une équipe est une sorte de canal qui peut englober des sous-canaux. C’est une manière de mieux ranger différents espaces de discussions qui seraient susceptibles d’intéresser le même groupe de personnes à chaque fois. Et en plus, on peut spécifier si certains de ces sous-canaux doivent accueillir automatiquement toutes les personnes de l’équipe par exemple.

Plus facile de s’y retrouver ainsi lorsqu’on veut être certain·e par exemple que toutes les personnes de l’équipe “Bénévoles” soient bien inclus dans tous les canaux susceptibles de les intéresser.

 Pour info On vous a rédigé une fiche explicative dans laquelle on vous explique comment prendre en main c’est fonctionnalité.

Diviser une salle de visio en plusieurs salles annexes

C’était une fonctionnalité très attendue… Il est maintenant possible de créer des salles annexes depuis une session visio sur la nouvelle version de Jitsi. Très utile lorsqu’un groupe de participant·e·s se divise pour prendre un temps pour échanger à propos de différents sujets tout en pouvant circuler librement d’une salle à l’autre et se retrouver à nouveau ensemble ultérieurement dans la salle principale si besoin.

 Peinture fraîche Cette fonctionnalité est encore assez récente, il se peut qu’elle comporte quelques bugs. Si vous en rencontrez, n’hésitez pas à nous écrire à support /at\ indiehosters.net pour nous en faire part ou, mieux encore, à directement déposer (ou compléter) un ticket de bug sur le dépôt de code officiel de jitsi.

Autres nouveautés en visio

Lancer un sondage

Vous pouvez maitenant proposer un sondage durant une session de visio. Pratique pour faire des quizz en direct ou bien des votes par exemple!

 Vous trouverez cette option dans le panneau qui s’ouvre à gauche de l’écran lorsque vous consultez le chat.

De nouvelles réactions

On pouvait lever la main… et maintenant on peut même applaudir ou bien huer. Et il y a le petit effet sonore qui va avec…

On n’a pas tellement encore trouvé l’utilité de cette nouveauté si ce n’est de nous donner le sourire lorsque l’effet est lancé au bon moment. À bon entendeur·euse;)

Et voilà!

On espère que ces nouvelles fonctionnalités vous permettront de profiter encore plus des possibilités offertes par Liiibre. Nous prenons soin régulièrement de transmettre aux contributeur·ice·s les suggestions que vous nous transmettez lors de nos échanges, donc n’hésitez pas à nous faire part des éventuelles soucis que vous seriez amené·e à rencontrer lors de votre usage.

#éco-conception

Un dernier petit mot à propos des exemples animées dans cet article.

On a pas mal hésité entre l’usage de capture statique et leur version animée, cette dernière étant plus lourde à charger. On a finalement opté pour la version animée lorsque une capture statique ne se suffisait pas à elle-même.

Enfin, après quelques tests de comparaison de poids des fichiers entre les formats gif vs mp4 vs webm on a pu déterminer que c’est le dernier, webm, qui offrait la meilleure compression. C’est donc la version webm qui se charge en priorité si votre navigateur est bien compatible. Sinon, c’est le mp4. (Enfin une autre bonne raison de soutenir webm est que c’est un format de fichier ouvert!¹)

Si vous avez des suggestions de ce côté, n’hésitez pas à les partager en commentaire.

1. En savoir plus à propos du format webm: Article Wikipédia ↩