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 est un contrat : fréquence, rejet, qui gagne en cas d'écart. Un export CSV du lundi ne tient aucune de ces trois lignes.
La synchronisation de stock en temps réel a une définition opérationnelle : une unité vendue sur un canal disparaît des autres avant le prochain clic. Pas toutes les quinze minutes, pas « presque », et pas comme un badge marketing. 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 signifie un stock, plusieurs promesses de délai, plusieurs règles d'annulation, ce qui va plus loin que « on est partout ». 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 engage un régime, un pays de destination, un seuil, une déclaration, et ne se résume donc pas à un taux dans le front. + 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 suppose un cours, un historique, une pièce comptable. 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 fait tourner une ops : entrepôt, SAV, compta, 40 personnes qui touchent l'outil, parfois plusieurs sociétés (boutique, logistique, UE). Une marque en lancement n'a pas ces contraintes. Grille tarifaire de l'agence, 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 (voir les 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) appartient au front, et 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. La question porte sur qui a le droit de promettre, pas sur la « scalabilité ». 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.