Solution · Par logiciel

WooCommerce t’encaisse la commande. Ce qui vient après —le retour, l’incident, l’échange de taille— c’est une personne qui le tient à la main, dans un Excel.

WooCommerce, c’est WordPress : ta boutique, c’est le core plus une pile de plugins, et le core n’embarque pas de flux de retours. D’où une vente automatisée et un SAV qui ne l’est pas : chaque retour, chaque incident et chaque échange se règle à l’email, en regardant la commande dans le back-office et en notant dans une feuille à part. Sur la REST API et les webhooks de ton WooCommerce, on monte la couche d’IA qui transforme ce SAV en vrac en dossiers avec un statut.

On le monte chez moi Voir comment ça marche

Le problème

La vente, c’est le plugin qui la tient. Le SAV, c’est quelqu’un qui s’en souvient.

Le retour arrive par email ou par WhatsApp, pas par un flux : quelqu’un le note dans un Excel, cherche la commande dans le back-office et suit le colis de mémoire jusqu’à ce qu’il arrive à l’entrepôt.
Quand le client demande où en est son retour, personne ne sait lui répondre sans ouvrir trois endroits : l’email, le panneau des commandes et la feuille où quelqu’un tient les comptes.
Les incidents —un article manquant, arrivé cassé, la mauvaise taille expédiée— se règlent au cas par cas et chacun fait à sa façon : les uns remboursent, les autres renvoient un article, les autres réclament une photo.
Les remboursements partiels se calculent à la main et parfois de travers : on rend l’article mais pas le port, ou l’inverse, et l’écart ressort des semaines plus tard.
Chaque nouveau produit attend que quelqu’un lui écrive sa fiche, et en attendant il est publié avec la description du fournisseur telle quelle, ou pas publié du tout.

Le coût de ne rien changer

Tu as une boutique qui vend toute seule et un SAV qui n’existe pas comme process : il existe comme des personnes qui s’en souviennent. Ça n’apparaît sur aucune facture —ça apparaît en retours qui mettent des semaines à se clore, en clients qui posent trois fois la même question, en remboursements mal calculés qui déséquilibrent le mois, et en un Excel parallèle que seule la personne qui le tient comprend. Et le jour où cette personne part en vacances, le SAV s’arrête.

La solution

Une couche d’IA sur la REST API et les webhooks de ton WooCommerce qui transforme le SAV en dossiers avec statut

1On écrit avec toi la carte qui n’existe pas aujourd’hui : quels motifs de retour tu acceptes, sous quel délai, qui paie le port dans chaque cas, quand on rembourse et quand on renvoie un article, et ce qui exige une photo ou un contrôle en entrepôt. Sans cette carte, il n’y a rien à automatiser, juste du jugement éparpillé.
2On connecte par la REST API de WooCommerce et ses webhooks —commande créée, payée, terminée, remboursée ou remboursée en partie— avec des identifiants limités, en respectant le stockage de commandes que tu utilises déjà. L’IA lit ce qui arrive par email, formulaire ou WhatsApp, le recoupe avec la vraie commande et ouvre le dossier avec son motif, ses articles et son statut.
3On automatise le trajet du dossier : l’étiquette d’enlèvement, l’avis au client à chaque changement de statut, le contrôle face au délai et à la politique, et le calcul du remboursement —article, port, promotion appliquée— posé prêt sur la commande WooCommerce. Ce qui exige du jugement —un schéma bizarre, un montant élevé, une exception à la politique— ne s’exécute pas : ça monte à une personne avec le dossier déjà monté.
4On boucle avec les fiches : l’information du fournisseur devient description, attributs et catégorie dans WooCommerce, pour que le nouveau produit n’attende pas que quelqu’un ait un après-midi de libre.
5On le laisse mesuré et avec un filet : combien de dossiers se règlent sans que personne touche à rien, combien montent et pourquoi, combien de temps prend un retour de bout en bout et combien de remboursements tombent faux face au process manuel précédent.

Ce qui change

Ce que tu arrêtes de perdre

