Posture de conformité

Le dossier de sécurité fourni à l'appui de votre homologation, les textes de référence, la répartition des obligations entre l'éditeur et vous, et ce qui reste une décision de droit non prise.

Un composant logiciel n’est pas homologué en tant que tel : c’est le système d’information qui l’accueille qui l’est, par décision de votre autorité d’homologation. Lemniscate fournit le dossier du composant, c’est-à-dire les pièces qui décrivent ce qu’il fait, ce qu’il ne fait pas, et comment le vérifier (livre blanc sécurité V3, section 10).

Cette page décrit ce dossier, les textes qui structurent la conception du produit, la répartition des obligations entre l’éditeur et vous, et ce qui reste une décision de droit non prise. Elle est publique et se lit sans compte.

Ce que cette page n’est pas

Cette page n’est pas un avis juridique. Le corpus de conformité classe chaque contrôle selon qui a le droit de statuer (specs/2026-07-29-conformite/spec.md, §4) :

Vérifiabilité	Ce que le contrôle recouvre	Qui statue
`MACHINE`	vérifiable dans le dépôt ou l’intégration continue, avec preuve `fichier:ligne`	l’outillage, preuve à l’appui
`JUGEMENT`	constat argumenté sans assertion mécanique unique	l’outillage, avec une réserve explicite obligatoire
`JURIDIQUE`	détermination de droit : rôle CRA, rôle RGPD, entité NIS2, classe de risque AI Act	un humain, et lui seul ; sans arbitrage humain, le contrôle reste sans statut

Les déterminations reprises ci-dessous sont des arbitrages humains consignés, recopiés depuis specs/2026-07-29-conformite/spec.md §2. Cette page ne les produit pas.

Les pièces du dossier de sécurité

Le dossier accompagne le produit et il est tenu à jour à chaque version (livre blanc sécurité V3, section 10.1). Ses pièces sont conçues pour s’insérer dans votre dossier d’homologation sans réécriture.

Pièce	Ce qu’elle vous permet
Matrice de flux	vérifier chaque port et chaque destination avec vos propres outils ; aucun flux sortant
Cible de sécurité au format CSPN, remise sur demande	lire le périmètre de confiance (la passerelle et le bac à sable), les biens protégés, les menaces et les fonctions de sécurité
SBOM et VEX, générés à chaque version	connaître ce qui est livré, et l’état d’exploitabilité de chaque vulnérabilité publiée
Rapport des scénarios d’évasion	constater que le confinement a été éprouvé sur la version livrée
Schéma des événements journalisés	intégrer les journaux à votre SIEM
Guide d’installation et profils de confinement	reproduire la configuration de référence

La matrice de flux est reprise dans Architecture. La nomenclature, le dossier VEX et la vérification de l’artefact livré sont décrits dans Ce qu’un acheteur peut vérifier lui-même.

Les recommandations de l’ANSSI

Cinq textes de l’ANSSI structurent la conception de Lemniscate (livre blanc sécurité V3, section 10.2).

Texte	Ce que le produit y oppose
Guide PA-102, systèmes génératifs (2024)	cloisonnement dans un environnement dédié, limitation des actions automatiques, journalisation des traitements
ANSSI et BSI, assistants de programmation (2024)	déploiement dans le périmètre, aucune donnée confidentielle transmise à un tiers, revue humaine
ANSSI et BSI, zéro confiance et modèles de langage (2025)	droits minimaux, traçabilité des décisions, supervision humaine des décisions critiques
CERTFR-2026-ACT-016, agents sur poste (2026)	règles d’autorisation explicites, approbations d’exécution, isolement des processus, validation par la DSI et le RSSI
Architectures sensibles et Diffusion Restreinte	hôte d’exécution dédié, aucun moteur de conteneurs sur les postes, journaux vers le SIEM du réseau

Le bulletin CERTFR-2026-ACT-016 vise les assistants autonomes installés sur les postes, qui exécutent des commandes avec les droits de l’utilisateur. Les conditions qu’il pose correspondent à trois mécanismes du produit : les règles d’autorisation sont la politique du projet, les approbations d’exécution sont la validation par défaut, et l’isolement est le bac à sable (livre blanc sécurité V3, section 5.4). Ces mécanismes sont décrits dans Les garde-fous d’exécution.

La répartition des obligations

Les textes répartissent les obligations entre l’éditeur et vous (livre blanc sécurité V3, section 10.3).

Qui est visé	Texte	Ce que le produit apporte
Éditeur	Cyber Resilience Act, règlement (UE) 2024/2847	notification sous 24 h des vulnérabilités exploitées depuis septembre 2026 ; ensemble des exigences en décembre 2027
Client	NIS 2 et sa transposition française	journaux, contrôle d’accès, inventaire des composants et chaîne de livraison signée, à l’appui de vos obligations
Client	RGPD	données localisées chez vous ; l’éditeur ne traite aucune donnée personnelle pour son compte
Client	IGI 1300 et II 901	déploiement dans le périmètre homologué, aucun flux sortant, pièces fournies à l’autorité d’homologation
Client	ITAR et EAR	aucune transmission de données techniques hors du périmètre ; aucun réexport
Client	DO-178C et normes aéronautiques	code proposé soumis aux mêmes revues que toute contribution ; le journal établit qui a accepté quoi

