Architecture et hébergement : sécurité, souveraineté et infrastructure de la plateforme Ragindeed

Pourquoi l'hébergement est une question stratégique, pas technique

Quand une SGP immobilière ou un CGP confie ses documents à une plateforme SaaS (Software as a Service — un logiciel accessible via internet, hébergé et maintenu par un prestataire, par opposition à un logiciel installé sur vos propres serveurs), la question "où sont mes données ?" n'est pas une curiosité technique. C'est une question réglementaire, commerciale et stratégique.

L'AMF et l'ACPR exigent que les sociétés de gestion puissent démontrer la maîtrise de leurs données sensibles et de leur chaîne de sous-traitance informatique. Les investisseurs institutionnels (assureurs, caisses de retraite, mutuelles) posent systématiquement la question de la localisation des données dans leurs questionnaires de due diligence. Et le RGPD impose des contraintes strictes sur la localisation et le traitement des données personnelles des investisseurs.

Selon une étude IDC (source : IDC, European Cloud Sovereignty Survey, 2024), 67 % des entreprises du secteur financier européen considèrent la souveraineté des données comme un critère de sélection prioritaire pour leurs fournisseurs cloud — devant le prix et même devant les fonctionnalités. Ce chiffre était de 41 % en 2021. La tendance est claire et irréversible.

Ragindeed a été conçu dès l'origine pour répondre à ces exigences. L'ensemble de l'infrastructure est hébergée en France, chez un opérateur cloud français soumis au droit européen, avec un chiffrement bout en bout et une isolation stricte entre les clients.

Cet article détaille l'architecture technique, les choix d'hébergement et les mécanismes de sécurité qui protègent vos données — en expliquant chaque concept technique pour que la lecture soit accessible à un directeur général comme à un RSSI.

