MVP e‑commerce en 7 jours : expédiez une petite boutique avec paiements réels

Ce que vous livrez (et ce que vous ne livrez pas)

Pour un MVP e‑commerce que vous pouvez finir en une semaine, « paiements réels » veut dire une chose : un vrai client peut payer, vous voyez la commande, et vous pouvez l’expédier sans deviner.

Gardez la première version étroite : un seul pays, une seule devise et une seule méthode de paiement (généralement les cartes). Si vous essayez de tout supporter, vous passerez la semaine sur des cas limites au lieu de vendre.

Le chemin le plus court est une toute petite boutique qui ne fait que les étapes nécessaires pour transférer de l’argent et déclencher la préparation :

• Une page produit avec un prix clair et l’état du stock
• Un panier qui permet de changer la quantité et d’afficher les totaux
• Un checkout qui collecte nom, email et adresse de livraison
• Une page de confirmation (et un reçu par email si possible)

« Fini » n’est pas une vitrine parfaite. « Fini » c’est prendre une commande, prélever avec succès, et l’expédier le jour même en utilisant les infos collectées. Si vous y arrivez pour 10 commandes d’affilée sans corrections manuelles, vous avez un MVP fonctionnel.

Pour protéger cet objectif, décidez d’emblée ce qui est hors périmètre. Ces fonctionnalités semblent standards, mais elles ne sont pas nécessaires cette semaine : listes d’envies, avis, recherche avancée, règles d’inventaire complexes, coupons, méthodes de paiement multiples et devises multiples.

Choisissez d’abord une cible d’appareil. Si la majorité des acheteurs vient des publicités sociales, optez pour un web mobile‑first. Si vous vendez aux entreprises, un desktop‑first peut convenir. Dans tous les cas, concevez pour une taille d’écran d’abord, puis adaptez.

Si vous construisez avec un outil piloté par chat comme Koder.ai, écrivez le périmètre avant de générer écrans et flux. Un périmètre strict est la façon la plus simple d’empêcher le « encore une fonctionnalité » de se transformer en jour 8.

L’ensemble de fonctionnalités le plus petit qui fonctionne

Un MVP e‑commerce est « réel » quand un inconnu peut trouver un produit, payer, et vous pouvez exécuter la commande sans échanges multiples par email.

Commencez par les produits. Il vous faut un titre, un prix, une image principale, une courte description et un drapeau actif/inactif pour masquer un article sans le supprimer. Gardez variantes, bundles et tarifications complexes pour plus tard.

Votre catalogue peut rester simple : une page liste produits et une page détail produit. Des filtres basiques (catégorie ou en stock) sont acceptables, mais ne construisez pas un moteur de recherche complet la première semaine.

Panier et checkout doivent être ennuyeux et prévisibles. Le panier doit permettre ajout, suppression, changement de quantité et afficher un sous‑total clair. Pour la livraison et la taxe, choisissez d’abord une règle simple (par exemple frais de port fixes et taxe uniquement si nécessaire).

Un flux minimal de bout en bout a généralement besoin de :

• Liste produits
• Détail produit
• Panier
• Checkout (infos client + adresse de livraison + récapitulatif)
• Zone admin (produits et commandes)

L’admin est souvent l’endroit où les MVP échouent. Vous n’avez pas besoin de graphiques. Vous avez besoin d’un login sécurisé, d’un moyen d’ajouter/modifier des produits et d’une liste de commandes où changer le statut (new, paid, shipped, refunded).

Exemple : vous vendez trois bougies. Chacune a une photo et un prix. Un acheteur ajoute deux unités, voit 5$ de frais de port fixes, saisit son adresse, paie, puis vous marquez la commande expédiée après impression de l’étiquette.

Si vous utilisez une plateforme vibe‑coding comme Koder.ai, gardez le prompt strict : « Seulement ces pages, seulement ces champs, pas de comptes, pas de coupons, pas de wishlists. »

Paiements : restez réaliste et sans fantaisie

Les paiements sont l’endroit où éviter la créativité. Choisissez un fournisseur que vous pouvez onboarder rapidement et ne livrez que le paiement par carte. Portefeuilles numériques, BNPL et virements peuvent attendre.

Le plus grand choix est le flux de paiement :

