De la cybersécurité (I’m back. Stronger.)

Enfin j’ai trouvé un peu de temps pour réparer tout mon bourbier.

En effet, depuis 2024, quand on accédait à mes sites wordpress, vous aviez ce message d’accueil fort charmant qui mentionnait un « incident technique ». J’avais dû fermer mes trois sites wordpress …

Pas des moindres. J’avais été piratée de partout ! Mon site d’urbex par exemple redirigeait vers une boutique en ligne. Et paf la cascade, mon site vitrine, mon blog et même un temps mon wiki sur mon jeu Minerland ! Un peu comme un jeu de dominos qu’on fait tomber petit à petit … de quoi être parano.

Il aura fallu attendre 2024 pour que ça se produise, en sachant que mes premiers sites perso remontent à 2000. Depuis, je me disais, tranquille, que je n’avais pas de raisons de me méfier ni de consolider mes iptables bien comme il le faut … voire faire l’impasse sur les mises à jour. L’erreur fatale. La cybersécurité est devenue lame de plus du développeur web qui doit apprendre de ses erreurs.

Intro sur la cybersécurité

En 2026, les petits sites web sont plus que jamais en première ligne.

Les attaques les plus courantes contre les petits sites sont silencieuses, opportunistes et automatisées. Elles défigurent un site, volent des données clients, ou utilisent le serveur pour héberger des contenus illicites, le tout à l’insu du propriétaire.

La grande nouveauté de 2026, c’est l’utilisation de l’IA par les attaquants. Les agents IA autonomes deviennent des outils courants de la cybercriminalité, capables de cartographier une attaque en quelques minutes et de générer des campagnes de phishing ciblées à grande échelle. Les campagnes de phishing générées par IA sont désormais quasiment indétectables — fini les fautes d’orthographe et les formulations bancales.

Plus de 90 % des piratages de sites WordPress exploitent des failles déjà corrigées dans une mise à jour que l’administrateur n’a pas appliquée. Le message est clair : mettre à jour, sécuriser ses accès, surveiller ses logs — ce n’est plus optionnel, même pour un petit blog perso.

Acte I — La découverte

Tout a commencé par un constat simple : mes sites WordPress ne répondaient plus correctement. En fouillant, j’ai découvert l’ampleur des dégâts. Les attaquants avaient réussi à s’introduire dans mes trois sites WordPress et ils s’étaient fait plaisir.

Leur spécialité : injecter du contenu. Des pages de spam, du phishing, et le pompon — un site de commerce en ligne complet, hébergé à mes frais sur mon propre serveur. Sympa.

En analysant les bases de données, j’ai retrouvé leurs traces partout. Dans la base d’amelieonline.net, un webshell — un script PHP qui permet de prendre le contrôle d’un serveur à distance — était planqué dans le fichier functions.php du thème. Du code obfusqué en base64 qui se connectait à des serveurs distants pour exécuter des commandes. Le plugin de sécurité All-In-One Security l’avait détecté et mis en quarantaine, mais le mal était fait.

Dans les fichiers du serveur, les bots avaient déposé des scripts PHP aux noms discrets : x.php, ha.php, gg.php… Des portes dérobées qui leur permettaient de revenir à volonté, même après un changement de mot de passe.

Acte II — Comment ils sont rentrés

La réponse est aussi simple que gênante : mon mot de passe wordpress était devenu trop faible. Ou alors ils se sont fait une joie de l’absence de certificat ssl …

Les bots qui parcourent internet 24h/24 testent des millions de combinaisons sur /wp-login.php et xmlrpc.php (une porte d’entrée WordPress souvent oubliée). Avec un mot de passe simple, il leur faut parfois quelques heures pour entrer.

Mais ce n’est pas tout. Mon serveur cumulait les facteurs aggravants. Ubuntu 18.04 en fin de vie depuis avril 2023, donc plus aucun correctif de sécurité. PHP 7.x, qui n’est plus maintenu depuis fin 2022. Pas de HTTPS — ce qui signifie que chaque fois que je me connectais à l’admin WordPress, mon identifiant et mon mot de passe transitaient en clair sur le réseau. Dans un café, à la gare, à l’hôtel, n’importe qui sur le même Wi-Fi pouvait les intercepter avec un simple outil comme Wireshark.