NIS 2 et sa transposition française s’imposent à vous lorsque vous êtes entité essentielle ou importante. Les cadres de défense et de contrôle des exportations sont traités comme des contraintes d’architecture : aucun flux sortant, aucun tiers impliqué, aucune donnée technique hors du périmètre.

Les positions arrêtées de l’éditeur

Le tableau qui suit reprend, règlement par règlement, la position que l’éditeur a arrêtée sur son propre rôle.

Règlement	Rôle de l’éditeur	Position arrêtée	Poids	Échéances
AI Act	intégrateur de modèles de langage tiers ; n’entraîne ni ne spécialise aucun modèle	pas fournisseur GPAI, risque limité ; obligations de transparence Art. 50 seulement	léger	aucune
RGPD	produit installé dans votre périmètre : l’éditeur ne reçoit aucune donnée (livre blanc sécurité V3, sections 8.3 et 10.3)	le rôle se détermine par activité. Pour le produit installé chez vous, l’éditeur ne traite aucune donnée personnelle pour votre compte : il n’est ni sous-traitant ni responsable de traitement, et vous répondez vous-même à l’exercice des droits. Une prestation de support qui donnerait à l’éditeur un accès régulier à vos journaux ou à vos sessions ferait de lui un sous-traitant, sous contrat Art. 28. Aucune donnée client n’alimente d’entraînement	modéré	aucune
NIS2	sous les seuils (moins de 50 salariés et moins de 10 M€ de chiffre d’affaires)	pas entité régulée en direct : la taille tranche. Le règlement atteint l’éditeur indirectement, par les clauses de chaîne d’approvisionnement de ses clients (Art. 21(2)(d))	indirect	aucune
CRA	fabricant ; auto-évaluation Module A probable	le règlement structurant : nomenclature logicielle (Annexe I §2.1), divulgation coordonnée et point de contact (Art. 13(5)), mises à jour gratuites sur 5 ans au moins, signalement 24 h / 72 h / 14 j (Art. 14), documentation technique, marquage CE	lourd	signalement sept. 2026 · marquage CE déc. 2027
DORA	prestataire TIC tiers seulement si l’éditeur a des clients « entités financières »	conditionnel : s’active dans ce seul cas, par clauses Art. 30. Traité comme conditionnel, pas comme acquis	conditionnel	aucune

Deux lectures transversales :

La première échéance dure est l’obligation de signalement CRA de septembre 2026. Elle change la portée de deux engagements internes : la nomenclature logicielle (SEC-9.3-01) et la signature des artefacts (SEC-9.4-*) deviennent des exigences à échéance datée.
Les cinq règlements sont ancrés dans le droit de l’Union. Aucune de ces obligations ne dépend de la politique fédérale des États-Unis. Le format OSCAL, d’origine NIST, est employé comme format et comme référence croisée facultative ; aucun contrôle ne l’invoque comme autorité.

L’évaluation

L’éditeur donne au client les moyens de vérifier (livre blanc sécurité V3, section 10.4).

Test d’intrusion. Vous pouvez le réaliser, ou le confier à votre prestataire qualifié, sur le périmètre du premier déploiement. Le code et les artefacts sont fournis à l’auditeur.
Cible de sécurité. Elle est rédigée au format CSPN et remise sur demande. L’évaluation sera engagée lorsque le périmètre sera figé.
Politique de sécurité interne de l’éditeur. Elle est auto-évaluée selon le guide d’hygiène informatique de l’ANSSI, et l’état des mesures est communiqué sur demande.
Accès au code pour audit, sous accord de confidentialité.

SecNumCloud : ce que l’éditeur ne peut pas prétendre

SecNumCloud ne qualifie pas un éditeur de logiciel installé chez le client. Le référentiel v3.2 qualifie des prestataires de services cloud opérés ; il est rédigé en « le prestataire doit… ». Un logiciel que le client installe et exploite lui-même n’est pas un service opéré par l’éditeur. La qualification, si elle existe, appartient à l’hébergeur ou à l’opérateur, c’est-à-dire au client (specs/2026-07-29-conformite/spec.md, §2bis, vérifié sur le référentiel officiel v3.2).

Ce référentiel n’impose ni nomenclature logicielle composant par composant, ni provenance de construction. Le chapitre le plus proche (ch. 8.1.b) demande un inventaire des logiciels déployés avec leur version. L’attente d’une nomenclature complète vient du CRA.

Trois canaux de ruissellement contractuel

Des exigences retombent sur l’éditeur sans qu’il soit l’entité régulée :

