IA et cybersécurité : 1 000 renforts chez Bank of America
Bank of America mobilise 1 000 consultants pour corriger des failles révélées par l’IA. Découvrez les enjeux pour les banques et leurs équipes cyber.
Bank of America mobilise 1 000 consultants pour corriger des failles signalées avec l'aide de l'IA
L'intelligence artificielle ne sert pas seulement à écrire du code ou à automatiser des tâches. Elle peut aussi mettre en lumière, à grande échelle, des faiblesses dans des logiciels qui tournent depuis des années. Bank of America l'a rappelé en parlant d'un chantier de correction mené avec l'aide de modèles d'IA, dont Mythos, développé par Anthropic.
Dans ses propos relayés au sujet des résultats du deuxième trimestre, son directeur général, Brian Moynihan, a indiqué que la banque avait mobilisé environ 1 000 consultants externes pour corriger des vulnérabilités repérées avec ces outils. Le renfort s'ajoute à un effectif déjà engagé : environ 3 000 salariés travaillaient sur des travaux de remédiation similaires.
Le montant évoqué donne aussi une idée du niveau d'effort. La banque a fait état de plusieurs centaines de millions de dollars de dépenses de remédiation sur la période, avec notamment un chantier distinct portant sur des contrôles antiblanchiment. Par ailleurs, les chiffres attribués à Brian Moynihan n'ont pas été vérifiés indépendamment par le média à l'origine de l'information.
Autrement dit, l'enjeu ne se limite pas à Mythos. Pour les banques et les entreprises européennes, la vraie question est opérationnelle : comment passer d'une découverte assistée par l'IA à une correction effectivement validée, priorisée et durable ?
Ce que Bank of America a réellement annoncé
Le 14 octobre, après la publication de ses résultats trimestriels, Brian Moynihan a déclaré à CNBC que Bank of America avait mobilisé environ 1 000 intervenants externes au deuxième trimestre. Ces consultants devaient aider à réparer des faiblesses logicielles mises en évidence par des modèles d'IA, dont Mythos, le modèle d'Anthropic. Le dirigeant a également mentionné le sujet lors de la conférence téléphonique avec les analystes.
Ces consultants ne faisaient pas partie des effectifs permanents de la banque. Ils venaient renforcer une équipe interne déjà mobilisée : environ 3 000 salariés travaillaient sur des actions de remédiation du même type avant leur arrivée. Dans ces conditions, parler de « 4 000 personnes » ne veut pas dire automatiquement qu'une nouvelle équipe dédiée à Mythos a été créée de toutes pièces, ni que 4 000 spécialistes travaillent exclusivement sur ce modèle.
Autre point à garder en tête : les « quelques centaines de millions de dollars et plus » de dépenses évoquées pour le trimestre couvraient deux chantiers distincts. Il y avait d'un côté les travaux liés aux vulnérabilités associées à Mythos, et de l'autre la réparation de contrôles antiblanchiment. Il n'est donc pas exact d'attribuer l'intégralité de la somme à l'IA, ou au seul modèle d'Anthropic. Moynihan a par ailleurs indiqué s'attendre à ce que la part des travaux liés à Mythos baisse au fur et à mesure que les équipes supplémentaires seront mobilisées.
Le contexte réglementaire renforce la nécessité de ces distinctions. La veille de ces déclarations, des sanctions dépassant 1,21 milliard de dollars avaient été annoncées à l'encontre de Bank of America. Les autorités reprochaient notamment à la banque de ne pas avoir signalé des transactions suspectes représentant 5 milliards de dollars, et de ne pas avoir achevé certaines mesures demandées en 2024. Ces difficultés de conformité peuvent expliquer une partie du volume de dépenses évoqué, mais elles ne doivent pas être confondues avec des failles logicielles repérées via l'IA.
Enfin, le chiffre des 1 000 consultants vient des propos de Brian Moynihan rapportés par CNBC et The Next Web. The Next Web précise ne pas avoir vérifié ces éléments de manière indépendante. On est donc face à un indicateur d'ampleur, pas à un audit public qui détaillerait les vulnérabilités, les coûts par catégorie ou le nombre de correctifs effectivement déployés.
Pourquoi l'IA change l'échelle de la cybersécurité
Les logiciels des grandes banques ne forment pas un bloc uniforme. On y trouve des applications récentes, des systèmes plus anciens, des composants fournis par des tiers et du code développé en interne. Une faiblesse peut apparaître dans une dépendance logicielle, dans une interface, dans un service exposé, ou encore dans une partie du code que personne n'a touchée depuis longtemps. Dans ce type d'environnement, repérer les problèmes est déjà compliqué ; décider lesquels traiter en premier l'est tout autant.
Un modèle capable d'analyser du code et de contribuer à repérer des vulnérabilités peut accélérer certaines étapes d'un audit. Il peut aider à signaler des motifs suspects, à explorer des chemins d'attaque, ou à attirer l'attention sur des composants qui méritent une vérification humaine. C'est une aide défensive réelle : mieux vaut identifier une faiblesse dans un périmètre contrôlé que la laisser accessible à des acteurs malveillants.
Mais l'IA ne transforme pas automatiquement un signal en correction sûre. Une vulnérabilité suggérée peut être un faux positif, un problème déjà traité, ou un risque difficile à exploiter dans le contexte réel. À l'inverse, une alerte qui semble mineure peut toucher un composant partagé par plusieurs applications. Dans tous les cas, il faut comprendre la dépendance, vérifier l'exposition, évaluer l'impact possible et tester le correctif sans mettre en danger un service critique.
C'est là que l'effet d'échelle devient concret. Si un outil permet de découvrir beaucoup plus de failles en moins de temps, le volume de travail peut grimper plus vite que la capacité des équipes à valider et déployer les correctifs. Autrement dit : l'IA accélère la découverte, mais elle ne supprime ni les arbitrages de priorité, ni les tests, ni les contraintes de mise en production. Dans certains cas, elle déplace simplement le goulot d'étranglement.
Anthropic a présenté Mythos en avril dans le cadre de Project Glasswing, un programme donnant accès au modèle à un groupe limité d'entreprises, de banques et d'organismes publics. L'objectif affiché était de repérer puis corriger des failles avant qu'elles ne soient exploitées. Un mois plus tard, des régulateurs américains auraient suspendu certains examens cyber pour laisser davantage de temps aux grandes banques. On voit donc que le sujet est à la fois technique, organisationnel et réglementaire.
Le véritable défi : corriger sans fragiliser le système
Pour une banque, un correctif ne se résume pas à modifier une ligne de code. Il faut savoir qui est propriétaire du composant, quels services en dépendent, si le fournisseur doit intervenir, et comment tester la modification. Sur des systèmes sensibles, une mise à jour mal synchronisée peut provoquer une interruption, créer une nouvelle vulnérabilité ou perturber un processus métier. Ne rien faire comporte un risque ; corriger sans maîtrise en comporte un autre.
Le recours à des consultants s'explique donc assez bien : cela augmente temporairement la capacité d'analyse et de remédiation, sans exiger de transformer immédiatement les effectifs permanents. Mais ça a aussi un coût et une limite. Les connaissances et les décisions doivent rester dans l'organisation. Si une partie des correctifs est produite sans transfert réel, la banque peut se retrouver avec une dette de compréhension une fois la mission terminée.
Une démarche robuste doit surtout relier la découverte à la preuve de correction. Concrètement, cela suppose un flux de travail clair, du type :
- Qualifier l'alerte : confirmer qu'il s'agit d'une vulnérabilité réelle et documenter ce qui a été observé.
- Mesurer l'exposition : identifier les systèmes concernés, leur accessibilité et les conséquences possibles d'une exploitation.
- Prioriser selon le risque : traiter d'abord les failles exploitables sur des services critiques, plutôt que suivre uniquement le volume d'alertes.
- Attribuer un responsable : préciser quelle équipe interne ou quel fournisseur doit intervenir, avec un délai et un niveau de validation définis.
- Tester et déployer : vérifier le correctif dans des conditions proches de la production, puis planifier sa mise en service.
- Confirmer la fermeture : contrôler que la vulnérabilité n'est plus présente et conserver une trace utile pour un audit.
Le pilotage doit aussi séparer les catégories de dépenses. Le montant global annoncé par Bank of America englobe la cybersécurité liée à Mythos et les contrôles antiblanchiment. Pour juger si l'IA améliore réellement la sécurité, il faudrait pouvoir distinguer les coûts de découverte, de validation, de développement des correctifs, de tests et de déploiement. Sans cette ventilation, il devient difficile de comparer sérieusement un programme assisté par IA à un audit plus classique ou à un renforcement des équipes internes.
Enfin, l'automatisation de l'analyse du code pose aussi des questions de gouvernance. Les organisations doivent savoir quelles données sont transmises au modèle, qui peut accéder aux résultats, comment les informations sensibles sont protégées, et si les conclusions sont suffisamment traçables. Le fait qu'un modèle ait produit une alerte ne vaut pas, à lui seul, preuve de sécurité. La responsabilité de la correction et de son déploiement reste celle de l'organisation.
Ce que les banques européennes peuvent en retenir
Les établissements européens n'ont pas besoin de reproduire à l'identique la façon de faire de Bank of America. Les systèmes ne sont pas les mêmes, les fournisseurs non plus, et l'exposition varie. En revanche, le cas illustre une réalité assez fréquente : quand un outil accélère la découverte, il crée aussi un besoin urgent de capacité humaine pour traiter les alertes.
Les autorités de supervision s'intéressent déjà aux risques liés à l'IA et aux agents capables d'agir sur des systèmes informatiques. La Banque centrale européenne a demandé aux établissements de préparer des mesures face aux menaces rendues possibles par l'IA, avec une échéance annoncée à la fin du mois d'octobre. Aux États-Unis, Jamie Dimon a indiqué en mai que plusieurs centaines de personnes travaillaient sur le sujet. Ces signaux vont dans le même sens : la préparation cyber devient un chantier de gouvernance, pas seulement un achat d'outil.
Pour une direction informatique ou un comité des risques, la question n'est pas seulement : « faut-il utiliser Mythos ? ». La question utile est plutôt : « si un outil révèle demain cent failles sérieuses, avons-nous la capacité de les qualifier, de les corriger et de prouver que c'est fait ? ». Cela vaut aussi pour les fournisseurs et les logiciels tiers. Bank of America précise que les faiblesses concernaient du code utilisé par la banque et par ses prestataires : la frontière entre sécurité interne et sécurité de la chaîne d'approvisionnement est donc plus floue qu'on ne le croit.
Un plan pragmatique peut commencer par quatre vérifications :
- Cartographier les composants critiques, y compris ceux fournis par des tiers, et désigner un responsable pour chaque périmètre.
- Mesurer le débit de remédiation, pas seulement le nombre de failles détectées : combien sont confirmées, corrigées et vérifiées dans des délais définis ?
- Préparer une capacité de renfort, en interne ou en externe, avec des règles d'accès, de confidentialité et de transfert de connaissances.
- Tester le processus sur un périmètre limité, avant d'étendre l'analyse assistée par IA à toute l'organisation.
Cette approche évite deux erreurs opposées. La première, refuser l'outil parce qu'il ne remplace pas les experts : il n'a pas besoin de les remplacer pour être utile. La seconde, croire que détecter automatiquement revient à sécuriser automatiquement. En réalité, la valeur dépend de la suite : qualification, arbitrage, correction, validation et apprentissage.
Pour les entreprises françaises, il faut aussi tenir compte des données et des responsabilités contractuelles. Avant d'envoyer du code à un service d'IA, il faut vérifier les conditions de traitement, les règles de confidentialité et les obligations applicables, notamment au regard du RGPD si des données personnelles entrent en jeu. La sécurité ne se délègue pas à un modèle, pas plus qu'à un prestataire : elle exige une chaîne de décision explicite.
Conclusion : mesurer la capacité à corriger, pas seulement à détecter
L'annonce de Bank of America montre une tendance importante : avec l'IA, la découverte de vulnérabilités peut atteindre un volume qui oblige les organisations à revoir leur capacité de remédiation. Les quelque 1 000 consultants annoncés ne prouvent pas, à eux seuls, que Mythos a découvert un nombre précis de failles ni que toutes ont été corrigées. Ce que cela indique, surtout, c'est que la découverte n'est qu'un début.
Pour les banques et les entreprises européennes, l'indicateur pertinent ne sera pas le nombre d'alertes produites par un modèle. Ce sera la capacité à confirmer les risques, prioriser les interventions, corriger sans fragiliser les services et conserver une preuve vérifiable du résultat. Commencez par cartographier vos actifs critiques et testez votre processus de remédiation sur un périmètre restreint : c'est souvent là que l'utilité de l'IA devient vraiment mesurable.