• Le checkout hébergé est généralement le plus rapide et le plus sûr, car le fournisseur gère la plupart de l’UI sensible.
• Les formulaires de carte intégrés peuvent paraître plus esthétiques, mais ajoutent des cas limites et du travail de sécurité.

Considérez les paiements comme un petit ensemble d’états simples à comprendre : created, paid, failed, canceled, refunded.

Stockez seulement ce dont vous avez besoin pour la réconciliation et le support : l’ID de paiement du fournisseur, éventuellement l’ID client/session du fournisseur, le montant, la devise et votre ID de commande interne. Ne stockez jamais les données brutes de carte et n’inventez pas de champs de paiement sauf si nécessaire.

Les webhooks rendent les commandes fiables. Après le checkout, ne supposez pas qu’une redirection navigateur signifie « payé ». Ajoutez un handler de webhook qui vérifie l’événement, puis marque la commande correspondante comme payée.

Rendez cela sûr face aux rejets répétés. Les webhooks peuvent être livrés plusieurs fois, donc votre handler doit être idempotent : si une commande est déjà marquée payée, il ne doit rien faire mais tout de même renvoyer un succès.

Si vous construisez rapidement avec un générateur piloté par chat comme Koder.ai, définissez d’abord les états de paiement et les champs minimaux, puis générez le endpoint webhook et la logique de mise à jour de commande. Cette clarté évite le désordre classique : clients payés, commandes non marquées et heures de vérification manuelle.

Plan jour par jour pour la construction en 7 jours

Jour 1 : verrouillez le périmètre. Rédigez une spécification d’une page : ce que peut faire un acheteur, ce que peut faire un admin et ce qui est hors périmètre. Choisissez un fournisseur de paiement. Décidez comment calculer les totaux (taxe/frais maintenant ou plus tard). Esquissez cinq écrans clés : catalogue, page produit, panier, checkout, résultat paiement.

Jour 2 : livrez le catalogue. Stockez les produits avec seulement les champs nécessaires : nom, prix, devise, photo, courte description, drapeau actif. Construisez une page « tous les produits » (ou catégories simples) et une page détail produit. Ajoutez environ 10 produits de test pour valider les flux réels.

Jour 3 : panier et brouillons de commande. Implémentez ajout/suppression et modifications de quantité. Quand le checkout démarre, créez un brouillon de commande et snapshottez les prix pour que les modifications futures de produit n’altèrent pas les anciennes commandes. Capturez l’email client et l’adresse de livraison tôt.

Jour 4 : paiements en mode test. Connectez le checkout à la création de paiement. Gérez success, canceled et failed. Sauvegardez le statut de paiement sur la commande. Affichez une page de confirmation claire avec le numéro de commande et les étapes suivantes.

Jour 5 : admin basique pour la préparation. Réduisez l’admin au strict nécessaire : créer/éditer/désactiver un produit, une liste de commandes avec mise à jour des statuts (paid, packed, shipped, refunded) et une page « voir commande » avec les infos nécessaires pour expédier.

Jour 6 : déploiement et sécurisation. Mettez en place staging et production séparés, activez les logs et répétez le flux complet avec des cartes de test. Rédigez un plan de rollback avant d’en avoir besoin.

Jour 7 : mise en production (contrôlée). Faites une dernière vérification avec un achat réel de faible montant, confirmez emails/reçus, puis ouvrez la boutique à une audience restreinte. Si vous utilisez Koder.ai, prenez un snapshot avant chaque changement majeur afin de pouvoir revenir rapidement si le checkout casse.

Données à stocker pour éviter les commandes confuses

Une boutique semaine‑un vit ou meurt sur la clarté des commandes. Une fois payé, vous devez pouvoir répondre rapidement : qu’a‑t‑il acheté, où l’expédier et quel est l’état actuel ?

Commencez avec un modèle de données petit et ennuyeux. Ces cinq enregistrements couvrent presque tout :

• Product : id, title, price, currency, active
• Customer : id, email, name (optionnel)
• Order : id, customer_id (ou email), champs d’adresse de livraison, status, snapshot des totaux, created_at
• OrderItem : order_id, product_id, title_snapshot, unit_price_snapshot, quantity
• Payment : order_id, provider, provider_payment_id, amount, currency, status, raw_event_id

Conservez les adresses minimales pour que le checkout reste rapide : généralement nom, ligne1, ville, code postal et pays. Le téléphone peut être optionnel sauf si votre transporteur l’exige.

