Gumroad devient scriptable. Voici les 12 agents qui gèrent ma boutique.

Trois ans. 22 produits Gumroad expédiés. Trois niches, tech et non-tech. À chaque lancement, la même arithmétique : environ une semaine de vrai travail par produit, et l'essentiel n'est pas le produit lui-même.

Cette semaine contient l'idée. Le positionnement. Trois itérations de couverture parce que la première fait toujours cheap. Deux réécritures de la landing page. La séquence d'emails post-achat. Le setup analytics. Le thread de support de la première semaine où cinq acheteurs d'affilée demandent si le lien de téléchargement fonctionne, alors que le lien fonctionne toujours, ils n'ont juste pas encore essayé. À chaque lancement, je me dis que le suivant sera plus rapide. Ce n'est jamais plus rapide. Même lancement. À chaque fois.

Gumroad vient de révolutionner la donne.

TLDR. Cette semaine Gumroad a sorti un CLI. Trois éléments de ma chaîne sont devenus scriptables. Neuf autres valent enfin la peine d'être scriptés. Un produit Gumroad cesse d'être un fichier figé et devient un service qui écoute, corrige, et se redéploie tout seul. 12 agents, 5 phases. Pas un multiplicateur de revenus. Ça devient exponentiel.

L'API Gumroad existe depuis des années. N'importe qui avec de la patience OAuth et un serveur pouvait déjà automatiser la création de produits. Personne ne l'a fait. Le coût de setup - enregistrer une app, stocker des secrets, rafraîchir des tokens, maintenir une box quelque part - était supérieur au temps manuel économisé par lancement. Le CLI change exactement une chose. OAuth est intégré, pas de clés à stocker, l'installation tient en une ligne. La barrière passe de "projet dev" à "après-midi de plomberie". Pas une nouvelle capacité. Une nouvelle économie.

Ce N'était Pas Impossible. C'était Impraticable.

Le CLI Gumroad n'est pas une interface plus jolie par-dessus l'API. L'API était techniquement ouverte. Pratiquement, c'était une forteresse : app OAuth, refresh token, une box qui reste vivante, et un weekend de plomberie auth avant que votre agent touche jamais un produit. Le CLI réduit ça à trois commandes : install, gumroad auth login, export GUMROAD_ACCESS_TOKEN. La seconde ouvre votre navigateur et gère OAuth nativement. La troisième est tout ce dont votre agent a besoin.

Le mode non-interactif est un citoyen de première classe (--no-input, --json, --quiet, --dry-run), et une skill Claude Code est livrée dans le repo, installable avec gumroad skill. L'outil a été écrit pour les agents. Les humains sont juste aussi les bienvenus.

J'ai argumenté il y a quelques mois que les CLI battent MCP pour l'intégration d'agents, parce que la surface CLI est là où vivent déjà les agents de code. Gumroad qui sort un CLI avec une skill Claude Code native dans le repo, c'est à peu près la validation platform-level la plus propre qu'on puisse avoir.

Ce n'était pas impossible. C'était impraticable. C'est une vraie distinction.

Trois des douze éléments ci-dessous ne sont devenus viables que cette semaine. Les neuf autres étaient faisables avant, mais leur ROI devenait négatif dès que l'expédition restait manuelle. Fermez le dernier gap et toute la chaîne bascule de hobby à système.

[INFOGRAPHIE : flux 5 phases — Sourcing / Rédaction / Expédition / Feedback / Évolution — avec les 3 éléments CLI (6, 7, 11) surlignés contre les 9 éléments ère-API]

Phase 1. Avant d'Écrire un Mot.

La plupart des vendeurs Gumroad commencent par "quel produit devrais-je faire". L'agent commence par "quel signal dit que quelque chose est demandé". La différence semble petite. Elle change où va la première heure.

Élément 1. Le mineur de signaux de niche. L'agent croise trois sources : vos propres analytics Gumroad (produits qui convertissent versus produits qui sont restés plats), prédictions de recherche Pinterest (vraies requêtes, pas des suppositions), et tags trending Gumroad Discover. L'output est trois angles candidats par semaine, chacun avec preuve de volume. Un angle programme workout maison qui apparaît deux fois dans deux sources est un vrai signal. Un angle "ça semble cool" ne l'est pas. Ce qui me prenait une demi-journée de tab-hopping prend maintenant à l'agent environ 15 minutes, et il le fait sur planning que je sois là ou pas.

