Publié le
ERP e-commerce : le stock, pas la vitrine
La vitrine vend. L'entrepôt sait. Quand les deux ne sont pas le même chiffre, on survend, on rembourse, on brûle de la pub pour un SKU fantôme. Un ERP e-commerce, ce n'est pas une plus jolie boutique. C'est le stock qui a le dernier mot.
La boutique n’est pas le système de gestion
Le flux catalogue part de quelque part. Prix, stock, visuel, variation, langue. S'il part de la boutique, l'entrepôt découvre les nouveautés sur le site. S'il part de l'ERP, la boutique affiche ce qui existe vraiment. Le second est plus ennuyeux à vendre, et c'est le seul qui ne survend pas. Un flux, ce n'est pas un export CSV du lundi. C'est un contrat : fréquence, rejet, qui gagne en cas d'écart.
La synchronisation de stock en temps réel n'est pas un badge marketing. C'est : une unité vendue sur un canal disparaît des autres avant le prochain clic. Pas toutes les quinze minutes. Pas « presque ». Une marketplace qui vend pendant que le site vend, c'est un avoir, un avis, un coût d'acquisition jeté. Le temps réel a un prix, et il se paie en modèle de réservation, pas en cron.
Les retours marketplace ne sont pas des avoirs de magasin. Ils arrivent en masse, parfois sans le colis, parfois avec le mauvais SKU, parfois hors délai mais « selon les CGU du canal ». L'outil doit savoir ce qui est revendable, ce qui est détruit, ce qui est réclamé au canal. Un état « retour » unique, c'est un tiroir. Quatre états, c'est de l'exploitation.
Le multi-canal, ce n'est pas « on est partout ». C'est un stock, plusieurs promesses de délai, plusieurs règles d'annulation. Promettre 24 h sur un canal et 72 h sur l'autre, sur la même pièce, exige que l'allocation soit consciente. Sinon le premier clic gagne, et le second client paie le service client.
TVA OSS, retours, et le canal qui désynchronise
La TVA OSS n'est pas un taux dans le front. C'est un régime, un pays de destination, un seuil, une déclaration. + 4 000 € à 10 000 € HT dès qu'on facture hors euro ou qu'on affiche une langue d'écran par marché. Le multi-devise n'est pas une traduction : c'est un cours, un historique, une pièce. Le mettre dans la boutique et dans l'ERP, c'est le mettre nulle part.
Chaque marketplace est un connecteur. + 2 000 € à 5 000 € HT quand l'API tient sa doc. Beaucoup ne la tiennent pas : webhooks qui disparaissent, champs qui changent, quotas. On le teste sur un échantillon, on chiffre le vrai, on refuse le « on a un plugin ». Un plugin, c'est le planning de quelqu'un d'autre.
+ 8 000 € à 18 000 € HT dès que l'entrepôt n'est plus un fond de garage : lots, deux dépôts (propre et 3PL), inventaire. Le 3PL qui pousse un stock la nuit, le site qui vend le jour : sans réservation côté ERP, on survend à 3 h du matin. C'est un problème d'ops, pas de « growth ».
Un connecteur par canal, le stock au milieu
Le marchand visé ici n'est pas une marque en lancement. C'est une ops : entrepôt, SAV, compta, 40 personnes qui touchent l'outil, parfois plusieurs sociétés (boutique, logistique, UE). Profil B : 98 000 € HT de mise en service, 17 000 € HT par an, postes détaillés. Les connecteurs se comptent. Le stock se compte. La devise se compte. Quatre facteurs majeurs, on arrête d'additionner, on rechiffre — amplitudes.
Une boutique seule, un canal, un dépôt, n'a pas besoin d'un ERP. Elle a besoin d'un front qui marche et d'une compta. Cette page n'existe pas pour lui vendre un système. Elle existe pour l'ops qui a déjà survendu deux fois ce trimestre.
La pub paie le clic. Le stock mentant paie l'avoir, l'avis, le coût d'acquisition brûlé. On le voit dans les logs, pas dans le ROAS. Un projet e-commerce qui commence par refaire la home a déjà choisi le mauvais bout. On commence par l'allocation : quelle unité, quel canal, quelle promesse de délai. Le reste — le visuel, le merchandising — n'est pas l'ERP. C'est le front. On le laisse au front.
Un 3PL qui pousse un fichier à 2 h, une marketplace qui vend à 2 h 12, un site qui vend à 2 h 13 : sans réserve côté gestion, les trois croient la même pièce disponible. Ce n'est pas un problème de « scalabilité ». C'est un problème de qui a le droit de promettre. L'ERP, s'il existe, est ce droit. Sinon c'est le hasard, et le hasard se lit dans les tickets SAV.
Vendre en ligne n'est pas du négoce de comptoir, ni de la production. Bâtiment · Industrie · PME · Transport · Négoce · Santé · Intérim · Groupe.
Le cadrage se fait sur un SKU survendu, un retour marketplace, une déclaration OSS. Pas sur une maquette de home.
Les questions d’ops e-commerce
On a déjà une boutique en ligne. Pourquoi un ERP ?
Parce que le front ne connaît pas votre coût, votre dépôt, votre facture, votre retour. Il connaît un catalogue et un panier. Le jour où deux canaux vendent la même SKU, le front ment. L'ERP, lui, est le stock. La boutique s'y branche, elle ne le remplace pas.
Un connecteur marketplace, vous le chiffrez comment ?
Par flux, pas « le e-commerce ». Une API documentée, + 2 000 € à 5 000 € HT. Aller-retour (commandes, stocks, retours), plus cher qu'un export. Un format propriétaire, encore au-dessus. Trois marketplaces, trois connecteurs. Les empiler « pour voir » est une façon de découvrir le vrai budget en cours de route.
La TVA OSS, c’est dans le front ou dans l’ERP ?
Dans le système qui facture. Si le front facture, il doit connaître le régime. S'il ne fait que vendre et que la pièce part de l'ERP, c'est l'ERP. Les deux à la fois, c'est deux TVA, et un contrôle. On choisit un endroit. On le documente.
Ça ressemble à quel profil ?
Un marchand qui a déjà un entrepôt, une marque, plusieurs canaux, 40 utilisateurs côté ops : profil B, 98 000 € HT de mise en service, 17 000 € HT par an. Le front n'est pas dans ce prix. Les connecteurs non plus. Budget type pour les postes. Devis après cadrage sur vos canaux, pas sur une maquette de boutique.