Un retour paraît banal. En exploitation, il ne l’est pas.
Ce que le client appelle “retour” correspond souvent à quatre décisions différentes.
Un client renvoie une veste parce que la taille ne va pas. Dans la boutique en ligne, l’affaire semble simple : on approuve le retour, on génère l’étiquette, on rembourse. Mais côté opérationnel, le dossier se divise en quatre flux : le produit peut revenir en bon état ou non ; l’argent peut sortir avant ou après l’inspection ; le stock peut redevenir vendable ou finir en perte ; et le service client peut clôturer le cas ou laisser une chaîne de messages ouverte.
La thèse qui dérange est la suivante : il ne faut pas chercher un retour “parfaitement intégré” si cela oblige tous les flux à avancer au même rythme. Dans beaucoup de PME, Shopify et l’ERP doivent bien se coordonner, mais pas comme s’ils formaient une seule machine. Ils doivent partager les faits, pas forcément les décisions au même instant.
L’erreur qui consiste à voir un retour comme un seul flux
Le conseil habituel dit : “intégrez Shopify à l’ERP pour éviter les tâches manuelles”. C’est juste quand les équipes ressaisissent les mêmes données et que personne ne sait quel état est le bon. Cela devient insuffisant quand le retour sert à plusieurs choses différentes.
Il faut penser dans cet ordre :
- Produit : est-il physiquement revenu ? Est-il abîmé ? Faut-il le contrôler ?
- Argent : remboursement total, partiel ou rien pour l’instant ?
- Stock : retour en stock vendable, en attente de contrôle ou en perte ?
- Support : qui répond au client, et sous quel délai ?
Shopify permet de gérer les retours et les échanges depuis la page des commandes, de créer un retour, d’envoyer des instructions d’expédition et d’émettre un remboursement après inspection. La plateforme propose aussi des retours et annulations en libre-service pour que le client lance la demande depuis la page d’état de commande. (help.shopify.com)
C’est utile, mais cela ne répond pas à la vraie question opérationnelle : quel système décide de quoi. Si Shopify pilote l’expérience client et que l’ERP pilote le stock, la finance et le réapprovisionnement, l’intégration doit respecter cette séparation. Sinon, on obtient deux vérités en même temps : une propre pour le client, une douloureuse pour l’entrepôt.
Là où la marge fuit sans que personne ne le voie
La marge ne disparaît presque jamais dans un grand incident. Elle fuit par petites erreurs administratives répétées.
- Un remboursement part avant la vérification de l’état réel du produit.
- Le stock revient en disponibilité alors qu’il attend encore l’inspection.
- Un ticket support est créé mais l’ERP ne reçoit jamais la mise à jour.
- Les échanges sont gérés par habitude et personne ne mesure leur coût réel.
Les flux de retour et d’annulation en libre-service de Shopify permettent au client de faire sa demande directement, mais le marchand doit encore la revoir et la résoudre dans l’administration. Les règles de retour et d’annulation fixent l’éligibilité et les délais. (help.shopify.com)
C’est important, car la fuite est le plus souvent répétitive, pas spectaculaire : une ligne mal classée, un réassort trop tôt, un remboursement fait “par confort”. Sur une semaine, cela paraît anodin. Sur un trimestre, cela devient une vraie perte de marge.
Un cas de PME avec deux règles différentes
Imaginez une PME de décoration qui traite 120 retours par mois. Le commerce veut des réponses rapides : si le client a raison, il faut rembourser vite. L’entrepôt, lui, doit inspecter les articles, car certains reviennent abîmés, ouverts ou incomplets.
Pendant des mois, l’entreprise applique la même règle à tout : retour approuvé, remboursement immédiat, réassort automatique. Le service client paraît plus rapide sur le papier, mais l’inventaire se charge d’articles invendables, et la comptabilité découvre la perte réelle trop tard.
La correction n’a pas été “plus d’automatisation”. Elle a été moins d’uniformité. L’équipe a séparé trois décisions :
- l’acceptation de la demande,
- l’inspection physique,
- la décision financière finale.
Shopify est resté la face visible pour le client. L’ERP a pris la main sur le réapprovisionnement et les sorties de stock. Le support a reçu un statut clair, afin de ne pas promettre ce que l’entrepôt n’avait pas encore validé.
La leçon est contre-intuitive : parfois, mieux intégrer signifie cesser de faire comme si tous les retours étaient identiques.
Quand l’approche classique reste la bonne
Le point de vue contrariant ne veut pas dire qu’il faut tout fragmenter. Si l’entreprise a peu de retours, un catalogue simple et une petite équipe, un circuit sobre peut être meilleur qu’un modèle d’exceptions trop sophistiqué. Une automatisation plus forte est aussi pertinente quand le risque d’erreur humaine est élevé et que la règle est toujours la même.
Mais dès qu’il y a des tailles, des échanges, des contrôles de dommages, du reconditionné ou des articles à inspecter, la vraie question n’est plus “peut-on automatiser ?”. C’est : quelle décision doit être vérifiée par un humain, et laquelle peut avancer seule ?
Shopify sépare déjà le remboursement, le retour et l’échange comme des actions distinctes. Ce détail compte : tout dossier clos ne doit pas devenir automatiquement un remboursement en argent ni un retour de stock. (help.shopify.com)
Trois vérifications à faire cette semaine
Commencez par trois contrôles concrets :
- Prenez un retour récent et dessinez ses quatre flux : produit, argent, stock et support.
- Décidez quel système est la source de vérité pour chacun : Shopify, ERP ou humain.
- Repérez un cas où le remboursement et le réassort vont trop vite.
Si la réponse est “cela dépend de la personne qui s’en occupe d’habitude”, vous avez déjà trouvé le problème.
Le retour n’est pas un sujet secondaire. C’est un test de coordination. Et pour beaucoup d’entreprises, c’est aussi une manière discrète de perdre de la marge si le processus n’est pas conçu avec rigueur. Chez Codefuente, c’est souvent là que l’on commence : moins de magie, plus de règles opérationnelles réellement applicables.