Créer un site e-commerce avec l’IA : paiements, sécurité

Pour créer un site e-commerce avec l’IA, vous faites écrire pas à pas par un agent de code le catalogue de produits, le panier et le paiement ; une configuration typique est Next.js, une base de données et un prestataire de paiement comme Stripe. L’agent écrit vite, mais c’est à vous de fixer les règles : les prix sont calculés côté serveur, les paiements sont confirmés par webhook et les données de carte ne sont jamais stockées. Décider d’abord si une plateforme hébergée comme Shopify couvre déjà vos besoins fait partie du travail.

Ce guide commence par cette décision, puis détaille la création d’une boutique sur mesure avec un agent, dans l’ordre : modèle de données, panier, paiement, webhooks, stock, e-mails, pages légales et déploiement. Chaque étape propose des prompts à copier. À la fin, une liste des erreurs que l’IA commet le plus souvent en e-commerce et une liste de contrôle de sécurité.

Première décision : plateforme hébergée ou sur mesure ?

La réponse honnête est souvent « plateforme hébergée ». Shopify, WooCommerce et les plateformes similaires gèrent pour vous les paiements, l’inventaire, les intégrations d’expédition, les taxes et les mises à jour de sécurité.

Le sur-mesure se justifie quand votre parcours de vente n’est pas pris en charge (par exemple des abonnements avec un configurateur de produits sur commande), quand vous ajoutez une boutique dans une application existante, ou quand vous voulez apprendre et garder un contrôle total. C’est la voie que couvre ce guide. Si vous préférez commencer par un simple site vitrine, lisez d’abord comment créer un site web avec l’IA.

1. Stack et installation

Pour un projet de vibe coding, je suggère une stack que les agents connaissent bien et qui est très documentée :

• Next.js (App Router) : pages, code serveur et routes d’API dans un seul projet.
• PostgreSQL : un service managé (Supabase, Neon et similaires) ou Docker en local.
• Un ORM (Prisma ou Drizzle) : le schéma et les migrations vivent dans des fichiers, vous et l’agent lisez donc la même source.
• Un prestataire de paiement : Stripe est le choix courant ; dans certains pays, des prestataires locaux sont la norme (en Turquie, par exemple, iyzico ou PayTR). Ce qu’ils ont en commun : la carte est saisie dans le formulaire du prestataire et le résultat arrive à votre serveur par notification.
• Un service d’e-mails transactionnels : pour les confirmations de commande et les avis d’expédition.

npx create-next-app@latest store
cd store
git status   # create-next-app usually initialises git; if not: git init
claude

2. Le premier prompt : un plan avant le code

Dire à un agent « fais-moi une boutique » vous donne tout d’un coup, avec les parties critiques survolées. Demandez d’abord un plan :

We're building a small ecommerce site with Next.js (App Router), PostgreSQL and Prisma.
Payments will use Stripe Checkout (card data must never reach our server).

Don't write code yet. First produce a plan covering:
1. Data model: product, product variant (size/colour), order, order item, stock.
2. Pages: product list, product detail, cart, checkout return pages, a simple admin.
3. Payment flow: from cart to creating a checkout session to marking the order paid via webhook.
4. Which operations must happen on the server, and why.

Rules:
- Store prices as integers in the smallest currency unit (cents), never floats.
- Never trust a price, total or discount amount sent from the client.
- Secrets live only in .env; no secret ever reaches client code.
Write the plan and wait for my approval.

Lisez le plan, corrigez ce qui ne vous plaît pas, puis implémentez morceau par morceau : modèle de données, puis catalogue, puis panier, paiements en dernier. Faites un commit après chaque morceau.

3. La base de produits

Quelques points que je surveille dans le modèle de données :

• L’argent est un entier. 14,90 $ est stocké comme 1490. Stripe et la plupart des prestataires attendent de toute façon des montants dans la plus petite unité monétaire.
• Les lignes de commande copient le prix. La commande garde le nom et le prix du produit au moment de l’achat, pour qu’un changement de prix demain ne réécrive pas les commandes passées.
• Le stock vit sur la variante. « T-shirt bleu, taille M » a sa propre ligne de stock.
• Le statut de commande est une liste explicite : pending, paid, shipped, cancelled, refunded, etc.

Quand l’agent écrit une migration, lisez le fichier. S’il supprime une table ou une colonne qui contient déjà des données, arrêtez-vous et posez la question.

4. Le panier

Le panier, dans le navigateur (ou dans la base pour les utilisateurs connectés), ne doit contenir que des identifiants de produit/variante et des quantités. Les prix et totaux sont affichés dans le panier mais toujours lus depuis le serveur.

Implement the cart. Store only a list of {variantId, quantity} in localStorage.
The cart page fetches current prices and the total from the server.
Out-of-stock or deleted products show in the cart with a warning.
Limit quantity to 1–10 and enforce that on the server too.

5. Paiement : les prix sont toujours calculés côté serveur