Enregistrez les totaux comme snapshot au moment de l’achat. Ne recalculiez pas les totaux plus tard depuis la table Product. Les prix changent, les frais de port sont ajustés et vous vous retrouverez avec « le client a payé X mais la commande montre maintenant Y ». Stockez le prix unitaire par article, ainsi que sous‑total, frais de port, taxe (même si zéro) et total général.

Utilisez des statuts clairs qui correspondent à la préparation, pas au jargon du fournisseur de paiement : new, paid, packed, shipped, canceled. Ajoutez refunded seulement si vous le supportez réellement.

Prévoyez l’idempotence pour les mises à jour de paiement. Le même webhook peut arriver deux fois ou hors ordre. Stockez un identifiant d’événement unique du fournisseur et ignorez les doublons.

Exemple : un webhook marque le paiement « succeeded » deux fois. Votre système ne doit pas créer deux envois ni envoyer deux emails de confirmation. Si vous construisez sur Koder.ai avec un backend en Go et PostgreSQL, une contrainte unique sur (provider, raw_event_id) plus une transaction autour de la mise à jour de statut suffit souvent.

Admin basique : uniquement ce qui aide à expédier

L’admin n’est pas un « tableau de bord ». C’est une petite arrière‑boutique où vous répondez vite à trois questions : que vendez‑vous, qu’est‑ce qui a été payé et qu’est‑ce qui doit être expédié.

Commencez avec un seul login admin. Un seul rôle suffit. Utilisez un mot de passe fort, une limitation basique de requêtes et un timeout de session court. Évitez la gestion du staff et les permissions cette semaine. Si une seconde personne doit aider, partagez l’accès volontairement et faites une rotation du mot de passe ensuite.

Gardez la gestion des produits simple : créer/éditer des produits, téléverser une image principale, définir le prix, basculer la disponibilité. Pour l’inventaire, ne mettez pas en place des comptes à moins d’en disposer réellement. Un interrupteur en stock / hors stock suffit souvent.

La vue commandes doit ressembler à un bon de préparation. Facilitez la recherche par ID de commande ou email client, puis affichez :

• Nom client, email, adresse de livraison
• Articles, quantités et totaux finaux (incluant livraison et taxe)
• Statut du paiement (paid, failed, refunded)
• Statut de fulfillment (new, packed, shipped)
• Horodatages et une courte note interne

Pour les actions de statut, limitez‑vous à deux boutons : « Mark packed » et « Mark shipped ». Quand vous marquez comme expédié, enregistrez éventuellement une note de suivi (transporteur + numéro, ou « Retrait local arrangé »). Les emails automatiques peuvent attendre si leur mise en place vous ralentit.

L’export CSV est optionnel. Ajoutez‑le seulement si vous savez que vous l’utiliserez la première semaine.

Si vous utilisez un outil comme Koder.ai, gardez l’admin dans la même app mais protégez la route et exigez une session valide.

Étapes pour obtenir le premier paiement réussi

Commencez en mode test. Votre but n’est pas « une page de checkout ». Votre but est une commande payée, enregistrée et prête à être expédiée.

Règle impérative : ne stockez jamais les données brutes de carte sur votre serveur. Utilisez un checkout hébergé ou une tokenisation côté client pour que les données sensibles aillent directement chez le fournisseur.

Le chemin vers votre première commande payée

1. Créez un produit de test et un prix sur le serveur. Le checkout doit récupérer les prix depuis la base, pas depuis le navigateur.
2. Démarrez une session de checkout en mode test. Votre backend crée la session de paiement et renvoie seulement ce dont le client a besoin pour rediriger.
3. Protégez contre les clics multiples. Désactivez le bouton Payer après le premier clic. Utilisez une clé d’idempotence côté serveur (par exemple l’ID du panier + une fenêtre temporelle) pour que les doublons retournent la même session au lieu de créer un second prélèvement.
4. Vérifiez le paiement côté serveur. Considérez le webhook du fournisseur comme source de vérité. Ne marquez la commande payée qu’après avoir confirmé que l’événement est réel et correspond au montant et à la devise attendus.
5. Testez les chemins d’erreur. Simulez un paiement échoué, un checkout annulé et une session expirée. Chacun doit aboutir à un état de commande clair, pas à une situation floue.

Facilitez la correction des erreurs

