ATS26 Lyon (03/11) « Security & AI » : 10 questions pour sécuriser GenAI et agents IA

Tu vas à ATS26 Lyon « Security & AI » ? Viens avec une grille d’audit, pas des slides

La plupart des projets GenAI en entreprise se plantent au même endroit. Pas sur le modèle. Sur l’exploitation. Accès trop larges, logs inutilisables, données sensibles qui partent dans les prompts, intégrations bricolées, gouvernance floue. Et quand tu ajoutes des agents IA, tu ajoutes un truc simple : une IA qui agit. Donc une surface d’attaque et un risque opérationnel en plus.

Le 3 novembre 2026, ATS26 Lyon propose une matinée « Security & AI » à Lyon, co-animée par SaxX, autour des enjeux IA et cyber. C’est un bon format pour tester tes hypothèses sur du concret. Accueil, démo de hacking éthique, défi « Security & AI », table ronde, sessions interactives partenaires, puis cocktail déjeunatoire. Source et détails pratiques : Arrow ECS.

Infos vérifiables : mardi 3 novembre 2026, 9h00-14h00. Lieu : La Bulle Workplace (salle « la source »), 3 rue Fénelon, 69006 Lyon. Source : arrow.com.

Le contexte est connu : on “utilise” l’IA, mais on ne l’industrialise pas. Des enquêtes SANS citées dans notre analyse pré-événement indiquent que 79% des SOC déclarent utiliser des outils IA/ML, mais 36% seulement les ont intégrés dans un workflow SOC défini, et que 78% des organisations disent utiliser activement l’IA en cybersécurité, mais 27% seulement se jugent matures en production. Moralité : si tu veux de la valeur, tu dois obtenir un workflow opéré, auditables, gouverné. Pas une démo.

Voici une grille simple, en 10 questions, à dérouler sur place. L’objectif n’est pas d’avoir toutes les réponses en 3 heures. L’objectif, c’est de repartir avec 2 ou 3 cas d’usage cadrés, une liste de décisions, et un backlog sécurité à 30 jours.

Avant tout : tu parles de quoi exactement ? « IA pour le SOC » vs « sécuriser l’IA »

À ATS26, tu vas entendre les deux, parfois mélangés. Sépare-les.

• IA pour le SOC : détection, triage, investigation, aide à la réponse, génération de playbooks, synthèse d’alertes.
• Sécuriser l’IA en entreprise : risques liés aux systèmes GenAI, attaques visant les LLM et les couches RAG, contrôle des accès, traçabilité, gouvernance, conformité.

Tu peux faire les deux. Mais si tu mélanges, tu repartiras avec des réponses qui ne collent pas à tes contraintes.

La grille d’audit « sécurité GenAI entreprise » à dérouler à ATS26 Lyon

Structure-la comme un audit rapide : identité et accès, journaux, données sensibles, intégrations, évaluation, red teaming, gouvernance. Tu poses la question, tu écoutes, puis tu demandes la preuve ou le mécanisme concret. Si on te répond “on peut”, “on sait”, “c’est prévu”, tu relances : “où, comment, avec qui, dans quel outil, et qui valide ?”.

1) Identité et accès : qui s’authentifie où, et comment ?

Question à poser : qui s’authentifie où, et comment, sur toute la chaîne GenAI ?

• SSO et MFA partout où c’est possible.
• Comptes humains vs comptes de service (agents, connecteurs, jobs).
• Séparation prod et hors prod (vraie séparation, pas juste “un autre workspace”).
• Gestion des secrets : qui crée, où ça vit, rotation, révocation.

Pourquoi tu t’en fous pas : dans beaucoup de boîtes, l’IA démarre “en équipe projet” et finit avec des clés API qui traînent dans un outil d’automatisation ou dans un repo. Le jour où ça fuit, tu ne sais même pas quoi révoquer.

2) Least privilege : quels droits minimaux pour tes agents IA ?

Question à poser : quels droits minimaux donnes-tu à un agent IA, et comment tu limites ses actions ?

• Permissions API au strict nécessaire.
• Allowlist d’actions autorisées (et pas “accès admin parce que c’est plus simple”).
• Validation humaine sur les actions à impact (paiement, suppression, modification de droits, push en prod).
• Garde-fous : blocage, escalade, “humain dans la boucle”.

Point dur : l’automatisation sans garde-fous génère des incidents internes. Les agents IA ne “piratent” pas forcément, ils font des conneries à grande vitesse.

3) Logs : qu’est-ce qui est journalisé, où, et combien de temps ?

Question à poser : qu’est-ce qui est loggé exactement sur un usage GenAI et sur un agent IA ?

• Prompts et réponses, avec masquage si nécessaire.
• Appels outils (tool calls), actions effectuées, résultats.
• Décisions automatiques : pourquoi ça a escaladé, clôturé, refusé.
• Changements de configuration, erreurs, latence.
• Tokens, coûts, quotas (oui, c’est aussi un sujet sécurité).

