Agent qui analyse Stripe : revenus, churn, anomalies

Ton dashboard Stripe te donne des chiffres. Il ne te dit pas pourquoi ton MRR a baissé de 4% ce mois-ci, ni que trois de tes plus gros comptes ont eu un failed payment la même semaine, ni que sept abonnements créés mardi viennent probablement de cartes volées. Un agent Claude branché sur Stripe fait ce travail d'interprétation. Cet article te montre comment l'assembler, quoi lui faire calculer, et avec quel prompt système démarrer cette semaine. Si tu veux d'abord poser les bases de Claude côté outils et workflows, on a un guide complet pour apprendre Claude qui te servira de socle.

On parle ici d'un agent au sens propre : une boucle où Claude raisonne, appelle un outil (l'API Stripe), reçoit la réponse, raisonne à nouveau, et finit par produire une analyse. Pas un prompt one-shot avec un CSV collé.

Ce qu'un agent Stripe + Claude fait que ton dashboard Stripe ne fait pas

Le dashboard Stripe est un outil de consultation. Tu y vois ton MRR, ton churn, tes paiements échoués. Pour comprendre pourquoi un chiffre bouge, tu dois ouvrir cinq vues différentes et faire le croisement de tête. L'agent fait ce croisement pour toi, à chaque fois, sans oublier d'angle.

Trois exemples concrets de ce qu'il repère et que tu rates :

• Ton MRR baisse de 800 € en mars. L'agent croise les events customer.subscription.updated avec les coupons appliqués et te répond : un coupon promo de 20% est arrivé à expiration le 28 février sur 12 comptes, dont 4 ont downgradé dans la foulée.
• Quatre disputes arrivent dans la même semaine. L'agent les groupe par BIN de carte et te montre que trois sortent de la même banque émettrice, qui a probablement déclenché une vague de chargebacks automatiques.
• Ton taux de failed payment monte de 0,4 point. L'agent isole le segment : ce sont quasi uniquement des cartes brésiliennes, et la cause est un changement de règle 3DS chez l'acquéreur local.

Aucune de ces analyses n'est hors de portée d'un humain. Aucune n'est faite en pratique parce qu'elles coûtent une heure chacune. C'est exactement le créneau des agents IA autonomes avec Claude : automatiser le travail d'interprétation qu'on ne fait jamais faute de temps.

Architecture minimale : Claude, l'API Stripe et le serveur MCP

