Atheme vs Anope : quel framework de services IRC choisir

En 1999, quand j'ai monté mon premier réseau IRC avec deux serveurs UnrealIRCd, la question des services ne se posait pas — tout le monde installait Epona ou DayDream. En 2024, le choix se résume à deux projets sérieux : Atheme et Anope. Les deux font le travail, mais ils le font différemment. Voici un comparatif basé sur mon expérience d'opérateur, pas sur des fiches marketing.

Les services IRC : pourquoi c'est indispensable

Un IRCd seul ne gère pas l'enregistrement des pseudos ni la propriété des canaux. Sans services, n'importe qui peut prendre votre nick quand vous n'êtes pas connecté, et les canaux disparaissent quand le dernier utilisateur part. Les services IRC résolvent ce problème en offrant :

NickServ — Enregistrement et protection des pseudonymes. Authentification par mot de passe ou certificat TLS.
ChanServ — Enregistrement des canaux, gestion des listes d'accès (flags), modes persistants.
MemoServ — Messages offline entre utilisateurs enregistrés.
OperServ — Outils d'administration réseau (akill, jupe, stats).
BotServ — Bots de canal gérés par les services (gardiens de canal).
HostServ — Cloaks personnalisés (vhosts) pour masquer les hostnames.

Atheme et Anope implémentent tous ces services, mais avec des différences d'architecture, de syntaxe et de fonctionnalités avancées.

Historique rapide : de NickServ à aujourd'hui

L'histoire des services IRC est un arbre généalogique touffu. La lignée simplifiée :

EsperNet Services (1996)
  └── Epona (1999)
       └── Anope 1.x (2003)
            └── Anope 2.x (2014) ← réécriture C++

IRC Services (Andrew Church, 1996)
  └── Blitzed Services
       └── Shrike (2003)
            └── Atheme 1.x (2005)
                 └── Atheme 7.x (actuel)

Atheme est né comme une réécriture propre, pensée pour la modularité. Anope 2.x a fait sa propre réécriture depuis zéro en C++ pour corriger les dettes techniques d'Anope 1.x.

Atheme : architecture et philosophie

Atheme est écrit en C (pas C++). Son architecture repose sur un noyau minimal et des modules qui étendent chaque fonctionnalité. NickServ, ChanServ, etc. sont eux-mêmes des modules.

Compilation depuis les sources :

git clone https://github.com/atheme/atheme.git
cd atheme
git submodule update --init
./configure --prefix=/opt/atheme \
  --with-protocol=unreal4 \
  --enable-large-net
make -j$(nproc)
make install

L'option --with-protocol= est le choix du module de liaison avec votre IRCd. Les protocoles supportés incluent : unreal4, inspircd, charybdis, ratbox, ngircd, et d'autres.

La configuration d'Atheme se fait dans atheme.conf :

serverinfo {
    name = "services.example.net";
    desc = "IRC Services";
    numeric = "00A";
    recontime = 10;
    netname = "MonReseau";
};

uplink "irc.example.net" {
    host = "127.0.0.1";
    port = 7000;
    send_password = "linkpass";
    receive_password = "linkpass";
};

/* Modules NickServ */
loadmodule "modules/nickserv/main";
loadmodule "modules/nickserv/identify";
loadmodule "modules/nickserv/register";
loadmodule "modules/nickserv/set";
loadmodule "modules/nickserv/cert";
loadmodule "modules/nickserv/enforce";

/* Modules ChanServ */
loadmodule "modules/chanserv/main";
loadmodule "modules/chanserv/flags";
loadmodule "modules/chanserv/register";
loadmodule "modules/chanserv/set";
loadmodule "modules/chanserv/akick";

/* Modules OperServ */
loadmodule "modules/operserv/main";
loadmodule "modules/operserv/akill";
loadmodule "modules/operserv/jupe";

Le système de flags d'Atheme est une de ses forces. Chaque permission sur un canal est un flag granulaire :

/msg ChanServ FLAGS #canal Marco +votsriRfA

# Signification :
# +v = voice
# +o = op
# +t = modifier le topic
# +s = utiliser SET
# +r = supprimer des flags (limité)
# +i = inviter
# +R = récupération de canal
# +f = modifier les flags d'autres
# +A = accès fondateur

Anope : architecture et philosophie

Anope 2.x est écrit en C++. L'architecture est également modulaire, mais avec une approche différente : le noyau est plus riche que celui d'Atheme, et certaines fonctionnalités sont intégrées plutôt que modulaires.

Compilation :

git clone https://github.com/anope/anope.git
cd anope
mkdir build && cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/opt/anope \
  -DINSTDIR=/opt/anope
make -j$(nproc)
make install

Anope utilise CMake, ce qui facilite la compilation sur différentes plateformes. Les modules sont activés/désactivés dans modules.conf.

Configuration de base (services.conf) :

define {
    name = "services.host"
    value = "services.example.net"
}

uplink {
    host = "127.0.0.1"
    port = 7000
    password = "linkpass"
}

serverinfo {
    name = "services.example.net"
    description = "IRC Services"
    id = "00A"
}

module {
    name = "unreal4"
}

