--- title: "Stripe partie 1 : checkout, subscriptions, test vs production" description: "Encaisser de vrais paiements avec Stripe Checkout et les subscriptions, modéliser des prix mensuels et annuels et travailler en sécurité en mode test avant de passer en live" type: "lesson" locale: "fr" course: "Le stack applicatif moderne - Auth, données et paiements" number: "3.5" canonical: "https://agenticschool.dev/fr/cours/modern-app-stack/stripe-part-1-checkout-subscriptions-test-vs-production" datePublished: "2026-06-12" dateModified: "2026-06-12" --- # Stripe partie 1 : checkout, subscriptions, test vs production - Course: Le stack applicatif moderne - Auth, données et paiements - Lesson: 3.5 - Duration: 30 min - Level: fortgeschritten - Status: published - Canonical URL: https://agenticschool.dev/fr/cours/modern-app-stack/stripe-part-1-checkout-subscriptions-test-vs-production - Locale: fr > Encaisser de vrais paiements avec Stripe Checkout et les subscriptions, modéliser des prix mensuels et annuels et travailler en sécurité en mode test avant de passer en live ## Summary Ici votre produit peut gagner de l'argent. Stripe gère les paiements pour que vous ne touchiez jamais de données de carte brutes. Cette leçon couvre Embedded versus Hosted Checkout, le modèle produits-et-prix, les subscriptions avec facturation mensuelle et annuelle, les cartes de test contre lesquelles vous construisez (4242 4242 4242 4242) et la stricte séparation test/production qui vous laisse facturer les clients avec confiance sans risquer d'argent réel en development. ## What you learn - Embedded versus Hosted Stripe Checkout et pourquoi vous ne gérez jamais les données de carte vous-même - Le modèle produits-et-prix et les subscriptions avec facturation mensuelle versus annuelle - Le mode test avec la carte de test 4242 et le chemin propre vers la production ## Vue d'ensemble Auth, données et secrets sont en place. Maintenant votre produit peut gagner de l'argent. Stripe est le standard pour encaisser des paiements, et l'avantage principal est que vous ne touchez jamais un numéro de carte de crédit brut - Stripe le collecte, si bien que votre charge de conformité passe d'effrayante à gérable. Cette leçon vous amène à une subscription fonctionnelle : les deux saveurs de checkout, comment produits et prix modélisent votre tarification, comment les subscriptions gèrent la facturation récurrente y compris le toggle mensuel versus annuel dont votre page de pricing a besoin, et la discipline du mode test qui vous laisse tout bâtir et vérifier sans bouger un centime d'argent réel. ## Ce que vous allez apprendre Vous allez apprendre la différence entre Hosted et Embedded Checkout et quand utiliser chacun, comment le modèle produits-et-prix de Stripe se mappe sur vos paliers de tarification, comment les subscriptions gèrent la facturation récurrente mensuelle et annuelle, comment tout bâtir en mode test avec les cartes de test de Stripe et la checklist propre pour passer en production une fois que tout fonctionne. ## Prérequis Une app fonctionnelle avec auth et données et la discipline des secrets de la leçon précédente, car les clés Stripe font partie des plus sensibles que vous tiendrez jamais - une clé live fuitée est une ligne directe vers votre argent. Vous devez aussi être à l'aise avec le fait que test et production sont des mondes séparés, exactement comme avec Clerk. ## Le problème Les débutants supposent qu'encaisser des paiements veut dire bâtir un formulaire de carte de crédit et stocker les numéros de carte. Ce chemin est un cauchemar : gérer des cartes brutes vous met sous tout le poids de la conformité PCI, et une erreur vous expose à de la fraude et une responsabilité juridique que vous n'êtes pas équipé pour porter. Alors les gens évitent le débit tout court et laissent de l'argent sur la table, ou bâtissent quelque chose d'insécurisé. Stripe existe précisément pour que vous ne stockiez jamais un numéro de carte. Vous renvoyez l'étape de paiement à Stripe, il collecte la carte sur sa propre infrastructure sécurisée et vous communique le résultat. Votre job rétrécit à « configurer les produits et réagir à ce que Stripe vous dit », ce qui est totalement faisable. ## Hosted versus Embedded Checkout Stripe Checkout est une page de paiement pré-bâtie et sécurisée que Stripe maintient, donc vous obtenez un flux de paiement poli et conforme PCI sans bâtir de formulaire. Il vient en deux saveurs. Hosted Checkout redirige le client vers une page hébergée par Stripe (checkout.stripe.com), il paie, et Stripe le redirige vers votre URL de succès - le plus simple à mettre en place, entièrement maintenu par Stripe. Embedded Checkout rend la même expérience de paiement sécurisée à l'intérieur de votre propre page, si bien que le client ne quitte jamais votre app, ce qui peut améliorer la conversion et se sentir plus natif. Les deux sont également sûrs, car Stripe gère les données de carte dans les deux cas ; la différence est purement de savoir si le paiement a lieu sur la page de Stripe ou intégré dans la vôtre. Démarrez avec Hosted pour être fonctionnel le plus vite, puis passez à Embedded pour une expérience plus fluide (la partie 2 couvre Embedded en détail). - Hosted Checkout : rediriger vers une page Stripe, payer, rediriger de retour. Le plus rapide à shipper, zéro gestion de carte. - Embedded Checkout : le même flux sécurisé, rendu dans votre propre app. Meilleure conversion, plus de finition. - Les deux sont également sûrs - Stripe gère la carte dans les deux cas. Le choix concerne l'expérience utilisateur. - Vous ne voyez ni ne stockez de numéro de carte avec aucune des deux options. ## Produits et prix Stripe modélise votre tarification avec deux objets liés : un produit et un ou plusieurs prix. Un produit est la chose que vous vendez (« plan Pro »). Un prix est une façon précise de payer pour ça (« 20 USD par mois » ou « 200 USD par an »). Un produit peut avoir plusieurs prix - c'est exactement ainsi que vous bâtissez une page de pricing avec un toggle mensuel/annuel : le même produit Pro a un prix mensuel et un prix annuel, et votre toggle bascule le prix que le checkout utilise. Vous créez produits et prix dans le dashboard Stripe (ou via l'API), et chaque prix reçoit un ID comme price_xxx que vous référencez quand vous lancez un checkout. Garder les prix comme objets séparés, au lieu de mettre les montants en dur dans votre code, signifie que vous pouvez changer la tarification dans le dashboard sans redéployer. - Produit : ce que vous vendez (le « plan Pro »). - Prix : une façon de payer pour ça (mensuel vs annuel sont deux prix sur le même produit). - Un toggle mensuel/annuel est simplement le choix entre deux IDs de prix au moment du checkout. - Référencez les prix par leur ID price_xxx ; changez les montants dans le dashboard sans toucher au code. ## Subscriptions : mensuel et annuel Une subscription est un prix facturé selon un calendrier récurrent. Quand un client fait un checkout avec un prix récurrent, Stripe crée une subscription et débite sa carte automatiquement à chaque cycle - mensuel ou annuel - et gère les renouvellements, les nouvelles tentatives sur paiements échoués et les annulations pour vous. C'est le moteur des revenus SaaS, et Stripe pilote le cycle de facturation pour que vous n'ayez pas à le faire. Pour la page de pricing que le style maison de ce cours exige, vous modélisez deux prix récurrents par palier (un prix mensuel et un prix annuel), mettez la page par défaut sur le prix annuel par mois et laissez le toggle basculer vers mensuel. Voici la forme pour lancer un subscription checkout - la surface d'API exacte évolue, alors suivez les docs à jour de Stripe, mais la structure reste stable. ```typescript // Backend uniquement (utilise la SECRET key). Crée une checkout session pour un // prix récurrent. L'ID de prix décide mensuel vs annuel. import Stripe from 'stripe' const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!) export async function createSubscriptionCheckout(opts: { priceId: string // price_xxx pour le plan mensuel OU annuel choisi customerEmail: string }) { return stripe.checkout.sessions.create({ mode: 'subscription', // facturation récurrente, pas un paiement unique line_items: [{ price: opts.priceId, quantity: 1 }], customer_email: opts.customerEmail, success_url: 'https://app.yoursite.com/welcome?session_id={CHECKOUT_SESSION_ID}', cancel_url: 'https://app.yoursite.com/pricing', }) } ``` Une subscription checkout session. mode: subscription signifie récurrent ; l'ID de prix choisit mensuel ou annuel. Cela tourne sur le backend avec votre secret key, jamais dans le navigateur. La session qu'il renvoie est ce vers quoi vous redirigez le client (Hosted) ou ce que vous rendez dans votre page (Embedded). Dans les deux cas, la carte est collectée par Stripe. ## Mode test et cartes de test Stripe vous donne deux modes totalement séparés - test et live - chacun avec ses propres clés et ses propres données. En mode test, vous bâtissez et vérifiez tout le flux de paiement sans bouger d'argent réel, avec des numéros de carte de test spéciaux que Stripe reconnaît. La fameuse est 4242 4242 4242 4242 : une Visa qui réussit toujours. Stripe offre aussi des cartes qui simulent des échecs, refus et défis d'authentification, pour que vous puissiez tester aussi les chemins malheureux. Utilisez n'importe quelle date d'expiration future, n'importe quel CVC à trois chiffres et n'importe quel code postal. Faites tout votre development ici. Vos clés de test commencent par sk_test et pk_test et reflètent la même convention de préfixe que vous avez vue avec Clerk. - 4242 4242 4242 4242 - réussit à chaque fois. Votre défaut pour tester le happy path. - 4000 0000 0000 0002 - toujours refusée, pour que vous puissiez tester la gestion d'erreur. - 4000 0025 0000 3155 - exige une authentification (3D Secure), pour que vous puissiez tester ce flux. - Utilisez n'importe quelle date d'expiration future, n'importe quel CVC, n'importe quel code postal. Les vraies cartes ne font rien en mode test. Les données du mode test (clients, subscriptions, paiements) sont totalement séparées des données live et ne se transfèrent jamais. Quand vous passez en live, vous démarrez avec un dashboard live propre. Cette séparation est une fonctionnalité : vous pouvez expérimenter librement sans jamais craindre un vrai débit. ## Passer en production Une fois que tout fonctionne en mode test, passer en live est une courte checklist soigneuse plutôt qu'une reconstruction. Vous activez votre compte Stripe (Stripe a besoin de vos coordonnées d'entreprise et bancaires pour vous payer), recréez vos produits et prix en mode live si vous ne les avez faits qu'en test, échangez vos clés test contre des clés live dans votre environnement déployé et mettez à jour tous les IDs de prix que votre code référence vers les IDs live. Puis vous faites vous-même une vraie petite transaction pour confirmer que toute la boucle fonctionne de bout en bout avec des clés live. Crucialement, gardez test et live strictement séparés - ne collez jamais une clé live dans un fichier env de development. La partie 2 ajoute le setup de webhooks dont la facturation de production a vraiment besoin, alors traitez le passage en live comme « prêt à encaisser des paiements » plutôt que « pleinement durci pour la production », jusqu'à ce que vous ayez fait la partie 2. - Activez votre compte Stripe avec de vraies coordonnées d'entreprise et bancaires, pour que les versements fonctionnent. - Recréez produits et prix en mode live ; notez les nouveaux IDs price_xxx live. - Échangez sk_test / pk_test contre sk_live / pk_live uniquement dans votre environnement déployé. - Faites vous-même une petite vraie transaction pour confirmer la boucle live, puis remboursez-la. - Ne l'appelez pas fini tant que la partie 2 n'a pas câblé les webhooks - ils sont la façon dont votre app apprend ce qui s'est vraiment passé. ## Erreurs fréquentes Les courantes : mettre la Stripe secret key dans le code frontend, où chaque visiteur peut la lire (elle n'appartient qu'au backend) ; mettre les montants de prix en dur dans le code au lieu de référencer des IDs de prix, si bien qu'un changement de prix veut dire un re-déploiement ; oublier que les données test et live ne se connectent jamais et paniquer parce que la production a l'air vide ; et la grosse, contre laquelle ce cours prévient sans cesse - penser que le checkout seul suffit. Sans webhooks (partie 2), votre app devine si un paiement a vraiment réussi. Bâtissez en mode test, gardez la secret key au backend et traitez la partie 2 comme obligatoire, pas optionnelle. ## ROI business Les paiements sont le moment où votre produit cesse d'être un centre de coûts et devient un business. Stripe laisse une fondatrice en solo encaisser de l'argent de partout dans le monde, selon un calendrier récurrent, sans équipe de paiements ni auditeurs PCI, en un après-midi. Les subscriptions transforment spécifiquement un effort ponctuel en revenu récurrent, ce qui est tout l'attrait financier du SaaS - vous construisez une fois et gagnez chaque mois. Et le toggle mensuel versus annuel n'est pas cosmétique : les plans annuels améliorent le cashflow et réduisent le churn, ce pour quoi le style maison de ce cours met la page de pricing par défaut sur le prix annuel. Être bien payé est autant une décision produit qu'une décision technique. ## Checklist Vous êtes prêt pour la partie 2 quand tout ceci est vrai en mode test. - Vous savez expliquer pourquoi vous ne gérez jamais de données de carte brutes et ce que le checkout fait pour vous. - Vous avez créé un produit avec à la fois un prix mensuel et un prix annuel. - Un subscription checkout fonctionne en mode test avec la carte 4242 4242 4242 4242. - La Stripe secret key vit uniquement au backend, dans un fichier env gitignored. ## Ressources Les docs Stripe et la référence des cartes de test sont essentielles et toujours à jour - gardez-les ouvertes pendant que vous construisez. La Stripe CLI (fortement utilisée en partie 2) vaut d'être installée dès maintenant. Votre page de pricing devrait suivre le style maison de ce cours : prix annuel montré par défaut par mois, avec un toggle mensuel/annuel. Ensuite, la partie 2 rend la facturation vraiment fiable avec les webhooks. ## Votre mission En mode test, créez un produit Pro avec un prix mensuel et un prix annuel, puis bâtissez un subscription checkout qu'un utilisateur connecté peut compléter avec la carte de test 4242. Confirmez que la subscription apparaît dans votre dashboard Stripe de test. Essayez ensuite la carte refusée (4000 0000 0000 0002) et remarquez comment votre app gère l'échec - cette conscience du chemin malheureux sépare un vrai flux de facturation d'une démo. ## Prochaine leçon Le checkout n'est que la moitié de l'histoire. La prochaine leçon gère les parties qui rendent la facturation digne de confiance : les webhooks (et pourquoi le polling est le mauvais instinct), la vérification de signature, l'idempotence, la proration quand un client upgrade en milieu de cycle, les coupons et promotion codes et l'Embedded Checkout. Ce sont les détails qui séparent un jouet d'un vrai système de facturation. ## Transcript Ici votre produit peut gagner de l'argent. Stripe gère les paiements pour que vous ne touchiez jamais de données de carte brutes. Cette leçon couvre Embedded versus Hosted Checkout, le modèle produits-et-prix, les subscriptions avec facturation mensuelle et annuelle, les cartes de test contre lesquelles vous construisez (4242 4242 4242 4242) et la stricte séparation test/production qui vous laisse facturer les clients avec confiance sans risquer d'argent réel en development.