Et mon certificat SSL ? Expiré depuis des mois. J’avais payé cher pour un certificat classique, il avait expiré, et je n’avais jamais pris le temps de le renouveler. J’étais persuadée qu’il fallait racheter un certificat pour chaque nom de domaine. Trois domaines, trois certificats, une facture qui pique. En fait, non — mais j’y reviendrai.

Acte III — Le grand nettoyage

Le ménage a été méthodique. D’abord, les bases de données : analyser chaque dump SQL à la recherche de contenu injecté — du spam en chinois, en japonais, en cyrillique, des liens vers des boutiques frauduleuses, des webshells en quarantaine. Chaque site a été passé au peigne fin, table par table, grâce à l’aide de mon ami Claude, devenu mon nouveau formateur/secrétaire/IA couteau suisse.

Ensuite, les fichiers du serveur : traquer les scripts PHP malveillants dans les répertoires d’uploads (il ne devrait jamais y avoir de fichier PHP dans wp-content/uploads/), vérifier chaque thème, chaque plugin, identifier les fichiers modifiés récemment.

Et puis la grosse opération : migrer le serveur d’Ubuntu 18.04 vers une version maintenue. Trois sauts successifs — 18.04 vers 20.04, puis 22.04 — chacun avec son lot de surprises. PHP 7 vers PHP 8 a cassé plusieurs choses : des fonctions dépréciées, des syntaxes devenues invalides, des conflits de configuration entre l’ancien PHP-FPM et le nouveau module. À chaque étape, un site qui tombe, un diagnostic, une correction, on repart.

Acte IV — L’horreur des logs

C’est une fois le serveur remis d’aplomb que j’ai vraiment mesuré l’ampleur du problème. En regardant les logs d’authentification SSH :

Failed password for root from 179.111.150.107
Failed password for invalid user adurbex from 172.188.89.41
Failed password for invalid user amelayesbiophp from 59.51.98.254
Failed password for invalid user urbexmarseille from 187.191.48.4
Failed password for invalid user tonwebautableau from 121.78.158.30

Des dizaines de tentatives par heure. Et le plus flippant : les bots n’essayaient pas que des noms génériques comme « admin » ou « root ». Ils testaient adurbex, urbexmarseille, amelayesbiophp etc … — des identifiants dérivés de mes noms de domaines, de mon pseudo, de mes projets.

Quelqu’un — ou plutôt quelque chose — avait scanné mes sites, relevé tous les indices disponibles. Les noms d’auteur WordPress sont exposés par défaut via /?author=1 ou l’API REST (/wp-json/wp/v2/users). Les pages « à propos », les footers, les noms de domaine eux-mêmes : tout est découpé, recombiné, et testé automatiquement.

Les logs Apache racontaient la même histoire côté web : des scans massifs de wlwmanifest.xml (un fichier WordPress utilisé pour détecter les installations), des rafales de requêtes cherchant des webshells PHP à des noms comme x.php, ha.php, gg.php… Un bot a généré des dizaines de 404 en quelques millisecondes, balayant méthodiquement tous les noms de fichiers suspects.

En analysant les adresses IP, un inventaire géographique impressionnant : Brésil, Bulgarie, Chine, Corée du Sud, Russie, Vietnam, Pays-Bas, Ukraine, Singapour, Afrique du Sud… La plupart provenaient de datacenters ou de services cloud comme Microsoft Azure ou Alibaba Cloud. Et l’ironie : l’une des IP attaquantes appartenait à un serveur Kimsufi OVH — un serveur dédié comme le mien, probablement compromis et utilisé comme relais.

Ce ne sont pas de vrais humains derrière un écran. Ce sont des botnets — des réseaux de milliers de machines compromises qui scannent automatiquement toutes les IP du monde, 24 heures sur 24.

