ATS26 Lyon (03/11) : prépare ta matinée « IA & cyber » et repars avec un plan, pas des slides

Tu viens pour des décisions, pas pour de la veille passive

Une matinée « IA & cyber », c’est souvent sympa, parfois brillant… et trop souvent inutilisable le lundi d’après. Le piège est simple : tu repars avec des idées, des mots-clés, deux démos, et aucun arbitrage. Or côté RSSI et décideurs IT, le sujet est déjà chaud : l’IA est partout dans les offres sécurité, mais son intégration réelle dans les workflows SOC reste incomplète.

Quelques chiffres posent le décor. D’après la SANS SOC Survey (15 juin 2026), 79% des SOC déclarent utiliser des outils IA/ML, mais seulement 36% les ont intégrés dans un workflow SOC défini. D’après la SANS AI Survey 2026, 78% des organisations disent utiliser activement l’IA en cybersécurité, mais seulement 27% estiment être « matures en production ». Le message est limpide : ce n’est plus un sujet “gadget”, c’est un sujet d’industrialisation.

Le 3 novembre, ATS26 Lyon se positionne justement sur ce croisement « IA & cyber ». Si tu y vas, ton objectif doit être net : repartir avec 2 à 3 cas d’usage cadrés, une liste de décisions à prendre, et un backlog réaliste à 30 jours.

ATS26 Lyon : les faits (et comment exploiter le format)

ATS26 Lyon est annoncé comme une matinée en deux temps autour des enjeux de l’IA en cybersécurité, co-animée par SaxX (hacker éthique et vulgarisateur). Source : page événement Arrow.

• Date : mardi 3 novembre, 9h00-14h00
• Lieu : La Bulle Workplace, salle « la source », 3 rue Fénelon, 69006 Lyon
• Trame publiée : accueil, démo de hacking éthique, défi « Security & AI », table ronde, sessions interactives partenaires, cocktail déjeunatoire

Ce déroulé est utile si tu le lis comme un plan de collecte :

• Démo : tu captes les scénarios d’attaque et les angles de défense concrets.
• Défi / interactif : tu testes tes hypothèses de cas d’usage et tu compares les approches.
• Table ronde : tu poses les questions qui fâchent (données, conformité, MCO, dette technique).
• Cocktail : tu verrouilles 2 rendez-vous de suivi (pas 12 cartes de visite).

Ce qu’une matinée « IA appliquée à la cybersécurité » couvre typiquement

Pour un décideur IT ou un RSSI, l’intérêt n’est pas “l’IA” en général. L’intérêt, c’est l’effet sur ton exploitation sécurité. Typiquement, tu peux t’attendre à 4 blocs.

1) Détection et SOC : réduire le bruit sans perdre la couverture

Le SOC souffre rarement d’un manque d’alertes. Il souffre d’un manque de signal exploitable. L’IA est souvent vendue comme une machine à corréler, regrouper et accélérer le triage.

• Corrélation multi-sources (SIEM, EDR, cloud, IAM, proxy, DNS).
• Réduction du bruit : regroupement d’alertes similaires, déduplication, suppression de faux positifs connus.
• Triage assisté : résumé automatique, hypothèses de cause, next steps.
• Couverture hybride : environnements on-prem, cloud, SaaS, postes nomades.

Le point dur à valider sur place : où s’insère l’IA dans TON workflow (et pas dans une démo). Si ça ne s’intègre pas à l’escalade, au ticketing, et aux règles de clôture, tu vas juste empiler un outil de plus.

2) Priorisation : traiter ce qui compte, pas ce qui crie le plus fort

Deux “piles” explosent en entreprise : les alertes et les vulnérabilités. L’IA est souvent utilisée pour passer d’une logique « on voit tout » à « on traite ce qui compte maintenant » via la contextualisation :

• criticité métier de l’actif
• exposition Internet et chemins d’attaque
• exploitabilité, signaux de menace, exploitation active
• dépendances applicatives

Ce bloc est clé si tu veux un plan à 30 jours : la priorisation est le levier le plus rapide pour réduire le risque sans promettre une révolution d’architecture.

3) Automatisation : SOAR, runbooks, humain dans la boucle

L’IA en cyber devient intéressante quand elle déclenche de l’action. Mais l’automatisation en sécurité sans garde-fous, c’est une source d’incidents internes.

• Orchestration : enchaîner enrichissements, vérifications, création de ticket, notifications.
• Réponses semi-automatiques : blocage, isolation, reset, désactivation, mais avec validation humaine.
• Runbooks : standardiser ce qui est répétitif et documenter les exceptions.

Le test simple : si on te décrit une “réponse automatique”, demande immédiatement qui valide, quand, et comment on revient en arrière.

4) Sécuriser l’IA en entreprise : gouvernance et menaces spécifiques

Ne mélange pas deux sujets. Il y a :

• IA pour le SOC : améliorer détection, triage, réponse.
• Sécuriser l’IA en entreprise : gouvernance, risques IA, attaques visant les systèmes IA, contrôle des accès, traçabilité.

