Dans le cadre d'une SAÉ en groupe, on a développé un jeu de labyrinthe en Java. Le but était de coder un générateur de labyrinthes (parfaits et imparfaits) en utilisant des algorithmes comme le parcours en profondeur (DFS). On a aussi créé une interface graphique avec JavaFX et intégré trois modes de jeu : solo, coopération et jeu libre.

Sur ce projet, on a travaillé à quatre. Cela a demandé du travail d'équipe : nous avons dû nous répartir le code (comme séparer la logique du labyrinthe de l'affichage JavaFX) et tout fusionner sur Git en résolvant les conflits ensemble. De mon côté, je me suis occupé de la gestion des entrées clavier avec JavaFX pour rendre les déplacements du joueur et de la caméra fluides, ce qui a demandé de la rigueur pour que mes ajouts de touches clavier ne cassent pas le pattern MVC du projet. J'ai aussi codé le module de chargement des textures graphiques (les portes, les murs, les éléments interactifs) et j'ai dû faire preuve de résolution de problèmes pour corriger un bug où le joueur traversait les textures de portes en retraçant pas à pas la détection des collisions.

On a obtenu un jeu jouable en solo et à deux joueurs en coopération. L'interface permet de choisir la taille et la complexité du labyrinthe. Pour la partie conception, on a réalisé des diagrammes de classes UML pour documenter la structure du code.

La plus grande difficulté a été de gérer correctement les entrées clavier sous JavaFX. Il a fallu utiliser `consume()` sur les événements pour éviter des déplacements involontaires de la caméra en même temps que le joueur. Ça m'a obligé à bien fouiller la documentation de JavaFX.

L'objectif de cette SAÉ était de déployer et configurer un serveur de messagerie décentralisé et sécurisé Matrix (via Synapse) sur une machine Debian. On devait mettre en place le client web Element pour les utilisateurs, sécuriser les accès et documenter toute la configuration.

Je me suis occupé de la sécurisation des connexions à la VM en configurant des redirections de ports et des tunnels SSH (local forwarding). Ce projet a demandé du travail en équipe car nous devions nous coordonner en continu pour que ma configuration Nginx concorde parfaitement avec l'installation de Synapse faite par mon camarade. J'ai aussi configuré le reverse proxy Nginx pour servir le client statique Element Web et rediriger les requêtes API vers le serveur Matrix/Synapse, et j'ai connecté Synapse à la base de données PostgreSQL. Cela a demandé de la rigueur, notamment pour isoler nos identifiants de base de données dans des fichiers d'environnement séparés afin de ne pas les pousser par erreur sur notre dépôt GitHub public.

Le serveur Matrix et le client Element Web sont pleinement opérationnels. Tout le trafic passe par Nginx de façon sécurisée, et nous avons rédigé un journal de bord détaillé qui explique toutes nos étapes d'installation et de configuration système.

La principale difficulté a été de configurer Nginx pour qu'il gère correctement les appels CORS et transmette les bons en-têtes (comme `X-Forwarded-For`) sans casser la connexion entre Element Web et Synapse. J'ai dû faire pas mal de tests sur les blocs location de Nginx pour résoudre cela.

Le but de cette SAÉ était d'automatiser le déploiement d'instances Dolibarr pour plusieurs clients sur un serveur Debian. On a créé un script principal `INSTALL.SH` qui installe tout automatiquement : des conteneurs Podman pour chaque client, des bases PostgreSQL séparées, et Traefik comme reverse proxy avec gestion du HTTPS.

Je me suis principalement occupé d'écrire le script de sauvegarde (`BACKUP.SH`). Il effectue les sauvegardes (dumps SQL) de PostgreSQL et les transfère de manière sécurisée vers une machine distante de stockage. Pour notre collaboration, on a défini une politique de branches Git stricte pour éviter d'écraser le travail de l'autre sur les scripts d'installation. J'ai aussi modifié `DOLIBARR.SH` pour pouvoir choisir la version de Dolibarr à installer. Ce projet a demandé de la rigueur : j'ai restreint les permissions d'accès au fichier de configuration de PostgreSQL pour sécuriser les sauvegardes. Enfin, j'ai fait de la résolution de problèmes en corrigeant un bug où les sauvegardes SQL échouaient silencieusement, en ajoutant des vérifications du code de retour de chaque commande intermédiaire.

On a obtenu un script qui configure tout en une seule commande. Chaque client a son sous-domaine géré dynamiquement par Traefik, ses données sont isolées, et les sauvegardes sont lancées automatiquement toutes les nuits avec cron et rsync.

La principale difficulté a été de rendre le script de sauvegarde robuste : il fallait s'assurer qu'aucun fichier ne soit corrompu et que le script s'arrête proprement en cas d'erreur. J'ai résolu cela en testant systématiquement les codes de retour (`exit status`) de chaque commande dans `BACKUP.SH`.

J'ai créé mon blog technique (blog.evand.dev) pour partager mes notes, mes configurations et mes projets. Je rédige mes articles en Org-mode dans Emacs, puis ils sont exportés automatiquement en HTML avec `org-publish` et publiés sur GitHub Pages sous mon propre nom de domaine.

