Quad
Unlimited

La niche powersports française est mal servie. Les pièces et carénages de Yamaha Banshee, Raptor ou YFZ sont dispersés sur des sites lents, des annonces et des groupes Facebook. Aucun endroit clair pour trouver, visualiser et commander un kit complet.

Le projet demandait un catalogue et une expérience de configuration adaptés à cette niche. J’ai choisi une architecture qui me permettait de contrôler l’interface et les données produit.

• Catalogue Banshee/Raptor illisible et éclaté
• Impossible de visualiser un carénage avant d'acheter
• Boutiques génériques, lentes, mauvais SEO
• Parcours d’achat à adapter aux pièces et aux modèles

Trois murs, posés dès le départ. Un : hébergement statique pur sur Cloudflare Pages — aucun build, aucun serveur applicatif ; tout doit tourner par simple push de fichiers. Deux : un budget quasi nul — plans gratuits Cloudflare, Supabase, Resend, avec des coûts limités au départ — qui impose des arbitrages et dicte chaque arbitrage de performance.

Trois, la plus structurante : comme tout est rendu côté client, la clé d'accès à la base est publique dans le navigateur. La sécurité ne peut donc reposer sur aucun secret — uniquement sur ce que la base elle-même autorise. La moindre règle trop permissive expose clients, commandes… et surtout les prix d'achat et les fournisseurs.

• Zéro build, zéro framework — imposés
• Maîtriser les coûts d’infrastructure au démarrage
• Clé base publique → sécurité par la base, pas par un secret
• Le prix vit dans 3 sources à garder en parité
• Une seule personne : site + back-office + 10 apps

Face au « pas de build », j'ai fait du monolithe une force : du HTML/CSS/JS vanilla servi tel quel, avec une couche partagée /core/ (tokens, composants, SDK) réutilisée par le site et les dix apps par simple URL — chaque module protégé par un garde d'idempotence pour survivre à un double chargement. Sans bundler dans cette version.

Pour être trouvé sans budget pub ni backlinks, une couche SSR sur Cloudflare Functions : 42 fonctions rendent des pages entièrement crawlables (JSON-LD Schema.org, Open Graph), en cache CDN versionné (cache CDN). Le catalogue reste piloté par Supabase, hydraté à chaud. Et les rich snippets (avis, livraison offerte) ne sont émis que s'ils sont vrais — jamais de faux signaux à Google.

• /core/ partagé par URL, gardes d'idempotence
• SSR + JSON-LD pour rendre les fiches lisibles par les moteurs
• Prix d'achat & fournisseurs verrouillés colonne par colonne (la RLS ne filtre que les lignes)
• Webhook & stock idempotents — aucun doublon sur retry
• Suivi de commande anti-énumération (réf + email)
• Configurateur 3D chargé au clic, jamais bloquant

349 commits, ~6 semaines, une personne. Pas de cowboy pour autant : branches → pull request → merge (un commit sur cinq passe par une PR), worktrees isolés, convention de commits stricte, et vingt documents — manuels séparés opérateur / gérante, cahier des charges, audits — pour dérisquer la dépendance à une seule tête.

Faute de QA externe, je me suis imposé des audits 360 datés comme points de contrôle : le jour de l'audit sécurité, 62 commits en 24 h pour éponger la dette d'un coup. La sécurité a été durcie en cinq vagues P0 successives — du verrouillage RLS à l'anti-énumération des commandes.

• 349 commits · ~30 jours actifs · 100 % solo
• Branches → PR → merge, même seul
• Cadencé par des audits 360 (la QA que je me fixe)
• Sécurité durcie en 5 vagues P0
• Décision fondateur : catalogue ravalé sur le stock réel — ne jamais se mettre en perte
• 4 tests bloquent le déploiement (parité prix, calculs)

Une boutique et ses outils de présentation sont en ligne : catalogue, pages produit et parcours de commande. Le projet montre le travail de conception et d’intégration ; son activité commerciale se mesure séparément.

Le configurateur 3D permet de visualiser des combinaisons de pièces et de coloris avant de passer à la commande.