Triage des alertes : qui lit à 3 heures du matin ?

Sophos a analysé 661 cas de réponse à incident dans 70 pays et y a trouvé un schéma qui ne tient pas à la technologie : 88 % des charges utiles de rançongiciel sont déclenchées en dehors des heures ouvrées, et 79 % des actions d'exfiltration également. Les attaquants n'attendent pas la nuit par superstition. Ils attendent le moment où le triage des alertes de sécurité s'arrête, parce que plus personne ne regarde.

Dans une entreprise sans centre opérationnel de sécurité, le problème est rarement qu'elle ne voit rien. Les signaux sont déjà là : sshd, nginx, le pare-feu, un antivirus qui envoie des courriels. Le problème, c'est le triage — qui sépare, et en combien de temps, les trois choses qui comptent des trois cents qui ne comptent pas. Dans beaucoup d'entreprises, la réponse honnête à « en combien de temps » est « lundi matin ».

Pourquoi le triage est le goulot d'étranglement, pas la détection

Pourquoi vous avez ces alertes est une discussion à part, menée dans notre article sur les serveurs exposés à Internet. Ici, nous partons de la suite : l'alerte existe déjà, elle est dans la file, et quelqu'un doit décider quoi en faire.

La taille du tas dépend de ce que vous appelez « alerte ». Vectra AI, dans une étude auprès de 1 450 praticiens, rapporte une moyenne de 2 992 alertes par jour — comptées brutes, sur l'ensemble du parc d'outils ; 69 % des répondants utilisent plus de dix outils de détection et de réponse, 39 % plus de vingt. Prophet Security, dans une étude auprès de 250 répondants, rapporte un volume médian d'environ 100 alertes par jour — mais on y compte ce qui arrive effectivement dans la file d'un analyste, après filtrage. L'écart d'un facteur trente n'est pas une erreur de mesure, c'est une définition différente du mot « alerte ». Les deux sont des études financées par des fournisseurs qui vendent la solution au problème mesuré ; c'est précisément pour cela que nous citons les deux.

Ce que l'on connaît mieux, c'est la part du tas qui est vide. Une recherche Omdia commandée par Microsoft — 300 praticiens SOC dans des organisations de plus de 750 salariés — relève 46 % de faux positifs et des analystes qui basculent entre 10,9 consoles en moyenne ; 66 % des équipes perdent un cinquième de leur semaine rien qu'à agréger des données. Le SANS Detection & Response Survey 2025 place les faux positifs en tête des problèmes de détection pour 73 % des équipes, et la catégorie « très fréquent » est passée de 13 % à 20 % en un an.

Chaque alerte coûte du temps humain, et pas qu'un peu. Prophet mesure un temps d'investigation médian d'environ 45 minutes (moyenne autour de 75), avec 64 % des équipes au-dessus de 30 minutes, plus 23 minutes médianes passées simplement dans la file avant que quelqu'un ne regarde. Multipliez par votre volume réel et vous obtenez le nombre de personnes qu'il vous faudrait pour que rien ne passe à la trappe. Presque aucune entreprise de taille moyenne ne dispose de ce nombre.

La conséquence est mesurée par tout le monde, avec des résultats qui ne se recouvrent pas : 42 % d'alertes « non investiguées » chez Omdia/Microsoft, 28 % en moyenne (22 % en médiane) chez Prophet, 63 % « non traitées » chez Vectra. « Personne n'a regardé » et « rien n'a été fait » ne sont pas la même chose, et les populations étudiées diffèrent. L'ordre de grandeur tient pourtant, quelle que soit la source à laquelle vous vous fiez : entre un quart et deux tiers environ des alertes n'aboutissent nulle part. Prophet ajoute le détail gênant — 60 % des organisations ont eu des alertes ignorées qui se sont révélées ensuite être de vrais incidents.

