Agent qui analyse Stripe : revenus, churn, anomalies

Le lundi matin, tu ouvres Stripe Dashboard. Tu regardes le MRR, tu compares à la semaine dernière, tu descends dans la liste des nouveaux abonnements, tu vérifies les échecs de paiement, tu croises deux exports CSV dans un Google Sheet pour comprendre si le pic vient d'un client ou d'une tendance. Deux heures plus tard, tu as un chiffre à annoncer en réunion et une intuition floue sur le reste. C'est exactement ce qu'un agent Claude branché à Stripe via MCP fait sauter. Pas en te donnant un plus joli dashboard, mais en répondant directement à la question que tu te poses, avec le contexte croisé qu'un dashboard statique n'a jamais.

Cet article détaille comment monter cet agent en pratique, quelles boucles d'analyse prioriser, et où sont les garde-fous. Si tu débutes complètement avec Claude, commence par le guide complet Claude pour entrepreneurs, sinon tu peux entrer directement dans le vif.

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

Stripe Dashboard répond à la question "quel est mon MRR ?". Un agent répond à la question "pourquoi mon MRR a bougé de 8 % cette semaine, est-ce sain, et que dois-je faire ?". La différence n'est pas cosmétique, elle est structurelle : le dashboard agrège, l'agent raisonne et corrèle.

Trois questions typiques que tu poses le lundi matin et que ton dashboard force à recouper manuellement :

• "Ce pic MRR, c'est une vraie tendance ou un seul gros contrat ?" L'agent liste les nouvelles souscriptions de la semaine, sort les 3 plus grosses en montant, calcule leur part du delta et te dit si le reste de la cohorte suit ou pas.
• "Combien d'échecs de paiement cette semaine sont récupérables et combien sont du churn déguisé ?" L'agent croise les invoices en statut uncollectible avec les tentatives Smart Retries et te donne un chiffre net, pas un total brut.
• "Quels clients vont churner dans les 30 jours ?" L'agent lit les signaux (baisse d'usage si tu exposes la donnée, méthode de paiement expirée, downgrade récent, tickets support) et te sort une short-list hiérarchisée.

Le dashboard te donne des chiffres. L'agent te donne une lecture. C'est le passage du reporting descriptif au reporting explicatif, et c'est ce qui rend le lundi matin utilisable.

Les 3 boucles d'analyse à automatiser en priorité

Ne cherche pas à tout automatiser d'un coup. Trois boucles couvrent la quasi-totalité du besoin d'un dirigeant SaaS ou d'un e-commerce en abonnement.

La boucle revenus te donne la santé macro. La boucle churn te dit d'où vient l'hémorragie (un client à 5 000 € qui part ne se lit pas comme dix clients à 50 €, mais ton dashboard les additionne). La boucle anomalies te réveille avant que Stripe ne suspende ton compte pour chargeback ratio élevé ou que 300 abonnements silencieusement bloqués deviennent 300 churns officiels le mois suivant.

Résiste à l'envie d'ajouter une quatrième boucle avant d'avoir les trois premières qui tournent proprement pendant un mois. La sur-configuration au départ est le principal facteur d'abandon de ce type d'agent.

Architecture technique : Claude + MCP Stripe

Le composant qui rend tout ça possible s'appelle MCP, Model Context Protocol. C'est un standard ouvert créé par Anthropic qui permet à Claude d'appeler des outils externes de façon structurée, sans que tu écrives du code d'intégration à chaque fois. Si le concept est nouveau pour toi, la page dédiée à MCP côté Ottho détaille le protocole.

Concrètement, l'architecture tient en trois briques :

1. Une clé API Stripe restricted en lecture seule. Tu ne donnes à l'agent que les permissions read sur customers, subscriptions, invoices, charges et disputes. Aucune écriture au démarrage, on y reviendra.
2. Un serveur MCP Stripe. Stripe maintient officiellement un serveur MCP qui expose les endpoints de l'API sous forme d'outils que Claude peut appeler (rechercher un client, lister les invoices d'un abonnement, récupérer les charges d'une période).
3. Un client Claude configuré pour utiliser ce serveur MCP. Soit Claude Desktop avec la configuration MCP dans le fichier de préférences, soit une intégration via l'API Anthropic pour un déploiement serveur ou une intégration dans ton stack interne.

Le flux est simple : tu poses une question en langage naturel. Claude interprète, décide quels endpoints Stripe interroger, fait les appels via MCP, reçoit les objets JSON, les croise avec les questions précédentes de la session, et te renvoie une analyse structurée. Tu peux enchaîner : "OK, sors-moi le détail des 5 plus gros comptes de cette cohorte", et l'agent continue avec le contexte déjà chargé.

Setup pas à pas : de la clé API au premier rapport

Voici la séquence minimale pour avoir un agent fonctionnel en une soirée.

1. Créer la clé Stripe restricted. Dans le dashboard Stripe, section Developers, API keys, Create restricted key. Coche uniquement les permissions Read pour Customers, Subscriptions, Invoices, Charges, Disputes, Payment Intents. Nomme la clé "claude-agent-readonly". Copie-la, tu ne la reverras plus.

2. Installer le serveur MCP Stripe. Suis la documentation officielle Stripe pour leur serveur MCP. L'installation typique passe par npm ou une image Docker selon ton environnement.

3. Connecter à Claude. Ajoute le serveur MCP dans la configuration de ton client Claude, en passant la clé restricted en variable d'environnement. Redémarre le client. Tu dois voir apparaître les outils Stripe dans la liste des outils disponibles.

4. Poser le prompt système. C'est l'étape que 90 % des gens bâclent et qui détermine tout. Voici un point de départ :

