Mes projets personnels

MultiPOV rassemble plusieurs points de vue YouTube, Twitch et Kick pour les sessions Discord et les événements. En VOD, la synchronisation audio mesure les décalages ; une horloge et des offsets maintiennent ensuite l’alignement. Le web est en production sur watchmultipov.app (Solid, TypeScript, Vite, PWA et hls.js). Le moteur Rust commun est exposé en WASM sur le web et compilé en natif dans l’app Android Tauri 2. Celle-ci embarque la régie web, des lecteurs Media3/ExoPlayer et une synchronisation live instrumentée pour les tests sur appareil.

• Sync VOD web : GCC-PHAT mesure les décalages audio, puis une horloge maître et des offsets maintiennent les POV alignés après pause, seek ou changement de layout
• Cœur Rust commun : moteur média partagé, exposé en WASM côté web et compilé en natif côté Android pour centraliser le timing, les offsets, les capacités provider, les erreurs et les fallbacks
• YouTube, Twitch et Kick dans une même vue, avec une couche provider commune pour gérer les différences entre plateformes
• Sessions partageables sans compte, encodées dans le chemin de l'URL (/s/), portables en commentaire ou en message privé
• Moteur de disposition configurable : grille auto, spotlight, theater et empilements ; glisser, redimensionner et dispositions sauvegardées (localStorage)
• Mode plein écran immersif : Fullscreen API sur toute la régie, avec verrouillage de l'orientation paysage et Wake Lock pour garder l'écran allumé pendant la lecture
• Overlay de chat unifié (Twitch/YouTube/Kick) : superposition éphémère repositionnable par POV ou dock latéral, messages fusionnés avec une pastille de couleur par plateforme et alignés sur la timeline en VOD
• App native Android : Tauri 2, régie web embarquée, cœur Rust commun, players natifs Media3/ExoPlayer et sync live instrumentée pour les contrôles sur appareil
• Développement assisté par Claude/Codex : spécifications, implémentation, revue et vérifications en production et sur appareil, avec commits délimités

Plateforme web de TTRPG textuel multijoueur où une IA générative incarne le maître de jeu. Système de jeu original (2d6+stat, GM Moves, Trait Cards, Vœux & Horloges, 5 modes de pacing) sécurisé par une « drift gate » de 19 invariants qui valide chaque sortie du LLM avant application de l'état. Pensée pour Claude (Anthropic) en première intention, l'application reste utilisable avec Gemini, OpenAI ou un modèle local (Ollama, llama.cpp, vLLM via API OpenAI-compatible) grâce à une architecture d'adaptateurs. La communauté crée ses propres univers via un wizard 11 étapes en 4 phases (import Fandom, génération assistée par IA, profils vocaux, lore par saison/épisode, traduction) et publie après modération. Backend Python 3.12 / FastAPI + WebSocket, SQLite asynchrone, frontend Vite, pool TTS multi-conteneurs Qwen et tier gratuit avec monnaie virtuelle Flares.

