Chat : de irssi + gateway messenger à weechat, la philosophie du client mince
L’article irssi de 2009 finissait sur un edit: “Une configuration à jour est dispo ici sur github” (c’était un stub d’article, la vraie valeur vivait dans le repo, la suite des temps l’a prouvé). Il faut maintenant raconter ce que l’article ne racontait pas: le montage qui rendait irssi indispensable et pourquoi deux ans plus tard j’ai tout déménagé vers weechat sans changer la philosophie.
irssi + BitlBee: le pont vers les messengers
Le montage de l’époque: un serveur BitlBee local qui présente les réseaux de messagerie instantanée (MSN, AIM, ICQ, Jabber) comme un canal IRC ordinaire et irssi qui s’y connecte comme à n’importe quel serveur. Résultat: un seul client, un seul buffer, une seule config de logs, pour IRC et pour les contacts MSN qui ne connaissent de l’IRC que le nom.
Les artefacts qui survivent de cette époque: une config irssi multi-réseaux (367 lignes, git 2013, recyclé-irc/otaku-irc/worldnet SSL:7000/fansub-irc/OFTC SSL:9999, thème green.theme) et cinq scripts Perl perso signés d5-ro (contact 0din@vhalholl.info): autojoin.pl (rejoindre après kick, protocole IRC brut via send_raw("JOIN ...")), slap.pl (136 lignes, le classique /me slaps <nick> with a random object, avec guide de Windows ME et CD de Lorie dans la liste), dd.pl (la variante D&D avec points de dégâts aléatoires), loop.pl et screenlaunch.pl (lancer une commande dans Screen depuis l’IRC: le multiplexeur et le client se donnent la main).
C’était la bonne architecture et c’en est resté une: le client est mince, la gateway porte la complexité des protocoles. Ce que l’article d’époque ne disait pas: la config vivait dans les dotfiles, le détachement se faisait dans Screen (avec byobu sur les machines à la mode) et la question fatidique commençait à se poser: et si le client pouvait être piloté sans terminal?
weechat: la migration et pourquoi elle a tenu
weechat (0.3.x à l’époque) a pris le relais pour trois raisons pratiques et une architecturale:
- L’API de scripting (python/perl/lua): les plugins de l’époque s’écrivaient en quelques dizaines de lignes et la config
~/.weechat/se versionne comme le reste des dotfiles; - Le relay: le protocole de relay de weechat expose le buffer à des clients externes (web, mobile), c’est le BitlBee inversé: au lieu de tirer les messagers vers IRC, on pousse IRC vers d’autres clients;
- Le buffer unique: même raisonnement qu’irssi, tout dans un buffer, les réseaux distingables par couleur et par hotlist;
- Et l’architecturale: weechat est un client avec une API de couche réseau propre, exactement l’endroit où brancher une gateway de plus.
La migration irssi -> weechat a pris un après-midi (importer les logs, recopier les aliases, rejouer les couleurs) et n’a rien changé au montage: BitlBee est resté, weechat s’y connecte comme irssi le faisait. C’est ça, la leçon: on change de client comme on change d’éditeur, on garde la gateway comme on garde sa maison.
[edit: 2026] Le monde a rattrapé la gateway
MSN est mort en 2014, AIM en 2017 et les messengers propriétaires ont fermé leurs protocoles un par un. BitlBee est resté debout en migrant vers Jabber et la gateway de l’époque moderne s’appelle Matrix: le protocole de bridge qui parle à tout le monde et héberge l’historique. Le weechat d’aujourd’hui s’y connecte par le script weechat-matrix et le vieux montage irssi+BitlBee de 2009 ressemble à la première itération d’une idée qui n’a pas bougé: un client mince, une gateway qui porte les protocoles, une archive des logs. On a juste changé le protocole de la gateway trois fois en dix-sept ans et le client deux fois.