Tu es l'analyste financier de [NOM_ENTREPRISE], SaaS B2B.
Tu as accès en lecture seule aux données Stripe via MCP.

Règles :
- Chiffre tout ce que tu affirmes, cite les IDs Stripe.
- Distingue toujours revenue churn et logo churn.
- Distingue voluntary churn (annulation active) et involuntary
  churn (échec paiement non récupéré).
- Pour toute variation > 5 %, explique la cause en descendant
  au niveau client si nécessaire.
- Si une donnée manque ou est ambiguë, dis-le, n'extrapole pas.
- Format : réponse structurée avec chiffres clés en tête,
  détail ensuite, actions recommandées à la fin.

Contexte métier :
- Plans : [liste tes plans et prix]
- Cycle de facturation dominant : mensuel / annuel
- Devise principale : EUR

5. Tester avec 3 questions calibrées. "Donne-moi le rapport revenus des 7 derniers jours." Puis "Quels sont les 5 abonnements à plus haut risque de churn ce mois-ci et pourquoi ?". Puis "Y a-t-il des anomalies dans les échecs de paiement des 30 derniers jours ?". Compare les réponses à ce que tu sais déjà. Si l'agent invente ou hallucine un chiffre, remonte-le dans le prompt système pour cadrer.

Prompts qui marchent pour l'analyse récurrente

Une fois l'agent branché, la qualité de sortie dépend de la qualité de tes prompts. Six formulations qui produisent des rapports directement exploitables :

• Rapport hebdo revenus : "Compare le MRR d'aujourd'hui avec celui d'il y a 7 jours. Décompose la variation en : nouveaux abonnements, expansion (upgrades), contraction (downgrades), churn. Donne le top 3 des mouvements en montant absolu dans chaque catégorie."
• Analyse de cohorte churn : "Prends tous les clients acquis en [mois]. Combien sont encore actifs aujourd'hui ? Combien ont churné ? Quel est le revenue churn de la cohorte ? Compare avec la cohorte du mois précédent."
• Détection d'anomalies : "Regarde les échecs de paiement des 30 derniers jours. Identifie tout pattern anormal : concentration sur une méthode de paiement, sur une plage horaire, sur un pays. Sors les 10 abonnements bloqués en past_due avec le plus gros MRR à risque."
• Top clients à risque : "Liste les 10 abonnements actifs avec le MRR le plus élevé qui ont un signal de risque : méthode de paiement qui expire dans les 60 jours, échec de paiement récent récupéré, downgrade dans les 90 derniers jours. Hiérarchise par revenu à risque."
• Comparaison mois vs mois : "Compare [mois en cours] vs [mois précédent] sur : nouveau MRR, expansion MRR, churn MRR, MRR net. Explique la variation nette et cite les 3 mouvements clients qui pèsent le plus."
• Contrôle chargebacks : "Combien de disputes ouvertes ce mois-ci ? Quel ratio par rapport au volume de transactions ? Y a-t-il un pattern (même produit, même segment client, même pays) ?"

Sauvegarde ces prompts. Le vrai gain n'est pas de les taper à chaque fois, c'est de les enchaîner : l'agent garde le contexte de la session, donc après le rapport hebdo tu peux dire "OK, prends le client X que tu viens de mentionner, sors-moi son historique complet".

Limites et garde-fous

Cet agent n'est pas magique et il y a trois pièges à connaître avant de le mettre entre les mains de quelqu'un d'autre.

Il n'est pas bon en prédiction long terme. Demande-lui "quel sera mon MRR dans 6 mois" et il fera une extrapolation linéaire naïve. Les prédictions de revenus futurs demandent des modèles dédiés, pas un LLM avec accès à Stripe. Utilise-le pour comprendre le passé et le présent, pas pour deviner le futur.

Garde-le en lecture seule au moins un mois. La tentation de lui donner les permissions d'écriture Stripe arrive vite (appliquer un coupon, relancer un paiement, annuler une souscription). Résiste. Le premier mois, tu dois vérifier manuellement les chiffres critiques que l'agent te sort, sinon tu construis une confiance non validée qui te coûtera cher le jour où il se trompera sur un chiffre stratégique.

Surveille les coûts API. Une analyse de cohorte sur 12 mois peut charger des milliers d'objets Stripe dans le contexte, ce qui pèse en tokens. Sur Claude Sonnet 5, le tarif reste raisonnable (à partir d'environ 2 $ le million de tokens en entrée), mais un agent qu'on interroge 30 fois par jour peut chiffrer. Utilise le mode Concise si les réponses n'ont pas besoin d'être bavardes.

Corrélation avec la donnée produit. L'agent ne voit que Stripe. Un client qui n'utilise plus ton produit depuis 3 semaines mais qui paie encore, l'agent ne le détectera pas comme risque de churn. Pour ça, il faut brancher un second serveur MCP sur ta base produit (Postgres, Mixpanel, PostHog). C'est l'étape suivante, pas la première.

Passer de l'agent d'analyse à l'agent d'action

Une fois que l'agent lecture seule tourne depuis un mois et que tu lui fais confiance, la suite logique est de passer à un agent qui agit. Envoyer automatiquement l'email de relance sur échec de paiement au bon moment. Appliquer un coupon de rétention aux clients détectés à risque. Alerter Slack quand le ratio de chargeback dépasse un seuil. Créer un ticket dans ton outil support quand un compte à plus de 5 000 € de MRR passe en past_due.

Cette transition, du reporting automatisé à l'action automatisée, c'est le cœur du travail sur les agents autonomes. Pour aller plus loin sur les patterns d'architecture d'agents avec Claude, et si tu veux structurer une compétence complète pour piloter tes agents autonomes jusqu'en production, c'est le prochain palier logique.