Comment les règles de Scanara sont construites et vérifiées
Cette page s'adresse aux ingénieurs et aux responsables conformité qui veulent juger la fiabilité des règles de Scanara. Chaque règle renvoie à un article, un paragraphe et un point du règlement sur l'IA. Une version du jeu de règles doit passer six contrôles. La dernière section indique ce que les chiffres ne mesurent pas.
Mesuré le 9 septembre 2026.
Comment les règles sont construites
Le pipeline de règles de Scanara analyse le texte du règlement (UE) 2024/1689 tel que modifié et ancre chaque règle à son article, paragraphe et point exacts. Un unique fichier de correspondance attribue à chaque obligation l'un de trois résultats : détectable dans le code, vérifiable 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
Le jeu de règles passe six contrôles successifs, des vérifications structurelles larges jusqu'à une comparaison exacte avec une sortie de référence. Les six contrôles s'exécutent dans le pipeline CI de Scanara.
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
Contrôles structurels sur le corpus de règles : couverture des articles, pas de motifs en double, métadonnées complètes, valeurs d'énumération valides, identifiants de règle uniques et limites sur les 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 constat avec un résultat attendu enregistré, pour les 27 applications de test qui ont un instantané de référence, figée sur une version précise du jeu 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 documentaires de Scanara s'exécutent sur Open Policy Agent (OPA). OPA évalue la documentation technique par rapport aux obligations du règlement (UE) 2024/1689. C'est une approche policy-as-code : des règles déclaratives et une évaluation déterministe, de sorte qu'un même document donne le même résultat à 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 montre le principe, simplifié pour la documentation publique. Le jeu de règles de production est plus étendu et gère aussi plusieurs langues de documents et la pondération par gravité.
package eu_ai_act.example.article_11
# Illustrative pattern only — simplified for public documentation.
# Scanara's production ruleset is larger and also handles several document
# languages and severity weighting.
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 satisfiedDans l'instantané du 24 août 2026, des règles automatiques couvrent 66 des 113 articles (environ 58 %). Les règles de code couvrent 43 articles et les règles documentaires 23, dans 8 langues de documents de l'UE. Les autres articles sont traités par des évaluations guidées et de la documentation générée, ou concernent les autorités plutôt que les opérateurs. Ces chiffres sont un instantané daté et changent à chaque génération de règles. Les constats des deux moteurs alimentent le rapport de conformité, et chaque constat remonte à un résultat de scan réel, pas à une liste de contrôle autodéclarée.
Valeurs actuellement mesurées
| Métrique | Seuil | Actuel |
|---|---|---|
| Articles pris en compte par le pipeline de règles (119 dans le règlement) | 100% | 100% |
| Couverture par motifs réels des articles éligibles au code | 100% | 100% |
| Articles documentaires/politiques avec couverture OPA | 100% | 100% |
| Obligations détectables dans le code avec au moins une règle | 100% | 100% |
| Règles portant des métadonnées de niveau de risque | 100% | 100% |
| Règles portant des métadonnées d'acteur | 100% | 100% |
| Règles portant des recommandations de remédiation structurées | 100% | 100% |
| Écart du nombre de règles entre les 12 langages pris en charge | ≤ 1 | 0 |
| Identifiants de règles dupliqués | 0 | 0 |
| Règles stub (sans motif de code) par article | ≤ 1 | 0 |
| Seuils de KPI L4 franchis | 17/17 | 17/17 |
Ce que ces chiffres ne mesurent pas
Les valeurs de 100 % pour la couverture des articles signifient que le pipeline de règles prend chaque article en compte ; elles ne signifient pas que chaque article est vérifié automatiquement. Ces indicateurs mesurent la couverture, l'exhaustivité et le déterminisme : quelle part du règlement est cartographiée et avec quelle constance le pipeline se comporte d'un langage et d'une version à l'autre. Il n'existe pas d'indicateur de précision, de rappel ou de taux de faux positifs, car il faudrait un corpus de référence étiqueté par des humains que Scanara n'a pas. La preuve structurelle contre les faux positifs est la suivante : chaque fixture négative par obligation doit produire zéro constat, et une application de test à risque minimal, avec toutes les règles à haut risque, pour les modèles d'IA à usage général et à risque limité supprimées, doit aussi produire zéro constat.
Scanara détecte les écarts, dans le code et les documents, que couvrent ses règles. Il peut manquer du code personnalisé, non standard ou obscurci, et un scan réussi ne signifie pas qu'une organisation est conforme. La classification et l'interprétation juridique restent à votre charge et à celle de votre conseil.