La sécurité IA regarde au mauvais endroit

Le chiffre le plus inquiétant sur la sécurité de l’IA dans les recherches d’IBM ne raconte pas l’histoire d’un modèle génial inventant une attaque inédite. Il pointe vers quelque chose de bien plus ordinaire : une hausse de 44 % des attaques qui ont commencé par des applications exposées au public.

Ce constat paraît presque décevant, et c’est précisément ce qui le rend important. Alors que le débat imagine des logiciels malveillants autonomes et des vagues d’hameçonnage synthétique, le risque immédiat passe souvent par de vieux chemins : logiciels visibles, contrôles d’identité faibles, identifiants périmés et outils tiers peu vérifiés.

L’IA révèle les contrôles remis à plus tard

IBM X-Force indique que les attaques débutant par l’exploitation d’applications accessibles au public ont augmenté de 44 % sur un an dans son 2026 Threat Intelligence Index. Il ne s’agit pas d’un scénario de science-fiction. Il s’agit du portail de connexion, du point d’API, du panneau d’administration, du module oublié ou du service visible sur internet que l’équipe devait examiner plus tard.

Or ce “plus tard” n’a plus le même coût. Si des attaquants peuvent utiliser l’IA pour scanner plus vite, résumer de la documentation technique, produire des variantes d’exploitation et transformer des identifiants volés en accès réel, chaque retard ancien reçoit un nouveau multiplicateur. Il suffit d’un contrôle négligé en public, pendant que l’automatisation rend la découverte moins coûteuse.

La brèche commence avant le récit sur l’IA

Le communiqué d’IBM affirme que l’exploitation de vulnérabilités est devenue la première cause d’attaques, représentant 40 % des incidents observés par X-Force en 2025, selon l’annonce d’IBM. La question pratique change donc : que leur avons-nous déjà laissé ouvert ?

Dans une PME, une agence ou une équipe produit en croissance, la réponse est souvent prosaïque. Un compte SaaS reste actif après le départ d’un prestataire. Un tableau de bord public repose sur un mot de passe réutilisé. Une dépendance web n’a pas de responsable clair. Une boîte de support peut réinitialiser trop de comptes. Une clé d’API se trouve dans un document partagé parce que c’était pratique, non parce que c’était sûr.

Le problème d’identité était déjà visible

Le point le plus utile du rapport n’est pas de dire que l’IA ne compte pas. Il consiste à rappeler que la couche IA repose sur des problèmes d’identité et d’exposition que beaucoup d’organisations ont déjà sous-estimés. IBM souligne que 56 % des vulnérabilités divulguées ne nécessitaient aucune authentification, tandis que plus de 300 000 identifiants de chatbots IA ont été observés à la vente sur le dark web, selon le hub du rapport 2026.

Si plus de la moitié des vulnérabilités publiées ne requièrent pas de connexion, l’attaquant n’a peut-être même pas besoin de voler un mot de passe pour commencer. En parallèle, des identifiants de chatbot volés peuvent exposer des prompts privés, du contexte métier, des fragments clients, des notes internes et des flux connectés. Ce n’est pas seulement un secret perdu. C’est un inventaire de contexte.

Voilà pourquoi les data brokers and exposed personal data appartiennent à la même discussion. Les brèches commencent rarement par une porte spectaculaire enfoncée. Elles commencent par assez d’informations éparses pour rendre la porte suivante plus facile à ouvrir.

Que corriger avant d’acheter un nouvel outil

La position contrarienne n’est pas d’ignorer les cyberattaques renforcées par l’IA. Elle consiste à cesser de les traiter comme un univers séparé. Si les correctifs, l’authentification, les journaux et la suppression des comptes sont faibles, l’IA ne crée pas la faiblesse. Elle accélère la facture.

Une équipe réelle peut commencer par un audit court : lister les applications exposées; activer le MFA là où une prise de compte ferait des dégâts; supprimer les comptes inactifs; renouveler les clés anciennes; vérifier les applications tierces; alerter sur les connexions impossibles, téléchargements massifs et nouveaux administrateurs.

Si cela semble élémentaire, c’est le cœur du sujet. Même la conversation sur le MFA est une conversation sur la qualité des contrôles, raison pour laquelle le classement des MFA methods that fail fast doit accompagner tout budget de sécurité IA.

L’erreur consiste à acheter des outils censés voir l’avenir alors que le présent fuit encore. Avant de demander si les attaquants utilisent l’IA, demandez quel contrôle ennuyeux échouerait plus vite s’ils l’utilisaient.