Acte V — Pourquoi mon petit serveur ?

C’est la question que je me suis posée. Mes sites ne contiennent rien de sensible. Mais ce n’est pas mes données qui intéressent les attaquants. C’est mon serveur lui-même : sa bande passante pour lancer des attaques vers d’autres cibles ou participer à des attaques DDoS, son processeur pour miner de la cryptomonnaie, son adresse IP pour héberger du phishing ou envoyer des millions de spams, et le fait qu’il tourne 24h/24 en faisant office d’outil gratuit.

Un serveur dédié compromis devient un soldat anonyme dans une armée de machines zombies. Et quand quelqu’un remonte la piste d’une attaque, c’est sur mon Kimsufi qu’il tombe — pas sur le vrai attaquant.

Acte VI — La fortification

La reconstruction s’est faite couche par couche.

Fail2ban, valeur sûre. J’avais fail2ban d’installé, mais sa configuration par défaut était une passoire : 10 minutes de bannissement après 5 échecs. Les bots attendaient tranquillement et revenaient. 4681 tentatives échouées au compteur, 491 IP bannies au total, mais zéro bannie à l’instant T. J’ai durci la config : 3 échecs en une heure, et c’est 24 heures de ban.

Mais le SSH n’était pas le seul front. J’ai ajouté des jails fail2ban pour chaque type d’attaque : les scans WordPress (wlwmanifest), les floods de 404 génériques, les tentatives de brute force sur DokuWiki, les scans de fichiers sensibles. Six jails au total, chacune avec ses propres seuils. Le port 22 quant à lui, exit !

Iptables pour les récidivistes. Pour les IP les plus agressives — celles avec 60, 80, 90 tentatives au compteur — j’ai écrit un script qui les bloque définitivement dans iptables. Ces adresses ne peuvent plus du tout communiquer avec mon serveur, sur aucun port, par aucun protocole.

CrowdSec, la défense collaborative. En plus de fail2ban, j’ai installé CrowdSec — un outil communautaire où les serveurs partagent les IP malveillantes. Quand une IP attaque un serveur du réseau, elle est signalée et bloquée sur tous les autres.

HTTPS avec Let’s Encrypt. Fini les certificats payants. Certbot et Let’s Encrypt m’ont permis de sécuriser mes trois domaines en une seule commande, gratuitement, avec renouvellement automatique tous les 90 jours. Plus jamais de certificat expiré oublié dans un coin. Un timer systemd vérifie deux fois par jour si un renouvellement est nécessaire.

Le blocage de xmlrpc.php. Ce fichier WordPress est un vecteur classique de brute force. Bloqué.

Les permissions qui vont bien. 644 pour les fichiers, 755 pour wp-content.

La mise à jour de tout. Ubuntu à jour, PHP à jour, WordPress core à jour, plugins à jour, thèmes à jour. Chaque composant obsolète est une porte ouverte.

Ce que j’ai appris

Cette aventure m’a enseigné des leçons que j’aurais aimé connaître plus tôt.

Un mot de passe faible est une porte ouverte. C’est banal à dire, mais c’est la cause numéro un des compromissions WordPress. Aujourd’hui, 20 caractères minimum, générés aléatoirement, et uniques pour chaque site.

Le HTTPS n’est pas optionnel. Même pour un blog perso, chaque page de connexion sans HTTPS est une invitation au vol d’identifiants. Et avec Let’s Encrypt, il n’y a plus aucune excuse financière.

La sécurité par défaut n’existe pas. Fail2ban installé avec sa config d’usine, c’est presque comme s’il n’était pas là. Il faut prendre le temps de configurer chaque outil correctement.

Tout serveur exposé sur internet est une cible. Ce n’est pas une question de « si », mais de « quand ». Les bots ne dorment jamais, et ils sont plus malins qu’on ne le croit — ils analysent vos sites pour en extraire des identifiants potentiels. Les premières tentatives de brute force arrivent dans les minutes qui suivent la mise en ligne d’un serveur.

