Construire une PropTech en tant qu'opérateur d'actifs

J'exploite trois locations de courte durée entre l'Algarve et l'Andalousie. La plateforme qui les gère est React + Supabase + Lovable Cloud. On me demande si le stack passe à l'échelle. Oui — mais pas de la façon dont les blogs l'imaginent.

J'ai commencé par lire des conseils PropTech. Le conseil était uniforme : construire pour des locataires, concevoir pour l'échelle, abstraire le modèle de propriété pour qu'il fonctionne sur différentes classes d'actifs. Suffisamment générique pour être licencié à d'autres opérateurs par la suite.

Ce conseil est juste — pour un type de PropTech.

Il en existe deux types, et de l'extérieur, ils se ressemblent.

Le premier type vend de la gouvernance à d'autres opérateurs. Le produit, c'est l'abstraction : un modèle multi-tenant qui fonctionne sur différentes classes d'actifs, configurable par client, découplé de l'exploitation réelle de l'acheteur. Échelle horizontale : plus de clients, chacun exploitant sa propre activité sur la plateforme.

Le second type gère les actifs propres de l'opérateur. Le produit, c'est l'intégration : un couplage profond avec la façon dont je fais l'onboarding des voyageurs, tarife les propriétés, synchronise les calendriers, gère la conformité. Échelle verticale : plus d'actifs à moi, plus de juridictions, plus de propriétaires sous ma gestion — mais la plateforme est à moi, pas sous licence.

Les deux passent à l'échelle. Les deux sont de vrais business. Ils passent simplement à l'échelle sur des axes différents.

Je construis le second type. Voici ce que cela signifie en pratique.

La plateforme est multi-tenant — pour mes propriétaires, pas pour d'autres opérateurs. Row-Level Security et l'authentification multifacteur (MFA) existent parce que je gère des actifs pour le compte de propriétaires qui ont besoin d'un accès limité à leurs propres finances. Ajouter le dixième propriétaire est une modification de configuration, pas une refonte d'architecture. Mais ici, « tenant » signifie « propriétaire avec qui je travaille », pas « client PropTech qui me paie un abonnement SaaS ».

La conformité est codée pour les juridictions où j'opère. Le RNAL au Portugal. La NRUA en Espagne. Le RGPD partout. La plateforme code ces règles par défaut parce que je sais dans quelle juridiction se trouve chaque propriété. Ajouter une troisième juridiction (EAU, France) revient à créer un fork des règles de conformité par défaut — même architecture, plus de règles. La plateforme supporte l'horizontalité par juridiction, même si elle ne supporte pas l'horizontalité par client.

Les edge functions automatisent mes opérations récurrentes. Cinq edge functions en production prennent en charge des tâches qui, autrement, me prendraient du temps : synchronisation iCal depuis Airbnb (sync-ical-feeds), cycle de vie des tokens du portail propriétaires (generate / validate / revoke tokens) et routage des e-mails de contact. Chacune remplace une tâche manuelle récurrente par propriété. Ajouter la quatrième propriété n'ajoute pas quatre heures d'administration hebdomadaire — les edge functions les absorbent. C'est ça, l'échelle verticale.

La contrainte n'est pas la capacité, c'est le positionnement. Pourrais-je licencier cela à un autre opérateur demain ? Techniquement, oui — Supabase est multi-tenant, le code est suffisamment propre. Mais le jour où je voudrais vendre cela comme un SaaS, l'architecture changerait : configurabilité plutôt que valeurs par défaut, workflows abstraits plutôt que conformité codée en dur, couche de customer success, facturation. C'est un produit différent, pas un refactor. Et c'est un choix stratégique de ne pas le construire.

Le piège de la PropTech d'opérateur n'est pas de prétendre que c'est un futur SaaS. C'est de prétendre que le choix n'existe pas. Il y a une vraie bifurcation : vendez-vous de la gouvernance à des opérateurs, ou exploitez-vous ? Vendre signifie investir dans l'abstraction, la configurabilité, l'onboarding des clients, le support. Exploiter signifie investir dans une intégration profonde avec ses propres opérations, la conformité pour ses propres juridictions, l'automatisation de ses propres tâches récurrentes.

Les deux mènent quelque part. Ils mènent à des endroits différents.

Pour l'instant, j'exploite. La plateforme évolue avec moi — plus de propriétés, plus de propriétaires, plus de juridictions, automatisée là où cela compte. Le jour où la question stratégique sera « LusiberiaStays devrait-elle devenir une PropTech SaaS ? » sera le jour où la conversation sur l'architecture commencera. Aujourd'hui n'est pas ce jour.

La PropTech que j'exploite m'exploite en retour. Ce n'est pas une limitation. C'est la conception.

Sources

• LusiberiaStays operations stack: React 18 + TypeScript + Supabase + Lovable Cloud
• Compliance frameworks: PT DL 128/2014 (consolidated DL 76/2024), ES Decreto 28/2016, GDPR
• Edge functions in production: sync-ical-feeds, send-contact-email, generate-portal-token, validate-portal-access, revoke-portal-token
• Properties under management: 3 (Algarve, Algarve, Andalucía)
• Multi-tenant architecture: Row-Level Security on Supabase, MFA TOTP on admin, owner portal with token-scoped access