Détection sans signatures : quatre moteurs, quatre hypothèses

8 min. Temps de lecture

Détection basée sur les signatures ne reconnaîtra plus en 2026 que les attaques que l’attaquant voulait déjà laisser derrière lui. Les analyses comportementales, les modèles d’anomalies ML et le raisonnement par LLM combleront cette lacune, mais ce ne sont pas trois variantes du même outil. Si l’on achète ces outils comme appartenant à la même catégorie, on crée un SOC qui reste désemparé lors d’un incident réel.

Les points clés en bref

Les signatures restent une obligation, non une solution. Elles captent le bruit que tout SOC doit éviter. Pour les attaques ciblées, elles constituent le mauvais niveau.
Les analyses comportementales nécessitent un inventaire. Celui qui n’a pas compris ses utilisateurs et ses machines au niveau de la base de référence se retrouve avec surtout du bruit issu des moteurs de comportement.
Le raisonnement par LLM est la classe la plus coûteuse. Il fournit les meilleures explications, mais son fonctionnement 24h/24 et 7j/7 n’est pas économique. Il est toutefois idéal pour les enquêtes ciblées, mais pas encore adapté pour une détection globale.

Connexes :Analyse des menaces guidée par l’IA pour les SOC allemands en 2026 / NIS2 applique le Cloud Act

Ce que réalise vraiment une engine de détection en 2026

Qu’est-ce qu’une engine de détection ? Une engine de détection est la composante d’un stack SOC ou EDR qui extrait des données brutes pour en tirer une conclusion : quelque chose se passe ici, et il faut y prêter attention. Elle analyse les journaux, la télémesure et les flux réseau, les compare à des modèles ou à des schémas préétablis et génère des alertes. Cette engine décide alors ce qui est détecté comme incident et ce qui reste en arrière-plan.

La scène de la détection s’est diversifiée au cours des trois dernières années. Alors qu’au-delà de 2022, les IDS et les EDR dominaient le secteur, en 2026, quatre engines méthodologiquement différentes se côtoient : les signatures, les analyses comportementales, les anomalies ML et le raisonnement par LLM. Elles proviennent de mondes différents, elles coûtent différemment, et elles fournissent des résultats variés lors d’un incident réel.

La discussion dans les SOC allemands dure depuis deux ans autour de la question de savoir quelle de ces engines est la « bonne ». La réponse n’est pas une seule engine, mais une stratification consciente. Ceux qui l’ignorent achètent des outils qui se recouvrent mutuellement ou qui laissent des lacunes ouvertes, dont personne ne prend la peine de nommer.

Quatre moteurs, quatre hypothèses, quatre faiblesses

Moteur	Atout	Point aveugle	Prérequis
Signature	Rapide, économique, déterministe. Détecte massivement les malwares sans effort.	Utilisation de techniques « living-off-the-land », vulnérabilités zero-day, attaquants ciblés équipés d’outils sur mesure.	Flux actuels d’intelligence sur les menaces, règles YARA bien entretenues.
Analytics comportemental	Identifie des séquences anormales comme des mouvements latéraux inhabituels ou l’utilisation abusive de comptes de service.	Faux positifs dans des environnements vivants sans inventaire propre.	Inventaire des utilisateurs et des actifs, phase d’apprentissage de la ligne de base de six à huit semaines.
Anomalie par apprentissage automatique	Détecte des motifs statistiquement inhabituels sur de vastes ensembles de données, même sans intelligence sur les menaces.	Difficile à expliquer, difficile à calibrer, risque de dérive à chaque modification de l’infrastructure.	Pipeline de données stable, ingénieur en apprentissage automatique au sein de l’équipe ou sous forme de service géré.
Raisonnement par LLM	Fournit des explications riches en contexte pour les alertes, propose les prochaines étapes d’enquête.	Le coût par alerte n’est pas négligeable, risque d’hallucinations dans les cas limites.	Aggrégation propre des journaux, région d’inférence allemande ou européenne.

