Projets
Mes projets
Une sélection de projets réalisés en BTS SIO SISR et en alternance.
ORION
AlternanceApplication cartographique — visualisation de données réseau
📅 Juin 2025 — en cours📋 Contexte
Dans le cadre de mon alternance, j'ai développé ORION : une application cartographique permettant de visualiser et d'exploiter des données réseau sur une carte interactive, en remplacement d'un traitement tabulaire peu lisible sur de grands volumes.
🎯 Objectifs
- Automatiser l'extraction et le traitement de données issues de sources hétérogènes
- Permettre la visualisation géographique des données sur une carte interactive
- Réduire le temps d'analyse et supprimer les manipulations manuelles
⚙️ Réalisation
- Extraction et analyse des données sources
- Traitement, nettoyage et normalisation pour le géocodage
- Développement de l'interface cartographique et de ses filtres
- Livraison de l'outil aux équipes
🚧 Difficultés rencontrées
- Géocodage imprécis (fusions de communes, abréviations) → pipeline de nettoyage en amont
- Données hétérogènes multi-sources → consolidation et validation avant traitement
📈 Résultats
- Temps d'analyse réduit de ~1 heure à 5–10 minutes
- Suppression des manipulations manuelles sur données tabulaires
- Outil livré et utilisé en production
🎓 Compétences BTS SIO SISR mobilisées
Proxmox — Acerveur
Projet personnelServeur de virtualisation personnel — labs, TP et expérimentations avancées
📅 Décembre 2025📋 Contexte
Serveur de virtualisation personnel surnommé Acerveur, monté à partir d'un boîtier Acer Aspire réutilisé (Xeon E5-2680 v4, 64 Go RAM DDR4). Plateforme Proxmox VE dédiée aux TP et labs BTS, avec expérimentation du GPU passthrough via une GTX 1650 inutilisée.
🔍 Problématique
Comment disposer d'une infrastructure de virtualisation polyvalente pour les labs BTS, tout en expérimentant le passthrough PCIe d'un GPU dans une VM ?
🎯 Objectifs
- Héberger plusieurs VM de test et de lab pour la formation BTS SIO SISR
- Expérimenter le GPU passthrough (VFIO/IOMMU) sur une VM Windows
- Mettre en place un streaming local via Sunshine / Moonlight
⚙️ Réalisation
- Montage du serveur et installation de Proxmox VE
- Déploiement de plusieurs VM de lab (Windows Server, Debian…)
- Activation IOMMU dans le BIOS et le kernel, configuration VFIO
- Passthrough de la GTX 1650 vers une VM Windows + streaming Sunshine/Moonlight
🔄 Architecture
🚧 Difficultés rencontrées
- Affichage hôte perdu après attribution du GPU → administration via SSH et interface web uniquement
- Compatibilité IOMMU incertaine → validation des groupes PCI et paramètres BIOS
- Drivers GPU instables dans la VM → plusieurs itérations pour stabiliser
📈 Résultats
- Infrastructure stable et réutilisable pour tous les labs BTS
- GPU passthrough fonctionnel avec performances natives
- Cloud gaming local opérationnel via Sunshine / Moonlight
🔮 Améliorations possibles
- Supervision des ressources matérielles (CPU, RAM, température)
- Stratégie de sauvegarde des VM
- Accès distant via VPN (Tailscale)
🎓 Compétences BTS SIO SISR mobilisées
Serveur de déploiement PXE — FOG
Projet BTSDéploiement automatisé de postes Windows via le réseau (PXE + Sysprep)
📅 Janvier – Février 2026📋 Contexte
Dans le cadre de la préparation du plateau technique pour l'épreuve E6 du BTS SIO, il était nécessaire de déployer rapidement des postes Windows configurés avec les bons logiciels. Pour éviter les installations manuelles répétitives, j'ai mis en place un serveur de déploiement automatisé via le réseau avec FOG Project.
🔍 Problématique
Comment déployer rapidement plusieurs postes Windows identiquement configurés pour le plateau technique de l'épreuve E6, sans passer des heures à réinstaller chaque poste manuellement ?
🎯 Objectifs
- Mettre en place un serveur de déploiement automatisé via le réseau (PXE)
- Créer une image Windows Sysprep standardisée et réutilisable
- Déployer les postes cibles en quelques minutes sans aucune intervention manuelle
💡 Solution technique
MDT (Microsoft Deployment Toolkit) étant abandonné par Microsoft, j'ai cherché une alternative maintenue et open source. FOG s'est imposé comme la solution la plus adaptée : gratuit, actif et compatible PXE.
⚙️ Réalisation
- Installation et configuration du serveur Debian hébergeant FOG
- Préparation du poste modèle Windows avec les logiciels souhaités
- Exécution de Sysprep pour généraliser l'image (suppression SID, OOBE)
- Capture de l'image via FOG et déploiement PXE sur les postes cibles
🚧 Difficultés rencontrées
- Sysprep capricieux (sensible aux drivers, mises à jour, logiciels) → plusieurs itérations nécessaires pour obtenir une image stable, avec suppression des éléments problématiques
- Coordination DHCP/PXE avec le réseau existant → configuration du DHCP pour rediriger le boot PXE sans impacter le reste du réseau
📈 Résultats
- Déploiement complet d'un poste en quelques minutes (vs 30–45 min manuelle)
- Image Windows standardisée, capturée et réutilisable
- Zéro installation manuelle sur les postes cibles
- Plateau technique E6 prêt à temps
🔮 Améliorations possibles
- Mise en place d'images de mise à jour incrémentale pour appliquer les patches sans recapture complète
- Intégration d'un inventaire automatique des postes déployés via FOG
- Extension du déploiement à des environnements Linux pour les labs
🎓 Compétences BTS SIO SISR mobilisées
Pilotage à distance d'un serveur TrueNAS via Wake on LAN
Projet personnelAllumer, éteindre et redémarrer un NAS à distance via une interface web légère
📅 Mars 2026📋 Contexte
Projet personnel autour de mon NAS maison — un HP ProDesk 400 G4 hébergeant TrueNAS Scale. Pour éviter de le laisser allumé en permanence, j'ai voulu pouvoir le démarrer, l'éteindre et le redémarrer à distance via une interface web simple, accessible depuis n'importe où sans intervention physique.
🔍 Problématique
Comment démarrer et administrer un NAS TrueNAS éteint depuis n'importe où dans le monde, sans laisser le serveur allumé 24h/24 et sans ouvrir de port sur la box internet ?
🎯 Objectifs
- Permettre l'allumage à distance du NAS via Wake on LAN depuis l'extérieur
- Offrir une interface web légère pour démarrer, éteindre et redémarrer le serveur
- Sécuriser l'accès sans ouverture de port sur la box (zéro exposition directe)
💡 Solution technique
Le routeur GL.iNet GL-SFT1200 sous OpenWRT, déjà présent sur le réseau, s'est imposé comme relais idéal : capable d'envoyer des paquets Wake on LAN, d'exécuter des scripts shell et d'héberger une interface web légère. GoodCloud et Tailscale ont été retenus pour l'accès distant sans ouverture de port.
⚙️ Réalisation
- Configuration du Wake on LAN sur TrueNAS (activation via ethtool au démarrage)
- Développement des scripts shell sur le routeur (WoL, ping, SSH)
- Mise en place de nginx + fcgiwrap pour exécuter les scripts via HTTP
- Création de l'interface web de contrôle hébergée sur le routeur
- Sécurisation de l'accès SSH par clé publique et configuration sudo sans interaction
🚧 Difficultés rencontrées
- WoL non natif sur TrueNAS → activation manuelle via ethtool + persistance au redémarrage dans la configuration système
- CGI restreint via GoodCloud → contournement par nginx + fcgiwrap pour exécuter les scripts shell en HTTP
- sudo interactif impossible en SSH non-interactif → utilisation de sudo -S avec redirection stdin pour les commandes d'arrêt
📈 Résultats
- NAS pilotable depuis n'importe où dans le monde via interface web
- Allumage, arrêt et redémarrage sans intervention physique
- Consultation en temps réel du statut du serveur
- Serveur allumé uniquement à la demande → économies d'énergie
🔮 Améliorations possibles
- Ajout d'une authentification sur l'interface web (protection par mot de passe ou token)
- Mise en place de notifications si le serveur devient inaccessible
- Extension du pilotage à d'autres équipements réseau de l'infrastructure
🎓 Compétences BTS SIO SISR mobilisées
IA locale sur Proxmox
Projet personnelInfrastructure d'inférence LLM locale — multi-GPU, multi-backend
📅 2025 – 2026📋 Contexte
Projet personnel sur mon homelab : déployer une infrastructure complète d'IA locale sous Proxmox pour faire tourner des LLM de manière autonome, sans dépendance au cloud, en gardant la maîtrise des données et des coûts.
🎯 Objectifs
- Déployer plusieurs VMs spécialisées sous Proxmox (inférence, services, benchmark)
- Tester et comparer plusieurs backends GPU : CUDA, Vulkan, ROCm
- Héberger une interface utilisateur et des outils d'automatisation
- Intégrer l'IA locale dans un usage concret de développement
⚙️ Réalisation
- VM INTELIA — inférence via llama.cpp/Vulkan sur Intel Arc B570, API REST port 8080
- VM ORCHESTRE — services : Open WebUI, SearXNG, n8n
- VM RXIA — inférence AMD RX 7600 via ROCm + Ollama (nœud benchmark)
- Benchmark comparatif : RTX 3060, Tesla P100, Arc B570, RX 7600
- Intégration dans VS Code via l'extension Continue
🔄 Architecture
🚧 Difficultés rencontrées
- Intel Arc + IPEX-LLM trop complexe en VM → migration vers llama.cpp/Vulkan
- Compatibilité GPU non-NVIDIA moins mature → plusieurs itérations pour stabiliser
- Différences importantes entre CUDA, Vulkan et ROCm selon les modèles
📈 Résultats
- Stack d'inférence fonctionnelle avec interface web accessible
- Support multi-GPU multi-backend sur deux nœuds Proxmox
- Benchmark comparatif de 4 architectures GPU (NVIDIA/AMD/Intel)
- IA locale intégrée dans le workflow de développement VS Code
🎓 Compétences BTS SIO SISR mobilisées