Règle numéro un du e-commerce : ne faites jamais confiance à un prix venant du client. Toute valeur dans le navigateur peut être modifiée ; n’importe qui peut ouvrir les outils de développement et fixer le total à 1 $. Le bon déroulement :

1. Le client n’envoie au serveur que la liste de variantId et quantity.
2. Le serveur lit le prix et le stock de chaque article dans la base et calcule lui-même le total.
3. Le serveur crée une commande au statut pending.
4. Le serveur crée une session de paiement chez le prestataire (une Stripe Checkout Session, ou le formulaire de paiement du prestataire local) et y rattache l’identifiant de la commande.
5. Le client est redirigé vers la page ou l’iframe du prestataire et y saisit sa carte.

Une idée allégée du code serveur :

// app/api/checkout/route.ts (sketch)
const items = await db.variant.findMany({ where: { id: { in: cart.map(c => c.variantId) } } })
const lineItems = cart.map(c => {
  const v = items.find(i => i.id === c.variantId)
  if (!v || v.stock < c.quantity) throw new Error('Out of stock')
  return { price: v.priceCents, quantity: c.quantity }   // price from the DB, not the client
})

Les codes de réduction suivent la même règle : le code vient du client, mais sa validité et le montant qu’il retire sont décidés côté serveur.

6. Webhooks : payé ou non ?

Un client qui arrive sur votre page « paiement réussi » ne prouve pas que le paiement est passé ; cette page peut être ouverte à la main, et le client a pu fermer l’onglet. La source de vérité est la notification que votre prestataire envoie à votre serveur (un webhook chez Stripe, souvent appelé callback chez d’autres prestataires).

Expliquez cela à l’agent pour le point d’accès du webhook :

Write the Stripe webhook endpoint (/api/webhooks/stripe):
- Verify the signature with STRIPE_WEBHOOK_SECRET; reject unsigned or invalid requests.
- Use the raw request body for signature verification.
- On checkout.session.completed, read the order ID from metadata, and inside one
  database transaction mark the order "paid" and decrement stock.
- Make it idempotent: if the same event arrives twice, the second time changes nothing.
- Compare the amount paid with the order total; if they differ, flag the order and log it.

Pour tester en local, la CLI Stripe peut rediriger les événements vers votre machine :

stripe listen --forward-to localhost:3000/api/webhooks/stripe

En mode test de Stripe, des cartes de test comme 4242 4242 4242 4242 permettent de parcourir tout le flux sans argent réel. Les autres prestataires ont aussi des bacs à sable ; demandez à l’agent de lire leur documentation sur la façon de vérifier la signature ou le hash de la notification.

7. Le stock

Le stock est l’endroit où deux personnes peuvent acheter le dernier article au même instant. Les agents écrivent en général « lire, puis écrire », ce qui laisse une condition de concurrence entre les deux. Faites plutôt la vérification et la décrémentation dans une seule requête atomique :

UPDATE variants SET stock = stock - 2
WHERE id = 'var_123' AND stock >= 2;
-- if zero rows were affected, there wasn't enough stock

Décrémenter le stock une fois le paiement confirmé (dans le webhook) est l’option simple ; pour des articles très limités, vous pouvez aussi garder une courte réservation à l’ouverture de la session de paiement. Dites explicitement à l’agent laquelle vous voulez.

8. E-mails

Il vous en faut au moins deux : une confirmation de commande et un avis d’expédition. Envoyez la confirmation depuis le webhook, pas depuis la page de succès, pour qu’elle ne parte que pour les commandes réellement payées. La clé d’API du service d’e-mail reste sur le serveur. Si vous sautez les enregistrements SPF/DKIM que votre fournisseur d’e-mail demande pour votre domaine d’envoi, vos e-mails risquent de finir en spam.

9. Pages légales

Ce n’est pas du code, mais cela fait partie de la boutique. Ce qui est obligatoire dépend de l’endroit où vous et vos clients vous trouvez, mais la plupart des boutiques ont besoin de :

• Une politique de confidentialité (qui indique ce que vous collectez et pourquoi, avec le RGPD ou ses équivalents locaux là où ils s’appliquent)
• Un avis sur les cookies là où il est exigé
• Des conditions de vente
• Une politique de remboursement et de retour, y compris le délai légal de rétractation
• Les informations du vendeur : raison sociale, adresse et coordonnées

Si vous vendez en Turquie, prévoyez un avis de confidentialité KVKK, un contrat de vente à distance et un formulaire de pré-information que le client approuve avant de commander. Vous pouvez demander à l’agent d’ajouter les cases de consentement au paiement et de stocker le consentement avec la commande. L’IA peut rédiger ces textes, mais faites-les relire par un juriste ou un comptable avant la mise en ligne, et interrogez-les sur la facturation et les obligations fiscales.

10. Déploiement

Mettre l’application Next.js sur Vercel et la base sur un service PostgreSQL managé est le chemin le plus court. Avant le lancement :