Source : Analyse propre des configurations SOC de la zone DACH, mai 2026.

Le tableau ne constitue pas un classement. Il montre que chacun des quatre moteurs résout un problème spécifique tout en en créant un autre. Celui qui se contente d’une approche basée sur les signatures dispose d’un SOC incapable de détecter les attaques ciblées. Quant à celui qui mise uniquement sur le raisonnement par LLM, il se retrouve avec un moteur coûteux mais dépourvu de discipline en matière de données brutes.

Quels scénarios d’attaque nécessitent réellement quel moteur

Trois exemples tirés de la gestion quotidienne des incidents au cours des derniers trimestres rendent cette stratification tangible.

Premièrement, une vague massive de phishing utilisant une famille de malwares connue. Le moteur basé sur les signatures identifie les pièces jointes en quelques minutes, car elles figurent dans la base de données de renseignement sur les menaces (Threat Intel). Un moteur comportemental pourrait détecter la tentative, mais il s’avère ici plus lent. Un moteur LLM expliquerait la détection sans pour autant l’accélérer. Conséquence : les signatures sont appropriées ici, tout le reste serait excessif.

Deuxièmement, un attaquant ciblé qui pénètre dans l’Active Directory via des identifiants compromis et se déplace latéralement à l’aide d’outils natifs. Aucune signature de malware ne fonctionne. L’analyse comportementale constitue ici la première véritable opportunité, car le schéma des connexions, de l’utilisation des comptes de service et des accès aux fichiers s’écarte de la ligne de base. La détection d’anomalies par ML peut compléter cette approche. Le raisonnement LLM aide à prioriser les alertes et à suggérer les prochaines étapes de traçage.

Troisièmement, une exfiltration subtile de données via des API cloud, camouflée en tâche de sauvegarde légitime. Les signatures ne détectent rien, car aucun malware n’est impliqué. L’analyse comportementale perçoit quelque chose si le volume de sauvegarde est anormal, mais des fluctuations légitimes peuvent masquer le signal. La détection d’anomalies par ML sur les appels d’API cloud est ici le moteur qui identifie le schéma. Le raisonnement LLM peut rendre ce schéma compréhensible pour le SOC.

Une stratégie de détection sans stratification claire des moteurs n’est qu’une liste de fournisseurs, pas un concept. Lors d’un audit, une simple liste ne suffit pas.

Ce que coûte concrètement le raisonnement LLM dans la réalité DACH

0,80 €

coûte une analyse assistée par LLM par alerte de taille moyenne (environ 5 000 tokens en entrée, 1 500 tokens en sortie) aux prix catalogue actuels des grands fournisseurs. Avec 2 000 alertes par jour, cela représente un montant annuel à six chiffres, avant même d’ajouter les outils périphériques.

Source : Évaluation propre des prix des fournisseurs, état mai 2026.

Cela ne signe pas la fin du moteur LLM dans le SOC, mais fixe une limite à son utilisation. En 2026, la couche LLM est surtout pertinente dans deux configurations : lors du tri des alertes hautement prioritaires et lors de l’investigation d’incidents spécifiques. Pour le traitement continu de chaque alerte, elle est actuellement trop coûteuse ; cela devrait changer avec l’arrivée de modèles endpoint moins chers, probablement au second semestre 2026.

Quiconque propose un moteur LLM comme solution de détection universelle doit communiquer ouvertement le prix par alerte. Celui qui l’ignore n’a pas calculé le coût de son produit de manière honnête.

Trois étapes concrètes pour la stratégie de détection 2026

Stratification sur une fenêtre de 90 jours

Jour 1 à 30

Vérifier la couche de signatures. Flux d’intelligence des menaces, règles standard EDR, YARA personnalisé pour vos propres charges de travail. Qu’est-ce qui est actuel, qu’est-ce qui est obsolète ? Mettre à jour ou remplacer les flux obsolètes.

Jour 31 à 60

