« Vos données restent au Québec. » C'est une phrase qu'on entend beaucoup. Mais qu'est-ce que ça veut dire techniquement? Voici la vraie architecture de Beluga, sans flou marketing.
Le centre de données
Beluga tourne sur OVHcloud BHS — le campus de Beauharnois, Québec. OVH est une entreprise française (siège social à Roubaix), donc non soumise au CLOUD Act américain. Le matériel est ici, le droit qui s'applique est canadien et français. Aucune autorité américaine ne peut obliger OVH à fournir vos données.
Le cluster
Nous opérons un cluster Kubernetes v1.29 managé par OVH, avec trois nœuds de travail. L'ingress utilise NGINX, les certificats sont renouvelés automatiquement par Let's Encrypt. Tout est provisionné par Terraform et déployé par Helm — rien d'ad hoc, tout est reproductible.
Le réseau privé
Beluga utilise un vRack OVH — un réseau privé 10.0.0.0/16 qui isole complètement le trafic interne. Vos conteneurs, la base PostgreSQL, le cache Redis, les serveurs de courriel Postfix/Dovecot, MinIO S3, LiveKit, Synapse — tout communique par ce réseau privé. Zéro flux Internet entre nos composants internes.
Exactement deux points d'entrée publics
- Un Load Balancer HTTPS pour le web (TLS 1.2+, HSTS activé 1 an, JWT RS256 avec cache JWKS).
- Une IP fixe pour le courriel (SMTP avec PTR configuré, DKIM/SPF/DMARC).
Le reste est invisible depuis Internet. Un attaquant doit passer par l'un de ces deux points ou rien.
Le chiffrement
AES-256 au repos sur tous les volumes. TLS 1.2+ obligatoire en transit. JWT RS256 (clés asymétriques, cache JWKS 1h). Aucun secret partagé en clair, même entre composants internes.
L'authentification
Keycloak 24.0 (OIDC/PKCE). 2FA TOTP disponible pour tous, obligatoire pour les super-administrateurs. Blocage après 5 tentatives infructueuses (lock 15 min). Rate limiting serveur : 300 req/min pour les utilisateurs authentifiés, 60 req/min pour les anonymes, 5 inscriptions/h par IP.
Ce n'est pas de la magie. C'est de l'ingénierie méthodique, faite ici, pour ici.