Dernière mise à jour :
Le catalogue POSITRONIA-RULES est structuré pour couvrir des cas que personne d'autre ne couvre. Plus la couverture est pertinente — pas seulement volumineuse — plus POSITRONIA devient incontournable pour le solopreneur IA et la TPE européenne.
Cette page donne la structure du catalogue, pas la liste exhaustive des règles.
Chaque règle est classée selon sa valeur stratégique :
| Tier | Sens | Rôle |
|---|---|---|
| T1 — Essentielle | Les fondamentaux que tout scanner sérieux finit par avoir : clés en dur, crypto faible, secrets. | Nécessaire, comble le trou de crédibilité. |
| T2 — Différenciatrice | Les règles que personne d'autre n'écrit, parce que personne n'a notre positionnement (solopreneur IA + souveraineté EU + chaîne IA bout-en-bout). | C'est la marque. Justifie le prix. |
| T3 — Pré-screen → scorer | Cas qui exigent un raisonnement contextuel : le moteur émet une piste, un scorer la confirme avec raisonnement traçable. | Transforme une limite technique en architecture. |
Le catalogue est organisé en familles cohérentes. En voici les axes principaux, avec des exemples parlants.
Les fondamentaux de la sécurité des données personnelles : clé API en dur,
secret ou chaîne de connexion dans le code, clé LLM exposée côté navigateur
(NEXT_PUBLIC_* — l'erreur n°1 du solopreneur), HTTP sans TLS, CORS en wildcard,
PII en localStorage. Articles couverts : Art. 5, 25, 28, 30, 32, 35.
Exemple : une clé
sk-…écrite en dur déclenche une règle Art. 32, avec une recommandation de remédiation.
La famille la plus distinctive, parce qu'elle vise exactement ce que construit le solopreneur IA aujourd'hui : des applications RAG et des agents.
Exemple : des embeddings de données utilisateur stockés dans un vector store (Qdrant, Pinecone, pgvector…) sans chemin d'effacement déclenche une règle Art. 17 (droit à l'effacement). Personne ne vérifie l'effacement sur un vector store — c'est précisément le genre de cas que POSITRONIA couvre.
Autres exemples : historique de conversation sans TTL (Art. 5.1.e + 17), champ PII interpolé dans un prompt envoyé à un LLM tiers (Art. 9 / 5 + 44).
La conformité de la chaîne IA, en entrée et en sortie.
Exemple : génération d'image, d'audio ou de vidéo (DALL·E, Stable Diffusion, ElevenLabs…) sans marquage de provenance déclenche une règle Art. 50.2. Un endpoint chatbot sans la mention « vous parlez à une IA » déclenche Art. 50.1.
Articles couverts : Art. 5 (pratiques interdites), Art. 10 (gouvernance des données d'entraînement), Art. 15 (robustesse), Art. 50 (transparence), Annexe IV (épinglage de version pour la reproductibilité de l'audit).
Une catégorie que personne d'autre ne traite : le « linting de souveraineté ». Chaque finding suggère l'alternative européenne.
Exemple : un appel LLM direct vers une API hors-UE sans passage par une région européenne, ou une région cloud US codée en dur (
us-east-1), déclenche une règle Art. 44 (transferts hors UE) — avec suggestion d'alternative souveraine.
Autres exemples : Google Analytics (sanctionné par la CNIL), endpoints SaaS US, API IA propriétaire du navigateur.
Une règle de souveraineté qui recommande une alternative européenne ne la valorise que si l'hébergement effectif est réellement EU et qu'une DPA EU est en place. Un fournisseur européen hébergé hors UE retombe dans le flux standard « audit des transferts ». Toute recommandation produite avec l'aide d'un LLM est marquée AI Act Art. 50.
Bientôt. D'autres cadres (DORA, NIS2, Cyber Resilience Act, DSA) et l'extension systématique des règles à davantage de langages sont ancrés au backlog pour les phases ultérieures. Ils ne font pas partie du périmètre V1.
Voyez Licence et fonctionnement hors ligne pour comprendre l'activation et l'usage air-gappé.