Architecture d'une plateforme immobilière multi-tenant

Quand une agence immobilière nous confie son projet d'application, elle n'imagine pas toujours ce qui se joue sous la surface. Construire une plateforme mobile moderne pour une seule agence, c'est un travail de développement classique. Construire une plateforme capable d'accueillir des dizaines d'agences, chacune avec sa marque, ses biens, ses clients et ses données strictement cloisonnées, tout en partageant le même socle technique, c'est un autre métier : celui de l'architecture logicielle. C'est exactement le pari d'AGENCYA, notre plateforme immobilière en marque blanche. Dans cet article, nous ouvrons les coulisses de sa conception, des choix d'architecture aux compromis techniques, pour montrer comment un produit pensé pour durer se construit dès la première ligne de code.

Le multi-tenant : un code, plusieurs agences

Le terme « multi-tenant » (littéralement « multi-locataires ») décrit une architecture où une même application sert plusieurs clients à partir d'une infrastructure unique. Chaque agence est un « tenant » : elle dispose de son espace, de ses utilisateurs et de ses données, comme si la plateforme lui appartenait en propre. Mais en coulisses, toutes partagent le même code et la même base de données.

Pourquoi ce choix plutôt que de dupliquer l'application pour chaque agence ? Pour deux raisons que tout dirigeant comprend immédiatement. D'abord, la mutualisation : une correction de bug ou une nouvelle fonctionnalité profite instantanément à toutes les agences, sans avoir à maintenir vingt versions différentes du même logiciel. Ensuite, la maîtrise des coûts : un seul socle à héberger, à surveiller et à faire évoluer. L'alternative, dupliquer le code pour chacun, transforme la moindre évolution en chantier répété autant de fois qu'il y a de clients. Nous détaillons d'ailleurs ces arbitrages produit dans notre regard sur le développement de SaaS sur mesure.

Isoler les données : la frontière invisible

Le multi-tenant pose immédiatement une question de confiance : si toutes les agences partagent la même base, comment garantir qu'une agence ne verra jamais les biens, les contacts ou les mandats d'une autre ? Cette frontière invisible est le cœur de notre travail de sécurité.

Nous nous appuyons sur Supabase, qui repose sur PostgreSQL, et sur l'une de ses fonctions les plus puissantes : la Row Level Security (sécurité au niveau de la ligne). Plutôt que de filtrer les données dans le code de l'application, où une erreur de développeur pourrait ouvrir une brèche, nous appliquons les règles d'accès directement dans la base. Concrètement, chaque ligne (un bien, un client, un message) porte l'identifiant de l'agence à laquelle elle appartient. Une politique de sécurité vérifie, à chaque requête, que l'utilisateur connecté appartient bien à cette agence. Si la condition n'est pas remplie, la donnée est tout simplement invisible : elle n'existe pas pour lui.

La meilleure protection des données n'est pas celle que l'on ajoute par-dessus l'application : c'est celle que la base de données applique elle-même, sans exception possible.

Cette approche déplace la sécurité au plus près de la donnée. Même si une faille apparaissait dans l'interface, la base refuserait de livrer ce qui ne concerne pas le tenant. C'est une discipline exigeante, mais c'est la condition d'un produit immobilier crédible, un secteur où la confidentialité des mandats et des coordonnées est un actif sensible, comme nous l'évoquons dans notre analyse du secteur immobilier.

L'authentification multi-rôles

Une plateforme immobilière n'a pas un seul type d'utilisateur. Au sein d'une même agence cohabitent des profils aux droits très différents : le directeur qui pilote son espace, les négociateurs qui gèrent leurs biens, parfois des collaborateurs aux accès restreints. À l'échelle de la plateforme, il y a aussi notre rôle d'administration globale.

Nous gérons cette diversité grâce au système d'authentification de Supabase, enrichi de rôles applicatifs. À la connexion, chaque utilisateur est rattaché à une agence et à un niveau de permission. Ce double marquage, le tenant et le rôle, alimente directement les règles de sécurité décrites plus haut. Un négociateur voit ses biens, son directeur voit ceux de toute l'agence, et personne ne franchit la frontière du tenant. L'authentification n'est donc pas une simple porte d'entrée : c'est le point de départ de toute la logique d'accès.

Personnaliser sans dupliquer

La promesse de la marque blanche, c'est que chaque agence se reconnaisse dans « son » application. Logo, couleurs, identité visuelle, contenus mis en avant : tout doit refléter sa marque, pas la nôtre. Le défi technique consiste à offrir cette personnalisation sans créer une version distincte du logiciel pour chaque client.

Notre réponse est de traiter la personnalisation comme de la donnée, et non comme du code. Chaque tenant possède sa configuration : ses couleurs, son identité, ses réglages d'affichage, stockés dans la base. L'application, au démarrage, lit la configuration de l'agence concernée et adapte son apparence en conséquence. Le même code source produit ainsi des expériences visuellement distinctes. Ajouter une agence ne demande pas de recompiler quoi que ce soit : il suffit de renseigner sa configuration. Nous illustrons ce fonctionnement de bout en bout dans notre étude de cas AGENCYA.

iOS et Android : une seule base de code

Côté mobile, nous avons fait le choix de React Native avec Expo. L'enjeu est le même que pour le multi-tenant, transposé aux plateformes : écrire le code une fois, le faire vivre partout. Plutôt que de développer une application en langage natif iOS, puis une seconde en natif Android, nous maintenons une base de code unique qui se décline sur les deux systèmes.

Les bénéfices sont concrets. Une fonctionnalité développée arrive simultanément sur iPhone et sur les terminaux Android, sans double effort et sans décalage de version entre les deux mondes. Le back-office, lui, permet à chaque agence de piloter ses biens et ses contenus. Cette approche partagée n'efface pas les spécificités de chaque système (notifications, publication sur les stores, ergonomies propres), mais elle concentre l'énergie de l'équipe sur la valeur métier plutôt que sur la duplication.

Les défis : monter en charge, sécuriser, déployer

Une architecture solide se juge à sa capacité à encaisser la croissance. Plusieurs sujets nous occupent en permanence. La montée en charge, d'abord : une base partagée doit rester rapide à mesure que les agences et les volumes de biens augmentent, ce qui passe par une indexation soignée et des requêtes pensées pour l'échelle. La sécurité, ensuite, qui n'est jamais acquise : les politiques d'isolation doivent être testées, vérifiées et reconfirmées à chaque évolution du schéma. Le déploiement, enfin : faire évoluer un socle commun sans interrompre le service de toutes les agences impose une grande rigueur sur les migrations de base et la rétrocompatibilité.

Ces défis ne sont pas des obstacles, ce sont les garde-fous qui distinguent un prototype d'un produit professionnel. Les anticiper dès la conception, c'est s'épargner une dette technique coûteuse plus tard.

Conclusion

AGENCYA n'est pas qu'une application : c'est une démonstration de notre manière de concevoir des produits faits pour durer. Multi-tenant pour mutualiser, Row Level Security pour isoler, authentification multi-rôles pour structurer les accès, personnalisation par la donnée pour respecter chaque marque, base de code mobile unique pour servir iOS et Android : chaque décision répond à une exigence de fiabilité et de sécurité. Si vous portez un projet immobilier ou un produit en marque blanche, nous serions ravis d'en discuter. Découvrez nos services ou écrivez-nous directement via notre page contact.