Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

Use this file to discover all available pages before exploring further.

1

(Facultatif) Définir la portée de la base de code avec Ask Devin

Si vous ne savez pas comment votre application gère les paiements à l’heure actuelle — ni à quels fichiers et patterns vous référer dans votre spécification — utilisez Ask Devin pour commencer votre investigation :Utilisez les réponses pour compléter votre spécification — faites référence à des fichiers, noms de tables et patterns précis afin que Devin construise quelque chose qui s’intègre naturellement à votre base de code. Vous pouvez aussi démarrer une session Devin directement depuis Ask Devin, et celle-ci conservera tout ce qu’il a appris comme contexte.
2

Ajouter les clés de test Stripe

Devin a besoin de clés Stripe en mode test pour créer des sessions de paiement et vérifier le gestionnaire de webhook. Utilisez toujours des identifiants d’environnement de test (sandbox) — ne donnez jamais à Devin de clés Stripe de production.La façon la plus simple de procéder est de les stocker en tant que secrets d’organisation avant de démarrer la session :
  1. Allez dans Settings > Secrets et ajoutez :
  2. Devin y accède sous forme de variables d’environnement, de sorte qu’elles ne se retrouvent jamais en dur dans votre code source.
Les secrets d’organisation doivent être ajoutés avant de démarrer la session — ils sont injectés au démarrage de la session. Vous pouvez aussi fournir des secrets pendant la session via le chat, et Devin vous demandera de manière proactive tous les identifiants dont il a besoin lorsqu’il rencontre des variables d’environnement manquantes.
3

Transmettez les spécifications de votre checkout

Collez votre spécification — à partir d’un PRD, d’un ticket Linear ou d’un message Slack détaillé — directement dans Devin. Une bonne spécification de checkout couvre les paliers tarifaires, le flux de paiement et ce qui se passe après un paiement réussi. Plus c’est structuré, mieux c’est.Une bonne spécification pour Devin comprend trois éléments : quoi construire (niveaux de tarification, flux de paiement, gestionnaire de webhook), où cela se trouve (routes, tables, fichiers), et comment cela s’intègre (patterns existants à suivre). Vous n’avez pas besoin de spécifier chaque détail d’implémentation — Devin explore votre base de code pour combler les lacunes.
4

Devin builds and verifies in the browser

Devin lit votre spécification, explore la base de code pour trouver des patterns correspondants, puis implémente sur l’ensemble de la pile. Avant d’ouvrir une PR, il exécute votre application localement et ouvre son navigateur intégré pour vérifier que le flux de paiement fonctionne de bout en bout.Voici à quoi cela ressemble pour l’exemple de paiement Stripe :
  1. Crée la migration — Ajoute la table subscriptions avec des colonnes pour user_id, stripe_subscription_id, plan, status, et current_period_end
  2. Construit la page de tarification — Crée les cartes de tarification à trois niveaux sur /pricing, chacune avec un bouton « S’abonner » qui envoie une requête à l’API de paiement
  3. Implémente la création de session de paiement — Construit POST /api/checkout/sessions qui crée une session Stripe Checkout avec le bon identifiant de prix, l’e-mail du client et les URLs de redirection
  4. Ajoute le gestionnaire de webhook — Implémente POST /api/webhooks/stripe avec la vérification de signature, la gestion de l’événement checkout.session.completed, et les mises à jour de la base de données
  5. Construit la page de succès — Crée /checkout/success qui récupère la session Stripe, affiche le nom du plan, le montant facturé, et un lien « Aller au tableau de bord »
  6. Écrit les tests — Tests pour la vérification de la signature du webhook (valide, invalide, manquante), la création de session de paiement, et la logique de mise à jour du plan dans la base de données
  7. Ouvre le navigateur — Démarre le serveur de développement, navigue vers /pricing, clique sur « S’abonner » pour le niveau Pro, vérifie que la redirection Stripe Checkout fonctionne, et s’assure que la page de succès s’affiche correctement après un paiement test
  8. Ouvre une PR — Livre toutes les modifications avec un résumé de ce qui a été implémenté et comment cela a été vérifié
L’étape de vérification dans le navigateur détecte des problèmes que les tests unitaires manquent — une carte de tarification qui ne déclenche pas le paiement, une URL de redirection qui renvoie une erreur 404, ou une page de succès qui ne parvient pas à charger les détails de la session. Si vous avez défini un skill de test local, Devin suit ces étapes automatiquement pour chaque fonctionnalité qu’il construit.
5

Iterate from the PR

Une fois la PR ouverte, envoyez des invites de suivi dans la même session pour étendre ou ajuster le flux de paiement.
6

Review the PR with Devin Review

Une fois que Devin ouvre la PR, utilisez Devin Review pour examiner les modifications. Devin Review dispose du contexte complet de votre base de code et peut détecter des bugs, des problèmes de sécurité et des incohérences de style dans le diff. Vous pouvez poser des questions de suivi dans le chat de révision — par exemple, « Le gestionnaire de webhook valide-t-il le type d’événement avant de le traiter ? » — et Devin répondra en se basant sur le code réel.