Consignez les erreurs de paiement avec le contexte actionnable : ID commande, ID session, email client (si disponible), total attendu, code d’erreur du fournisseur et un message court comme « Amount mismatch » ou « Webhook signature invalid ».

Exemple : un client essaie d’acheter deux mugs. Votre serveur calcule 24$ + livraison, crée la session et enregistre une commande en attente. Si le client ferme la page, la commande devient annulée. S’il paie, le webhook la bascule en paid et vous pouvez la préparer en toute confiance.

Un workflow de déploiement sûr que vous pouvez suivre

Quand vous n’avez qu’une semaine, les déploiements deviennent souvent la cause silencieuse des pannes du checkout. L’objectif n’est pas du DevOps sophistiqué mais une routine répétable qui réduit les surprises et offre un filet de secours.

Mettez en place deux environnements : staging et production. Staging doit ressembler le plus possible à la production : mêmes réglages, mêmes templates, mêmes règles taxe/livraison, mais paiements en mode test. Faites les vérifications finales sur staging, puis promouvez exactement le même build en production.

Utilisez des releases versionnées. Même si c’est juste v1, v2, v3, taggez chaque release et gardez la précédente prête. Le rollback doit être une action : revenir au build précédent ou restaurer un snapshot. Si votre plateforme prend en charge snapshots et rollback (Koder.ai le fait), prenez‑les avant chaque release.

Considérez les migrations de base comme risquées pendant la semaine MVP. Préférez les changements rétro‑compatibles : ajoutez des tables ou colonnes, ne renommez ni ne supprimez encore, et gardez les anciens chemins fonctionnels jusqu’à la stabilité du nouveau release. Si vous devez backfiller des données, faites‑le dans un job séparé, pas dans une requête utilisateur.

Gardez les secrets hors du repo. Utilisez des variables d’environnement ou un gestionnaire de secrets pour clés API, secrets de signature webhook, URLs de base, mots de passe admin.

Checklist de release :

• Confirmez que le checkout staging fonctionne de bout en bout avec une carte de test et un événement webhook
• Exécutez les migrations sur staging puis production et confirmez que la création de commandes fonctionne toujours
• Vérifiez l’envoi et l’apparence des emails (confirmation commande, paiement échoué)
• Prenez un snapshot pré‑release et notez la version
• Faites une seconde revue rapide : une personne déploie, une autre vérifie la checklist

Pièges courants qui ralentissent un MVP en 7 jours

La façon la plus rapide de rater l’objectif est de construire des fonctionnalités « sympas » qui cassent silencieusement le flux d’argent. Le but est une boutique qui prend un paiement, crée une commande fiable et vous permet de l’expédier.

Une erreur courante est de laisser le navigateur décider du prix final. Si totaux, remises ou livraison sont calculés côté client, quelqu’un finira par payer un mauvais montant. Faites du serveur la source unique de vérité : reconstruisez la commande depuis les IDs produits et quantités, puis recalculer les totaux avant de créer le paiement.

Les règles de livraison et de taxe sont aussi des goulets d’étranglement. Des équipes perdent des jours à supporter chaque pays et cas limites. Pour la semaine un, choisissez une règle simple et tenez‑vous‑y.

Les paiements peuvent aussi paraître fonctionner en checkout mais échouer en production si les webhooks manquent. Un client paie, mais votre base ne marque pas la commande comme payée et la préparation stagne. Considérez la gestion des webhooks comme obligatoire.

Cinq pièges à surveiller :

• Faire confiance aux totaux côté client au lieu de recalculer au serveur
• Construire des tableaux de livraison et taxe complexes avant d’avoir la demande
• Sauter les webhooks et se reposer uniquement sur les pages de redirection
• Oublier un message de confirmation clair ou un email
• Déployer directement en production sans possibilité de rollback

Exemple : un client termine le paiement puis ferme l’onglet avant le chargement de la page de succès. Sans webhooks, il suppose que le paiement a échoué, réessaie, et vous pouvez vous retrouver avec des prélèvements en double.

Si vous travaillez avec Koder.ai, utilisez snapshots et rollback dans votre routine : poussez de petites modifications, conservez une version connue bonne et restaurez vite si quelque chose casse.

Vérifications rapides avant d’activer les paiements live

Faites ces contrôles d’abord en staging, puis répétez‑les juste avant de passer en real. L’objectif est simple : un client paie une fois, vous l’enregistrez une fois, et vous pouvez expédier.

