Architecture de la plateforme
Cette section s'adresse aux équipes IT, DSI, RSSI et auditeurs qui évaluent la plateforme. Elle décrit les principes d'architecture sans détailler les éléments d'implémentation sensibles (adressage, topologie réseau interne, secrets, noms d'hôtes internes).
Vue d'ensemble
Principes
| Principe | Mise en œuvre |
|---|---|
| Infrastructure déclarative | L'état souhaité de chaque client est décrit dans un dépôt versionné ; un opérateur d'intégration continue le réconcilie en permanence. Aucune modification manuelle ne subsiste. |
| Un espace isolé par client | Chaque structure dispose de son propre espace d'exécution, avec ses propres instances, bases et volumes. |
| Identité centralisée | Un unique fournisseur d'identité gouverne l'accès à tous les outils. Aucun outil ne détient de base de mots de passe. |
| Chiffrement de bout en bout du transport | HTTPS obligatoire sur toutes les adresses publiques, certificats émis et renouvelés automatiquement. |
| Sauvegarde par client | Chaque structure a sa propre clé de chiffrement de sauvegarde. |
| Suppression réellement destructive | La suppression d'une structure efface les données partout, y compris sur les services mutualisés et dans les sauvegardes. |
Les briques
Point d'entrée
Un routeur d'entrée unique termine le TLS et dirige chaque requête vers l'outil concerné en fonction du nom d'hôte. Les certificats sont émis par une autorité publique (Let's Encrypt) et renouvelés automatiquement, y compris pour les domaines de nos clients.
Orchestration
Les charges de travail tournent sur un cluster Kubernetes. Les déploiements sont pilotés en GitOps : la configuration de chaque client est un manifeste versionné, appliqué et continuellement resynchronisé. Conséquence pratique : une dérive de configuration est corrigée automatiquement, et l'historique des changements est traçable.
Identité
Un fournisseur d'identité (Keycloak) centralise comptes, mots de passe, rôles et sessions. Les outils s'y connectent en OpenID Connect, à l'exception du support client qui utilise SAML 2.0. Voir Identité & SSO.
Données
- Bases relationnelles : PostgreSQL, avec un rôle et des identifiants distincts par application. Aucune application n'utilise de compte superutilisateur.
- Volumes : stockage bloc répliqué sur plusieurs nœuds, chiffré au repos.
- Objets : stockage objet européen pour les sauvegardes, séparé de la production.
Messagerie
La réception (boîtes, IMAP, webmail) et l'envoi (relais sortant, signature DKIM, suivi de délivrabilité) sont assurés par des services dédiés de la plateforme. Voir E-mail & délivrabilité.
DNS
Un serveur DNS autoritaire gère les zones des clients qui délèguent leur domaine, et publie automatiquement les enregistrements d'outils, de messagerie et de validation de certificats. Voir DNS & TLS.
Modèle de déploiement des outils
Les instances dédiées sont déployées dans l'espace du client : rien n'est partagé avec une autre structure, ni le processus, ni la base, ni le volume.
Les services communs sont mutualisés, avec un cloisonnement applicatif : chaque structure y possède son organisation, ses ressources et ses membres, et n'a aucune visibilité sur les autres.
Cycle de vie d'un client
Ce que nous ne publions pas
Par principe de sécurité, cette documentation ne contient ni adresses IP, ni topologie réseau interne, ni noms d'hôtes d'administration, ni détails de configuration des pare-feux. Ces éléments sont communicables sous accord de confidentialité dans le cadre d'un audit.