Case Study — AI Product Design & Engineering

AI MASTER G

Un outil de mastering audio professionnel.
Navigateur. Zéro upload. Zéro serveur. Zéro compte.

7 jours de production
3 systèmes IA orchestrés
16 modules JS
version livrée
↓ Scroll
01 — Contexte

Le mastering professionnel, sans les intermédiaires.

Les outils de mastering accessibles en ligne imposent un upload de fichier vers un serveur tiers, une chaîne de traitement opaque, et un abonnement. Les solutions DAW professionnelles exigent des années d'apprentissage et des licences coûteuses.

Le brief posait une contrainte non-négociable : aucun fichier audio ne doit quitter la machine de l'utilisateur. Tout le traitement devait se faire dans le navigateur, en temps réel, avec un niveau de qualité comparable aux outils de studio — chaîne DSP paramétrable, export WAV et MP3, visualisation spectrale.

L'outil devait également être lisible : l'utilisateur voit ce que fait le mastering, compare l'original et le signal traité sur le même spectromètre en temps réel. Ce n'est pas un mastering "magique" — c'est un mastering transparent, dont chaque décision algorithmique est visible.

0 octet
uploadé vers un serveur
< 3s
analyse spectrale complète
WAV + MP3
export double format 320 kbps
10 modules
chaîne DSP V2
02 — Méthode

Trois IA. Trois rôles distincts.

La méthode n'a pas consisté à déléguer la création à l'IA. Elle a consisté à affecter chaque système à la tâche pour laquelle il est structurellement le plus efficace, en maintenant une direction créative et technique continue entre les sessions.

Phase 1
ChatGPT
Recherche en sound design et analyse psychoacoustique. Utilisé pour transformer une expertise audio subjective en spécifications techniques documentées et chiffrées.
Framework mastering professionnel
Analyse LUFS / LRA / True Peak
Paramétrage DSP par genre musical
Benchmark comparatif multi-versions
Phase 2
Gemini
Prototypage rapide. Validation de la faisabilité technique du concept avec les API Web Audio natives. Établissement de l'identité visuelle initiale.
Preuve de concept fonctionnel
Architecture EQ + Saturation + Limiter
ADN visuel : #9eff00, fond #040507
Validation drag & drop audio
Phase 3
Claude Code
Engineering et production. Architecture modulaire, algorithmes avancés, cryptographie, système de licence. De v0.1 à v1.08 en sessions successives.
16 modules JS indépendants
DSP V2 — 10 nœuds de traitement
Chiffrement AES-GCM + Ed25519
Cloudflare Workers + Stripe
03 — Phase 1 / ChatGPT

La recherche comme spécification DSP.

Avant d'écrire une ligne de code, une session d'analyse approfondie a été conduite sur le titre de référence du projet. L'objectif : transformer une écoute experte en paramètres DSP chiffrés et directement utilisables.

La session a produit des mesures précises : loudness à -15.6 LUFS, True Peak à -0.7 dBTP, LRA à 6.2 LU. Ces valeurs n'ont pas servi à "documenter" le titre — elles sont devenues les seuils, ratios et gains de la chaîne DSP finale. Le pont entre la recherche et le code était direct.

La comparaison entre trois versions masterisées — original, 2026, preset variant — a permis d'identifier la philosophie de traitement cible : densité contrôlée plutôt qu'agression loudness, translation émotionnelle plutôt que choc immédiat. Ces formulations sont devenues les contraintes qualitatives de chaque algorithme.

Extrait — Analyse spectrale comparée · ChatGPT
Bande Low-End (60–120 Hz) : relation kick / 808 / corps harmonique relativement propre. Point technique fort de la production. Potentiel d'amélioration : séparation transitoire, punch shaping, impact mono sous 90 Hz.

Midrange (1–4 kHz) : zone déterminante pour la perception de "qualité premium". Forwardness vocal, articulation transitoire, sculpture harmonique "major-label".

