Stocks ou prix modifiés : vandalisme ou accès catalogue
Des prix à 0,01 €, des stocks à zéro, un catalogue vandalise : accès employé, clé API, ou module. Exportez avant de corriger — l'historique sert. Recalculez depuis la source (fournisseur, ERP), pas depuis le front « pour que ça ait l'air juste ».
Un accès employé ou une API. Exportez avant de corriger : l'historique sert. Recalculez ensuite depuis la source (fournisseur, ERP), pas depuis le front.
Vandalisme visible vs pillage silencieux
Le vandalisme se voit : 1 € sur toute une catégorie, rupture partout, titres insultants. Le pillage : une hausse discrète, un SKU d'appel à prix coûtant pour vider le stock, un export nocturne. Les deux demandent la même copie (base + fichiers) avant correction. Sans export, vous perdez qui a changé quoi, et vous recalculez au feeling.
Ce n'est pas toujours un « hacker ». Un import CSV mal mappé, un stagiaire, un connecteur ERP en double, produisent le même tableau. La recherche d'entrée tranche (logs employé, API, date d'import). Traitez le symptôme (prix) après avoir figé, pas à la place.
Exporter avant de « remettre les prix »
Export produits (SKU, prix HT/TTC, stock, date de maj si vous l'avez), règles de promo, prix spécifiques (PrestaShop), tier prices (Magento), grilles B2B. Horodatez. Cet export est la pièce « état vandalisé ». Puis seulement, réimport depuis une source saine.
Les captures du front aident le commercial ; le CSV aide le constat. Gardez les deux. Boutique B2B si des grilles pro sont en jeu.
- CSV catalogue + promos, fenêtre de l'incident.
- Qui avait le droit d'écrire (employés, clés).
- Dernier import / cron d'sync daté.
Employé, API, import : qui a écrit
PrestaShop : employés, webservice `products` write, modules d'import. Magento : admin, integrations, import CSV, ERP. Woo : users, REST `products`, plugins d'import. Les access.log sur les routes admin / REST datent. Employé fantôme, clés Magento.
Un module « dynamic pricing » ou un JS front qui affiche un prix faux sans toucher la base : le panier peut quand même encaisser le faux si le serveur fait confiance au POST. Vérifiez côté serveur (règles de prix) pas seulement la fiche.
Promos, règles de prix, et groupes clients
Une règle « -90 % pour tout le monde » est plus discrète qu'un prix catalogue réécrit. Vérifiez panier / catalog rules, coupons créés la nuit, groupes (visiteur vs pro). En B2B, un groupe « public » qui hérite du tarif négocié est une fuite commerciale autant qu'un vandalisme.
Les prix barrés / marketing (schema.org) : un écart front / serveur crée des litiges. Recalculez, puis videz les caches (page, CDN, Merchant Center).
Recalculer depuis l'ERP, pas depuis le site
Le front n'est pas une source. L'ERP, le fichier fournisseur, le dernier export sain d'avant la fenêtre (lu, pas « last backup » aveugle) le sont. Un restore catalogue d'il y a trois mois écrase les vrais changements du mois (nouveaux SKU, vraies promos). Diff, puis réimport ciblé.
Si l'ERP a été poussé DEPUIS le site (sync inverse), l'ERP est sale aussi. Stoppez la sync, tranchez la source de vérité, puis un seul sens.
Commandes passées au tarif pirate
Exportez-les. Décision commerciale : honorer, annuler, régulariser. Juridiquement, un prix affiché peut lier — parlez à votre conseil pour les volumes. Techniquement, ne « corrigez » pas les commandes déjà payées dans le CMS pour faire disparaître l'incident : vous perdez la trace. Les litiges PSP sont un autre tiroir.
Un pic de commandes à 0,01 € oriente vers une automatisation (bots). Coupez le paiement le temps du recalcul si le trou est large — fermer le checkout.
Marketplaces : le flux a suivi
Amazon, Cdiscount, Fnac : un feed a pu pousser les prix vandalisés. Révoquez / pausez le flux, corrigez à la source, renvoyez. Les condos marketplace (prix trop bas, ruptures) ont leurs propres sanctions. Flux marketplace.
Refermer l'écriture catalogue
Rôles, clés, imports (auth, IP), crons. Un catalogue propre et une clé `products:write` oubliée recommence mardi. Relisez les prix d'un échantillon (20 SKU) à J+2. Créer un compte si l'ERP et le site ne sont plus d'accord et que personne n'ose trancher.
- État vandalisé exporté.
- Source de vérité unique, sync stoppée le temps du tri.
- Écriture catalogue restreinte.
- Flux market pausés puis recollés.
Taxes, devises, et le prix « juste » qui ne l'est pas
Un taux de TVA passé à 0, une devise boutique basculée, un arrondi : le front « a l'air » soldé, le catalogue HT n'a pas bougé. Vérifiez taxes, zones, devises, arrondis, et le TTC calculé. Un attaquant moins voyant qu'un prix à 0,01 € passe par là. Les règles B2B hors taxes vs TTC aussi.
Merchant Center et les comparateurs affichent souvent le TTC. Un écart site / flux crée des refus de pub et des clients mécontents. Après correctif, renvoyez le flux et demandez un recrawl des fiches importantes. Ne « corrigez » pas Merchant à la main en laissant le CMS sale.
Les packs / produits composés : un composant à 0 casse le pack. Exportez aussi ces liaisons. Recalculez depuis l'ERP, testez 10 SKU dont 2 packs et 1 promo, puis le reste.