03 · Équipe & rôles

Quatre rôles. Un projet.

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.

AdminTous les projets
  • 12 projets actifs
  • 4 collaborateurs
  • 8 maîtres d'ouvrage
ÉquipeAssignés
  • Villa Kirchberg
  • Résidence Cessange
  • 3 tâches ouvertes
Maître d'ouvrageVotre villa
  • Villa Kirchberg
  • Gros œuvre · 62%
  • 2 nouvelles photos
InvitéUn projet
  • Villa Kirchberg
  • Documents (3)
  • Avancement : 62%

La surexposition détruit la confiance.

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.

Un maître d'ouvrage ouvre le portail et voit par accident qu'une autre villa était 40 000 € plus chère.
Un chef de chantier obtient l'accès à des onglets destinés à la direction.
Un architecte externe voit des noms de clients d'autres projets pour lesquels il n'a pas été mandaté.
Un sous-traitant reçoit un accès entreprise et voit soudain tout le pipeline.

Chaque rôle a son horizon.

BuildFlow connaît quatre rôles. Chacun a un périmètre clairement défini · appliqué techniquement, pas seulement masqué visuellement.

I

Admin

L'entrepreneur. Le plus souvent gérant ou Project Manager. Gère toute l'entreprise.

Voit
  • Tous les projets de l'entreprise
  • Tous les membres d'équipe
  • Tous les maîtres d'ouvrage et invités
  • Facturation, formule, factures
Ne voit pas
  • Projets d'autres entreprises
  • Contenus d'autres comptes BuildFlow
Invitation
II

Membre d'équipe

Équipe sur le terrain, conduite de chantier, assistance projet. Travaille pour l'entreprise de construction.

Voit
  • Uniquement les projets auxquels il est rattaché
  • Mises à jour et jalons de ces projets
  • Tâches et documents
  • Notes internes
Ne voit pas
  • Projets auxquels il n'est pas rattaché
  • Facturation et paramètres de la formule
  • Inviter d'autres membres d'équipe
Invitation
III

Maître d'ouvrage

Le client. La famille Weber d'Ettelbruck. L'architecte d'une résidence à Esch.

Voit
  • Exclusivement son propre projet
  • Avancement, photos, textes de mise à jour
  • Messages adressés à l'entrepreneur
  • Documents qui lui ont été partagés
Ne voit pas
  • Autres projets de l'entreprise
  • Notes internes ou tâches
  • Facturation, calculs, marges
Invitation
IV

Invité

Architecte, ingénieur, sous-traitant. Observateur externe pour un seul projet.

Voit
  • Un seul projet pour lequel il a été autorisé
  • Avancement et documents pertinents
  • Communication dans laquelle il est impliqué
Ne voit pas
  • Autres projets de l'entreprise
  • Finances internes ou facturation
  • Membres d'équipe qui ne travaillent pas sur le projet
Invitation

Inviter en trois étapes.

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.

I

L'admin clique sur « Inviter »

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.

II

L'invité reçoit un e-mail

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.

III

L'adhésion est activée côté serveur

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.

Les rôles sont appliqués techniquement.

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.

Company-isolation

Chaque entreprise ne voit que ses propres données

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.

Project-isolation

Les membres d'équipe ne voient que les projets attribués

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.

Role-isolation

Maîtres d'ouvrage et invités ne voient jamais les données admin

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.

Audit-trail

Chaque invitation est traçable

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.

Quatre rôles, zéro chaos.

Configurez votre équipe en dix minutes. Le premier admin, c'est vous. Vous invitez le reste en quelques clics.