→ Cible mastering : +1.5 à +3 LUFS de densité perçue via compression parallèle, harmoniques et saturation subtile — sans destruction de la dynamique.
04 — Phase 2 / Gemini

Le prototype : preuve de faisabilité.

Le premier code fonctionnel a été généré par Gemini en réponse à un brief précis. Son rôle n'était pas de produire du code de production — mais de valider que la Web Audio API couvrait le périmètre technique sans dépendance externe.

Le prototype : un seul fichier index.html de ~200 lignes. Drag & drop, lecture, EQ à 3 kHz, saturation WaveShaper, limiter brickwall à -1 dBTP. Fonctionnel. Non scalable. Non maintenable.

Ce prototype a établi trois choses importantes : la faisabilité technique du concept avec les API natives du navigateur, l'identité visuelle (fond #040507, accent vert lime #9eff00, typographie monospace), et la limite structurelle immédiate du monolithique — une codebase impossible à faire évoluer sans refactoring complet. C'est cette limite qui a justifié le passage à Claude Code.

Prototype Gemini — Chaîne DSP initiale (3 nœuds)
// Chaîne de mastering initiale — 1 fichier, ~200 lignes const eqNode = audioCtx.createBiquadFilter(); eqNode.type = "peaking"; eqNode.frequency.value = 3000; // présence vocale eqNode.gain.value = 2.5; const saturationNode = audioCtx.createWaveShaper(); saturationNode.curve = makeDistortionCurve(15); saturationNode.oversample = '4x'; const limiterNode = audioCtx.createDynamicsCompressor(); limiterNode.threshold.value = -1.0; limiterNode.ratio.value = 20; // brickwall // Connexion linéaire — fonctionnel, mais non paramétrable sourceNode.connect(eqNode); eqNode.connect(saturationNode); saturationNode.connect(limiterNode); limiterNode.connect(audioCtx.destination);
05 — Phase 3 / Claude Code

Architecture : v0.1 → v1.11

Huit versions, sept jours. Chaque version majeure correspond à un saut qualitatif précis — pas une accumulation de fonctionnalités, mais des décisions d'architecture successives, chacune motivée par une limite identifiée dans la version précédente.

