Vue d'ensemble de l'architecture

Cette page décrit l'architecture de NEXCLARA à l'usage des équipes d'architecture et de sécurité d'une institution : ce qui sépare les données d'une institution de celles des autres, ce qui sépare l'exploitation de la plateforme des données des emprunteurs, et sur quels composants elle repose.

Deux plans séparés

Le plan de contrôle a sa propre base, ses propres opérateurs et son propre contrat d'interface. Ses opérateurs n'ont aucun compte ordinaire dans l'espace d'une institution. Il transmet des commandes signées que l'instance tire elle-même et accuse ; il ne lit pas les dossiers. Un accès exceptionnel du support suit le régime fixé au contrat de l'institution : consentement préalable d'un de ses administrateurs, ou notification avec droit d'opposition avant l'échéance. Il passe par une identité de support distincte, en lecture seule, bornée dans le temps et dans son périmètre ; l'institution peut y mettre fin à tout moment, et chaque consultation est journalisée de son côté.

Isolation de chaque institution

Dans le plan de données, chaque institution dispose de son propre espace, et l'isolation est assurée à trois niveaux indépendants :

1. un schéma de base de données par institution ;
2. une sécurité au niveau des lignes activée et forcée sur toutes les tables de l'institution, en lecture comme en écriture ;
3. un contexte d'institution porté par la transaction, retiré par la base elle-même à la fin de chaque transaction.

L'application se connecte avec un rôle qui ne peut ni contourner ces règles, ni modifier une trace du journal. Ces propriétés sont vérifiées à chaque intégration : une suite de tests d'isolation passe avec le rôle applicatif, puis la même suite doit échouer avec un rôle privilégié, ce qui prouve qu'elle teste réellement quelque chose. Une ressource d'une autre institution répond exactement comme une ressource inexistante.

Composants standards

La plateforme ne repose que sur des interfaces standards : PostgreSQL, Redis (facultatif) et conteneurs. Un stockage objet compatible S3 est prévu par l'architecture, mais aucun n'est encore employé : les fichiers déposés sont conservés dans la base de l'institution. Aucun service propriétaire d'un fournisseur d'informatique en nuage n'est employé, et un contrôle automatique le vérifie. La pile complète démarre et fonctionne sur un réseau fermé, sans aucun appel sortant obligatoire.

L'interface web est un intermédiaire côté serveur : le navigateur ne voit jamais le jeton de session, conservé dans un cookie protégé. L'API ne lit ni n'émet de cookie : elle reçoit un jeton porteur (voir Authentification).

Modes de déploiement

L'architecture prévoit quatre modes : service mutualisé, service dédié à une institution, déploiement sur l'infrastructure de l'institution, et mode hybride. Le passage d'un mode à l'autre relève de la configuration, pas du code métier.

Ce qui est encore en construction

• seul un déploiement mutualisé est en service, dans un environnement de pré-production sur données synthétiques ; aucun environnement de production bancaire n'est en service ;
• le plan de contrôle est en ligne depuis le 2026-10-15, en validation et en production, réservé aux opérateurs NEXCLARA derrière une passerelle ; il ne pilote encore qu'une partie des opérations décrites ci-dessus ;
• aucun site d'hébergement dans l'UMOA n'est retenu, et aucune certification d'hébergeur n'est vérifiée ;
• ni images signées, ni guide d'installation pour un déploiement sur l'infrastructure de l'institution.