Parce que… c’est l’épisode 0x356!

Shameless plug

• 13 et 14 novembre 2026 - Worldwide - DEATHCon
• 16 au 19 novembre - Rennes, France - European Cyber Week 2026
• 25 et 26 février 2027 - Québec, Canada - SéQCure 2027
• 9 au 11 mars 2027 - Lilles, France - Forum INCYBER - Europe 2027
• I.A. Café - Enquête au cœur de la recherche sur l’intelligence artificielle
• 16 novembre 2026 - Paris, France - CNIL - Convaincre ou manipuler ? L'éthique du numérique à l'épreuve des urnes
• Boostsecurity - Dazio

Description

Cette description a été faite à l’aide de GLM 5.3 Flash, à partir de la transcription qui a été effectuée par ElevenLabs Scribev2. Aucune vérification humaine n’a été faite. Si vous découvrez des erreurs ou des inexactitudes, vous pouvez m’en faire part afin que je procède aux modifications appropriées.

Présentation de l’invité et contexte

Dans cet épisode spécial BSides du Polysecure, Nicolas reçoit Pierre Collard, qui dirige les équipes de détection et de réponse chez Sopra Steria pour le périmètre Canada et États-Unis. Sopra Steria est une société européenne de transformation numérique en pleine expansion en Amérique du Nord qui accompagne des clients de tailles et de secteurs variés, allant de l’assurance aux municipalités en passant par de grands groupes automobiles. Pierre est venu présenter au BSides, ainsi qu’à GoSec, un sujet portant sur la modernisation du SOC et la place réelle de l’intelligence artificielle dans les opérations de cybersécurité.

La promesse de l’IA face à la réalité du terrain

Pierre constate un consensus clair sur le potentiel de l’intelligence artificielle, mais souligne que la majorité des clients, petits comme grands, ne disposent pas encore de la maturité opérationnelle ni de la gouvernance nécessaires pour déployer des outils gérés par l’IA à grande échelle. Les données ne sont souvent ni fiables ni structurées et les processus manquent de clarté. Contrairement au discours marketing qui promet de trier le désordre existant, Pierre soutient que ce désordre doit être organisé en amont avant qu’une intelligence artificielle puisse générer une valeur réelle. L’IA n’est pas un outil magique, et sans les informations adéquates, elle ne livrera que la performance standard de la solution, mal alignée avec les enjeux business.

Le cycle de vie d’un incident et les limites de l’autonomie

Pierre décompose le cycle de vie d’un incident en trois phases. La détection génère les alertes, l’investigation consiste à corréler les événements, enrichir les cas et comprendre la situation, puis vient la décision, où l’on détermine quoi faire de cette information. Sur les deux premières phases, l’IA apporte déjà des gains notables en accélérant l’ingénierie de la détection, la gestion des signaux faibles, la création de rapports et l’enrichissement. Cependant, la partie décision reste problématique. Déléguer des actions à un agent ne transfère pas la responsabilité, qui demeure du côté des équipes de sécurité. Ce niveau de confiance requis pour une autonomie complète n’est pas encore atteint dans la plupart des organisations.

Trois prérequis pour brancher l’IA utilement

Pierre identifie trois éléments essentiels. Le premier est le contexte, c’est-à-dire donner à l’agent les informations qui permettent de comprendre ce que l’entreprise considère comme malveillant, selon son environnement, ses enjeux et son historique. Le deuxième est l’historique, qui consiste à corroborer une hypothèse avec les incidents passés et les décisions qui avaient été prises, notamment via une intégration à un outil ITSM, ce qui suppose une hygiène de gestion rigoureuse. Le troisième est l’autorité, soit la délimitation de ce qu’on délègue ou non à l’agent selon la criticité du cas d’usage et la capacité à revenir en arrière. Certains cas tolèrent un niveau de confiance de 60 à 70 pour cent, tandis que d’autres, comme la mise hors ligne d’une production, exigent une certitude proche de 99 pour cent avec un humain dans la boucle.

