Teissier YannisDéveloppeur · IA & fullstackLyon · sept. 2026
Retour à l'indexProjet 04 sur 06
04Étude de cas — 2026

Un serveur Minecraft moddé, en production
un panel en lecture seule, un journal de mesures et un mod à quatre correctifs

545 mods, une poignée de joueurs, et un tick passé de 120 à 45 ms, chaque changement adossé à un profil, chaque correctif un mixin de vingt lignes, et un panel de supervision qui ne peut pas écrire sur le serveur par construction.

Rôle
Ops, mesure, collecteur Go, mod Java, panel web
Stack
Go · Java · NeoForge · Spark · Fastify · React · PostgreSQL
Statut
En production, mod 1.4, panel en ligne, journal publié

Le problème

Un serveur entre amis sous All the Mods 10 (545 mods sur NeoForge) plantait sur son watchdog, gelait plusieurs secondes quand quelqu'un se connectait, et se figeait à chaque sauvegarde automatique. Personne ne voyait ce qui se passait, et chaque conseil d'« optimisation » trouvé en ligne contredisait le précédent. Je voulais trois choses : voir le serveur sans pouvoir le casser, mesurer avant de toucher, et ne corriger que ce que les mesures désignaient.

Ce que j'ai construit

Un panel de supervision dont le collecteur est en lecture seule comme propriété du code, pas comme intention : trois commandes RCON en constantes de compilation, un test d'AST qui échoue si autre chose est envoyé, un lint qui refuse tout symbole d'écriture, et une sandbox systemd avec système de fichiers en lecture seule et aucune capacité. Il échantillonne le processus, les logs, la liste des joueurs et le tick, envoie tout par un tunnel WireGuard à un worker qui agrège dans PostgreSQL, derrière une API à rôles hiérarchiques et un front React. Le collecteur est volontairement hors pipeline de déploiement : rien d'automatique ne se livre à côté du serveur de jeu.

Un journal de mesures : profils Spark de cinq minutes lus par un petit outil qui décode le format non documenté, un banc local reconstruit depuis une vraie sauvegarde avec dix faux joueurs et une JVM chaude, un changement à la fois, résultats négatifs consignés. Puis un mod NeoForge de quatre mixins pour les quatre goulots désignés par les profils : une garde sur les contrôleurs de stockage, une recherche de slot dichotomique au lieu de linéaire, un cache de recettes, et un writer de sauvegarde qui compresse en mémoire, écrit une fois, synchronise une fois et remplace atomiquement. Tick médian 120 → 45 ms à quatre joueurs, crashs watchdog 16 en deux jours → zéro, écriture des fichiers joueurs 700 → 8 ms, gel à la connexion 6,7 s → 0, gel d'auto-save 35 → 6 minutes par jour.

fig. 1 — pas de capture, un croquis
Fig. 1 — en haut, la chaîne de supervision et le mur que le collecteur ne peut pas franchir ; en bas, cinq goulots avant et après01

Ce que j'ai appris

Que la première version de la garde a coupé tous les joueurs de leurs coffres pendant onze minutes, parce qu'un autre mod lisait le contrôleur exactement comme celui que je voulais bloquer. Donc avant d'interdire une capacité, énumérer ses usages légitimes, et journaliser chaque refus. Qu'un correctif qui gagnait 14 ms sur le banc a éjecté un joueur en production. Qu'une métrique reconstituée peut inverser quatre conclusions, et qu'un pourcentage de profil n'est pas un coût. Et qu'alléger le cluster d'à côté n'a rien changé du tout : la contention de l'hébergement n'était pas le goulot, quoi qu'il en ait eu l'air.

“Un banc valide un gain ; il ne valide pas une mise en production.”
Suivant — 05Vision temps réel en périphérie