- En reliant des données de comptes financiers et des connecteurs MCP, il devient possible d’automatiser, avec de simples prompts, des vérifications financières répétitives à partir des soldes, transactions, investissements et prêts
- L’ancienne approche par cron job Codex CLI cassait souvent à cause des connexions web, des problèmes de rendu navigateur, du 2FA et des limites liées aux passkeys, ce qui rendait difficile un suivi fiable compte par compte
- La nouvelle automatisation d’e-mail quotidien combine une planification matinale, un custom connector et l’outil
email_me()pour envoyer un récapitulatif de tous les comptes et du patrimoine net, avec un contenu modifiable simplement en ajustant le prompt - L’automatisation de surveillance des transactions détecte les opérations anormales et les sorties importantes en les comparant aux habitudes récentes, puis n’envoie un e-mail que lorsque les conditions sont remplies afin de réduire les alertes inutiles
- Cette approche permet de tester et d’étendre rapidement une automatisation opérationnelle personnalisée à très faible coût, tout en rendant les contrôles financiers connectés à des données en temps réel accessibles même aux non-développeurs
Méthode de mise en place de l’automatisation
- Driggsby se connecte aux comptes financiers via Plaid, puis expose, via MCP, des outils donnant accès aux soldes, à l’historique des transactions, aux informations d’investissement et aux prêts
- Au départ, l’usage était surtout conversationnel, avec des questions posées à Claude au besoin, mais des schémas répétitifs sont apparus, comme la vérification du patrimoine net, la revue des soldes ou la surveillance des transactions
- Les Claude Code routines facilitent l’automatisation par simple prompt de ce type de tâches répétitives
- Il suffit de relier un prompt et un connecteur MCP, sans écrire de code de boucle d’agent ni préparer d’environnement de déploiement séparé
- Dès lors que les données et les outils peuvent être proprement reliés via un connecteur MCP, l’automatisation devient possible
Limites de l’ancienne méthode et changement d’approche
- Auparavant, l’auteur utilisait un cron job Codex CLI non conversationnel pour se connecter à des comptes bancaires, cartes de crédit, comptes-titres et comptes retraite, récupérer les soldes et transactions récentes, puis envoyer un e-mail quotidien de synthèse financière
- Chrome DevTools MCP servait à se connecter à chaque site web et à en extraire les informations
- La tâche paraissait simple — envoyer chaque jour un e-mail de synthèse financière au couple — mais elle cassait souvent en pratique
- Les échecs dès le lendemain étaient fréquents, et des problèmes de rendu navigateur ou des demandes 2FA inattendues interrompaient régulièrement l’exécution au niveau d’un compte
- Il arrivait aussi que GPT change complètement le format de l’e-mail, ou qu’il se perde en cours d’exécution et ne récupère les informations que d’un seul compte
- Parmi les comptes à ajouter, certains n’autorisaient qu’une connexion par passkey
- À force de ces pannes répétées, il fallait intervenir manuellement à chaque fois que l’e-mail attendu n’arrivait pas, et c’est pour rendre ce processus moins stressant que Driggsby a été conçu
Automatisation de l’e-mail quotidien
- La première chose reconstruite a été l’e-mail quotidien, avec pour objectif de recevoir chaque matin un résumé proprement formaté de tous les comptes et du patrimoine net
- Ces informations se trouvaient à l’origine dans une ancienne feuille de calcul perdue quelque part dans Google Drive
- La mise à jour ne prenait qu’environ 15 minutes, mais cette petite friction suffisait à la repousser souvent, au point qu’elle n’était actualisée qu’une fois tous les six mois au mieux
- Avec routines, la configuration initiale a été très simple : un prompt, une planification matinale et la connexion du custom connector Driggsby suffisaient
- Au départ, il n’y avait toutefois aucun moyen d’envoyer l’e-mail, et en ajoutant le connecteur Gmail, seul un brouillon bien présenté était généré
- Le connecteur Gmail ne pouvait pas effectuer l’envoi réel et se limitait à créer un draft
- Pour résoudre ce point, l’auteur a ajouté à Driggsby un outil MCP
email_me(), qui s’est révélé assez pratique- L’envoi a été limité à l’adresse e-mail vérifiée du propriétaire du compte, avec blocage des liens et des images pour rester à un niveau de sécurité jugé acceptable
- Le corps du message a été imposé en Markdown, puis enrichi de CSS lors du rendu en e-mail afin de réduire les incohérences de format d’une exécution à l’autre
- Quelques petits bugs ont pu être corrigés assez facilement grâce à l’inspectabilité de routines
- L’interface ressemble à une session Claude Code classique dans Claude Desktop ou dans l’application web, ce qui facilite l’inspection directe de l’état pendant l’exécution
- Après les tests, l’e-mail quotidien est effectivement arrivé, et il est ensuite devenu possible de modifier son contenu en ajustant uniquement le prompt dans l’interface routines, sans changer le code
- Comme le couple ne consulte pas les mêmes informations, il est aussi devenu possible de configurer des e-mails quotidiens différents pour chacun via des prompts distincts
Surveillance des opérations anormales et des dépenses
- Une fois l’e-mail quotidien en place, l’auteur a commencé à ajouter d’autres automatisations en profitant de la possibilité de lancer des agents sans charge d’infrastructure supplémentaire
- La première a été une surveillance des transactions anormales à partir des données de transaction, avec une routine hebdomadaire qui récupère un an d’historique des cartes Amex, tout en concentrant l’analyse sur les sept derniers jours
- Si les transactions des sept derniers jours paraissent inhabituelles par rapport aux habitudes passées — double facturation, changement d’abonnement, nom ou description de commerçant inconnu — un e-mail est envoyé
- Si ces transactions récentes semblent normales et cohérentes, aucune alerte n’est envoyée
- Ce type de prompt simple peut produire des faux positifs, mais le coût d’ajustement au fil du temps comme le coût de revue restent faibles
- Une autre routine a ensuite été créée pour surveiller, sur un compte courant, les sorties importantes et inattendues
- Elle n’examine que les transactions du dernier jour, puis cherche, par rapport aux habitudes des 12 derniers mois, les opérations supérieures à 500 $ correspondant à des sorties importantes ou inhabituelles
- Comme l’automatisation tourne tous les jours, le périmètre de revue a été volontairement limité à la seule journée la plus récente
- Si des éléments correspondent aux critères, un e-mail intitulé "Checking account outflow alert" est envoyé ; sinon, aucune notification n’est émise
- Par la suite, cette méthode a été étendue au suivi des investissements, à l’analyse des abonnements et à la surveillance de plusieurs catégories de dépenses
- Comme la configuration avec routines est très simple, le besoin de regrouper plusieurs conditions ou d’affiner davantage les prompts devient plus important avec le temps
Pourquoi c’est important
- Le principal atout de routines est qu’on peut essayer presque sans effort
- Dès qu’un prompt vient à l’esprit, l’automatisation peut être lancée immédiatement
- Il est particulièrement notable que même des non-développeurs puissent piloter eux-mêmes des automatisations cloud reliées à des données en temps réel
- Son épouse, qui est CPA, exploite elle aussi les données en temps réel de Driggsby pour exécuter ses propres automatisations
- Cette manière de travailler permet de créer rapidement, avec de simples prompts et connecteurs, une automatisation opérationnelle personnalisée
1 commentaires
Avis sur Hacker News
J’ai récemment monté quelque chose comme ça moi-même. J’utilise https://tiller.com/ pour synchroniser les transactions de compte courant/carte de crédit vers Google Sheets, puis GitHub Actions pour répliquer cette feuille dans une base Supabase gratuite
J’ai permis à Claude/Codex d’accéder à l’historique des transactions et aux soldes via Supabase MCP ou
psqlavec des requêtes en anglais, et leur capacité à repérer des habitudes d’abonnement ou des schémas anormaux m’a plutôt impressionné. C’était aussi assez bon pour les prévisions de trésorerie, que les outils en ligne gèrent souvent mal, par exemple pour demander combien on peut transférer vers l’épargne en fonction des habitudes de dépenses mensuelles et du cash disponibleCôté classification automatique, Claude s’en est aussi très bien sorti avec un DSL personnalisé. Je lui ai fait créer un ensemble de règles sous forme de tableaux markdown pour normaliser les bénéficiaires/catégories, et ces règles tournent aussi dans GitHub Actions
Est-ce qu’ils les tirent via quelque chose comme Plaid, ou faut-il toujours leur donner ses identifiants de banque en ligne, et comment la 2FA est-elle gérée ?
Je me demande aussi si, pour les établissements sans API officielle, ils dépendent encore du scraping d’écran, et ce qui se passe s’il y a un bug entraînant un clic involontaire, un consentement accidentel, voire un mauvais virement. On parle de lecture seule, mais j’ai rarement vu des banques grand public proposer de vrais comptes auxiliaires strictement en lecture seule
Je me demande également s’il existe une assurance ou une garantie permettant d’être indemnisé en cas de gros préjudice financier, et les implications en matière de vie privée du fait d’exposer l’ensemble de ses données bancaires à deux prestataires m’inquiètent aussi. J’ai entendu parler d’actions collectives liées à des données vendues ou partagées de manière inappropriée, mais je ne sais pas ce qui s’est réellement passé
Il y a aussi ces clauses dans les conditions bancaires où l’on accepte de ne pas partager son mot de passe avec des tiers. Confier mes finances à un service web/cloud me met mal à l’aise, et je préférerais un logiciel client tournant en local et communiquant avec les API bancaires. Je me demande aussi si ça existe au Canada
On parle d’open banking à venir, mais il n’est pas clair si des logiciels développés par des particuliers pourront y accéder directement. Si je pouvais vraiment faire confiance à une API bancaire, et qu’il y avait même une politique imposant de minimiser la conservation interne après téléchargement, alors oui, j’aimerais l’utiliser
Je l’utilise depuis le rachat de Mint par Intuit, avec une configuration similaire. Sauf que moi, j’ai branché l’accès aux sheets avec un modèle qwen local et une clé API créée via OAuth, donc l’approche Claude Routine aurait sans doute été bien plus simple
J’aimerais voir la configuration complète, en particulier les prompts utilisés
Peut-être que c’est parce que ma valeur nette est faible, mais honnêtement je ne vois pas bien en quoi c’est utile
Je n’ai pas envie qu’un LLM m’envoie un email tous les jours, et si j’ai besoin de regarder mes investissements plus souvent qu’une fois par trimestre, j’aurais sans doute intérêt à adopter une stratégie plus sûre. Les outils de budgétisation m’intéressent un peu, mais j’aimerais que ce soit entièrement déterministe
Ma planification financière est globalement assez tranquille, donc je pense qu’au lieu de passer plus de temps à optimiser mes dépenses, je ferais mieux de chercher un poste mieux payé
Pour tout ce qui touche aux chiffres, je pense que ça devrait de toute façon être totalement déterministe
J’ai montré ma base SQLite au LLM et lui ai demandé de dire ce qu’il voyait dans les transactions des cinq dernières années ; ce qu’il a relevé et rappelé était impressionnant. Mais je ne sais pas s’il y avait une valeur concrète qui me ferait réellement changer quelque chose
Je vais peut-être essayer de lui faire faire une revue mensuelle pendant un temps, mais rien qu’en mettant à jour mon budget, je connais déjà en gros ma situation financière, donc je ne sais pas à quel point cela m’aidera
C’est ce que j’utilise pour suivre mes cartes de crédit et mon compte courant, et si tu veux tu peux y connecter MCP pour analyser en un seul endroit les données qui s’y trouvent
Je vis au Canada et j’utilise https://lunchmoney.app/ pour le suivi, avec une intégration Plaid
Il y a une API, donc j’ai fait générer un CLI par un LLM, ce qui permet à l’agent de récupérer à peu près les données qu’il veut
Une autre tâche que je lui ai donnée a été d’accumuler des règles de tagging, et ça tourne une fois par jour via cron. De temps en temps, je lui fais aussi parcourir les règles pour qu’il crée de nouvelles règles pour les transactions non classées
Je trouve assez bon le schéma consistant à faire en sorte que le LLM mémorialise le travail sous forme de moteur de règles ou de code. Une fois qu’on a juste un CLI interrogeable, on peut demander presque n’importe quoi à l’agent
Pour celles et ceux que ça intéresse, voici une vue d’ensemble de notre architecture d’infrastructure/sécurité
Le backend et le CLI sont en Rust avec linting strict, l’application web tourne sur Axum et se connecte à Postgres via sqlx
Les fonctions financières sont en lecture seule. Il n’y a pas d’outil de virement, de paiement de facture ou de transfert, et il est impossible de déplacer de l’argent depuis la surface IA
Chez Plaid, nous ne demandons que les transactions, les investissements et les dettes ; nous ne demandons ni auth/transfer/payment initiation, donc nous ne recevons ni numéros de compte complets ni numéros de routage, seulement le masque de base des quatre derniers chiffres
Les identifiants bancaires ne passent pas par nous : ils vont à Plaid Link, et nous ne conservons que des access tokens par établissement
Les access tokens Plaid sont stockés dans une base séparée derrière un service Cloud Run de custody dédié. Ils sont chiffrés au stockage avec Cloud KMS, et le broker appelle les endpoints KMS d’encrypt/decrypt ; le matériel racine des clés ne sort jamais du périmètre HSM de Google. Seul le compte de service du broker a les droits de chiffrement/déchiffrement, et l’application web n’a pas les droits de lecture sur cette base
À chaque appel de chiffrement/déchiffrement, nous passons l’ID d’item Plaid comme AAD, afin qu’un texte chiffré d’un item ne puisse pas être remplacé puis déchiffré avec le token d’un autre item
Chaque service Cloud Run s’exécute avec sa propre identité cloud et son propre rôle DB, et les appels internes entre services sont aussi authentifiés avec des identity tokens à courte durée de vie
La base de production n’a pas d’IP publique, et les secrets sont stockés dans un gestionnaire de secrets, pas dans le code source ni dans les images de conteneur
Le connecteur IA utilise OAuth 2.1 + PKCE, avec des scopes par utilisateur et une révocation possible depuis l’interface. Nous journalisons chaque appel d’outil avec le nom de l’outil, les arguments nettoyés, le client appelant et la raison fournie par l’agent, afin que les utilisateurs puissent voir ce que le LLM a demandé en leur nom
La surface IA n’expose ni fetch-URL, ni shell, ni outils d’E/S génériques ; elle ne renvoie que des données financières structurées. Le réseau, l’IAM, les droits DB et tout le reste sont gérés avec Terraform, et les changements d’infrastructure ne passent que par cette voie
L’accès à l’infrastructure est contrôlé par 2FA et clés de sécurité
On sent que vous comprenez le lectorat de ce site, et le soin apporté à la sécurité à chaque couche augmente aussi la confiance dans l’outil dans son ensemble
J’avais moi aussi envisagé de construire quelque chose de similaire ; pour le MVP initial, j’en étais au téléchargement manuel de PDF de relevés puis à l’utilisation de Claude pour configurer un ledger en texte brut, avec l’idée d’ajouter Plaid plus tard
Je suis surtout curieux de savoir comment les gens utilisent Plaid. Faut-il déjà un certain volume d’utilisateurs pour démarrer, ou peut-on créer un compte Plaid pour un usage personnel, simplement pour connecter ses comptes perso/pro à une API propre ?
Il faut être prudent avec Routine
Il y a une petite note presque invisible indiquant qu’en mode routine, les outils MCP sont toujours autorisés, y compris avec des permissions d’écriture. Donc techniquement, l’agent pourrait modifier des ressources à sa guise
Ça ressemble à une solution en quête de problème. https://tiller.com/ suffit déjà largement, on peut faire tous les calculs voulus dans une feuille de calcul, et bonus : il n’y a pas d’hallucinations
Je ne vois pas très bien pourquoi je voudrais en plus une longue synthèse de LLM à lire. Il suffit de classer ses dépenses de temps en temps pour que les anomalies sautent vite aux yeux, et avec Tiller c’est facile
Il va vraiment y avoir beaucoup de produits différents dans cet espace, et le nôtre n’est qu’une approche parmi d’autres. Personnellement, je vois plutôt d’un bon œil la multiplication de ce genre d’essais
Le plus important, c’est que les LLM peuvent ingérer et combiner facilement de nombreuses sources de données
Chez Era Finance, nous construisons une solution qui vise exactement cela. Era Context est un MCP qui connecte n’importe quel agent compatible aux finances personnelles, et c’est à voir sur https://era.app
Pour l’instant, nous nous concentrons sur les outils de lecture, mais nous préparons aussi des outils d’écriture pour les virements d’argent ou le remboursement de dettes
Si vous avez des fonctionnalités souhaitées, envoyez un mail à alex sur ce domaine. Pour situer, je suis Alex, le CEO, c’est presque ma première fois sur HN, mais j’étais auparavant responsable de la présence web de stripe.com, et avant cela chez Square/CashApp
J’imagine que la bataille est peut-être déjà perdue, mais je ne comprends toujours pas pourquoi on voudrait confier l’historique complet de ses transactions financières à un LLM
Je ne pense pas que les fournisseurs de LLM aient des protections plus solides que le secteur financier sur l’usage de ce type de données. Et le secteur financier lui-même est déjà une industrie brutale de collecte, d’extraction et de revente de nos données
Comme je m’intéresse aux habitudes de dépenses et aux investissements, même des prompts très basiques m’ont parfois permis de découvrir des choses que j’aurais autrement manquées
Bien sûr, rendre tout cela sûr est extrêmement difficile, et c’est pourquoi j’y réfléchis depuis très longtemps
Du coup, je ne vois pas bien où est exactement le problème
Ma banque principale, Monzo au Royaume-Uni, fournit une API complète et des webhooks de déclenchement d’événements
Grâce à ça, j’ai pu créer un bot WhatsApp qui demande d’expliquer les transactions anormales, et le LLM ne sert qu’au raisonnement. J’ai aussi mis en place une automatisation qui balaie chaque jour le solde restant vers un compte d’épargne juste avant minuit afin de maximiser les intérêts quotidiens
Je ne garde qu’un petit montant sur le compte courant, et si je dépense de l’argent en journée, je le réalimente depuis l’épargne pour maintenir ce faible solde. Si j’ai besoin d’une dépense plus importante, alors je transfère manuellement
Quand j’ai essayé d’utiliser Claude pour analyser des transactions passées, il y avait sans arrêt des hallucinations : il inventait des prélèvements inexistants, ajoutait de nouvelles lignes et faisait du double comptage
Pour les finances, ce n’est pas suffisant que Claude ait raison à 95 %. Il faut rester sur ses gardes et revoir les résultats en permanence, donc dans mon cas cela perd pratiquement toute valeur
Moi aussi, j’ai trouvé que Claude hallucinait assez facilement, surtout sur des jeux de données incomplets ou limités