Donner l'accès à votre client dès qu'il paie
MAJ du 12 avril 2026
Un client paie votre programme, et son compte reste bloqué en accès gratuit tant que vous n'avez pas changé sa ligne à la main. Le soir, le week-end, en déplacement : entre son paiement et son accès, il y a vous. Et chaque minute d'attente nourrit le doute et les demandes de remboursement.
Cette masterclass vous montre comment supprimer cette étape manuelle : le paiement déclenche l'accès tout seul, à la seconde, même quand vous dormez. Six étapes, de la colonne dans votre base au test final avec un faux paiement.
Ce que cet exercice ne peut pas casser
L'exercice du jour se fait sur une feuille, en français, sans une ligne de code. Et quand vous brancherez le webhook, tout se teste en local avec un faux paiement : vous ne touchez à de l'argent réel qu'une fois certain que ça marche.
Ce que vous saurez faire à la fin
- Expliquer ce qu'est un webhook et pourquoi c'est lui qui sécurise un paiement, pas une vérification côté navigateur.
- Écrire sur le papier la logique exacte de votre upgrade : quel événement écouter, quel client retrouver, quel champ changer.
- Brancher Stripe sur votre base pour que le passage en Pro soit instantané et impossible à falsifier.
- Tester votre webhook en local avant de toucher à la production.
- Niveau membre· le prompt prêt à coller qui écrit le code du webhook adapté à votre stack, et vous interroge si vous hésitez sur une étape.
- Niveau Pro· je branche le webhook avec vous en direct, je gère les cas limites (doublons, remboursements, emails qui ne matchent pas) et je débloque vos erreurs en live.
Le chemin que parcourt un paiement réussi, de serveur à serveur, jusqu'au compte Pro.
Pourquoi un webhook, et pourquoi exactement six étapes
Un webhook, c'est une porte que Stripe vient frapper chez vous dès qu'il se passe quelque chose. Le paiement réussit, Stripe envoie un message à votre serveur : voici qui a payé, voici combien. Votre serveur écoute, comprend, et agit. La raison pour laquelle on passe par un webhook, et pas par une vérification quand le client revient sur le site, tient en un mot : la confiance. Un client peut modifier son navigateur, falsifier une réponse, contourner un bout de JavaScript. Il ne peut pas falsifier un message que Stripe envoie depuis ses propres serveurs, signé avec une clé secrète. La méthode tient en six étapes. Pas cinq, parce qu'on ne peut pas tester sans avoir préparé la base avant. Pas sept, parce que la sécurité et le déploiement ne se découpent pas davantage sans devenir confus.
1Préparer la base : où va atterrir le résultatdoute : « où s'écrit le passage en Pro ? »
Avant d'écouter quoi que ce soit, vous devez savoir où l'information va se ranger. Votre table d'utilisateurs (souvent appelée profiles dans Supabase) doit avoir une colonne qui dit le niveau d'accès, par exemple tier, avec deux valeurs possibles : free et pro. Par défaut, tout le monde est free. C'est cette colonne que le webhook viendra changer. Si elle n'existe pas, vous la créez maintenant : tant que cette cible n'existe pas, le reste n'a nulle part où écrire.
2Récupérer les trois clés : votre laissez-passerdoute : « comment deux services qui ne se connaissent pas se font-ils confiance ? »
Un webhook met en relation deux services étrangers l'un à l'autre. Pour qu'ils se fassent confiance, il vous faut trois clés : la clé secrète de Stripe (pour parler à Stripe), la clé de signature du webhook (pour vérifier que le message vient bien de Stripe et pas d'un imposteur), et la clé d'administration de votre base (pour avoir le droit de changer la ligne d'un utilisateur). Ces trois clés ne vivent jamais en clair dans le code : elles vont dans vos variables d'environnement. Pour les chiffrer proprement, voyez Garder ses clés secrètes même sur GitHub.
3Écrire la logique de l'upgrade : le cerveau du webhookdoute : « et si je ne sais pas coder ? »
C'est l'étape qui fait peur et qui ne devrait pas. En une phrase : quand Stripe me dit qu'un paiement réussi est arrivé, je prends l'email du client, je trouve sa ligne dans ma base, et je passe son tier à pro. Tout le reste du code n'est que de la plomberie autour de cette phrase. Si vous savez l'écrire en français, vous savez ce que le code doit faire. La machine, elle, ne fait que la traduire.
4Vérifier la signature : la serrure de la portedoute : « qui me prouve que le message vient de Stripe ? »
C'est la ligne qu'on oublie et qui coûte cher. Avant de croire le message, votre serveur vérifie qu'il vient vraiment de Stripe, grâce à la clé de signature récupérée à l'étape 2. Sans ce contrôle, n'importe qui connaissant votre adresse pourrait simuler un faux paiement et s'offrir un accès Pro gratuit. Cette étape transforme une porte ouverte en porte verrouillée. On ne la saute jamais.
5Déclarer le webhook dans Stripe : donner l'adressedoute : « comment Stripe sait-il où frapper ? »
Stripe ne devine pas où frapper. Vous allez dans Stripe, section Webhooks, et vous donnez l'adresse de votre serveur, par exemple votredomaine.com/api/stripe/webhook. Vous précisez quel événement vous intéresse : le paiement réussi (checkout.session.completed). Stripe vous remet alors une clé de signature propre à cet endpoint : c'est elle qui rejoint vos variables d'environnement à l'étape 2. Le lien est posé dans les deux sens.
6Tester avant de jouer avec de l'argent réeldoute : « et si ça casse en production ? »
Jamais en production sans avoir testé. Stripe fournit un outil qui simule un faux paiement vers votre serveur local. Vous déclenchez le faux événement, vous regardez votre serveur répondre que le message est bien reçu, et vous vérifiez dans votre base que la ligne est passée en pro. Quand ça marche en local, et seulement là, vous déployez. Vous savez alors que le jour où un vrai client paiera à 22h47 un dimanche soir, son accès s'ouvrira tout seul.
À vous de jouer : votre phrase d'upgrade
Faites l'étape 3 à la main, sur une feuille. C'est elle qui contient toute la valeur, et elle ne demande aucune ligne de code. Remplissez les blancs un par un.
Le résultat, en 30 secondes
À partir de votre seule phrase d'upgrade et du nom de votre table, le prompt écrit le webhook complet, prêt à coller, commenté en français, avec la marche à suivre et les erreurs à éviter.
Ma logique reformulée : quand Stripe envoie le paiement réussi, je récupère l'email du client, je le retrouve dans la table profiles, je passe son champ tier de free à pro. Le code du webhook : un seul bloc, chaque partie commentée en français, la vérification de signature mise en évidence. Si ça ne marche pas : signature refusée (clé d'endpoint), variable manquante, client introuvable (email qui ne matche pas).
Le prompt prêt à coller
# RÔLE Tu es un développeur back-end senior, spécialiste des paiements en ligne et des bases de données. Tu écris du code clair, sécurisé, commenté en français, qui tourne en production. Tu ne t'appuies QUE sur ce que je te donne. Tout ce qui manque (mon framework, le nom de ma table, le nom de mes champs), tu me le demandes au lieu de l'inventer. Si une approche est risquée pour la sécurité, tu me préviens. # CONTEXTE Je veux brancher un webhook entre mon processeur de paiement et ma base de données, pour que le compte d'un client passe automatiquement en niveau payant dès qu'il paie. Je n'ai pas envie de faire ce passage à la main pour chaque client. Ma logique d'upgrade, en une phrase (si je l'ai déjà écrite) : [collez ici votre phrase de l'étape 3, par exemple : quand un paiement réussi arrive, je récupère l'email du client, je le retrouve dans ma table profiles, je passe son champ tier de free à pro].
Le prompt écrit le code complet de votre webhook à partir de votre phrase d'upgrade, adapté à votre framework et à votre base, avec la marche à suivre et le diagnostic des trois erreurs classiques. Si vous séchez sur une étape, il passe en mode interview et vous questionne pas à pas. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Votre webhook est en ligne. Quelqu'un découvre son adresse et lui envoie un faux message de paiement réussi pour s'offrir un accès Pro gratuit. Que se passe-t-il si vous avez suivi la méthode ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
En une phrase, à quelqu'un qui n'y connaît rien : pourquoi fait-on confiance à un message signé par Stripe plutôt qu'à une vérification dans le navigateur du client ? Si vous savez le dire simplement, le système est à vous.
Ce que vous savez faire maintenant
- Expliquer pourquoi un message de serveur à serveur, signé, est la seule preuve fiable qu'un paiement a eu lieu.
- Écrire votre phrase d'upgrade : l'événement écouté, le client retrouvé, le champ qui change.
- Dérouler les six étapes du branchement, de la colonne dans la base au test en local avec un faux paiement.
Un client peut falsifier son navigateur, il ne peut pas falsifier un message que Stripe signe et envoie depuis ses propres serveurs.
Continuez seul
Une fois les paiements uniques automatisés, la marche suivante : les abonnements récurrents.
Encaisser cinq cents euros chaque année par client →Faites-le avec moi
Je branche le webhook avec vous en direct, je gère les cas limites (doublons, remboursements, emails qui ne matchent pas) et je débloque vos erreurs en live. Vous repartez avec un webhook qui tourne et que vous comprenez.