But : audit, preuve, forensic. Si tu ne peux pas retracer, tu ne maîtrises pas.

À relier si tu veux creuser le sujet après : Tracer les décisions prises avec l'aide d'une IA.

4) Rejouabilité : peux-tu rejouer une décision et reconstituer le contexte ?

Question à poser : si un agent IA fait une action douteuse, peux-tu rejouer le scénario et comprendre “pourquoi” ?

• Version du modèle, paramètres, policies.
• Données entrantes et documents RAG utilisés.
• Outils appelés, réponses des outils, timing.
• Chaîne de décision : étapes, scores, seuils.

Ce que tu cherches : une capacité d’analyse post-incident. Pas juste un transcript incomplet.

5) Données sensibles : quelles données sont autorisées dans les prompts et dans le RAG ?

Question à poser : quelles données ont le droit d’entrer dans un prompt, et quelles données ont le droit d’alimenter tes bases RAG ?

• Classification : PII, secrets d’affaires, données client, données RH.
• Masquage et anonymisation (automatique si possible, contrôlable sinon).
• Règles anti-exfiltration : DLP, filtres, politiques de partage.
• Conditions d’hébergement selon la sensibilité.

Si tu as besoin d’un rappel opérationnel : Anonymiser ses données avant de les envoyer à un modèle et Shadow AI : quand vos équipes utilisent des IA sans vous le dire.

6) Flux et sous-traitants : où vont les données et les logs, vraiment ?

Question à poser : où partent les données, où partent les logs, et qui y a accès ?

• Localisation (région d’hébergement), transferts, sous-traitants.
• Multi-tenant : cloisonnement, isolation, audits.
• Politique de conservation, y compris sur les traces de conversation.
• Accès support éditeur : encadré, tracé, révocable.

Astuce : demande un schéma de flux. Si personne ne peut te le dessiner en 2 minutes, c’est que personne ne le maîtrise.

Pour cadrer côté conservation : Écrire une politique de conservation des données pour ses outils IA.

7) Intégrations : quelles intégrations opérables, pas juste une démo ?

Question à poser : où l’IA s’insère dans ton workflow existant, avec tes outils, et avec quelles règles de passage de relais ?

• ITSM et ticketing (création, enrichissement, assignation, clôture).
• SIEM, EDR, cloud logs, IAM, proxy, DNS.
• Règles d’escalade : quand l’IA agit, quand elle propose, quand elle s’arrête.
• Mesure : temps gagné, qualité, faux positifs, charge analyste.

Le piège : empiler un outil IA. Le sujet, c’est le workflow SOC ou RUN, opéré et auditable. Sinon tu auras de la “valeur perçue” et zéro valeur en prod.

8) Contrôle des actions : quels mécanismes pour éviter qu’un agent fasse n’importe quoi ?

Question à poser : quelles barrières techniques et opérationnelles protègent tes systèmes quand un agent IA a des droits ?

• Rate limiting et quotas par agent et par action.
• Allowlist d’outils, de domaines, de dépôts, d’environnements.
• Sandbox et environnements isolés pour tests et actions risquées.
• Kill switch, rollback, et procédure d’arrêt en RUN.

Pour te mettre dans le bon état d’esprit avant d’automatiser : Agents IA : 10 garde-fous avant d’automatiser en entreprise et Sécuriser un agent IA qui a accès à vos outils.

9) Évaluation avant prod : comment tu testes sécurité, fuites, prompt injection ?

Question à poser : comment tu évalues le système avant mise en production, et pas juste le modèle ?

• Jeux de tests représentatifs métier, y compris cas “tordus”.
• Métriques sécurité : fuites, refus, contournement, comportements interdits.
• Tests de régression à chaque changement (prompt, policy, modèle, connecteur).
• Critères stop ou go, documentés.

À garder en tête : l’injection de prompt est un classique, et elle marche encore trop souvent. Pour poser le vocabulaire : Injection de prompt : la faille que les entreprises sous-estiment.

10) Red teaming continu : quel dispositif, quelle fréquence, qui porte la responsabilité ?

Question à poser : qui fait le red teaming, à quelle fréquence, sur quels scénarios, et comment c’est intégré au cycle de changement ?

• Scénarios : prompt injection, extraction de données, contournement de politiques, abus d’outils, empoisonnement de données RAG.
• Responsabilités : interne, prestataire, éditeur, mix.
• Suivi : tickets, SLA, priorisation, validation des corrections.
• RUN : surveillance et alerting sur comportements anormaux.

Relance utile : “montre-moi le dernier rapport de test, même anonymisé, et le backlog qui en est sorti”.

Gouvernance : la question qui doit revenir dans chaque échange

