Qui a changé ce prix ? L'historique des modifications produits dans PrestaShop

Lundi matin. Un client écrit parce qu'il a acheté un produit à un prix qui n'a aucun sens : la moitié du prix habituel. Vous regardez la fiche et, effectivement, le prix est faux. Qui l'a modifié ? Quand ? Combien valait-il avant ? Combien de commandes sont arrivées à ce prix ?

Dans une boutique PrestaShop standard, la réponse honnête est « nous ne savons pas ». Et la conversation qui suit dans l'équipe est souvent délicate, car tout le monde affirme n'avoir rien touché.

Pourquoi PrestaShop ne le sait pas

La base de données de PrestaShop conserve l'état actuel de chaque produit : son prix, son stock, sa description, s'il est actif. Quand quelqu'un enregistre une modification, la nouvelle valeur remplace l'ancienne et l'ancienne disparaît.

Ce qu'elle conserve en revanche :

• La date de dernière modification du produit (date_upd), sans dire ce qui a changé ni qui l'a fait.
• Le journal du système (Paramètres avancés > Logs), qui selon la version note certaines actions des employés, mais sans la valeur d'avant et celle d'après.
• Les mouvements de stock, lorsque la gestion avancée est active ou dans les versions qui les enregistrent, qui indiquent la quantité déplacée mais rien sur le reste de la fiche.

Pour savoir ce qui s'est passé, il vous faut ce que l'on appelle un journal d'audit : une ligne par modification, avec qui, quand, quel champ, la valeur précédente et la nouvelle.

Quelles modifications enregistrer

Tous les champs n'ont pas la même importance. Par ordre de désagréments causés :

1. Prix de vente et prix d'achat. Une erreur ici se transforme en argent perdu le jour même.
2. Stock. En séparant les ajustements manuels des mouvements issus des commandes et des synchronisations avec l'ERP.
3. Activation. Un produit désactivé disparaît du catalogue et des flux Google Shopping ou des marketplaces.
4. Catégorie par défaut et associations. Elles influent sur l'URL, le fil d'Ariane et le référencement.
5. Nom, description et URL simplifiée. Un changement d'URL sans redirection, c'est une page perdue dans Google.
6. Références et codes (référence, EAN) : l'entrepôt, l'ERP et les marketplaces en dépendent.
7. Poids et dimensions. Ils modifient ce que vous facturez pour la livraison.

Ce que doit contenir un bon historique

• L'employé, avec son nom, pas seulement un numéro.
• La date et l'heure exactes.
• L'origine : back-office, import CSV, webservice ou module. Bien des surprises ne viennent pas d'une personne, mais d'une intégration.
• L'avant et l'après de chaque champ, sur la même ligne.
• Des filtres par produit, employé, champ et dates.
• L'export, pour le croiser avec les commandes ou le montrer à qui de droit.
• Une durée de conservation configurable : tout garder indéfiniment remplit la base de données ; mieux vaut un délai raisonnable et un nettoyage automatique.

Les cas où il sert

Le prix que personne n'a modifié

Une boutique alimentaire voit régulièrement, à quelques jours d'intervalle, des produits avec un prix à zéro. Personne dans l'équipe n'y a touché. L'historique montre que la modification arrive par le webservice, toujours à la même heure : le connecteur de l'ERP envoie un prix vide lorsqu'un article n'a pas de tarif attribué. Sans l'origine notée, on aurait continué à soupçonner l'équipe.

Le stock qui ne colle pas

Un distributeur B2B fait son inventaire et il manque des unités. La chronologie du produit montre chaque ajustement manuel, chaque mouvement de commande et chaque synchronisation. L'écart apparaît dans un ajustement manuel effectué sur la mauvaise déclinaison.

La fiche qui a perdu des positions

Un produit qui se vendait bien recule dans Google. L'historique indique qu'il y a trois semaines, le nom et l'URL simplifiée ont été modifiés, sans redirection. On restaure l'ancienne URL ou on crée la redirection, et l'on sait exactement quel texte il y avait avant.

Combien de commandes sont passées au mauvais prix

Avec l'heure exacte de la modification et celle de sa correction, vous filtrez les commandes de cet intervalle qui contiennent ce produit. Vous savez désormais à qui écrire et combien cela vous a coûté.

Comment l'organiser dans l'équipe

• Un compte employé par personne. Si trois personnes partagent le même compte du back-office, n'importe quel historique dira seulement « c'était le compte de la boutique ». Chacun le sien, avec le profil dont il a besoin.
• Des comptes dédiés aux intégrations. L'ERP, le connecteur fournisseurs et la marketplace, chacun avec sa clé de webservice : ainsi, leur origine se distingue.
• Revue hebdomadaire. Un coup d'œil au résumé de la semaine : qui a le plus modifié, quels champs et quels produits. Ce qui est anormal saute aux yeux.
• Durée de conservation convenue. Quelques mois suffisent généralement au quotidien ; si vous vendez des produits à prix réglementés ou contractuels, il vous faudra peut-être davantage.

Utile aussi lors des mises à jour

Lorsque vous mettez à jour PrestaShop ou un module, ou que vous changez de version, il arrive souvent qu'un processus commence à modifier des champs qu'il ne touchait pas auparavant : un module qui réécrit les prix lors de sa réinstallation, un import qui interprète désormais les décimales autrement. Avoir l'historique actif avant la mise à jour vous permet de voir, le lendemain, si quelque chose a modifié des produits sans que personne ne l'ait demandé.

Checklist

• Chaque membre de l'équipe avec son propre compte employé.
• Chaque intégration avec sa propre clé de webservice.
• Historique actif au minimum pour le prix, le prix d'achat, le stock, l'activation, la catégorie, le nom et l'URL.
• Durée de conservation fixée et nettoyage automatique.
• Revue périodique du résumé.
• Avant et après une mise à jour, un coup d'œil aux modifications.

Comment le résoudre dans PrestaShop

Full Product Log enregistre chaque modification de vos produits avec l'employé, la date et l'heure, l'adresse depuis laquelle elle a été faite et la valeur précédente à côté de la nouvelle, sur jusqu'à 84 champs que vous choisissez de surveiller. Au-dessus de la liste, vous avez le résumé de la période, avec qui modifie le plus, quels champs et quels produits, et chaque nom est un raccourci qui filtre la liste. Chaque produit a sa chronologie, les mouvements de stock arrivant par le webservice depuis l'ERP sont enregistrés, vous exportez en CSV ce que vous consultez et vous décidez combien de temps les données sont conservées. Il ne modifie pas vos produits, n'ajoute rien à la vitrine et fonctionne en multiboutique, de PrestaShop 1.7.6 à 9.