Administration de la boutique depuis CRM Cycles
Un magasin de vélos qui investit dans un CRM métier complet (catalogue produits, stock sérialisé, prix par groupe client, ordres de réparation) se retrouve face à une question évidente : comment exposer cette donnée sur un site marchand grand public, sans dupliquer la saisie ni risquer la désynchronisation ? CRM Boutique répond à cette question. C’est un site vitrine e-commerce Next.js 14 qui consomme les API REST de CRM Cycles en lecture, déployable sur Vercel en quelques minutes, et déclinable en blanc-marque par boutique cliente via des variables d’environnement.
Côté client : l’expérience d’achat
Le visiteur arrive sur un site moderne, rapide (score Lighthouse > 95 sur la home grâce au static rendering), avec une recherche produit instantanée et un catalogue calibré au métier : familles, catégories, sous-catégories, marques, gamme de prix, état neuf ou occasion. Pour les vélos, les filtres incluent la taille recommandée (cross-référence avec un guide des tailles intégré), le type d’usage (route, VTT, urbain, enfant), et la disponibilité physique en magasin (« en stock ici » avec compte des unités).
Le panier supporte les bons d’achat émis par le CRM (le client colle un code KDO et la réduction s’applique), la livraison à domicile ou le retrait magasin avec créneaux horaires synchronisés sur le calendrier atelier, et le paiement Stripe avec gestion 3D Secure native. À la confirmation de commande, la donnée part vers CRM Cycles via webhook pour création de la commande, réservation du stock et notification au magasin.
Côté éditorial, chaque page produit affiche les photos en zoom natif, les caractéristiques techniques structurées, le guide des tailles spécifique au modèle, les avis collectés via Google Places API (rich snippet étoiles activé), et une section « Demande d’essai » qui apparaît seulement si le vélo est physiquement présent en magasin (croisement avec le stock sérialisé du CRM).
Côté technique
Le projet est construit sur Next.js 14 avec App Router et React Server Components. TypeScript strict est imposé partout, sans any, sans as unknown as X, et sans @ts-ignore — la cohérence des types entre le client API CRM et les composants est contrôlée par zod à chaque entrée serveur.
Le client API CRM (lib/crm.ts) centralise tous les appels REST vers CRM Cycles, avec authentification par clé API stockée en variable d’environnement CRM_API_KEY. Cette clé n’est jamais exposée côté navigateur : tous les appels passent par des API Routes Next.js server-side, ce qui évite toute fuite de credentials même en cas de prompt-injection ou d’inspection du JS client.
Le panier est géré côté client par Zustand (état persistant en localStorage), avec synchronisation server-side au moment du checkout pour validation finale du stock et des prix. Stripe est branché via webhook (/api/stripe/webhook) qui crée la commande dans CRM Cycles à la confirmation du paiement, avec idempotence par payment_intent_id pour éviter les doublons en cas de retry Stripe.
Le SEO est généré dynamiquement par catégorie / produit via generateMetadata du App Router, avec balisage JSON-LD Product, AggregateRating et BreadcrumbList. Sitemap et robots.txt sont également générés côté serveur, indexés par catégorie pour faciliter le crawl Google sur les gros catalogues.
L’architecture est aucune base de données propre côté Next.js. CRM Cycles reste la source unique de vérité pour les produits, le stock, les clients et les commandes. Le site vitrine est purement un consommateur : il lit le catalogue à chaque request (avec cache Vercel selon TTL), et écrit uniquement à la création d’une commande. Cette séparation rend la mise en blanc-marque triviale : pour ouvrir un nouveau site sous une autre marque cliente, il suffit de cloner le repo, de changer les variables d’environnement (logo, couleurs, URL API CRM, Stripe keys), de déployer sur Vercel et de pointer le DNS.
Mettre à jour un produit depuis l’admin
Pourquoi cette architecture plutôt qu’un Shopify ou un WooCommerce
Shopify et WooCommerce conviennent bien quand le métier d’un commerçant est suffisamment générique pour rentrer dans leur modèle de données (produits simples ou variantes, stock unique, paiement direct). Le commerce du vélo casse ce modèle : produits sérialisés avec numéro de série unique par exemplaire, garanties cadre et vélo qui démarrent à la facturation (et non à l’expédition), Livre de police obligatoire sur les reprises, parc client traçable dans le temps.
En séparant le CRM métier (Yii2) du site vitrine (Next.js), on garde le meilleur des deux mondes : un système métier exhaustif et conforme côté coulisses, et un site marchand moderne et rapide côté client. La synchronisation par API REST évite la double saisie et la désynchronisation, et la déclinabilité blanc-marque permet de déployer la stack pour plusieurs magasins clients sans repartir de zéro.
