Connecter PrestaShop à GoManage et Aunabase : un cas réel
Un distributeur de matériel électrique et de plomberie dont les prix et stocks viennent de Go!Manage, les fiches…
« Je voudrais renvoyer les bottes, elles sont trop petites. » Quelqu'un de votre équipe ouvre la commande, répond à la main, note le cas dans un tableur et attend un colis. Quand il arrive, il faut se rappeler de qui il venait et de ce qu'on avait promis. Multipliez par vingt par mois.
Le client écrit toujours la même chose, mais derrière se cachent trois processus que la loi traite séparément, avec des délais et des coûts qui n'ont rien à voir :
En France, la garantie légale de conformité est de deux ans, et l'article L217-7 du code de la consommation va plus loin que le minimum européen : tout défaut qui apparaît dans les vingt-quatre mois suivant la délivrance est présumé exister depuis le départ pour un bien neuf (douze mois pour l'occasion). C'est au vendeur de prouver le contraire, pas au client.
Et il y a une règle que beaucoup de boutiques ignorent : chaque réparation prolonge la garantie de six mois (article L217-13). Si vous remplacez le produit au lieu de le réparer, c'est une garantie complète de deux ans qui repart sur le produit de remplacement.
Les confondre coûte cher dans les deux sens. Traiter une rétractation comme un retour commercial —« le délai était de trente jours et il est passé »— vous met hors la loi. Traiter une garantie comme une rétractation, c'est rendre de l'argent que vous n'aviez pas à rendre.
Le client écrit toujours le même e-mail. Derrière, trois processus différents, et un seul des trois vous appartient.
Celui-là n'est dans aucun manuel et c'est le plus fréquent : le client a oublié de saisir son code promo. Il ne veut pas renvoyer la marchandise — il ne l'a même pas encore — il veut annuler toute la commande et la refaire correctement.
Et il en a le droit, parce que la rétractation n'oblige pas à attendre le colis : elle s'exerce dès la conclusion du contrat. Les quatorze jours sont la fin du délai, pas son début.
Sur le plan opérationnel, c'est tout autre chose qu'un retour. Si la commande n'est pas sortie de l'entrepôt, il n'y a rien à récupérer : il faut l'arrêter, l'annuler et rembourser. Si elle est déjà partie, vous avez une commande en transit qui reviendra toute seule. PrestaShop n'offre aucune voie pour que le client fasse cela seul — cela finit en e-mail, ou en appel — et c'est exactement ce que résout la rétractation électronique obligatoire depuis juin 2026, ce que nous montons avec Droit de Rétractation.
Ce qui reste — le retour du quotidien, avec la marchandise déjà chez le client — est le sujet de la suite.
Cela surprend beaucoup de monde : il n'y a rien à acheter pour commencer. PrestaShop intègre un système de retours marchandise depuis des années, mais il arrive désactivé, et c'est pour cela que presque personne ne sait qu'il existe.
On l'allume dans Service client → Retours marchandise. Deux réglages et c'est tout : activer, et indiquer combien de jours vous acceptez — quatorze par défaut.
À partir de là, le client ouvre sa commande depuis son compte, coche les produits qu'il renvoie et en quelle quantité, écrit pourquoi, et envoie sa demande. Elle apparaît dans une liste de votre back-office, avec cinq états entre lesquels vous la déplacez : en attente de confirmation, en attente du colis, colis reçu, refusé et terminé. Chaque changement d'état envoie un e-mail au client, et vous pouvez imprimer un bon de retour en PDF à glisser dans le carton.
Pour une boutique avec trois ou quatre retours par mois, cela suffit. Vraiment. Allumez-le avant d'envisager autre chose.
La première surprise, c'est le moment où le bouton apparaît. PrestaShop ne propose de renvoyer qu'une commande payée et expédiée, et il compte les jours à partir de la date d'expédition inscrite sur la commande : celle qui se remplit quand vous changez le statut, pas quand le client ouvre le carton. Si votre entrepôt met deux jours à marquer les commandes, le client démarre avec deux jours de moins sans que personne ne le lui dise.
La deuxième, c'est que les commandes numériques sont exclues. Si ce que vous vendez se télécharge, PrestaShop n'affiche jamais l'option de retour — ce qui se tient pour un fichier, mais ne laisse aucune voie aux boutiques qui mélangent physique et téléchargeable dans la même commande.
La troisième, c'est le motif. Le client l'écrit dans une zone de texte libre, et tout s'arrête là : pas de liste de motifs, donc à la fin du trimestre vous ne pouvez pas répondre à la seule question qui compte —pourquoi me renvoie-t-on ces produits ?—. Avec des motifs fermés, vous découvrez que 40 % des retours d'une référence portent sur la taille, et que ce produit a besoin d'un meilleur guide des tailles, pas d'un autre fournisseur.
La quatrième, c'est que le retour ne déplace pas l'argent. L'approuver ne génère aucun remboursement : c'est un autre écran, sur la commande, que quelqu'un doit penser à remplir. Pas d'enlèvement non plus, pas d'étiquette transporteur, pas d'avis à l'entrepôt.
En bref : PrestaShop enregistre la demande. Tout ce qui vient après vit encore dans votre boîte mail.
Dès qu'une boutique dépasse vingt ou trente retours par mois, les mêmes demandes reviennent, et ce n'est presque jamais « je veux un module RMA » :
Le troisième point est celui qui prend le plus de formes, et il vaut mieux les distinguer, car ce ne sont pas les mêmes pièces :
RMA-00001, précisément parce que le client comprend « RMA » et pas « commande de retour de vente ». Si votre ERP sait déjà faire cela, la boutique n'a pas à l'apprendre : elle doit le prévenir.C'est cette dernière idée qui nous fait gagner le plus de temps. Nous l'appliquons déjà dans l'intégration avec Go!Manage : l'ERP commande le métier, la boutique est la vitrine. Pour les retours c'est pareil — celui qui décide d'accorder un avoir est celui qui tient la comptabilité, pas le catalogue.
Ce qui se répète dans tous les cas, c'est le point de départ : le système natif allumé, pour que la demande soit enregistrée sur la commande et non dans un e-mail, et à partir de là on connecte ce qu'il faut.
Allumez les retours natifs et réglez le délai sur ce que vous acceptez vraiment. Écrivez les trois voies séparément sur votre page de retours, avec leurs délais, et arrêtez de les discuter au cas par cas. Puis, pendant un mois, notez à la main le motif de chaque retour : à trente lignes, vous saurez s'il faut connecter quelque chose ou si cela vous suffit largement.
Si ces trente lignes vous disent qu'il faut emmener tout cela ailleurs, racontez-nous comment vous travaillez et avec quels outils — le tableau, l'ERP, l'entrepôt — et nous vous dirons ce qui vaut la peine d'être connecté et ce qu'il vaut mieux ne pas toucher.
Un distributeur de matériel électrique et de plomberie dont les prix et stocks viennent de Go!Manage, les fiches…
Prêt à propulser votre boutique PrestaShop ? Parlons de votre projet et créons ensemble quelque chose d'exceptionnel.
Contactez-nous