Projet Surf - App de prévision surf et conditions côtières 100% européenne
Moteur de décision déterministe, architecture multi-services souveraine, sans compte ni collecte de données personnelles
Contexte
Cette App est une plateforme de prévision des conditions de surf et côtières que j'ai conçue et développé seul.
J'ai combiné un pipeline d'enrichissement de données, avec un moteur de décision déterministe et explicable, spot par spot, ainsi que des briefs de session en langage naturel générés par MISTRAL
Quelques résultats particulièrement significatifs :
Les grandes étapes du projet
Conception de l'architecture et choix structurants
J'ai découpé le projet en cinq dépôts spécialisés plutôt qu'un monolithe : un moteur de scoring en Python/FastAPI, une couche API en Java/Spring Boot, une application mobile Angular/Ionic, un backoffice Angular, et un dépôt d'orchestration Docker Compose.
Ce découpage n'est pas qu'organisationnel : il est là pour assurer la sécurité des données et de l'ensemble du projet.
Les paramètres de calibration (orientation du spot, direction de vent optimale, fenêtres de houle, seuils de score) restent exclusivement dans les fichiers JSON internes au moteur FastAPI. Ils ne transitent jamais vers PostgreSQL, Spring Boot, ou une réponse HTTP, quelle qu'elle soit.
J'ai également tranché tôt sur le modèle produit : pas de compte utilisateur, aucune donnée personnelle collectée, et une stack reposant uniquement sur des fournisseurs européens (hébergement Scaleway Paris, IA Mistral, données Open-Meteo, SHOM et Puertos del Estado).
Indispensable pour un positionnement basé sur de la souveraineté européenne.
Modélisation des spots
Chaque spot de surf est décrit par un fichier JSON structuré, avec des blocs geometry et conditions qui portent l'ensemble de la logique de calibration.
Ces fichiers sont versionnés dans Git et embarqués directement dans l'image Docker du moteur : Spring Boot n'effectue aucune lecture de fichier JSON, il fonctionne à 100% sur base de données. Seul FastAPI a légitimement accès aux paramètres de calibration.
La couche API expose les données publiques (spots, ports, prévisions, briefs) sans jamais exposer la logique de calibration du moteur.
Application mobile Angular / Ionic
Le brief de session affiche les données au format que j'estimais le plus lisible pour un surfeur : un texte neutre généré par Mistral, deux panneaux d'histogrammes de houle (0h–12h / 13h–24h, tous les 2h), des panneaux de tendance de vent avec une rose des vents, et les heures de marée haute/basse.
- prévisions à 7 jours avec hauteur de houle en donnée principale, température de l'eau, vent, période et marées en détail ;
- recherche débouncée à 300ms sur les pages surf, spots et ports, affichant nom, ville et région ;
Pipeline de données et BDD
J'ai construit avec rigueur un pipeline en plusieurs étapes documentées (11 documents de spécification). Pour avoir une collectecte la plus complète possible et correspondant aux données terrain, contextualiser mon jeu de données, et avoir des tables saines.
Cette étape a été réalisée en plusieurs itérations, avec un premier passage manuel pour être certain des specs de chaque spot, villes et ports.
Puis un travail d'automatisation a été réalisé pour travailler sur les valeurs de chaques tables.
- 167 spots vérifiés en France, 81 en Espagne, 84 à 85 au Portugal
- 677 Villes calibrées actuellement pour l'onglet Météo
- 800+ Ports de plaisance
- scripts de calibration idempotents.
Infrastructure et déploiement
L'ensemble des services tournent via Docker Compose, avec un pipeline GitHub Actions qui construit et publie les images vers le registre de conteneurs Scaleway.
Je garde une vision de souveraineté européenne côté infra