Vue d'ensemble de l'architecture

                    Internet
                       │
                       ▼
              ┌─────────────────────┐
              │  Ingress TLS 1.3    │
              │  (Let's Encrypt)    │
              │  cert-manager       │
              │  OVH DNS-01         │
              └─────────────────────┘
                       │
                       ▼
         ┌────────────────────────────────┐
         │    Kubernetes Scaleway         │
         │    (Paris DC4 / Lille DC2)     │
         │                                │
         │  ┌──────────┐  ┌──────────┐   │
         │  │ Serveur   │  │ Serveur  │   │
         │  │ Web       │  │ Worker   │   │
         │  │ (HTTP)    │  │ (Jobs)   │   │
         │  └──────────┘  └──────────┘   │
         │       │              │         │
         │       ▼              ▼         │
         │  ┌──────────────────────┐      │
         │  │   PostgreSQL         │      │
         │  │   + pgvector         │      │
         │  │   (Base managée)     │      │
         │  └──────────────────────┘      │
         │                                │
         │  ┌──────────────────────┐      │
         │  │ Scaleway Object      │      │
         │  │ Storage (S3)         │      │
         │  │ AES-256 au repos     │      │
         │  └──────────────────────┘      │
         │                                │
         │  ┌──────────────────────┐      │
         │  │ Services annexes     │      │
         │  │ OCR, Marker PDF,     │      │
         │  │ moteurs de           │      │
         │  │ transcription        │      │
         │  └──────────────────────┘      │
         └────────────────────────────────┘

Hébergement : Scaleway, opérateur cloud français

Ragindeed est hébergé intégralement chez Scaleway, filiale du groupe Iliad (maison mère de Free). C'est un choix délibéré qui répond à trois critères fondamentaux.

1. Souveraineté juridique des données

Scaleway est un opérateur français, soumis au droit français et européen. Les données hébergées chez Scaleway ne sont pas soumises au Cloud Act américain ni au FISA (Foreign Intelligence Surveillance Act — la loi américaine qui autorise les services de renseignement américains à accéder aux données détenues par les entreprises américaines, y compris celles stockées sur des serveurs situés en Europe).

C'est une différence fondamentale avec AWS (Amazon), Azure (Microsoft) ou GCP (Google), dont les maisons mères sont des entreprises américaines. Même si ces fournisseurs proposent des régions européennes et des programmes de "cloud souverain", leur statut juridique de société américaine les soumet au Cloud Act — un risque que la CNIL et l'ANSSI ont clairement identifié (source : CNIL, Recommandations sur l'utilisation des outils collaboratifs américains, 2023).

Le Comité européen de la protection des données (CEPD) a confirmé en 2023 que le recours à des fournisseurs cloud soumis à des lois extra-territoriales constitue un risque pour la protection des données personnelles européennes, même en présence de clauses contractuelles types (source : CEPD, Guidelines on data transfers under the GDPR, 2023).

2. Localisation physique en France

Les datacenters utilisés par Ragindeed sont situés exclusivement en France :

Aucune donnée ne quitte le territoire français. Ni pour le calcul, ni pour le stockage, ni pour les sauvegardes. Cette garantie est vérifiable : les adresses IP des serveurs sont géolocalisables, et Scaleway publie la liste de ses datacenters (source : Scaleway, Trust Center — Data Center Locations, 2024).

3. Certifications de sécurité

Les datacenters Scaleway sont certifiés selon les standards internationaux les plus exigeants :

Scaleway est également engagé dans le processus de qualification SecNumCloud (qualification de sécurité délivrée par l'ANSSI — c'est l'équivalent d'un label "Étoile Michelin" pour la sécurité des hébergeurs cloud français, avec des audits techniques approfondis et des exigences de souveraineté juridique). La version 3.2 du référentiel SecNumCloud, publiée en 2024, ajoute des exigences d'immunité aux lois extra-territoriales (source : ANSSI, Référentiel SecNumCloud v3.2, 2024).

Kubernetes : orchestration et haute disponibilité

L'application Ragindeed s'exécute sur un cluster Kubernetes (un système d'orchestration de conteneurs — imaginez un chef d'orchestre qui répartit automatiquement les musiciens sur la scène, remplace un musicien malade par un suppléant et ajoute des musiciens quand la salle est pleine). Le service utilisé est Kapsule, le Kubernetes managé de Scaleway.

Déploiement et mise à l'échelle automatique

Kubernetes gère automatiquement la vie de l'application :

• Réplication : les composants de la plateforme (serveur web, serveur de traitement) sont déployés en plusieurs copies (replicas) pour garantir la disponibilité. Si un exemplaire tombe en panne, les autres continuent à servir les utilisateurs
• Mise à l'échelle : en cas de pic de charge (par exemple, 500 utilisateurs simultanément pendant une campagne de souscription SCPI), Kubernetes ajoute automatiquement des replicas pour absorber la charge
• Auto-guérison : en cas de défaillance d'un noeud physique (le serveur matériel), les composants sont automatiquement redémarrés sur un autre noeud, sans intervention humaine

Séparation des charges de travail

L'architecture sépare les traitements interactifs (l'interface utilisateur) des traitements lourds (OCR, extraction, transcription) pour que les uns n'impactent jamais les autres :

Routage et certificats TLS

Un contrôleur d'entrée (ingress controller) gère le routage des requêtes entrantes. Les certificats TLS (les "cadenas" de sécurité dans la barre d'adresse du navigateur) sont générés automatiquement par cert-manager via Let's Encrypt, avec validation DNS-01 chez OVH. Le renouvellement est automatique — aucune intervention manuelle, aucun risque de certificat expiré.

Le routage en production :
- *.ragindeed.com pointe vers le service multi-tenant (chaque client accède à son espace dédié)
- ragindeed.com pointe vers le site principal
- www.ragindeed.com redirige automatiquement vers ragindeed.com

Chiffrement : protéger les données en transit et au repos

Les données sont chiffrées à deux niveaux distincts, couvrant l'intégralité de leur cycle de vie.

Chiffrement en transit (TLS 1.3)

Toutes les communications entre le navigateur de l'utilisateur et la plateforme sont chiffrées en TLS 1.3 (Transport Layer Security version 1.3 — le protocole de chiffrement le plus récent et le plus sécurisé pour les communications internet, comme un tunnel blindé entre votre navigateur et nos serveurs). Cela inclut :