Élément 2. Le détecteur de gaps. L'agent lit les avis publics sur les concurrents directs, sur les équivalents Etsy, sur les stores Substack qui ont récemment pivoté vers Gumroad. Il extrait ce que les acheteurs demandent explicitement ("j'aimerais que ça ait X") et ce dont ils se plaignent implicitement (la même frustration répétée dans cinq avis que personne n'a adressée). L'output est une liste priorisée de demandes non satisfaites dans votre niche. Sur deux des trois niches que je gère, l'angle gagnant de mon dernier produit traînait dans l'avis d'un concurrent six mois avant que j'expédie. Je ne l'avais juste pas lu. L'agent les lit tous.

Élément 3. Le tracker de vélocité cross-niche. Pour les vendeurs qui travaillent dans plus d'une niche (moi, trois niches), l'agent track la conversion par niche dans le temps et vous dit où doubler la mise, où faire pause. Use case sensible ici. J'ai failli tuer une de mes niches non-tech après six semaines de volume plat. Il s'est avéré que c'était saisonnier. Si l'agent avait eu autorité pour couper, j'aurais tué un canal qui a payé le loyer quatre mois plus tard. La règle reste : les humains décident kill, les agents décident focus. Quatre-vingt-dix jours minimum de data avant qu'une niche soit retirée.

Phase 2. La Partie Où J'Arrête d'Être un Bagnard de l'Écriture.

Le vrai coût d'un lancement Gumroad n'est pas l'upload. Ce sont les dix heures de réécriture de copy landing, les quatre heures sur la calibration de voix, les six heures d'A/B-testing d'angles de positionnement. C'est là qu'un agent gagne sa croûte.

Élément 4. Le générateur de draft-sous-contrat. Un contrat par niche, pas un prompt générique. Un contrat PDF meal prep dit "ne jamais promettre de pertes caloriques, cadrer comme structure de planning hebdomadaire uniquement". Un contrat preset photo dit "toujours spécifier les boîtiers testés et les assumptions d'exposition de base". Un contrat workbook craft d'écriture dit "pas de claims productivité-par-jour, cadrer comme structure de pratique". L'agent produit un premier draft sous ce contrat. J'écrivais v0.1 en quatre heures. Je review maintenant v0.8 en vingt minutes. J'ai détaillé le pattern de bout en bout dans la pièce Prompt Contracts, et les mêmes mécaniques portent sur la copy produit sans modification.

Élément 5. La porte d'auto-critique. Avant que le draft m'atteigne jamais, l'agent critique son propre output contre la rubrique de niche. Claims vérifiables. Caveats présents. Voix cohérente avec les trois derniers lancements. Il revient avec un diff, pas une ardoise propre. Le hic : il approuve encore le phrasé sur-optimiste environ un draft sur cinq. J'ai gardé une étape de veto humain. Aucune copy n'expédie sans ma lecture. J'ai appris ça sur un lancement manuel il y a deux ans où j'ai expédié une landing page promettant "10x productivité" et j'ai passé les quinze jours suivants à me faire démonter dans les avis. Gatez votre propre draft. Puis gatez la gate.

Phase 3. Une Commande. Vingt Minutes. C'est le Vrai Job du CLI.

Le CLI fait ce que seul le CLI peut faire. Neuf des douze éléments de cette stack existaient sous une forme ou une autre avant. Ces deux-là non, du moins pas économiquement.

Élément 6. Le script d'expédition one-shot. Une skill Claude Code qui chaîne les appels CLI Gumroad en un seul prompt. Vous décrivez le produit. L'agent lance gumroad products create comme draft, upload le fichier (gumroad files upload), définit le prix et la devise, attache les tags, écrit la description dans l'appel create, lance gumroad products update pour attacher la cover, preview l'output avec --dry-run, puis appelle gumroad products publish une fois que vous confirmez.

La forme de la skill d'expédition ressemble grosso modo à ça :

