Aqualib by Florent Manaudou : un concept de piscine

Un concept de piscine à convaincre aux institutions

Aqualib, c'est le projet de Florent Manaudou pour révolutionner l'accès à la natation en France. Des piscines modernes, pensées pour être simples d'accès et faciles à réserver. Mais avant de construire la première piscine, il fallait convaincre les décideurs publics, maires, élus, institutions, que le concept tenait la route.

L'application mobile était l'outil de démonstration. Pas un prototype bricolé, une vraie app, complète, brandée, fonctionnelle. Une app qu'un maire pouvait prendre en main lors d'une réunion et utiliser de A à Z sans qu'on lui explique quoi faire.

‍

Créer une application mobile de démonstration crédible pour les institutions publiques

Le défi n'était pas de convaincre des utilisateurs, il n'y en avait pas encore. Le défi était de convaincre des décideurs qui n'ont aucune habitude d'évaluer des produits tech.

L'app devait être suffisamment simple pour être comprise en 30 secondes, et suffisamment complète pour résister aux questions d'un élu ou d'un directeur des sports : "Comment les gens rentrent dans la piscine ?", "Qu'est-ce qui empêche deux personnes de réserver le même couloir en même temps ?"

Des vraies questions opérationnelles, qui méritaient de vraies réponses techniques.

Et tout partait de zéro, pas de charte graphique, pas de design system, pas d'identité visuelle. Juste un concept et une vision.

‍

Comment on a créé l'application mobile Aqualib en 2 mois

Un branding créé de zéro, intégré directement dans le code

Avant d'écrire la première ligne de code, on a construit l'identité visuelle complète d'Aqualib. Logo, palette de couleurs, typographie, design system — tout créé from scratch pour refléter à la fois la modernité du concept et la crédibilité nécessaire pour convaincre des institutions publiques.

Mais le branding ne s'est pas arrêté à Figma. Chaque décision visuelle a immédiatement été traduite en design tokens dans la codebase : couleurs primaires et secondaires exposées comme constantes TypeScript, typographie intégrée dans un système de composants partagés, espacements et rayons de bordure unifiés à travers toute l'interface. Le résultat : un produit visuellement cohérent à 100%, sans aucun composant UI improvisé.

‍

Une architecture Supabase pensée pour la gestion de capacité en temps réel

Le cœur du projet, c'est le moteur de réservation. Et derrière l'interface simple qu'un maire voit sur son téléphone, il y a une architecture backend qui gère des contraintes opérationnelles réelles.

On a construit le backend sur Supabase, PostgreSQL managé avec Row Level Security activé sur toutes les tables sensibles. Chaque piscine expose une capacité par couloir et par vestiaire. Quand un utilisateur lance une réservation, la disponibilité est vérifiée et verrouillée en temps réel via Supabase Realtime : les slots occupés disparaissent instantanément de l'interface de tous les utilisateurs actifs, sans polling, sans rechargement.

Le double-booking est structurellement impossible. Ce n'est pas une règle métier codée à la main, c'est une contrainte d'unicité au niveau base de données, renforcée par une transaction PostgreSQL qui garantit l'atomicité de l'opération. Même en charge simultanée, deux utilisateurs ne peuvent pas confirmer le même couloir au même créneau.

L'architecture a été pensée dès le départ pour absorber une montée en charge sans refonte. Supabase repose sur du PostgreSQL standard : si le déploiement national d'Aqualib le justifie, la base de données peut migrer vers une instance managée enterprise, Cloud SQL sur GCP, Azure Database for PostgreSQL, ou Amazon RDS — sans toucher au schéma ni aux requêtes. Le système de temps réel peut être swappé vers Google Pub/Sub ou Azure Service Bus selon l'infra choisie. Et comme le système d'authentification repose entièrement sur des JWT stateless, l'API est nativement prête pour un déploiement horizontal derrière un load balancer, sans session côté serveur à gérer. La stack de démo et la stack de production partagent les mêmes fondations.‍

‍

Un QR code d'accès dynamique sécurisé par JWT

À la validation d'une réservation, l'app génère un QR code unique signé par JWT. Pas un simple identifiant lisible, un token cryptographiquement signé qui encode l'identité de l'utilisateur, le créneau réservé, le couloir attribué et une expiration calée exactement sur l'heure de début de session.

Le QR code est valide uniquement dans la fenêtre du créneau. Il expire automatiquement. Il est invalidé côté serveur dès la première lecture. Impossible à copier, impossible à réutiliser, impossible à falsifier sans la clé de signature.

C'est ce mécanisme qui rend le concept opérationnellement crédible : l'entrée dans la piscine est entièrement automatisée, sans intervention humaine, sans badge physique, sans file d'attente à l'accueil.

‍

React Native TypeScript, en distribution interne contrôlée

L'app est développée en React Native avec TypeScript strict, zéro JavaScript vanilla dans la codebase. TypeScript de bout en bout, du composant UI jusqu'aux types Supabase générés automatiquement depuis le schéma de base de données. Ça élimine une classe entière de bugs runtime et ça rend la codebase immédiatement lisible par n'importe quel développeur qui reprend le projet.

La distribution se fait via TestFlight pour garder un contrôle total sur qui accède à l'app pendant la phase de démonstration institutionnelle. Chaque décideur invité à tester reçoit un accès ciblé — pas de version publique, pas de fuite du concept avant que les premiers partenariats soient signés. C'est une décision stratégique autant que technique.

‍

Une gestion d'état cohérente sur tout le cycle de réservation

Une réservation passe par plusieurs états : disponible → sélectionné → en cours de confirmation → confirmé → utilisé → expiré. Chaque transition est gérée côté serveur et reflétée en temps réel dans l'interface via les subscriptions Supabase Realtime. L'utilisateur voit toujours l'état exact de sa réservation, sans avoir à rafraîchir, sans désynchronisation possible entre ce qu'il voit et ce qui est en base.

‍

Les résultats

• 2 mois de développement, de zéro à la livraison en production
• Branding complet créé from scratch : logo, design tokens, design system, identité visuelle
• Architecture Supabase avec gestion de capacité temps réel, zéro double-booking structurellement garanti
• QR code d'accès JWT signé, expirant automatiquement à la fin du créneau
• Codebase 100% TypeScript avec types Supabase auto-générés
• Architecture scalable vers GCP, Azure ou AWS sans refonte du schéma
• Distribution interne via TestFlight, accès contrôlé pendant la phase institutionnelle

‍

Ce qu'on retient sur la création d'une application mobile institutionnelle

Une app de démonstration n'est pas une app au rabais. C'est souvent l'inverse, elle doit être irréprochable parce qu'elle est jugée par des décideurs qui vont poser de vraies questions opérationnelles.

"Comment vous gérez les conflits de réservation ?", on a une réponse. "Le QR code peut être copié ?", on a une réponse. "Qui peut accéder à l'app ?", on a une réponse. "Ça tient si on déploie dans 50 piscines ?", on a une réponse.

Chez firstapp, on a compris que le vrai utilisateur d'Aqualib en phase de démo, c'était le maire en face de Florent Manaudou. C'est lui qu'il fallait convaincre et pour ça, il ne suffisait pas que l'app soit belle. Il fallait qu'elle soit solide.