• L'interface web (consultation, upload, validation)
• Les appels API (intégrations externes, connecteurs de stockage)
• Les communications entre les services internes du cluster (communication inter-pods)

TLS 1.3 supprime les suites cryptographiques obsolètes (RC4, 3DES, SHA-1) et impose le Perfect Forward Secrecy (PFS — une propriété qui garantit que même si la clé privée du serveur était compromise dans le futur, les communications passées resteraient indéchiffrables, comme si chaque conversation utilisait une clé éphémère détruite après usage).

L'ANSSI recommande TLS 1.3 comme configuration minimale pour les systèmes d'information traitant des données sensibles (source : ANSSI, Recommandations de sécurité relatives à TLS, 2024).

Chiffrement au repos (AES-256)

Les données stockées sont chiffrées au repos, c'est-à-dire sur les disques physiques des serveurs :

Le chiffrement AES-256 (Advanced Encryption Standard avec une clé de 256 bits) est le standard utilisé par les institutions financières, les gouvernements et les armées du monde entier. Pour donner un ordre de grandeur : une attaque par force brute contre AES-256 nécessiterait 2^256 opérations — un nombre supérieur au nombre d'atomes dans l'univers observable. Avec les ordinateurs les plus puissants existants, cette attaque prendrait plus de temps que l'âge de l'univers (source : NIST, Advanced Encryption Standard — FIPS 197, 2023 update).

Multi-tenant : isolation par base de données séparée

