Sécurité & confiance

Une architecture pensée pour garder le contrôle.

La sécurité repose sur l’isolation des organisations, les sessions et permissions vérifiées côté serveur, ainsi que sur des traces consultables. Ces mécanismes donnent un cadre pour examiner qui peut accéder aux données et comment une décision a été préparée. Ils ne valent pas certification ou attestation de conformité.

Pourquoi cette approche

La sécurité doit être vérifiable dans la manière dont les données circulent. Le serveur décide qui peut voir ou modifier quoi ; les traces permettent de comprendre les opérations, tandis que le tenant reste une frontière explicite.

01 / AQS22

Isolation des organisations

L’isolation des organisations est appliquée dans la couche de données par le contexte tenant et PostgreSQL RLS, pas seulement par un filtre d’interface. Cette frontière réduit le risque qu’une vue ou une requête expose les données d’une autre organisation.

  • L’isolation est appliquée dans la couche de données, pas seulement dans l’interface.
  • Le contexte d’organisation est vérifié lors des accès.
02 / AQS22

Sessions et capacités

Les sessions sont gérées côté serveur et les opérations dépendent des rôles et capacités autorisés. Le navigateur peut présenter une action, mais il ne décide jamais seul si elle est permise : le backend vérifie le droit réel au moment de l’exécuter.

  • Sessions serveur et contrôles de permission protègent les parcours concernés.
  • L’interface n’est pas la source de vérité pour l’autorisation.
03 / AQS22

Audit et preuves

Les événements, sources, décisions et versions de politique peuvent être retracés pour une revue ultérieure. Cette auditabilité aide à comprendre les choix opérés, à résoudre un désaccord et à améliorer le système sur des faits examinables.

  • Les changements significatifs sont associés à une trace.
  • Les preuves et versions de politiques soutiennent l’examen d’une décision.
04 / AQS22

Actions contrôlées

La préparation d’une décision est séparée de l’exécution d’une action. Les propositions P0 sont simulées, leurs préconditions peuvent bloquer la suite et les opérations sensibles ne sont pas déclenchées automatiquement sur des systèmes externes.

  • La séparation entre décision et action évite un effet externe implicite.
  • Les blocages et raisons d’escalade sont consultables.
POUR ALLER PLUS LOIN

Les questions qui comptent.

Une vue directe sur ce que le produit apporte aujourd’hui — et sur ce qu’il ne promet pas encore.

L’interface suffit-elle à protéger les données ?

Non. Les frontières de tenant, les sessions et les permissions sont appliquées côté serveur et en base de données. Le design d’interface aide à comprendre les droits, mais il n’en est pas la source de vérité.

AQS22 revendique-t-il une certification ?

Aucune certification non obtenue n’est revendiquée. La page décrit des contrôles d’architecture vérifiables dans le Core ; une démarche de conformité formelle exigerait ses propres preuves, audits et validations.

Le périmètre, sans ambiguïté

Cette page décrit des mécanismes d’architecture présents dans le Core. Elle ne constitue ni une attestation de conformité, ni une certification SOC 2, ISO 27001 ou autre non obtenue.

Avancer avec méthode

Moins de charge répétitive. Plus de maîtrise.

Voyez comment AQS22 relie les messages, les données commerce et vos règles dans un espace de décision contrôlé.

Parlons de vos opérations