Conformité et audit IA | Architecture Rust certifiable | Lexiane

Les exigences de conformité applicables aux systèmes d’intelligence artificielle se durcissent. IEC 62304 Ed. 2, ISO 26262, DORA, NIS2, RGPD, AI Act : les référentiels s’accumulent, leurs périmètres se chevauchent, et les délais se resserrent. La plupart des organisations qui cherchent à déployer de l’IA en environnement régulé font face à la même réalité : les solutions disponibles ont été conçues pour d’autres contextes, et la conformité y est traitée comme une couche à ajouter après coup — un processus documentaire sur un système qui ne la rend pas possible par nature.

Lexiane est conçu dans l’ordre inverse. La conformité n’est pas une fonctionnalité. C’est la conséquence directe d’un ensemble de décisions architecturales prises dès les premières lignes de code.

---

L’IA réglementée : ce que vos auditeurs vont chercher — et ce que la plupart des systèmes ne peuvent pas leur fournir

Un auditeur travaillant sur un système IA en environnement régulé pose invariablement les mêmes questions fondamentales.

Traçabilité. Qui a décidé quoi, sur quelle base, à quel moment ? Pour un système de traitement documentaire ou de génération de réponses, cela signifie : quel document a été ingéré, par quel pipeline, avec quels paramètres ? Quelle décision de filtrage a été appliquée, sur quelle donnée ? Quelle réponse a été produite, à partir de quelles sources ?

Isolement des composants tiers. Dans les référentiels IEC 62304 et ISO 26262, un composant logiciel dont le code source n’est pas entièrement maîtrisé par le fabricant est classifié comme SOUP — Software of Unknown Provenance. Le SOUP doit être identifié, documenté, et son interface avec le système certifié doit être explicitement délimitée. Sur un système Python typique, cette frontière est structurellement impossible à tracer : les bibliothèques s’importent mutuellement, les dépendances transitives sont nombreuses, et la ligne entre code maîtrisé et code SOUP est floue par nature.

Déterminisme et absence de comportement indéfini. Un système certifié doit se comporter de façon prévisible. Un garbage collector qui déclenche une pause à un moment critique, un bug de type masqué par le typage dynamique de Python, une dépendance implicite entre deux modules — chacun de ces phénomènes est une source de comportement non déterministe qu’un auditeur ne peut pas accepter sans compensation.

Souveraineté des données. Dans les environnements régulés — défense, santé, finance, secteur public —, la question de la localisation des données n’est pas une préférence. C’est une exigence réglementaire ou opérationnelle dont le non-respect expose l’organisation à des sanctions, des responsabilités, ou des risques souverains.

Lexiane a été conçu pour répondre à ces quatre exigences — pas par déclaration, mais par des mécanismes vérifiables à l’inspection du code et de l’architecture.

---

Une architecture dont les propriétés de conformité sont prouvées à la compilation

Le périmètre certifié : un noyau sans concession

Le cœur de Lexiane — vectrant-core — est soumis à une contrainte absolue : #![forbid(unsafe_code)]. Cette directive n’est pas une convention de développement ni une règle de revue de code. Elle est appliquée par le compilateur Rust lui-même. Aucun développeur ne peut introduire une opération mémoire non vérifiée dans le périmètre certifié, même par inadvertance, même sous pression — le compilateur rejette le code avant que le binaire n’existe.

Dans ce périmètre, les propriétés suivantes sont garanties mécaniquement :

• Absence de pointeurs nuls : les valeurs optionnelles sont exprimées via Option<T>, dont le traitement est exhaustif et vérifié à la compilation.
• Absence de fuites mémoire et de use-after-free : le système de propriété de Rust élimine ces catégories de bugs par construction — sans garbage collector, sans runtime supplémentaire.
• Absence de chemins d’erreur ignorés : le marqueur #[must_use] est appliqué sur l’ensemble des résultats. Un chemin d’erreur non traité est une erreur de compilation, pas un bug découvert en recette ou en production.
• Absence de unwrap(), expect() ou panic!() en code de production : vérifié par un test automatisé en intégration continue. Toute régression est détectée immédiatement.