v0.1
Premier refactoring — DSP isolé
Extraction de la logique DSP dans un module dédié (dsp-chain.js). Crossover 320 Hz, WaveShaper mid, brickwall limiter. Architecture encore monolithique mais chaîne de traitement isolée et instanciable.
MasteringEngine class dsp-chain.js
v0.5
Intelligence spectrale + i18n + double FFT
Algorithme d'analyse du ratio énergie bas/médium pour sélection automatique de preset. Double spectromètre FFT — courbe originale (bleu) superposée à la courbe masterisée (lime), avec gel de courbe en bypass. Internationalisation FR/EN/ES/JA. Export WAV + MP3 320 kbps via lamejs. Templates nommés et sélectionnables.
runSmartAudioAnalysis() Double FFT temps réel i18n 4 langues MP3 320 kbps Templates system
v0.9
Architecture modulaire — 9 fichiers
Décomposition complète en modules à responsabilité unique : analyzer, dsp-chain, exporter, i18n, main, player, spectrometer, state, templates, utils. Chaque module testable et remplaçable indépendamment. Scalabilité établie.
Separation of concerns state.js player.js exporter.js
v1.04
Landing page — productisation
Hero canvas animé simulant le double spectrogramme. Scroll reveal, FAQ, proof bar, CTA. Transition enterApp() vers l'application. L'outil devient un produit présentable à un utilisateur non-technique.
landing.js Canvas animation IntersectionObserver
v1.06
DSP V2 — Moteur 10 modules + Sécurité
Réécriture complète du moteur de traitement. EQ 3 bandes paramétriques, matrice M/S stéréo (encode → process → decode), compresseur multiband 3 bandes avec crossovers variables, 3 algorithmes de saturation harmonique (tanh / even / odd), de-esser, brickwall limiter -0.3 dBFS. Module security.js : chiffrement AES-GCM 256 bits des clés API avec dérivation PBKDF2. Tutorial interactif. Dev tools de capture de templates d'usine.
MasteringEngineV2 Matrice M/S stéréo Multiband 3 bandes AES-GCM 256 dsp-chain-v2.js security.js tutorial.js
v1.08
Système de licence — produit commercial
Validation Ed25519 100% offline via WebCrypto API. Cloudflare Worker pour webhook Stripe — vérification HMAC-SHA256, génération de clé signée, envoi email automatique via Resend. Plans Free / Particulier / Studio Pro. Clé privée isolée en Workers Secret, validation par clé publique embarquée dans le frontend. Rétrocompatibilité totale V1/V2 via factory createMasteringEngine(snapshot).
Ed25519 WebCrypto Cloudflare Workers license.js Stripe Resend API studio.html
v1.10
Responsive mobile — overflow systémique résolu
Refonte complète de la compatibilité mobile. Correction d'un débordement horizontal affectant toutes les vues. Cause principale : grid-template-columns: 1fr résolu comme minmax(auto, 1fr) — le auto autorise les colonnes à s'élargir au-delà du viewport. Correction par minmax(0, 1fr). Second piège : blocs @media positionnés avant les règles de base dans le fichier — écrasés par la cascade. Landing activée #landingActivated pour les plans non-free. Correction du flash de landing à l'init et à la sortie de l'app.
minmax(0, 1fr) CSS cascade order #landingActivated leaveApp / enterApp overflow-x mobile
v1.11
Isolation d'origine — présentation et studio séparés
Le widget conversationnel du site s'exécutait sur la même page que le studio. Script tiers en same-origin, il avait accès au DOM, au localStorage et au cache déchiffré de security.js — donc aux clés API LLM de l'utilisateur. L'application étant une SPA mono-fichier, enterApp() ne faisait que basculer des display : le script restait vivant pendant toute la session de mastering. Découpe en deux documents — index.html pour la présentation, app.html pour le studio — reliés par une navigation réelle. Les 17 gestionnaires onclick inline remplacés par des addEventListener, ce qui permet de retirer 'unsafe-inline' de script-src. CSP stricte par défaut sur le dossier, exception <Files> pour la seule page de présentation : l'isolation devient une propriété de l'en-tête, pas une discipline. Numéro de version centralisé dans version.js.
app.html CSP stricte par défaut <Files> override addEventListener version.js
Chaîne DSP V2 — Signal flow
[ Source Audio ] — BufferSource
↓
HP Filter — Highpass 30 Hz Q:0.5
Élimination infrasonic
↓
EQ 3 bandes paramétriques
Lowshelf 120 Hz · Peaking variable · Highshelf 10 kHz
↓
Matrice M/S — Encodage stéréo
Mid = (L+R)×0.5 · Side = (L−R)×0.5 · width [0–2]
↓
Multiband Compressor — 3 bandes parallèles
Sub ≤200 Hz · Mid 200–4 kHz · High ≥4 kHz
↓
WaveShaper — Saturation harmonique
tanh (tape) · even (tube) · odd (arctangente)
↓
De-esser — Peaking 6 kHz · Q:2.0
↓
Brickwall Limiter — −0.3 dBFS · ratio 20:1
Attack 1 ms · Release 100 ms
↓
[ Analyser ] → [ Destination ]
Saturation harmonique — 3 algorithmes
// tanh — harmoniques impaires · chaleur tape/transistor const div = Math.tanh(amt); curve[i] = Math.tanh(x * amt) / div; // even — harmoniques paires · écrêtage asymétrique tube // anode / cathode — normalisé x=±1 → output=±1 if (x >= 0) { curve[i] = (1 - Math.exp(-x * amt)) / posNorm; } else { curve[i] = -(1 - Math.exp(x * 0.6)) * 0.88 / negNorm; } // odd — soft clip arctangente · plus agressif const k = amt * 2; curve[i] = (1 + k) * x / (1 + k * Math.abs(x));
Fingerprint spectral — 9 axes d'analyse
// Profils détectés automatiquement à l'upload const fp = { rms: -14.2, // énergie RMS globale (dB) peak: -0.7, // crête max (dBFS) crest: 13.5, // facteur de crête dynamicRange: 6.2, // LRA estimé (LU) subW: 0.24, // poids sub 20–80 Hz lowMidW: 0.38, // poids bas-médium midW: 0.27, // poids médium presW: 0.14, // présence 3–8 kHz airW: 0.06 // air 8–20 kHz }; // → Sub Dominant · Low-Mid Heavy · Presence Forward // → Air Lacking · High-End Excess
06 — Design

