Un agent d'intelligence artificielle peut déjà agir à votre place dans plusieurs applications : préparer un achat, gérer un agenda ou remplir un formulaire. Mais dès qu'il faut lui transmettre un identifiant bancaire et un mot de passe, la question change de nature. Là , vous ne déléguez pas seulement une tâche : vous donnez à un logiciel un accès à des informations financières sensibles. Et, trop souvent, on sait mal ce qu'il lit exactement et ce qu'il peut déclencher.
La mise en garde de Bank of America, relayée par ZDNET, s'inscrit dans un mouvement plus large : certains établissements cherchent à limiter l'accès de certains agents tiers. En France aussi, le sujet concerne les particuliers comme les entreprises. L'enjeu n'est pas de décider si « toute IA » serait dangereuse, mais de vérifier si les permissions accordées sont vraiment proportionnées - et surtout révocables. Voici comment comprendre les risques, distinguer les niveaux d'accès et poser quelques règles simples avant de connecter un agent à vos comptes.
Pourquoi les banques s'inquiètent-elles des agents IA ?
La nuance entre un assistant conversationnel et un agent n'est pas qu'un détail. Un assistant répond à une demande. Un agent, lui, peut enchaîner des actions dans des services connectés. Selon les droits accordés, il peut naviguer dans une application, lire des informations ou exécuter une tâche. Et plus il peut agir, plus il faut savoir exactement ce qu'il a le droit de faire - et comment on coupe l'accès.
Dans le cas bancaire, les conséquences d'une erreur se voient vite. Une mauvaise interprétation peut mener à une opération, à un changement de paramètre ou à une exposition de données. Même si l'agent n'a pas été conçu « pour décider » à votre place, l'accès à l'espace bancaire peut lui donner de la visibilité : soldes, habitudes de dépense, informations personnelles.
ZDNET indique que Bank of America a prévenu ses clients de ne pas partager leurs identifiants avec des agents IA. L'article mentionne aussi des restrictions ou des blocages d'accès chez plusieurs banques américaines, dont JPMorgan Chase. Ce n'est pas la preuve que toutes les banques appliquent les mêmes règles, ni que tous les agents sont bloqués partout. Mais c'est un signal : les établissements évaluent bel et bien le risque d'un accès automatisé à leurs systèmes.
Le problème est aussi pratique. Pour une banque, traiter un agent tiers « comme un client humain » est difficile si elle ne sait pas qui est à l'origine de chaque action, si le consentement a été donné pour cette action précise, ou si l'agent a dérivé de la demande initiale. Et en cas de transaction contestée, il faut pouvoir attribuer la responsabilité : utilisateur, fournisseur de l'agent ou un tiers.
L'autonomie rend la frontière de confiance plus floue
Lire une page et agir sur un compte, ce n'est pas le même niveau de risque. L'agent peut en plus dépendre de plusieurs briques : le modèle, l'application qui l'encadre, les connecteurs utilisés, et les services tiers auxquels il transmet des informations. Il suffit qu'un maillon soit mal configuré (ou défaillant) pour que l'accès devienne plus large que ce que l'utilisateur pensait avoir autorisé.
Les banques ne cherchent donc pas seulement à « empêcher l'IA ». Elles veulent encadrer des accès automatisés dont la portée, la traçabilité et la responsabilité sont parfois difficiles à établir. Autrement dit : c'est autant une question de gouvernance des accès que de sécurité.
Quels risques entraîne le partage d'identifiants bancaires ?
Un identifiant et un mot de passe, ce n'est pas juste une clé de connexion. C'est souvent une porte d'entrée vers un espace où il y a des soldes, des relevés, des bénéficiaires et des données personnelles. Selon les protections mises en place par la banque, ces identifiants peuvent aussi servir à initier des actions ou préparer une opération - ensuite validée par une étape supplémentaire.
Le premier risque, c'est la perte de contrôle sur les données. Pour fonctionner, un agent peut traiter ce qu'il voit. Les informations peuvent transiter par le service de l'agent, être conservées par son fournisseur sur une durée définie, ou être accessibles à d'autres outils connectés. Et surtout : ne partez pas du principe qu'une information « restera chez vous » une fois saisie.
Le deuxième risque, c'est l'action non souhaitée. Un agent peut mal comprendre une consigne, confondre deux opérations, ou agir à partir d'une information trompeuse. Et ce n'est pas forcément un scénario « malveillant ». Une automatisation mal cadrée suffit : l'agent peut exécuter correctement... mais la mauvaise tâche.
Le troisième risque, c'est la réutilisation ou la compromission des identifiants. Une fois transmis à un service, le mot de passe n'est plus sous votre contrôle exclusif. En cas de fuite, d'accès indu ou de stockage insuffisamment protégé, il peut être exploité. Et si le même mot de passe est réutilisé ailleurs, les dégâts s'additionnent.
Enfin, partager ces identifiants complique souvent la gestion d'un incident. Si vous remarquez une opération anormale, vous aurez du mal à savoir qui a accédé au compte, quelle instruction a été donnée, et quelles données ont été conservées. Résultat : la réaction peut être plus lente, et la révocation des accès plus compliquée.
Une politique de confidentialité ne remplace pas une vraie limite technique
Les conditions d'utilisation et les politiques de confidentialité expliquent comment un fournisseur dit traiter les données. C'est utile, mais ça ne remplace pas une architecture qui limite réellement les permissions. Sur un compte bancaire, la bonne question n'est pas uniquement « que promet le fournisseur ? ». C'est aussi : quelles actions le produit peut-il faire, et comment je peux couper ça.
Certains agents demandent un accès assez large pour proposer plus de fonctions. Ils peuvent avoir accès, selon les paramètres et les permissions, à des messages, des contacts, des fichiers ou des données financières. Et un consentement « global » lors de l'installation ne devrait pas vouloir dire autorisation illimitée pour toutes les opérations futures.
Tous les accès bancaires par IA présentent-ils le même risque ?
Non. Il faut distinguer au moins trois cas, car les données consultées et les capacités de l'agent ne sont pas les mêmes.
- Vous copiez une information dans une conversation. C'est le plus simple à comprendre, mais la donnée quitte quand même son contexte bancaire. Il faut savoir si elle est conservée et si elle peut être utilisée par le fournisseur.
- L'agent consulte un compte via une connexion ou un connecteur. Selon l'intégration, l'accès peut être limité ou plus large. Là encore, la portée des permissions, leur durée et leur révocation font toute la différence.
- L'agent agit dans une session bancaire à votre place. Par exemple, un outil automatise la navigation et manipule l'interface. Si vous fournissez les identifiants, il devient difficile de distinguer ses actions des vôtres et de limiter précisément ce qu'il peut faire.
En Europe, certains services d'information ou d'initiation de paiement fonctionnent dans un cadre réglementé, notamment autour de la directive sur les services de paiement et du consentement de l'utilisateur. Ce cadre ne doit pas être confondu avec l'idée de donner un mot de passe à un agent généraliste. En théorie, une intégration bancaire conçue pour fournir des permissions ciblées permet davantage de contrôle qu'un partage d'identifiants. Mais le cadre réglementaire ne garantit pas, à lui seul, que chaque produit soit sûr ou adapté à votre usage.
Le bon critère : la portée, pas l'étiquette « IA »
Pour évaluer une intégration, posez des questions très concrètes : l'agent peut-il se limiter à consulter un solde, ou peut-il aussi déclencher un virement ? Peut-il accéder à l'historique complet ? L'accès est-il limité dans le temps ? Une validation humaine est-elle requise avant chaque opération ? Et où voir ce qui a été fait - et comment couper l'accès ?
Si le fournisseur ne répond pas clairement à ces points, considérez l'intégration comme trop opaque pour un compte financier. À l'inverse, un outil encadré, avec des permissions minimales, une authentification séparée et une validation explicite des opérations, peut présenter un risque différent. Mais dans tous les cas, il faut vérifier les conditions de la banque et du fournisseur.
Comment protéger concrètement ses comptes ?
La règle la plus simple est aussi la plus robuste : ne communiquez pas vos identifiants bancaires à un agent IA généraliste. Si l'argument est juste « ça simplifie vos finances », cela ne justifie pas de donner un mot de passe qui permet d'entrer dans votre espace client.
Avant de connecter un outil, faites ce contrĂ´le en cinq Ă©tapes :
- Définissez la tâche. Si vous voulez seulement catégoriser des dépenses, demandez-vous si un export expurgé de données sensibles suffit. Évitez l'accès bancaire complet pour une opération manuelle ponctuelle.
- Vérifiez la méthode d'accès. Refusez les solutions qui vous demandent de saisir votre mot de passe bancaire dans une interface tierce sans explication claire sur la sécurité et le cadre d'accès.
- Réduisez les permissions. Cherchez d'abord la consultation seule, et évitez la capacité d'effectuer des paiements. Limitez l'accès aux données et à la durée strictement nécessaires, quand c'est possible.
- Gardez une validation humaine. Toute opération financière doit passer par votre vérification dans l'application officielle de la banque. Une consigne donnée à un agent n'est pas une preuve suffisante de votre intention si l'agent interprète mal.
- Contrôlez et révoquez. Regardez les autorisations actives et l'historique des opérations. Coupez immédiatement ce que vous n'utilisez plus.
Activez aussi l'authentification multifacteur proposée par votre banque, et utilisez un mot de passe unique stocké dans un gestionnaire fiable. Ces mesures ne rendent pas le partage d'identifiants « sans risque », mais elles réduisent certains dégâts en cas de compromission.
Que faire si vous avez déjà partagé vos identifiants ?
Traitez la situation comme toute divulgation possible de mot de passe. Depuis le canal officiel de votre banque, modifiez le mot de passe, puis vérifiez les appareils, sessions ou autorisations connectées. Regardez les opérations récentes, et contactez la banque si quelque chose vous paraît anormal. Si le mot de passe a été réutilisé ailleurs, changez-le aussi sur les autres services.
Et ne vous contentez pas de désinstaller l'application : ça ne prouve pas que l'accès ou les données déjà transmises ont été supprimés. Révoquez explicitement les autorisations quand l'option existe, et consultez les paramètres de conservation côté fournisseur. En cas de doute, demandez à votre banque ce qu'elle recommande pour sécuriser le compte.
Que doivent retenir les entreprises et les Ă©quipes produit ?
Le sujet n'est pas réservé aux usages individuels. Une entreprise peut connecter un agent à des outils de facturation, de trésorerie ou de gestion des achats pour accélérer des tâches répétitives. Le gain de temps peut être réel. Mais dès qu'un agent accède à un compte partagé, ou utilise des identifiants de service, vous créez un risque organisationnel : ses actions peuvent devenir difficiles à attribuer, et encore plus difficiles à auditer.
Pour une équipe produit ou informatique, le principe utile est le moindre privilège : un agent ne doit avoir que les droits nécessaires à sa tâche précise. Par exemple, un agent chargé de rapprocher des écritures n'a pas automatiquement besoin de pouvoir effectuer des paiements. Et les comptes personnels ne devraient pas servir de « raccourci » pour intégrer un service dans un processus pro.
Concrètement : séparez les accès en consultation et en exécution, imposez une validation humaine pour les opérations sensibles, et gardez des journaux permettant de reconstituer ce qui s'est passé. Ajoutez aussi un mécanisme de révocation rapide, un responsable interne par intégration, et une procédure de réponse aux incidents. Oui, c'est plus lourd qu'un simple partage de mot de passe. Mais ça coûte moins cher qu'une opération erronée sans piste d'audit.
Le cadre européen de protection des données impose aussi de traiter les données personnelles avec une finalité précise et des mesures adaptées. Pour une entreprise, cela veut dire examiner ce qui est réellement transmis à l'agent, les conditions du fournisseur et les responsabilités des parties. Même une « expérimentation interne » ne contourne pas ces exigences parce que l'outil est nouveau.
Le bon modèle n'est donc pas d'interdire toute automatisation. Commencez par les tâches à faible risque et des données minimisées, puis élargissez les permissions seulement si le bénéfice est mesuré et si les contrôles suivent. Si vous ne pouvez pas expliquer qui peut déclencher une opération, comment elle est validée, et comment l'accès est coupé, l'intégration n'est pas prête pour un compte financier.
Conclusion
Les avertissements des banques ne veulent pas dire que toute automatisation financière serait à exclure. Ils rappellent surtout ceci : un agent capable d'agir sur un compte doit être traité comme un accès sensible, pas comme un simple « confort ». Dès qu'on partage un mot de passe, la portée de l'accès devient plus difficile à contrôler, à attribuer et à révoquer.
Pour un particulier comme pour une entreprise, la règle reste pragmatique : ne donnez pas plus de pouvoir que nécessaire. Vérifiez les permissions, gardez une validation humaine pour les opérations, surveillez les accès et choisissez des intégrations transparentes. Avant de connecter un compte, posez-vous une question simple : si l'agent se trompe ou si ses données sont exposées, est-ce que vous pourrez contenir la situation ? Si la réponse est incertaine, ne lui confiez pas cet accès.