J'ai géré ce projet en totale autonomie de A à Z, en apprenant seul à configurer org-publish et à lier mon nom de domaine DNS sans aide extérieure. J'ai écrit la feuille de style CSS à la main (pour avoir un thème clair sobre et lisible), configuré le script Emacs Lisp pour l'exportation automatique et créé des snippets avec `yasnippet`. Ce projet m'aide pour ma communication écrite car rédiger des articles techniques m'oblige à expliquer clairement mon workflow pour qu'il soit compréhensible par tous. Cela demande aussi de la rigueur : je teste toujours la génération HTML et le rendu visuel en local avant de pousser mes articles sur GitHub Pages.

Le blog est en ligne avec mes premiers articles (sur la création du CSS, LaTeX et le fonctionnement du blog). Mon workflow est très simple : je tape mon texte dans Emacs, je lance la publication et je pousse sur Git. Le site se met à jour tout seul en quelques minutes.

Je savais déjà faire du CSS, mais ce projet m'a surtout permis de comprendre comment rendre une page web agréable à lire. Mon CSS a été pensé dès le départ pour être très sobre et lisible. Avec le recul, j'aurais dû structurer mes variables CSS de couleurs dès le départ : cela m'aurait évité de devoir modifier manuellement des dizaines de lignes de code lorsque j'ai ajusté le contraste du texte.

Pour la suite, je prévois de continuer à l'alimenter en écrivant sur tout ce qui touche à l'informatique et aux workflows, et de pratiquer davantage Emacs pour personnaliser mon environnement.

J'ai voulu aller plus loin dans ma connaissance de Linux en installant Gentoo sur mon ordinateur personnel. C'est une distribution où tout est compilé à partir des sources, ce qui oblige à comprendre comment le système est construit et comment ses composants s'articulent.

J'ai géré l'installation et la configuration de Gentoo de A à Z en totale autonomie, en suivant et adaptant la documentation d'installation officielle à mon ordinateur personnel. J'ai réalisé le partitionnement des disques, la compilation manuelle du noyau, la configuration de systemd et du chargeur de démarrage UEFI (sans utiliser GRUB). J'ai fait face à de la résolution de problèmes : lorsque le système a refusé de démarrer après compilation, j'ai dû analyser les erreurs EFI pour trouver le pilote manquant. Cela a demandé beaucoup de persévérance car j'ai passé plusieurs jours à recompiler et ajuster mon noyau pour avoir un système stable avec toutes mes touches de raccourci fonctionnelles.

J'utilise maintenant ce système au quotidien pour mes cours et mes projets. Le système est très léger (moins de 150 Mo de RAM utilisés au démarrage). J'ai pu compiler un noyau Linux sur mesure adapté à mon matériel et j'ai appris à gérer finement les dépendances des paquets avec Portage.

Installer Gentoo m'a permis de bien comprendre comment un système d'exploitation démarre et fonctionne. Contrairement aux distributions classiques où tout est automatique, j'ai dû tout configurer manuellement : le partitionnement GPT, le bootloader UEFI (via systemd-boot), et l'initialisation des services avec systemd. Ça m'a rendu beaucoup plus autonome pour diagnostiquer des erreurs et lire les logs système (`journalctl`) lors de soucis de pilotes ou de démarrage.

Avec le recul, j'aurais dû utiliser le noyau précompilé officiel (`gentoo-kernel-bin`) au début pour avoir un système stable rapidement. Configurer et compiler le noyau entièrement à la main dès le premier jour m'a fait perdre beaucoup de temps en résolvant des problèmes de pilotes WiFi et audio manquants.

Quand j'ai commencé le BUT, je pensais surtout faire du réseau. Mais au fil des semestres, et surtout grâce aux projets pratiques d'administration système (déploiement de conteneurs pour plusieurs clients, automatisation de sauvegardes, configuration de serveurs), je me suis rendu compte que c'était l'administration système qui me plaisait le plus. C'est ce qui m'a donné envie de m'orienter vers ce domaine pour mon futur métier.

Ces deux années m'ont permis de structurer ce que j'apprenais seul et d'acquérir de vraies méthodes de travail. J'ai appris à travailler en équipe avec Git, ce qui n'est pas toujours simple au début. Le BUT a confirmé mon goût pour les systèmes et réseaux : j'ai appris à configurer des serveurs, à sécuriser des flux réseau et à apprécier le fait de rendre un système propre, stable et automatisé.

Pour la suite de mon parcours, mes projets dépendent de la recherche d'alternance pour la troisième année :

Si je trouve une alternance : Je souhaite m'investir dans l'entreprise pour cette dernière année de BUT, avec l'objectif de poursuivre sur un CDI si l'opportunité se présente.

Si je ne trouve pas d'alternance : Je compte poursuivre mes études après le BUT en Master orienté administration système, réseaux ou support utilisateur pour approfondir mes compétences.

Disponible à partir de septembre 2026 pour un rythme d'alternance BUT 3 (métropole lilloise ou région Nord).