Tu peux poser 10 questions techniques et rater l’essentiel si la gouvernance est floue. Donc tu reviens toujours à ça :

• Qui est responsable en RUN ? RSSI, DSI, équipe data/ML, SOC, métier, éditeur, infogérant ?
• Qui porte le MCO et le MCS ? patching, upgrades, changements de modèle, suivi vulnérabilités, coûts, incidents.
• Qui arbitre ? quand sécurité, coût et performance se contredisent.

Pour cadrer sans blabla : Gouvernance de l'IA : qui décide quoi dans une entreprise de cinquante personnes.

Profils à envoyer à ATS26 Lyon (si tu veux du résultat)

Viens à plusieurs. Pas dix personnes. Quatre profils max, complémentaires. Sinon tu repars avec des opinions, pas des décisions.

• RSSI ou GRC : pour porter l’exigence de contrôle, la traçabilité, la gestion du risque, et les règles d’exploitation.
• DSI ou responsable plateforme : pour trancher sur l’intégration au SI, l’IAM, l’ITSM, le SIEM, et la responsabilité RUN.
• Data/ML ou engineering GenAI : pour parler évaluation, jeux de tests, RAG, MLOps, versions modèles, et contraintes réelles.
• Juridique ou DPO : pour verrouiller données, sous-traitance, conservation, clauses contractuelles, preuves en cas d’incident.

Si tu dois n’en envoyer que deux : RSSI plus DSI. Tu couvriras 80% des décisions qui bloquent les déploiements.

Livrables à ramener (sinon ta matinée ne sert à rien)

Objectif : rentrer à Lyon Part-Dieu, Gerland, Vaise ou Villeurbanne avec de quoi bosser dès le lendemain. Pas une inspiration.

• Carte des risques : 10 risques max, classés par impact et probabilité (accès, logs, data, intégrations, actions agentiques, dépendances fournisseurs).
• 2 à 3 quick wins faisables en 30 jours : exemple, SSO et MFA, rotation secrets, policy prompts, journalisation minimale, kill switch, tests injection de prompt.
• Backlog sécurité priorisé : qui fait quoi, dans quel outil, avec quelle date. Si possible : tickets déjà créés ou au moins un format prêt à copier.
• Décisions à acter : hébergement, conservation des logs, périmètre des données autorisées, modèle et dépendances, mode RUN.

Tu peux compléter ensuite avec une routine J+30. Si tu veux une trame simple : Après la conférence à Lyon : 7 actions J+30 pour sécuriser cloud, GenAI et contrats.

Pourquoi cette checklist colle à la réalité terrain (et pas à un discours “AI washing”)

Sur Lyon et plus largement en Auvergne-Rhône-Alpes, on voit la même bascule : le sujet n’est plus “tester l’IA”. Le sujet, c’est de l’insérer dans des workflows opérés, auditables, gouvernés. Les chiffres SANS cités plus haut vont dans le même sens : l’usage est là, l’industrialisation est en retard.

Et la GenAI a une propriété qui change la donne : elle manipule du texte libre, donc des données sensibles, et elle peut être connectée à des outils. À partir du moment où un agent IA peut créer un ticket, envoyer un mail, modifier un droit, lancer une action, tu dois penser comme un ops. Avec du contrôle, de la preuve, et de la responsabilité.

Plan d’attaque pour le 3 novembre (simple, efficace)

Tu veux tirer de la valeur d’un événement cybersécurité Lyon novembre 2026 ? Fais ça.

• Avant : choisis un cas concret (exemple : assistant interne sur base documentaire, agent SOC de triage, agent ITSM). Prépare 10 minutes de contexte : outils en place, données touchées, contraintes, niveau de risque acceptable.
• Pendant : déroule les 10 questions ci-dessus. Note les réponses sous forme “mécanisme + preuve + dépendance”. Si tu n’as pas ces trois éléments, c’est du vent.
• Après : écris ton backlog sécurité à 30 jours, et fixe un point de décision interne à J+7. Pas J+60.

Ce que tu dois retenir avant de te pointer à ATS26

Si tu vas à ATS26 Lyon « Security & AI » avec l’idée de “voir ce qui se fait”, tu rentreras avec des tendances. Si tu y vas avec une grille d’audit, tu rentreras avec un plan.

Le bon résultat pour toi, c’est simple : identifier où tu es fragile (IAM, logs, data, intégrations, évaluation), décider qui porte le RUN, puis lancer 2 ou 3 quick wins. Le reste suivra.

Si tu veux préparer le terrain côté agents : Agents IA et cybersécurité : effacement de traces, audit des logs et accès avant d’automatiser.

Mots-clés à garder en tête : Security AI Lyon, sécurité GenAI entreprise, agents IA cybersécurité, événement cybersécurité Lyon novembre 2026.