Comment ajouter l'e-commerce à un site existant

Votre site existe. Il a été fait à la main, généré par une IA, ou monté sur un CMS. Il vous plaît. Et maintenant vous voulez encaisser dessus.

Les trois chemins, et ce qu'ils coûtent

Migrer vers une plateforme

Vous refaites le site dans le thème d'une plateforme. Vous héritez d'un back-office complet, et vous perdez la mise en page que vous aviez, la structure d'URL qui était indexée, et la liberté de changer de frontend plus tard.

C'est le bon choix si le site actuel est un prototype. C'est un mauvais calcul s'il fonctionne déjà.

Installer une extension dans son CMS

Rapide, tant que votre CMS a l'extension qui va bien. Vous héritez de son modèle de données, de son rythme de mises à jour, et de ses limites le jour où vous voudrez vendre autrement : une prestation avec rendez-vous, un service récurrent, un devis.

Brancher un backend commerce

Votre site reste ce qu'il est. Le catalogue, le panier, le checkout, les paiements, les commandes et les factures vivent dans un service séparé, que votre site appelle en HTTP. On appelle ça du commerce headless : un moteur de commerce sans tête, la tête étant votre site.

votre site (inchangé)
      |
      |  HTTP
      v
 backend commerce
      |-- catalogue, panier
      |-- checkout hébergé
      |-- PSP (Stripe, PayZen, Sogecommerce...)
      |-- commandes, factures, emails
      v
   webhooks vers votre système

Ce qu'il faut vérifier avant de choisir

Quatre questions, dans cet ordre.

1. Qui encaisse ? Sur votre compte chez votre prestataire de paiement, ou sur celui de la plateforme qui reverse ensuite ? La réponse change votre trésorerie et votre comptabilité.

2. Quelle commission ? Un pourcentage sur le chiffre d'affaires n'est pas un abonnement : il grandit avec vous, et il s'ajoute aux frais du PSP.

3. Qui possède les données ? Vos clients, vos commandes, vos factures : peut-on les sortir par API, ou sont-ils prisonniers d'un back-office ?

4. Qu'est-ce qui fait foi pour un paiement ? La réponse correcte est la notification signée du prestataire de paiement, jamais le retour du navigateur. Un service qui marque une commande payée parce que le client est revenu sur la page de confirmation encaissera un jour des commandes que personne n'a payées.

La marche à suivre, avec un backend commerce

Voici le parcours concret, avec Ts-Shop comme exemple. Les principes valent pour tout backend headless.

1. Créer la boutique et ses services. Nom, devise, régime de TVA, préfixes de numérotation. Au Lot 1, Ts-Shop ne vend que des Disponibleservices : des prestations, pas des articles à expédier.

2. Brancher un prestataire de paiement. DisponibleStripe, PayZen, Sogecommerce aujourd'hui. Vous saisissez vos clés de test et vos clés de production, et un interrupteur dit lequel des deux jeux encaisse. L'argent va sur votre compte.

3. Afficher le catalogue sur votre site. Un GET sur l'API publique rend les services, leurs prix et leur devise. Les prix viennent toujours de l'API : les recopier dans le code est la façon la plus sûre d'afficher un tarif qui n'est plus le bon.

4. Ouvrir un panier, puis un checkout. Le panier est anonyme et recalculé à chaque lecture. Le checkout est hébergé par le backend : c'est lui qui collecte l'acheteur et l'envoie au paiement.

5. Laisser la notification faire foi. Le PSP signe un message qui dit que le paiement a eu lieu ; c'est ce message, et lui seul, qui fait passer la commande à payée, déclenche la facture et l'email.

À quoi ressemble un appel

Le catalogue se lit sans authentification : c'est une vitrine.

curl https://api.ts-services.com/v1/shop/public/stores/ma-boutique/products

Et côté site, un bouton « Réserver » ouvre un panier puis un checkout :

const panier = await fetch(`${API}/public/carts`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ storeSlug: "ma-boutique" }),
}).then((r) => r.json());

await fetch(`${API}/public/carts/${panier.id}/items`, {
  method: "POST",
  headers: { "Content-Type": "application/json", "X-Cart-Token": panier.token },
  // Le prix n'est PAS envoyé : il est celui du catalogue, calculé par le
  // serveur. L'envoyer reviendrait à le laisser choisir au client.
  body: JSON.stringify({ productId, quantity: 1 }),
});

Et le référencement ?

C'est l'argument décisif en faveur du headless quand le site existe déjà : vos URL ne bougent pas. Les pages restent servies par votre frontend, avec votre structure, vos balises et votre historique. Seuls s'ajoutent des appels serveur-à-serveur et un checkout qui vit ailleurs.

Une migration de plateforme, à l'inverse, change les URL, les gabarits et les balises d'un coup. Cela se rattrape avec des redirections, mais cela se paie quelques mois.

Questions courantes

Faut-il savoir coder ? Pour brancher une API, oui, un peu. Si votre site a été généré par un outil comme Loveable ou Base44, l'assistant peut écrire l'intégration à partir du serveur MCP.

Que se passe-t-il si je change de frontend plus tard ? Rien du côté commerce : le catalogue, les commandes et les factures sont dans le backend, pas dans le thème.

Et si je veux vendre des produits physiques ? Ts-Shop ne le fait pas aujourd'hui : le stock et la livraison sont des lots ultérieurs, et un produit physique sans livraison donne une commande qu'on ne sait pas expédier.

Pour aller plus loin

• Headless commerce : définition et architecture
• Pourquoi le webhook PSP est la source de vérité du paiement
• Comment ajouter l'e-commerce à un site Loveable