Espace-IRC ? Kesako ?

Article publié initialement en 2007 sur fafchamps.be — réécrit, enrichi et complété en janvier 2025 avec le recul des années.

Espace-IRC était un réseau IRC francophone : un espace d'échange, d'entraide et de conseils entre internautes. Les utilisateurs connectés s'appelaient les spationautes, et l'ensemble constituait l'espace. D'où le nom.

IRC, pour Internet Relay Chat, permettait à des milliers de personnes de discuter en temps réel à une époque où Facebook n'existait pas encore vraiment, où MSN Messenger régnait sur les conversations privées et où Discord était très loin d'exister. On se connectait à un réseau, puis on rejoignait des salons, reconnaissables à leur # : #belgique, #informatique, #aide. Chaque réseau avait ses serveurs, ses règles, ses opérateurs et sa communauté. Il fallait un logiciel comme mIRC, XChat ou irssi, ou un client web : j'ai fini par écrire le mien, pour ceux qui voulaient tchater sans apprendre de commandes. Notre adresse était irc.espace-irc.org, derrière laquelle se trouvaient plusieurs serveurs reliés entre eux.

Pourquoi ce projet

Car tout groupe humain prend sa richesse dans la communication, l'entraide et la solidarité visant à un but commun : l'épanouissement de chacun dans le respect des différences.

Car le contact, c'est l'appréciation des différences.

Car le but de la discussion ne doit pas être la victoire, mais l'amélioration.

Ces trois phrases, ce n'est pas moi qui les ai écrites : c'est Leslie. Elles ouvraient le site à l'époque, et presque vingt ans plus tard elles sont toujours aussi justes. Merci à elle.

J'ai commencé à toucher à tout cela vers 14 ans, et c'est probablement ce qui m'a le plus appris en informatique. Au début, je faisais tout mal : je modifiais des fichiers de configuration sans comprendre chaque ligne, je cassais des choses, je cherchais pourquoi ça ne fonctionnait plus, je demandais de l'aide, et je recommençais.

J'ai appris ainsi à administrer un serveur Linux, à compiler des logiciels, à lire des logs, à comprendre les processus, les ports, les permissions. Avec IRC, il fallait toucher à tout : le système, le réseau, le développement, les bases de données, la sécurité, les services. Google existait déjà, mais l'essentiel venait des forums, des mailing-lists, de documentations plus ou moins bien écrites, et surtout d'autres passionnés qui avaient cassé exactement la même chose quelques semaines plus tôt.

IRCu, CService et le fameux X

Nous étions partis sur une architecture IRCu avec CService, et son célèbre X. Là où d'autres systèmes multipliaient les services séparés — NickServ, ChanServ, MemoServ, OperServ —, CService avait une philosophie différente : X était présent directement sur le salon. On le voyait dans la liste des utilisateurs et on savait qu'il gérait le channel, les accès, les opérateurs. Chaque salon avait presque son propre gardien.

Puis l'écosystème s'est essoufflé : développements rares, composants plus maintenus, documentation vieillissante, compatibilités compliquées, et de moins en moins de réseaux qui l'utilisaient. Nous avons fini par basculer, un peu à contre-cœur, vers un autre IRCd et la série de services classiques. Techniquement, l'écosystème était plus vivant ; mais avec la disparition de CService, c'était aussi une petite époque d'IRC qui se terminait.

Les Eggdrop

Impossible de parler d'IRC à cette époque sans parler des Eggdrop, ces bots qu'on installait sur un shell ou son propre serveur. On leur ajoutait des scripts, très souvent en Tcl, pour gérer un salon, protéger du flood, sortir des statistiques, animer des jeux.

C'est de là que venaient #Quizz, #Motus et #Pendu, entièrement pilotés par des bots. Ça paraît simple aujourd'hui, mais ce genre de salon réunissait du monde et créait une vraie petite communauté : on reconnaissait les pseudos, on revenait le lendemain pour battre son score, et le jeu devenait souvent secondaire par rapport aux discussions autour. C'était aussi une excellente excuse pour apprendre : compiler, configurer, installer un script Tcl, changer deux lignes, tout casser, et découvrir une heure plus tard qu'il manquait une accolade.

Les shells, les PID, et le premier serveur dédié