• Saisissez les variables d’environnement (URL de la base, clés de paiement et d’e-mail, secret du webhook) dans le tableau de bord de votre hébergeur.
• Enregistrez l’URL du webhook de production dans le tableau de bord de votre prestataire de paiement ; ne mélangez pas les clés de test et de production.
• Exécutez les migrations en production de façon délibérée, après avoir fait une sauvegarde.
• Passez une petite vraie commande en production, remboursez-la et vérifiez tout le parcours (e-mail, stock, statut de commande) de vos propres yeux.

Ce que l’IA se trompe à faire en e-commerce

• Calculer le total dans le client et l’envoyer au serveur. Le plus dangereux. Cherchez dans le code un price ou un total venant du client et supprimez-le.
• Marquer la commande payée sur la page de succès. Sans webhook, le statut de la commande ne doit pas changer.
• Sauter la vérification de signature du webhook, ou analyser le corps en JSON avant de vérifier, puis désactiver la vérification parce que « ça ne marche pas ».
• Des flottants pour l’argent. Le problème de 0.1 + 0.2 finit sur les factures.
• Pas d’idempotence. Le même webhook arrive deux fois, le stock baisse deux fois, deux e-mails partent.
• Une administration non protégée. Elle construit une page /admin mais oublie les contrôles d’autorisation sur les routes d’API. Assurez-vous que chaque API d’administration vérifie le rôle côté serveur.
• Passer en production avec des clés de test, ou l’inverse, utiliser des clés de production pendant le développement.

Sécurité

• Ne stockez, ne journalisez et ne collectez jamais de données de carte avec votre propre formulaire. Utilisez la page ou le formulaire de paiement hébergé du prestataire ; cela garde votre périmètre PCI DSS aussi petit que possible.
• Secrets dans .env, avec .env dans .gitignore. Ne mettez jamais de clé secrète (comme sk_...) dans le code client ni dans des variables d’environnement publiques (dans Next.js, celles préfixées par NEXT_PUBLIC_).
• Ne collez jamais de clés d’API dans le chat. Dites à l’agent le nom de la variable, pas la valeur.
• Lisez ce que l’agent exécute. Dans un terminal connecté à une base de production, n’approuvez pas automatiquement les migrations, les DROP ni les UPDATE en masse.
• Lisez chaque diff, surtout le code de paiement et d’authentification. Un second regard est essentiel ici ; la revue de code par IA explique comment le mettre en place.
• Collectez le moins de données personnelles possible, et gardez ce que vous collectez derrière un accès restreint.

Le faire avec AgentVera

Garder plusieurs agents séparés aide sur un projet de boutique, et je le fais avec AgentVera :

• Backend et interface dans des worktrees séparés. Un agent Claude Code travaille sur les paiements, les webhooks et le modèle de données pendant qu’un agent Codex construit les pages produit et l’interface du panier. Chacun est dans son propre worktree git, tous dans un seul espace de travail.
• Gestionnaire de bases de données. Consultez les tables, commandes et stocks créés par l’agent dans le gestionnaire de bases de données sans ouvrir un autre outil ; il prend en charge PostgreSQL, MySQL et SQLite.
• DB Guard. Il analyse les migrations écrites par l’agent à la fin d’un tour ; DB Guard met d’emblée en évidence des risques comme un DROP ou un UPDATE sans WHERE.
• Revue de code et aperçus. À la fin d’un tour, la revue de code fait relire par un second modèle ; les environnements d’aperçu font tourner le serveur de développement de chaque worktree à sa propre adresse. Vous relisez toujours vous-même le diff de paiement avant de fusionner.

Rien de cela ne rend les choses justes à votre place ; cela facilite seulement de voir ce qui a changé.

Liste de contrôle rapide

• Plateforme hébergée ou sur mesure décidé en connaissance de cause
• Prix en entiers dans la plus petite unité ; les lignes de commande copient le prix
• Le panier ne contient que des identifiants et des quantités ; le total est calculé côté serveur
• Les commandes ne passent à « payée » que via un webhook à signature vérifiée ; le webhook est idempotent
• Le stock est décrémenté avec une requête atomique
• L’e-mail de confirmation est envoyé depuis le webhook ; SPF/DKIM configurés
• Confidentialité, conditions, politique de remboursement et informations du vendeur en ligne et relues
• Aucune donnée de carte nulle part ; secrets uniquement côté serveur
• Une vraie commande passée et remboursée en production

Pour conclure

Vous pouvez créer un site e-commerce avec l’IA, et un agent en écrira l’essentiel rapidement. Mais ce qui rend une boutique digne de confiance, l’agent ne le fait pas seul : prix calculés côté serveur, paiements confirmés par webhook, stock décrémenté de façon atomique, aucune donnée de carte conservée, et les bonnes pages légales. Mettez ces règles dans votre premier prompt, testez chaque étape en mode test et relisez toujours le code de paiement avant de le fusionner.