Ce deuxième volet monte vite, surtout avec des assistants et des agents qui touchent aux données et aux outils. Si tu veux creuser ce point avant ATS26, tu peux partir de deux bases utiles publiées sur Lyon IA : Sécuriser vos LLM en production : menaces et parades et Injection de prompt : la faille que les entreprises sous-estiment.

Arriver avec 2 à 3 cas concrets : le format qui marche (et qui tient en une page)

Si tu débarques “pour voir”, tu repars “avec des slides”. Si tu débarques avec 2 à 3 cas, tu repars avec des arbitrages. Garde le format suivant : problème, cible, données, KPI, risque, effort 30 jours.

Cas 1 : Triage et réduction du bruit dans le SOC

• Problème : trop d’alertes, fatigue analyste, backlog, triage lent.
• Cible : classification, regroupement, enrichissement automatique, résumé “lisible humain”.
• Données : flux SIEM, EDR, logs cloud, CMDB (ou inventaire), ticketing.
• KPI : temps moyen de triage, taux de faux positifs, backlog d’alertes, MTTA.
• Risque : IA qui masque un signal, manque de traçabilité, dérive du modèle.

Cas 2 : Priorisation vulnérabilités et exposition “risque métier”

• Problème : des milliers de CVE, arbitrages impossibles, patching inefficace.
• Cible : priorisation contextualisée (criticité, exposition, exploitabilité, dépendances).
• Données : scan vulnérabilités, inventaire actifs, carto applis, identité, exposition Internet.
• KPI : time-to-remediate sur top risques, couverture des actifs critiques, réduction du “vuln backlog utile”.
• Risque : scoring opaque, responsabilité floue quand l’outil “recommande”.

Pour un angle local concret, Lyon a un acteur très identifié sur ce sujet : Hackuity (Lyon) lève 19 M$ : 6 leçons pour industrialiser l’IA en gestion des vulnérabilités. Même si tu n’achètes rien, l’article te donne une grille utile : industrialisation, intégration, métriques, dette opérationnelle.

Cas 3 : Automatisation contrôlée des réponses (semi-auto)

• Problème : runbooks manuels, escalades lentes, tâches répétitives.
• Cible : orchestration (SOAR), actions “human-in-the-loop”, standardisation.
• Données : alertes, tickets, annuaire/IAM, EDR, outils ITSM, référentiels.
• KPI : temps de confinement, taux d’actions automatisées validées, incidents réouverts.
• Risque : automatiser trop large, droits excessifs, erreurs non réversibles.

Si tu touches aux agents (qui appellent des outils), lis aussi : Sécuriser un agent IA qui a accès à vos outils et Agents IA en production : les cinq garde-fous à poser.

Questions à poser sur place : données, conformité, industrialisation (le trio qui décide tout)

Tu veux éviter les réponses floues. Pose des questions qui obligent à parler architecture, responsabilité et exploitation.

Données : ce que l’IA exige vraiment

• Sources minimales : lesquelles sont indispensables (SIEM, EDR, IAM, cloud, ticketing) ? Lesquelles sont optionnelles ?
• Qualité : quels champs doivent être propres (horodatage, user, hostname, asset ID, sévérité, mapping MITRE) ? Quel taux d’événements incomplets est toléré ?
• Normalisation : est-ce que ça marche si mes logs ne sont pas normalisés ? Qui fait le boulot, toi ou l’éditeur ?
• Feedback loop : comment le SOC réinjecte ses décisions (true positive, false positive, “benign”) ?
• Drift : comment on détecte la dérive (nouvelles applis, nouvelles règles, migration SIEM) ?

Conformité et maîtrise : “où tournent les modèles, où vont les logs”

• Hébergement : où tournent les modèles (UE, France, hors UE) ? Quelles garanties contractuelles ?
• Données sensibles : est-ce que les logs, identifiants, extraits de payload peuvent sortir ? Peut-on filtrer, anonymiser, pseudonymiser ?
• Conservation : combien de temps sont conservées les données envoyées au moteur IA ? Par défaut, et configurable ?
• Traçabilité : est-ce que je peux expliquer pourquoi l’IA a proposé une action ou une priorité ? Est-ce journalisé ?

Pour te mettre en tête les bons réflexes “données et gouvernance”, tu peux t’appuyer sur : RGPD et IA en entreprise : ce que vous pouvez faire, ce que vous ne pouvez pas et Écrire une politique de conservation des données pour ses outils IA.

Industrialisation : le vrai sujet (MCO, coûts, responsabilités)

• Workflow SOC : à quel moment l’IA intervient (avant triage, pendant, après) ? Qu’est-ce qui change dans les règles de clôture ?
• Intégrations : ITSM (ServiceNow, Jira…), SIEM, EDR, IAM. Natif, API, connecteurs ? Délais réalistes ?
• Run : qui maintient les modèles, les prompts, les règles, les connecteurs ? Quel RACI ?
• Mesure : quels KPI “avant/après” pour prouver que ça marche (et couper si ça ne marche pas) ?
• Coûts : licence, ingestion, compute, stockage, et surtout coût d’intégration. Où est la zone de surprise ?