module {
    name = "ns_register"
}
module {
    name = "ns_identify"
}
module {
    name = "ns_set"
}
module {
    name = "cs_register"
}
module {
    name = "cs_access"
}
module {
    name = "cs_set"
}
module {
    name = "os_akill"
}

Le système d'accès d'Anope utilise traditionnellement des niveaux numérotés :

/msg ChanServ ACCESS #canal ADD Marco 10

# Niveaux par défaut :
# 3  = Auto-Voice
# 5  = Auto-Op
# 7  = Auto-Protect (halfop)
# 10 = Fondateur / Full Access

# Anope 2.x supporte aussi les flags style XOP :
/msg ChanServ VOP #canal ADD Marco   # Voice
/msg ChanServ AOP #canal ADD Marco   # Op
/msg ChanServ SOP #canal ADD Marco   # Super-Op

Anope 2.x a aussi ajouté le support des flags granulaires similaires à Atheme, via le module cs_flags. Mais l'héritage des niveaux numérotés reste la méthode la plus documentée et utilisée dans la communauté Anope.

Comparatif technique détaillé

┌──────────────────────┬──────────────────┬──────────────────┐
│ Critère              │ Atheme 7.x       │ Anope 2.x        │
├──────────────────────┼──────────────────┼──────────────────┤
│ Langage              │ C                │ C++              │
│ Build system         │ autotools        │ CMake            │
│ Accès canaux         │ Flags (granulaire)│ Niveaux + Flags  │
│ SASL                 │ Natif            │ Module           │
│ Base de données      │ Flatfile/OpenSDB │ Flatfile/SQL     │
│ SQL support          │ Limité           │ MySQL/SQLite     │
│ API HTTP/JSON        │ XMLRPC (module)  │ Module XMLRPC    │
│ Protocoles IRCd      │ ~12              │ ~15              │
│ CertFP auth          │ Natif            │ Module           │
│ MemoServ             │ Oui              │ Oui              │
│ BotServ              │ Non (via Bots)   │ Oui              │
│ HostServ             │ Oui              │ Oui              │
│ GameServ             │ Oui (module)     │ Non standard     │
│ RAM (1000 comptes)   │ ~15-25 Mo        │ ~20-35 Mo        │
│ Documentation        │ Wiki GitHub      │ Wiki dédié       │
│ Communauté           │ Libera Chat      │ Anope.org        │
└──────────────────────┴──────────────────┴──────────────────┘

Base de données. Atheme stocke par défaut dans un fichier plat (OpenSDB). Anope 2.x offre un support SQL natif — MySQL, PostgreSQL et SQLite. Si vous voulez interroger les données des services depuis une application web, Anope simplifie la tâche.

SASL. Les deux supportent SASL pour l'authentification avant la connexion complète. Atheme l'intègre nativement avec le module saslserv/main. Anope le fournit via un module séparé. En pratique, les deux fonctionnent bien.

Compatibilité IRCd. Les deux supportent les IRCd majeurs (UnrealIRCd, InspIRCd, Charybdis). Anope a un léger avantage en nombre de protocoles supportés, notamment pour des IRCd moins courants. Vérifiez que votre IRCd spécifique est dans la liste avant de choisir.

Migrer de l'un à l'autre

La migration d'Anope vers Atheme (ou inversement) implique la conversion de la base de données. Atheme fournit un outil dbverify et des scripts de conversion pour certains formats. Anope dispose de modules d'import dans son arbre source.

# Atheme : importer une base Anope 1.x
# (les scripts varient selon les versions)
./contrib/anope2atheme.pl < anope.db > atheme.db

# Anope 2.x : importer depuis un dump SQL
# Utilisez le module db_import correspondant

La méthode la plus sûre reste l'export/import des données critiques via des scripts personnalisés : comptes NickServ (nick + hash + email), canaux ChanServ (nom + fondateur + flags), et akills OperServ. Les MemoServ et autres données secondaires peuvent être sacrifiées si la migration automatique échoue.

J'ai fait cette migration deux fois en production. Les deux fois, j'ai perdu quelques heures à corriger des problèmes de formatage dans les flags de canaux. Prévoyez une fenêtre de maintenance d'au moins 2-3 heures, et communiquez à vos utilisateurs qu'ils devront peut-être ré-identifier leur nick après la migration.

Mon verdict après 20 ans de pratique

Il n'y a pas de mauvais choix entre Atheme et Anope — les deux sont matures et fiables. Mon critère de décision principal :

Choisissez Atheme si : vous voulez un système de flags granulaire natif, vous utilisez Charybdis ou Solanum (le combo naturel), vous préférez une empreinte mémoire minimale, ou vous contribuez à un réseau qui l'utilise déjà (Libera Chat utilise Atheme).

Choisissez Anope si : vous avez besoin d'un backend SQL pour interroger les données depuis une application web, vos utilisateurs sont habitués aux niveaux d'accès numérotés, vous utilisez UnrealIRCd (l'intégration est historiquement excellente), ou vous voulez BotServ intégré.

Personnellement, j'utilise Atheme sur mes réseaux depuis 2008. Le système de flags correspond mieux à ma façon de gérer les permissions. Mais j'ai administré des réseaux sous Anope sans problème. Le choix technique est moins déterminant que la qualité de votre configuration et de votre maintenance.