Ce que cela représente pour un auditeur : un périmètre dont les propriétés de sécurité sont prouvées à la compilation, indépendamment des pratiques des développeurs individuels.

L’isolement du SOUP : une frontière architecturale, pas documentaire

Lexiane est structuré selon une architecture hexagonale stricte. Le cœur certifié communique avec le monde extérieur exclusivement via 25 interfaces d’abstraction typées — des contrats d’interface explicites, vérifiés statiquement. Aucune dépendance externe ne peut pénétrer dans le noyau sans passer par l’une de ces interfaces.

Les composants tiers — modèles de langage, bases vectorielles, parseurs de documents, APIs cloud — sont des adaptateurs qui implémentent ces interfaces. Ils sont intégralement classifiables comme SOUP, avec une frontière architecturale nette et vérifiable : la liste des interfaces. Ce qui est à l’intérieur est maîtrisé. Ce qui est à l’extérieur est documenté et isolé.

Une contrainte complémentaire renforce cette séparation : le noyau certifié ne contient zéro dépendance vendor — vérifié par un test automatisé qui échoue à la compilation si une dépendance externe y est introduite. Ce test fait partie de la suite d’intégration continue : la régression est impossible sans qu’elle soit détectée immédiatement.

La validation statique des dépendances entre composants

Le pipeline de Lexiane valide ses dépendances internes à l’assemblage, avant toute exécution. Chaque étape déclare les données qu’elle consomme et les données qu’elle produit. L’assembleur vérifie statiquement que l’ensemble des dépendances est satisfait avant que le pipeline ne démarre.

Pour un auditeur, cela signifie qu’une erreur de configuration — une étape manquante, une dépendance non satisfaite, un composant mal connecté — n’est pas un bug qui apparaît à l’exécution sur une donnée réelle. C’est une erreur d’assemblage détectée avant que le système ne traite un seul document.

---

Conformité RGPD : la protection des données par architecture

La résidence des données comme propriété physique

Le RGPD impose une localisation des données personnelles dans des conditions que le responsable de traitement peut contrôler et documenter. La plupart des solutions IA cloud satisfont cette exigence par contrat : une clause stipule que les données restent dans une zone géographique définie. La conformité repose sur la confiance dans le respect de ce contrat par le prestataire.

Lexiane offre une alternative différente de nature : dans sa configuration air-gapped, les données ne quittent pas votre périmètre parce que l’architecture le rend physiquement impossible — pas parce qu’un contrat l’interdit. Il n’y a pas d’appel réseau à surveiller ni de flux à auditer : le binaire ne dispose d’aucune interface réseau active vers l’extérieur. Aucun document, aucun fragment, aucun embedding ne peut sortir de votre infrastructure.

Pour un délégué à la protection des données, la différence est fondamentale : il s’agit d’une garantie architecturale, pas d’une garantie contractuelle.

Le filtrage PII : avant la donnée, pas après

Le filtre de données personnelles de Lexiane opère en amont du pipeline — avant toute vectorisation, toute indexation, tout appel à un modèle de langage. Les catégories détectées couvrent les données personnelles les plus courantes dans les corpus documentaires professionnels : adresses électroniques, numéros de téléphone, IBAN, numéros de sécurité sociale, adresses IP.

Trois politiques de traitement sont disponibles et configurables par catégorie de donnée :

• Masquage typé — la valeur est remplacée par un placeholder sémantique ([EMAIL], [IBAN], [NIR]). Le type de la donnée reste lisible pour le traitement sémantique. La valeur est inaccessible.
• Suppression — la valeur est retirée du fragment avant toute transmission au pipeline.
• Hachage — la valeur est remplacée par son empreinte cryptographique. La cohérence référentielle est préservée sans exposer la donnée en clair.

