Presentation Control – Pilotage de démo mobile en temps réel

Une plateforme pour piloter des démos mobiles en temps réel. Parce que les démos ratent toujours au pire moment.

Le problème

Bon. Vous connaissez ce moment en démo où vous dites “et maintenant, si je clique ici…” et rien ne se passe ? Le WiFi de la salle de conf a décidé que c’était le bon moment pour mourir. Ou le mobile affiche encore l’écran d’avant. Ou vous êtes en train de swiper frénétiquement pendant que 15 personnes vous regardent.

Les démos techniques ratent souvent. Pas parce que le produit est mauvais. Parce que coordonner ce qui est sur l’écran du mobile avec ce que vous racontez, en temps réel, sur un réseau qu’on ne contrôle pas… c’est compliqué.

Presentation Control résout ça. Un dashboard web avec des vignettes. Vous cliquez sur une vignette. L’écran du mobile change. Instantanément. Pas de swipe. Pas de “attendez, je reviens en arrière”. Juste : clic, changement.

C’est tout. C’est le produit.

Ce que ça fait

• Dashboard web : une grille de miniatures. Vous voyez tous les écrans de votre démo d’un coup.
• App mobile Flutter : elle affiche ce que le dashboard lui dit d’afficher.
• Temps réel : latence < 500ms. Vous cliquez, ça change.
• Monitoring : vous savez si le mobile est connecté, quelle est la latence, combien de devices sont branchés.
• Auth par magic link : pas de mot de passe à retenir. Un email, un lien, c’est fait.

Comment c’est construit

Le backend (Go)

Go avec Chi comme router. PostgreSQL pour la base. WebSocket pour le temps réel. Pas d’ORM — juste du SQL avec pgx. Les messages passent en Protobuf parce que si vous allez faire du temps réel sur trois plateformes différentes, autant avoir un format de sérialisation qui fonctionne partout.

Architecture simple : handlers → services → repositories. Rien de révolutionnaire. C’est le point.

Le frontend (Vue 3)

Vue 3 en Composition API, TypeScript strict, Pinia pour le state. Une grille de 60+ vignettes qu’on peut réorganiser. Design laptop-first parce que personne ne pilote une démo depuis son téléphone.

Le mobile (Flutter)

Flutter avec Clean Architecture. Provider pour le state. Client WebSocket qui maintient la connexion et affiche un indicateur quand ça coupe. Heartbeat régulier pour détecter les déconnexions.

L’infra

Ansible pour provisionner. Podman rootless pour les containers. Nginx devant avec TLS 1.3. GitLab CI qui fait lint → tests → build → deploy. La couverture de tests doit rester au-dessus de 95% sinon le pipeline échoue.

Les contraintes qu’on s’impose

Performance : WebSocket < 500ms bout en bout. API p95 < 200ms. Le frontend doit être interactif en moins de 3 secondes. Si le mobile se déconnecte, on le détecte en moins de 3 secondes.

Sécurité : JWT RS256. L’access token reste en mémoire — jamais dans localStorage. Le refresh token est en cookie httpOnly. Rate limiting par utilisateur. On valide le JWT avant d’upgrader en WebSocket.

Code : TDD. Les tests s’écrivent avant le code. TypeScript strict, zéro any. Conventional Commits. 95% de couverture minimum.

Pourquoi je construis ça

C’est un projet portfolio. L’objectif est de montrer que je sais :

• Partir d’un besoin et arriver à une architecture complète — backend, frontend, mobile, infra
• Écrire du code propre, testé, typé
• Documenter les décisions et les compromis

33 exigences fonctionnelles. 31 non-fonctionnelles. 6 épics. 37 stories avec critères d’acceptation testables.

C’est beaucoup de paperasse pour un side project. Mais c’est aussi le point.

Où ça en est

La conception est terminée. PRD complet. Architecture détaillée. Stories découpées.

L’implémentation est en cours. Des articles techniques suivront.