Le système de règles POSITRONIA-RULES

Un moteur d'analyse maison

POSITRONIA-CORE s'appuie sur POSITRONIA-RULES, le moteur d'analyse statique développé en interne par EuTrustedIA. Il est écrit en Python pur, utilise tree-sitter pour comprendre la structure du code (l'arbre syntaxique), et tourne nativement sous Linux, macOS et Windows — y compris ARM64 — sans dépendance système externe.

Ce moteur est le cœur de notre différenciation : les règles sont les nôtres, le moteur est le nôtre. La brique de parsing tree-sitter reste une dépendance open source (sous licence Apache 2.0), mais la logique d'analyse et le catalogue de règles sont propres à EuTrustedIA.

Comment une règle est structurée

Une règle décrit ce qu'on cherche et pourquoi c'est un problème de conformité. Elle est déclarée en YAML, dans un format lisible :

rules:
  - id: rgpd-art32-crypto-faible       # identifiant unique, préfixé par la régulation
    message: |
      Crypto faible détectée (MD5/SHA-1) — RGPD Art. 32.1 : mesures techniques
      appropriées au risque non satisfaites pour des données personnelles.
    severity: WARNING                  # INFO | WARNING | ERROR | CRITICAL
    languages: [python, javascript, java]
    metadata:
      regulation: rgpd                 # rgpd | ai_act
      article: "RGPD Art. 32.1"
      remediation: |
        Remplacer hashlib.md5() par hashlib.sha256(), ou pour les mots de passe
        utiliser argon2id.
    patterns:
      - kind: function_call
        name: [hashlib.md5, hashlib.sha1]

Chaque règle porte un rattachement réglementaire explicite (regulation + article) qui apparaît dans le rapport. Chaque finding renvoie ainsi à l'article de droit qu'il documente.

Ce que les règles savent détecter

POSITRONIA-RULES combine plusieurs types de détecteurs (« matchers ») :

• Appel de fonction — détecte un appel précis dans le code (ex. hashlib.md5), via l'arbre syntaxique. Plus fiable qu'une simple recherche de texte : ignore les commentaires et les chaînes.
• Import de module — détecte l'usage d'un module (ex. pickle, subprocess).
• Recherche textuelle — applique une expression régulière sur le code brut, pour les cas où l'AST n'est pas nécessaire.
• Présence / absence de fichier — vérifie qu'un fichier attendu existe (ex. un registre des traitements) ou qu'un fichier sensible est absent.
• Frontmatter — vérifie les métadonnées en tête des fichiers Markdown/MDX (ex. une mention de divulgation IA requise).

Langages couverts

Une quinzaine de langages sont pris en charge via la même base tree-sitter : Python, JavaScript, TypeScript / TSX, Java, Go, Rust, PHP, Ruby, C / C++, C#, Kotlin, Swift — plus Markdown, YAML, JSON, HTML, CSS, Bash et SQL pour les détecteurs de configuration et de documentation.

Calibrage de la sévérité

Pour un produit de conformité, une règle qui crie au loup détruit la confiance — c'est pire qu'une règle absente. La sévérité est donc calibrée volontairement :

Chaque règle est livrée avec deux jeux de tests — un cas qui doit déclencher et un cas qui ne doit pas déclencher — pour borner les faux positifs.

Ce que le moteur ne fait pas (encore)

Honnêteté sur le périmètre actuel : POSITRONIA-RULES détecte des motifs syntaxiques (appels, imports, expressions). Il ne réalise pas encore d'analyse de flux de données profonde — suivre une valeur sensible à travers plusieurs fonctions. Ce niveau d'analyse est prévu en Phase B.

Les cas qui exigent un raisonnement contextuel (ex. « cette entrée utilisateur finit-elle dans un prompt sans filtrage ? ») sont traités selon une logique « détection syntaxique d'abord, confirmation par scorer ensuite » : le moteur émet une piste peu coûteuse, qu'un scorer dédié confirme ou écarte avec un raisonnement traçable.

Étape suivante

Voyez l'aperçu du catalogue de règles pour les familles couvertes (RGPD, AI Act, souveraineté EU).