Le retour ne vit plus dans un Excel parallèle : il entre comme dossier dans le système, avec son motif, son délai et son statut, donc n’importe qui peut dire au client où ça en est sans ouvrir trois endroits.
Mécanisme
La politique s’applique pareil à chaque fois : le délai, qui paie le port et ce qui exige une photo, c’est la carte écrite qui le décide, pas celui qui ouvre l’email ce matin-là.
Mécanisme
WooCommerce n’embarque pas la gestion des retours dans son core —c’est une extension à part sur le marketplace officiel—, donc la plupart des boutiques n’ont pas un process, elles ont une habitude. Cette couche pose le process par-dessus sans t’obliger à changer de plugins. Source : [Returns and Warranty Requests](https://woocommerce.com/products/warranty-requests/), WooCommerce Marketplace, consulté le 10 septembre 2026.
WooCommerce Marketplace (extension RMA officielle), 10-sept-2026
Ce qu’on mesure : % de dossiers SAV résolus sans intervention, motifs d’escalade, temps de bout en bout d’un retour, remboursements qui tombent faux et temps jusqu’à la publication d’un nouveau produit, le tout face à la ligne de base du process manuel.
Ce qu’on mesure

Fiche technique

Travail supprimé: que le SAV de la boutique —retours, incidents de commande, échanges et remboursements partiels— soit tenu à la main par une personne, entre l’email, le back-office WooCommerce et un Excel parallèle
Mise en place habituelle: 2–4 semaines
Entrée: ce qui arrive après la vente : un email ou un message qui demande un retour, un incident de commande, la photo d’un article cassé, un événement de remboursement WooCommerce
Sortie: le dossier monté et déplacé dans ton WooCommerce : motif et articles identifiés, étiquette d’enlèvement émise, client prévenu à chaque changement de statut et remboursement calculé et posé sur la commande
Compatible avec: WooCommerce 8.x & 9.x on WordPress (REST API v3 + webhooks)High-Performance Order Storage (HPOS) and the legacy posts storageExisting returns/RMA plugins, kept in place
Peut se connecter à: Ton install WooCommerce et sa base de données, sans migrer vers un SaaSL’email, le formulaire et le WhatsApp par lesquels le SAV arrive aujourd’huiTon transporteur, pour l’enlèvement et le suivi réelTon Holded ou un autre ERP, si la facture et l’avoir passent par un autre flux
Ce qu’on mesure: % de dossiers SAV résolus sans interventionmotifs d’escaladetemps de bout en bout d’un retourremboursements qui tombent fauxtemps jusqu’à la publication d’un nouveau produit
Adapté pour: les boutiques qui vendent déjà avec WooCommerce et tiennent le SAV à la main, avec assez de volume pour que les retours et les incidents soient un travail en soi
Pas adapté pour: les décisions métier qui exigent du jugement au cas par cas —à qui on fait une exception, à quel fournisseur on réclame— ni les boutiques avec si peu de retours par mois que le process manuel reste rentable

Questions fréquentes

Un plugin de RMA te donne le formulaire, le numéro de retour et un écran pour les voir. Ça, c’est le contenant. Ce qu’une personne continue de faire, c’est le contenu : lire l’email du client qui n’a pas utilisé le formulaire, décider si c’est dans les délais, recouper avec la commande, voir si la promotion de la commande d’origine change le montant, calculer ce qu’on rend sur le port, émettre l’enlèvement et prévenir à chaque étape. Notre couche fait ce travail de jugement sur la REST API de ta boutique, et si tu as déjà un plugin de retours, on n’y touche pas : il continue de tenir le registre et on se pose par-dessus. Ce qu’on ne fait pas, c’est te vendre un plugin de plus pour la pile.

Un ticket se ferme en répondant ; un dossier SAV se ferme en déplaçant des choses. Répondre « ta commande est partie hier, voici le suivi », c’est du support. Un retour, c’est autre chose : il a des statuts —demandé, autorisé, enlevé, reçu, contrôlé, remboursé—, des délais qui courent, de l’argent qui bouge et un entrepôt qui doit confirmer. C’est pour ça qu’ici on ne monte pas un répondeur : on monte le dossier avec sa machine à états dans ton WooCommerce. Si ce que tu as en trop, ce sont des questions répétées et pas des retours, ce que tu cherches c’est le support IA 24/7, qui est une autre pièce.

Non, sauf si tu l’autorises explicitement et par type de cas. Ça démarre en mode proposition : l’IA monte le dossier, applique ta politique, calcule le montant et le laisse prêt ; une personne confirme. À mesure que la justesse tient, on lâche l’autonomie par paliers —d’abord les retours dans les délais et sous un montant que tu fixes toi, et seulement ceux-là. Les schémas bizarres, les montants élevés et les exceptions à la politique demandent toujours une confirmation humaine, par construction : le coût d’un remboursement mal approuvé, ce n’est pas le modèle qui le paie. On le monte comme ça parce que c’est ce qui tient en production, pas parce que ça fait joli à dire.

Non, et exprès. Cette couche tient le dossier SAV dans WooCommerce jusqu’à laisser le remboursement calculé et appliqué sur la commande. Le saut vers la compta —que ce remboursement sorte en avoir dans ton ERP, avec sa TVA et son ajustement de stock— est un autre flux, avec sa propre API en face, et on l’a monté à part : intégrer WooCommerce avec Holded grâce à l’IA. On peut avoir les deux et elles s’emboîtent ; ce qu’on ne fait pas, c’est les mélanger dans un projet de trois mois qui ne finit jamais.

Non. WooCommerce est à toi —WordPress, sur ton hébergement, avec ta base de données— et ça reste comme ça. On travaille par la REST API officielle et les webhooks, avec des identifiants limités à ce qu’il faut, et on respecte la façon dont tu stockes les commandes aujourd’hui, que tu sois sur le stockage haute performance (HPOS) ou sur le classique. Tes plugins restent où ils sont : on n’est pas un remplaçant de ta pile, on est la couche qui fait le travail qu’une personne fait aujourd’hui entre eux. Tu ouvres le même bureau qu’avant, juste avec les dossiers déjà montés.

On le monte chez toi ?

Tu as ciblé le problème. On livre la solution et on la laisse mesurée.

Voir le service