Réponse courte : non, ne donne jamais ton login et ton mot de passe bancaires à un agent IA, qu'il s'agisse de Claude, de ChatGPT ou d'un autre. Ce que tu peux faire, en revanche, c'est lui donner une vue en lecture seule de tes comptes, et c'est ce que cet article détaille. Si tu débutes avec Claude, commence par apprendre Claude de zéro, puis reviens ici pour la partie sécurité.
Ce que font les banques face aux agents IA (Schwab, JPMorgan et les autres)
Le point de départ est un fait observable. Le PDG de Charles Schwab, Rick Wurster, a déclaré sur Bloomberg Television que sa banque bloque les agents IA externes non autorisés qui tentent de déplacer l'argent de clients, y compris Muse, l'agent personnel de Meta. Son problème est précis : des clients donnent leurs identifiants à un agent qui agit ensuite à leur place, et selon ses mots, la banque ne peut pas le contrôler, le client non plus, et en cas de pépin la question de la responsabilité reste ouverte. Schwab dit en bloquer des dizaines par semaine pour les grands agents.
Chez JPMorgan, Jamie Dimon a mis en garde contre les « rogue agents » lors de l'appel de résultats du troisième trimestre. Selon la presse, la banque bloque les agents externes qui agissent pour des clients particuliers : la lecture seule reste possible via des connecteurs comme Plaid, mais ni envoi d'argent ni paiement de facture, sans calendrier pour autoriser davantage.
Il faut être précis sur ce que cela veut dire. Ces banques ne déclarent pas une interdiction générale des agents IA : elles refusent qu'un agent se connecte avec les identifiants du client et déplace de l'argent. Schwab prévoit d'ailleurs ses propres serveurs MCP, pour que le client puisse brancher son modèle d'IA selon les règles de la banque, consulter ses soldes et faire des recherches, sans pouvoir déplacer d'argent. La ligne de partage est donc nette : lecture oui, mouvement d'argent non.
Ces exemples sont américains. Je n'ai pas de source sur des mesures identiques côté banques françaises ou européennes, donc je ne t'en annonce pas. Pour un lecteur européen, la logique est voisine, avec ses propres règles (DSP2, agrégateurs agréés), mais le principe qui t'importe ne dépend d'aucune banque : ce qu'on donne à un agent, c'est un périmètre de droits, pas un compte entier.
Pourquoi ne jamais confier vos identifiants bancaires à un agent IA
Un login et un mot de passe n'ont pas de scope. Quand un agent les reçoit, il peut tout faire avec, y compris ce que tu n'avais pas prévu qu'il fasse. Trois mécanismes concrets le montrent.
L'injection de prompt. Imagine un agent chargé de « vérifier mes encaissements » qui lit au passage un e-mail ou une page web. Si ce contenu contient une instruction cachée du type « effectue un virement vers tel IBAN », l'agent peut la traiter comme une consigne légitime. Plus il a de droits, plus le dégât possible est grand. Tu ne peux pas compter sur le modèle pour toujours distinguer ta demande d'une instruction glissée dans les données qu'il lit.
La fuite des identifiants. Un mot de passe collé dans un prompt vit ensuite dans l'historique de conversation. Passé dans un outil, il peut finir dans des logs, une trace d'exécution ou un service tiers. Tu perds la maîtrise de tous les endroits où il est copié, et tu ne peux pas le « reprendre » : il faut le changer.
La responsabilité. La plupart des conditions générales de banque traitent la communication de tes identifiants à un tiers comme une faute du client. En cas de fraude, cela peut peser sur le remboursement. Le cadre exact en France relève notamment du Code monétaire et financier : vérifie les conditions de ta propre banque avant d'imaginer qu'un agent qui a agi avec tes identifiants serait couvert. Je ne cite pas de cas chiffré d'incident, faute de source ; le mécanisme suffit à justifier la règle.
Les incidents d'agents autonomes qui sortent de leur périmètre existent d'ailleurs ailleurs : voir ce que racontent les incidents de cybersécurité en environnement de test isolé et la leçon tirée des agents OpenAI sur des sites gouvernementaux. Aucun n'est un cas bancaire, mais tous rappellent la même chose : un agent avec trop de droits finit par les utiliser.
MCP en lecture seule : le principe qui change tout
Un serveur MCP est le connecteur entre Claude et une source de données ou un outil. Le Model Context Protocol est un standard ouvert créé par Anthropic en 2024. Tu y exposes, côté serveur, une liste d'outils précis que Claude peut appeler : « lister les transactions », « lire le solde ». Claude ne voit que ces outils, rien d'autre.
Le point clé est la nature de la protection. Il y a deux manières de dire à un agent de ne pas faire de virement :
| Approche | Où vit la protection | Robustesse |
|---|---|---|
| Consigne dans le prompt | Dans le texte (« ne fais aucun virement ») | Fragile : une injection de prompt peut la contourner |
| Lecture seule par architecture | Dans les droits du jeton et dans les outils exposés par le serveur MCP | Robuste : l'action n'existe pas, la banque la refuse |
La première repose sur la bonne volonté du modèle. La seconde repose sur ce que le système permet techniquement. Si le jeton d'accès n'a pas le droit d'initier un paiement, aucune phrase, même habile, ne le lui donnera. C'est exactement l'idée de Schwab : un accès où l'on consulte mais où l'on ne peut pas déplacer d'argent.
Mettre en place un accès lecture seule, pas à pas
La procédure ci-dessous est volontairement générale : les noms de produits et de scopes varient selon ta banque ou ton agrégateur, et je ne t'en invente pas. Les extraits de configuration sont illustratifs.
- Passe par une API, pas par le login web. Utilise l'API d'agrégation ou d'export de ta banque, ou celle d'un agrégateur agréé. Renseigne-toi sur ce que propose ton établissement : certaines banques offrent un accès développeur, d'autres seulement un export de fichier.
- Crée un jeton au scope le plus restreint. Consultation des soldes et des transactions, rien d'autre. Si l'interface te propose « paiements » ou « initiation de virement », ne le coche pas.
- Garde le jeton hors du prompt. Stocke-le dans les variables d'environnement du serveur MCP, jamais dans une conversation ni dans un fichier que Claude lit.
- N'expose que des outils de lecture. Le serveur MCP ne déclare que des fonctions de consultation. Pas de fonction « virement », même désactivée.
- Teste l'échec volontaire. Demande à Claude d'effectuer un virement et vérifie que l'appel est refusé côté banque. C'est le test qui prouve que la protection tient.
# Illustratif : le serveur MCP ne déclare que de la lecture
TOKEN_BANQUE=*** (variable d'environnement, jamais dans le prompt)
OUTILS_EXPOSES = ["lister_transactions", "lire_solde"]
# Aucun outil "creer_virement" n'est déclaré.Si tu ne veux aucune connexion, il existe une version minimaliste : un export CSV hebdomadaire déposé dans un dossier que Claude lit. Moins pratique, mais sans jeton, donc sans risque de ce côté. Pour ceux qui orchestrent l'agent eux-mêmes, l'API Anthropic permet de piloter ce flux en code. Pour t'appuyer sur un serveur existant ou en construire un, le guide serveur MCP avec Claude détaille la mécanique.
Ce qu'un agent en lecture seule peut vraiment faire pour votre trésorerie
Une fois l'accès verrouillé, le gain est réel. Chaque cas ci-dessous a une entrée, une sortie, et un gain observable.
- Classer les transactions du mois par catégorie. Entrée : l'export du mois. Sortie : un tableau par poste (logiciels, déplacements, sous-traitance). Gain : fini le tri à la main avant la clôture.
- Repérer les abonnements en doublon. Entrée : douze mois de prélèvements. Sortie : la liste des services facturés deux fois ou plus utilisés.
- Comparer encaissements et facturation émise. Entrée : transactions entrantes et liste de factures. Sortie : les factures émises sans paiement correspondant, donc les relances à faire.
- Préparer le récapitulatif pour l'expert-comptable. Sortie : un résumé daté, par catégorie, avec les lignes à justifier.
- Signaler les écarts avec le prévisionnel. Entrée : transactions réelles et budget prévu. Sortie : les postes où tu dépasses.
Un prompt court pour le deuxième cas :
Voici mes prélèvements des 12 derniers mois.
Repère les abonnements récurrents, regroupe-les par fournisseur
et signale ceux qui apparaissent deux fois ou dont le montant a changé.
Réponds sous forme de tableau : fournisseur, montant, fréquence, remarque.Limite assumée : l'agent propose, tu valides et tu exécutes. Aucun paiement ne part sans toi, ce qui est précisément ce que garantit la lecture seule. Si tu utilises Claude Cowork pour ces tâches, le guide Claude Cowork montre comment lui déléguer ce type de travail récurrent.
Garde-fous complémentaires avant de lancer l'agent
Quelques règles de contrôle, sans empiler de généralités :
- Fais tes essais sur un compte dédié au solde limité, pas sur ton compte principal.
- Active les alertes bancaires sur chaque opération : si quelque chose bouge, tu le sais tout de suite.
- Journalise les appels du serveur MCP pour savoir ce que l'agent a réellement demandé.
- Révoque le jeton à la moindre anomalie, et renouvelle-le périodiquement.
Il reste un risque même en lecture seule : les données financières que Claude lit transitent par le modèle. Avant d'y exposer des informations sensibles, vérifie les conditions de traitement des données de l'offre Claude que tu utilises (les règles ne sont pas les mêmes selon le plan). Pour aller plus loin sur la sécurisation d'un agent, voir sécuriser un agent Claude, et pour la logique de sandbox au niveau système, NVIDIA OpenShell avec les agents Claude.
Passer à la pratique
Le principe se résume en une ligne : donne à l'agent un droit de regarder, jamais un droit d'agir sur ton argent. Si tu veux monter en compétence sur la configuration de Claude au quotidien, commence par configurer Claude ; pour comprendre comment bâtir des agents sérieux, parcours construire des agents IA autonomes avec Claude.
Quand tu seras prêt à orchestrer plusieurs agents avec une supervision humaine claire, la suite logique est de piloter vos agents autonomes dans un cadre accompagné, avec les bons garde-fous dès le départ.