Les canaux de la banque en ligne et de l'application mobile passent par l'API Gateway, ensuite — identification, moteur unique de limites et de règles, logique bancaire de domaine, bus d'événements et AI uniquement comme interface d'action, et non comme intermédiaire d'argent. Les canaux ne vont pas directement vers les microservices. Il est judicieux de comparer votre paysage avec ce schéma : si l'application mobile accède à l'ABS en contournant le gateway, une dette existe déjà. Self Cube intègre le gateway, les limites et l'audit dans l'architecture, et non « nous ajouterons le WAF plus tard ». Les couches peuvent être activées progressivement, mais il est impossible de sauter le gateway.

L'API Gateway est un point d'entrée unique : authentification, routage, politique d'accès aux microservices de la plateforme. Sans gateway, chaque canal — web, iOS, Android, partenaire, agent — traîne ses propres intégrations et ses propres failles. Dans Self Cube, les canaux ne vont pas directement vers le domaine pour cette raison. Il est important de ne pas confondre le gateway avec un répartiteur de charge : le répartiteur distribue le trafic, le gateway impose également le contrat et les droits. Si « l'API de la banque » est un ensemble d'URL internes sans politique, il n'est pas possible de placer une couche d'agent dessus. Le gateway rend justement l'API d'entreprise, et non artisanale.

Non. L'assistant prépare un brouillon d'opération, les services de paiements et de comptes s'exécutent après les limites et les règles. L'humain est intégré dans l'architecture de Self Cube, et non ajouté par une politique de sécurité « un jour ». Il est judicieux d'interdire explicitement aux modèles l'accès direct au service de paiement et à la base. Si la démo montre « j'ai écrit dans le chat — l'argent est parti », c'est soit une simulation, soit un contour dangereux. L'architecture sépare justement l'interface d'action et l'exécution. Il ne faut pas les confondre ni en phase pilote, ni en production.

Le chemin critique du client est synchrone et court : identification, limites, opération de domaine. L'anti-fraude approfondi, l'analyse et les modèles fonctionnent de manière asynchrone par événements — Non-Blocking Compliance, afin que la conformité ne soit pas au même niveau que le clic sur « envoyer ». Il est judicieux de décider à l'avance quelles vérifications doivent être synchrones (limite, blocage de compte), et lesquelles peuvent suivre l'événement. Si tout est tiré dans une seule requête, le canal commencera à ralentir. Le bus d'événements est justement pour cette séparation, et non « pour la mode de Kafka ».

Dans le contour de Self Cube — plus de 80 microservices et plus de 300 types d'événements. Ce n'est pas un monolithe avec une seule API « pour tous les produits de la banque ». Les événements sont nécessaires pour que l'analyse, les notifications et la conformité ne bloquent pas l'étape client. Il est judicieux de ne pas avoir peur des chiffres et de ne pas exiger « mettons tout dans un seul service pour la simplicité » : la simplicité au départ meurt rapidement lors des intégrations. Il faut regarder les frontières des domaines et le gateway, et non la possibilité de dessiner moins de carrés. Le volume des services ici est une conséquence du domaine, et non un objectif en soi.

La plateforme gère le scénario numérique, les systèmes externes exécutent la comptabilité et les opérations spécialisées. Par défaut, elle se connecte à l'ABS, aux cartes, au bus d'intégration, KYC/AML et aux notifications. Le noyau de la banque ne doit pas être cassé. Il est judicieux, au départ, de rédiger ce qui reste un système d'enregistrement et ce qui devient un orchestrateur de canal. Si l'ABS et le DBO sont actuellement liés de manière rigide à l'intérieur du monolithe, la première étape sera justement de sortir le canal du gateway. Self Cube est conçu pour l'intégration, et non pour le slogan « jetez tout ».

Le modèle utilise un contexte minimal, les données sont masquées, il n'y a pas d'accès direct du modèle linguistique à la base. L'orchestrateur décide de ce qui peut être donné et de ce qui doit rester dans le domaine. Il est logique d'interdire séparément les identifiants bruts, les extraits complets et les profils étrangers dans le prompt. Si le pilote « a simplement connecté le modèle au DWH », il n'y a pas de contour architectural. Self Cube intègre la minimisation des données et un contexte contrôlé comme couche, et non comme instruction pour l'employé. Cela est vérifié par un audit, et non par une diapositive.

REST sans contrat — un ensemble d'URL qui vit dans un wiki et dans la tête de l'équipe. OpenAPI rend le contrat lisible par machine : les services et les agents IA trouvent des opportunités selon la spécification, avec des types, des erreurs et une politique d'accès. Sans cela, la couche agent ne se construit pas : les modèles n'ont rien à appeler en toute sécurité. Il est logique de vérifier si le contrat est à jour tout comme le code, et non « la documentation plus tard ». Dans Self Cube, OpenAPI est une partie de la plateforme, et non une application à la version. Un fichier Swagger juste pour faire joli ici n'est pas un critère suffisant.