Ragindeed est une plateforme SaaS multi-tenant (multi-locataire — une architecture où plusieurs clients partagent la même infrastructure applicative, mais avec une isolation stricte de leurs données, comme un immeuble d'appartements où chaque locataire a son propre espace privé avec sa propre serrure). Chaque client (SGP, CGP, groupe financier) dispose de son propre tenant avec une isolation maximale.

Architecture d'isolation

Le modèle d'isolation choisi est le plus sécurisé qui existe : une base de données PostgreSQL séparée par tenant.

Cluster Kubernetes
    │
    ├── Application Ragindeed (partagée)
    │       │
    │       ├── Requête client A ──▶ Base de données A
    │       │
    │       ├── Requête client B ──▶ Base de données B
    │       │
    │       └── Requête client C ──▶ Base de données C
    │
    └── Object Storage
            │
            ├── Bucket / préfixe client A
            │
            ├── Bucket / préfixe client B
            │
            └── Bucket / préfixe client C

Pourquoi une base par tenant ?

Il existe trois modèles d'isolation multi-tenant, classés du moins sécurisé au plus sécurisé :

Le modèle "base séparée" est le seul qui offre :
- Isolation totale : aucun risque de fuite de données entre clients, même en cas de bug applicatif — les requêtes SQL d'un client ne peuvent physiquement pas atteindre la base d'un autre
- Restauration indépendante : possibilité de restaurer les données d'un seul client sans affecter les autres — un avantage critique en cas d'erreur de manipulation
- Performance prévisible : les requêtes lourdes d'un client (par exemple, un reporting trimestriel sur 5 000 investisseurs) n'impactent pas les temps de réponse des autres clients
- Conformité RGPD simplifiée : en cas de demande de droit à l'effacement, la suppression de la base du client est une opération atomique (complète et irréversible), sans risque de résidu dans des tables partagées

Selon Gartner (source : Gartner, Best Practices for SaaS Multi-Tenancy Architecture, 2024), le modèle "base par tenant" est recommandé pour les applications SaaS traitant des données financières ou personnelles sensibles, malgré sa complexité opérationnelle supérieure.

Limites configurables par tenant

Chaque tenant dispose de limites configurables pour garantir un usage équitable des ressources partagées :

Ces limites sont surveillées en continu par l'infrastructure, avec des alertes avant d'atteindre les seuils et des mécanismes de protection contre les dépassements.

PostgreSQL et pgvector : base relationnelle et vectorielle unifiée

Ragindeed utilise PostgreSQL comme base de données, avec l'extension pgvector pour le stockage et la recherche de vecteurs d'embedding (des représentations numériques du contenu des documents — imaginez que chaque paragraphe d'un document est transformé en un "code-barres" de 1 024 chiffres qui capture son sens, permettant de retrouver des paragraphes similaires par calcul mathématique plutôt que par mots-clés).

Pourquoi PostgreSQL ? C'est la base de données relationnelle open source la plus mature et la plus performante au monde, utilisée par des organisations comme Apple, Instagram, Spotify et la NASA. Elle dispose d'un écosystème d'extensions riche et d'une communauté de développeurs massive (source : DB-Engines, Database Rankings, 2024).

Pourquoi pgvector plutôt qu'une base vectorielle séparée ? Plutôt que d'ajouter une base vectorielle dédiée (Pinecone, Weaviate, Qdrant — des bases de données spécialisées dans le stockage de vecteurs), Ragindeed stocke les embeddings directement dans PostgreSQL via pgvector. Les avantages sont significatifs :

Les embeddings texte (1 024 dimensions) et vision (1 536 dimensions) sont indexés avec des index HNSW (Hierarchical Navigable Small World — un algorithme d'indexation qui organise les vecteurs dans un graphe navigable, permettant de trouver les vecteurs les plus similaires en quelques millisecondes même parmi des millions) pour des recherches de similarité performantes.

Des benchmarks récents montrent que pgvector avec index HNSW atteint des performances de recherche comparables aux bases vectorielles spécialisées pour des volumes allant jusqu'à 10 millions de vecteurs, avec un recall (taux de rappel — le pourcentage de résultats pertinents effectivement retrouvés) supérieur à 95 % (source : Supabase, pgvector v0.7.0 Performance Benchmarks, 2024).

Stockage objet : Scaleway Object Storage

Les fichiers (documents PDF, images, fichiers audio, rapports générés) sont stockés sur Scaleway Object Storage, un service de stockage objet compatible S3 (le protocole standard de stockage cloud, initialement créé par Amazon mais devenu un standard ouvert adopté par tous les fournisseurs cloud).

Caractéristiques techniques :
- Protocole S3 : compatible avec tous les outils et SDK S3 standards, facilitant l'intégration et la portabilité
- Chiffrement : AES-256 server-side encryption, activé par défaut sur tous les objets
- Durabilité : 99,999999999 % (11 nines — cela signifie que sur 100 milliards de fichiers stockés, la probabilité d'en perdre un est de 1 sur 100 milliards)
- Disponibilité : 99,9 % (soit moins de 9 heures d'indisponibilité par an)
- Localisation : France (Paris), même datacenter que l'application

L'accès aux fichiers depuis l'application se fait via fsspec (une abstraction Python pour les systèmes de fichiers qui permet de changer de backend de stockage sans modifier le code applicatif) et un module de redirection transparent qui stocke automatiquement les fichiers sur le stockage S3 plutôt que sur le système de fichiers local.

Le module rclone (un outil open source de synchronisation de fichiers, souvent décrit comme le "couteau suisse" du transfert cloud) est utilisé pour les synchronisations avec les sources externes des clients (OneDrive, SharePoint, Google Drive, SFTP, etc.). Rclone gère les transferts, la reprise sur erreur et la synchronisation incrémentale de manière fiable et performante.

Stratégie de sauvegarde

La stratégie de sauvegarde suit la règle 3-2-1 (une bonne pratique universelle en informatique — comme avoir 3 copies de vos clés : une dans votre poche, une chez vous et une chez un voisin de confiance) :
- 3 copies des données (production + 2 sauvegardes)
- 2 supports différents (base de données managée + stockage objet)
- 1 copie hors site (datacenter de Lille, géographiquement distant de Paris)

Indicateurs de reprise :
- RPO (Recovery Point Objective — la quantité maximale de données que vous acceptez de perdre en cas de sinistre) : inférieur à 24 heures pour les snapshots quotidiens, et inférieur à quelques minutes pour le WAL archiving continu
- RTO (Recovery Time Objective — le temps maximal pour restaurer le service après un sinistre) : 4 heures pour une restauration complète d'un tenant à partir d'une sauvegarde

La restauration est testée régulièrement dans le cadre du plan de reprise d'activité (PRA). Chaque test est documenté et les résultats sont disponibles sur demande pour les audits de conformité.

Conformité RGPD

La conformité RGPD (Règlement Général sur la Protection des Données — le règlement européen qui encadre le traitement des données personnelles, applicable depuis mai 2018) est native dans l'architecture de Ragindeed. Voici comment chaque exigence est couverte :

Point critique : les données ne sont jamais utilisées pour entraîner des modèles d'IA.

Les documents traités par Ragindeed sont envoyés aux fournisseurs d'IA (OpenAI, Mistral, Google) pour extraction et analyse, mais avec des garanties contractuelles strictes :
- Les appels API sont effectués avec l'option data_retention=off quand elle est disponible (cas d'OpenAI)
- Les fournisseurs utilisés (OpenAI API, Mistral API) garantissent contractuellement que les données des appels API ne sont pas utilisées pour l'entraînement de leurs modèles (source : OpenAI, API Data Usage Policy, 2024 ; Mistral AI, Terms of Service — API, 2024)
- Les embeddings sont calculés et stockés localement dans PostgreSQL — ils ne sont pas envoyés à des services tiers
- La CNIL a publié des recommandations spécifiques sur l'utilisation des API d'IA en conformité avec le RGPD (source : CNIL, Guide pratique — IA et données personnelles, 2024)

Souveraineté numérique : pourquoi c'est un enjeu business pour les SGP

La question de la souveraineté des données n'est pas théorique pour une SGP ou un CGP. Elle a des implications concrètes, mesurables et immédiates.

1. Conformité AMF/ACPR et externalisation informatique.
Le régulateur attend que les sociétés de gestion puissent démontrer la maîtrise de la chaîne de sous-traitance informatique. L'article 313-75 du Règlement général de l'AMF impose une évaluation formelle des risques liés à l'externalisation, y compris la localisation des données et la juridiction applicable au prestataire. L'ACPR a renforcé ses attentes dans ce domaine avec les orientations EBA sur l'externalisation dans le cloud (source : ACPR, Guide sur l'externalisation dans le cloud, 2023).

2. Clause de réversibilité et portabilité.
En cas de changement de prestataire (un scénario que tout dirigeant prudent doit anticiper), les données doivent être récupérables dans un délai et un format raisonnables. L'architecture base-par-tenant de Ragindeed simplifie considérablement cette réversibilité : un export de la base PostgreSQL + du stockage S3 du tenant constitue un jeu de données complet, autonome et exploitable sans dépendance à la plateforme.

3. Risque juridique extra-territorial (Cloud Act).
Si vos données sont hébergées chez un opérateur cloud américain (AWS, Azure, GCP), elles sont potentiellement accessibles aux autorités américaines via le Cloud Act, même si les serveurs sont physiquement situés en Europe. Ce risque est documenté par la CNIL et par le Conseil d'État (source : Conseil d'État, Étude annuelle 2024 — Le numérique et les libertés fondamentales, 2024). Il est éliminé en choisissant un hébergeur français soumis exclusivement au droit européen.

4. Confiance des investisseurs institutionnels.
Les investisseurs institutionnels (assureurs, caisses de retraite, fonds de pension) qui souscrivent dans vos fonds posent de plus en plus la question de l'hébergement des données dans leurs questionnaires de due diligence opérationnelle. "Hébergé en France, chez un opérateur français, avec chiffrement bout en bout et isolation par base de données" est un argument de confiance mesurable et différenciant.

5. Évolution réglementaire européenne (DORA).
Le cadre réglementaire se durcit. La directive DORA (Digital Operational Resilience Act — le règlement européen sur la résilience opérationnelle numérique du secteur financier, applicable en janvier 2025) impose aux entités financières de maîtriser les risques liés à leurs prestataires ICT (informatique et télécommunications), avec des exigences de tests de résilience et de plans de sortie documentés (source : Commission européenne, Règlement (UE) 2022/2554 — DORA, 2022).

Analyse comparative des options d'hébergement

Le choix d'un hébergeur pour une plateforme SaaS financière n'est pas anodin. Voici un comparatif des principales options :

Pourquoi Scaleway plutôt qu'OVHcloud ou Outscale ? Le choix de Scaleway repose sur la qualité de son offre Kubernetes managée (Kapsule), la compétitivité tarifaire de son stockage objet, et la simplicité de son API. OVHcloud et Outscale sont des alternatives françaises également valables — l'essentiel est de rester dans le périmètre juridique français et européen (source : Scaleway, Kubernetes Kapsule Documentation, 2024).

Tendances technologiques et perspectives

Le paysage du cloud souverain évolue rapidement sous la pression réglementaire et géopolitique :

SecNumCloud v3.2 et immunité extra-territoriale (2024-2026) : la nouvelle version du référentiel SecNumCloud de l'ANSSI exige que l'hébergeur soit immunisé contre les lois extra-territoriales. Concrètement, cela exclut les filiales de sociétés américaines, chinoises ou d'autres pays disposant de lois d'accès aux données. Scaleway, OVHcloud et Outscale sont éligibles ; AWS, Azure et GCP ne le sont pas (source : ANSSI, Référentiel SecNumCloud v3.2, 2024).

EUCS — European Union Cybersecurity Certification Scheme for Cloud Services (2025-2027) : l'ENISA (l'agence européenne de cybersécurité) travaille sur un schéma de certification européen pour les services cloud, qui devrait remplacer à terme les certifications nationales. Le niveau "High" de l'EUCS reprendra les exigences de souveraineté de SecNumCloud. La France milite activement pour que ce niveau élevé soit maintenu dans le texte final (source : ENISA, EUCS Candidate Scheme v1.0, 2024).

Gaia-X et fédération de données (2024-2027) : l'initiative européenne Gaia-X vise à créer un écosystème de données fédéré et souverain. Bien que le projet ait connu des difficultés de gouvernance, les principes fondamentaux (portabilité, interopérabilité, souveraineté) s'inscrivent dans la trajectoire réglementaire européenne (source : Gaia-X, Architecture Document Release 24.06, 2024).

Marché du cloud souverain : projections de croissance : selon IDC (source : IDC, European Sovereign Cloud Forecast 2024-2028, 2024), le marché du cloud souverain européen devrait croître de 25 % par an pour atteindre 15 milliards d'euros en 2028, porté par les exigences réglementaires (DORA, NIS2, AI Act) et la prise de conscience des risques extra-territoriaux.

European AI Act et hébergement des données IA (février 2025 - août 2026) : le Règlement européen sur l'intelligence artificielle impose des obligations spécifiques pour les systèmes d'IA à haut risque, notamment en matière de traçabilité des données d'entraînement et de conformité. Pour les systèmes d'IA utilisés dans le secteur financier, le recours à des infrastructures souveraines sera de facto exigé par les régulateurs nationaux (source : Commission européenne, Règlement (UE) 2024/1689 — AI Act, 2024).

Récapitulatif : les garanties de l'infrastructure Ragindeed

En résumé

L'infrastructure de Ragindeed repose sur trois piliers indissociables : la souveraineté (hébergement 100 % français chez Scaleway, non soumis au Cloud Act, données qui ne quittent jamais le territoire), la sécurité (chiffrement bout en bout AES-256 et TLS 1.3, isolation multi-tenant par base de données séparée, certifications ISO 27001 et SOC 2) et la fiabilité (Kubernetes pour la haute disponibilité et l'auto-guérison, sauvegardes multiples avec règle 3-2-1, monitoring continu).

Pour une SGP ou un CGP, ces garanties ne sont pas des options techniques ou des arguments marketing. Elles sont des prérequis réglementaires (AMF, ACPR, RGPD, DORA) et des arguments commerciaux (confiance des investisseurs institutionnels, des distributeurs et des commissaires aux comptes).

Vos documents contiennent les données les plus sensibles de votre activité : pièces d'identité de vos investisseurs, avis d'imposition, baux commerciaux, bulletins de souscription, coordonnées bancaires. L'infrastructure qui les protège doit être à la hauteur de cette responsabilité. Avec un hébergement souverain, un chiffrement de niveau militaire et une isolation par base de données, Ragindeed offre le niveau de protection que ces données exigent.