Quand on suit une enquête, on remarque vite que le déclic ne vient pas d’une seule preuve. C’est l’ensemble des éléments, liés les uns aux autres, qui permet de reconstruire le scénario. La cybersécurité fonctionne de façon similaire : pour tirer parti de l’intelligence artificielle, encore faut-il lui donner ce qui manque le plus souvent — des données complètes, capables de raconter l’histoire entière.
Dans la pratique, beaucoup d’environnements ajoutent de l’IA à des systèmes qui n’ont jamais été pensés pour fournir la matière première dont les modèles ont besoin. Le résultat ? Des signaux incomplets, des chronologies difficiles à reconstituer et des analyses qui ne “collent” pas toujours à la réalité du terrain.
Pourquoi l’IA échoue sans données complètes
Pendant longtemps, la “donnée” en sécurité s’est résumée aux journaux (logs) et aux événements. Or, ces informations ne reflètent pas fidèlement tout ce qui se passe dans l’environnement. Les outils de sécurité filtrent, normalisent et pré-traitent souvent la télémétrie avant de la transmettre. Ainsi, les logs qui arrivent au SIEM ne représentent qu’une fraction de la réalité produite sur le système.
Concrètement, cela signifie qu’un événement “création de processus” peut arriver déjà amputé de son contexte et de ses relations temporelles avec les événements voisins. Pour un humain, ces manques se traduisent par des zones d’ombre. Pour un modèle d’IA, ils peuvent suffire à empêcher de relier correctement des indices.
Dans une époque où les attaques ne se contentent plus d’un seul domaine, l’enjeu devient plus élevé encore. Les intrusions modernes s’étendent sur plusieurs systèmes et plusieurs couches. Pour les détecter et les “coudre” ensemble, l’IA doit disposer d’informations qui traversent les produits, pas seulement d’extraits isolés.
Relier les fragments : le besoin de contexte multi-systèmes
Imaginez un scénario d’initié malveillant : une personne quitte l’entreprise, ouvre un document lié à l’analyse concurrentielle, le télécharge, le copie vers un espace cloud personnel puis l’envoie à l’extérieur. Cette chaîne d’actions touche plusieurs systèmes distincts.
Un SIEM classique peut certes signaler des événements partiels : une alerte DLP lors du téléchargement, un drapeau CASB lors de l’upload vers un service externe. Mais sans l’enchaînement complet — la lignée du fichier, les autres accès, et la comparaison du comportement avec la normale observée sur plusieurs mois — il devient beaucoup plus difficile de comprendre l’intention.
Avec l’approche “données complètes”, l’objectif change : au lieu d’identifier seulement une anomalie locale, on cherche à reconstruire la séquence. En interprétant les événements via leur trajectoire (qui a accédé à quoi, quand, et comment) et via la chronologie, on transforme des signaux isolés en indice d’une attaque en cours.
Passer du “volume” à la “qualité” : normalité et écart
Un autre défi apparaît avec l’augmentation de la sophistication des attaques. L’intelligence artificielle aide à détecter des comportements discrets, notamment quand l’adversaire tente de se fondre dans le quotidien. Pourtant, ces écarts ne deviennent vraiment visibles que lorsque les échantillons sont suffisamment riches.
Un seul événement, comme une connexion à 1 h du matin, peut être ambigu. En revanche, une série d’événements sur la durée — et corrélée à d’autres données comme la télémétrie d’appareils et les schémas d’accès — permet de déterminer si l’utilisateur correspond à un profil attendu (par exemple, un dirigeant en déplacement) ou si l’on a affaire à un usage anormal de clés volées.
Autrement dit, l’IA ne peut pas “inventer” le contexte. Les données complètes servent justement à rendre la normalité observable et l’écart exploitable.
Qu’est-ce que des données complètes pour la sécurité IA ?
Pour fonctionner correctement, la sécurité alimentée par l’IA a besoin de plus qu’un simple flux d’alarmes. Elle requiert des informations à haute fidélité, non filtrées dès la source, et accompagnées d’un contexte opérationnel profond.
Les données utiles se regroupent généralement en plusieurs catégories.
- Télémétrie de sécurité : signaux provenant des systèmes de protection et d’observation.
- Contexte infrastructure et opérations : réseau, capteurs OT, objets IoT, environnements SaaS et cloud, selon l’architecture de l’entreprise.
- Données d’identité : identité des humains, mais aussi des services, comptes techniques, clés API et jetons associés aux événements.
- Données utilisateur et contenu : fichiers, documents et contenus qui circulent dans les applications, serveurs et environnements de travail.
- Données “cœur” propriétaires : ce que l’organisation considère comme ses actifs les plus critiques, souvent exclus des analyses externes.
Sans cet ensemble, les modèles peuvent produire des résultats incomplets ou difficiles à actionner. Avec les données complètes, l’IA peut mieux interpréter les événements et réduire les angles morts.
Les “joyaux de la couronne” : pourquoi l’absence de données pénalise tout
Dans la plupart des entreprises, les informations les plus précieuses sont aussi celles qui sont les moins visibles pour la sécurité. Il s’agit souvent de documents métiers, de code source, de propriété intellectuelle, d’enregistrements clients ou de modèles financiers.
Or, ce sont précisément ces actifs que les attaquants ciblent en premier. Malgré cela, ces données sont fréquemment écartées des analyses de sécurité pour des raisons de confidentialité, de contraintes réglementaires ou simplement par prudence organisationnelle. Par exemple, un responsable sécurité ne sera pas toujours en mesure d’envoyer des données sensibles dans un cloud tiers.
Le problème est plus qu’un “risque juridique”. C’est aussi un problème de détection. Une IA qui n’a pas accès aux dépôts de code ne peut pas repérer facilement un clonage intégral avant un départ. Une IA qui n’a pas les modèles financiers peut manquer l’exfiltration interne d’informations liées à des projections.
Le parallèle avec une enquête financière est parlant : sans regarder les écritures, on peut continuer à enquêter, mais le vol passe inaperçu.
Complétude et souveraineté : la même exigence, deux angles
À mesure que l’on cherche des données complètes, une question devient incontournable : qui contrôle ces données et que deviennent-elles après usage ? Dès lors que l’on alimente l’IA avec du code, des modèles financiers, des dossiers clients et de la télémétrie, il faut savoir où les informations sont traitées, qui détient les résultats, quels modèles sont utilisés et quelles autorités pourraient demander l’accès.
On peut voir la complétude et la souveraineté comme deux faces d’un même besoin. D’un côté, on veut que l’IA “voie” l’essentiel. De l’autre, on doit pouvoir garantir que l’organisation conserve la maîtrise du traitement et de la production.
Cette réflexion pousse de nombreux acteurs à exiger des mécanismes qui protègent la confidentialité des données, ainsi que le contrôle sur les modèles et leurs paramètres. Pour des organisations et des États qui veulent déployer l’IA dans la sécurité, ces garde-fous deviennent des prérequis.
Le futur ne se jouera pas uniquement sur la sophistication des modèles
Dans beaucoup de discours, l’attention se porte sur la puissance des modèles d’IA. Pourtant, la différence décisive pourrait venir ailleurs : de la capacité à fournir à l’IA les données complètes, avec une fidélité élevée, un contexte opérationnel riche et, surtout, sans abandonner le contrôle.
En pratique, l’objectif est clair : éviter les analyses basées sur des fragments, réduire les angles morts nés des filtrages et des exclusions, et relier les événements pour reconstruire ce qui compte vraiment — l’intention, la chronologie et les liens entre systèmes.
Quand l’IA dispose de données complètes et que l’entreprise maîtrise le traitement, la sécurité passe d’un ensemble d’alertes à une compréhension exploitable. C’est ainsi que l’on transforme la détection en investigation plus fiable, et que l’on améliore concrètement la capacité à anticiper les attaques.
Source: https://www.securityweek.com/the-future-of-ai-driven-security-depends-on-complete-data/