gumroad products create \
  --name "Terminal Theme Pack v1" \
  --type digital \
  --price 12.00 \
  --tag "terminal" --tag "theme" --tag "dev-tools" \
  --description "$(cat landing.md)" \
  --custom-permalink "terminal-theme-v1" \
  --json --no-input

gumroad products update <id> --price 14.00 --dry-run --json --no-input

gumroad products publish <id> --json --no-input

\

Le run d'expédition complet pour un nouveau produit prenait ~4 heures de clic-clic-clic dans l'UI web Gumroad. C'est maintenant ~20 minutes de bout en bout, et le rôle humain se réduit à confirmer trois décisions : prix, cover, go-live. Règle dure écrite dans la skill dès le jour un : chaque changement de prix nécessite une étape de confirmation, jamais d'auto-exécution. J'ai mis le mauvais prix deux fois sur 22 lancements manuels. Un agent le fera plus vite et plus mal si vous ne pinez pas cet invariant. Le prompt de confirmation est l'autosave avant un boss fight, et je ne re-run pas ce donjon.

Élément 7. Le routeur multi-store. Pour les vendeurs qui gardent des stores séparés par marque (je le fais, un par niche, pour un positionnement propre), l'agent lit les tags du produit et route vers le token du bon store avant expédition. Pas de contamination cross-brand. C'est un petit guardrail qui prévient le genre d'erreur de cleanup de 30 minutes qui m'arrivait une fois par trimestre. Petit, mais le genre de petit qui compose.

Phase 4. Où le Produit Vivant Commence.

Un produit vit ou meurt dans les avis. La plupart des vendeurs le découvrent quand un remboursement arrive. Cette phase transforme chaque achat en input pour le cycle suivant, et c'est la partie qui découple réellement la stack d'un vendeur classique.

Élément 8. Le trigger post-achat, J+7. L'agent envoie un email sept jours après achat. Pas un jour, sept. Trois questions, pas "comment c'était ?". Les trois que j'ai affinées sur 22 lancements : pour quoi l'avez-vous réellement utilisé (usage réel versus celui que j'assumais), qu'attendiez-vous qui n'était pas là (détection de gap inverse), paieriez-vous pour une v2 qui corrige X (signal pricing pour le cycle de patch). L'email est écrit par produit et par profil d'acheteur (première fois versus repeat). L'un non-négociable ici : ne jamais trigger dans la fenêtre de remboursement. La fenêtre de remboursement Gumroad sur les produits digitaux est de sept jours. Demander du feedback dans cette fenêtre sur un lancement manuel il y a deux ans a doublé mon taux de remboursement en une semaine. Attendez la fin de la fenêtre. Puis demandez.

Élément 9. Le synthétiseur de sentiment et gap. Les réponses feedback vont à l'agent d'abord, jamais ma boîte mail. Il tague chaque réponse (demande de feature, bug, praise, confusion), agrège hebdomadairement par produit, et fait surface des patterns. Pas "lisez ces 200 emails". Plutôt "43% mentionnent X manquant, 17% veulent Y, 8% se plaignent de Z". Une lecture de cinq minutes, pas un slog de 200 emails. La vraie valeur kick in un layer plus haut : l'agent compare les patterns entre produits dans la même niche. Sur une niche non-tech que je gère, trois produits différents recevaient discrètement la même demande dans leurs avis. Je ne l'aurais jamais repéré en lisant produit par produit, parce que chaque instance était minoritaire dans son propre feedback. Agrégé sur la niche, c'était la demande #1. Ça a donné le prochain produit standalone. Règle ici : l'agent distribue les patterns, il ne rank pas les priorités. La fréquence n'est pas l'importance. Une plainte d'un acheteur high-value peut l'emporter sur trois demandes casual. La distribution va vers moi. Le ranking reste humain.

Élément 10. Le post-mortem remboursement. Chaque remboursement déclenche une petite passe forensique. L'agent tire la raison du remboursement (si l'acheteur en a donné une), cross-référence le profil d'achat original, et tague la cause probable : mauvais acheteur, feature manquante, problème qualité, mismatch pricing. Rapport hebdomadaire avec totaux et causes racines. L'agent ne supprime pas le coup au ventre d'une notification de remboursement à 3h du mat', je les reçois encore et je grimace encore. Il me donne un diagnostic au matin au lieu de me laisser mijoter jusqu'à lundi. C'est ça le vrai win.

