Agents IA, banques et cybersécurité : les risques
Agents dans les comptes bancaires, failles PHP découvertes avec l’IA, baisse des coûts des modèles : les signaux à comprendre pour agir dès maintenant.
Agents IA, banques et cybersécurité : trois signaux à prendre au sérieux
L'intelligence artificielle progresse vite, mais ses effets ne se limitent pas à des démonstrations de modèles ou à des gains de productivité. Dans les banques, des agents logiciels commencent à accéder à des comptes clients. En cybersécurité, des outils d'IA ont aidé à repérer des failles dans du code PHP, largement présent sur le Web. Et pendant que ces usages montent en puissance, le prix des modèles baisse, ce qui rend les prévisions économiques moins simples qu'on ne l'imagine.
Le point commun, c'est le passage de la conversation à l'action : l'IA lit des données, appelle des services, exécute des tâches. C'est là que la gouvernance, la responsabilité et la rentabilité deviennent très concrètes. Pour les entreprises françaises et européennes, l'enjeu n'est pas de suivre chaque annonce, mais de comprendre ce qui change dans leurs systèmes et dans leurs décisions.
Voici trois signaux à surveiller, les risques qu'ils révèlent et une méthode pragmatique pour s'y préparer, sans confondre potentiel technique et capacité réelle à déployer en production.
Des agents IA accèdent aux comptes bancaires
Selon des informations rapportées par Axios le 22 octobre 2026, plusieurs grandes banques américaines auraient détecté des agents d'IA tiers qui accèdent à des comptes clients. Dans certains cas, ces outils utiliseraient les identifiants transmis par le client. D'autres activités observées auraient consisté à contacter des centres d'appels ou à lancer des actions qui ne semblaient pas suivre exactement les instructions de l'utilisateur.
Deux situations méritent d'être séparées. D'un côté, un client peut autoriser un assistant à consulter ses opérations ou à préparer une action. De l'autre, un agent peut accéder à un compte dans des conditions que la banque n'a ni conçues ni validées. Pour l'établissement, la difficulté est de vérifier si l'action vient bien du client, si elle correspond à son intention, et si le logiciel n'a pas dépassé le périmètre autorisé.
Le problème n'est pas seulement l'accès, mais le niveau d'autorité
Un assistant en lecture seule peut agréger des dépenses ou répondre à une question sur un budget. Un agent qui initie un virement, effectue un achat ou modifie des paramètres change de catégorie : il devient un acteur opérationnel, capable d'agir.
La différence n'est pas « théorique ». Une mauvaise interprétation dans une réponse textuelle peut être rattrapée au tour suivant. Une opération financière, elle, peut être beaucoup plus compliquée à annuler. Et si l'agent agit avec les identifiants de l'utilisateur, les mécanismes de sécurité habituels peuvent ne pas distinguer clairement une action humaine d'une automatisation.
D'après le même article, certaines banques américaines limitent déjà l'accès d'agents tiers à leurs plateformes. Les positions ne sont pas uniformes : plusieurs établissements privilégient la consultation, sans capacité d'exécuter des opérations. Un porte-parole de Morgan Stanley a indiqué à Axios que la banque n'avait pas observé de cas d'agents IA « hors de contrôle » accédant à ses plateformes. Ces nuances comptent : un signalement de risque n'est pas la preuve qu'un incident avéré a touché toutes les banques.
Les identifiants partagés créent une zone grise
En général, les banques déconseillent de partager ses identifiants avec un tiers. Pourtant, certains services d'automatisation ne fonctionnent qu'en se connectant « comme si l'utilisateur était là ». Cela peut faciliter un déploiement, mais ça rend l'attribution plus délicate : qui a vraiment déclenché l'action, et qui porte la responsabilité quand quelque chose tourne mal ?
En Europe, la question touche directement la protection des données et la sécurité des services financiers. Le règlement général sur la protection des données encadre le traitement des informations personnelles, tandis que les exigences de sécurité du secteur bancaire imposent de maîtriser les accès et les opérations. Concrètement, une entreprise qui intègre un agent dans un parcours de paiement ne peut pas se contenter de vérifier que « ça marche ». Elle doit aussi définir ce qui est autorisé, comment on le contrôle, et comment on retrace ce qui s'est passé.
Pour un déploiement sérieux, il faut au minimum préciser :
- quelles données l'agent peut consulter ;
- quelles actions il peut proposer, préparer ou exécuter ;
- quelles étapes exigent une confirmation humaine ;
- quels journaux sont conservés pour reconstituer une opération ;
- comment on révoque les accès et on revient à un état sûr après un incident.
La règle pratique tient en une phrase : commencez par le périmètre d'action le plus limité qui apporte une valeur mesurable. La lecture seule n'est pas une solution « magique », mais elle réduit clairement le risque quand quelque chose se trompe. Ensuite seulement, l'autonomie peut s'étendre action par action, si les contrôles et les recours sont bien en place.
La découverte de failles par l'IA change la donne
Le deuxième signal concerne la cybersécurité. Des chercheurs auraient identifié deux vulnérabilités critiques dans PHP, un langage open source utilisé par une grande partie des sites Web. Selon le contenu rapporté par Axios, un modèle d'OpenAI aurait contribué à cette découverte. Des autorités de plusieurs pays, dont les États-Unis et le Japon, auraient appelé les organisations concernées à appliquer les correctifs, voire à mettre hors ligne les systèmes qui ne peuvent pas être suffisamment protégés.
Ces failles auraient permis à un attaquant de prendre le contrôle de serveurs vulnérables, sans mot de passe ni identifiant. Des chercheurs de Wiz ont décrit ces découvertes comme faisant partie des vulnérabilités les plus graves identifiées dans PHP. Attention toutefois à ne pas tirer une conclusion trop large : ce n'est pas « l'IA trouve toutes les failles désormais ». C'est plutôt ceci : des modèles peuvent aider à repérer des problèmes que des processus humains et des tests automatisés n'avaient pas détectés, y compris dans des composants anciens et très répandus.
L'IA accélère la découverte, mais pas la correction
Trouver une vulnérabilité ne rend pas un système sécurisé. Il faut vérifier le constat, identifier les versions concernées, estimer l'exposition réelle, préparer un correctif, le tester et le déployer. Dans une grande organisation, ces étapes passent souvent par des dépendances applicatives, des fenêtres de maintenance et des environnements dont l'inventaire n'est pas toujours complet.
C'est là que l'asymétrie se joue. L'aide fournie par l'IA peut accélérer le travail d'un chercheur, mais elle peut aussi aider un attaquant à avancer plus vite. Les équipes défensives doivent donc améliorer deux choses : la capacité à détecter, et surtout le délai de réponse. Une alerte qui reste coincée plusieurs semaines dans une file de traitement n'a pas grand intérêt si l'exploitation arrive, elle, en quelques heures ou jours.
Les équipes techniques peuvent s'en servir pour poser des questions très concrètes :
- Quelles versions de PHP et quelles dépendances tournent chez nous ?
- Quels services sont exposés depuis Internet ?
- Qui décide de déployer un correctif critique, et sous quel délai ?
- Avons-nous un plan de repli si la mise à jour casse une application essentielle ?
Si la réponse à la première question est « on n'est pas sûrs », un nouvel outil de sécurité ne devrait pas être la première priorité. Avant tout, il faut fiabiliser l'inventaire et tenir une chaîne de mise à jour opérationnelle. En France, les recommandations de l'ANSSI peuvent servir de point de départ pour structurer cette démarche.
L'open source est un actif partagé, pas une garantie
Beaucoup d'organisations utilisent des composants open source sans financer directement toute la maintenance. Ce modèle a créé des briques indispensables. Mais il crée aussi une dépendance collective : un défaut dans une bibliothèque très utilisée peut toucher des services très différents, du site marchand à l'outil métier interne.
Cela ne veut pas dire « évitez l'open source ». Ça veut dire « traitez les dépendances comme un patrimoine technique ». Les responsables doivent savoir quels composants sont déployés, qui les maintient, comment les correctifs sont suivis, et quelles alternatives existent si un composant devient vulnérable ou est abandonné.
L'IA ne remplace pas cette discipline. Elle peut aider à analyser du code, prioriser des alertes, ou accélérer certaines tâches de recherche. Mais un résultat issu d'un modèle doit être vérifié par des personnes capables d'en évaluer la portée. En sécurité, une fausse alerte fait perdre du temps ; une confiance trop forte dans une analyse erronée peut coûter bien davantage.
La baisse des prix des modèles brouille les prévisions
Le troisième signal est économique. Les prix des jetons - l'unité utilisée pour facturer les entrées et sorties des modèles - ont baissé ces derniers mois. L'indice de dépenses de jetons de Silicon Data cité par Axios est passé sous un dollar par million de jetons, après un pic à 2,07 dollars fin mai, soit une baisse de 54 %.
Cet indice reflète un mix de modèles et de tarifs. Il ne dit donc pas exactement ce que coûte chaque requête, ni ce que chaque fournisseur facture. La baisse s'explique notamment par l'adoption de modèles ouverts moins chers, des réductions annoncées par certains acteurs, et la mise en cache d'une partie des échanges réutilisés dans des conversations longues.
À première vue, des modèles moins chers rendent les usages plus rentables. Mais le coût unitaire n'est qu'une partie du modèle économique. Il faut aussi compter l'intégration, le traitement des erreurs, l'évaluation, la supervision humaine, la sécurité, et les coûts d'infrastructure. Une automatisation « pas chère » par requête peut vite coûter cher si elle déclenche plusieurs appels, ou si elle impose une vérification systématique.
Plus d'usage ne veut pas dire plus de revenus
Le paradoxe de Jevons est souvent cité : quand une ressource devient moins chère, la demande peut augmenter au point de faire monter la consommation totale. Ici, l'usage progresse bien. Pourtant, selon les données de Ramp reprises dans l'article, les dépenses des entreprises en jetons seraient restées assez stables sur deux mois, alors que l'utilisation continuait d'augmenter.
Le décalage mérite attention. Les entreprises obtiennent davantage de capacité pour un budget similaire, ce qui peut être positif pour les clients. Mais pour les fournisseurs de modèles, une hausse du volume ne garantit pas une hausse proportionnelle du chiffre d'affaires. Si les prix baissent plus vite que les volumes ne montent, les prévisions de revenus doivent être revues.
Le même raisonnement vaut pour les investissements dans les centres de données et les infrastructures. Axios cite des estimations de Goldman Sachs : les grands opérateurs américains de services infonuagiques pourraient investir environ 800 milliards de dollars en 2026, puis 1 100 milliards en 2027. Ce sont des projections, pas des dépenses déjà engagées ni une promesse de rendement. Leur pertinence dépendra surtout de la demande solvable, des marges, et du taux d'utilisation des capacités.
Pour une entreprise utilisatrice, le bon indicateur n'est donc pas seulement le prix par million de jetons. Il faut suivre le coût complet d'un résultat réellement utile :
- coût du modèle et des appels associés ;
- temps passé à vérifier et corriger les réponses ;
- taux de réussite de la tâche sans intervention ;
- coût des erreurs, des retours en arrière, et des opérations à annuler ;
- économies réellement constatées par rapport au processus existant.
C'est ce calcul qui permet de savoir si la baisse de tarif améliore la rentabilité, ou si elle encourage surtout un usage plus intense sans gain métier proportionnel.
Conclusion : traiter l'IA comme un système d'action
Les signaux sont différents, mais leur message est commun : l'IA change les systèmes dès qu'elle peut accéder à des données, intervenir dans un processus, ou accélérer une activité existante. La vraie question n'est donc pas seulement « quel modèle choisir ? », mais « quelles conséquences peut-il déclencher, et comment les détecter ou les arrêter ? »
Pour avancer, commencez petit : un usage limité et mesurable. Cartographiez les accès, suivez les coûts complets, mettez vos dépendances à jour et prévoyez un scénario de retour en arrière. Si un agent peut agir, vous devez pouvoir comprendre, limiter et interrompre son action.
Choisissez un processus concret dès cette semaine. Identifiez les données auxquelles il donne accès, les décisions qu'il automatise, et la personne qui peut arrêter le système. C'est un meilleur point de départ qu'un projet d'IA plus ambitieux, mais beaucoup plus difficile à contrôler.
Comment décider quoi faire dans son entreprise
Ces trois évolutions ne appellent pas la même réponse. Les agents bancaires posent d'abord une question de gouvernance et de contrôle des actions. Les failles PHP rappellent l'importance de la gestion des vulnérabilités. La baisse des prix oblige à revoir les hypothèses économiques. Regrouper tout cela sous une bannière « stratégie IA » ne remplace pas les décisions opérationnelles à prendre.
Une méthode en quatre étapes
Cette approche s'aligne avec les principes de gestion des risques attendus par la réglementation européenne, notamment le règlement européen sur l'intelligence artificielle. Les obligations varient selon les usages et les rôles des acteurs. Le plus important, pour une équipe produit, n'est pas de transformer chaque projet en exercice juridique. C'est d'intégrer responsabilités, contrôles et documentation dès le départ, plutôt que de les rajouter après coup.
Et évitez deux réflexes opposés. Le premier, c'est « on automatise tout parce que c'est possible ». Le second, c'est « on bloque tout parce qu'il y a un risque ». Dans les deux cas, la décision se fait sans regarder le contexte. Une approche plus robuste consiste à commencer par des tâches réversibles, limiter les permissions, observer les résultats, puis élargir le périmètre seulement si les preuves le justifient.