29 mai 2023 - Le collectif IndieHosters

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