SecNumCloud ch. 15.2 et 14.5 : un client qui fait qualifier un service incluant Lemniscate doit exiger de ses tiers (« développeur, intégrateur, sous-traitant », ch. 15.1.a) un niveau de sécurité « au moins équivalent », avec clauses d’audit (ch. 15.2.b).
LPM / OIV : un opérateur d’importance vitale impose par contrat à ses fournisseurs une Maintenance en Condition de Sécurité : veille, détection et remédiation des vulnérabilités.
NIS2 Art. 21.d : les clients entités essentielles évaluent la maturité cyber de leurs fournisseurs et insèrent des clauses de sécurité.

Réserve consignée dans la source : les chapitres SecNumCloud sont extraits du référentiel officiel v3.2, mais les numéros d’articles LPM et NIS2 proviennent de synthèses secondaires. Ils restent à valider article par article par un expert en sécurité des systèmes d’information ou un juriste. Cette réserve figure dans specs/2026-07-29-conformite/spec.md §2bis ; elle n’est pas levée.

Ce qui se dit et ce qui ne s’affirme pas

Le tableau ci-dessous est repris de specs/2026-07-29-conformite/spec.md §6. Il vaut engagement de langage : ce qui figure dans la colonne de droite n’est écrit dans aucun document commercial, aucune réponse à questionnaire, aucune page de ce site.

Formulation défendable	Ce qui n’est pas affirmé
« développé selon les exigences applicables de SecNumCloud v3.2 (ch. 14, 12.11, 8.1) et déployable au sein d’un environnement lui-même qualifié par son opérateur »	toute revendication d’une certification ou d’une qualification SecNumCloud portée par le produit, ou d’un agrément ANSSI
« conforme aux exigences applicables du CRA » (nomenclature, gestion des vulnérabilités, notification), en readiness	toute revendication d’une certification CRA, ou d’un marquage CE déjà obtenu
« facilite la conformité LPM et NIS2 de nos clients : clauses de sécurité et d’audit acceptées, maintenance en condition de sécurité, nomenclature fournie »	toute revendication de conformité NIS2 en propre : l’éditeur n’est pas l’entité régulée
« déployable hors ligne, sans flux sortant, souveraineté du déploiement »	aucune

L’éditeur ne détient aucune certification, et la cible de sécurité au format CSPN n’a pas encore fait l’objet d’une évaluation. La présomption de conformité que la certification européenne EUCC apportera au CRA n’est pas finalisée ; elle n’est pas présentée comme acquise.

Comment une affirmation est tracée

La posture ci-dessus s’appuie sur un référentiel technique. specs/securite/referentiel.md décompose le document d’architecture et de garanties de sécurité en 286 identifiants stables SEC-*. Chacun porte sa nature (CODE, CICD, DOC, ORGA, CONTRAT, HOTE) et son axe d’audit ; une proposition de modification référence les identifiants qu’elle couvre. Le statut de chaque exigence et la preuve qui l’établit vivent dans des relevés datés (specs/securite/snapshots/, un fichier par date), et non dans le référentiel lui-même.

Deux règles de méthode y sont attachées :

Un statut ne se relève pas sur la foi d’un fichier de configuration, mais sur celle d’un effet observé. Une option correctement écrite mais sans effet mesuré ne compte pas comme un contrôle tenu.
Un même fait technique n’a qu’un statut. Un contrôle réglementaire technique n’est pas réaudité : il hérite du statut des SEC-* correspondants, et le pire statut l’emporte. Une exigence commune au CRA et à NIS2 a donc une seule valeur, quel que soit le règlement invoqué.

Les décisions d’architecture de sécurité sont consignées dans specs/securite/arbitrages.md avec leurs options écartées et le critère qui a tranché, la forme attendue par un auditeur qui demande pourquoi telle voie a été retenue.

Ce qui reste une décision de droit non prise

Ces points portent, dans le corpus, un statut vide. Ils ne sont ni tranchés ni présentés comme tels.

Activation de DORA. L’éditeur vise-t-il des clients « entités financières » ? Tant que la question n’est pas tranchée, DORA reste une section conditionnelle inactive (specs/2026-07-29-conformite/spec.md, §8, décision ouverte n° 1). Rien n’est affirmé sur les clauses Art. 30.
Trajectoire de certification. ISO 27001 d’abord ou EUCC ensuite : l’ordre n’est pas arrêté (§8, décision ouverte n° 2). Aucune échéance n’est communiquée.
Validation article par article des références LPM et NIS2 du §2bis, par un expert humain, avant que le catalogue de contrôles réglementaires ne soit figé.

Pour aller plus loin

Ce qu’un acheteur peut vérifier lui-même : nomenclature logicielle, dossier VEX, scans, vérification de l’artefact livré.
Ce qui reste à construire : les axes spécifiés et non livrés, dits sans date.
Où passent les données : où vit chaque catégorie de données, et quels flux existent.
Les garde-fous d’exécution : les sept garanties d’une session et les mécanismes qui les tiennent.