Mesure de l’efficacité et qualité des données

Pour évaluer les agents, l’équipe de Pierre s’appuie sur plusieurs métriques, dont le taux d’accord sur les décisions recommandées, la capacité de l’agent à retrouver des preuves contextuelles, le taux d’actions non sécurisées et l’analyse coût-performance. Les tests se font principalement en interne, via des campagnes avec des critères précis, puisque la majorité des clients n’en sont qu’à utiliser les fonctionnalités IA fournies avec leurs outils existants. Concernant les données, Pierre recommande un modèle de données clair avec des champs critiques, dont le raisonnement suivi par l’agent et le contexte utilisé, sans exiger une CMDB parfaitement propre avant de démarrer les preuves de concept. Il estime par ailleurs que les efforts de gouvernance et d’assurance qualité autour d’un agent représentent deux à trois fois les efforts de sa mise en place initiale.

Un exemple concret de l’importance du contexte

Pierre illustre son propos avec une alerte de détection de clé USB ou de fichier malveillant. Pour une entreprise dont la politique interdit les supports amovibles et où l’alerte provient d’un VIP du département des finances, l’incident sera ouvert et escaladé avec isolement de l’hôte. Pour une autre entreprise où l’usage quotidien des supports amovibles est accepté et où les données sont moins sensibles, le contrôle aura simplement fonctionné sans ouverture d’incident. Le même contexte technique peut donc produire des décisions diamétralement opposées selon le contexte opérationnel, et c’est précisément ce type d’information qu’il faut transmettre aux agents.

L’évolution du rôle de l’analyste

Les tâches techniques sont de plus en plus automatisées et le rôle de l’analyste se transforme vers la vérification, l’encadrement des agents, la gestion des identités et des exceptions, et la gouvernance du contexte fourni. Pierre prend l’exemple de la fonction XDR Attack Disruption de Microsoft, qui agit de façon autonome sans playbook manuel, les analystes vérifiant ensuite les actions et documentant les exceptions. Il nuance toutefois l’idée d’un simple décalage latéral des compétences. Selon lui, l’expertise technique doit rester présente, avec en plus des compétences en gestion de l’IA et en gouvernance, ce qui élève le point d’entrée de l’échelle d’un cran plutôt qu’il ne le décale sur le côté. Cela rend l’intégration de profils juniors plus difficile et nécessitera à terme des formations plus structurées et explicites pour maintenir les compétences.

Le SOC du futur et le modèle économique

Pierre décrit un changement du centre de gravité du SOC. Là où l’analyste était historiquement le goulot d’étranglement, l’organisation de demain verra les humains concevoir l’architecture et le service, les agents réaliser les investigations et les recommandations, et des garde-fous statiques comparer ces recommandations à la politique de sécurité. La valeur ajoutée des offres se recentre sur les résultats cybersécurité plutôt que sur le simple nombre d’analystes facturés, ce qui devrait transformer en profondeur le marché du MDR.

La question des coûts

La dimension financière constitue une troisième dimension à ajouter à la criticité et à la capacité de retour en arrière. Les coûts sont plus variés qu’avant, incluant l’inférence, le stockage, les requêtes de données volumineuses, la vérification et le travail humain de contrôle. Pierre propose trois types de réponses, soit conserver les playbooks SOAR statiques pour les processus simples, limiter l’IA au rôle prescriptif de recommandation, ou accorder l’autonomie à l’IA sur des cas d’usage précis. Tous les cas d’usage ne justifient pas la complexité et les coûts d’un outil IA. Le marché se trouve encore dans une phase d’exploration et de curiosité, où les coûts passent au second plan, plutôt que dans un mode croisière avec des garde-fous financiers établis.

Contributeurs

Nicolas-Loïc Fortin	pierrecollard

Crédits

• Montage par Intrasecure inc
• Locaux virtuels par Riverside.fm

Tags: bsidesmtl, ia, soc