La conformité RGPD n’est pas traitée comme une étape de post-production. Elle est inscrite dans le flux de traitement comme une contrainte préalable à toute opération sensible.

L’audit trail comme registre de traitement

Le RGPD impose aux responsables de traitement de tenir un registre des activités de traitement et de pouvoir démontrer la conformité de leurs traitements sur demande d’un régulateur. L’audit trail cryptographique de Lexiane constitue un registre technique de chaque opération effectuée sur chaque document : identité du document, horodatage, opérations appliquées, politiques de filtrage activées, accès utilisateurs.

Ce registre n’est pas un journal de logs. C’est une chaîne SHA-256 : chaque entrée est signée par le hash de la précédente. Toute modification rétrospective d’un enregistrement est mathématiquement détectable. La preuve de conformité est dans la chaîne elle-même — pas dans une déclaration.

---

Réglementations sectorielles : ce que Lexiane rend possible

Santé et dispositifs médicaux — IEC 62304 Ed. 2

La révision de la norme IEC 62304, dont la publication est prévue pour août 2026, introduira pour la première fois des exigences explicites sur les logiciels embarquant des composants d’intelligence artificielle et de machine learning. Pour les fabricants de dispositifs médicaux qui développent ou intègrent aujourd’hui des systèmes documentaires basés sur l’IA, cette échéance n’est pas lointaine : un cycle de certification se compte en années, pas en mois.

Lexiane est le seul moteur RAG conçu depuis ses fondations pour répondre à ce référentiel :

• Périmètre certifié avec #![forbid(unsafe_code)] — les propriétés de sécurité sont vérifiables à la compilation
• Isolation explicite du SOUP par architecture hexagonale — les dépendances tierces sont documentées et délimitées par des interfaces typées
• Audit trail SHA-256 sur chaque décision du pipeline — la traçabilité est structurelle, pas optionnelle
• Compatibilité avec Ferrocene — le compilateur Rust qualifié IEC 62304 et ISO 26262 (voir ci-dessous)
• Absence de comportement indéfini garanti par le système de types — les catégories de bugs classifiées comme risques dans IEC 62304 sont éliminées par construction

Pour un fabricant de dispositifs médicaux, cela signifie que le dossier de qualification du composant logiciel IA peut s’appuyer sur des preuves mécaniques — pas seulement sur des processus déclarés.

Automobile et systèmes embarqués — ISO 26262

L’intégration de l’IA dans les systèmes embarqués automobiles soulève des questions de sécurité fonctionnelle que ISO 26262 ne peut ignorer. Un système qui traite de l’information sur un véhicule — manuels techniques, diagnostics, bases de connaissance produit — doit satisfaire des exigences de déterminisme et d’auditabilité incompatibles avec les caractéristiques structurelles des frameworks Python.

Lexiane répond à ces exigences par deux propriétés fondamentales :

L’absence de garbage collector. Rust gère la mémoire statiquement, sans mécanisme de collecte automatique. Il n’y a pas de pause GC imprévisible susceptible de violer une contrainte temps-réel. Le comportement temporel du système est déterministe par construction — une propriété que les runtimes Python ou JVM ne peuvent pas offrir.

Le binaire statique autonome. Lexiane se compile en un seul binaire sans dépendance dynamique. Il ne nécessite pas d’interpréteur, pas de machine virtuelle, pas de gestionnaire de paquets. Dans un environnement embarqué sans connectivité réseau permanente, cette propriété est essentielle : le système fonctionne tel qu’il a été qualifié, sans dépendance à un environnement d’exécution externe susceptible d’évoluer.

Compilable avec Ferrocene, Lexiane peut être intégré dans un dossier de qualification ASIL D — le niveau le plus exigeant de la norme ISO 26262.

Finance — DORA et exigences prudentielles

