Obexal Résidence des données et souveraineté
Où tourne Obexal, de quoi il dépend, son statut de certification et comment repartir avec vos données, énoncé factuellement.
Les promesses de souveraineté sont faciles à formuler et difficiles à vérifier. Cette page énonce les faits: où vivent les données, la liste exacte de ce dont dépend le chemin des requêtes, le statut réel des certifications, et comment récupérer vos données.
Résidence des données
Obexal est hébergé en France, dans un datacenter en région parisienne, avec une résidence des données dans l'Union européenne. Toutes les données personnelles résident en UE: utilisateurs, identifiants, sessions, entrées d'audit, facteurs MFA, clés publiques de passkeys, clients OAuth, jetons et clés de signature.
La résidence est appliquée, pas seulement déclarée: chaque tenant porte une région de données (par défaut eu), et la création d'un tenant dans une région hors de l'allowlist du serveur est refusée.
Aucune dépendance hors UE dans le chemin des requêtes
Aucune requête servie par Obexal ne dépend d'un service opéré hors de l'UE. Concrètement:
- La vérification des mots de passe compromis s'appuie sur une liste locale embarquée dans le service. Aucun appel vers une API de fuites externe.
- La résolution GeoIP (pour l'accès conditionnel par pays) lit une base
.mmdblocale sur disque. Le format est ouvert et agnostique au fournisseur; aucune requête réseau n'est jamais émise. - L'email transactionnel (invitations, liens magiques, codes OTP) passe par un relais SMTP UE en TLS. Aucun SaaS d'email américain.
- Les polices et les assets statiques sont auto-hébergés et servis depuis le même domaine. Aucun CDN tiers.
- Aucun analytics, télémétrie ou envoi de logs vers un tiers. La télémétrie des frameworks est désactivée à la construction.
- Les clés de signature sont générées et détenues dans la plateforme, la clé privée chiffrée au repos. Aucun KMS ni HSM tiers dans le chemin des requêtes.
La connexion sociale via Google ou Microsoft est la seule exception délibérée: un choix de fédération explicite de votre administrateur, désactivé par défaut. Le mode souverain strict (SOCIAL_SOVEREIGN_ONLY=true) refuse d'activer les fournisseurs hors UE même configurés; le connecteur OIDC générique permet de fédérer à la place avec un fournisseur d'identité européen.
Auto-hébergement sur votre infrastructure
Chaque composant est open source et auto-hébergeable: un binaire Go statique, PostgreSQL, Redis, et des fronts Next.js auto-hébergés. Vous pouvez faire tourner la plateforme entière sur votre propre infrastructure UE, sans aucun SaaS tiers obligatoire. Commencez par les Prérequis.
Certifications: statut actuel
Au 2 juillet 2026:
| Référentiel | Statut |
|---|---|
| ISO/IEC 27001 | Non certifié. Une correspondance mesure par mesure avec l'Annexe A d'ISO/IEC 27001:2022 est tenue à jour et documentée |
| SOC 2 | Non certifié |
| HDS (hébergement de données de santé) | Non certifié |
| SecNumCloud (ANSSI) | Non qualifié. Une feuille de route vers la qualification existe; la conception de la plateforme (résidence, chiffrement, audit) vise ses exigences |
| RGPD | Pas une certification: l'outillage de conformité est intégré, voir RGPD et protection des données |
Nous publions ce statut tel quel plutôt que de suggérer des certifications que nous ne détenons pas. Il sera mis à jour au fil des audits.
Réversibilité par les standards ouverts
Partir doit être aussi standard qu'arriver:
- Toutes les surfaces d'intégration sont des standards ouverts: OpenID Connect / OAuth 2.1, SAML 2.0, SCIM 2.0, WebAuthn. Aucun SDK propriétaire dont vos applications dépendraient.
- Les utilisateurs peuvent exporter les données de leur compte en JSON, et les admins lire l'annuaire via l'API d'administration.
- Le SCIM sortant peut pousser votre annuaire vers un autre système en continu, ce qui sert aussi de chemin de migration.
- En fin de contrat, les données sont supprimées ou restituées, au choix du responsable de traitement, conformément au DPA.