• Système de jeu original « dice-first » : le lancer 2d6+stat est résolu par le moteur AVANT l'appel au LLM (jet figé transmis comme fait établi), Position & Effect déterministes, 5 modes de pacing, Bold Move, HP/Momentum gérés à 100 % côté moteur (jamais par le LLM)
• Objectifs & horloges pilotés par le LLM : l'agent Architect définit les Vœux (objectifs de 0 à 10) et des Horloges à 4, 6 ou 8 segments — au lancement ou créées dynamiquement en partie — que le moteur fait progresser et agrège de façon déterministe
• Drift gate à 19 invariants : chaque réponse de l'IA est validée avant patch d'état (clamp automatique en cas de dérive sur HP, momentum, pacing, position, effets)
• Multi-provider via adaptateurs : optimisé pour Claude (Sonnet pour les tours, Haiku pour la validation et l'extraction, Opus pour les dilemmes moraux), aussi compatible Gemini, OpenAI et modèles locaux (Ollama, llama.cpp, vLLM) via API OpenAI-compatible
• Création communautaire d'univers : wizard 11 étapes en 4 phases avec import Fandom (scraping → extraction Haiku → builder Sonnet), boutons « AI Generate » par étape, profils vocaux WAV par personnage/langue, enrichissement de lore par saison/épisode et traduction EN ↔ FR
• Cycle de vie & modération : draft → pending → published → flagged → removed, signalements utilisateurs, procédure de takedown DMCA/LCEN/DSA, notifications email aux créateurs
• Landing publique + SPA authentifiée : galerie d'univers servie en HTTP cache 60 s, redirection auth sur /app, comptes utilisateurs (JWT, bcrypt, OAuth, magic-link)
• Tier gratuit avec monnaie virtuelle Flares : crédit à l'inscription, claim quotidien, publicités récompensées (CSP dynamique par utilisateur, exclusion service worker)
• Audio immersif à voix clonées : pool TTS Qwen multi-conteneurs Docker synthétisant une voix clonée par personnage et par langue (à partir d'un échantillon de référence), avec dispatch least-connections, semaphore par utilisateur, cache LRU des profils vocaux, intro musicale par univers et catalogue de pistes classées par humeur
• Outils d'observabilité : traces JSONL, replay 0-API, audit narratif/mécanique, tracker de coûts par session, panel admin avec auth HMAC

Nomad permet de développer depuis un téléphone Android connecté à un poste Linux via RustDesk. Le téléphone affiche le bureau distant et sert à la dictée ; un Joy-Con Nintendo Switch, tenu dans l’autre main, contrôle la souris et les raccourcis avec des profils configurables pour Claude Code, OpenCode ou Codex. Un daemon Linux orchestre écran, audio et transcription à la connexion du client mobile. Le projet comprend un fork RustDesk adapté (gamepad, voice call, identité visuelle), un serveur de licence Axum + SQLite + Ed25519 avec grâces hors-ligne et d’expiration, et le site bilingue nomadrust.dev. L’accès se fait sur demande via le formulaire du site.

• Conception du concept : utiliser un Android comme terminal vocal pour piloter un poste Linux distant via RustDesk
• Intégration Joy-Con Nintendo Switch : périphérique d'appoint qui libère le téléphone pour la dictée — déplacement souris via stick analogique et raccourcis clavier déclenchés par combinaisons de boutons
• Profils de touches configurables (Claude code, Open code, codex...) offrant un nombre d'actions suffisant pour piloter ces CLI sans clavier physique
• Dictée vocale pour parler au LLM : l'appli Android ouvre un appel vocal (voice call RustDesk) vers le daemon, qui transcrit la voix en local (Voxtype / Whisper large-v3-turbo) et injecte le texte comme frappe clavier (wtype sur Wayland, xdotool sur X11) directement dans le CLI voulu (Claude Code, Codex…) — on parle, le texte s'écrit dans le terminal
• Daemon Linux orchestrant automatiquement écran, audio et transcription dès qu'un client mobile se connecte
• Fork RustDesk avec patches dédiés (mapping gamepad Joy-Con, voice call, rebrand)
• Serveur de licence autonome (Axum + SQLite + Ed25519) avec grâces hors-ligne et expiration
• Site web bilingue FR/EN (Astro 5 + Tailwind CSS 4) pour la distribution
• Tarification prévue : 5 €/mois ou 50 € pour une licence à vie, sans essai gratuit ; V1.0 limitée à Linux

Portfolio FR/EN développé avec Angular 21 et pré-rendu en HTML statique. Il combine routes canoniques par langue, métadonnées SEO et partage social, mise en page responsive Tailwind CSS 4 et génération de CV PDF. Le fond astronomique est sélectionné quotidiennement ; son animation en couches dispose d’un rendu statique selon les capacités et les préférences de l’appareil.

• Génération statique Angular 21 : HTML pré-rendu pour les routes publiques
• Core Web Vitals : LCP < 2,5 s, INP < 200 ms, CLS < 0,1
• Score Lighthouse 100/100 sur performance, accessibilité, bonnes pratiques et SEO
• Switch bilingue FR/EN via routes canoniques : FR sur /, EN sur /en/*
• Fond cosmique quotidien multi-sources : un script (images:fetch via GitHub Actions) sélectionne chaque jour une vraie image issue de NASA APOD, ESA Hubble, ESA Webb ou ESO Picture of the Week ; filtres de luminosité et d'entropie, garde OCR, whitelist des hôtes, denylist et garde anti-stagnation écartent les images plates, annotées ou répétées, avec fallback sur cache local
• Fond animé en couches : environ 300 fragments Voronoi modulés par un champ d'énergie, scintillements détectés sur les zones lumineuses et étoiles filantes occasionnelles
• Animation sous contrainte : boucle d'énergie plafonnée à 30 FPS, calcul des fragments déporté dans un Web Worker, chargement différé et désactivation sur les profils mobiles ou à faible capacité
• Design glassmorphism : surfaces translucides en backdrop-filter (blur + saturate), rotation de teinte par carte et échantillonnage du fond (photo-tint) pour des reflets cohérents
• Animations CSS progressives entre les pages et au scroll, avec respect du mouvement réduit
• Générateur de CV PDF : création à la demande depuis les données du portfolio avec jsPDF
• Tailwind CSS 4 pour la mise en page responsive et les animations
• Images WebP et chargement différé pour réduire les temps de chargement
• Métadonnées dynamiques : Open Graph, Twitter Cards et JSON-LD
• CI/CD GitHub Actions : build statique pré-rendu et déploiement SFTP automatiques sur chaque push
• Angular Signals, composants standalone, pré-rendu statique et cache HTTP

Bot Minecraft autonome piloté par un LLM via le Model Context Protocol (MCP). Architecture « atomique » volontairement stricte : le bot Mineflayer n'est qu'un bras exécuteur (actions unitaires, aucune décision), tandis que le LLM raisonne sur des données brutes remontées par des senseurs (blocs découverts, dangers, inventaire, niveaux Y) pour décider quoi miner, construire ou fuir. Trois serveurs MCP séparent les actions, la connaissance Minecraft (recettes, Y-levels, outils) et une mémoire spatiale persistante en SQLite. Projet d'apprentissage qui m'a fait comprendre, par le jeu, comment formuler des règles explicites et fournir le bon contexte à un LLM — une compétence directement réinvestie dans la drift gate d'Aidventures et dans ma manière de cadrer le développement assisté par Claude Code.

• Architecture atomique : le bot exécute des actions unitaires (creuser, poser, équiper) et ne prend aucune décision — tout le raisonnement est délégué au LLM
• Senseurs renvoyant des données brutes (blocs autour, eau/vide, dangers, niveaux Y optimaux, inventaire) plutôt que des ordres, pour que le LLM raisonne sur le contexte réel
• Trois serveurs MCP séparés : actions, connaissance Minecraft (recettes, Y-levels, outils) et mémoire spatiale persistante en SQLite (escaliers, maisons et veines déjà connus)
• Règles de gameplay explicites (ordre de minage d'une veine, technique d'échafaudage pour ne pas s'enfermer) montrant que la qualité du résultat dépend de la qualité des règles données
• Agents parallèles (perception, sécurité, raisonnement) qui collectent et analysent l'état du monde avant chaque action