Article publié initialement en 2007 sur fafchamps.be — réécrit, enrichi et complété en janvier 2025 avec le recul des années.
Réseau IRC Francophone.
Espace-IRC était un réseau qui avait pour fonction d'allier à la fois un espace d'échange, de communication, d'entraide et de conseils entre ses internautes.
Les spationautes étaient les utilisateurs connectés.
Et l'ensemble de ces éléments constituait l'espace : d'où l'origine du nom du serveur Espace-IRC.
Mais au fait...
IRC, c'était quoi ?
IRC signifie Internet Relay Chat.
À une époque où Facebook n'existait pas encore vraiment, où MSN Messenger régnait sur les discussions privées et où Discord était encore très, très loin d'exister, IRC permettait déjà à des milliers de personnes de discuter ensemble en temps réel.
On se connectait à un réseau IRC, puis on rejoignait des salons, appelés des channels, généralement reconnaissables à leur #.
Par exemple :
#belgique
#informatique
#aide
#espace-irc
Chaque réseau possédait ses propres serveurs, ses propres règles, ses opérateurs, ses services et surtout sa communauté.
Pour se connecter, il fallait généralement utiliser un logiciel comme mIRC, XChat, irssi ou encore différents clients web.
On indiquait l'adresse du serveur, un pseudo et hop...
Bienvenue sur IRC :-)
Dans notre cas :
irc.espace-irc.org
derrière lequel se trouvaient plusieurs serveurs reliés entre eux afin de former le réseau Espace-IRC.
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.
... étaient les valeurs clés d'Espace-IRC.
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.
Mais Espace-IRC, pour moi, c'est aussi quelque chose d'un peu plus personnel.
J'ai commencé à toucher à tout cela lorsque j'avais environ 14 ans.
Et avec le recul...
C'est probablement une des choses qui m'a fait apprendre le plus en informatique.
Évidemment, au début, je faisais tout mal.
Mais vraiment tout :-)
Je modifiais des fichiers de configuration sans forcément comprendre chaque ligne.
Je cassais des choses.
Je recommençais.
Je cherchais pourquoi cela ne fonctionnait plus.
Je demandais de l'aide.
Puis je recommençais encore.
Et petit à petit...
J'ai appris.
Apprendre sans vraiment savoir qu'on apprenait
J'ai appris à administrer un serveur Linux.
J'ai appris que quelques lignes dans un fichier texte pouvaient complètement changer le comportement d'un programme.
J'ai appris à compiler des logiciels, à lire des logs, à comprendre les processus, les ports, les connexions réseau, les permissions, les utilisateurs...
J'ai aussi commencé à développer. D'abord quelques petits scripts. Puis des choses de plus en plus complexes.
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.
Et forcément...
Quand quelque chose ne fonctionnait plus, il fallait trouver pourquoi.
Google existait déjà, bien sûr, mais on trouvait aussi beaucoup de réponses sur des forums, des mailing-lists, des documentations parfois plus ou moins bien écrites... et surtout auprès d'autres passionnés qui avaient probablement cassé exactement la même chose quelques semaines avant vous :-)
IRCu, CService et le fameux X
Au début, nous étions partis sur une architecture basée sur IRCu avec CService.
Et surtout avec le célèbre X.
Pour ceux qui ont connu IRC à cette époque, ce simple nom rappellera probablement quelques souvenirs :-)
X était le service chargé de gérer les salons.
Contrairement à d'autres systèmes où l'on retrouvait toute une série de services séparés avec des noms comme NickServ, ChanServ, MemoServ, OperServ, etc., CService avait une philosophie assez différente.
Et personnellement...
J'aimais beaucoup.
J'aimais surtout le principe de X présent directement sur le salon.
Il faisait partie du décor.
On voyait X dans la liste des utilisateurs et on savait qu'il était là pour gérer le channel, les accès, les opérateurs et toute une série de paramètres.
Cela donnait presque l'impression que chaque salon avait son propre petit gardien :-)
C'était aussi un système auquel je m'étais habitué et que j'aimais administrer.
Mais petit à petit, l'écosystème autour de CService s'est essoufflé.
Les développements se faisaient plus rares.
Certaines choses n'étaient plus vraiment maintenues.
La documentation vieillissait.
Les compatibilités devenaient parfois compliquées.
Et surtout, de moins en moins de monde utilisait encore cette architecture.
Il devenait donc de plus en plus difficile de faire évoluer le réseau autour de CService.
On a fini par devoir changer.
Et je dois bien l'avouer...
C'était un peu à contre-cœur.
Nous sommes alors passés vers une architecture plus classique avec un autre type d'**IRCd** et toute la série de services que beaucoup de réseaux utilisaient :
ChanServ
NickServ
MemoServ
OperServ
...
Techniquement, cela apportait un écosystème plus vivant et davantage de possibilités.
Mais j'avais toujours un petit faible pour CService.
Et surtout pour X.
Même si les nouveaux services proposaient parfois davantage de fonctionnalités, je trouvais que CService avait une certaine simplicité.
Une autre philosophie.
X était là.
Visible.
Présent sur le salon.
On savait qu'il gérait le channel.
Et quelque part, avec la disparition progressive de ce système, c'était aussi une petite époque d'IRC qui se terminait.
Et puis... les Eggdrop :-)
Impossible de parler d'IRC à cette époque sans parler des Eggdrop.
Un Eggdrop, c'était un bot IRC que l'on installait généralement sur un shell ou sur son propre serveur.
Et évidemment...
Dès qu'on avait un réseau IRC, il fallait des bots :-)
On pouvait leur ajouter des scripts, très souvent en Tcl, afin de leur faire faire à peu près tout ce qu'on voulait.
Gestion d'un salon.
Protection contre le flood.
Statistiques.
Commandes diverses.
Animations.
Jeux.
Et c'est là qu'apparaissaient les fameux salons :
#Quizz
#Motus
#Pendu
Des salons entièrement consacrés à des petits jeux pilotés par des bots.
Sur #Quizz, le bot posait des questions et comptabilisait les bonnes réponses et les scores.
Sur #Motus, il fallait retrouver un mot.
Et sur #Pendu...
Inutile de faire un dessin :-)
Cela paraît assez simple aujourd'hui.
Mais à cette époque, ce genre de salon pouvait réunir pas mal de monde et créer une véritable petite communauté.
On finissait par reconnaître les pseudos.
On revenait le lendemain pour battre son score.
On discutait entre deux questions.
Et parfois, le jeu devenait presque secondaire par rapport aux discussions qui se déroulaient autour.
Techniquement, c'était encore une excellente excuse pour apprendre.
Installer un Eggdrop.
Le compiler.
Le configurer.
Le connecter au bon serveur.
Modifier son fichier de configuration.
Installer un script Tcl.
Changer deux lignes.
Tout casser.
Chercher pendant une heure pourquoi le bot ne voulait plus démarrer.
Et finalement découvrir qu'on avait oublié une accolade quelque part.
Puis recommencer :-)
Bref...
Encore une école d'informatique sans vraiment savoir qu'on était en train d'apprendre l'informatique.
Les shells... et compter ses PID
Héberger tout cela à cette époque n'était pas aussi simple qu'aujourd'hui.
Le cloud n'existait pas vraiment pour le grand public et louer un serveur coûtait cher, particulièrement quand on était étudiant.
Au début, je louais ce qu'on appelait un shell.
En gros, on louait simplement un compte utilisateur sur un serveur Linux appartenant à quelqu'un d'autre.
Pas d'accès root.
Pas de serveur rien qu'à soi.
Juste un compte sur une machine.
Et certaines offres étaient assez particulières.
On payait notamment suivant le nombre de PID, autrement dit le nombre de processus que l'on pouvait faire tourner simultanément.
Un processus pour un serveur IRC.
Un autre pour un Eggdrop.
Encore un autre pour un service.
Et rapidement...
Il fallait compter :-)
Aujourd'hui, cela paraît presque étrange.
On lance des machines virtuelles, des conteneurs, des services dans le cloud...
À l'époque, un pauvre processus supplémentaire pouvait déjà rentrer dans la réflexion budgétaire :-)
Puis le serveur dédié
Ensuite sont arrivés les serveurs dédiés de plus en plus accessibles aux particuliers.
Avoir son propre serveur, avec un accès root complet, c'était évidemment le rêve.
La machine entière pour soi.
Pouvoir tout installer.
Tout configurer.
Tout modifier.
Et...
Tout casser aussi :-)
Mais les prix étaient encore particulièrement élevés pour un étudiant.
Il fallait donc optimiser.
Surveiller la mémoire.
Surveiller la charge CPU.
Surveiller l'espace disque.
Configurer correctement les services.
Faire les mises à jour.
Éviter de faire tomber la machine.
Et lorsque quelque chose ne redémarrait plus après une modification à deux heures du matin...
Il fallait trouver pourquoi.
Pas question de simplement supprimer la machine et d'en recréer une nouvelle en trente secondes.
Le serveur était là.
Il fallait le réparer :-)
Un réseau IRC, c'était aussi une communauté
Mais avec le recul, l'une des choses les plus intéressantes n'était probablement pas uniquement la technique.
Il y avait surtout les utilisateurs.
Car gérer un réseau IRC, c'était aussi gérer une communauté.
Des dizaines, parfois des centaines de personnes.
Des habitués.
Des nouveaux.
Des modérateurs.
Des opérateurs.
Des gens qui venaient simplement discuter.
Et évidemment...
Quelques-uns qui venaient uniquement pour mettre le bazar :-)
Sur IRC, pratiquement tout le monde utilisait un pseudonyme.
On ne savait pas nécessairement qui se trouvait réellement derrière DarkAngel, Neo, TitiDu59, LinuxMan ou n'importe quel autre pseudo choisi ce jour-là.
Et surtout...
Changer d'identité était extrêmement simple.
Quelques secondes suffisaient pour changer de pseudo.
Une personne bannie pouvait revenir avec un autre pseudo.
Une autre connexion.
Une autre adresse IP.
Un proxy.
Et parfois seulement quelques minutes après avoir été expulsée.
La modération ne consistait donc pas uniquement à taper une commande /ban et considérer que le problème était terminé.
Très souvent...
Le même utilisateur revenait.
Mais... c'est pas lui qu'on vient de bannir ?
Il fallait donc essayer de comprendre qui était qui.
Observer les habitudes.
La manière d'écrire.
Les expressions utilisées.
Les heures de connexion.
Les salons fréquentés.
Les pseudos successifs.
Les adresses IP ou les hosts lorsqu'ils étaient visibles.
Les changements de connexion.
Les comportements.
Et parfois, cinq minutes après avoir banni quelqu'un, un nouvel utilisateur arrivait.
Nouveau pseudo.
Nouvelle adresse.
Mais au bout de trois phrases...
On se disait :
« Mais... c'est pas lui qu'on vient de bannir ? »
Alors on regardait. On recoupait les informations dont on disposait.
Pas avec des outils extraordinaires.
Pas avec de grandes bases de données.
Pas avec les outils actuels.
Mais avec beaucoup d'observation.
Avec le recul, c'était presque une forme très primitive de ce que l'on appellerait aujourd'hui du recoupement d'informations numériques.
Évidemment, nous étions des adolescents et de jeunes adultes.
Nous ne faisions pas de cyberenquête au sens professionnel du terme :-)
Mais certains mécanismes étaient déjà là.
Un individu change d'identité.
Il utilise plusieurs pseudonymes.
Il change de connexion.
Il passe par un proxy.
Il revient après un bannissement.
Il essaie d'adopter un comportement légèrement différent.
Et de l'autre côté, il faut essayer de déterminer s'il s'agit réellement de la même personne ou simplement de quelqu'un qui lui ressemble.
Cela apprend assez vite une chose importante :
un indice n'est pas une preuve.
Deux personnes peuvent utiliser le même fournisseur d'accès. Plusieurs personnes peuvent partager une adresse IP. Une adresse peut changer. Un proxy peut être utilisé par de nombreuses personnes. Une manière d'écrire peut ressembler à celle d'un autre utilisateur.
Il fallait donc éviter de tirer trop rapidement des conclusions.
Bon...
À 15 ou 16 ans, je ne vais certainement pas prétendre que j'appliquais toujours parfaitement cette règle :-)
Il y a sûrement eu quelques bans un peu rapides.
Des erreurs d'appréciation.
Des décisions prises sur un coup de tête.
Des conflits qui auraient pu être mieux gérés.
Mais là encore...
C'est comme cela qu'on apprend.
Les comportements humains derrière un écran
IRC m'a également appris très tôt quelque chose qui reste toujours aussi vrai aujourd'hui.
Derrière un écran et un pseudonyme, certaines personnes peuvent adopter des comportements qu'elles n'auraient probablement jamais eus dans une conversation en face à face.
Le pseudonymat pouvait être extrêmement positif.
Il permettait à des personnes timides de discuter plus facilement.
De rencontrer du monde.
De participer à une communauté.
De demander de l'aide sans forcément avoir peur du regard des autres.
Mais il pouvait aussi libérer des comportements nettement moins sympathiques.
Insultes.
Provocations.
Flood.
Harcèlement.
Spam.
Acharnement contre un utilisateur.
Multiplication des pseudos.
Contournement des sanctions.
Petites guerres entre salons.
Conflits personnels qui finissaient par déborder sur les channels publics.
Finalement, les plateformes ont beaucoup changé depuis.
Mais les comportements humains...
Pas toujours autant :-)
Modérer, ce n'était pas juste bannir
Une communauté en ligne ne s'autorégule pas toujours toute seule.
Il fallait fixer des règles.
Les expliquer.
Les appliquer.
Essayer surtout de les appliquer de manière cohérente.
Et ce dernier point était probablement le plus compliqué.
Bannir quelqu'un parce qu'il nous énervait était facile. Décider si son comportement justifiait réellement une sanction était une autre histoire.
Il fallait aussi gérer les modérateurs.
Choisir les personnes auxquelles on donnait des droits.
Leur faire confiance.
Éviter les abus.
Retirer parfois les droits à quelqu'un.
Gérer les désaccords au sein même de l'équipe.
Et lorsqu'un opérateur estimait qu'un utilisateur devait être banni alors qu'un autre pensait le contraire...
Il fallait bien trancher.
Tout cela alors que nous étions parfois nous-mêmes très jeunes.
Avec le recul, c'était une expérience assez particulière.
On apprenait la technique.
Mais également la gestion de communauté.
La médiation.
La modération.
La confiance.
La responsabilité.
Et parfois simplement à reconnaître que l'on avait pris une mauvaise décision.
Les proxies, les clones et le jeu du chat et de la souris
Et puis il y avait un autre sport assez répandu à cette époque sur IRC :
les attaques de clones.
Le principe était assez simple.
Une personne lançait un grand nombre de connexions vers le réseau, généralement dans le but de perturber un salon ou de saturer les serveurs.
Et pour compliquer les choses, ces connexions pouvaient passer par différents proxies.
On bannissait une adresse.
Une autre arrivait.
On bloquait un proxy.
Dix autres étaient utilisés.
On ajoutait une protection.
Quelques jours plus tard, quelqu'un trouvait une manière de la contourner.
Et on recommençait :-)
C'était un véritable jeu du chat et de la souris.
Les clones pouvaient rejoindre un salon en masse.
Flooder.
Spammer.
Changer de pseudo.
Quitter.
Revenir.
Faire tomber certains services.
Ou simplement rendre un salon inutilisable pendant quelques minutes.
Il fallait donc mettre en place des protections.
Des limites de connexions.
Des bans.
Des scripts.
Des bots.
Des règles au niveau de l'IRCd.
Des contrôles sur les proxies.
Et toujours essayer de trouver un équilibre.
Car bloquer énormément de monde était facile.
Le plus difficile était de bloquer les comportements abusifs sans empêcher les utilisateurs légitimes de se connecter.
Encore une problématique qui n'a finalement pas tellement changé aujourd'hui.
Le jour où les logs ont rempli le serveur
Je me souviens d'ailleurs particulièrement d'une attaque passant par des proxies.
Elle avait généré une quantité énorme de logs sur mon serveur dédié.
Mais vraiment énorme.
Au point de remplir complètement le disque.
Et lorsque le disque d'un serveur Linux arrive à 100 %...
Disons que beaucoup de choses commencent rapidement à devenir amusantes :-)
Plus rien ne peut écrire correctement.
Certains services commencent à tomber.
D'autres ne redémarrent plus.
Les logs eux-mêmes peuvent poser problème.
Bref...
Le serveur n'était pas très heureux.
Le prestataire qui hébergeait la machine m'avait alors contacté.
En gros, le message était assez simple :
si cela se reproduisait et qu'une intervention de leur part était nécessaire, elle risquait de m'être facturée.
Aujourd'hui, cela peut sembler assez anodin.
Mais à l'époque...
Avec mes petits moyens d'étudiant et un serveur dédié qui représentait déjà une dépense importante, recevoir ce genre de message faisait réfléchir :-)
Je n'avais clairement pas envie de recevoir une facture supplémentaire parce qu'un idiot avait décidé de lancer quelques milliers de connexions vers mon serveur.
Alors j'ai cherché.
Pourquoi les logs avaient-ils grossi aussi rapidement ?
Comment mettre en place correctement une rotation des logs ?
Quelle taille maximale autoriser ?
Comment éviter qu'un simple fichier remplisse complètement une partition ?
Comment limiter certaines connexions ?
Comment identifier certains comportements anormaux ?
Comment automatiser certaines protections ?
Comment éviter qu'une attaque externe puisse provoquer une panne simplement en générant suffisamment de logs ?
Encore une fois...
Ce n'était absolument pas prévu au programme.
Personne ne m'avait dit :
« Aujourd'hui, tu vas apprendre à gérer la rotation de logs et les conséquences d'une saturation disque. »
Le problème était simplement arrivé.
Et il fallait le résoudre.
C'est probablement cela qui m'a fait apprendre le plus.
Mes premières notions de sécurité... sans le savoir
Avec le recul, toute cette période était probablement ma première vraie confrontation avec ce que l'on appellerait aujourd'hui plus facilement :
la sécurité informatique,
la supervision,
la gestion d'incidents,
la détection de comportements anormaux,
le durcissement d'un serveur,
et même, dans une certaine mesure, l'analyse et le recoupement de comportements numériques.
À l'époque, évidemment...
Je n'appelais pas cela comme ça.
Je voulais juste que mon réseau IRC fonctionne :-)
Mais finalement, on se posait déjà énormément de questions qui existent toujours 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 ?
Est-ce un proxy ?
Un clone ?
Un utilisateur légitime ?
Est-ce que je dois bloquer uniquement cette adresse ou une plage entière ?
Est-ce que je risque de bloquer des utilisateurs innocents ?
Qu'est-ce qui s'est passé avant l'incident ?
Que disent les logs ?
Quelle est la chronologie ?
Avec nos petits moyens et nos connaissances de l'époque, c'était déjà une sorte de petite enquête permanente.
Très artisanale.
Très imparfaite.
Mais terriblement formatrice.
Puis les VPS sont arrivés
Ensuite sont arrivés les VPS, les serveurs privés virtuels.
Et là, le monde de l'hébergement a commencé à changer.
Pour quelques euros, il devenait possible d'avoir sa propre petite machine virtuelle avec un accès administrateur complet.
Plus besoin de partager un shell et de compter chaque processus.
On pouvait avoir son propre environnement.
Installer ses services.
Redémarrer sa machine.
Tester.
Casser.
Réinstaller.
Les technologies de virtualisation ont évolué.
Les puissances ont augmenté.
Les prix ont diminué.
Puis les serveurs dédiés eux-mêmes se sont complètement démocratisés.
Ce qui représentait auparavant une dépense importante pour un étudiant est progressivement devenu accessible pour quelques dizaines d'euros par mois, voire beaucoup moins selon les besoins.
Et aujourd'hui...
On peut lancer une machine Linux quelque part dans le monde en quelques secondes.
Choisir sa quantité de mémoire.
Son CPU.
Son stockage.
Créer la machine.
La supprimer.
En créer une autre.
À l'époque, tout cela ressemblait davantage à de l'artisanat :-)
Et finalement...
C'est peut-être justement ce côté-là qui était intéressant.
Il fallait comprendre ce qu'on faisait.
Ou du moins...
Essayer de comprendre.
Bien plus qu'un simple serveur de discussion
Espace-IRC aura donc été pour moi bien plus qu'un simple serveur de discussion.
C'était un terrain de jeu.
Un laboratoire.
Une communauté.
Un endroit où j'ai appris l'administration système.
Le réseau.
Le développement.
La configuration de services.
Les fichiers texte.
Les logs.
Les processus Linux.
Les bases de données.
Les bots.
La sécurité.
Mais également quelque chose que je n'aurais probablement jamais pensé apprendre derrière un terminal Linux :
comprendre les comportements humains derrière un écran.
Observer.
Recouper.
Essayer de distinguer un comportement normal d'un comportement malveillant.
Comprendre qu'une adresse IP n'identifie pas forcément une personne.
Comprendre qu'un pseudonyme peut en cacher dix autres.
Comprendre qu'un utilisateur problématique peut changer d'identité sans forcément changer de comportement.
Comprendre qu'une information technique peut être un indice sans constituer une preuve.
Et surtout...
Comprendre qu'avant de sanctionner quelqu'un, il vaut mieux essayer d'être certain de ce que l'on avance.
Bien entendu, au départ, je faisais les choses un peu au hasard.
Puis, au fil des erreurs, des lectures, des essais, des attaques, des conflits et des rencontres avec d'autres passionnés...
J'ai appris les techniques.
Les outils.
Les stacks.
Et surtout la manière de chercher lorsqu'on ne sait pas encore.
Avec le recul...
Aujourd'hui, lorsque je repense à tout cela, je trouve assez amusant de voir le chemin parcouru.
À l'époque, je ne me disais évidemment pas :
« Tiens, je suis en train d'acquérir des compétences en administration système, développement, sécurité et analyse de comportements numériques. »
Non.
Je voulais simplement faire fonctionner mon serveur IRC :-)
Je voulais que X reste connecté.
Que l'IRCd ne plante pas.
Que les Eggdrop répondent.
Que #Quizz fonctionne.
Que les clones arrêtent de flooder.
Et que le petit nouveau arrivé cinq minutes après un ban soit réellement un petit nouveau...
et pas exactement la personne qu'on venait de bannir :-)
Mais quelque part, une bonne partie de ce que je fais encore aujourd'hui en informatique trouve probablement ses racines dans ces soirées passées à modifier des fichiers de configuration, compiler des programmes, relancer un Eggdrop, analyser des logs ou chercher pendant des heures pourquoi quelque chose ne faisait pas exactement ce que j'avais prévu.
À l'époque, Espace-IRC était accessible sur :
http://www.espace-irc.org
ou directement depuis un client IRC via :
irc.espace-irc.org
EDIT
Quelques années plus tard, Espace-IRC a finalement fermé ses portes et le projet n'existe plus aujourd'hui.
Une page s'est tournée.
CService.
X.
Les Eggdrop.
#Quizz.
#Motus.
#Pendu.
Les shells.
Les PID.
Les premiers serveurs dédiés.
Les attaques de clones.
Les proxies.
Les bans.
Les utilisateurs qui revenaient avec un autre pseudo.
Les nuits à chercher pourquoi un serveur ne voulait plus démarrer.
Tout cela appartient désormais à une autre époque d'Internet.
Une époque où l'on bricolait énormément.
Où l'on apprenait beaucoup en cassant les choses.
Où une communauté de quelques centaines de personnes pouvait représenter un véritable petit monde.
Mais toutes les heures passées dessus, les rencontres, les erreurs et surtout tout ce que ce projet m'aura permis d'apprendre...
Ça, c'est resté.
Avec le recul, ce petit réseau IRC aura été à la fois mon laboratoire de développement, mon premier véritable environnement d'administration système, mon terrain d'apprentissage de la sécurité informatique, de la gestion de communauté...
et probablement aussi ma toute première introduction, sans le savoir, à certains mécanismes que l'on retrouverait bien plus tard dans le monde de la cyberenquête.
À l'époque, évidemment, je n'aurais jamais appelé cela comme ça.
Je voulais juste savoir qui était encore revenu foutre le bordel sur #Accueil :-)
Et finalement...
Pour un projet commencé quand j'étais adolescent, ce n'est déjà pas si mal.