Note d'architecture technique — Version 1.0

Statut Artefact public contrôlé
Version 1.0
Date de publication 2026-02-17
Juridiction Suisse
Périmètre Périmètre de démonstration

Énoncé du problème

Les systèmes d'autorisation conventionnels reposent sur l'inférence probabiliste, les seuils basés sur des scores ou la classification heuristique pour produire des décisions. Ces approches introduisent une ambiguïté au point de décision, rendant structurellement impossible la garantie de résultats déterministes dans des conditions adverses ou incomplètes. L'architecture décrite dans ce document adopte une approche par l'indétermination : le système est conçu pour produire une décision formellement bornée — incluant un état indéterminé explicite — pour chaque entrée. Cela élimine la classe d'erreurs résultant d'une résolution binaire forcée et garantit que chaque décision est traçable, rejouable et liée aux preuves. L'architecture n'infère pas l'intention, ne prédit pas les résultats et n'interpole pas les preuves manquantes. Elle évalue uniquement ce qui est présenté, dans des limites formellement déclarées.

Invariants formels

Les cinq invariants suivants sont des contraintes architecturales appliquées à chaque couche du système. Ils ne sont pas configurables, pas optionnels et ne peuvent pas être contournés à l'exécution.

1. Aucune inférence probabiliste

  • Définition: Le système n'emploie aucun apprentissage automatique, scoring statistique, inférence bayésienne ou toute forme de raisonnement probabiliste dans son chemin de décision.
  • Garantie: Chaque décision est produite par l’évaluation déterministe de règles de politique explicitement déclarées appliquées aux preuves présentées.
  • Limite: Les systèmes externes alimentant la plateforme en données peuvent utiliser des méthodes probabilistes ; cet invariant s'applique strictement au chemin d'évaluation des décisions.

2. Extraction liée aux preuves

  • Définition: Aucune décision ne peut être produite sans un dossier de preuves complet. Le système ne fabrique pas, ne suppose pas et ne substitue pas les champs de preuve manquants.
  • Garantie: Chaque sortie de décision est accompagnée d'un ensemble de preuves cryptographiquement lié, présent au moment de l'évaluation.
  • Limite: La complétude des preuves est définie par le schéma de politique. Le système ne valide pas la véracité des preuves — uniquement leur présence structurelle et leur conformité de format.

3. Rejouabilité déterministe

  • Définition: Étant donné la même version de politique et le même ensemble de preuves, le système doit produire une sortie de décision identique à chaque exécution.
  • Garantie: Le rejeu de décision est une capacité d'audit de première classe. Toute décision historique peut être réévaluée avec ses entrées originales pour vérifier la cohérence.
  • Limite: La rejouabilité suppose un versionnage immuable des politiques. Si une version de politique est modifiée en place (une violation du protocole opérationnel), les garanties de rejeu ne tiennent pas.

4. Architecture non auto-exécutante

  • Définition: Le système produit des décisions mais ne les applique pas. Il n'a aucune capacité d'exécuter des actions, de modifier des systèmes externes ou de déclencher des effets en aval de manière autonome.
  • Garantie: La sortie de décision est un artefact consultatif. L'application est toujours déléguée au système appelant, qui conserve le contrôle total de l'exécution des actions.
  • Limite: Les schémas d'intégration peuvent automatiser des actions basées sur la sortie de décision. Une telle automatisation est externe à l'architecture et hors du périmètre de cet invariant.

5. Frontière de contrôle humain

  • Définition: Chaque décision produite par le système est soumise à la revue et au contrôle humain. L'architecture n'inclut aucun chemin contournant l'autorité humaine.
  • Garantie: Les événements de contrôle sont enregistrés dans le même registre en ajout seul que les décisions originales, préservant la chaîne d'audit complète incluant l'identité et la justification du contrôle.
  • Limite: La plateforme fournit le mécanisme d’enregistrement des contrôles. Les politiques organisationnelles régissant quand les contrôles sont permis sont hors du périmètre du système.

Définition de la garantie déterministe

Une décision est considérée déterministe si et seulement si toutes les conditions suivantes sont remplies :

  • La version de politique utilisée pour l'évaluation est immuable et verrouillée au moment de la requête.
  • L'ensemble de preuves est complet tel que défini par le schéma de politique, sans champs inférés ou substitués.
  • La fonction d'évaluation ne contient aucun effet de bord, aucun appel externe et aucune entrée aléatoire.
  • La sortie est l’un des trois états exactement : AUTORISER, REFUSER ou INDÉTERMINÉ.
  • La paire entrée-sortie complète est enregistrée dans un registre en ajout seul et est disponible pour une vérification indépendante par rejeu.

Pile de vérification

OmegaOS™ est conçu avec une pile de vérification multicouche destinée à détecter les défauts logiques, les violations d’invariants et les transitions d’état inattendues. Le processus de vérification combine plusieurs techniques complémentaires :

  • Mutation testing — vérifie que les tests détectent les défauts injectés.
  • Property-based testing — explore de vastes espaces d’entrées aléatoires.
  • Differential testing — compare des implémentations indépendantes de la logique centrale.
  • Coverage-guided fuzzing — soumet les composants critiques à des entrées adversariales.
  • Formal verification (Kani) — prouve les propriétés algébriques et logiques du kernel triléen.
  • Model checking (TLA+) — valide les invariants système et les transitions d’état.

Métriques de vérification

600+

tests de mutation

0

mutants survivants en production

13M+

exécutions de fuzzing

100K+

cas property-based

13

preuves formelles (Kani)

3M+

états vérifiés par modèle (TLA+)

700+

cas de tests déterministes

code → tests → mutation testing → fuzzing → formal proofs → model checking

Ces techniques vérifient les composants non-SOVEREIGN du système. Les modules SOVEREIGN restants sont implémentés hors ligne et seront vérifiés avec le même pipeline une fois terminés.

Clause de périmètre de démonstration

Cet artefact décrit une architecture telle qu'implémentée dans un environnement de démonstration contrôlé. Il ne représente pas un déploiement en production, un système certifié ou un service exploité commercialement. L'environnement de démonstration fonctionne avec des données synthétiques, des conditions de charge contraintes et un périmètre locataire limité. Aucune affirmation n'est faite concernant la scalabilité, la disponibilité ou la certification réglementaire de l'architecture décrite. Les organisations évaluant ce système pour un déploiement opérationnel doivent conduire leur propre évaluation indépendante de l'adéquation à l'usage.

Empreinte d'intégrité

L’empreinte cryptographic hash sera publiée conjointement avec l’artefact PDF signé. Contactez l’équipe d’ingénierie pour obtenir la version signée sous NDA.

Contacter l’équipe

Demander l'artefact complet

Obtenez la note d'architecture technique complète sous forme de document portable, sous NDA.

Demander le PDF