Skip to main content

Comment les règles de Scanara sont construites et vérifiées

Chaque règle est ancrée à l'article, au paragraphe et au point exacts du règlement — et passe par six niveaux de vérification avant sa mise en production.

Mesuré le 4 août 2026 — revérifié à chaque version.

Comment les règles sont construites

Le pipeline de règles de Scanara analyse le texte intégral du règlement (UE) 2024/1689 et ancre chaque règle à son article, paragraphe et point exacts. Un unique fichier de correspondance classe chaque obligation du règlement en trois catégories : détectable dans le code, détectable dans un document de politique, ou non détectable automatiquement et confiée à une évaluation guidée.

L'échelle des portes de mise en production

Chaque version du référentiel de règles traverse six portes en série, des vérifications structurelles générales jusqu'à une comparaison exacte avec un résultat de référence. Une version n'est mise en production que si toutes les portes sont franchies.

L2.5

Cohérence du catalogue

Vérifie que le catalogue d'articles, la correspondance des obligations et les règles de suppression des chevauchements restent synchronisés entre eux.

L1/L2

Structure du corpus

Neuf vérifications structurelles sur le corpus de règles : couverture des articles, absence de motifs dupliqués, métadonnées complètes, valeurs d'énumération valides, identifiants de règles uniques, et limites de règles stub.

L3

Fixtures par obligation

Pour chaque obligation détectable dans le code, une fixture positive doit déclencher au moins un résultat et une fixture négative doit en déclencher zéro — dans chaque langage pris en charge.

L4

Seuils de KPI

17 seuils de couverture, d'exhaustivité et de déterminisme — voir le tableau ci-dessous.

L5

Instantanés de référence

Une comparaison exacte de chaque résultat avec un résultat attendu validé, sur 25 applications de benchmark, fixée à une version précise du référentiel de règles.

R1

Porte de remédiation

Confirme qu'une fixture brute déclenche un résultat non satisfait, et que la même fixture avec la remédiation recommandée appliquée est reconnue comme satisfaite.

Comment Scanara évalue la documentation avec OPA et Rego

Les contrôles de conformité de Scanara au niveau documentaire s'exécutent sur Open Policy Agent (OPA). OPA évalue la documentation technique par rapport aux obligations du règlement (UE) 2024/1689. Cela suit la même approche policy-as-code utilisée dans tout l'écosystème OPA : des règles déclaratives, une évaluation déterministe, un résultat auditable à chaque fois. Cela s'exécute en parallèle de l'analyse du code source de Scanara. L'analyse de code vérifie ce que fait le code. OPA vérifie ce que dit la documentation.

Chaque fichier de documentation suit les mêmes étapes. D'abord, Scanara l'analyse et détecte sa langue (8 langues de l'UE sont prises en charge). Ensuite, Scanara le normalise en un document d'entrée structuré : sections, titres, texte extrait. OPA évalue ce document structuré à l'aide d'un ensemble de règles Rego compilées.

Scanara génère ces règles à partir d'une correspondance canonique entre le texte des articles du règlement (UE) 2024/1689 et des exigences vérifiables automatiquement. Aucune règle n'est écrite à la main pour un dépôt donné. Chaque règle se rattache à un article, un paragraphe et un point précis. L'évaluation produit un constat par obligation : satisfaite, manquante ou partielle. Ces constats alimentent le rapport de conformité aux côtés des constats du code source.

L'exemple ci-dessous illustre le principe. Il est simplifié à des fins de documentation publique. Le jeu de règles en production couvre des dizaines de catégories d'obligations, avec en plus la détection multilingue, la pondération de gravité et des contrôles de cohérence entre documents non présentés ici.

package eu_ai_act.example.article_11

# Illustrative pattern only — simplified for public documentation.
# Scanara's production ruleset covers dozens of obligation categories with
# multi-language detection, severity weighting, and cross-document
# consistency checks not shown here.

default satisfied := false

# A document satisfies this (illustrative) Article 11 check when its parsed
# sections include the required topic, with non-empty content.
satisfied if {
	some section in input.document.sections
	section.topic == "risk_management_process"
	count(trim_space(section.content)) > 0
}

finding := {
	"article": "11",
	"obligation": "technical_documentation.risk_management_process",
	"status": "satisfied",
} if satisfied

finding := {
	"article": "11",
	"obligation": "technical_documentation.risk_management_process",
	"status": "missing",
	"severity": "high",
} if not satisfied

Ensemble, les deux moteurs détectent automatiquement 66 articles du règlement (UE) 2024/1689 : 44 éligibles au code et 22 documentaires via OPA. La couverture s'étend aux 8 langues de l'UE. Les constats des deux moteurs alimentent directement le dossier de conformité généré. La traçabilité des preuves remonte à un résultat de scan réel, pas à une simple déclaration.

Valeurs actuellement mesurées

MétriqueSeuilActuel
Couverture des articles (113 articles du règlement)100%100%
Couverture par motifs réels des articles éligibles au code100%100% (44/44)
Articles documentaires/politiques avec couverture OPA100%100% (22/22)
Obligations détectables dans le code avec au moins une règle100%100% (77/77)
Règles portant des métadonnées de niveau de risque100%100% (522/522)
Règles portant des métadonnées d'acteur100%100% (522/522)
Règles portant des recommandations de remédiation structurées100%100% (522/522)
Écart du nombre de règles entre les 12 langages pris en charge≤ 10
Identifiants de règles dupliqués00
Règles stub (sans motif de code) par article≤ 10
Seuils de KPI L4 franchis17/1717/17

Ce que ces chiffres ne mesurent pas

Ce sont des métriques de couverture, d'exhaustivité et de déterminisme — elles montrent quelle part du règlement est cartographiée et à quel point le pipeline se comporte de manière cohérente entre les langages et les versions. Il n'existe aucun KPI de précision, de rappel ou de taux de faux positifs, car cela nécessiterait un corpus de référence annoté par des humains que nous n'avons pas. La preuve structurelle contre les faux positifs est la suivante : chaque fixture négative par obligation doit produire zéro résultat, et une application de benchmark à risque minimal dédiée — où chaque règle à haut risque, GPAI et à risque limité est supprimée — doit également produire zéro résultat.

Scanara détecte les lacunes de conformité au niveau du code et des documents. Pour les interprétations juridiques complexes, nous recommandons de faire appel à un conseil juridique spécialisé.