Construire la couche comportementale. Consolider l’inventaire des utilisateurs et des actifs, activer le module UEBA, lancer la phase de référence. Six à huit semaines sont réalistes, pas deux.

Jour 61 à 90

Définir la couche LLM pour le triage. Définir par niveau de sévérité à partir de quand une analyse LLM s’exécute. Fixer un plafond de coûts par jour et garantir le verrouillage régional sur l’UE.

La couche d’anomalie ML ne s’inscrit encore en 2026 dans aucun modèle de 90 jours. Elle exige sa propre pipeline de données, elle nécessite un ingénieur ML et elle demande une acceptation du bruit de faux positifs pendant la phase d’apprentissage. Qui y croit vraiment planifie un semestre, pas un trimestre.

Ce qui a changé par rapport au SOC 2022

Trois glissements que toute mise à jour d’architecture SOC devrait prendre en compte. Premièrement : les signatures ne sont plus la couche principale, mais la couche d’hygiène. Elles restent obligatoires, elles ne constituent pas l’outil de différenciation. Deuxièmement : l’analyse comportementale est devenue en 2026 la norme pour tout SOC sérieux, et non une option premium. Qui n’en dispose pas accepte une zone aveugle qui deviendra visible lors des audits NIS2. Troisièmement : le raisonnement LLM est la nouvelle classe premium avec un effet réel, mais des limites réalistes.

Celui qui ne traduit pas cela dans sa stratégie achète soit trop sur une couche, soit trop peu sur une autre. La mauvaise investissement le plus fréquent en 2026 est celui d’une plateforme XDR coûteuse qui promet quatre moteurs sous un même toit et n’en met en œuvre sérieusement que deux en pratique. Qui vérifie cela examine la roadmap produit du fournisseur, et non le dossier marketing.

Foire aux questions

La détection basée sur les signatures est-elle vraiment encore nécessaire lorsque le comportement et le ML sont activés ?

Oui, pour deux raisons. Premièrement, les signatures capturent le volume élevé d’attaques standards qui surchargerait les moteurs comportementaux et ML de bruit. Deuxièmement, elles sont déterministiquement explicables, ce qui a une grande valeur lors des audits et dans la documentation de conformité. Un SOC sans couche de signatures présente des taux de faux positifs plus élevés dans les autres couches et un historique d’audit plus difficile à tracer.

Combien de temps dure réellement la phase de référence d’un moteur UEBA ?

Six à huit semaines dans un environnement stable, trois à quatre mois dans un environnement dynamique. Si vous effectuez une migration cloud, une fusion de locataires Office 365 ou un changement majeur d’AD pendant cette période, vous devez prolonger la phase de référence, sinon le modèle apprendra la transformation et non la normalité. Les promesses des fabricants selon lesquelles le système est « opérationnel après 14 jours » s’appliquent aux cas d’utilisation préfabriqués, et non à une base réelle.

Les modèles d’anomalie ML peuvent-ils expliquer pourquoi ils ont généré une alerte ?

De manière limitée. Les modèles statistiques classiques comme Isolation Forest ou Autoencoder produisent des scores d’anomalie, mais n’expliquent pas leur décision dans un champ linguistique naturel. Les techniques d’explicabilité telles que SHAP ou LIME aident, mais sont difficiles à consommer dans le contexte d’une alerte en direct. En pratique, les LLMs prennent ici en charge la partie explication, c’est la tâche de la couche de raisonnement LLM.

Un SIEM dédié vaut-il le coup si un fournisseur Managed XDR fournit tous les moteurs ?

Cela dépend du niveau de maturité. Un SIEM propre ou une plateforme de détection comme Wazuh, Elastic Security ou Sentinel offre un contrôle sur ses propres règles et ses propres données, mais exige des collaborateurs dotés de compétences en ingénierie de la détection. Un fournisseur Managed XDR fournit les moteurs, mais assume également la logique des règles. Qui a besoin d’une auditabilité NIS2 et suit sa propre stratégie cyberne doit à moyen terme disposer de compétences en ingénierie de la détection en interne.