IA et cybersécurité : pourquoi le contexte compte
Découvrez pourquoi les agents d’IA peinent en cybersécurité sans contexte partagé, comment une couche de connaissance peut aider et quels points vérifier.
En cybersécurité, les agents d'IA ont besoin de comprendre votre entreprise
Les agents d'intelligence artificielle peuvent accélérer l'analyse des alertes, rapprocher des événements et décharger les équipes de tâches répétitives. Sauf qu'en entreprise, une réponse correcte ne dépend presque jamais d'un seul outil. Il faut savoir quels systèmes sont concernés, comment ils sont reliés, quelles règles internes s'appliquent et ce qui s'est déjà passé.
Ces informations sont dispersées entre des plateformes cloud, des postes de travail, des outils d'identité, des applications SaaS, des tickets et de la documentation interne. Et donner à un modèle accès à « plus de données » ne suffit pas : encore faut-il qu'il sache les relier et comprendre ce qu'elles signifient, concrètement, pour votre organisation.
Sola Security veut résoudre ça avec une couche de contexte commune aux analystes et aux agents d'IA. L'idée est intéressante, mais il faut la regarder de près : une telle infrastructure améliore-t-elle vraiment les décisions, réduit-elle les coûts et limite-t-elle les risques liés à l'autonomie ? Voici comment l'approche est présentée, ce qu'elle peut apporter, et ce qu'il vaut mieux vérifier avant de l'adopter.
Pourquoi les agents d'IA peinent-ils en cybersécurité ?
Un agent peut être très bon en langage, en programmation ou dans l'analyse de documents, et pourtant se tromper dès qu'on lui pose une question de sécurité « terrain ». Le problème ne vient pas tant d'un manque d'intelligence que du décalage entre ce qu'il sait (ou ne sait pas) et l'environnement réel.
Une alerte, prise toute seule, ne raconte pas l'histoire complète. Pour la qualifier, il faut parfois relier une identité, une machine, une application cloud, une règle interne et un incident précédent. La portée d'un compte compromis n'est pas la même selon les droits accordés, les dépendances techniques et les processus métier concernés. En clair : la cybersécurité, c'est de la relation et du contexte, pas seulement du texte ou du code.
Des données dispersées, mais aussi des connaissances absentes
Dans les grandes entreprises, on empile souvent plusieurs outils de sécurité. Chacun voit « son » morceau : terminaux, identités, cloud, etc. À côté de ces signaux techniques, il y a tout le reste - procédures, contrats, politiques, rapports d'incident, tickets et décisions d'exploitation - qui vit ailleurs.
Le souci, c'est que cette connaissance organisationnelle est rarement disponible de façon homogène. Elle peut être périmée, contradictoire, ou connue seulement de quelques personnes. Résultat : un agent qui interroge un produit peut répondre de façon précise... à une version incomplète du problème. Et même si un SIEM centralise certains événements, il ne reconstitue pas forcément les liens utiles, ni n'intègre vraiment les règles métier.
Pourquoi multiplier les copilotes ne règle pas tout
Les éditeurs ajoutent des assistants dans leurs produits. C'est pratique, mais chaque assistant reste généralement enfermé dans la vision de son outil. Celui qui observe les terminaux ne connaît pas forcément la politique d'accès aux applications SaaS, ni l'importance métier d'un serveur exposé.
Et quand on multiplie les agents, on crée parfois des réponses qui ne s'alignent pas : sources différentes, contexte reconstruit autrement, conclusions qui divergent. Le problème n'est donc pas uniquement « le bon modèle » ou « le plus puissant ». Il faut surtout des informations pertinentes, cohérentes et traçables au moment où une décision est prise.
Dans ce que présente Sola Security, Ron Peled (cofondateur) résume bien le décalage : la sécurité repose sur les relations, les dépendances et les connexions, pas uniquement sur le texte ou le code. C'est une distinction utile pour les équipes sécurité : un modèle peut raisonner correctement avec ce qu'il reçoit... tout en passant à côté de la réalité si un élément décisif manque.
Quels bénéfices peut-on attendre, et à quelles conditions ?
Le bénéfice opérationnel le plus crédible, c'est la réduction du temps passé au rapprochement. Quand une alerte touche plusieurs systèmes, un analyste passe souvent du temps à retrouver les éléments, vérifier les dépendances et consulter les procédures internes. Si une couche commune fournit ces éléments avec des références vérifiables, l'équipe peut consacrer davantage d'énergie à l'analyse et à la décision.
Mais ce gain n'est pas automatique. Tout dépend de la couverture des sources, de la qualité des connecteurs, de la fraîcheur des données et de la capacité de l'organisation à maintenir sa documentation. Une couche qui centralise des informations obsolètes ne rendra pas les réponses plus fiables : elle peut juste rendre l'erreur plus rapide... donc potentiellement plus convaincante.
Cohérence des réponses et gouvernance des agents
Un contexte commun peut limiter les écarts entre agents qui utilisent des outils différents. Il facilite aussi l'audit : les équipes peuvent remonter à ce qui a contribué à une réponse, plutôt que de traiter chaque agent comme une boîte noire isolée.
Pour que cette cohérence existe vraiment, il faut fixer des règles claires : quelles sources font autorité, comment gérer les contradictions, à quelle fréquence actualiser les données, et comment signaler quand une information manque. Sans ces garde-fous, la plateforme risque de « lisser » les désaccords au lieu de les résoudre.
Les permissions comptent autant. Une architecture centralisée devient un point d'accès sensible. Il faut donc vérifier les droits par rôle, séparer les périmètres, journaliser les requêtes et prévoir des mécanismes de révocation. Le fait d'être en lecture seule ne veut pas dire que l'agent doit pouvoir tout lire.
Le chiffre de 70 % : une hypothèse à tester chez vous
Sola affirme que son approche peut réduire d'environ 70 % le nombre de requêtes adressées aux modèles, en préparant le contexte en amont plutôt qu'en le reconstruisant à chaque demande. L'entreprise avance aussi que cela peut éviter de mobiliser une équipe dédiée à l'ingénierie du contexte.
Ces chiffres restent des affirmations de l'éditeur, pas une garantie universelle. Les résultats dépendent du volume de requêtes, des modèles utilisés, du coût des connecteurs et du travail nécessaire pour nettoyer et maintenir les données. Et oui : préparer le contexte en continu a aussi un coût. Ce sera probablement rentable si le contexte sert souvent, moins si vous l'utilisez de manière ponctuelle.
La comparaison utile, c'est le coût complet : temps d'analyse économisé, consommation des modèles, intégration, exploitation, contrôle, correction des erreurs. Pour un pilote, mesurez a minima le délai de qualification, le nombre de sources réellement consultées, le taux de réponses vérifiables, et les cas où un analyste doit reprendre entièrement l'investigation.
Comment évaluer cette approche dans une entreprise ?
La bonne question n'est pas « est-ce qu'on a besoin d'un cerveau pour l'IA ? ». La question, c'est : est-ce que vos équipes perdent du temps à relier des sources, et est-ce que cette friction abîme la qualité des décisions. Autrement dit : partez d'un processus observable, pas d'une promesse d'autonomie.
Choisir un cas d'usage mesurable
Commencez par un scénario fréquent, plutôt coûteux, et suffisamment circonscrit : qualification d'une alerte d'identité, investigation d'un poste compromis, ou analyse d'un changement cloud suspect. Clarifiez aussi le périmètre des outils nécessaires et ce que l'agent est censé soutenir comme décisions.
Avant de lancer le pilote, définissez une mesure de référence. Combien de temps faut-il aujourd'hui pour réunir les preuves ? Combien de systèmes sont consultés ? Quelle proportion des alertes est requalifiée après examen ? Le but est d'évaluer un progrès réel, pas seulement une démo « qui a l'air bien ».
Vérifier les preuves, les limites et les coûts cachés
Demandez à voir comment la réponse est construite. L'outil peut-il identifier les sources utilisées, distinguer un fait d'une hypothèse, et signaler quand une information est absente ou contradictoire ? Les analystes doivent pouvoir remonter aux éléments d'origine et corriger une donnée erronée. Une réponse fluide sans provenance vérifiable ne prouve pas la fiabilité.
Regardez aussi la couverture réelle : quels systèmes sont connectés, avec quels droits, et à quelle fréquence les informations sont-elles mises à jour. Évaluez enfin les coûts d'intégration et d'exploitation : charge de maintenance des connecteurs, impact si la couche de contexte devient indisponible. L'objectif n'est pas de remplacer des silos par une dépendance centrale mal gouvernée.
Enfin, fixez dès le départ les conditions pour arrêter ou étendre le pilote. Étendez si les réponses sont traçables, les gains mesurés, les risques maîtrisés. Réduisez ou stoppez si les données sont trop incomplètes, si les erreurs sont difficiles à détecter, ou si le coût opérationnel dépasse le temps économisé.
Cette prudence vaut aussi pour les projets d'IA au sens large : une couche de contexte peut être une brique utile, mais elle ne remplace pas une stratégie de sécurité. Elle doit s'inscrire dans une architecture de contrôle, des responsabilités clairement attribuées, et des procédures de réponse aux incidents compréhensibles par les équipes.
Conclusion : rendre l'IA utile avant de la rendre autonome
L'approche de Sola Security met le doigt sur un point simple : un agent n'aide vraiment une équipe sécurité que s'il comprend plus qu'une fraction de l'environnement. Relier les données des outils aux dépendances et aux connaissances internes peut améliorer l'investigation, la cohérence des réponses et la gouvernance des usages.
Mais une couche de contexte ne garantit ni la justesse des conclusions ni la conformité de l'architecture. La qualité des sources, la traçabilité, la gestion des droits et le coût total restent déterminants. Avant de multiplier les agents, choisissez un cas d'usage mesurable et vérifiez si le contexte partagé améliore réellement le travail des analystes. C'est à cette condition que l'infrastructure devient un avantage opérationnel, plutôt qu'un nouvel ensemble à maintenir.
Comment fonctionne une couche de contexte de sécurité ?
Sola Security décrit son produit comme un « cerveau de sécurité » d'entreprise, indépendant des fournisseurs. L'objectif n'est pas de remplacer les outils existants, mais de rapprocher leurs données et la connaissance interne pour obtenir une image plus cohérente de l'environnement.
La plateforme vise à couvrir plusieurs domaines - cloud, terminaux, identités, applications SaaS et agents de programmation - puis à relier les entités et leurs dépendances. L'idée est simple : permettre à un analyste ou à un agent de poser une question qui implique plusieurs systèmes, sans devoir refaire tous les rapprochements manuellement.
Une représentation partagée plutôt qu'une suite de recherches
Dans une architecture plus classique, un agent reçoit une demande, va chercher des informations dans plusieurs sources, puis tente de reconstruire le contexte « à la volée ». C'est flexible, mais ça peut coûter cher, et la qualité dépend beaucoup des sources interrogées et de leur disponibilité.
L'approche décrite par Sola consiste aussi à préparer en continu des informations jugées prioritaires. Au lieu d'attendre chaque requête, la plateforme maintient un contexte mobilisable ensuite par les équipes et les agents. Si les données intégrées sont fiables et bien tenues à jour, cela peut améliorer à la fois la vitesse et la cohérence des réponses.
Ce que l'entreprise met en avant, c'est la combinaison de données techniques, de connaissances organisationnelles et d'éléments issus de la recherche en sécurité. Ce n'est pas « juste » une centralisation : ce qui compte, c'est la capacité à faire ressortir les bons liens, conserver les preuves, et signaler les zones où l'information manque ou reste incertaine.
Une couche de connaissance n'est pas une autorisation d'agir
Sola présente aussi son architecture comme une couche d'intelligence en lecture seule. Autrement dit, l'objectif est de donner aux agents les informations nécessaires, sans leur attribuer directement des identifiants de production ni des droits d'action très étendus.
La séparation est logique : comprendre un environnement et le modifier ne sont pas le même niveau de risque. Un agent qui peut lire des données peut déjà exposer des informations sensibles ou interpréter quelque chose de travers. Le mode lecture seule réduit certains risques d'action, mais il ne remplace pas la gestion des accès, la journalisation, ni le contrôle strict de ce qui est consulté.
Pour un déploiement en France ou dans l'Union européenne, il faut notamment passer au crible la nature des données traitées, leur conservation, les accès des sous-traitants et les exigences liées au RGPD. Selon le secteur, d'autres contraintes de gouvernance ou de résilience peuvent s'ajouter. Et surtout : la seule architecture ne permet pas de conclure qu'un produit répond automatiquement à toutes ces obligations.