Le paradoxe de la priorisation
Chaque matin, la vue depuis un tableau de bord de sécurité est sensiblement la même. C’est un mur de texte rouge : des centaines de vulnérabilités détectées, des dizaines d’anomalies IAM, des dérives Terraform et un flux incessant d’alertes provenant d’analyseurs, de journaux et de pipelines.
La plupart de ces signaux sont importants. Certains d’entre eux sont essentiels. Et certains sont si urgents que les responsables ingénierie auraient dû être mis au courant il y a 10 minutes.
Ce n’est plus le manque de visibilité qui nous pose problème, mais la priorisation.
Nous disposons de trop de données et de trop peu de temps pour les transformer en décisions. À l’heure actuelle, la réponse à la question « Quelle est notre posture de sécurité aujourd’hui ? » est dispersée entre 15 sources différentes, allant des analyses Trivy et des journaux Okta aux modèles d’accès CloudTrail et aux checklists de conformité.
Résultat ? Les dirigeants manquent de clarté, et les équipes ingénierie ne reçoivent pas de tâches priorisées. Les ingénieurs SRE comme nous passent trop de temps à synthétiser des données au lieu de concevoir réellement des solutions.
Lors d’un récent hackathon interne, nous avons essayé de résoudre ce problème en posant une question simple : l’IA peut-elle transformer toutes ces informations parasites en une synthèse courte et précise ?
Le concept : un briefing quotidien sur la sécurité
Nous n’avions pas l’intention de créer un autre tableau de bord. Personne ne veut d’un autre tableau de bord.
Nous voulions créer une synthèse d’une page qu’un dirigeant puisse lire en 30 secondes en se rendant à une réunion, mais qui fournisse tout de même aux ingénieurs les preuves, les signaux bruts et la responsabilité nécessaires pour corriger les problèmes.
Nous avons créé un prototype qui combine nos signaux de sécurité existants, une couche légère de notation fondée sur la logique et un outil de résumé optimisé par l’IA (utilisant la RAG) pour produire un briefing quotidien sur la sécurité.
Voici exactement à quoi ressemble le résultat pour un dirigeant :
Point quotidien sur la sécurité – 7 nov. 2025 – Posture générale : modérée (⬆ tendance à la hausse)
Les 3 actions principales
1. Résiliation de l’accès public sur le compartiment S3 customer-export-backup. Des preuves indiquent des requêtes GET externes provenant d’adresses IP inconnues. (Confiance : élevée)
2. Application d’un correctif auth-api pour résoudre la vulnérabilité CVE-2024-XXXX. Démonstration de faisabilité (PoC) publique disponible. (Confiance : élevée)
3. Examen de deux connexions inhabituelles à la console d’administration. Activité détectée depuis une nouvelle zone géographique ou un nouveau terminal. (Confiance : moyenne)
Contexte et narratif : « La plupart des observations d’aujourd‘hui sont routinières, mais deux éléments augmentent le risque global : un compartiment S3 public contenant des exportations sensibles et une vulnérabilité OpenSSL critique avec des tentatives d’exploitation actives signalées. En combinaison avec une activité anormale au niveau de l’administration IAM, nous préconisons de traiter ces problèmes dans les 48 heures. »
L’architecture « sans magie »
Pour ce faire, nous avons créé un pipeline en quatre étapes qui transforme les données brutes en un narratif structuré. Nous avons veillé à ne pas trop le complexifier.
Étape 1 : ingestion et normalisation – Nous agrégeons les résultats de tous nos analyseurs et journaux (Trivy, Tenable, CloudTrail, etc.) et les convertissons en un schéma JSON unique et normalisé. Ceci garantit qu’une vulnérabilité dans un conteneur et une dérive dans Terraform parlent le même langage.
Étape 2 : priorisation et notation (sans IA) – Nous avons intentionnellement évité d’utiliser un machine learning de type « boîte noire » pour la couche de notation. Au lieu de cela, nous avons employé une notation pratique et fondée sur la logique (0 à 100) basée sur des facteurs de risque.
- Compartiment public + étiquette de données à caractère personnel ? Risque élevé.
- CVSS 9.0 + système exposé à Internet ? Critique.
- Dérive sur un module Terraform critique ? Priorisation.
Ce filtrage garantit que l’IA se concentre uniquement sur les éléments qui comptent réellement.
Étape 3 : récupération du contexte (la couche RAG) – Pour les principaux éléments à haut risque, nous utilisons la recherche vectorielle pour récupérer le contexte. Nous interrogeons notre base de données vectorielle pour identifier des incidents similaires passés, des runbooks pertinents, des différences dans les demandes d’extraction et des métadonnées des propriétaires de ressources. Ceci fournit la « mémoire » dont le système a besoin pour déterminer si une anomalie est réellement nouvelle ou s’il s’agit simplement d’un faux positif récurrent.
Étape 4 : synthétisation par l’IA avec des garde-fous – Enfin, nous intégrons les éléments principaux et le contexte récupéré dans un LLM. Nous utilisons des invites strictes pour éviter les hallucinations, en demandant au modèle : « Synthétise les éléments de preuve ci-dessous en 3 ou 4 phrases claires pour un profil cible de dirigeants. N’invente aucun fait. Utilise uniquement les preuves fournies. »
Ce que l’IA fait réellement
Au cours de cette expérience, nous avons découvert quelque chose de surprenant : l’IA n’est pas forcément douée pour « détecter les problèmes ». Nos analyseurs le font très bien.
L’IA excelle dans la compression du contexte.
La magie ne réside pas dans la détection, mais dans la synthétisation et le narratif. L’IA aide à répondre aux questions suivantes :
- Qu’est-ce qui a changé récemment ?
- Quelles sont les 3 choses importantes aujourd’hui ?
- Qui devrait agir ?
Il s’agit de la partie sur laquelle les humains perdent des heures, et celle que l’IA gère magnifiquement.
Leçons tirées de l’expérience
1. 70 % des résultats sont des informations parasites
En imposant un modèle de priorisation strict, nous avons appris que la grande majorité des découvertes quotidiennes n’ont pas d’importance pour l’instant. Elles ne sont pas nécessairement sûres, mais elles ne sont pas exploitables aujourd’hui. L’IA aide à identifier les modifications spécifiques qui nécessitent une attention immédiate.
2. Les dirigeants préfèrent le format narratif aux métriques
Les métriques ne sont pas synonymes de compréhension. Les dirigeants préfèrent un format narratif qui explique « C’est important parce que... » et « Cela a un impact sur les clients... » plutôt qu’un graphique montrant « 500 vulnérabilités élevées ». Le format narratif permet un alignement instantané entre l’équipe sécurité, les ingénieurs SRE et les dirigeants.
3. Les ingénieurs ont besoin de l’« annexe »
Alors que les dirigeants reçoivent la synthèse, le système génère une annexe détaillée pour les ingénieurs contenant les résultats bruts des analyses, les journaux CloudTrail, les différences et les runbooks associés. Lorsque les ingénieurs ont constaté que l’IA fournissait automatiquement les ensembles de preuves et les différences, ils se sont rendu compte que l’outil ne les remplaçait pas, mais qu’il effectuait les tâches ingrates qu’ils n’appréciaient guère.
Le verdict
Ce système ne remplace pas le jugement humain. L’IA ne peut pas évaluer les risques opérationnels, approuver les correctifs d’urgence ni comprendre les nuances organisationnelles. Elle agit comme un « analyste junior » qui rédige la première version et soumet les bons problèmes aux bonnes personnes.
En appliquant une IA pratique avec de solides garde-fous, nous avons transformé des données opérationnelles désordonnées en un système qui permet d’économiser des heures d’efforts manuels chaque semaine.
Conclusion
La sécurité moderne n’est pas un problème de visibilité, mais un problème de priorisation. Nous n’avons pas besoin de davantage de tableaux de bord, mais de plus de clarté. En élaborant un pipeline optimisé par l’IA pour ingérer les signaux et produire un récit, nous pouvons cesser de nous noyer dans les informations parasites et commencer à nous concentrer sur l’action.
