Prestataire (Provider)
En une phrase : l'entreprise partenaire chez qui l'on réserve — le restaurant, le musée, le loueur de kayaks — détentrice des coordonnées, de la localisation et de la relation commerciale.
Rôle métier
Le prestataire est l'identité de l'entreprise, à distinguer soigneusement de ce qu'elle vend : l'ancienne base du client confondait l'entreprise et l'expérience dans un même enregistrement ; le nouveau modèle les sépare — un prestataire propose plusieurs activités.
Le prestataire concentre :
- l'identité publique : nom, site, coordonnées de réservation, adresse et position géographique (la recherche des planificateurs de tours est géolocalisée : « les prestataires autour de tel point ») ;
- le positionnement commercial :
standing(standard/premium) ; - la mémoire interne : notes d'équipe (jamais montrées aux voyageurs), lien CRM HubSpot, identifiants de l'ancienne base (imports idempotents et reconstruction future des liens, ex. destinations).
Cycle de vie
draft → approved → archived, doublé d'une provenance (origin) qui dit comment le prestataire est entré dans le catalogue :
imported— repris de l'ancien système ;signed_up— auto-inscription via le formulaire public ;on_the_fly— créé à la volée par l'équipe pendant la planification d'un tour.
Seul un prestataire approved est visible hors de l'équipe : les planificateurs côté organisation et les voyageurs ne voient que le catalogue approuvé (une fiche non approuvée répond « n'existe pas », pas « interdit »). L'approbation et l'archivage sont des actes d'équipe explicites, jamais un effet de bord.
Le visage public
L'identité, le contact et la localisation du prestataire — la constante Provider::PUBLIC_ATTRIBUTES — forment son visage public : c'est ce qu'une activité présente au voyageur (effective_provider) et ce qu'un prestataire déclare sur lui-même à l'auto-inscription. Le cycle de vie, le standing et la mémoire interne n'en font jamais partie.
Historique : une activité pouvait autrefois surcharger ce visage via une « ligne fantôme » (
type = override) de la même table. Le mécanisme a été retiré — voir l'historique dans Base de données ; un besoin réel de divergence par activité se traite par colonne nullable ciblée suractivities(cf.contact_*).
Relations métier
| Relation | Sens métier |
|---|---|
| ← Activités | Les expériences que l'entreprise vend ; elles disparaissent avec elle |
| ← Étapes de tours (indirect, via les activités) | La présence du prestataire dans les road-trips vendus |
| ← Journal d'audit | Toute modification de la fiche est tracée |
La liaison aux images (photos du prestataire) est prévue mais pas encore construite.
Règles métier
- Visibilité par approbation :
approvedest la frontière entre le back-office et le public. - La recherche publique porte sur le nom et la ville uniquement — jamais sur les notes internes ni les clés CRM/héritage, qui sont aussi retirées des réponses hors super-admin.
Détail technique (contraintes de forme, recherche plein texte, PostGIS) : Base de données — prestataires & activités.