Brancher des services : e-mails, paiement, IA

L’app qui parle au monde

Le succès de l'app de Tom dépasse sa classe : une collègue de français l'utilise avec ses 4e, et un prof de maths d'un autre collège lui a écrit pour savoir « comment l'installer pour son établissement — et combien ça coûte ». Trois envies émergent : envoyer aux élèves un récap hebdomadaire par e-mail, ajouter un message d'encouragement généré par IA quand un élève termine sa journée, et proposer une version « classe » payante pour les profs des autres collèges. Trois fonctionnalités, un même mécanisme : faire dialoguer son app avec des services externes.

Ce dialogue passe par des API (interfaces de programmation). Le principe : un service — Resend pour les e-mails, Stripe pour le paiement, Claude pour l'IA — expose un guichet sur Internet. Ton app s'y présente avec une demande structurée (« envoie cet e-mail à cette adresse ») et une clé API qui prouve son identité, et le service exécute puis répond. Tu n'as pas besoin de comprendre comment Resend achemine un e-mail, pas plus que tu n'as besoin de comprendre une centrale électrique pour brancher une prise : l'API est la prise.

La règle d’or : les clés restent côté serveur

Avant le moindre branchement, une règle absolue. Ta clé API est une carte bancaire : quiconque la possède consomme le service en ton nom et à tes frais. Or, tout le code qui tourne dans un navigateur est lisible par n'importe qui — un simple F12 suffit. Conclusion implacable : une clé secrète ne doit jamais se trouver dans le code côté navigateur. Elle vit côté serveur, là où personne ne peut la lire.

