Du design
au développement.

Ce que la plateforme doit faire, pour qui, et avec quelles contraintes. Le contrat fonctionnel.

Objectif

Frank'line est une maison de polos et de maille. La plateforme doit permettre de vendre en ligne (boutique e-commerce), de raconter la marque (magazine éditorial), et de gérer l'activité (back-office). Le polo est le cœur du catalogue ; les compléments (L'Atelier) et la Maison sont secondaires.

Périmètre fonctionnel

Exigences non fonctionnelles

• Performance · LCP < 2,5 s, CLS < 0,1, images < 120 Ko
• Accessibilité · WCAG 2.1 niveau AA, navigation clavier, focus visible
• Responsive · mobile d'abord, 4 breakpoints (≤720 / ≤1000 / ≤1440 / +)
• Sécurité · paiement 3D Secure, données chiffrées, RGPD
• Marque · palette Heritage, zéro vert, zéro cadratin, apostrophe rouge, inspiration Tommy
• International · FR primaire + EN, multi-devises (EUR d'abord)

Recommandation de pile technologique. Le front actuel est statique : il sert de référence visuelle exacte à reproduire dans le framework choisi.

Vue en couches. Le client et l'admin sont deux applications distinctes consommant la même API.

Modèle relationnel (schéma conceptuel). ● clé primaire · ● clé étrangère.

• product 1 ··· N variant (un polo a plusieurs couleurs/tailles)
• customer 1 ··· N order 1 ··· N order_item N ··· 1 variant
• customer 1 ··· N address et 1 ··· N wishlist
• user (admin) isolé des customer · table et authentification séparées

REST, réponses JSON. Préfixe /api/v1. Authentification par jeton (Bearer) pour les routes privées.

// 200 OK
{
  "id": "a3f…",
  "name": "Polo Colette",
  "category": "femme",
  "price_cents": 8900,
  "variants": [
    { "sku": "COL-BLU-S", "color": "Blush", "size": "S", "stock": 4 },
    { "sku": "COL-BLU-M", "color": "Blush", "size": "M", "stock": 11 }
  ],
  "monogram_available": true
}

Frank'line se déploie en Côte d'Ivoire, en Afrique de l'Ouest puis à l'international. Le système de paiement est donc multi-canal : mobile money local, cartes, et agrégateurs régionaux, branchés derrière une couche d'abstraction unique.

Couche d'abstraction paiement

L'application ne parle jamais directement à un opérateur. Elle passe par un service Paiement interne qui expose une interface unique (createPayment, confirmPayment, refund) et route vers le bon fournisseur selon le pays, la devise et le moyen choisi. On peut ainsi ajouter/retirer un opérateur sans toucher au checkout.

Mobile money Afrique de l'Ouest

Agrégateurs recommandés

Plutôt que d'intégrer chaque opérateur un par un, on s'appuie sur un agrégateur qui réunit Orange/MTN/Moov/Wave + cartes en une seule API. Choix recommandé selon couverture :

International

• Cartes · Visa, Mastercard, Amex (3D Secure)
• Wallets · Apple Pay, Google Pay, PayPal
• Paiement fractionné · 3× / 4× (selon marché)

Devises & tarification

Flux mobile money (ex. Orange Money / Wave)

Le paiement mobile money est asynchrone : la commande reste en attente de paiement jusqu'au webhook de confirmation. L'écran de checkout affiche un état « en attente de validation sur votre téléphone » avec compte à rebours et reprise possible.

Deux mondes séparés : les clients (boutique) et les utilisateurs internes (back-office). Jamais la même table, jamais le même jeton.

• Jetons JWT courte durée + refresh token httpOnly
• Double authentification (2FA) obligatoire pour ADMIN
• Journal des accès back-office (qui, quoi, quand)
• Invitation collaborateur par e-mail avec rôle pré-assigné, expiration 72h

Les parcours critiques, étape par étape.

Commande + paiement

Cycle de vie d'une commande

confirmée → en préparation (atelier, +5j si monogramme) → expédiée (n° suivi transporteur) → en livraison → livrée. Chaque transition notifie le client et s'affiche dans la traçabilité (côté client) et le back-office (côté admin).

Réapprovisionnement

Quand stock_qty passe sous un seuil défini par variante, une alerte apparaît au tableau de bord et un bon de commande fournisseur peut être généré. La chaîne d'appro (filature → tissage → coupe → broderie → contrôle) est suivie par étapes.

Services tiers, branchés via API/webhooks depuis le back-office.

Les briques techniques partagées par toute la plateforme, au-delà du métier.

Le prototype se déploie déjà en statique via GitLab Pages. En production, le même pipeline build les apps et l'API.

# .gitlab-ci.yml (production)
stages: [ lint, test, build, deploy ]

lint:    # eslint + stylelint + prettier
test:    # unitaires (jest) + e2e (playwright)
build:   # build front boutique + admin + api (docker)
deploy:  # push images → registre → orchestrateur
  environment: production
  only: [ main ]

DATABASE_URL=postgres://…
STRIPE_SECRET_KEY=sk_live_…
STRIPE_WEBHOOK_SECRET=whsec_…
JWT_SECRET=…
S3_BUCKET / S3_KEY / S3_SECRET=…
MAIL_API_KEY=…
META_APP_ID / META_APP_SECRET=…

Surveiller la santé de la plateforme et garantir sa visibilité dès la mise en ligne.

Séquence recommandée pour passer du prototype à la production.