Le règlement DORA (Digital Operational Resilience Act), applicable depuis janvier 2025, impose aux entités financières des exigences renforcées de résilience opérationnelle numérique, de gestion des risques liés aux tiers, et de traçabilité des systèmes critiques.

Pour une institution financière qui déploie un système IA sur des données internes — rapports de risque, documentation réglementaire, procédures opérationnelles —, Lexiane apporte des garanties directement pertinentes :

• Indépendance vis-à-vis des tiers : chaque composant de Lexiane est interchangeable via ses interfaces d’abstraction. La dépendance à un fournisseur unique de LLM ou d’embeddings est éliminée par architecture. Si un prestataire devient indisponible ou modifie ses conditions, la migration ne touche pas au pipeline ni aux données indexées.
• Traçabilité des décisions : l’audit trail SHA-256 documente chaque accès aux données, chaque réponse produite et ses sources. Pour un contrôleur ou un auditeur interne, chaque décision du système est reconstituable.
• Déploiement on-premise total : les données financières sensibles ne transitent pas par des infrastructures tierces. La localisation est maîtrisable et documentable.

Secteur public — RGPD, NIS2 et souveraineté numérique

Les administrations publiques sont soumises à une double contrainte structurelle : traiter des volumes croissants de documentation réglementaire et administrative, tout en garantissant que les données des citoyens et les informations sensibles restent sous contrôle souverain.

NIS2, RGPD, et les orientations croissantes vers des solutions qualifiées SecNumCloud rendent incontournable la question de la résidence des données et de l’auditabilité des systèmes IA. Lexiane offre ici une réponse architecturale : le déploiement air-gapped exclut structurellement tout transfert de données vers un prestataire tiers, indépendamment de sa localisation ou de ses engagements contractuels.

---

Ferrocene : quand le compilateur lui-même fait partie du dossier de qualification

La chaîne de confiance d’un système certifié ne s’arrête pas au code source. Elle inclut l’outil qui transforme ce code en binaire exécutable. C’est l’enjeu de la qualification du compilateur.

Ferrocene est la version qualifiée du compilateur Rust, développée par Ferrous Systems. Il est qualifié ISO 26262 jusqu’au niveau ASIL D (systèmes automobiles) et IEC 61508 SIL 4 (sécurité fonctionnelle industrielle). La qualification IEC 62304 Ed. 2, qui intégrera des exigences explicites sur les systèmes IA/ML, est anticipée pour accompagner la publication de la norme en 2026.

Ferrocene fournit à ses utilisateurs des packages d’évidence — des ensembles documentaires structurés qui permettent à l’auditeur de vérifier que le compilateur lui-même satisfait les exigences du référentiel cible. La chaîne de confiance est complète : du code source, au compilateur, jusqu’au binaire déployé en production.

Lexiane est conçu pour être compilé avec Ferrocene. Pour un fabricant de dispositifs médicaux, un équipementier automobile ou un intégrateur de défense, cela signifie qu’il n’y a pas de maillon manquant dans le dossier de qualification.

Aucun framework RAG Python ne peut offrir une telle garantie. Pas par manque de soin de ses développeurs — mais parce que Python ne dispose pas d’un compilateur qualifié équivalent, et que l’ensemble de ses dépendances d’exécution constituerait un volume de SOUP que nul référentiel de certification ne peut absorber raisonnablement.

---

Ce que vos auditeurs obtiennent concrètement

Un dossier de qualification ou un audit de conformité sur un système IA nécessite des preuves — pas des déclarations. Voici ce que Lexiane met à disposition :

Périmètre certifié délimité et vérifiable Le noyau certifié est un module de compilation autonome (vectrant-core), sans dépendance vendor, dont les propriétés de sécurité sont appliquées par le compilateur. Sa frontière est la liste de ses 25 interfaces d’abstraction. Elle est précise, stable, et inspectable.

Audit trail SHA-256 exportable Chaque action du pipeline est enregistrée dans une chaîne cryptographique dont l’intégrité est vérifiable mathématiquement. Le registre est exportable et consultable indépendamment du système en production.