Un système non maintenu est un système compromis. Ubuntu 18.04 en fin de vie + PHP 7 abandonné = zéro correctif de sécurité depuis des mois. Autant laisser la porte grande ouverte.

Vérifiez vos logs régulièrement. Sans cette habitude, je n’aurais jamais su que mon serveur subissait des milliers de tentatives d’intrusion quotidiennes.

Migration du serveur Minetest (en PostgreSQL !)

Le moment était venu. Le serveur qui hébergeait jusqu’alors mon jeu Minetest « Amelaye in Minerland » commençait à souffrir, tant la base de données tendait à être énorme (33 Go, vous voyez un peu …). Difficile de dire aux joueurs d’arrêter d’explorer, de creuser, bref de tirer la plus-value du monde qu’ils aimaient modifier. D’autant plus que j’avais bien envie d’installer de nouveaux mods. Et puis surtout, le serveur qui héberge le jeu est une machine perso, qui sert également pour pas mal de choses.

Alors j’ai décidé d’une part de louer un nouveau serveur Kimsufi, une machine assez robuste pour cet usage exclusif, et d’autre part, de migrer la base de données Minetest, à l’origine en SQLite vers PostgreSQL. Pourquoi ? Parce que si on regarde bien, c’est plutôt vivement recommandé.

Documentation des backends Minetest

Tout est dit, ne plus rester sous SQLite implique de limiter les lags, et également de réduire les risques de corruption de la base de données (ma plus grande crainte !). Et ça, c’est tout bénéf’ !

Allons-y. Ma nouvelle machine arrive toute fraiche avec la dernière version d’Ubuntu. Déjà, je m’enlève de la tête qu’on n’installe pas Minetest avec un simple apt-get dans mon cas de figure, ce serait trop simple. Car la version déjà compilée ne supporte pas PostgreSQL. Il va falloir compiler les sources. Je relève le défi.

On prépare le terrain

J’installe la matière première, les librairies qui me seront utiles …

sudo apt install wget postgresql 
postgresql-contrib g++ make libc6-dev libirrlicht-dev cmake 
libbz2-dev libpng-dev libjpeg-dev libxxf86vm-dev libgl1-mesa-dev 
libsqlite3-dev libogg-dev libvorbis-dev libopenal-dev 
libcurl4-gnutls-dev libfreetype6-dev zlib1g-dev libgmp-dev 
libjsoncpp-dev libpq-dev libpqtypes-dev doxygen 
libluajit-5.1-dev libspatialindex-dev libncurses-dev

Comme ça, c’est fait. Je me crée un utilisateur minetest :

sudo useradd -mU minetest

Et je me logue sur le compte, comme ça :

sudo -i -u minetest

Puis je télécharge les sources de Minetest. Important : téléchargez la DERNIERE VERSION stable qui correspond à celle que vous utilisiez, sinon ça peut engendrer des bugs. Dans mon cas, c’est la 5.5.1 :

git clone https://github.com/minetest/minetest.git
git checkout 5.5.1
cd minetest/games/
git clone https://github.com/minetest/minetest_game.git
git checkout 5.5.1
cd ..

Ok, c’est facile. Maintenant, je passe à la pré-compilation (et je croise les doigts) :

cmake . -DRUN_IN_PLACE=TRUE 
-DBUILD_CLIENT=FALSE 
-DBUILD_SERVER=TRUE 
-DCMAKE_BUILD_TYPE=Release 
-DBUILD_UNITTESTS=FALSE 
-DENABLE_POSTGRESQL=TRUE 
-DVERSION_EXTRA=postgresql 
-DPostgreSQL_INCLUDE_DIR=/usr/include/postgresql 
-DPostgreSQL_TYPE_INCLUDE_DIR=/usr/include/postgresql 
-DPostgreSQL_LIBRARY=/usr/lib/x86_64-linux-gnu/libpq.so

Et là … ça plante.

CMake Error at CMakeLists.txt:110 (message):
IrrlichtMt headers are required to build the server, but none found.
The Minetest team has forked Irrlicht to make their own customizations.
It can be found here: https://github.com/minetest/irrlicht
For example use: 
git clone --depth=1 https://github.com/minetest/irrlicht lib/irrlichtmt