• L'alerte sérieuse arrive le samedi à 2 h 40 et se lit le lundi à 9 h 15, sur le même écran que trois cents autres notifications de routine.
• Personne ne peut dire vite si l'alerte est pertinente ici : une campagne réelle contre un produit que l'entreprise n'exploite pas ressemble, dans une liste, exactement à une campagne qui compte.
• La personne qui pourrait décider est celle-là même qui s'occupe des imprimantes, des sauvegardes et de la migration du fournisseur de messagerie.
• Après la troisième fausse alarme venant de la même source, la règle est désactivée « temporairement » — et le reste.
• Quand quelque chose se produit vraiment, il n'existe nulle part d'historique des décisions : qui a regardé, ce qu'il a vu, sur quelle base il a clôturé.

En Roumanie, une arithmétique de personnel toute simple vient se poser par-dessus. Un rapport du DNSC, l'autorité nationale de cybersécurité, montre que le pays compte moins de 3 % de spécialistes TIC dans sa population active occupée, contre une moyenne européenne de 5 %, le manque de personnel qualifié et l'insuffisance des moyens financiers étant les principaux obstacles dans la plupart des secteurs évalués. L'ISC2 relève 33 % d'organisations sans les ressources nécessaires pour doter correctement leur équipe de sécurité et 29 % qui ne peuvent pas s'offrir les compétences dont elles ont besoin. Le même rapport du DNSC montre aussi que près de 70 % des organisations évaluées jugent leur propre sécurité « bonne » ou « très bonne » — la confiance ne suit pas la même courbe que les effectifs.

Les deux horloges : combien de temps avant que vous l'appreniez

La question « combien de temps avant que vous l'appreniez » reçoit deux réponses qui semblent se contredire. IBM, dans le Cost of a Data Breach Report 2026 (recherche Ponemon, 602 organisations, compromissions survenues entre mars 2025 et février 2026), mesure 247 jours en moyenne pour identifier et contenir une compromission — en hausse par rapport aux 241 de l'édition précédente, soit l'inversion de plusieurs années d'amélioration. Sophos, sur ses 661 cas de réponse à incident, mesure un temps de présence médian de 3 jours.

Elles ne se contredisent pas. Elles mesurent les extrémités opposées d'une même distribution : dans les cas qui arrivent chez une équipe de réponse, la médiane se compte en jours, parce que l'intrusion y a été détectée ; dans la statistique des compromissions déclarées, elle se compte en mois. L'écart entre ces deux populations est exactement ce que vous achetez quand vous achetez du triage.

La fenêtre utile est pourtant bien plus courte que l'un ou l'autre de ces chiffres. Sophos mesure 3,4 heures en médiane avant que l'attaquant n'atteigne le serveur Active Directory. CrowdStrike décrit une intrusion où l'exfiltration de données a commencé 4 minutes après l'accès initial. À 3,4 heures, une alerte qui attend 23 minutes dans la file puis exige 45 minutes d'investigation peut encore arriver à temps. À 4 minutes, non.

L'écart entre « c'est arrivé » et « quelqu'un a décidé que cela méritait d'être déclaré » se voit le mieux dans les données nationales. Les capteurs du DNSC roumain ont collecté plus de 25 millions d'événements de cybersécurité en 2025, dont environ 5,88 millions de tentatives de force brute. La même année, 47 incidents de force brute ont été déclarés au DNSC. Les deux chiffres ne sont pas comparables — l'un est de la télémétrie de capteurs, l'autre de la déclaration d'incidents — et c'est précisément pour cela qu'ils sont utiles ensemble : entre les deux se trouve le triage. Or l'obligation de déclaration ne l'attend pas : sous NIS2, le compte à rebours démarre par une alerte initiale à 24 heures, détaillée dans notre guide de préparation à la déclaration. On ne déclare pas en 24 heures ce que l'on apprend trois semaines plus tard.

La détection est bon marché et peut tourner seule, en continu. Le jugement est cher et dort la nuit. C'est là qu'est le goulot d'étranglement, pas au niveau des capteurs.