Mini-kit avant, pendant, après : transforme ATS26 Lyon en backlog sécurité à 30 jours

Objectif : sortir d’ATS26 Lyon avec un plan simple, défendable, exécutable. Pas une “stratégie IA cyber” de 40 pages.

Avant (J-7 à J-1) : préparation en 45 minutes

• 1 objectif unique : “réduire le backlog d’alertes”, ou “prioriser vulnérabilités”, ou “automatiser 2 runbooks”. Pas les trois.
• 2 à 3 cas (ceux au-dessus), chacun sur une page, avec KPI.
• Ta baseline : 3 chiffres actuels (exemple : nombre d’alertes/jour, temps moyen de triage, backlog vulnérabilités).
• 3 contraintes non négociables : hébergement, données qui ne sortent pas, traçabilité, ou autre.
• 1 liste de systèmes : SIEM, EDR, IAM, ITSM, cloud, CMDB. Juste les noms. Pour parler intégration concret.

Si tu veux cadrer “POC vers run” sans te raconter d’histoires, garde sous la main cette checklist : Industrialiser l’IA en DSI à Lyon : la checklist POC vers run. Oui, c’est orienté IA au sens large, mais les questions d’industrialisation sont les mêmes en cyber.

Pendant (9h-14h) : collecte orientée décision

• Pendant la démo : note les signaux utilisés (logs, identité, réseau), et ce qui déclenche l’escalade. Pas la mise en scène.
• Pendant la table ronde : pose au moins 2 questions sur données et run. Si tu n’oses pas, tu perds ta matinée.
• Dans les sessions interactives : demande une architecture type (schéma simple), puis demande “qui opère ça au quotidien”.
• Au cocktail : verrouille 2 suivis maximum, avec une question précise à traiter (exemple : “peux-tu valider l’intégration ITSM et la journalisation des actions ?”).

Après (J+1 à J+30) : backlog réaliste, preuve rapide, pas de tunnel

Voici un plan 30 jours que tu peux adapter, même avec une équipe petite.

• J+1 : écris une note d’une page. Problème, hypothèse de solution, systèmes impactés, risques, KPI. Point.
• Semaine 1 : atelier 60 minutes SOC + IT + RSSI. Choix du cas prioritaire. Définition du “done” d’un pilote.
• Semaine 2 : check données. Qualité des logs, champs manquants, accès, conservation. Tu corriges 2 irritants rapides.
• Semaine 3 : pilote limité (périmètre restreint, human-in-the-loop). Mesure “avant/après” sur 1 KPI.
• Semaine 4 : décision. On étend, on corrige, ou on stop. Et tu écris le backlog des 3 prochaines briques.

Pour objectiver le gain sans te faire balader, appuie-toi sur : Mesurer le gain réel d’un usage IA : la méthode avant / après. Ça t’aide à sortir du “ça a l’air mieux”.

Ce que tu dois viser en sortant d’ATS26 Lyon

Si ta matinée est rentable, tu dois pouvoir formuler ces trois sorties, clairement :

• 2 à 3 cas d’usage classés par valeur et faisabilité, avec un KPI chacun.
• Une check-list données et conformité : sources, qualité, conservation, hébergement, traçabilité.
• Une liste de décisions : périmètre du pilote, intégrations nécessaires, humain dans la boucle, critères de stop/go.

Et si tu veux rester lucide sur le risque “agents et automatisation qui partent en vrille”, garde une lecture rapide en tête : Agents IA et cybersécurité : effacement de traces, audit des logs et accès avant d’automatiser.

Ton plan simple pour ATS26 Lyon : une page, trois décisions

Avant de partir à ATS26 Lyon, écris ta page. Pendant, tu la complètes. Après, tu l’exécutes.

• Décision 1 : quel cas d’usage unique tu lances sur 30 jours (triage, priorisation, automatisation) ?
• Décision 2 : quelles données tu acceptes de mobiliser, avec quel niveau de contrôle et de conservation ?
• Décision 3 : quel niveau d’automatisation tu autorises (et où tu imposes l’humain dans la boucle) ?

Avec ça, tu ne “fais pas de l’IA”. Tu fais de la sécurité qui avance. Et c’est exactement ce que tu veux obtenir d’une matinée « IA cybersécurité Lyon » comme ATS26 Lyon.

Sources : annonce et informations pratiques ATS26 Lyon (Arrow) : https://www.arrow.com/globalecs/fr/regional-pages/ressources/events/ats26-lyon/ ; SANS SOC Survey 2026 (15 juin 2026) ; SANS AI Survey 2026 ; ANSSI étude de marché « IA pour la détection et la réponse » (juillet 2025, extension février 2026) : https://cyber.gouv.fr/nous-connaitre/publications/etude-de-marche/etude-de-marche-ia/