SMF·DRIP
Un prompt peut-il remplacer Drip ?
Newsletters et publication — email newsletters and creator publishing
Bordereau de suivi des pièces
Verdict
Un seul email déclenché par événement — écouter un webhook de boutique, attendre un délai fixé, vérifier si un achat a eu lieu, et envoyer via SES si ce n’est pas le cas — c’est une vraie automatisation fonctionnelle et un projet d’une session raisonnable pour ce seul déclencheur. Le vrai produit de Drip, c’est toute une bibliothèque de déclencheurs et de séquences ramifiées réagissant à tout un flux d’événements de boutique ; cette construction gère exactement l’un d’entre eux, honnêtement.
Pièce A — Le prompt
Reçu le31.07.2026Construis une automatisation email e-commerce à un seul déclencheur : un récepteur de webhook, une tâche de délai-et-vérification, et Amazon SES pour l’envoi. Stack : routes API Next.js, PostgreSQL pour suivre les envois en attente, une file de tâches (BullMQ avec Redis) pour la vérification différée, Amazon SES.
Boucle centrale : expose un point d’accès webhook que la plateforme de boutique appelle quand un checkout démarre (le `checkouts/create` de Shopify est une bonne cible concrète — choisis une plateforme plutôt que d’essayer de prendre en charge chaque forme de webhook). Stocke l’identifiant de panier et l’email du client, et planifie une tâche différée (par exemple une heure plus tard) qui vérifie si un webhook `orders/create` pour le même panier est arrivé entre-temps. Si non, envoie un email de rappel via SES avec un lien vers le panier. Journalise chaque envoi et si un achat a fini par suivre, pour une vue basique « est-ce que ça a marché » — pas une attribution de revenus complète, juste un oui/non par email envoyé.
Nécessite un compte de plateforme de boutique avec accès webhook (la boutique de développement gratuite de Shopify suffit pour construire et tester), Redis pour la file de tâches différées, et un compte AWS avec accès SES plus un domaine d’envoi vérifié.
Ne construis pas : des types de déclencheurs supplémentaires au-delà de l’abandon de panier, des séquences ramifiées à plusieurs étapes, la normalisation de webhooks multi-plateformes (prendre en charge Shopify, WooCommerce et d’autres à la fois), ni un reporting d’attribution de revenus au-delà d’un simple indicateur de conversion — chacun de ceux-là est une extension légitime, mais aucun n’a sa place dans une construction honnête sur le fait de bien faire un seul déclencheur.L’ouverture pré-remplit le prompt — il ne reste qu’à appuyer sur entrée.
Pièce B — Ce que tu perds
- B.1 une bibliothèque de déclencheurs préconstruits au-delà de l’abandon de panier (abandon de navigation, ventes additionnelles post-achat, séquences de reconquête)
- B.2 une logique d’automatisation ramifiée et multi-étapes au lieu d’un seul déclencheur linéaire
- B.3 la résolution d’identité qui fusionne la navigation anonyme d’un acheteur avec son achat final
- B.4 un reporting d’attribution de revenus reliant les emails envoyés aux ventes réelles
- B.5 des intégrations natives pour chaque grande plateforme e-commerce, pas juste une forme de webhook
Alternatives existantes
Pièce C — Pourquoi certains continuent de payer : deliverability, growth network, and integrations
Les gens paient Drip parce qu’un email de panier abandonné, c’est un bon début, mais le vrai marketing e-commerce, ça veut dire des dizaines de déclencheurs réagissant correctement à un flux d’événements désordonné et à haut volume, en attribuant correctement quel email a vraiment généré quelle vente. Cette étendue et cette fiabilité à volume, c’est le produit, pas l’idée de « envoyer un email quand quelque chose se passe ».
Questions
Puis-je importer mes flux Drip existants ?
Non — les définitions de workflow visuel de Drip sont internes à leur plateforme et ne s’exportent pas dans un format portable. Tu reconstruirais le seul déclencheur dont tu as vraiment besoin depuis ce prompt.
Ça marche sur mon téléphone ?
Il n’y a pas d’application grand public ici — ceci tourne comme un service backend réagissant à des webhooks. Tu vérifierais les logs et la configuration depuis un tableau de bord web, qui fonctionne dans un navigateur mobile mais n’est pas conçu pour ça.
Combien ça coûte à faire tourner ?
SES coûte environ 0,10 $ pour 1 000 emails. La file de tâches et le récepteur de webhook ont besoin d’un petit serveur toujours actif, quelques dollars par mois — ça ne peut pas être qu’une fonction serverless puisque ça doit planifier de façon fiable des vérifications différées.
Quelle est la seule chose qui ne survit pas à la reconstruction ?
La couverture. Drip réagit à tout un catalogue d’événements de boutique avec une logique ramifiée ; cette construction gère exactement le seul déclencheur que tu configures, et chaque autre automatisation utile (abandon de navigation, emails de reconquête, ventes additionnelles) est une construction séparée depuis zéro.
Outils proches
Récépissé