La stack la plus courte qui marche tient en deux composants : Claude (via Claude Desktop ou l'API Anthropic) et un accès en lecture à l'API Stripe. Deux chemins selon ton niveau de tech.

Chemin 1, sans code : Claude Desktop + serveur MCP Stripe. Tu installes le serveur MCP Stripe en local, tu colles ta clé restricted Stripe (lecture seule), et tu interroges Claude Desktop en langage naturel. Pas de cron, pas de déploiement. Tu lances une analyse quand tu veux. C'est le bon point d'entrée pour un dirigeant qui veut tester avant d'industrialiser. Si tu n'as jamais touché à MCP, on a un tour d'horizon des serveurs MCP qui couvre l'installation.

Chemin 2, avec un peu de code : tool use direct via l'API Anthropic et tool use. Tu définis des tools (par exemple list_subscriptions, get_charges, list_disputes) qui wrappent les endpoints Stripe. Claude décide quoi appeler. Tu peux faire tourner ce script en cron, envoyer la sortie dans Slack ou par mail. C'est le bon chemin dès que tu veux du récurrent.

Côté Stripe, crée une restricted API key avec uniquement les scopes en lecture dont tu as besoin : charges:read, customers:read, subscriptions:read, disputes:read, invoices:read, balance_transactions:read. Pas d'écriture, jamais, surtout au début.

Ordre de grandeur de coût. Sur un compte avec 200 clients actifs et une analyse mensuelle complète (MRR, churn, disputes, anomalies), une session typique avec Sonnet consomme entre 80k et 200k tokens en entrée et quelques milliers en sortie. Avec Sonnet à environ 3 USD le million d'input et 15 USD le million d'output, tu es entre 0,30 et 0,80 USD par analyse. Tu peux passer à Opus pour des audits trimestriels plus poussés, c'est environ 5x plus cher mais le raisonnement long-format en vaut souvent la peine.

Les 4 analyses à faire calculer en premier

Ne demande pas tout d'un coup. Commence par ces quatre.

Question concrète à poser à l'agent pour chacune :

• MRR : « Compare le MRR au 1er du mois courant et au 1er du mois précédent. Détaille les mouvements en new business, expansion, contraction, churn. Cite les customer IDs pour les top 5 mouvements en valeur. »
• Churn : « Sur les 30 derniers jours, sépare les cancellations en volontaires et involontaires. Pour les involontaires, dis-moi combien ont été récupérés via Stripe Smart Retries. »
• Anomalies : « Liste les decline codes les plus fréquents sur les 7 derniers jours, par pays. Compare au taux moyen des 30 jours précédents. Flag tout segment qui dévie de plus de 2x. »
• Cohortes : « Pour les clients acquis en janvier, février et mars 2026, donne-moi le taux de rétention à M+1 et la raison principale de churn quand elle est identifiable. »

Le prompt système qui transforme Claude en analyste finance

Le prompt système fait 80% du travail. Voici un squelette utilisable tel quel, à adapter à ton contexte.

Tu es analyste finance senior pour une entreprise SaaS.
Tu as accès à l'API Stripe en lecture seule via les tools fournis.

Règles non négociables :
1. Tu ne donnes JAMAIS un chiffre sans l'avoir requêté.
   Si une donnée manque, tu le dis et tu arrêtes.
2. Tu cites systématiquement les IDs Stripe pertinents
   (sub_xxx, cus_xxx, ch_xxx) pour permettre la vérification.
3. Avant de conclure, tu listes tes hypothèses
   (période, devise, fuseau, exclusions test).
4. Tu ne fais pas de prévision. Tu décris ce qui s'est passé.
5. Si une analyse demande plus de 50 appels API,
   tu proposes d'abord un plan, tu n'exécutes pas tout.

Format de sortie obligatoire :
- Résumé exécutif : 5 lignes max
- Chiffres clés avec IDs sources
- Anomalies détectées (ou "aucune")
- Actions recommandées : 3 max, classées par impact
- Limites de l'analyse : ce que tu n'as pas pu vérifier

La règle qui change tout est la première. Sans elle, Claude va estimer, arrondir, extrapoler quand une période est trop large pour ses appels. Avec elle, il te dit « je n'ai pas pu charger les transactions au-delà du 15 mars, voici ce que j'ai », ce qui est mille fois plus utile qu'un chiffre faux.

Détecter les anomalies : ce que Claude voit que toi non

Le pattern le plus utile à apprendre à l'agent, c'est la comparaison fenêtre courante / fenêtre de référence. Tu ne lui dis pas « cherche des anomalies », formulation trop vague qui produit du bruit. Tu lui dis :

Compare la semaine du 14 au 20 avril à la moyenne des 4 semaines précédentes, sur ces dimensions : taux de décline par pays, taux de dispute, nombre de nouveaux abonnements par tranche horaire, distribution des montants. Flag tout écart supérieur à 2 écarts-types et propose une cause probable.

Exemples de patterns que ça remonte et qu'un humain rate :

• Sept abonnements créés entre 2h et 4h du matin UTC, mêmes prénoms, BINs séquentiels : test de cartes volées. Ton fraud system Stripe va peut-être les choper, mais peut-être pas si chaque charge est petite.
• Le taux de dispute passe de 0,3% à 1,1% sur un segment géographique précis. Souvent un changement côté banque, parfois un bug de facturation côté toi.
• Un pic de failed payments concentré sur les cartes Amex émises avant 2022. Ça arrive plus souvent qu'on ne croit, lié à des mises à jour de tokenisation.

L'agent ne va pas trouver tout ça tout seul. Il trouve ce que tu lui demandes de chercher. Le travail intelligent, c'est de lister les dimensions de comparaison pertinentes pour ton business et de les coder dans le prompt système.

Faire tourner l'agent en autonomie : cron, alertes, garde-fous

Trois niveaux d'autonomie, par ordre de complexité.

Niveau 1, manuel hebdo via Claude Desktop. Tu lances l'analyse tous les lundis matin, tu lis, tu décides. Ça prend dix minutes. Pour la plupart des dirigeants, c'est suffisant pendant six mois. N'industrialise pas trop tôt.

Niveau 2, cron hebdomadaire avec sortie Slack. Un script Python ou Node qui appelle l'API Anthropic avec tool use, exécute l'analyse, et poste le résumé exécutif dans un canal #stripe-weekly. Le détail complet va en thread. Compte une demi-journée pour mettre ça en place proprement.

Niveau 3, alertes temps réel sur anomalies. Webhooks Stripe vers ton agent, qui décide si l'event mérite une alerte ou non. Plus complexe à calibrer (faux positifs = bruit, faux négatifs = manqué), garde ça pour quand le niveau 2 tourne depuis trois mois.

Garde-fous obligatoires dès le niveau 2 :

• Clé API Stripe restricted en lecture seule, jamais une clé complète.
• Limite de tokens par run (par exemple 300k input max) pour éviter qu'une boucle infinie te coûte 50 USD.
• Log de chaque appel API Stripe avec timestamp, endpoint, nombre d'objets retournés. Tu veux pouvoir auditer.
• Pas d'écriture sur Stripe, jamais. Si l'agent doit déclencher une action (annuler un abonnement frauduleux), il poste une recommandation dans Slack et un humain clique.

Les limites à connaître avant de s'y mettre

L'agent n'est pas magique. Ce qu'il ne fait pas bien :

• Pas de FP&A. Pour de la prévision sérieuse, il te faut un vrai modèle avec hypothèses paramétrables. L'agent peut te sortir une projection naïve, pas un budget.
• Pas de comptabilité. Reconnaissance de revenu, TVA, écritures comptables : laisse ça à ton expert-comptable et à Pennylane ou équivalent. L'agent te donne des chiffres de gestion, pas des chiffres comptables.
• Sensible aux dates ambiguës. Si tu dis « le mois dernier » un 2 mai, il faut préciser : tout avril, ou les 30 derniers jours glissants ? Cadre dans ton prompt système.
• Coût qui explose sur les transactions brutes. Charger 50 000 charges brutes dans le contexte coûte cher en tokens et donne souvent un pire raisonnement qu'un agrégat. Préfère lui faire requêter list_balance_transactions avec des filtres précis et des agrégats côté Stripe quand c'est possible.
• Pas de mémoire entre sessions sans setup. Si tu veux que l'agent compare avec l'analyse de la semaine dernière, tu dois lui passer le rapport précédent dans le contexte, ou utiliser Claude Projects pour persister.

Passer à la pratique cette semaine

Action concrète, dans l'ordre. Lundi : crée une restricted API key Stripe avec les six scopes en lecture mentionnés plus haut. Mardi : installe Claude Desktop et le serveur MCP Stripe, fais ton premier prompt sur le MRR du mois dernier. Mercredi : code le prompt système avec les règles anti-hallucination. Jeudi : lance les quatre analyses prioritaires une par une, note ce qui marche et ce qui hallucine. Vendredi : décide si tu industrialises en cron ou si tu restes en manuel hebdo. Pour la plupart des comptes sous 500 clients actifs, le manuel hebdo suffit largement.

Si tu veux aller plus loin que ce premier agent Stripe et bâtir un vrai système d'agents qui couvre revenus, marketing et ops, c'est exactement ce qu'on outille dans notre parcours pour piloter vos agents autonomes de bout en bout, avec les prompts systèmes, les architectures MCP et les garde-fous prêts à déployer.