Architecture de référence et environnement d'exécution
Ce qui est construit dans le cloud du client : l’entrée, le cluster Kubernetes à trois nœuds réparti sur plusieurs zones, la base de données gérée avec son système de secours, le stockage d’objets, la sortie, le coffre-fort isolé et les options de dimensionnement.
Chaque déploiement est conçu une seule fois, en s'appuyant sur la même architecture de référence. Les différences entre les clouds (produits de connectivité, gestion des clés, moteurs de base de données) deviennent alors des choix de configuration plutôt que des refontes.
| Conception | Construire | Fonctionner | Innover |
|---|---|---|---|
| Un seul modèle de données et un seul moteur de publication pour chaque événement financier. | Services conteneurisés sur un cluster Kubernetes à trois nœuds avec répartition de charge. | Des publications immuables et une piste d'audit complète sont prévues dès la conception. | ASK agit via les API propres à TRANXACT. |
| Conçu pour être multi-entités, multidevises et multirégional. | Une base de données gérée, au choix du client et dimensionnée pour une haute disponibilité. | Live DR dans une deuxième région d'exécution et sauvegardes isolées du réseau en standard. | Une file d'attente d'actions prenant en compte les rôles et apprenant ce qui compte. |
Qu'y a-t-il à l'intérieur d'une région ?
| Composant | Qu'est-ce que c'est | Notes |
|---|---|---|
| Équilibreur de charge et WAF | Entrée HTTPS sur erp.<domaine client>; TLS 1.2 ou supérieur; protection DDoS. | Le seul point d'entrée public. |
| Point de terminaison privé / équilibreur de charge interne | Point d'entrée pour le trafic privé via VPN, connexion privée ou peering. | Présent lorsque l'accès privé est utilisé. |
| cluster Kubernetes | Au moins trois nœuds de travail répartis sur plusieurs zones de disponibilité, TLS de bout en bout. | Gère le site web et l'API, le moteur de publication, l'opérateur ASK, ainsi que les travailleurs et les tâches. |
| Base de données gérée | Un serveur principal avec un serveur de secours HA synchrone dans une autre zone. | Le choix du moteur et de la cylindrée revient au client. |
| stockage d'objets | Documents et pièces jointes, versionnés et répliqués dans toutes les régions. | Les documents ne sont pas stockés dans la base de données. |
| Sortie NAT | Le trafic sortant est autorisé uniquement vers une liste de destinations autorisées. | Banques, impôts et facturation électronique, paie, courriel, moteur d'IA. |
| Chambre forte à lame d'air | Un compte distinct contenant des sauvegardes immuables, à écriture unique. | La production peut s'appuyer dessus et rien d'autre. |
Les nœuds de calcul sont répartis sur plusieurs zones afin que la perte d'un nœud ou d'une zone permette de maintenir la capacité de service aux utilisateurs. Le guide indique sur quel nœud chaque service s'exécute ; c'est le planificateur qui les place.
En dehors du groupe
- Le moteur d’IA pour ASK — niveau premium, équilibré ou économique, ou la propre clé du client (BYOK).
- Services externes — banques, fiscalité et facturation électronique, paie, plateformes de BI et de données, messagerie électronique.
- Utilisateurs distants et mobiles, se connectant via le fournisseur d'identité du client.
- Le réseau d’entreprise du client : utilisateurs de bureau, fournisseur d’identité, systèmes existants et systèmes d’atelier — accessibles via VPN ou liaison privée lorsque la connectivité privée est utilisée.
La connectivité privée est optionnelle. Lorsque tout l'accès se fait via HTTPS, le VPN/lien privé et l'équilibreur de charge interne ne sont tout simplement pas mis en place.
Les boutons de dimensionnement
- Taille du nœud.
- Nombre de nœuds — trois au minimum.
- Moteur de base de données et taille.
- La région Live DR.
- Le nombre d'environnements.
Tout le reste constitue l'architecture de référence et est identique pour tous les clients. Consultez la section « Avant le contrat » pour connaître les niveaux d'utilisation qui définissent les valeurs initiales.
Configurez, ne personnalisez pas
Le même principe régit l'exécution au sein du cluster. Une exigence allant au-delà de la norme est satisfaite dans l'ordre suivant : par la configuration (low-code/no-code, mise à jour avec la plateforme) ; par une intégration via les API TRANXACT exécutée hors du cluster ; et seulement ensuite, après un examen de sécurité et d'ingénierie, par du code ou un agent au sein du cluster — qui, s'il est approuvé, est toléré et pris en charge par le client. Le code refusé s'exécute hors du cluster. Le chapitre X du manuel répertorie les tâches pour chaque résultat.
Tout ce qui est configurable ne doit pas devenir du code personnalisé. La configuration évolue à chaque mise à jour de la plateforme ; le code personnalisé, lui, reste inchangé.
Suivez le cours à ce sujet, avec des schémas et une vérification.