Votre investissement dans la sécurité de l’IA est aussi solide que les données qui le sous-tendent.
Les responsables de la sécurité se sont lancés dans une course aux dépenses. Le marché mondial de l’IA dans la cybersécurité est évalué à 44 milliards de dollars en 2026 et devrait atteindre 213 milliards de dollars d’ici 2034, une trajectoire qui reflète la conviction sincère que l’apprentissage automatique comblera l’écart entre le volume des menaces et la capacité des analystes humains. Cette croyance n’est pas fausse. Ce qui ne va pas, c’est sur quoi la plupart des organisations se concentrent lorsque les outils cessent de fonctionner.
Lorsque la détection basée sur l’IA est sous-performante, l’instinct est d’ajuster l’algorithme, de recycler le modèle ou de pousser le fournisseur à proposer un meilleur produit. Le véritable coupable, dans la plupart des cas, se situe en amont dans les pipelines de données bien avant qu’un modèle ne voie un événement. Une télémétrie fragmentée, des schémas incohérents et des références comportementales obsolètes dégradent discrètement les performances des systèmes de sécurité d’IA dans l’ensemble de l’entreprise. Corriger l’algorithme sans corriger les données, c’est comme recalibrer une balance alors que l’entrée ne cesse de changer.
Le problème de la prolifération des outils dont personne ne parle au niveau des données
La plupart des grandes entreprises ne travaillent pas avec des données de sécurité propres et unifiées. Ils travaillent avec des décennies de décisions accumulées en matière d’infrastructures. Les recherches montrent qu’une entreprise moyenne utilise 83 produits de sécurité différents provenant de 29 fournisseurs distincts, et que les équipes SOC absorbent près de 3 000 alertes par jour, dont 63 % ne sont pas traitées. Chacun de ces outils génère sa propre télémétrie dans son propre format, avec ses propres conventions de dénomination de champs, normes d’horodatage et schémas de métadonnées.
Les analystes humains développent une intuition pour naviguer dans cette incohérence. Les modèles d’apprentissage automatique ne le font pas. Un modèle de détection comportementale formé pour corréler les événements d’authentification sur votre plateforme d’identité, votre agent de point de terminaison et votre courtier d’accès au cloud produira des résultats peu fiables si ces trois outils appellent le même champ sous trois noms différents. Le modèle n’est pas cassé. Il reçoit des données structurellement incohérentes et lui demande de trouver des modèles dans le bruit.
Ce que la dérive de schéma vous coûte réellement
C’est là que le problème devient invisible et coûteux. La dérive de schéma, c’est-à-dire la mutation progressive des formats de données à travers les pipelines de sécurité au fil du temps, déclenche rarement une alerte. Les formats de journaux changent lorsque les fournisseurs proposent des mises à jour. Les nouvelles sources de télémétrie ajoutent des champs qui n’existaient pas auparavant. Les plateformes d’identité renomment les attributs sans en informer l’équipe d’ingénierie de sécurité. Au fil des mois, les modèles statistiques qui ont entraîné vos modèles de détection comportementale ne correspondent plus aux données que ces modèles reçoivent en production.
Les effets en aval sont exactement ce que la plupart des RSSI subissent déjà : des taux de faux positifs élevés, la lassitude des analystes et des lacunes de détection qui ne deviennent visibles qu’après un incident. Ce que la plupart des responsables de la sécurité ne réalisent pas, c’est que ces symptômes remontent à la couche de données et non à la couche d’algorithme. Gartner prévoit que d’ici 2026, les organisations abandonneront 60 % de leurs projets d’IA en raison d’une qualité de données insuffisante, et cette tendance se manifeste aussi visiblement dans les opérations de sécurité que partout ailleurs.
Les lignes de base obsolètes constituent un avantage pour les attaquants
Le problème de la fraîcheur des données est sous-estimé en tant que risque de sécurité. Les modèles d’IA comportementale établissent des références à partir de l’activité historique. Dans les environnements d’entreprise en évolution rapide, ces références deviennent obsolètes plus rapidement que la plupart des équipes de sécurité ne le pensent.
Le passage au travail hybride a radicalement modifié les modèles d’accès. L’adoption du cloud a modifié les ressources avec lesquelles les utilisateurs interagissent et à quel moment. Les fusions et acquisitions introduisent de nouvelles populations d’utilisateurs aux profils comportementaux totalement différents. Lorsque les modèles d’IA évaluent l’activité actuelle par rapport à des références construites à partir d’une main-d’œuvre et d’une infrastructure qui n’existent plus, les résultats sont prévisibles : un accès légitime déclenche des alertes d’anomalie, et des attaquants sophistiqués qui étudient des modèles de référence peuvent se fondre dans la situation précisément parce que les hypothèses du modèle n’ont pas suivi l’environnement.
Les recherches d’IBM sur les coûts de la qualité des données estiment le coût annuel moyen d’une mauvaise qualité des données à 12,9 millions de dollars par organisation. Dans un contexte de sécurité, ce chiffre ne prend pas en compte les coûts de réponse aux incidents, l’exposition réglementaire ou les dommages à la réputation qui résultent d’un échec de détection enraciné dans une mauvaise architecture de données.
Le fossé organisationnel qui maintient ce problème en place
La raison pour laquelle ce problème persiste est structurelle. Les pipelines de données sont généralement gérés par des équipes d’ingénierie de données ou d’infrastructure. Les modèles de détection appartiennent aux analystes SOC ou aux équipes de renseignement sur les menaces. Les systèmes d’IA qui se situent entre ces deux fonctions n’appartiennent souvent à aucune des deux. Lorsque la qualité de la détection diminue, les équipes de sécurité ajustent les paramètres. Les équipes d’ingénierie se concentrent sur le coût et la disponibilité du pipeline. Personne n’est propriétaire de la cohérence analytique des données circulant dans le système, car aucune description de poste ne couvre cette lacune spécifique.
Il s’agit d’un problème de leadership avant d’être technique. Les RSSI qui souhaitent que les outils de sécurité de l’IA fonctionnent comme annoncé doivent combler ce fossé en matière de propriété et traiter la télémétrie de sécurité avec la même rigueur que celle appliquée aux autres actifs de données critiques de l’entreprise.
Trois priorités pour les responsables de la sécurité
Résoudre ce problème ne nécessite pas de remplacement de plateforme ni de programme de transformation pluriannuel. Cela nécessite une attention délibérée dans trois domaines :
- Standardisez les schémas de télémétrie dans votre pile de sécurité. Un schéma unifié, même imparfait, donne aux modèles d’apprentissage automatique une base cohérente. Établissez des conventions de dénomination pour les champs courants, normalisez les formats d’horodatage et documentez les écarts lorsque les fournisseurs ne peuvent pas s’y conformer. Il ne s’agit pas d’un projet ponctuel. C’est une gouvernance continue.
- Intégrez une surveillance de la qualité des données dans chaque pipeline d’ingestion. Avant qu’un événement n’atteigne un système ML, validez-le pour détecter les champs manquants, les anomalies d’horodatage et les écarts de schéma. Il est bien moins coûteux de détecter la dérive des données lors de l’ingestion que de diagnostiquer les échecs de détection après un incident réel ou après qu’un attaquant s’est déjà déplacé latéralement.
- Appliquez une discipline de gouvernance aux données de sécurité, et pas seulement aux données d’entreprise. Le suivi du lignage, les règles de validation et les schémas de contrôle de version appartiennent autant aux pipelines de sécurité qu’aux pipelines de reporting financier. La télémétrie de sécurité est un actif commercial essentiel et doit être gérée en conséquence.
Les outils de sécurité basés sur l’IA de votre pile sont capables d’apporter une réelle valeur ajoutée contre les menaces modernes. Mais cette capacité dépend entièrement de la qualité, de la cohérence et de la fraîcheur des données qui y circulent. Avant que votre organisation n’investisse un dollar supplémentaire dans le réglage de modèles ou dans la mise à niveau de la plateforme, posez une question plus difficile et plus productive : à quand remonte la dernière fois que quelqu’un a audité les pipelines dont dépendent réellement ces modèles ?
Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?
