Platane a rejoint l'initiative France Num pour accompagner les TPE PME dans leur transformation numérique : diagnostics, formations et aides financières.
L'off-market représente plus de 10 % des ventes immobilières en France selon Hosman, et la part monte fortement sur les biens haut de gamme et les opérations entre marchands de biens. Pourtant, la plupart des réseaux qui gèrent ce flux de deals tournent encore sur du WhatsApp, des feuilles Google Sheets partagées et des CRM bricolés. Quand un fondateur décide d'en faire une vraie plateforme off-market immobilier, il découvre que la difficulté n'est ni le design ni l'inventaire : c'est de réconcilier confidentialité, matching pertinent et modèle économique récurrent dans un seul produit cohérent.
Cet enjeu touche aussi les clubs deal, les réseaux d'investisseurs privés, les apporteurs d'affaires immobiliers, les chasseurs et les marchands de biens. Le besoin métier est commun, l'architecture technique aussi. Voici comment nous concevons un MVP solide, quelles décisions structurent les 6 premiers mois, et où sont les pièges qui font dérailler le projet à 80 % d'avancement.
Une plateforme off-market n'est pas une marketplace classique
Un site comme SeLoger ou Leboncoin Immobilier optimise pour la discovery publique : SEO, filtres ouverts, indexation Google, photos en HD. Tout l'inverse de l'off-market. Sur une plateforme off-market immobilier, la valeur vient du réseau et de la rareté. Le bien le plus convoité ne doit ni être indexé, ni apparaître dans une URL publique, ni être listé pour les non-membres.
Cette inversion change tout :
Pas de SEO produit, donc pas d'enjeu Core Web Vitals sur les fiches biens.
Authentification systématique avant l'accès au moindre fil d'annonces.
Plusieurs niveaux de visibilité par publication : public membres, accès sur demande, accès sous NDA, privé limité à un cercle.
Plusieurs types de posts : opportunité côté vendeur, recherche acquéreur, référence (un partenaire utile, un dossier financier).
Côté UX, on n'optimise pas la conversion d'un visiteur anonyme : on optimise la qualité du fil pour un membre déjà connecté. C'est plus proche d'un Slack métier que d'un site immobilier.
:::our-take
La métrique de succès d'une plateforme off-market n'est pas le nombre de biens listés, c'est le pourcentage de biens listés qui débouchent sur une mise en relation qualifiée. Un MVP qui shippe 5 biens convertis vaut mieux qu'un MVP qui shippe 500 fiches dormantes.
:::
Sur ce type de produit, nous avons par exemple accompagné Astory sur la conception d'une plateforme transactionnelle privée (location d'œuvres d'art entre galeries et collectionneurs), avec une logique très proche : authentification stricte, pas d'indexation publique, contrats personnalisés. Trois ans plus tard, Astory dépasse 800 000 € de chiffre d'affaires annuel. Les patterns décrits ci-dessous sont issus de ce type de retour terrain.
Le BlogDes infos, des actus, du fun !
Créer une plateforme FinTech intelligente : architecture, IA et conformité
Découvrez les enjeux techniques et stratégiques pour concevoir une plateforme FinTech Full Stack intégrant l'intelligence artificielle, des calculs financiers avancés et une architecture multi-tenant sécurisée et conforme RGPD.
Comment créer une plateforme d'abonnement sécurisée avec gestion de paiements récurrents et intelligence artificielle
Guide complet pour développer une solution web multi-interfaces intégrant Stripe, IA conversationnelle et conformité RGPD pour la gestion d'abonnements et de services clients.
Plateforme off-market immobilier : architecture confidentielle d'un MVP
Le socle confidentialité : Supabase et la Row Level Security
La pile Next.js + Supabase + Stripe est un excellent choix par défaut pour ce type de produit. Pas parce que c'est tendance, mais parce que Supabase Row Level Security (RLS) déplace l'enforcement des règles de confidentialité au niveau de la base Postgres, pas au niveau du code applicatif. Concrètement : même si un développeur oublie un check dans une route API, la base refuse la requête.
Le pattern de base pour un fil d'annonces multi-niveaux ressemble à ceci :
altertablepublic.posts enablerowlevel security;-- Niveau 1 : posts publics membres (tous les comptes authentifiés)create policy "members_can_read_public_posts"onpublic.posts forselectusing( visibility ='public_members'and auth.uid()isnotnull);-- Niveau 2 : posts contrôlés (accès accordé explicitement)create policy "members_with_grant_can_read"onpublic.posts forselectusing( visibility in('controlled','nda')andexists(select1frompublic.post_access_grants g
where g.post_id = posts.id
and g.user_id = auth.uid()and g.status='granted'));-- Niveau 3 : posts privés (auteur uniquement)create policy "owner_can_read_private"onpublic.posts forselectusing( visibility ='private'and author_id = auth.uid());
Trois choses comptent :
Une policy par niveau de visibilité, pas une grosse policy à condition unique. Plus lisible, plus auditable, plus facile à tester.
Une table post_access_grants séparée qui trace qui a obtenu accès à quoi, quand, et après quelle action (demande simple, signature NDA, validation manuelle). C'est l'audit log natif.
Le service role Supabase bypasse la RLS. Il ne sort jamais du backend. Si un développeur copie-colle la clé service dans le frontend, tout le modèle de sécurité s'effondre. C'est l'erreur la plus courante.
:::warning
Une RLS lente bloque tout le produit. Si vos policies font des JOIN complexes ou appellent des fonctions Postgres non immutables sur chaque ligne, vous allez payer en latence. Indexez les colonnes utilisées dans les policies (visibility, author_id, post_id sur les grants) et utilisez (select auth.uid()) plutôt que auth.uid() direct dans les conditions, l'optimiseur Postgres mettra le résultat en cache pour la requête.
:::
L'agence Platane (https://platane.io) applique exactement ce pattern sur Jef.chat, l'assistant IA du Barreau de Bruxelles. Chaque avocat a son propre espace documentaire, et l'isolation par tenant est garantie par RLS au niveau base. Même un administrateur système n'a pas de visibilité sur les contenus individuels. C'est le bon niveau d'exigence pour de la donnée transactionnelle off-market.
Matching scoring : commencer simple, mesurer avant d'optimiser
Le brief type sur ce sujet contient toujours la phrase : "moteur de matching IA paramétrable". La tentation est forte de partir sur des embeddings vectoriels et un LLM. C'est presque toujours une erreur en V1.
La raison est simple : un moteur d'apprentissage a besoin de signaux de feedback pour apprendre (clic, sauvegarde, demande d'accès, transaction conclue). Tant que ces signaux n'existent pas dans la donnée, n'importe quel modèle ML produit du bruit. La bonne séquence : un scoring heuristique qui marche, puis du feedback collecté pendant 6 à 12 mois, puis un réentraînement supervisé.
Un scoring heuristique pour de l'immobilier pro tient en 50 lignes de TypeScript :
Les poids sont configurables par profil. Un investisseur patrimonial pondère la zone à 50 %, un value-add pondère le rendement à 40 %. Le membre doit pouvoir les ajuster.
Le seuil d'alerte est explicite. Un score ≥ 0,65 déclenche une notification, sinon le deal apparaît juste dans la recherche. Sans seuil, on noie le membre.
On stocke le score historisé dans la base, pas calculé à la volée. Quand un profil de recherche est mis à jour, on rejoue le scoring sur les opportunités actives. C'est la base du futur entraînement supervisé.
:::tip
Avant d'écrire la moindre ligne de matching, demandez à 3 utilisateurs cibles de scorer manuellement 20 opportunités selon leurs propres critères. Comparez avec votre algorithme. Si vous êtes à 70 % d'accord avec eux, vous avez un MVP exploitable. En dessous, vos poids sont à revoir.
:::
NDA et data room légère : ne pas réinventer DocuSign
La 7e fonctionnalité du brief type est toujours "système simple de NDA et data room". Le piège : viser un workflow d'eSignature légalement bétonné dès la V1. C'est 2 à 3 mois de dev pour quelque chose que les utilisateurs n'utiliseront pas avant d'avoir trouvé du flux.
Le pattern MVP qui suffit dans 90 % des cas :
L'utilisateur clique sur "demander l'accès au dossier".
Il coche une case "j'accepte les termes d'accès" qui affiche le contenu d'un NDA standard rédigé par le juriste de la plateforme.
On enregistre en base : user_id, post_id, accepted_at, ip_address, user_agent, nda_version_hash.
La RLS débloque l'accès aux pièces jointes du dossier pour cet utilisateur.
Chaque téléchargement de pièce ajoute une ligne dans la table document_access_log.
Cette approche est très proche de l'architecture "One-Click NDA" que documentent des acteurs spécialisés comme Digify. Pour un MVP, c'est largement suffisant. Le jour où un litige réel oblige à passer à l'eSignature qualifiée, on intègre DocuSign ou PandaDoc côté API en quelques jours, et on remplace l'étape 2.
:::gotcha
Le hash de version du NDA est crucial. Si vous modifiez les termes en V2, les utilisateurs qui ont accepté la V1 conservent leur acceptation V1. Sans hash de version, vous ne pouvez plus prouver à quelle version chaque acceptation correspond. Stockez le contenu complet du NDA accepté dans Supabase Storage, hashé en SHA-256, jamais juste un numéro de révision.
:::
Stripe et plans freemium : le piège du billing trop tôt
L'intégration Stripe est la partie la plus documentée et la moins risquée techniquement. Les vraies questions sont stratégiques.
Le triptyque classique Free / Essai / Pro fonctionne bien sur ce type de plateforme, à condition de respecter trois règles :
Le Free doit permettre de voir suffisamment pour donner envie, pas juste une page de teasing. Les membres comparent en 30 secondes : si le Free n'expose rien, ils ne reviennent pas.
L'Essai est temporel, 14 ou 30 jours, avec carte demandée à la souscription. C'est la friction qui filtre les curieux et qualifie l'intention.
Le Pro débloque les profils de matching multiples, les alertes, l'accès aux dossiers NDA, et la messagerie illimitée.
Côté code, le pattern Next.js + Stripe est canonique : un endpoint /api/stripe/checkout qui crée la Checkout Session, un webhook /api/stripe/webhook qui écoute checkout.session.completed, customer.subscription.updated et customer.subscription.deleted, et une table subscriptions dans Supabase qui sert de source de vérité applicative. La doc officielle Stripe Billing couvre les 80 % du sujet.
Deux gotchas qui font perdre des soirées :
Les webhooks Stripe loupent. Pas souvent, mais ça arrive (timeout, déploiement en cours, bug temporaire). Sans job de réconciliation quotidien qui compare l'état Stripe avec l'état Supabase, vous aurez des comptes en active côté app pour des abonnements annulés côté Stripe. Le temps qu'un user le signale, vous lui devez un remboursement.
Les entitlements doivent être lus côté Postgres, pas côté Next.js. Si la logique "ce user a accès à la fonctionnalité X" est dans le frontend, on peut la contourner. Stockez les entitlements dans une table indexée et faites-les vérifier par RLS sur les tables sensibles.
L'architecture qu'on a posée pour Easop, startup spécialisée dans la gestion internationale des stock-options, suit exactement cette logique. Elle a tenu pendant 2 ans de croissance jusqu'au rachat par Remote.com. La même rigueur sur le billing s'applique pour une plateforme off-market qui ambitionne plusieurs centaines de membres payants.
L'extension navigateur : fausse bonne idée du MVP
Le brief mentionne presque toujours "option : extension navigateur pour importer des annonces depuis des sites externes". C'est tentant : ça permet à un membre de capturer un deal repéré sur LinkedIn ou un site d'agence sans recopier. En pratique, c'est presque toujours à reporter en V2. Trois raisons :
Coût de maintenance par site cible. Chaque site externe a son DOM, ses anti-bots, ses CGU. Une extension qui supporte 5 sites représente 5 selectors à maintenir, et chaque refonte de site cible casse l'extension.
Conformité incertaine. Beaucoup de sites immobiliers interdisent explicitement le scraping dans leurs CGU. Même un usage individuel via extension peut tomber sous le coup d'une violation contractuelle, voire d'un abus de la base de données protégée par le code de la propriété intellectuelle.
Workflow utilisateur fragile. L'utilisateur doit installer un binaire, l'autoriser sur chaque site, gérer la mise à jour. Le taux d'adoption tombe vite à 10 ou 15 %.
L'alternative MVP qui marche : un import par copier-coller. L'utilisateur copie le texte d'une annonce, le colle dans un formulaire, et un appel à un LLM (GPT-4o, Claude, Mistral via Scaleway) extrait les champs structurés (prix, surface, zone, type d'actif). Ça fonctionne sur 100 % des sources, ça ne casse jamais, ça coûte 0,005 € par import. La structuration manque parfois sur les annonces atypiques, mais l'utilisateur corrige avant de publier. C'est un workflow assumé.
L'extension reprend du sens en V2, sur 1 ou 2 sites cibles seulement, quand la volumétrie le justifie et que la base utilisateurs est suffisante pour amortir le coût de maintenance.
Périmètre MVP : ce qu'on coupe au premier semestre
Sur 12 fonctionnalités demandées dans le brief type, 6 forment le vrai MVP :
Authentification + onboarding + profil membre.
Fil d'annonces avec 3 niveaux de visibilité (public membres, contrôlé, NDA).
Création de posts avec champs structurés et pièces jointes.
Matching scoring heuristique avec un seul profil par membre.
Messagerie privée 1-1 reliée aux annonces.
Stripe avec 2 plans (Free, Pro) et webhook de réconciliation.
Les 6 autres glissent en V2 :
Profils de recherche multiples, scoring multi-strategy.
Data room avec eSignature qualifiée.
Librairie personnelle, coffre documentaire.
Annuaire membres avec filtres avancés.
Centre d'alertes multicanal (in-app + email + push).
Extension navigateur d'import.
Avec une équipe de 2 développeurs full-stack, ce périmètre MVP tient sur un calendrier de 14 à 16 semaines, soit un budget total entre 60 et 90 k€ HT selon le niveau de finition design. C'est l'ordre de grandeur réaliste pour un produit que des professionnels accepteront de payer 80 à 150 € par mois.
Côté infrastructure : Supabase Pro à 25 $/mois pour les 100 premiers utilisateurs, Vercel Pro à 20 $/mois, Stripe sans frais fixes, plus un poste de stockage S3 pour les pièces jointes via Supabase Storage. On reste sous 200 € de coûts mensuels jusqu'à plusieurs centaines de membres actifs. C'est l'avantage de cette pile : l'économie d'unité est saine dès le premier euro encaissé.
Questions fréquentes sur la construction d'une plateforme off-market
Combien de temps faut-il pour développer un MVP de plateforme off-market immobilier ?
Pour le périmètre MVP de 6 fonctionnalités décrit ci-dessus, comptez 14 à 16 semaines avec une équipe de 2 développeurs full-stack, soit 60 à 90 k€ HT. Un périmètre étendu avec extension navigateur, alertes multicanal et eSignature qualifiée représente 22 à 26 semaines.
Pourquoi choisir Supabase plutôt que Firebase pour ce type de plateforme ?
Supabase repose sur Postgres, qui supporte nativement la Row Level Security et les requêtes SQL complexes nécessaires au matching scoring. Firebase Firestore ne permet pas la RLS native ni les jointures, ce qui rend les règles de confidentialité multi-niveaux beaucoup plus difficiles à enforcer côté base.
Faut-il un vrai NDA juridique en MVP ou un simple terms of access suffit ?
Pour un MVP qui démarre avec moins de 100 membres, un terms of access avec horodatage, IP et hash de version suffit. Le passage à un NDA qualifié via DocuSign ou PandaDoc se fait en V2, quand le volume de transactions le justifie et que les premiers litiges potentiels apparaissent.
Combien coûte l'infrastructure d'une plateforme off-market avec 100 membres actifs ?
Moins de 200 € par mois en moyenne, en additionnant Supabase Pro, Vercel Pro, Stripe (commission uniquement), et le stockage S3 via Supabase Storage. Cette structure de coût permet une marge brute supérieure à 90 % dès qu'on dépasse 30 abonnés payants à 100 € par mois.
Quels sont les principaux risques d'échec d'un projet de plateforme off-market ?
Les trois plus fréquents : vouloir un moteur de matching IA en V1 sans avoir de feedback utilisateur, sous-estimer la complexité de la RLS et concentrer la sécurité dans le code applicatif, et investir trop tôt dans des features comme l'extension navigateur ou la data room avant que le produit ait prouvé sa valeur réseau.
Conclusion
Construire une plateforme off-market immobilier ne se résume pas à empiler Next.js, Supabase et Stripe. La vraie ingénierie est dans les arbitrages : quels niveaux de confidentialité on enforce dès la V1, quelle simplicité on accepte sur le matching scoring, à quel moment on laisse la data room tomber dans les V2. Ces choix conditionnent le time-to-market, le coût de maintenance et la confiance que les premiers membres accorderont au produit.
Si vous portez ce type de projet et que vous voulez challenger votre architecture cible, votre périmètre MVP ou votre stack avant de signer avec une équipe technique, contactez Platane. Notre double casquette dev et conseil produit nous permet de cadrer un projet en quelques sessions de sparring, et de poser des fondations qui tiennent pendant les 2 ou 3 années de croissance qui suivent le lancement.
Développement Frontend React pour SaaS : Les Clés d'une Interface Utilisateur Performante
Découvrez les meilleures pratiques pour développer une interface utilisateur SaaS avec React, TailwindCSS et une approche UX centrée utilisateur. Apprenez comment créer un frontend performant, responsive et évolutif pour votre application.
