BonjourHelloこんにちはHolaCiaoSalveBonjourJe suis QuentinDe la spec au déploiement, en solo.

Le problème résolu

Le positionnement éditorial — « le Michelin du café de spécialité » — impose que la découverte passe par la qualité de la fiche, pas par le volume. J'ai construit un modèle de données et une architecture de pages pensés pour le SEO local, puis instrumenté le site avec une stack analytics légère après comparaison de PostHog, Umami et Plausible. Les applications mobiles partagent le même backend Supabase : les migrations restent dans le dépôt web, les apps ne font que consommer le schéma.

• Carte interactive Mapbox avec autocomplétion d'adresses
• Back-office d'administration complet des établissements
• Guides éditoriaux en MDX, rendus statiquement pour le SEO
• Rate limiting Upstash Redis et emails transactionnels Resend
• Row Level Security Postgres sur l'ensemble des tables
• Apps iOS et Android (Expo) : interface native par plateforme, Sign in with Apple
• Tests unitaires Jest et parcours e2e Maestro communs aux deux plateformes

Le problème résolu

Dans un jeu où la progression vient d'activités réelles, la triche ruine l'intérêt pour tout le monde. Toutes les règles vivent donc côté serveur : comptage des sorties, tirage des coffres et progression de l'équipement sont calculés par des fonctions Postgres, le client ne fait que lire son état. J'y ai réutilisé la brique Strava construite pour Run&Roast — OAuth, refresh tokens, webhooks — cette fois dans des Edge Functions Supabase. Enfin, j'ai retiré la monnaie virtuelle, les gemmes et les timers de coffres : seul l'effort réel fait progresser.

• Progression 100 % effort : pas de monnaie, coffres ouverts dès la sortie comptée
• Équipement qui gagne en niveau avec les km-effort parcourus en le portant
• Règles de jeu entièrement côté serveur (RPC Postgres security definer)
• OAuth et webhooks Strava en Edge Functions ; tokens jamais lisibles par l'app
• Anti-triche : une sortie par jour, activités manuelles ou trop rapides ignorées
• Sentier et personnages en SVG animés par Reanimated, mode hors-ligne de démo

Le problème résolu

Un site vitrine qu'il faut redéployer à chaque changement de texte ne tient pas dans la durée. J'ai donc livré un back-office administrable : chantiers, matériel, prestations, FAQ et témoignages sont éditables en ligne. Le site reste consultable même sans base de données — le contenu retombe alors sur des valeurs par défaut — ce qui évite qu'une panne de Supabase mette la vitrine hors service.

• Back-office complet : chantiers, matériel, prestations, FAQ, témoignages
• Row Level Security sur toutes les tables ; aucune clé service_role utilisée
• Repli automatique sur des contenus par défaut si la base est indisponible
• Galerie de chantiers avec carrousel et images optimisées
• Formulaires validés par Zod et React Hook Form

Le problème résolu

Pour un restaurant, le site a un seul objectif : déclencher la réservation. J'ai construit l'interface autour de cette action — barre d'appel permanente sur mobile, lien CoverManager accessible de partout — et traité le référencement local comme une exigence de départ : sitemap, robots, données structurées et métadonnées orientées « restaurant à Saint-Gervais ».

• Réservation CoverManager accessible depuis toutes les sections
• Défilement fluide (Lenis) et animations au scroll (Motion)
• SEO local : sitemap, robots.txt et métadonnées dédiés
• Bandeau de consentement cookies et mentions légales
• Contenu centralisé : horaires, cartes PDF et fermeture annuelle éditables en un fichier

Le problème résolu

Le cœur technique est l'intégration Strava : flux OAuth, rafraîchissement des tokens, webhooks d'activité, normalisation des données et déduplication. Je l'ai construite comme une brique autonome, ce qui m'a permis de la réutiliser ensuite sur d'autres produits sans la réécrire. Ce n'est pas une intégration jetable, c'est une fondation capitalisée.

• OAuth 2.0 Strava complet : autorisation, refresh tokens, révocation
• Webhooks d'activité avec normalisation et déduplication
• Classements temps réel et système de gamification
• Paiement et abonnements via Stripe
• Architecture de policies RLS documentée

Le problème résolu

Trois arbitrages d'architecture structurent le projet : appeler l'API Claude depuis le main process via IPC plutôt que depuis le renderer, pour ne jamais exposer la clé API côté client ; utiliser la recherche full-text Postgres plutôt que des embeddings, parce que sur un corpus de cette taille le gain de pertinence ne justifiait ni le coût ni la complexité d'une base vectorielle ; planifier les traitements avec node-cron côté application.

• Application desktop macOS native (Electron via Nextron)
• Clé API isolée dans le main process, exposée par IPC uniquement
• Recherche full-text Postgres — arbitrage assumé contre les embeddings
• Architecture multi-équipes avec isolation stricte des espaces
• Résumé, tagging et scoring de pertinence par IA