10 octobre 2024 - Le collectif IndieHosters

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.