Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.2 — Répondre aux incidents et aux demandes d’assistance et d’évolution · B1.5 — Mettre à disposition des utilisateurs un service informatique
Le contexte et l’objectif
Dans un cadre personnel, j’ai conçu et déployé pour un groupe d’amis une infrastructure complète autour d’un serveur de jeu ARK: Survival Ascended, hébergé sur ma machine. L’objectif dépassait le simple « faire tourner un serveur » : je voulais un service entièrement autonome, que n’importe quel membre du groupe puisse démarrer ou arrêter sans mon intervention et sans compétences techniques, avec la garantie que la sauvegarde du monde est toujours la plus récente, qu’aucune double instance ne tourne à l’insu du groupe, et que le serveur est toujours à jour.
Le besoin technique
Les exigences que je me suis fixées ressemblent à un vrai cahier des charges d’exploitation : accès réservé aux seuls membres du groupe, sans exposer ma machine sur Internet ; démarrage et arrêt « presse-bouton » par n’importe quel membre ; détection préalable d’une instance déjà en cours, localement ou chez un autre membre ; synchronisation systématique de la sauvegarde avant lancement et après arrêt ; et configuration identique quel que soit l’hébergeur du moment.
La solution mise en œuvre
L’architecture réseau repose sur Tailscale, un VPN maillé fondé sur WireGuard : chaque membre rejoint un réseau privé chiffré, et tous les appareils communiquent comme en réseau local. J’aurais pu ouvrir les ports du jeu sur ma box, mais ce choix aurait exposé mon adresse publique en permanence ; le VPN restreint l’accès aux seuls membres du réseau privé — plus sûr, et plus simple à maintenir.
L’automatisation a été construite par preuves de concept successives : chaque brique (lancement du serveur avec tous ses paramètres, détection d’une instance en cours, synchronisation de la sauvegarde) a d’abord été développée et testée isolément, puis les briques validées ont été assemblées en scripts complets. La détection d’instance illustre bien la démarche : le script vérifie d’abord localement qu’aucun serveur ne tourne, puis interroge chaque machine du réseau privé sur le port du jeu avec un délai court, pour s’assurer qu’aucun autre membre n’héberge déjà la partie. La sauvegarde du monde et les fichiers de configuration sont centralisés sur un espace cloud partagé et synchronisés automatiquement : n’importe quel membre peut héberger, la partie reprend toujours là où elle s’était arrêtée. À l’arrêt, une commande d’administration distante ordonne d’abord la sauvegarde propre du monde, puis le serveur est arrêté et la sauvegarde renvoyée vers le cloud.
Le service a ensuite évolué en réponse à un problème d’exploitation récurrent : à chaque mise à jour du jeu, un serveur resté sur l’ancienne version refuse les connexions des joueurs à jour, et il fallait intervenir manuellement. J’ai donc fait évoluer le script de démarrage : il vérifie désormais, avant chaque lancement, si une mise à jour du serveur est disponible et l’applique automatiquement le cas échéant — puis enchaîne les contrôles habituels (détection d’instances, synchronisation de la sauvegarde) avant de démarrer. Cette évolution a fait disparaître la première cause de demandes d’assistance du groupe.
La dimension sécurité
Trois choix structurent la sécurité du service : aucune ouverture de port sur Internet, tout l’accès passant par le réseau privé chiffré ; une administration distante du serveur protégée par mot de passe et limitée au réseau local de l’hôte ; et une stratégie de sauvegarde systématique, synchronisée avant et après chaque session, qui protège les données du groupe contre la panne ou la fausse manipulation d’un hôte.
Ma plus-value personnelle
Ce projet est probablement celui qui ressemble le plus à de l’exploitation réelle : des utilisateurs non techniciens, un service qui doit fonctionner sans moi, des incidents (versions, doubles instances, sauvegardes divergentes) qu’il a fallu transformer en évolutions du service. J’y ai appris à concevoir pour les autres : les scripts sont « clé en main », prévoient les cas d’erreur et affichent des messages compréhensibles. La démarche par preuves de concept, la synchronisation cloud en ligne de commande, l’administration à distance et la supervision multi-machines sont autant de réflexes que j’ai directement réinvestis pendant mon stage.
La procédure technique détaillée, avec l’ensemble des scripts commentés, est disponible en téléchargement au format PDF ci-dessous.