On sent bien les origines allemandes du jeu, tiens. Il a besoin d’une librairie « Irrlicht » pour pouvoir compiler. Mais pourtant, je l’ai apt-getté, celui-là … bon, on va là aussi compiler les sources avec l’adresse GIT qui est fournie alors.

Installation d’Irrlicht

Donc, on récupère Irrlicht dans le répertoire minetest pour pouvoir faire en sorte que l’include dans les sources trouve ses petits. Il est très important d’installer Irrlicht dans lib/irrlichtmt

git clone --depth=1 https://github.com/minetest/irrlicht lib/irrlichtmt

On va dans le répertoire et on compile :

cd lib/irrlichtmt
cmake . -DBUILD_SHARED_LIBS=OFF
make -j$(nproc)

Normalement on s’en sort avec juste quelques warnings.

Compilation réussie !

Je reviens deux répertoires en arrière, relance la pré-compilation de Minetest, et … mince encore des erreurs.

CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Zstd (missing: ZSTD_LIBRARY ZSTD_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
cmake/Modules/FindZstd.cmake:24 (find_package_handle_standard_args)
src/CMakeLists.txt:228 (find_package)

Bon, certainement une lib qui manque, ce ne sera pas la mer à boire. Je reviens dans mon compte utilisateur et je fais un petit :

sudo apt install -y libzstd-dev

Je reviens dans mon compte minetest et mon répertoire minetest, je relance la pré-compilation. Cool, ça a marché. Maintenant je lance la compilation :

make -j$(nproc)

Okay, le terminal m’indique que minetestserver a été compilé avec succès.

Je lance le binaire :

cd ..
./minetest/bin/minetestserver

Et je lance mon jeu depuis Minetest en spécifiant l’adresse IP du serveur. Tout se lance, génial. J’éteins le serveur, le plus complexe reste à venir.

Configuration du serveur PostgreSQL

Je relance par sécurité le service :

sudo systemctl restart postgresql.service

Et puis je lance mon interface PostgreSQL

sudo -u postgres psql 
CREATE USER monuser WITH PASSWORD '*****';
CREATE DATABASE adventure OWNER monuser;
GRANT ALL PRIVILEGES ON DATABASE adventure TO monuser;

Je vérifie avec /l que tout est ok et je sors

La migration de l’ancien serveur

Là, je suis obligée de dire à mes joueurs que le serveur doit être fermé pour la migration. J’éteins mon ancien serveur et je fais une copie de mon monde vers le nouveau. Je ne cache pas que ça prend du temps, vu le nombre de gigaoctets de mon map.sqlite.

Pour vous situer, il faut copier deux répertoires :
– celui des mods : .minetest/mods vers minetest/mods
– celui du monde, dans mon cas : .minetest/worlds/adventure vers minetest/worlds/adventure

Je tremble un peu durant ce transfert et prie pour que tout se passe bien. Je relance après cette étape en spécifiant mon monde et … ça se lance ! Tout va bien, je souffle un peu ! Maintenant passons aux choses sérieuses !

J’édite mon fichier world.mt du monde adventure pour y ajouter mes identifiants de connexion PostgreSQL. On ne touche à rien d’autre, notamment la configuration des backends en SQLite. Ce sera fait automatiquement.

pgsql_connection = host=127.0.0.1 port=5432 user=monuser password=***** dbname=adventure
pgsql_auth_connection = host=127.0.0.1 port=5432 user=monuser password=***** dbname=adventure
pgsql_player_connection = host=127.0.0.1 port=5432 user=monuser password=***** dbname=adventure

Et je lance ma première migration, celle du monde, et j’attends. Ce qui est sympa, c’est que l’avancée de la migration s’affiche :

./minetest/bin/minetestserver --migrate postgresql --world minetest/worlds/adventure

Si vous avez comme moi une base de données énorme, ne faites pas l’erreur que j’ai faite, de lancer le script dans un terminal et le laisser juste agir comme ça (sincèrement, je ne pensais pas que ça prendrait tant de temps !). Je suis partie me coucher, le lendemain mon ordi avait rebooté tout seul, interrompant le process (que j’avais lancé la veille à 15h30), et que j’ai dû relancer cette fois dans un screen (ou faites un nohup … &, bref, permettez au script de le laisser exécuté même si il y a une coupure.). Bref, une bonne vingtaine d’heures plus tard (oui, une VINGTAINE d’heures !!!) après le deuxième lancement, la base des blocs est migrée !

Regardons le fichier world.mt. Il a changé automatiquement le backend correspondant à la base des blocs. Nickel. Faisons la suite. Les autres bases de données migrent très vite.

./minetest/bin/minetestserver --migrate-auth postgresql --world minetest/worlds/adventure
./minetest/bin/minetestserver --migrate-players postgresql --world minetest/worlds/adventure

L’heure de vérité à sonné. Je vérifie que mes backends ont bien été modifiés et que tout pointe sur ma base PostgreSQL. Mieux que ça, je convertis mes fichiers map.sqlite, auth.sqlite et players.sqlite en map.old, auth.old et players.old. Je lance le jeu, et super, tout marche et je retrouve mon monde tel que je l’avais laissé …

Reste à remettre dans mon minetest.conf les paramètres de l’ancien serveur, sauf l’adresse, qui change.

Pour terminer, augmentez la mémoire allouée pour les requêtes PostgreSQL, sinon vous allez vous retrouver avec des plantages core dumped. Donc dans /etc/postgresql/potgresql.conf, changez la valeur du paramètre shared_buffer pour qu’il ait au moins une valeur supérieure à 512Mo. Chez moi, j’ai affecté 1024Mo.

Il ne reste plus qu’à profiter du jeu maintenant !

Création de mon Wiki Minetest !

Être sérieux tout en s’amusant, beau concept ! J’adhère !

Comme certains le savent déjà, je n’ai pas super bien vécu le confinement. Je pensais être une louve solitaire dans l’âme, pensant que son rêve le plus cher serait d’être débarquée sans retour sur une île déserte.
Ben non ! En fait. J’aime les gens.
Bref, durant cette période de confinement, il a bien fallu s’occuper. J’ai eu la chance de pouvoir continuer à travailler normalement, étant déjà autoentrepreneur à la maison, mais j’avoue que en dehors de ces heures, il a fallu m’occuper, si mes sides-projects sont prenants, il me fallait « sortir », et ça j’avoue que ça m’a bien manqué, surtout pour l’urbex. Alors je suis sortie d’une autre façon.

Il y a dix ans de ça, je découvrais Minecraft … de loin. Je l’ai associé malgré moi à une tête de nœud qui voulait jouer les petits chefs, et qui pendant les pauses de midi, passait son temps sur la plate-forme, tout en ingurgitant un répugnant « hachis parmentier » made in Carrefour ou Casino. Ecoeurée par l’odeur de ce truc infâme qui se voulait être de la nourriture, je regardais ce qu’il faisait du coin de l’œil, le traitant intérieurement de « bébé qui joue aux Lego ». Je me suis ensuite renseignée sur le projet, et j’avais même écrit un article assassin sur ce blog, espérant que mon ennemi allait tomber dessus et se sentir outrageusement blessé dans son égo trop développé.

Dix ans plus tard, je me rends compte que ce programme a toujours du succès et que bon nombre de geeks dans mon entourage jouaient au dérivé libre et gratuit de Minecraft (parce que racheté par Microsoft, c’est devenu diabolique) appelé Minetest. Je me suis dit alors que si ces gens, intelligents, aimaient ce jeu c’est qu’il devait y avoir une bonne raison. Oui je sais, j’ai tendance à mettre des cases « tout blanc tout noir ».

Des cookies ! Plein de cookies !!!

Je m’y suis mise en test, en mode survival, en mode créative, un peu touché à tout, construit une maison de fortune, et j’ai été surprise de tout ce qu’on pouvait faire. Puis j’ai un pote qui m’a dit « viens sur mon serveur, j’y joue avec mon fils, on est bien et des cookies t’attendent ! » … donc là j’ai commencé à construire des trucs plus sympas, un cottage en bord de mer, que j’ai relié à un « donjon », devenu base de crafting (fabrication). Puis ayant fini, j’ai crée un château, puis des champs cultivables, avec des éléments craftables pour créer des petits plats, une ferme avec des vaches et des moutons, etc …

Si c’est pas sympa, franchement ?
Domaine avec château, champs et ferme
Salut, toi !

Personnalisable à l’infini !

Laissant jouer mon pote en famille, j’ai récupéré les sources du monde qu’il avait crée pour l’installer sur mon serveur. J’ai réinstallé les mods pour qu’ils soient compatibles avec ma version, et j’ai commencé à installer d’autres mods sympas. J’avais en effet commencé à faire une sorte de station de métro à côté du château, avec les rails de base, et j’ai donc voulu tester le formidable AdvTrains pour qu’on croit vraiment, à ce métro. Et franchement, je me suis bien amusée à y mettre des wagons qui semblent bien inspirés du U-Bahn berlinois, qui roulent réellement ! Et je pourrai même à l’avenir les automatiser ! Oui, c’est exactement une version virtuelle du petit train électrique !

Prenez place …

C’est ainsi que j’ai commencé à créer un vrai petit village avec : église, mairie (j’ai même un cimetière où j’ai mis les prénoms de mes exs) … à travers différents mods : mod_church, homedecor, x-decor … pour ne citer que ceux-là. Parce que oui, on peut optimiser son jeu comme on le souhaite, soit en installant des mods existants, soit en les créant soi-même avec le langage LUA. Et là on commence à toucher le côté geek du jeu (cœur avec les doigts <3).

J’essaie pas mal de m’inspirer des tutos de Richard Jeffres, qui a l’air de bien s’amuser et qui fait vraiment des choses impressionnantes.

Une de mes dernières créations en date : garage privé et voitures de luxe

Comme dans mon rêve

Ce que certains mods apportent, ce sont des extensions aux biomes existants. Parce que oui, ton monde dans Minetest et juste immense et s’étale en 3 dimensions sur 60000 blocs pour la dernière version. Je pense que peu de joueurs ont déjà tenté de générer la map complète de leur univers. C’est ainsi qu’on traverse savanes, jungles, icebergs, déserts … Mais on peut y ajouter une touche bien fantaisiste.

Le mod Ethereal apporte de nouveaux biomes, ainsi que de nouveaux arbres et plantes … il y a également le mod Caverealms qui apporte aussi de nouveaux styles de caves. J’ai également installé Nether mais je ne le trouve pas aussi sympa que ça en a l’air. Il faudra voir à l’utilisation.

Oui, ce sont des champignons géants.
Je sais pas vous mais je trouve ça trop joli <3

Geek stuff

Bien sûr je ne compte pas m’arrêter là. Si je compte agrandir mon petit village en y ajoutant des restaurants et des boutiques, j’ai également très envie de faire des choses bien plus poussées qui font l’attrait de Minetest : créer des usines et automatiser le métro. Car avec le langage LUA, qui peut s’injecter dans les éléments du jeu, on comprend l’intérêt ludique de ce qu’on appelle Serious Gaming.

J’ai commencé à suivre quelques tutoriels justement pour commencer à comprendre comment tout cela fonctionne.

Un calculateur qui affiche le résultat en chiffres et en lettres (avec Mesecons et Digilines)

Du coup voilà, j’ai plein de projets et espère bien ramener des gens car je m’y sens un peu seule sur ce serveur. Donc j’ai commencé à créer un wiki et ferai à l’avenir quelques vidéos pour vous monter un peu ce mignon petit monde 😉

Et hop : http://minetest.amelieonline.net

Et sinon la moralité de cette histoire : quand on ne connaît pas, on ne juge pas 😉 ! A plus tard dans la Matrice 😉 !