Héberger tout cela n'était pas aussi simple qu'aujourd'hui : le cloud n'existait pas pour le grand public, et louer un serveur coûtait cher quand on était étudiant. Je louais donc un shell, c'est-à-dire un simple compte utilisateur sur la machine Linux de quelqu'un d'autre. Pas de root, pas de serveur à soi.

Certaines offres étaient facturées au nombre de PID, autrement dit au nombre de processus qu'on pouvait faire tourner simultanément : un pour le serveur IRC, un pour un Eggdrop, un pour un service. Aujourd'hui on lance des conteneurs sans y penser ; à l'époque, un processus supplémentaire entrait dans la réflexion budgétaire.

Puis les serveurs dédiés sont devenus accessibles aux particuliers. Avoir sa propre machine avec un accès root complet, c'était le rêve, mais les prix restaient élevés : il fallait surveiller la mémoire, la charge, l'espace disque. Et quand quelque chose ne redémarrait plus après une modification à deux heures du matin, pas question de supprimer la machine et d'en recréer une en trente secondes. Il fallait la réparer.

Une communauté, et la question de savoir qui est qui

Avec le recul, la partie la plus intéressante n'était pas la technique. Gérer un réseau IRC, c'était gérer une communauté : des dizaines, parfois des centaines de personnes, des habitués, des nouveaux, des modérateurs, et quelques-uns qui venaient pour mettre le bazar.

Presque tout le monde utilisait un pseudonyme, et changer d'identité prenait quelques secondes : une personne bannie revenait avec un autre pseudo, une autre connexion, une autre adresse IP, un proxy, parfois quelques minutes après son expulsion. La modération ne consistait donc pas à taper un /ban et considérer l'affaire close.

Il fallait donc essayer de comprendre qui était qui : les habitudes, la manière d'écrire, les expressions, les heures de connexion, les salons fréquentés, les pseudos successifs, les adresses quand elles étaient visibles. Cinq minutes après un bannissement, un nouvel utilisateur arrivait, nouveau pseudo, nouvelle adresse, et au bout de trois phrases on se disait : « mais c'est pas lui qu'on vient de bannir ? »

Alors on recoupait les informations dont on disposait. Pas avec des outils extraordinaires ni de grandes bases de données : avec beaucoup d'observation. C'était une forme très primitive de ce qu'on appellerait aujourd'hui du recoupement d'informations numériques. Nous étions des adolescents et de jeunes adultes, et nous ne faisions rien de professionnel, mais le mécanisme était déjà là : quelqu'un change d'identité, passe par un proxy, revient après un bannissement, adopte un comportement légèrement différent, et de l'autre côté il faut déterminer s'il s'agit de la même personne ou simplement de quelqu'un qui lui ressemble.

C'est là que j'ai appris, par la pratique et à mes frais, la seule règle qui compte : un indice n'est pas une preuve. Deux personnes peuvent utiliser le même fournisseur d'accès. Plusieurs peuvent partager une adresse. Une adresse change. Un proxy sert à beaucoup de monde. Une façon d'écrire peut ressembler à une autre. Chaque élément pris seul ne désigne personne.

Je ne prétendrai pas que je l'appliquais correctement à 15 ou 16 ans. J'ai sanctionné trop vite, en confondant une impression avec une conclusion, et je me suis trompé sur des gens qui n'avaient rien fait. C'est en me trompant, et en devant l'assumer devant le salon, que la règle est devenue quelque chose que j'applique plutôt qu'une phrase que je récite.

