Les origines : Oulu, 1988
Internet Relay Chat naît à l'université d'Oulu, en Finlande, à l'été 1988. Son auteur, Jarkko Oikarinen — connu sous le pseudonyme WiZ — travaille alors comme administrateur système au département des sciences de l'information (OuluBox). Sa tâche initiale est modeste : améliorer un programme de bavardage en ligne nommé MUT (Multi-User Talk), déjà présent sur le BBS local.
Oikarinen s'inspire de plusieurs protocoles contemporains — Bitnet Relay Chat, les systèmes Unix talk et ntalk — mais choisit une approche radicalement différente : un protocole texte, orienté ligne, transporté sur TCP, avec une topologie fédérée de serveurs. Le premier serveur IRC entre en ligne sur tolsun.oulu.fi en août 1988. Dès novembre de la même année, le réseau s'étend à d'autres universités finlandaises, puis scandinaves.
La croissance est exponentielle. En 1990, IRC dépasse les 200 utilisateurs simultanés. Le réseau originel, plus tard baptisé EFnet (Eris Free Network), devient la colonne vertébrale d'une communauté internationale qui n'existait pas deux ans plus tôt. En 1991, lors de la tentative de coup d'État en Union soviétique, IRC est utilisé pour relayer des informations en temps réel depuis Moscou — premier précédent historique documenté d'un usage journalistique de la messagerie instantanée sur Internet.
La RFC 1459 et la formalisation du protocole
Pendant quatre ans, IRC se développe sans spécification formelle publiée. Les serveurs et clients interopèrent sur la base du code source de référence et d'une culture orale entre administrateurs. Ce n'est qu'en mai 1993 que la RFC 1459, rédigée par Jarkko Oikarinen et Darren Reed, est publiée par l'IETF. Ce document de 65 pages constitue la première — et longtemps unique — définition normative du protocole.
La RFC 1459 spécifie plusieurs éléments fondamentaux :
- Le format des messages IRC : une ligne de texte ASCII terminée par
\r\n, d'une longueur maximale de 512 octets (préfixe inclus). - La syntaxe des commandes :
NICK,USER,JOIN,PRIVMSG,NOTICE,MODE,KICK,QUIT, entre autres. - Le protocole serveur-à-serveur (S2S), qui permet la fédération des serveurs en arbre spanning.
- La hiérarchie des droits sur les canaux : opérateur (
@), voix (+), utilisateur normal. - Les modes de canal et d'utilisateur (flags de type
+i,+s,+k,+l…).
Un exemple de session d'enregistrement conforme à la RFC 1459, vu du côté client :
PASS motdepasse_optionnel
NICK MonPseudo
USER identd 0 * :Prénom Nom
:serveur.example.com 001 MonPseudo :Bienvenue sur le réseau IRC
:serveur.example.com 002 MonPseudo :Votre hôte est serveur.example.com, version 2.11.2
:serveur.example.com 003 MonPseudo :Ce serveur a été créé le Lun Jan 10 2000 à 12:00:00 UTC
:serveur.example.com 004 MonPseudo serveur.example.com 2.11.2 oiwszcrkfydnxbauglZCD biklmnopstveIrRcaqKzMQNHGCExuLa RFC introduit également la notion de numeric replies : des codes à trois chiffres (001 à 999) qui codifient les réponses du serveur. Cette convention, directement inspirée du protocole SMTP, est toujours en vigueur dans les implémentations modernes. Les codes 001 à 099 concernent la connexion initiale, 200 à 399 les réponses aux commandes, 400 à 599 les erreurs.
La RFC 1459 ne traite pas de chiffrement, d'authentification forte, ni de persistance des messages. Ces lacunes reflètent l'état de l'art de 1993 et généreront, trente ans plus tard, les principaux axes de travail d'IRCv3.
Architecture client-serveur et topologie en arbre
IRC repose sur une topologie en arbre couvrant (spanning tree) : chaque serveur du réseau est connecté à un ou plusieurs autres serveurs, sans cycle. Cette contrainte structurelle garantit qu'un message envoyé par un utilisateur est propagé une seule fois à travers chaque lien serveur-à-serveur — ce qui était crucial pour des liaisons intercontinentales à faible bande passante.
Le protocole serveur-à-serveur (S2S) repose sur les mêmes commandes texte que le protocole client-serveur (C2S), avec quelques extensions spécifiques. Lorsqu'un client envoie PRIVMSG #canal :message, le serveur local propage ce message à tous les serveurs voisins qui ont des utilisateurs dans ce canal, selon l'arbre de routage.
Client A ---[C2S]--- Serveur 1 ---[S2S]--- Serveur 2 ---[C2S]--- Client B
|
[S2S]
|
Serveur 3 ---[C2S]--- Client CCette architecture présente un défaut structurel fondamental : un netsplit — la rupture d'un lien S2S — divise le réseau en deux partitions indépendantes. Les utilisateurs présents dans les deux partitions voient les membres de l'autre partition se déconnecter simultanément, puis se reconnecter lors du netjoin. Pendant l'intervalle, les deux partitions peuvent élire des opérateurs de canal distincts pour un même canal, créant des conflits d'état à la reconnexion.
Ce problème des netsplits a occupé les développeurs IRC pendant des décennies. La RFC 2813 (2000), qui remplace la partie S2S de la RFC 1459, tente d'améliorer la gestion de ces situations sans résoudre le problème de fond, inhérent à l'absence de consensus distribué dans le protocole original.
Les guerres de serveurs et la fragmentation du réseau
La période 1993–1996 est marquée par des conflits internes au réseau EFnet qui aboutiront à la fragmentation durable de la communauté IRC mondiale. Ces conflits, souvent désignés sous le terme générique de guerres de serveurs, combinent des dimensions techniques, politiques et personnelles.
La première grande scission intervient en 1992–1993 autour d'un serveur controversé, eris.berkeley.edu, qui refusait d'appliquer certaines politiques réseau. Suite à son exclusion d'EFnet, ses administrateurs fondent Undernet en 1993. Undernet apporte plusieurs innovations techniques absentes de la RFC 1459 : les services de canal (ChanServ, NickServ) qui persistent les enregistrements de canaux et de pseudonymes entre sessions, et un protocole S2S amélioré (P10) conçu pour réduire la charge de synchronisation d'état.
En 1995, une nouvelle scission produit IRCnet, principalement européen, à partir d'un désaccord entre serveurs nord-américains et européens d'EFnet sur la politique d'accès. IRCnet adopte une philosophie délibérément minimaliste : pas de services de canal, pas d'enregistrement centralisé, ce qui le rapproche de l'esprit original de la RFC 1459.
En 1996, DALnet — déjà séparé d'EFnet depuis 1994 — développe son propre ensemble de services et adopte le démon ircd-dal, une dérivation d'ircd avec de nombreuses extensions propriétaires. C'est sur DALnet que s'inventent plusieurs conventions qui deviendront standard : les vhosts (hôtes virtuels masquant l'adresse IP réelle de l'utilisateur), les memo services, et une gestion plus fine des abus.
Ces scissions révèlent une tension fondamentale dans la conception d'IRC : le protocole original ne prévoit aucun mécanisme d'identité persistante. Un pseudonyme (nick) est une ressource volatile, obtenue en premier arrivé premier servi au moment de la connexion. L'absence de standard pour les services a conduit à des implémentations incompatibles entre réseaux, rendant toute réunification technique très difficile.
La scène française : Epiknet et les grands réseaux hexagonaux
La France développe une culture IRC distincte, liée à l'histoire particulière de l'accès à Internet dans l'Hexagone. L'arrivée du Minitel avait habitué une part de la population à la communication en ligne dès les années 1980, mais c'est l'ouverture commerciale d'Internet dans les années 1990 qui propulse IRC dans les usages grand public français.
Epiknet est le réseau IRC francophone qui marque le plus durablement la mémoire collective des internautes français. Fondé à la fin des années 1990, Epiknet se distingue par une architecture multi-serveurs distribuée sur le territoire national, une politique d'accès ouverte, et une communauté de développeurs actifs qui contribuent à des dérivations du démon ircd adaptées aux besoins locaux. À son apogée, Epiknet compte plusieurs milliers d'utilisateurs simultanés, répartis sur des centaines de canaux thématiques.
Techniquement, Epiknet utilise une variante du démon Bahamut (développé par DALnet), étendue par des patchs locaux. Les services sont assurés par Sorcery puis par des dérivés de Anope, la suite de services IRC open-source qui s'impose progressivement comme référence dans les années 2000.
Parmi les autres réseaux francophones notables :
- GalaxiNet : réseau à forte coloration jeu vidéo, actif dans les années 2000.
- OpenIRC : réseau généraliste avec une gouvernance décentralisée.
- irc.fr : fédération de serveurs francophones maintenant un annuaire de réseaux.
- Freenode (à partir de 2002) : bien que britannique à l'origine, Freenode héberge de nombreux canaux de projets open-source francophones.
La scène française contribue également à la culture IRC globale par ses bots. Le bot Eggdrop — écrit en C par Robey Pointer en 1993 — est massivement utilisé et francisé par des développeurs hexagonaux qui produisent des scripts TCL spécialisés : gestion de listes de diffusion, jeux textuels, interfaces vers des bases de données de films (Allocine) ou de musique (CDDB).
.log peut donner des résultats inattendus.
Évolutions post-RFC 1459 : IRCv3 et l'état actuel
La RFC 1459 est complétée en 2000 par deux documents : la RFC 2810 (architecture générale), la RFC 2811 (gestion des canaux), la RFC 2812 (protocole client) et la RFC 2813 (protocole serveur). Ces quatre RFC reformalisent le protocole sans le modifier en profondeur, et présentent des divergences avec les implémentations réelles qui s'étaient accumulées depuis 1993.
C'est le projet IRCv3, lancé informellement autour de 2010 et structuré en groupe de travail à partir de 2012, qui entreprend une modernisation sérieuse. IRCv3 fonctionne par extensions optionnelles (capabilities), négociées entre client et serveur lors de la connexion via la commande CAP. Cette approche préserve la compatibilité descendante : un client IRC des années 1990 peut toujours se connecter à un serveur moderne.
Les principales extensions IRCv3 incluent :
CAP LS 302 ← Demande la liste des capabilities supportées
:server CAP * LS : multi-prefix extended-join account-notify \
batch server-time message-tags sasl \
draft/chathistory
CAP REQ :sasl message-tags
CAP END- SASL (RFC 4616 dans IRC) : authentification forte, remplaçant l'envoi du mot de passe en clair via
PASS. - message-tags : métadonnées attachées aux messages (horodatage côté serveur, identifiant de message unique).
- server-time : horodatage des messages par le serveur, permettant une meilleure synchronisation des historiques.
- draft/chathistory : récupération de l'historique des messages après reconnexion — fonctionnalité absente du protocole original et longtemps simulée par les bouncers IRC.
- multi-prefix : affichage de plusieurs modes simultanés (opérateur et voix) dans les listes de membres.
- account-notify : notification des changements d'état d'authentification des utilisateurs.
Le transport TLS, absent de la RFC 1459, est désormais standard : la plupart des réseaux IRC majeurs exposent un port TLS (généralement 6697) en complément du port en clair historique (6667). Certains réseaux, comme Libera.Chat — fondé en 2021 après la controverse autour de Freenode — imposent TLS pour toutes les connexions.
L'implémentation de référence ircd originale de Jarkko Oikarinen a été remplacée par une multitude de démons distincts. En 2024, les plus déployés sont InspIRCd (modulaire, écrit en C++, très utilisé par les réseaux indépendants), UnrealIRCd (populaire dans les réseaux communautaires européens), et Ergo (anciennement Oragono, écrit en Go, conçu nativement pour IRCv3 avec persistance des messages).
Malgré la concurrence de Discord, Slack et Matrix, IRC conserve une base d'utilisateurs fidèle, principalement dans les communautés open-source, les cercles de sécurité informatique, et les projets techniques qui valorisent la légèreté du protocole et l'absence de données persistantes côté serveur par défaut.
Questions fréquentes
Quelle est la différence entre la RFC 1459 et les RFC 2810–2813 ?
La RFC 1459 (1993) est le document fondateur, rédigé par Jarkko Oikarinen et Darren Reed. Elle couvre l'ensemble du protocole en un seul document. Les RFC 2810 à 2813 (2000) constituent une refonte documentaire qui divise la spécification en quatre parties thématiques (architecture, canaux, protocole client, protocole serveur) et tente d'aligner la spécification sur les pratiques réelles accumulées depuis 1993. En pratique, les deux jeux de RFC coexistent : certaines fonctionnalités documentées uniquement dans la RFC 1459 restent implémentées, et les RFC 2000 elles-mêmes ne couvrent pas toutes les extensions développées entre-temps par les grands réseaux.
Pourquoi les nicks IRC sont-ils limités à 9 caractères dans la RFC 1459 ?
La RFC 1459 fixe la longueur maximale des pseudonymes à 9 caractères. Cette limitation est héritée des contraintes de mémoire et de bande passante de 1988 : les tables de routage des serveurs stockaient les informations par nick, et une limitation stricte réduisait la taille des structures de données. En pratique, la plupart des implémentations modernes ont étendu cette limite (IRCnet autorise 9 caractères par conformité historique, tandis que Freenode, Libera.Chat et la plupart des réseaux contemporains permettent 16 à 30 caractères). La RFC 2812 maintient la limite à 9 caractères dans sa définition formelle, tout en reconnaissant que les serveurs peuvent l'étendre.
Un bouncer IRC est-il toujours utile avec IRCv3 ?
Le bouncer IRC (BNC) — logiciel comme ZNC ou sbnc qui maintient une connexion permanente au réseau IRC pour le compte de l'utilisateur — répondait principalement à deux besoins : la persistance de présence (rester connecté même hors ligne) et la consultation de l'historique des messages manqués. L'extension IRCv3 draft/chathistory, déployée sur des réseaux comme Libera.Chat et Ergo, fournit nativement l'historique côté serveur. La persistance de présence, en revanche, reste une fonctionnalité que seul un bouncer ou un client web hébergé peut offrir sur les réseaux qui ne supportent pas l'extension away-notify combinée à une gestion de session côté serveur. Pour un usage sur un réseau IRCv3 complet comme Ergo, le bouncer est devenu optionnel. Sur EFnet ou IRCnet, il reste pertinent.
Quel est le lien entre IRC et les premiers vecteurs de diffusion de malwares ?
IRC a été l'un des premiers vecteurs de diffusion de logiciels malveillants, principalement via le mécanisme DCC (Direct Client-to-Client). Le DCC, défini informellement (il n'existe pas de RFC pour ce sous-protocole), permet des transferts de fichiers directs entre clients, contournant le serveur IRC. Des vers comme Melissa (1999) et de nombreux chevaux de Troie de la période 1998–2005 exploitaient des bots IRC pour recevoir des commandes depuis un canal de contrôle (IRC botnet). Cette utilisation a conduit de nombreux FAI à filtrer les ports IRC standards (6667) en sortie, contribuant à la marginalisation progressive du protocole dans le grand public. Les botnets modernes ont migré vers des protocoles HTTPS ou P2P, mais la structure de commande IRC est restée une référence architecturale dans la littérature sur les botnets.