Ce qu'un modèle peut et ne peut pas faire en triage

C'est ici qu'entre l'IA, et ici aussi que commencent les exagérations. Les données de marché sont exceptionnellement claires sur l'endroit où se situe le gain. Prophet rapporte que 72 % de ceux qui utilisent l'IA en triage constatent une baisse de plus de 25 % du temps d'investigation, avec une moyenne autour d'un tiers, et 18 % font état de plus de 50 %. Le SANS Institute, dans une enquête auprès de 536 praticiens sponsorisée par un consortium de fournisseurs concurrents entre eux, montre l'adoption de l'IA en sécurité passant de 50 % à 78 % en un an — mais aussi 63 % de praticiens signalant des lacunes importantes lorsque l'IA détecte des menaces ou y répond, contre 45 % auparavant. Seuls 27 % qualifient leur mise en œuvre de « mature ».

Les deux résultats ne s'excluent pas. « Cela me fait gagner du temps » et « cela m'induit parfois en erreur » peuvent être vrais pour la même personne, la même semaine. Les échecs remontés au SANS se regroupent autour des faux positifs, de la difficulté à identifier des menaces inédites et de sorties formulées avec assurance mais fausses. C'est une description exacte de ce qu'est un modèle de langage : bon pour expliquer et prioriser, mauvais pour garantir. Quand les mêmes répondants énumèrent les contrôles les plus efficaces contre les menaces assistées par IA, on trouve en tête la détection comportementale (45 %), la sensibilisation (45 %) et la relecture par un analyste humain (39 %).

La pratique confirme cette prudence. Torq a interrogé 450 RSSI et responsables de SOC : 97 % sont convaincus que l'IA peut faire du triage, mais seuls 35 % l'utilisent effectivement pour cela, et 9 sur 10 veulent voir comment le modèle parvient à une décision avant d'élargir son autonomie — 46 % placent la transparence et l'explicabilité en tête des facteurs qui augmenteraient leur confiance. Dans la distribution de Prophet, 57 % exigent une relecture humaine avant la clôture d'une alerte, 44 % laissent le modèle recommander et l'humain exécuter, 30 % n'autorisent l'exécution automatique que pour des actions à faible risque — et 0 % accordent une autonomie complète, non supervisée. Zéro, dans une enquête menée par un fournisseur qui aurait eu tout intérêt à un autre chiffre.

Il existe une autre raison, plus rarement évoquée, pour laquelle un modèle n'a rien à faire avec des droits d'exécution sur un serveur de production. L'injection de prompt est le risque numéro un de l'OWASP Top 10 for LLM Applications, édition 2025, deuxième année consécutive en première position, et la cause est structurelle : le modèle reçoit instructions et données par le même canal, sans séparation. Songez maintenant à ce qu'est réellement une ligne de journal : du texte écrit par l'attaquant, dans un champ qu'il contrôle. Si ce texte parvient à un modèle capable d'exécuter des commandes, vous n'avez pas construit un analyste automatique — vous avez construit exactement le scénario LLM01. Les mesures d'atténuation de la liste sont ennuyeuses et efficaces : séparer explicitement le contenu externe, restreindre les privilèges, valider les entrées et garder un humain dans la boucle pour les opérations sensibles.

À quoi ressemble un triage qui tient à 3 heures du matin

Rien de ce qui suit ne suppose un SIEM ni une équipe en rotation. Cela suppose seulement que l'ordre des opérations soit correct.

