cas client
e-commerce
Deux canaux de vente, un seul flux. Et un catalogue qui s'écrit tout seul.
IndoorPoppies vend des plantes et des boutures rares sur sa boutique et sur Etsy. Deux canaux, deux back-offices, deux formats de commande, et une équipe au milieu qui recopie. Pendant ce temps, chaque nouvelle plante attend sa fiche, le blog n'avance pas, et l'hiver approche : un colis mal protégé arrive mort.
- client
- IndoorPoppies, plantes et boutures rares
- secteur
- E-commerce, vente multi-canal
- livré
- 13 scénarios, 3 chaînes reliées entre elles
- en service
- Depuis décembre 2024, enrichi en continu
Tout arrivait en double, sauf le temps.
Vendre sur deux canaux double le travail administratif sans doubler l'équipe. Une commande Etsy et une commande de la boutique ne se ressemblent pas : ni le même format, ni les mêmes références produit, ni le même endroit où aller la chercher. La préparation d'expédition commençait donc par une recopie.
Le catalogue posait le problème inverse : les plantes rares arrivent plus vite qu'on ne sait les décrire. Chaque référence réclame une description, une méta description, une FAQ, et idéalement un conseil d'entretien, sinon le client demande par email. Le blog, lui, restait à l'état d'intention.
Et une contrainte propre au métier, que peu de boutiques connaissent : en hiver, une plante expédiée sans protection thermique arrive morte. L'option existe au paiement, encore faut-il savoir, au moment d'emballer, qui l'a prise.
Un parc qui tourne, pas une démonstration.
Ce dernier chiffre est le seul qui m'intéresse vraiment. Un système d'automatisation se juge à sa deuxième année, pas à sa démonstration : celui-ci a passé deux hivers, des changements de catalogue et des évolutions d'API sans qu'on ait eu à le reconstruire.
Les commandes : deux entrées, une seule sortie.
Les deux canaux sont écoutés séparément, puis ramenés au même format. Le point délicat n'est pas la collecte, c'est la correspondance des produits : une ligne de commande Etsy doit retrouver le produit de la boutique pour que la préparation parle d'une seule référence. Les commandes à plusieurs lignes sont éclatées, puis réagrégées en un texte lisible par la personne qui prépare le colis.
- Les 2 canauxboutique et Etsy
- La correspondancele produit reconnu
- Le pivotune ligne par commande
-
Le bon de préparationPDF du jour
-
L'envoià la demande, avant d'emballer
Le catalogue et le blog s'écrivent, se relisent et se publient.
C'est la partie la plus lourde du dispositif, et elle fonctionne en cascade : chaque scénario prépare le travail du suivant. Rien n'est déclenché à la main.
- L'audit du catalogue. Un scénario parcourt la boutique et liste les fiches qui n'ont pas de description longue. Ce n'est pas un rapport pour faire joli : cette liste devient la file d'attente de l'écriture.
- L'écriture des fiches. Par lots de 10 pour lisser la charge : des données sont d'abord récupérées sur la plante, puis 4 générations successives produisent la description longue, la méta description, la FAQ, et une sortie structurée. La fiche est créée dans la boutique, complétée par un appel direct à l'API pour les champs que le module standard ne couvre pas, et dupliquée sur Etsy.
- La fiche d'entretien. L'écriture d'une fiche produit déclenche la suivante : la photo de la plante est analysée par un modèle de vision, le conseil d'entretien est rédigé, mis en page dans un gabarit, converti en PDF, déposé dans la médiathèque du site et rattaché au produit.
- Le blog. Un scénario lit chaque jour le plan du site pour savoir ce qui existe déjà, l'IA propose les sujets manquants, puis une vingtaine de générations successives écrivent l'article section par section, avec des sources récupérées en cours de route. Publication dans le site, statut mis à jour, notification par mail.
Les questions et réponses produites pour les FAQ sont en plus exportées de leur côté : la même matière peut resservir ailleurs sur le site sans être réécrite.
Les clients arrivent dans la base, une seule fois.
Les acheteurs Etsy remontent dans le tableur, puis dans l'outil d'emailing. Un filtre écarte les adresses déjà connues, et chaque ligne traitée est marquée en retour.
Sans ce marquage, une synchronisation qui tourne toutes les heures recréerait les mêmes contacts indéfiniment. C'est un détail d'implémentation qui décide si la base client reste propre ou devient inutilisable en six mois.
Le colis qui ne doit pas geler.
Quand un client ajoute l'option de protection thermique à son paiement, un scénario le détecte chez le prestataire de paiement, récupère le détail de la transaction et l'inscrit dans le tableau de préparation.
La personne qui emballe voit donc, sur le même document que sa commande, qu'il faut glisser une protection dans le colis. C'est trois modules et un filtre, et ça évite des plantes mortes, des remboursements et des avis négatifs.
Des outils que la boutique avait déjà, pour la plupart.
Make
WooCommerce- Etsy
- Mollie
Brevo- Google Sheets
WordPress
Claude
OpenAI
Make orchestre l'ensemble : c'est là que vivent les 13 scénarios, rangés dans un dossier dédié et préfixés selon leur criticité, pour qu'on sache en un coup d'oeil ce qui tourne en permanence et ce qui se lance à la demande.
Deux fournisseurs de modèles plutôt qu'un seul, choisis par tâche : l'analyse d'image et la rédaction des fiches d'entretien d'un côté, la chaîne éditoriale du blog de l'autre. Rien n'oblige à tout confier au même moteur, et s'attacher à un seul fournisseur est un risque inutile.
Le reste, la boutique l'utilisait déjà. Une automatisation qui impose 4 nouveaux abonnements ne se rentabilise jamais.
Un tableur au centre, et c'est volontaire.
Toute la donnée transite par un tableur partagé. Sur le papier, c'est le mauvais choix : une base de données ferait ça mieux, plus vite et plus proprement. Dans cette boutique, c'est pourtant le bon, pour trois raisons.
- Le client voit ce qui se passe. Une commande qui manque, une fiche en attente, un statut bloqué : tout est visible sans ouvrir un outil technique, et corrigible à la main quand il le faut.
- C'est une file d'attente entre les scénarios. L'audit du catalogue écrit ce que l'écriture des fiches viendra prendre ; l'écriture des fiches écrit ce que la fiche d'entretien viendra prendre. Les scénarios ne s'appellent pas entre eux, ils se passent des lignes.
- Ça survit à mon départ. Personne n'a besoin de moi pour lire un tableur, en ajouter une ligne, ou comprendre pourquoi une commande n'est pas partie.
La règle qui rend l'ensemble fiable tient en une phrase : chaque scénario réécrit la ligne qu'il vient de traiter. C'est ce retour d'écriture qui permet de rejouer n'importe quelle étape après une panne, sans créer un seul doublon.
Questions fréquentes
Pourquoi Google Sheets plutôt qu'une vraie base de données ?+
Comment évite-t-on de traiter deux fois la même commande ?+
Les fiches produits générées ne se ressemblent-elles pas toutes ?+
Que se passe-t-il quand une API limite les appels ?+
Deux cas voisins
la même idée, ailleurs
Fiches produits réécrites pour le SEO
Le modèle regarde la photo du produit et écrit la fiche, sur un catalogue entier.
lire le cas →
l'autre bout de la boutique
Le service client d'un e-commerce
4 demandes sur 5 traitées sans personne, les autres pré-rédigées pour l'équipe.
lire le cas →
Vous vendez sur deux canaux, vous saisissez deux fois ?
Marketplace et boutique, boutique et logiciel de caisse, ERP et site : dès qu'une donnée existe à deux endroits, quelqu'un la recopie. C'est le chantier le plus rentable à attaquer en premier, et le plus rapide à livrer.
ou écrivez directement à contact@leroynicolas.fr