L'entrepreneur a la vue d'ensemble. Le chef de chantier gère ses chantiers. Le maître d'ouvrage voit sa villa. L'architecte consulte un projet. Chacun voit exactement ce qu'il doit voir · ni plus, ni moins.
Quand chacun voit tout, personne ne voit rien correctement. Le maître d'ouvrage lit des échanges internes. Le chef de chantier voit les marges. L'architecte tombe sur des noms de clients. Les rôles ne sont pas un sujet d'admin · ils sont une question de relation client.
BuildFlow connaît quatre rôles. Chacun a un périmètre clairement défini · appliqué techniquement, pas seulement masqué visuellement.
L'entrepreneur. Le plus souvent gérant ou Project Manager. Gère toute l'entreprise.
Équipe sur le terrain, conduite de chantier, assistance projet. Travaille pour l'entreprise de construction.
Le client. La famille Weber d'Ettelbruck. L'architecte d'une résidence à Esch.
Architecte, ingénieur, sous-traitant. Observateur externe pour un seul projet.
BuildFlow n'utilise volontairement aucun magic-link. Chaque membre d'équipe définit un vrai mot de passe · parce que le compte est réutilisé et que les appareils de travail sont partagés.
Les maîtres d'ouvrage sont l'exception : ils n'ont pas besoin de compte. Ils ouvrent un lien et voient immédiatement l'état de leur villa.
Saisir l'e-mail et le nom. Pour les membres d'équipe : sélectionner les projets. Pour les invités : sélectionner un seul projet. L'invitation est générée côté serveur · pas dans le navigateur.
Un lien signé, valable sept jours. Le lien pointe vers app.buildflow.lu/register avec l'e-mail pré-rempli. La personne invitée définit un mot de passe et est immédiatement opérationnelle.
Une Edge Function vérifie le jeton, vérifie l'e-mail, active l'adhésion sur les projets exactement attribués. Aucun code côté client ne peut contourner cette étape.
Chaque requête à la base de données vérifie le rôle et l'attribution du projet. Il n'y a pas de mode « caché » qui masque les données · la base de données ne renvoie tout simplement rien d'autre.
Row-Level-Security au niveau de la base de données. Un admin de l'entreprise A ne peut techniquement pas interroger les projets de l'entreprise B · même s'il connaît l'ID interne du projet.
L'attribution est gérée via le champ project_ids. Une ligne de projet non attribuée n'apparaît dans aucune requête · ni via l'interface, ni via l'API.
Calculs, notes internes, facturations sont dans des tables séparées avec leur propre RLS. Un jeton client ne peut techniquement pas lire ces tables, même via une autre route.
Qui a invité qui et quand, quand l'invitation a été activée, quand elle a été retirée · tout dans une table d'audit séparée. Pour vous comme pour l'avocat.
Configurez votre équipe en dix minutes. Le premier admin, c'est vous. Vous invitez le reste en quelques clics.