1. 1Écrivez ce que « grave » signifie avant d'avoir un incident, par catégories : accès réussi contre tentative, compte à privilèges contre compte applicatif, service exposé contre service interne. Sans ce seuil, tout ce qui suit relève de l'opinion.
2. 2Coupez le bruit avant la file, pas dans la file. Une alerte écartée par un humain a déjà coûté du temps humain ; une alerte rejetée par une règle déterministe n'a rien coûté.
3. 3Éliminez explicitement ce qui ne peut pas vous atteindre. Une campagne réelle et persistante contre un produit que vous n'exploitez pas reste du bruit de fond — et c'est la catégorie la plus facile à automatiser correctement.
4. 4Gardez la décision de blocage déterministe : seuils, listes, règles que vous pouvez lire, tester et expliquer à un auditeur. Le modèle explique et priorise ; la règle décide.
5. 5Mettez en place un canal qui atteint un humain en dehors des heures ouvrées, pas un tableau de bord ouvert le lundi matin. 88 % des charges utiles de rançongiciel sont déclenchées, selon Sophos, en dehors des heures ouvrées.
6. 6Priorisez les correctifs selon l'exposition réelle, pas selon le score brut : un CVSS 6,5 figurant sur la liste CISA des vulnérabilités activement exploitées compte davantage qu'un 9,8 que personne n'exploite. Un scan récurrent de vulnérabilités tient la liste à jour sans dépendre de la mémoire de quelqu'un.
7. 7Conservez ce qui a été décidé, pas seulement ce qui s'est produit. Un historique des décisions de triage est la seule chose qui rende possible une déclaration en 24 heures, et la seule qui vous sorte de la discussion « qui a clôturé cette alerte ».
8. 8Si vous n'avez personne à mettre de garde, externalisez le jugement, pas seulement les outils — auprès d'un partenaire en cybersécurité doté d'un plan de réponse à incident écrit et répété.

Ce que nous avons construit — et ce qu'il ne fait pas encore

Sentinel est notre réponse exactement au problème ci-dessus, et la façon la plus honnête de le décrire passe par ce qu'il ne fait pas. La détection, le score et la décision tournent de manière déterministe, en continu, à coût nul. Le modèle n'est appelé que pour les incidents qui dépassent le seuil de sévérité : il lit ce qui s'est passé et dit en langage clair ce qui est réel, ce qui est du bruit et ce que vous avez à faire, en moins de deux minutes après l'ouverture de l'incident, puis rédige la procédure de remédiation. Il s'installe sur l'infrastructure du client et se livre avec sa documentation. Une seule machine ou une flotte, sans SIEM, sans agent externe, sans données envoyées hors du serveur.

Les quatre limites du modèle sont publiques, parce qu'elles constituent en réalité l'architecture. Il ne décide pas des blocages. Il n'exécute rien — le plan qu'il rédige passe par un validateur déterministe qui le refuse s'il n'est pas sûr ; le modèle rédige, le validateur décide. Il n'est pas sur le chemin critique : si l'API est en panne ou le budget épuisé, la détection, le blocage et l'alerte continuent, marqués « analyse IA indisponible ». Et il ne dépasse pas le budget — le plafond est vérifié avant chaque appel.

Face au problème OWASP évoqué plus haut, la réponse est aussi ennuyeuse qu'elle doit l'être : les lignes de journal et les chemins HTTP sont traités comme des données non fiables, avec des délimiteurs explicites, et le transport qui lit les fichiers sur le serveur tourne en mode plan — structurellement incapable de modifier quoi que ce soit. Il existe un test qui plante IGNORE PREVIOUS INSTRUCTIONS dans un journal d'accès et vérifie que rien n'a été exécuté. Côté blocage, la liste des adresses protégées est codée en dur dans le code, pas dans la configuration ni dans la base de données ; la règle de base est policy accept, c'est-à-dire une liste de refus et non un pare-feu ; et un fichier PANIC vide tous les blocages en moins de 60 secondes. Le blocage automatique est livré désactivé : les 72 premières heures vous montrent seulement ce qu'il aurait bloqué.

