<aside>

Réaliser un développement d'application

▶︎ Les apprentissages critiques

  1. AC21.01 | Élaborer et implémenter les spécifications fonctionnelles et non fonctionnelles à partir des exigences
  2. AC21.02 | Appliquer des principes d'accessibilité et d'ergonomie
  3. AC21.03 | Adopter de bonnes pratiques de conception et de programmation
  4. AC21.04 | Vérifier et valider la qualité de l'application par les tests </aside>

<aside>

📎 SAE à l’appui : S4 — Stage RTsys

Rappel : stage de 10 semaines chez RTsys (Lanester) consistant à développer un outil de visualisation et de traitement FFT pour la bouée acoustique RUBHY-AI.

L’objectif était de remplacer un prototype existant basé sur Chart.js, limité par son architecture et incapable de gérer efficacement des flux audio temps réel.

Le système développé comprend :

Stage chez RTsys

</aside>

Quelles ont été vos démarches, prises de décisions, degré d’implication et d’autonomie dans la SAE ?

J’ai travaillé de manière progressive en partant d’une validation sur des signaux simples (WAV sinusoïdaux avec fréquence et amplitude connues), avant de passer aux flux temps réel SDA14.

Une décision importante a été de repartir d’une architecture complète plutôt que de corriger le prototype existant. Celui-ci reposait sur du calcul FFT côté JavaScript et un rendu DOM, ce qui ne permettait pas d’atteindre les contraintes de performance et de latence. Cette décision a été discutée puis validée avec mon maître de stage.

J’ai ensuite structuré le développement autour d’un pipeline DSP clairement découpé (accumulation → normalisation → fenêtrage → FFT → conversion → mise à l’échelle logarithmique), afin de pouvoir isoler et tester chaque étape indépendamment.

Quelles ressources avez-vous choisies et combinées pour réaliser vos tâches et résoudre les problèmes rencontrés dans cette SAE ?

J’ai combiné les notions de traitement du signal, d’architecture logicielle et de programmation système pour construire un système cohérent de bout en bout.

Le backend a été développé en Rust avec Tokio pour gérer les flux temps réel et la concurrence. Le rendu a été réalisé en WebGL/GLSL afin d’exploiter le GPU et garantir une fluidité suffisante pour l’affichage du spectrogramme. Le tout est synchronisé via WebSocket.

Les notions de séparation des couches (acquisition / traitement / rendu) ont été essentielles pour garder un système testable et évolutif.

En vous appuyant sur vos traces, justifiez la maîtrise des apprentissages visés.

AC21.01 — Spécifications et contraintes :

Les contraintes ont été intégrées dès la conception (temps réel, faible latence, compatibilité flux SDA14). Elles ont guidé le choix de Rust et WebGL ainsi que la refonte complète de l’architecture.

AC21.03 — Bonnes pratiques de conception :

Le système est organisé en modules indépendants : acquisition, DSP, communication et rendu. Le pipeline est linéaire et testable étape par étape, ce qui facilite le debug et l’évolution.

AC21.04 — Validation par les tests :

Des tests ont été réalisés à partir de fichiers WAV synthétiques dont les valeurs théoriques sont connues (fréquence, amplitude, bruit contrôlé). Les résultats FFT ont été comparés aux attentes pour valider chaque étape du pipeline.