La plupart des vendeurs expédient et oublient. Un agent continue d'écouter.

Phase 5. La Boucle se Ferme.

Seconde entrée pour le CLI, et celle qui transforme un pipeline de lancement en boucle produit.

Élément 11. Le drafter de v-patch. L'agent lit la synthèse feedback hebdomadaire de la Phase 4, identifie les demandes qui récurrent dans plus de 20% des réponses, et drafte la liste de priorités v1.1. J'approuve ou rejette chaque changement. Pour un bundle preset photo, v1.1 pourrait être "ajouter trois variants warm-tone de plus". Pour un workbook fiction writing, ça pourrait être "étendre le chapitre scene-structure et corriger la typo dans l'exercice 4". L'agent applique les changements au fichier source, régénère les dérivés (tweak cover si pertinent, pages preview), et puis, et c'est la partie qui ne fonctionne que post-CLI, re-upload via le CLI. gumroad files upload plus gumroad products update pousse une nouvelle version, et les acheteurs existants récupèrent le fichier mis à jour dans leur bibliothèque automatiquement. Fait via l'UI web, le même patch c'est dix minutes par produit : login, page produit, drawer edit files, drag, attendre l'upload, save, vérifier. Sur 22 produits avec une cadence patch mensuelle, ça fait 220 minutes de plomberie chaque mois, pour une tâche où le vrai travail était déjà fait. Le CLI en fait trente secondes. C'est sur ça que le cycle de patch mourrait avant. Pas la paresse. Juste les maths.

Élément 12. L'email de mise à jour contextualisé. L'email final aux acheteurs existants n'est pas "nouvelle version disponible, téléchargez ici". Il est par acheteur, contextualisé. Si l'acheteur a écrit un feedback mentionnant X, l'email ouvre avec un callback : "Vous avez signalé X dans votre feedback. v1.1 l'adresse directement. Le fichier mis à jour est dans votre bibliothèque Gumroad." Ce callback change la relation. L'acheteur ne se sent pas comme une entrée de liste, il se sent comme quelqu'un dont la note a été lue. Pour les acheteurs qui n'ont jamais répondu, l'email reste neutre mais toujours spécifique au produit, jamais un blast générique. Et un plafond dur, écrit dans la skill : un email de mise à jour par produit par mois, maximum. J'ai testé une cadence hebdomadaire il y a deux ans sur un produit. Le taux de désabonnement a triplé en trois semaines. Les acheteurs ne veulent pas une newsletter. Ils veulent un produit qui devient discrètement meilleur à un rythme soutenable.

La Vérité Ennuyeuse des Stores Scriptables.

Ce qui change réellement. L'étape d'expédition d'un lancement passe d'environ quatre heures à environ vingt minutes. Le feedback passe de "jamais collecté" à "synthétisé hebdomadairement". Le cycle de patch passe de "jamais" à "mensuel". Pas un multiplicateur de revenus. Un multiplicateur de temps, exactement aux endroits où le temps était piégé dans la plomberie.

Ce qui ne change pas. Le produit doit toujours être bon. Un agent ne sauve pas un PDF médiocre, il accélère juste la vitesse à laquelle vous apprenez que le PDF est médiocre. La niche doit toujours être réelle. Le positionnement doit toujours être honnête. Une stack construite par-dessus un mauvais produit vous enseigne vite que c'est un mauvais produit, ce qui est utile, mais ce n'est pas magique.

En 2025, un vendeur Gumroad avait un store. En 2026, il a un service qui tourne, écoute, et se réécrit. Le CLI est la plus petite pièce.

La boucle autour est le produit. Et c'est exponentiel.

Sources

• CLI Gumroad, repo officiel et instructions d'install : github.com/antiwork/gumroad-cli
• Skill Claude Code Gumroad (livrée in-repo) : SKILL.md
• Sahil Lavingia sur la culture engineering AI-first de Gumroad : interview Lenny's Newsletter

Drafté avec Claude, édité et expédié par moi.