Suite de tests automatisée en intégration continue 1 254 tests passent en continu. Aucun test n’est désactivé par commodité — les 39 tests ignorés le sont explicitement parce qu’ils nécessitent une infrastructure externe (instance Qdrant, clé API, modèle téléchargé), et cette désactivation est documentée. La distinction entre tests unitaires, tests d’intégration et tests nécessitant une infrastructure est explicite dans la structure du projet.

Validation statique de la configuration à l’assemblage Les erreurs de configuration du pipeline sont détectées à l’assemblage, avant exécution. Un pipeline mal configuré ne peut pas démarrer. Cette propriété réduit la surface des comportements indéfinis en production.

Documentation de l’isolement SOUP Les 25 interfaces d’abstraction constituent la liste complète des points de contact entre le noyau certifié et les composants tiers. Chaque interface est documentée, typée, et testée. L’ensemble des dépendances externes sont des adaptateurs qui implémentent ces interfaces — leur statut SOUP est délimité par architecture.

---

Questions fréquentes des responsables conformité

Notre référentiel impose une qualification du compilateur. Est-ce que Rust/Ferrocene est reconnu ? Ferrocene est qualifié ISO 26262 ASIL D et IEC 61508 SIL 4. La qualification IEC 62304 est en cours d’élaboration pour accompagner la révision de la norme. Pour d’autres référentiels, Ferrous Systems fournit des packages d’évidence qui permettent d’engager le dialogue avec votre organisme de certification.

Nous devons documenter tous les composants SOUP. Comment Lexiane le facilite-t-il ? L’architecture hexagonale de Lexiane délimite le SOUP par construction : tout composant externe implémente une interface d’abstraction typée. La liste des interfaces est la liste complète des frontières SOUP. Les dépendances transitives de chaque adaptateur sont isolées dans leur propre module de compilation, sans accès au noyau certifié.

Notre auditeur demande à inspecter le code du système. Comment y accédons-nous ? Lexiane est distribué sous licence Apache 2.0 — le code source est intégralement disponible et inspectable. Il n’y a pas de composant fermé, pas de module binaire opaque, pas de fonctionnalité dont le comportement ne serait pas vérifiable dans le code.

Nous devons démontrer que les données personnelles ne quittent pas notre périmètre. Comment en apporter la preuve ? En configuration air-gapped, Lexiane ne dispose d’aucune interface réseau active vers l’extérieur. La preuve n’est pas contractuelle — elle est architecturale. Un auditeur peut vérifier, à l’inspection du binaire et de sa configuration, qu’aucun appel réseau sortant n’est possible. C’est une propriété différente de nature d’un engagement de confidentialité fournisseur.

Nous envisageons une certification dans 18 mois. Par où commencer ? L’anticipation est précisément ce que Lexiane permet. Sa conception pour la certification signifie que les propriétés requises sont présentes dès le déploiement — elles n’ont pas à être ajoutées rétrospectivement. Nous proposons un échange sur votre référentiel cible, votre périmètre, et les étapes de votre processus de qualification.

---

Engager la conversation sur votre contexte réglementaire.

Chaque référentiel de certification pose ses propres exigences. Chaque secteur a sa propre lecture de la conformité IA. Nous ne proposons pas de réponse générique.

Nous proposons un échange avec quelqu’un qui connaît les contraintes des environnements régulés, les enjeux de la certification logicielle, et ce que l’architecture de Lexiane permet concrètement dans votre contexte.

Ce que vous pouvez attendre de cet échange :

• Une réponse sous 48h ouvrées
• Un interlocuteur technique qui connaît IEC 62304, ISO 26262, DORA et le RGPD dans leur rapport à l’IA
• Une évaluation honnête de l’adéquation entre Lexiane et vos exigences de certification — y compris si des développements complémentaires sont nécessaires