Commencez par le parcours acheteur. Ajoutez un produit au panier, complétez le checkout et assurez‑vous d’atterrir sur une page de succès claire. Vérifiez que la commande payée apparaît dans l’admin avec les bons totaux.

Testez ensuite les webhooks de manière robuste : délais et réessais. Les webhooks peuvent arriver tard, deux fois ou hors ordre. La logique de mise à jour doit être idempotente pour que les réessais ne créent jamais de doublons.

Checklist pré‑lancement :

• Passez une commande de test de bout en bout et confirmez qu’elle apparaît en admin avec l’ID de transaction enregistré
• Renvoyez le même événement webhook et confirmez qu’il n’y a pas de duplication
• Désactivez un produit et confirmez qu’il disparaît et ne peut plus être acheté
• En admin, faites passer une commande par les statuts (new -> paid -> shipped) et ajoutez une note interne
• Déployez une petite modification et restaurez‑la en quelques minutes sans perdre les données de commande

Faites une réelle transaction live avant d’annoncer quoi que ce soit. Utilisez une vraie carte, un petit montant et votre adresse. Vous devriez voir la commande apparaître exactement une fois, avec un horodatage et un statut clairs.

Si vous utilisez Koder.ai, entraînez‑vous avec des snapshots : déployez, passez une commande, restaurez, et confirmez que les commandes existantes se chargent correctement.

Scénario exemple : une petite boutique prête à expédier cette semaine

Imaginez un petit torréfacteur qui veut vendre 12 sacs de café en ligne. Il n’a pas besoin d’abonnements, d’avis ou d’un programme de fidélité. Il a besoin d’une boutique simple qui prend de l’argent réel et crée des commandes propres qu’il peut préparer.

Au jour 2, le catalogue suffit si chaque produit a une photo claire, un prix et une courte description (niveau de torréfaction, notes de dégustation, taille du paquet). Gardez les options minimales : une taille par produit et une option d’expédition (par exemple tarif fixe dans un seul pays).

Au jour 4, le checkout fait une chose : collecter les détails de livraison, prendre une carte et afficher une page de confirmation que le client peut imprimer/screenshot. Affichez un ID de commande et un bref récapitulatif (articles, total, adresse). Si le client contacte le support, cet ID est le moyen le plus rapide de retrouver la commande.

Au jour 5, l’admin reste volontairement sobre. Le torréfacteur se connecte, voit les nouvelles commandes et les fait progresser : paid, packed, shipped. Le tracking peut venir plus tard. La première semaine, une note comme « Expédié via service postal, étiquette imprimée à 15h10 » suffit souvent.

C’est aussi un périmètre qui fonctionne bien avec des générateurs chat‑first comme Koder.ai : un petit ensemble d’écrans, quelques tables et un workflow clair.

Semaine 2 : idées à attendre — codes promo, meilleure recherche, comptage d’inventaire, plus d’emails automatisés. Ajoutez‑les seulement après que des commandes réelles vous disent ce qui compte.

Prochaines étapes après la mise en ligne du MVP

Considérez la première semaine live comme un sprint d’apprentissage. Faites passer des commandes réelles, puis supprimez la plus grosse friction que vous pouvez prouver.

Commencez par un petit pilote : visez 10 commandes payées provenant d’amis, collègues ou d’une petite audience que vous pouvez contacter directement. Demandez à chaque personne où elle a hésité. Suivez les abandons dans une feuille simple : page produit -> panier -> checkout démarré -> paiement réussi.

Après le pilote, n’ajoutez qu’un seul changement à la fois. Les meilleures améliorations initiales sont souvent simples : frais de port plus clairs, meilleures photos produit, moins de champs au checkout. Choisissez le prochain blocage le plus important d’après vos notes, corrigez‑le et lancez une nouvelle petite série.

Le support client vous montrera aussi rapidement ce qui manque. Préparez des réponses courtes pour les questions fréquentes : où est ma commande, puis‑je annuler, pourquoi le paiement a‑t‑il échoué, combien coûte la livraison et quand arrivera‑t‑elle, puis‑je modifier mon adresse.

Si vous voulez itérer vite sans risquer le checkout, Koder.ai peut vous aider à générer la version suivante depuis le chat et à utiliser snapshots/rollback pour tester les changements en sécurité avant de les pousser en production.