(Neuf mois après ce billet, j'ai repris ce raisonnement indice par indice, sur le réseau que je gère aujourd'hui : Reconnaître quelqu'un qui revient.)

Modérer, ce n'était pas seulement bannir

IRC m'a appris très tôt une chose qui n'a pas changé : derrière un écran et un pseudonyme, certaines personnes adoptent des comportements qu'elles n'auraient jamais eus en face à face. Le pseudonymat était souvent positif, puisqu'il permettait à des gens timides de participer et de demander de l'aide sans craindre le regard des autres. Il libérait aussi les insultes, le flood, le harcèlement, et la multiplication des pseudos pour contourner une sanction.

Une communauté en ligne ne s'autorégule pas toute seule. Il fallait fixer des règles, les expliquer, et surtout les appliquer de façon cohérente : ce dernier point était le plus difficile. Bannir quelqu'un qui nous énervait était facile ; décider si son comportement justifiait réellement une sanction était une autre affaire. Il fallait aussi choisir à qui donner des droits, parfois les retirer, arbitrer les désaccords dans l'équipe — le tout en étant nous-mêmes très jeunes.

Les clones, les proxies, et le jour où les logs ont rempli le disque

Un autre sport très répandu à l'époque : les attaques de clones. Quelqu'un lançait un grand nombre de connexions vers le réseau, souvent à travers des proxies, pour perturber un salon ou saturer les serveurs. On bannissait une adresse, une autre arrivait ; on bloquait un proxy, dix autres étaient utilisés ; on ajoutait une protection, et quelques jours plus tard quelqu'un trouvait comment la contourner. D'où les limites de connexions, les règles au niveau de l'IRCd, les contrôles sur les proxies, avec un équilibre qui n'a pas changé depuis : bloquer énormément de monde est facile, le difficile est de bloquer les comportements abusifs sans empêcher les utilisateurs légitimes de se connecter. (Note ajoutée en 2026 : cet équilibre a depuis mérité un billet à lui seul, avec les mécanismes que j'utilise aujourd'hui : Protéger un réseau de chat sans le rendre invivable.)

Je me souviens en particulier d'une attaque par proxies qui a généré assez de logs pour remplir tout le disque du serveur dédié. Quand un disque Linux atteint 100 %, plus rien ne s'écrit correctement : des services tombent, d'autres ne redémarrent plus, et les logs eux-mêmes deviennent un problème. L'hébergeur m'a contacté avec un message simple : si cela se reproduisait et qu'une intervention de leur part était nécessaire, elle me serait facturée. Avec des moyens d'étudiant et un serveur dédié qui représentait déjà une dépense importante, ça m'a fait réfléchir.

J'ai donc cherché. Pourquoi les logs avaient-ils grossi si vite, comment mettre en place une rotation correcte, comment éviter qu'un seul fichier remplisse une partition, comment limiter certaines connexions, comment éviter qu'une attaque externe provoque une panne simplement en générant assez de logs ? Personne ne m'avait annoncé que j'allais apprendre la rotation des logs et les conséquences d'une saturation disque. Le problème est arrivé, il fallait le résoudre, et c'est probablement ce qui m'a le plus appris.

Ce que c'était devenu, sans que je le sache

Cette période était en réalité ma première confrontation avec ce qu'on appellerait aujourd'hui la supervision, la gestion d'incidents, la détection de comportements anormaux, le durcissement d'un serveur. Je n'appelais pas cela comme ça : je voulais simplement que mon réseau IRC fonctionne. Mais les questions qu'on se posait déjà sont exactement celles d'aujourd'hui. Cette connexion est-elle normale ? Pourquoi cette adresse génère-t-elle autant de trafic ? Est-ce le même utilisateur qui revient, un proxy, un clone, un utilisateur légitime ? Est-ce que je bloque cette adresse ou une plage entière, et combien de gens innocents est-ce que je touche ? Que disent les logs, quelle est la chronologie ? Très artisanal, très imparfait, et terriblement formateur.

Le réseau était accessible sur http://www.espace-irc.org, ou directement via irc.espace-irc.org.

EDIT

Quelques années plus tard, Espace-IRC a fermé ses portes et le projet n'existe plus. CService, X, les Eggdrop, #Quizz, les shells, les PID, les attaques de clones, les nuits à chercher pourquoi un serveur ne voulait plus démarrer : tout cela appartient à une autre époque d'Internet, où l'on apprenait beaucoup en cassant les choses, et où une communauté de quelques centaines de personnes pouvait constituer un véritable petit monde.

Ce qui est resté, ce sont les heures passées dessus, les rencontres, les erreurs, et ce que ce projet m'a appris. Il aura été mon laboratoire de développement, mon premier vrai environnement d'administration système, mon terrain d'apprentissage de la sécurité et de la gestion de communauté. Et quelque chose que je ne m'attendais pas à apprendre derrière un terminal : qu'une adresse IP n'identifie pas une personne, qu'un pseudonyme peut en cacher dix autres, et qu'avant de sanctionner quelqu'un, il vaut mieux être certain de ce qu'on avance.

Je ne l'aurais évidemment jamais appelé du recoupement d'informations. Je voulais juste savoir si le nouveau venu sur #Accueil était vraiment un nouveau venu.