Posture de conformité

Cette page décrit la position arrêtée de l’éditeur au regard de cinq règlements européens, et nomme ce qui reste une décision de droit non prise. Elle est publique et lisible sans compte : une posture de souveraineté qu’il faut demander pour lire n’est pas opposable.

Ce que cette page n’est pas

Ce n’est pas un avis juridique. Le dépôt s’interdit d’en produire, et cet interdit est un mécanisme, pas une intention. 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, 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 — sinon 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. Elles ne sont pas produites par cette page.

Les cinq règlements — positions arrêtées

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	—
RGPD	sous-traitant — le code routé contient des données personnelles (noms de commits, fixtures)	obligations de sous-traitant : registre des traitements, accord de sous-traitance. Aucune donnée client n’alimente d’entraînement, donc pas d’analyse d’impact « entraînement »	modéré	—
NIS2	sous les seuils (< 50 salariés et < 10 M€ de chiffre d’affaires)	pas entité régulée en direct — la taille tranche. Le règlement rattrape l’éditeur indirectement, par les clauses de chaîne d’approvisionnement de ses clients (Art. 21(2)(d))	indirect	—
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 ≥ 5 ans, 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. À traiter comme tel, jamais comme acquis	conditionnel	—

Deux lectures transversales tirées de la même source :

La première échéance dure est l’obligation de signalement CRA de septembre 2026. Elle change la portée de deux engagements jusque-là internes : la nomenclature logicielle (SEC-9.3-01) et la signature des artefacts (SEC-9.4-*) cessent d’être de la dette technique pour devenir 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 ; il n’est invoqué comme autorité dans aucun contrôle.

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

Cette détermination est publiée parce qu’elle protège l’acheteur autant que l’éditeur.

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, pas de SecNumCloud.

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 doivent être validés 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 jour.

Ce qui se dit, ce qui ne se dira jamais

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 ne sera écrit dans aucun document commercial, aucune réponse à questionnaire, aucune page de ce site.

Formulation défendable	Ce qui ne sera jamais 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 certification n’est détenue à ce jour. La présomption de conformité que la certification européenne EUCC apportera au CRA n’est pas finalisée ; elle ne sera pas présentée comme acquise.

Comment une affirmation est tracée

La posture ci-dessus s’appuie sur un référentiel technique, pas sur des déclarations. 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), son axe d’audit et son statut ; une proposition de modification référence les identifiants qu’elle couvre.

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

Un statut ne se relève jamais 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. C’est ce qui empêche une exigence commune au CRA et à NIS2 d’avoir deux vérités selon 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 demandera 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 — ce qui sort du poste, ce qui n’en sort pas.