Aller au contenu

Espace Financement

Définition

Plateforme côté porteur de projet (PDP) : elle permet à un porteur de demander un financement immobilier sur Bricks, de suivre l'instruction de son dossier, puis de gérer son projet une fois financé (remboursements, documents, tirages travaux). C'est le pendant, côté demandeur de fonds, de l'application d'investissement (côté investisseurs). Elle remplace l'ancien outil bâti sur Bubble. Nom technique du module : app-pdp-financement (dev : app-financement.dev.bricks.co · prod : app-financement.bricks.co).

Pourquoi on en parle

Le chantier consiste à sortir tout l'outil porteur de Bubble (no-code) pour le reconstruire sur la stack Bricks, dans le cadre d'une bascule « big bang » — pas de cohabitation hybride (cf. ADR 2026-06-16). Jusqu'ici, ce périmètre était peu documenté dans le second cerveau alors qu'il représente une plateforme à part entière, avec ses propres parcours, règles et modèle de rôles. Cette page consolide le savoir issu de l'initiative Linear « Avoir un nouvel espace financement », des maquettes Figma et du channel Slack dédié #refonte-espace-financement.

Cadre : internal. Les chiffres financiers cités en exemple (apport, frais, taux, durée) proviennent de maquettes et sont illustratifs ; les conditions réelles sont définies au comité, projet par projet (cf. outil d'analyse).

Fonctionnement

Modèle produit et périmètre

Bricks est une plateforme de financement participatif agréée AMF : une communauté d'investisseurs prête aux porteurs de projets immobiliers sous forme d'obligations (cf. produit Bricks — présentation). L'Espace Financement est le guichet du porteur dans ce modèle : il y présente son projet, Bricks l'analyse, le met en collecte auprès des investisseurs, puis lui reverse les fonds et suit le remboursement.

Parcours annoncé au porteur, en 4 temps (maquette landing) : (1) constituer son dossier → (2) analyse par les équipes → (3) mise en ligne / collecte → (4) réception des fonds (Figma — Landing page).

5 typologies de projet éligibles, présentées dans le module d'éligibilité : marchand de biens, projet d'exploitation, projet locatif, promotion immobilière, refinancement (Figma — Eligibility module).

Périmètre de l'initiative (initiative Linear) : - Dans l'EF (tout ce qui est face-porteur) : parcours de préfinancement (front + API), espace post-financement côté porteur, gestion des users & rôles, migration des données Bubble, QA, design. - Hors EF (→ initiative sœur « Débrancher Bubble ») : les outils ops / back-office non face-porteur (édition admin, validation des tirages, trésorerie, messagerie ops, espace notaire côté ops, génération des garanties/contrats). - Règle produit transverse : vue mono-projet par défaut sur chaque écran (sauf la page Actualités), décidée au kick-off du 16/06. - Plafond réglementaire de collecte : 5 M€ / an / société (pas de blocage technique en V1, garde-fou éventuel en V2) (#refonte-espace-financement, Rémy, 2026-07-17).

Rôles et droits

Le modèle repose sur 3 rôles (le rôle « Autre / Admin » a été renommé Collaborateur le 29/07 ; on évite le mot « admin », qui prête à confusion avec l'admin interne Bricks). La table des membres est la seule source d'autorisation ; le socle back est BRI-1807, la matrice de droits BRI-1661 (table technique project_financing_request_member).

Périmètre Représentant Collaborateur Apporteur d'affaires
Page Utilisateurs (gestion des membres) Tous droits Tous droits Tous droits
Parcours de demande (préfinancement) Tout Tout Jusqu'à l'étape Analyse incluse
Voit l'Offre et la suite du parcours Oui Oui Non
Post-financement / suivi Toutes les pages Toutes les pages Dashboard + Utilisateurs uniquement
Signature Oui (exclusif) Non Non
  • Règle centrale : « La signature est dans tous les cas exclusive aux représentants » (précisé par Rémy, 2026-08-04).
  • Apporteur d'affaires : voit le statut de l'analyse de son dossier mais pas l'offre faite ; côté suivi, accès limité aux pages Dashboard et Utilisateurs (précisé par Rémy, 2026-08-04). Gating technique : BRI-1788. Note interne : « ça nous coûte de l'argent, les apporteurs d'affaires » — d'où un périmètre volontairement borné (#refonte-espace-financement, Romain, 2026-07-23).
  • Pas de droits plus fins en V1 : tous les rôles ont accès au parcours de demande ; on ne raffine pas davantage pour l'instant (précisé par Rémy, 2026-08-04).
  • Attribution des rôles :
  • À la création d'un projet, le choix du rôle est réduit à une checkbox « je suis apporteur d'affaires » (pas d'écran de sélection de rôle) (BRI-1791 ; #refonte-espace-financement, Hugo, 2026-07-28). C'est le seul moment pour se déclarer apporteur. Sinon, rôle par défaut = Collaborateur.
  • Un invité (par lien / mail) est toujours Collaborateur — le sélecteur de rôle a été retiré de la modale ; le lien d'invitation n'expire jamais (CTA « Relancer » disponible) (BRI-1784).
  • Un Collaborateur peut être promu Représentant en s'ajoutant à la liste à l'étape Emprunteur (identification par matching nom-prénom via Pappers).
  • Limitation V1 assumée : la checkbox apporteur est posée dès la création de compte, donc figée pour le 1er projet ; un même utilisateur ne peut pas être apporteur sur un projet et porteur sur un autre en V1. Reconnu comme « un dev contre nature » à rattraper plus tard (#refonte-espace-financement, Romain/Denis, 2026-07-23).
  • Disclaimer d'accès : ajouter un membre lui donne accès à la messagerie (et son historique) + tous les documents — information portée dans la description des rôles.

Parcours de demande de financement

Un tunnel en steps avec une machine à états par step (disabled / todo / done) qui redirige toujours vers la première étape non complétée (BRI-839). Découpage refondu le 2026-07-16 (#refonte-espace-financement, Rémy) :

Groupe 1 — le porteur monte son dossier : Présentation → Documents → Emprunteur (skippable) → envoi en analyse. Gate : Analyse (instruction par les équipes ops / back-office). Groupe 2 — après acceptation : Offre (affiche le résultat uniquement) → Emprunteur (ici si elle a été sautée — obligatoire pour rédiger les contrats) → Finalisation (ex-Collecte) → Signature.

Règles marquantes : - L'étape Emprunteur est « skippable » : le porteur peut envoyer son dossier en analyse sans l'avoir finie ; elle est alors repositionnée en groupe 2, entre Offre et Signature (BRI-1504). - 3 flows sur l'étape Emprunteur : recherche société via Pappers, saisie manuelle, ou société déjà enregistrée. Le représentant y est identifié par matching nom-prénom Pappers (#refonte-espace-financement, Rémy, 2026-08-03). - Le KYC (vérification d'identité) est porté par l'étape Finalisation — bloc « Vérification d'identité requise » qui redirige vers une page externe du partenaire Lemonway (Figma — Finalisation / KYC). Son emplacement a bougé au fil du cadrage (Offre → Emprunteur → Finalisation) ; l'état actuel est la Finalisation (précisé par Rémy, 2026-08-04). L'Offre n'affiche que le résultat. - Le KYC est considéré « validé » dès qu'il est débuté sur Lemonway (label « En cours » ; la validation réelle est suivie en asynchrone côté ops) (#refonte-espace-financement, Romain, 2026-07-22). - Un KYC rejeté n'est jamais bloquant dans le front (helper de relance non bloquant) ; en revanche la collecte n'est jamais mise en ligne tant que le KYC n'est pas validé côté Lemonway (prérequis back-office). - L'Analyse est un gate piloté par les équipes. États exposés au porteur : en cours, rejetée (avec commentaire), missing_information (ex-« bloquée »), approuvée. L'Offre ne s'ouvre qu'après approbation (BRI-1304, BRI-1305, BRI-1518). - Compléter son dossier pendant l'analyse = un seul flow « Annuler l'analyse » (bouton destructif + modale) qui repasse l'Emprunteur en draft éditable, puis re-soumission via le CTA existant (choix assumé pour éviter de multiplier les flows et le coût d'une ré-analyse) (#refonte-espace-financement, 2026-07-03). - Finalisation (renommée depuis « Collecte ») : synchro bancaire, informations bancaires, vérification d'identité (KYC Lemonway), et le porteur peut renseigner son propre notaire (BRI-1499). - Synchro bancaire (Bridge) : non nécessaire pour générer les contrats (IBAN + BIC suffisent, la RUM du mandat SEPA est générée côté Analyse), mais obligatoire par défaut pour signer, avec bypass possible via une coche back-office pour les cas à la marge. Non retirable du scope V1 (#refonte-espace-financement, Romain/Benoit, 2026-07-28 → 2026-08-03). - Signature : signature électronique des documents (groupés, avec témoin de signature). Le porteur peut relancer lui-même par mail un signataire (ex. un cautionnaire) sans passer par les ops (BRI-1816). - Pas de date d'expiration de l'offre dans le modèle (la « validité 15 jours » de la maquette peut rester en front pour inciter, mais n'est pas bloquante techniquement) (#refonte-espace-financement, 2026-07-17). - Reprendre un projet abandonné : modale « Reprendre ce projet » + bouton « Reprendre » sur le dashboard. - Entrée dans le parcours — tunnel de compte : landing (import du document de présentation) → création de compte → validation email par code (composant réutilisé de l'app invest, pas de lien) → « À propos de votre projet » (nom, type, besoin en financement, date de réception des fonds souhaitée, checkbox apporteur d'affaires) (Figma — Signup).

Modalités financières

Valeurs relevées dans le simulateur, illustratives (confirmées comme exemples par Rémy, 2026-08-04) — les conditions définitives sont établies après analyse (Figma — Simulation de financement) : - Apport personnel attendu : ~15 % du total. - Frais de collecte : ~8,4 % · Frais de garantie estimés : ~1,5 %. - Taux d'intérêt (exemple) : 10 % · Durée : 6 à 48 mois. - Remboursement anticipé sans pénalité · notion de séquestre travaux.

Taux évolutif (condition particulière réelle) : une offre peut porter un palier de taux — ex. 10 % sur 36 mois, +1 % (→ 11 %) si le remboursement dépasse 36 mois, jusqu'à un plafond de 48 mois ; au-delà, mise en défaut (#refonte-espace-financement, Vincent Besnier/Rémy, 2026-07-17).

Espace post-financement (projet financé)

Pages accessibles au porteur via le menu latéral :

Page Rôle Statut Linear
Dashboard / home Page d'accueil contextualisée selon le projet sélectionné ; vues distinctes porteur/collaborateur vs apporteur d'affaires ; « Mes autres projets » ; empty state (#refonte, Rémy, 2026-08-03) Refondu
Utilisateurs Gestion des membres du projet (invitations, rôles). Tous les rôles y ont tous les droits —
Actualités Fil d'actualités du projet = union des actus PDP + gestion des défauts + Bricks (uniquement le public, ce que voient les investisseurs — pas le fil interne défauts). Seule page non mono-projet en V1 —
Échéancier Suivi des remboursements : « 30 prochains jours », échéances restantes, capital restant dû ; statuts Payée / En retard / À venir ; régularisation ; remboursement de capital ; accès aux factures de frais de gestion (BRI-1351) En cours
Documents Onglet unique des documents post-financement = exactement les mêmes documents que l'étape Signature (ni plus ni moins), visibles par tous les membres y compris collaborateurs non-signataires. Contient aussi les factures (frais de gestion + collecte). Pas de documents post-signature en V1 (BRI-1629) Livré
Tirages travaux Suivre le séquestre travaux et demander un déblocage en self-service, contre facture. Règle : disponible = total − tiré − en attente. La validation reste sur le back-office Projet (GET/POST API Bricks, pas d'iframe en V1) (BRI-1391, BRI-1392) Livré
Aide Support / aide Livré

Requêtes (terme retenu, ex-« demandes ») : le porteur peut créer et suivre des requêtes ISO Bubble — types préformatés prorogation (en mois), report de procédure (date, ex-« gel désintérêt »), et « autre » (texte libre). Pas d'upload de doc ni de % de refus en V1.

Messagerie / chat : embarquée via un outil tiers, présente partout où pertinent (détail projet, tirages travaux, etc.) — pas d'outil de messagerie dédié.

Deux mondes de facturation à ne pas confondre : - Axonaut → factures de frais de gestion et de frais de fiducie (feature-flaggées), mensuelles, non stockées chez Bricks (récupérées à la demande), consultées depuis l'Échéancier. Téléchargement unitaire en V0 (téléchargement groupé prévu ensuite) (BRI-1381, BRI-1387). - InvoiceNinja → factures de frais de collecte, générées à l'envoi des fonds au porteur (depuis le back-office), facturées au porteur (montant fixé en comité), exposées dans Documents. - La société Axonaut et le client InvoiceNinja sont créés à la publication du projet ; la création de société Axonaut (faite par Bubble aujourd'hui) doit être reprise avant la release à cause du big bang.

Contrats, signature et notaire

  • C'est Bricks qui édite les contrats et pilote la signature électronique via YouSign (QTSP français, signature SES ; iframe repoussée en V2). Les contrats sont portés par l'outil d'analyse, pas par l'EF : l'EF affiche le parcours et récupère états + documents (ADR 2026-04-30 source contrats V1).
  • L'état de signature remonte via un déclencheur backend existant (check_full_signature_documents) et alimente 3 vues : côté porteur (BRI-450), côté ops / back-office (vue signataire par signataire + alerte Slack quand tout est signé, BRI-1820), et un espace notaire minimaliste.
  • Une caution externe (personne créée côté Analyse, hors Pappers) signe par mail YouSign mais pas via un bouton connecté dans l'EF en MVP.
  • Espace notaire : prototype front autonome (vibe-codé, hors EF pour ne pas la charger), même périmètre que Bubble ; intégration à la plateforme en V2. Un seul notaire à date (plusieurs à terme). Règle : le notaire de Bricks n'est pas celui du porteur ; l'espace explicite, par projet, de quel notaire il s'agit.

Modèle de données & fil rouge technique

  • Renommage SPV → ProjectOwnerCompany (BRI-1501) et passage de 1-1 à 1-N (une société peut porter plusieurs demandes de financement — un porteur peut emprunter avec sa société existante).
  • Statuts : blocked → missing_information ; nouveau statut canceled (projet abandonné = « archiver » dans l'UI, statut à part entière, déclenchable par Bricks ou par le porteur).
  • Débat de modélisation non tranché [à confirmer] : entité racine côté project-financing-request (préfi) puis bascule vers project à l'acceptation (position retenue en bootstrap), vs project comme racine durable unique (les obligataires migrés seront des projets sans demande). Recadrage calé début juillet — atterrissage à vérifier (#refonte-espace-financement, 2026-06-30).
  • Fil rouge : sortir de Bubble / no-code et reconstruire sur la stack Bricks — modules Kysely, montants en Cents, composants du design system Uimmo obligatoires (jamais de valeurs hardcodées), front smart/dumb + Storybook, principe « même table, actions différentes ». Automatisations no-code rapatriées : Make (orchestration au passage en financement : event Google Calendar financements@bricks.co + appel Bubble create-property conservé + alerte Slack #espace-financement-alertes, BRI-1819), n8n (assignation automatique aux Account Managers : dispo / plafond / % de répartition, BRI-258).
  • Authentification : une seule instance Better Auth partagée entre l'app invest et l'app porteur ; signup porteur marqué registeredFrom: 'financing' ; vérification email par code (OTP), 2FA, hub sécurité. Projet « Rework Auth » terminé.
  • KYB (Lemonway) : le porteur passe son KYB société via Lemonway depuis l'EF ; principe cardinal : le code métier ne manipule jamais les IDs Lemonway bruts, tout passe par un service d'abstraction (cf. ADR 2026-07-06 ; monorepo/docs/spv-creation-flow.md).
  • Analytics : instrumentation du tunnel avec PostHog. Stack front : Uniwind, Biome, SimpleLocalize, CustomerIO, skeletons, error boundary.
  • Migration Bubble : big bang on/off, sans cohabitation. Owner : Kevin Adoul (freelance). La migration des données est identifiée comme le chantier le plus bloquant / incompressible (reprise par Benoit). Samples JSON + schéma de mapping tenus sur Google Drive / Sheets.

Décisions liées

Projets et areas impactés

Sources

  • Initiative Linear — « Avoir un nouvel espace financement » (owner Romain Bazil) — scope, décisions de kick-off 16/06, modèle de rôles
  • Projets Linear de l'initiative : Structure du flow de création, Steps (Présentation, Documents, Emprunteur, Analyse, Offre, Collecte→Finalisation, Signature), Gestion des users & droits, Rework Auth, Orchestration passage en financement, Assignation AM, KYB Lemonway, pages Échéancier / Documents / Tirages travaux / Aide / Actualités, contrats & offre, espace notaire
  • Issues clés : BRI-1807 (modèle de membres + guard), BRI-1504 (phases + skip emprunteur + renommage Collecte→Finalisation), BRI-839 (machine à états), BRI-1784 / BRI-1788 / BRI-1791 (rôles & invitations), BRI-1501 (rename SPV→ProjectOwnerCompany), BRI-1819 (orchestration Make), BRI-258 (assignation AM), BRI-1351 (Échéancier), BRI-1391 / BRI-1392 (Tirages travaux), BRI-1820 (contrats vue ops)
  • Fichier Figma — 💼 EspaceFi : landing page, module d'éligibilité, simulateur, tunnel signup / login, Dashboard, Demandes, Actualités, Utilisateurs, rôles
  • Channel Slack #refonte-espace-financement (oct. 2025 → août 2026) : arbitrages rôles/droits, refonte des steps (16/07), KYC & Bridge, signature YouSign, facturation Axonaut/InvoiceNinja, actualités & requêtes, modèle de données, notaire, migration
  • Précisions produit apportées par Rémy Chavardes en session (2026-08-04) : règle de signature, périmètre de l'apporteur d'affaires, attribution des rôles, statut illustratif des chiffres du simulateur