Les chiffres qui suivent proviennent d'un seul de nos serveurs, sur 24 heures — une installation de production sur AlmaLinux 9, avec 14 applications supervisées. Ce n'est pas un échantillon et ce n'est pas « typique » : 1 055 attaquants uniques, 2 765 événements hostiles sur 7 031 au total, 554 incidents ouverts dont 13 graves, 5 adresses bloquées. Le bruit est rejeté avant la base — environ 96 000 diagnostics moteur par jour n'y arrivent jamais — et le modèle n'est appelé que pour les incidents qui dépassent le seuil, en général quelques dizaines par jour. Un exemple concret de triage tiré du même tableau de bord : « campagne active contre GLPI, 560 sondages ». Réelle, persistante, ciblée. Le serveur n'exécute pas GLPI, c'est donc du bruit de fond — et cela doit être dit clairement, pas laissé à occuper la première place d'un tableau de bord.

Ce qu'il ne fait pas encore est tout aussi public : les journaux de conteneurs ne sont pas collectés, il n'existe pas de moniteur dédié à l'intégrité des fichiers au-delà d'auditd, et l'installation sur Debian est couverte par des tests mais pas encore vérifiée sur un hôte Debian réel. La licence est par serveur, et la configuration initiale ainsi que la calibration de 72 heures sont incluses dans toutes les formules ; l'architecture, les limites et les plateformes couvertes sont décrites sur la page produit.

Conclusion

La détection est devenue bon marché jusqu'à la banalité : tout serveur moderne génère déjà plus de signaux que personne ne peut en lire. Ce qui n'est pas devenu bon marché, c'est le jugement — qui regarde, en combien de temps, et sur quelle base il décide que quelque chose compte. La différence entre une entreprise qui l'apprend en trois jours et une qui l'apprend des mois plus tard ne tient pas aux outils, elle tient au triage, et le triage se conçoit, il ne s'espère pas. L'IA aide sur la partie explication et priorisation, où elle est mesurablement bonne ; la décision de blocage reste là où elle peut être lue et testée. Si vous voulez que nous regardions ensemble ce que vos serveurs produisent en ce moment et quelle part parvient réellement à un humain, parlons-en 30 minutes.

Sources

• Sophos — « Active Adversary Report 2026 », 661 cas IR et MDR, novembre 2024 – octobre 2025 (sophos.com)
• Microsoft Security Blog — « Unify now or pay later », recherche Omdia commandée par Microsoft, N=300 praticiens SOC, février 2026 (microsoft.com/security/blog)
• SANS Institute — Detection & Response Survey 2025 (rapporté par stamus-networks.com) et « 2026 SANS AI Survey », N=536, juillet 2026 (sans.org)
• Prophet Security / ViB — « State of AI in the SOC 2026 », N=250, août 2026 (prophetsecurity.ai) — étude d'un fournisseur « AI SOC »
• Vectra AI — « State of Threat Detection and Response 2026 », N=1 450 (vectra.ai) — étude de fournisseur
• Torq — « 2026 AI SOC Leadership Report », terrain Sapio Research, 450 RSSI et responsables de SOC, mars 2026 (torq.io) — étude de fournisseur
• IBM — « Cost of a Data Breach Report 2026 », recherche du Ponemon Institute, 602 organisations, juillet 2026 (ibm.com/reports)
• CrowdStrike — « 2026 Global Threat Report », télémétrie propre, février 2026 (crowdstrike.com)
• DNSC, l'autorité nationale roumaine de cybersécurité — rapport annuel d'activité 2025, approuvé par la décision CSAT n° 117 du 7 août 2026 (rapporté par agerpres.ro et business24.ro) ; rapport du DNSC sur la pénurie de spécialistes (rapporté par europafm.ro)
• ISC2 — Cybersecurity Workforce Study 2025, décembre 2025 (isc2.org)
• OWASP GenAI Security Project — Top 10 for Large Language Model Applications 2025, LLM01 Prompt Injection (owasp.org)
• CryptoITData — Sentinel, documentation produit et données issues d'une seule installation de production (cryptoitdata.eu/sentinel)