Les systèmes critiques que votre audit cyber n’avait jamais vus

8h12. Le téléphone de Marc Lefèvre vibre pendant son trajet vers Palaiseau.

Le message vient du secrétariat général : ‍

“Le comité conformité veut une cartographie NIS2 consolidée avant vendredi. Audit externe dans six semaines.”

À première vue, le sujet paraît simple :

• Identifier les systèmes entrant dans le périmètre NIS2.
• Vérifier les obligations applicables.
• Repérer les écarts de conformité.

Mais dans un groupe industriel comme Véracier, les systèmes les plus exposés ne sont pas toujours ceux qui apparaissent dans les référentiels officiels.

• Certains environnements OT supportent directement des lignes de production stratégiques sans être remontés dans l’inventaire groupe. 
• Un ancien SCADA continue d’être exploité malgré des écarts de segmentation déjà signalés. 
• Un système MES est marqué comme conforme alors que son dernier audit sécurité date de plus de quatre ans.

Pris séparément, chaque document semble cohérent. Ensemble, ils racontent une autre histoire.

Marc ouvre LightOn et pose la question comme il le ferait avec son équipe :

“Quels systèmes industriels entrent réellement dans le périmètre NIS2 et où sont nos écarts de conformité ?”

La cartographie que l’audit n’avait pas produite

Quelques minutes plus tard, LightOn reconstruit ce que les documents n’avaient jamais formulé ensemble.

1. Onze systèmes industriels relèvent effectivement du périmètre NIS2.
2. Trois environnements OT critiques n’apparaissaient dans aucun inventaire centralisé.
3. Deux réseaux industriels présentent des écarts de segmentation incompatibles avec les politiques groupe.
4. Un système SCADA continue d’être exploité malgré une architecture déjà signalée comme non conforme dans un audit précédent.
5. Plusieurs actifs officiellement classifiés comme “non critiques” supportent pourtant des opérations de production essentielles.

Chaque conclusion est reliée directement aux documents sources : 

• rapports de pentest
• matrices OT
• politiques sécurité
• audits locaux
• référentiels industriels

Vendredi matin, le comité conformité commence avec une présentation incomplète des équipes IT. Les responsables industriels contestent certains périmètres. Le juridique rappelle les obligations réglementaires. La direction demande une estimation claire de l’exposition réelle.

Marc ouvre alors la cartographie consolidée :

• Systèmes concernés
• Sites impactés
• Écarts identifiés
• Documents sources
• Architectures contradictoires
• Inventaires incomplets

La discussion change immédiatement. À partir de ce moment-là, personne ne débat plus d’interprétations. Les documents parlent enfin ensemble.

Là où un RAG classique perd le fil

Ce résultat n’est pas difficile parce que les informations sont introuvables. Il est difficile parce qu’elles sont dispersées, partielles et parfois contradictoires.

L’analyse couvre douze documents répartis entre plusieurs entités européennes : 

• inventaires OT
• rapports de pentest
• architectures SCADA
• matrices de criticité
• politiques cybersécurité 
• procédures industrielles locales

Chaque document, pris seul, donne une réponse plausible.

• L’inventaire groupe suggère que certains systèmes sont hors périmètre
• La matrice de criticité classe certains actifs comme non critiques
• Un rapport local signale pourtant des dépendances de production essentielles
• Un audit précédent mentionne des écarts de segmentation encore non résolus
• Une architecture SCADA montre des connexions qui ne figurent dans aucun référentiel centralisé

Un RAG classique peut retrouver chacun de ces documents. Mais pour identifier l’exposition réelle, il faut faire autre chose : lire les documents les uns contre les autres.

C’est là que le cas d’usage devient impossible pour un système de recherche classique.

Il ne suffit pas de trouver la politique NIS2, ni de lister les actifs déjà marqués comme critiques. Il faut comprendre qu’un système officiellement “non critique” peut devenir réglementairement critique parce qu’il supporte une ligne de production essentielle, qu’il dépend d’un réseau mal segmenté, ou qu’il apparaît dans un audit local jamais consolidé au niveau groupe.

Autrement dit, le risque n’est pas écrit dans un seul document.
Il apparaît uniquement lorsque les documents commencent à se contredire.

Pourquoi ce cas d’usage compte

Le scénario CISO-02 dans EDiTh n’a pas été conçu pour tester la capacité d’un système à retrouver une politique cybersécurité.

Il teste quelque chose de plus difficile : 

Raisonner sur le périmètre réglementaire réel d’un groupe industriel à partir de documents incomplets, distribués et contradictoires.

Le problème n’est pas de retrouver un PDF mentionnant NIS2.

Le problème est d’identifier les systèmes que vous devrez réellement défendre devant un régulateur, un auditeur ou un comité exécutif.

Testez le scénario vous-même

Le scénario NIS2 fait partie d’EDiTh, le benchmark entreprise ouvert de LightOn construit autour de Véracier Industries : un groupe industriel synthétique contenant 1 004 documents répartis entre sept filiales, six langues, des architectures industrielles, des audits cybersécurité et des documents opérationnels réalistes.

Posez la même question :

“Quels systèmes industriels entrent réellement dans le périmètre NIS2 et où sont nos écarts de conformité ?”

Puis vérifiez si votre système retrouve simplement des politiques cybersécurité, ou s’il identifie réellement les systèmes que vous devriez défendre devant un régulateur européen.

Commencez avec EDiTh. Puis testez-le sur vos propres documents.

Accédez à LightOn Console pour lancer le scénario vous-même.

Vous voulez comprendre comment le corpus a été construit, comment le retrieval a fonctionné et pourquoi cette réponse est si difficile à obtenir ? Lisez l’article de lancement d’EDiTh.

Précédemment dans Impossible Use Cases : « L’ambiguïté d’une clause de force majeure, démêlée en un prompt ».