« Mais je n'ai pas de serveur ! » Si, presque : Vercel (et ses concurrents) propose des fonctions serveur — de petits bouts de code hébergés chez eux, qui s'exécutent à la demande. Le schéma est toujours le même : le navigateur appelle ta fonction serveur (sans clé), la fonction appelle le service externe (avec la clé, stockée dans une variable d'environnement), et renvoie au navigateur uniquement le résultat. L'IA sait créer ces fonctions parfaitement — ton travail est d'exiger cette architecture dans tes prompts.

flowchart LR
  N["Navigateur de l'élève"] -->|"Demande sans aucune clé"| F["Fonction serveur sur Vercel"]
  F -->|"Appel avec la clé secrète"| S["Service externe : Resend, Stripe ou Claude"]
  S -->|"Réponse"| F
  F -->|"Résultat propre"| N

Envoyer des e-mails : le récap hebdo

Premier branchement : l'e-mail. On n'envoie pas d'e-mails automatiques depuis sa boîte Gmail — les fournisseurs le bloquent vite et c'est fragile. On passe par un service d'e-mail transactionnel comme Resend, Postmark ou Brevo : conçus pour les apps, fiables, et gratuits à petite échelle (Resend offre 100 e-mails par jour, très au-delà des besoins de Tom). Le prompt de Tom, complet :

Ajoute l'envoi d'un e-mail récapitulatif à mon app de suivi d'habitudes.
Contexte : app HTML/JS sur Vercel, données dans Supabase, authentification par lien magique.
Ce que je veux :
1. un bouton « recevoir mon récap de la semaine » sur la page principale
2. au clic, une fonction serveur Vercel calcule les streaks et les coches de la semaine de l'utilisateur connecté, et lui envoie un e-mail propre et lisible via Resend
3. la clé API Resend reste côté serveur, dans une variable d'environnement Vercel — jamais dans le code du navigateur
4. limite stricte : un envoi par utilisateur et par jour maximum, avec un message clair si la limite est atteinte
Guide-moi d'abord pour créer le compte Resend et configurer la variable d'environnement sur Vercel, puis code la fonction.
Une étape à la fois, j'attends de tester avant la suivante.

Arrête-toi sur la ligne 4 : « un envoi par utilisateur et par jour ». Pourquoi limiter une fonctionnalité gratuite ? Parce que tout bouton qui déclenche un service externe peut être martelé — par un élève farceur ou par un robot — et que chaque envoi consomme ton quota. Poser une limite dès la conception est un réflexe d'architecte : tu protèges ton service avant qu'il en ait besoin. On généralisera ce réflexe au chapitre 9.

Encaisser un paiement sans coder : Stripe Payment Links

Pour la version « classe » payante, Tom redoute le pire : le paiement en ligne, c'est sérieux, réglementé, anxiogène. Bonne surprise : Stripe, le service de paiement le plus utilisé par les développeurs, propose les Payment Links — des pages de paiement hébergées par Stripe, créées en quelques clics dans leur tableau de bord, sans une ligne de code. Tu crées un produit (« Version classe — 29 €/an »), Stripe génère une URL, et ton app n'a qu'à afficher un bouton pointant vers cette URL. Stripe gère la carte bancaire, la sécurité, la facturation, les remboursements.

• Crée un compte sur stripe.com et reste en mode test pour l'instant.
• Dans le tableau de bord : Produits → ajouter « Version classe » avec son prix.
• Génère le Payment Link du produit et copie l'URL.
• Demande à l'IA d'ajouter une page « version classe » avec les bénéfices et un bouton vers ce lien.
• Teste le parcours complet en mode test, puis active le mode réel quand tout est validé.

Les Payment Links ont des limites — pas de déblocage automatique de fonctionnalités dans l'app après paiement, par exemple. Pour la v1 de Tom, c'est parfait : le prof paie via le lien, Tom reçoit la notification Stripe et active la classe à la main. Cinq clients par mois, c'est gérable manuellement ; le jour où ils seront cinquante, il branchera l'automatisation (les « webhooks ») — un problème de riche, pour plus tard. Automatiser ce qui n'arrive que cinq fois par mois est une mauvaise affaire.

Ajouter une touche d’IA dans ton app

Dernier branchement, le plus savoureux : utiliser l'IA dans ton app — et plus seulement pour la construire. L'idée de Tom : quand un élève coche sa dernière habitude de la journée, un court message d'encouragement personnalisé apparaît, généré par l'API de Claude. Même architecture que l'e-mail : fonction serveur, clé en variable d'environnement, limite d'usage. Avec deux précautions nouvelles, propres à l'IA :

Ajoute une fonction « encouragement du jour » à mon app de suivi d'habitudes.
Quand l'utilisateur coche sa dernière habitude de la journée, appelle l'API de Claude depuis une fonction serveur Vercel pour générer un court message d'encouragement personnalisé :
- ton chaleureux mais pas niais, adapté à des collégiens
- mentionne le streak actuel et l'habitude la plus régulière de la semaine
- 2 phrases maximum, en français
Contraintes techniques :
1. la clé API reste dans une variable d'environnement, côté serveur uniquement
2. limite : un appel par utilisateur et par jour
3. prévois un message par défaut sympa si l'appel échoue ou dépasse 5 secondes — l'app ne doit JAMAIS casser à cause de cette fonction
Montre-moi le texte exact du prompt que la fonction enverra à Claude, pour que je puisse l'ajuster.

Deux lignes méritent ton attention. « Prévois un message par défaut si l'appel échoue » : c'est la dégradation élégante — une fonctionnalité bonus ne doit jamais pouvoir casser l'app qui la porte. Et « montre-moi le texte exact du prompt » : eh oui, ton app contient désormais elle-même un prompt, que tu peux raffiner comme tu as appris à raffiner les tiens. Tu écris des prompts qui génèrent du code qui envoie des prompts — la boucle est savoureuse, et tu en maîtrises chaque étage.

Quand un service externe tombe en panne

Dernière leçon de ce chapitre : ton app dépend désormais de services que tu ne contrôles pas. Resend, Stripe ou l'API de Claude peuvent avoir une panne, ralentir, ou changer leurs règles. Trois habitudes en proportion : vérifier la page de statut du service avant de chercher le bug chez toi (« Resend status » dans un moteur de recherche), prévoir un comportement de repli pour chaque branchement (message par défaut, bouton désactivé avec explication), et ne jamais faire dépendre la fonction cœur de ton app d'un service externe. Les habitudes de Tom se cochent même si l'IA, l'e-mail et le paiement sont tous les trois en panne — c'est ça, une architecture saine.

Ton app sait maintenant écrire, encaisser et réfléchir. Mais chaque branchement a aussi agrandi sa surface d'exposition : des clés à protéger, des entrées à valider, des limites à faire respecter. Avant d'aller plus loin, il est temps de sécuriser sérieusement l'ensemble — c'est le programme du chapitre 9.