Une base de données partagée est un point de défaillance unique : comment les instances dédiées changent le risque

septembre 2026 • Sécurité

La plupart des plateformes comptables SaaS fonctionnent de la même façon : une application, une base de données, tous les clients dedans. C'est efficace pour l'éditeur — et cela signifie que tous les clients partagent le même sort. Cet article explique comment fonctionne ce modèle, ce qu'y ressemble une brèche et en quoi FiscFort est construit différemment.

Comment un SaaS partagé typique stocke vos données

Dans une plateforme multi-locataire, de nombreux clients (les « locataires ») sont servis par la même application et, très souvent, la même base de données. Chaque ligne porte un identifiant de locataire, et l'application ajoute « uniquement ce locataire » à chaque requête. La séparation entre clients relève de la logique applicative : elle tient tant que chaque requête, rapport, export et intégration applique correctement le filtre.

Les recommandations de l'OWASP sur la sécurité multi-locataire énoncent clairement le compromis : l'architecture est économique et constitue le socle du SaaS moderne, mais une seule vulnérabilité peut exposer les données de tous les locataires et une erreur de configuration peut faire fuiter des données d'un locataire à l'autre (OWASP). Les testeurs de sécurité font le même constat : sur une plateforme à base de données partagée, une seule injection SQL ou un filtre mal délimité peut exposer tous les locataires à la fois, car l'isolation n'existe que dans la couche applicative et n'est pas imposée par la base de données elle-même (AppSecure).

Ce que « compromis » signifie dans chaque modèle

Situation	SaaS multi-locataire partagé	Instances dédiées FiscFort
Où résident les données clients	Dans des tables partagées par tous les clients, séparées par un identifiant de locataire	Dans une base de données distincte par client, au sein de sa propre instance Odoo
Ce qui impose la séparation	Du code applicatif qui doit être correct à chaque requête	La base de données, les conteneurs, les réseaux et les identifiants eux-mêmes
Un bogue dans le filtre de locataire	Peut exposer beaucoup de clients, voire tous	Limité à l'instance de ce client ; aucune donnée d'un autre client n'y figure
Un identifiant de base de données ou d'administrateur qui fuit	Ouvre la base partagée : tous les clients	N'ouvre que la base d'un seul client ; les autres clients utilisent d'autres identifiants
Le compte d'un client est piraté	L'attaquant démarre à l'intérieur de la plateforme partagée	L'attaquant reste confiné à l'instance de ce client
Hébergement	Plateforme cloud partagée	Infrastructure dédiée, hébergée dans l'UE

Comment FiscFort est construit

Un Odoo, une base PostgreSQL et un stockage propre par client. La séparation est une propriété de la base de données, et non d'un filtre qui doit rester juste pour toujours. Le mode multi-sociétés d'Odoo garde toutes les sociétés dans une seule base et dépend de règles d'enregistrement correctes sur chaque modèle ; nous avons choisi de ne pas l'utiliser précisément pour cette raison.
Son propre réseau et ses propres règles de pare-feu. Les conteneurs de chaque client tournent sur leur propre réseau fixe, et les ports de chaque client ont leurs propres règles de pare-feu explicites.
Ses propres identifiants. Chaque client reçoit son propre mot de passe de base de données et ses propres clés d'API, générés pour ce client et jamais copiés d'un autre.
Ses propres adresses et connexions. Le comptable accède à l'Odoo de chaque client par sa propre URL avec sa propre connexion ; le client accède à son portail avec sa propre connexion. La liste des bases n'est jamais exposée — Odoo choisit la base du client d'après le nom d'hôte et rien ne peut être énuméré.

L'isolation se fait au niveau de l'infrastructure : conteneurs, bases de données, réseaux et identifiants distincts. Jusqu'à 10 clients partagent un serveur dédié qui appartient au bundle du comptable ; avec la formule Enterprise, un client dispose du serveur pour lui seul.

Qui peut accéder à quoi

Le client se connecte à son propre portail et ne voit que sa propre instance.
Le comptable se connecte séparément à l'Odoo de chaque client — une URL et une connexion par client — si bien que l'accès à un client n'implique jamais l'accès à un autre.
Les opérations FiscFort disposent d'un accès administrateur dans chaque instance, car les mises à jour et les évolutions réglementaires l'exigent. Cet accès est utilisé par des agents et des flux automatisés via un compte de service dédié, et non par des personnes qui se connectent ; son identifiant diffère sur chaque serveur et est stocké chiffré.
Tous les autres n'ont rien : les serveurs eux-mêmes n'ont pas d'adresse publique.

Dans Odoo, chaque enregistrement indique qui l'a créé ou modifié en dernier, et les écritures comptables validées ne peuvent qu'être extournées, jamais modifiées. Odoo n'enregistre pas qui a simplement consulté un enregistrement ; ce sont les modifications qui sont journalisées.

Le périmètre autour

Le trafic n'atteint un client qu'à travers Cloudflare (protection DDoS et pare-feu applicatif web) et notre couche de proxy inverse en HTTPS. Les serveurs n'ont pas d'adresse IP publique, seuls le portail et Odoo sont exposés, et l'accès d'administration n'est pas joignable depuis Internet. Les autres couches décrites sur nos pages produit — pare-feu d'entreprise, double chiffrement au niveau du stockage, liaisons UE redondantes, analyse antivirus en temps réel et surveillance des URL — viennent s'y ajouter. Les serveurs sont surveillés en permanence, et le système d'exploitation, Docker et les logiciels tiers sont mis à jour chaque semaine, avec un instantané et un retour arrière possible.

Toujours à jour, sans déplacer vos données

Le même moteur sert la Lituanie et la Belgique. Un processus défini et plusieurs agents d'IA vérifient les sources officielles des deux pays et, chaque petit matin à 3 h, mettent à jour l'Odoo de chaque client avec les règles en vigueur. La mise à jour change les règles, pas les données, et s'applique à l'intérieur de l'instance de chaque client — les données d'un client ne voyagent jamais vers un autre.

L'isolation doit être une propriété de l'infrastructure, pas une promesse faite dans le code.

Questions à poser à tout éditeur SaaS

Mes données sont-elles dans une base partagée avec d'autres clients ?
Qu'est-ce qui empêche un bogue du filtre de locataire d'exposer tout le monde ?
Combien de clients un seul identifiant qui fuit ouvre-t-il ?
Qui, chez l'éditeur, peut lire mes données, comment cet accès est-il accordé et où est-il journalisé ?
Où la plateforme est-elle hébergée, et qui l'exploite ?

Sources

La description des plateformes SaaS partagées correspond au schéma courant ; chaque éditeur diffère.

Découvrir le Bundle FiscFort Demander une démo