L'interface comme extension du son.

Les décisions de design ont toutes été orientées par une même contrainte : l'outil devait ressembler à un plugin de studio DAW, pas à une webapp grand public. L'esthétique n'est pas décorative — elle est fonctionnelle.

AI Master G — v1.1 · Mode AI+
AI Master G — Interface de mastering v1.1
Interface complète — Mode AI+ actif · Template chargé · Spectromètre en lecture
① Sélecteur de template AI+ ② Statut DSP actif + headroom ③ Panneau AI Insights ④ Spectromètre dual-canal
Visualisation
Le double spectromètre comme argument
Superposer la courbe originale (bleu #00aeff) et la courbe masterisée (lime #9eff00) en temps réel transforme le mastering en quelque chose de visible. L'utilisateur ne fait pas confiance à l'algorithme sur parole — il voit la différence. Le gel de la courbe master en mode bypass amplifie ce contraste sans interruption de la lecture.
Identité visuelle
Fond #040507, lime #9eff00, monospace
Établie dès le prototype Gemini et maintenue intacte sur 8 versions et 3 environnements IA différents. Le vert lime est réservé aux éléments "en vie" — signal masterisé, statuts actifs, métriques temps réel. La monospace donne à l'interface le registre d'un terminal d'ingénieur plutôt que d'une application grand public.
Landing page
Convertir l'outil en produit
La landing page est pensée comme une étape de productisation, pas de communication. Le hero canvas anime le même double spectrogramme que l'app — continuité visuelle intentionnelle entre la présentation et la fonctionnalité. La proof bar ("0 octet uploadé") répond directement à la principale objection utilisateur avant qu'elle soit formulée.
Internationalisation
FR / EN / ES / JA dès v0.5
L'i18n n'a pas été ajouté a posteriori comme une feature — il a été conçu comme contrainte architecturale. Chaque chaîne de texte passe par un dictionnaire de traductions. Le japonais a imposé des vérifications de rendu typographique que l'anglais seul n'aurait pas détectées, et a renforcé la robustesse du système.
07 — Engineering Avancé

Sécurité et couche commerciale.

La v1.08 a introduit deux systèmes autonomes qui transforment l'outil en produit commercial viable : un système de licence cryptographique entièrement offline et un module de chiffrement local des clés API.

Système de licence Ed25519 : la clé de licence est un token signé cryptographiquement avec une clé privée Ed25519 isolée dans un Cloudflare Workers Secret. La validation se fait entièrement côté client via WebCrypto API — aucun serveur requis après activation. À chaque chargement, la signature est re-vérifiée pour prévenir toute falsification du localStorage.

Chiffrement des clés API : les clés GPT, Claude et Gemini stockées localement sont chiffrées avec AES-GCM 256 bits. La clé de chiffrement est dérivée d'une empreinte machine stable via PBKDF2 (100 000 itérations, SHA-256). Les clés restent illisibles à l'œil nu dans DevTools > Application > localStorage.

Flux de génération et livraison de licence
Stripe — checkout.session.completed TRIGGER
↓ Vérification signature HMAC-SHA256
Cloudflare Worker — handler webhook EDGE
↓ Lecture clé privée depuis Workers Secret
Génération clé Ed25519 signée SIGN
↓ Format : MASTERG-[payload_b64url].[sig_b64url]
Resend API — email de livraison automatique DELIVER
↓ Activation locale via WebCrypto API
Validation Ed25519 — 100 % offline · re-vérifiée à chaque session VERIFY
08 — Arbitrages techniques

Pourquoi ce choix plutôt qu'un autre.

Les décisions d'architecture sont rarement visibles dans le produit final. Elles déterminent pourtant ce qui est faisable, scalable, et maintenable. Voici les arbitrages structurants du projet, avec leurs alternatives écartées.

Décision retenue
Alternative écartée
Raison
Web Audio API native
WASM / DSP Rust compilé
Zéro installation, zéro build pipeline. Le sandbox navigateur couvre les targets LUFS visées. La dette de compilation WASM n'était pas justifiée pour les contraintes de performance réelles.
lamejs — encodage chunké
WebCodecs API
Support navigateur plus large (Safari, iOS). Contrôle précis du bitrate 320 kbps. Découpage en chunks de 1152 samples natifs MP3 déjà documenté et testable.
localStorage chiffré AES-GCM
Stockage backend des clés API
Cohérence avec la contrainte "zéro serveur". Emprunte le modèle des password managers — les clés restent sous contrôle de l'utilisateur, chiffrées depuis son empreinte machine.
FFT 2048 points
FFT 4096 points
Équilibre résolution fréquentielle / latence temps réel. À 44 100 Hz : 2048 pts = 43 ms de latence, 4096 pts = 93 ms. La différence de résolution spectrale est imperceptible visuellement à 60 fps.
V2 — réécriture complète
Patch incrémental sur V1
La migration vers la matrice M/S exigeait un routage de nœuds incompatible avec la topologie V1. Patcher aurait produit une codebase hybride non maintenable. Le pattern factory a ensuite absorbé la coexistence.
Architecture système — couches logicielles
UI Layer
Landing page App shell i18n (FR/EN/ES/JA) Canvas animation IntersectionObserver Tutorial
↕
Core — Traitement
Analyzer · 9 axes DSP Engine V1 / V2 Exporter WAV + MP3 State manager Player Spectrometer
↕
Security Layer
AES-GCM 256 PBKDF2 · SHA-256 Ed25519 WebCrypto Device fingerprint Base64URL encoding
↕
Infrastructure Edge
Cloudflare Workers Workers Secret Stripe webhook Resend API
Métriques de performance — runtime
43 ms
Latence FFT
temps réel
< 3 s
Fingerprint
9 axes
≈ 3 s
Export MP3
/ 4 min audio
16
Modules JS
indépendants
0
Dépendances
npm runtime
09 — Compétences mobilisées

Ce que le projet documente.

Compétences techniques
Prompt engineering domaine-spécifique
Injection de valeurs DSP chiffrées · Orchestration multi-système · Séquençage des sessions
●
DSP / Traitement du signal audio
Web Audio API · BiquadFilter · WaveShaper · DynamicsCompressor · OfflineAudioContext
●
Algorithmes de saturation harmonique
tanh (tape) · even harmonics (tube) · odd arctangente · normalisation et edge cases
●
Architecture frontend modulaire
Separation of concerns · State management · Module pattern ES6 · Factory pattern
●
Cryptographie appliquée
Ed25519 · AES-GCM 256 · PBKDF2 · WebCrypto API · Base64URL encoding
●
Infrastructure edge / serverless
Cloudflare Workers · Webhook HMAC-SHA256 · Resend API · Wrangler
●
Motion design — Canvas API
Spectrogramme animé · Interpolation smooth-step · requestAnimationFrame · resize handler
●
Internationalisation
Architecture dictionnaire · Langues : FR / EN / ES / JA · Application dynamique DOM
●
Compétences humaines
Oreille et jugement audio
Évaluation qualitative à l'écoute de chaque version · Validation que les algorithmes sonnent "juste" au-delà des métriques
○
Vision produit antérieure au code
Brief mental complet avant le premier prompt · Contraintes non-négociables définies à l'avance, maintenues sur toute la durée
○
Direction technique multi-IA
Affectation délibérée de chaque système à sa tâche structurellement optimale · Aucun mélange des rôles
○
Évaluation critique des outputs IA
Identifier quand le code généré est fonctionnel mais non scalable · Décider du refactoring au bon moment
○
Domain knowledge comme levier de prompt
Injecter des valeurs réelles (LUFS, ratios, fréquences) plutôt que des demandes génériques produit un résultat calibré
○
Cohérence visuelle sous pression
Même charte maintenue sur 8 versions · 3 environnements IA différents · Sessions non-continues sur 7 jours
○
Résilience face à la perte de contexte
Reconstruire une architecture à froid après perte de session · Maintenir la direction sans dérive de scope
○
Pensée produit et business
Modèle freemium · Plans différenciés · Intégration du paiement dès la conception, pas en post-production
○
Ce que l'IA n'a pas fait

Les tâches non-délégables.

○
Validation perceptuelle à l'oreille
Aucun modèle ne peut écouter le résultat. Chaque version de la chaîne a été validée à l'oreille sur des références connues avant d'être intégrée.
○
Arbitrages cibles LUFS
Les seuils retenus (−11 LUFS ±1, LRA < 8) sont des conventions professionnelles, pas des constantes mathématiques. Ce sont des décisions éditoriales, pas des outputs algorithmiques.
○
Architecture de la mémoire externe
Le dossier _versions/ n'a pas émergé des prompts. Il a été décidé humainement après la première perte de contexte, comme réponse structurelle à la volatilité des sessions IA.
○
Décisions de compatibilité V1/V2
La stratégie de rétrocompatibilité (factory pattern, snapshot.chainVersion) a été conçue humainement. L'IA a implémenté — elle n'a pas anticipé la contrainte.
○
Direction artistique UI
La contrainte "plugin VST, pas webapp grand public" était une posture esthétique non-déductible des specs techniques. Elle a guidé chaque décision de design sur les 8 versions.
10 — Challenges

Ce qui n'a pas fonctionné.

Sept obstacles ont jalonné le développement. Chacun a contraint une décision d'architecture ou de méthode qui n'aurait pas été prise sans lui.

01
Perte de la première conversation architecturale
La session initiale avec Claude Code — celle où les décisions fondamentales de structure ont été prises — a été perdue lors d'un bug de session. Avec elle : le raisonnement derrière les choix de nommage, les options rejetées et leurs raisons, la documentation implicite d'un contexte construit sur plusieurs heures. La session suivante devait reconstruire l'architecture à froid, sans aucun point d'ancrage autre que le code lui-même.
Réponse structurelle
Adoption du dossier _versions/ comme mémoire externe systématique — chaque état stable sauvegardé avant toute modification significative. Les fichiers ODT de recherche (ChatGPT) et le fichier de référence Engineer sont devenus des points d'ancrage inter-sessions, indépendants de l'état des conversations IA. Ce que la perte de données a produit : une discipline de versionnage qui n'aurait probablement pas existé sans elle.
02
AudioContext suspendu — silence sans message d'erreur
Les navigateurs modernes suspendent l'AudioContext jusqu'au premier geste utilisateur. Les premières versions ne géraient pas ce cas : le fichier se chargeait, le décodage s'exécutait sans erreur, mais la lecture restait muette. Aucune exception levée. Le bug était invisible dans la console.
Réponse
Ajout d'un if (audioCtx.state === 'suspended') audioCtx.resume() systématique avant chaque createBufferSource(), avec gestion de la promesse retournée. Détecté par observation comportementale, pas par log d'erreur — ce qui a imposé une méthode de debug plus rigoureuse sur l'ensemble du cycle audio.
03
Matrice M/S — annulation stéréo sans artefact audible
L'implémentation M/S avec ChannelSplitter et ChannelMerger produit un signal mono en cas d'erreur de connexion — sans distorsion perceptible immédiate. Une inversion de signe manquante sur le canal Side produisait une somme au lieu d'une différence, effaçant silencieusement l'image stéréo. Le résultat sonnait "correct" à une écoute non attentive.
Réponse
Réécriture du routage nœud par nœud avec les formules mathématiques explicites en commentaire (Mid = (L+R)×0.5, Side = (L−R)×0.5, L_out = Mid + Side×w, R_out = Mid − Side×w). Validation avec du bruit blanc stéréo connu avant intégration dans la chaîne complète.
04
Gel du spectromètre en bypass — race condition
Le double spectrogramme devait maintenir la courbe master figée pendant l'écoute bypass de l'original. La première implémentation figeait les deux courbes ou ne figeait rien : l'ordre de copie des Uint8Array dans la boucle renderFFT dépendait de l'état de useMastering au moment précis du frame, et cet état changeait de façon asynchrone entre deux frames.
Réponse
Capture explicite du snapshot master (frozenMasterArray.set()) au moment précis du toggleBypass(true), pas dans la boucle de rendu. Séparation stricte entre la logique de capture et la logique d'affichage. Le rendu ne fait que lire des tableaux — il ne décide plus.
05
Encodage MP3 — blocage du thread principal
L'encodage lamejs d'un fichier de 3 minutes en synchrone gèle l'interface pendant plusieurs secondes. Le premier essai avec une boucle directe rendait l'application non-responsive et créait une perception de plantage sur les fichiers longs. Les deux actions (encodage et UI) s'exécutaient sur le même thread.
Réponse
Découpage en chunks de 1152 samples (taille de frame MP3 native) avec setTimeout(processChunk, 0) récursif — chaque chunk cède le thread entre deux exécutions. Ajout d'une barre de progression pour maintenir la perception de contrôle pendant un processus qui reste long sur les fichiers lourds.
06
Coexistence DSP V1 / V2 — compatibilité ascendante
L'introduction de MasteringEngineV2 en v1.06 ne devait pas invalider les templates existants ni les snapshots sauvegardés. Deux classes, deux formats de snapshot incompatibles, mais une seule interface d'usage dans player.js et exporter.js. Toute tentative de migration forcée aurait détruit les presets utilisateur.
Réponse
Factory function createMasteringEngine(snapshot) qui lit snapshot.chainVersion et instancie le bon moteur. Les snapshots sans chainVersion (V1) continuent de fonctionner sans modification. Le pattern factory a absorbé l'incompatibilité sans modifier une ligne du code V1.
07
Validation Ed25519 — format WebCrypto strict
L'API crypto.subtle exige le format SPKI exact pour les clés Ed25519 et base64url (pas base64 standard) pour le transport. Une seule inversion de caractère (- vs + ou _ vs /) produit une erreur de signature silencieuse — la clé est rejetée sans message d'erreur exploitable. Le système semblait fonctionner jusqu'au premier test de validation réel.
Réponse
Écriture et test isolé des fonctions _b64urlToBytes() et toB64url() avec des vecteurs de test connus avant intégration. Séparation stricte des fonctions de conversion du reste de la logique de validation. Aucune des deux fonctions ne fait autre chose que la conversion.
08
CSS Grid overflow — 1fr ≠ minmax(0, 1fr)
Sur mobile, le dashboard restait plus large que le viewport malgré overflow-x: hidden sur html. Cause : grid-template-columns: 1fr est résolu par le navigateur comme minmax(auto, 1fr) — le auto impose une largeur minimale égale au min-content du contenu. Si un enfant est plus large que le viewport, la colonne s'élargit pour l'accommoder, ignorant les contraintes du conteneur parent.
Réponse
Remplacement systématique par minmax(0, 1fr) dans toutes les déclarations de colonnes. La valeur 0 fixe le minimum absolu — la colonne peut alors réellement se comprimer en dessous de son min-content. Ajout de min-width: 0 sur les items de grille directs pour propager la contrainte aux flex containers imbriqués.
09
Cascade CSS — media query écrasée par règle base tardive
Des règles @media (max-width: 600px) positionnées en tête de fichier (~ligne 200) étaient sans effet sur certains composants. Cause : les règles de base de ces composants étaient définies plus loin dans le fichier (~ligne 1767). En CSS, à spécificité égale, l'ordre d'apparition dans le fichier détermine la priorité — la règle la plus tardive gagne, quelle que soit la media query.
Réponse
Ajout de blocs @media secondaires positionnés immédiatement après chaque règle de base concernée. Principe établi : tout override mobile d'un composant doit être déclaré après la règle de base du composant, pas dans un bloc global en tête de fichier.
11 — Résultat

Ce que sept jours produisent.

Moteur audio
DSP V2 — 10 nœuds de traitement
Chaîne complète de mastering professionnel dans le navigateur. EQ paramétrique 3 bandes, matrice M/S, compression multiband, 3 algorithmes de saturation, de-esser, brickwall limiter. Export WAV + MP3 320 kbps via OfflineAudioContext.
Intelligence
Analyse spectrale — 9 axes
Fingerprint spectral automatique à partir du fichier audio. Détection de 5 profils sonores. Sélection automatique de preset basée sur le ratio énergétique. Affichage du diagnostic DSP actif en temps réel dans l'interface.
Sécurité
Cryptographie 100 % locale
Chiffrement AES-GCM 256 bits des clés API, dérivation PBKDF2 depuis l'empreinte machine. Validation de licence Ed25519 offline. Clé privée isolée en Workers Secret — jamais exposée au client.
Produit
Infrastructure commerciale complète
Landing page, système de licence, intégration paiement Stripe, email de livraison automatique, plans différenciés Free / Particulier / Studio Pro. De l'outil au produit distribuable en une semaine.
Épilogue

Une question, une réponse.

En session de relecture externe de ce document, un modèle IA a posé la question suivante. La situation — une IA demandant la conclusion d'un case study sur la collaboration homme-IA — n'était pas prévue dans le brief initial.

IA · Session externe Modèle concurrent · Revue de document
"Avez-vous déjà prévu une stratégie pour les futures mises à jour du moteur DSP ou envisagez-vous d'ouvrir cet outil à une phase de beta-test publique pour récolter des retours utilisateurs ?"
Réponse

Le moteur DSP V2 est une base de travail, pas une version finale. Deux directions sont clairement tracées : un True Peak lookahead plus long pour une conformité broadcast stricte — actuellement single-pass, idéalement 4 ms de marge — et un compresseur à phase linéaire, ce qui demanderait de migrer le DSP vers un AudioWorklet dédié, voire un module WebAssembly, pour préserver les performances en temps réel.

Sur la beta publique : le plan Free remplit déjà ce rôle structurellement — usage complet limité, acquisition naturelle, retours implicites. Une phase formelle avec un panel de mastering engineers et de producteurs représente l'étape suivante logique, pour valider la qualité perçue là où les métriques LUFS s'arrêtent.

Ce projet a surtout démontré qu'une expertise domaine réelle — algorithmique, sound design, design d'interface, expérience utilisateur — combinée à une orchestration délibérée de plusieurs systèmes IA, peut produire en quelques jours ce qui demandait auparavant plusieurs profils et plusieurs semaines. Non pas parce que l'IA a remplacé des compétences : elle a amplifié des compétences déjà là.

Sans ces bases, aucune de ces collaborations n'aurait produit quoi que ce soit d'utilisable. Y compris le support multilingue — parce que les IA hallucinent aussi en quatre langues, et avec beaucoup de conviction.

← Ouvrir AI MASTER G
— Supa Stream

Cette question a été posée par un modèle IA lors d'une session de relecture externe du case study. Les deux autres systèmes ayant contribué à ce document ont également lu ce texte et n'ont pas demandé de droits d'auteur.