Services / 01
Opérations de sécurité
Nous concevons et construisons les systèmes sur lesquels un centre opérationnel de sécurité fonctionne réellement : l'architecture de la plateforme, la télémétrie qui l'alimente, le contenu de détection qui s'exécute dessus, et l'automatisation qui maintient l'ensemble gérable à mesure qu'il grandit. L'accent porte sur une détection que l'on peut tester, versionner et raisonner, plutôt qu'accumuler.
Le problème
La plupart des problèmes d'opérations de sécurité se présentent comme des problèmes de détection et se révèlent être des problèmes d'ingénierie. Les règles s'accumulent plus vite que quiconque ne peut les retirer. La couverture est affirmée à partir d'un nombre de règles plutôt que mesurée face à un modèle de menace. Le contenu vit dans une console, donc il ne peut être ni revu, ni testé, ni annulé. Et sous tout cela, la télémétrie dont dépend la détection a été intégrée au fil de l'eau plutôt que conçue.
La conséquence est un SOC qui devient à la fois plus coûteux et moins lisible. Ajouter une source devient un projet. Modifier une règle devient un risque. Personne ne peut dire ce qui se passerait si telle technique était employée, parce que la question suppose de savoir quelles données existent, sous quelle forme et avec quelle fidélité — et cette carte n'existe pas.
Architecture
La forme du travail.
Une vue de référence de l'assemblage de ce pilier. C'est une structure de départ, pas une conception figée : c'est le parc existant qui décide de ce qui change.
Collecte
Télémétrie poste, identité, réseau, cloud et applicative, chaque source avec un responsable nommé et une alerte lorsqu'elle cesse d'arriver.
Normalisation
Un schéma commun à toutes les sources : une détection s'écrit contre un champ, pas contre un produit.
Détection
Du contenu versionné, porteur d'un contrat de données explicite, testé sur des événements connus avant d'être promu.
Tri
Enrichissement et corrélation qui réduisent le nombre de décisions prises à la main et documentent mieux celles qui restent.
Réponse
Une automatisation dont la portée est définie à l'avance : ce qu'une action peut atteindre relève de la conception, pas de l'improvisation.
Mesure
Taux de déclenchement, issue et délai de tri, relevés détection par détection — ce dont une discussion sur la couverture a réellement besoin.
Compétences
Ce que couvre ce pilier.
Regroupées par partie du système sur laquelle elles agissent.
Architecture
- Conception et architecture SOC
- Ingénierie SIEM
- Migration SIEM
- Architecture Splunk
- Modernisation du SOC
- Observabilité du SOC
Détection
- Detection engineering
- Detection-as-code
- Détection des menaces
- Analytique de sécurité
- Alerting fondé sur le risque
Automatisation
- Automatisation de la sécurité
- Conception SOAR
- Ingénierie des workflows de réponse
Approche
Comment se déroule une mission.
La séquence compte davantage que l'outillage. Sauter une étape en reporte le coût, cela ne le supprime pas.
- 01
Évaluer
Établir ce qui existe : sources, pipelines, topologie de la plateforme, inventaire de détection, et où se situe réellement la douleur opérationnelle. L'évaluation est une collecte de preuves, pas un exercice de notation.
- 02
Architecturer
Concevoir l'état cible et — plus important encore — la séquence qui y mène sans gel de production. Chaque décision est écrite avec la contrainte qui l'a motivée.
- 03
Construire
Le réaliser : plateforme, pipelines, contenu de détection, tests et automatisation. Le contenu est livré sous forme de code, dans votre dépôt, sous votre contrôle.
- 04
Transférer
Transmettre avec documentation, runbooks et sessions de travail. La mesure du succès est que votre équipe puisse étendre le système sans nous.
Ce que vous recevez
Des livrables concrets, dans vos dépôts et sur vos plateformes.
- Une architecture SOC et SIEM cible, avec le chemin de migration depuis votre situation actuelle
- Un dépôt de detection-as-code : contenu sous contrôle de version, avec tests, revue et pipeline de déploiement
- Une couverture de détection cartographiée sur un modèle de menace plutôt que sur un nombre de règles
- Une conception d'alerting fondé sur le risque — comment les signaux s'agrègent en quelque chose qui mérite l'attention d'un analyste
- L'automatisation du travail répétitif qui, sans elle, plafonne la capacité d'un SOC
- L'observabilité de la plateforme : le SOC est-il lui-même en bonne santé, et comment le sauriez-vous s'il ne l'était pas
Résultats attendus
Des propriétés du système obtenu — pas des chiffres de performance, qui dépendent de votre patrimoine et non de nous.
- Un contenu de détection versionné, testé et relisible comme n'importe quel logiciel
- Une couverture exprimée face à un modèle de menace, avec les manques énoncés plutôt que masqués
- Une architecture de plateforme qui survit au prochain doublement du volume de données
- Moins d'alertes, mais meilleures — parce que l'agrégation est conçue et non subie au triage
- Une équipe capable d'étendre le système sans ceux qui l'ont construit
À lire ensuite
Des positions tenues en construisant.
Les articles d'ingénierie de ce pilier.
What NIS2 and DORA actually ask of your telemetry
A 24-hour reporting clock is a data architecture requirement before it is a policy one. An engineering reading of what the EU incident-reporting regimes need from a security data platform.
septembre 2026 · 5 min de lecture
Detection engineering is a software problem
Rule counts measure activity, not coverage. Treating detections as software — with dependencies, tests, owners and a retirement path — changes what a SOC can honestly claim.
septembre 2026 · 5 min de lecture