Socle Laravel et Filament
Application multi-rôles, panneaux d’administration, permissions, espaces distincts et logique multi-tenant single database.
Plateforme marketplace de services avec espaces multi-rôles
Cette fiche présente une marketplace de services où la vente déclenche un projet suivi. L’enjeu n’était pas seulement le paiement, mais ce qui se passe ensuite entre utilisateur, créateur et administration.
Fiche anonymisée : le nom du produit, les captures et certains détails commerciaux ne sont pas publiés.
Comment cadrer ce qui se passe après l’achat dans une marketplace de services ?
Fiche anonymisée
- SaaS marketplace
- Services créatifs
- 2024 - 2025
- Laravel, Filament
Organiser une marketplace de services autour du suivi de projet
SaaS marketplace Laravel et Filament pour une activité de services, conçu pour cadrer les projets, les échanges, les rôles, les litiges et la facturation après l’achat.
Dans une marketplace de services, la relation ne s’arrête pas au checkout. La plateforme devait garder la trace de ce qui est demandé, produit, corrigé, discuté ou arbitré.
Le risque : mélanger vente, production et arbitrage
Sans cadre clair après l’achat, les échanges sortent de la plateforme, les versions deviennent difficiles à suivre et les désaccords reposent sur des informations dispersées. Le produit devait donc structurer ces moments dès le départ.
- Distinguer les responsabilités de chaque rôle.
- Faire du projet client l’objet central après l’achat.
- Garder les échanges, versions et litiges dans le produit.
- Prévoir une facturation cadrée, à valider avec les conseils du projet.
Les choix structurants
Les choix structurants du projet, présentés à partir de leur impact sur le produit et son exploitation.
- 01
Séparer les responsabilités
L’administrateur valide et arbitre. Le créateur vend et produit. L’utilisateur achète, suit le projet et échange dans un espace défini.
- 02
Modéliser le projet comme objet central
Le projet rassemble la commande, les contenus, les versions, les messages, les statuts et les décisions importantes.
- 03
Encadrer les prix sans retirer l’autonomie
Les créateurs peuvent définir leurs prix autour d’un prix suggéré, avec des domaines d’action et des limites configurables.
- 04
Prévoir les situations non idéales
Litiges, arbitrage, désaccords, versions successives et limites de révision font partie du modèle, au lieu d’être traités comme des exceptions hors plateforme.
Les parties développées
Les livrables ont été organisés autour d’un fil commun : donner un cadre exploitable à la prestation après son achat.
Marketplace de services
Profils créateurs, validation administrative, domaines d’action, projets, prix suggérés et parcours d’achat.
Suivi et collaboration
Chat, statuts, versions de contenus, limite configurable de versions et échanges rattachés au projet.
Administration et facturation
Arbitrage, supervision des projets, gestion des différends et module de facture pensé pour les contraintes locales.
Cadrer l’après-achat
Définir ce qui se passe après le paiement
Le projet concernait une plateforme SaaS marketplace de services. La difficulté n’était pas seulement de vendre une prestation, mais d’organiser ce qui se passe ensuite : échanges, validation, livrables, désaccords possibles et décisions administratives.
Ce que cela change dans le modèle applicatif
La valeur de cette réalisation se situe dans les limites données à chaque action. Acheter, produire, corriger, arbitrer ou facturer ne relèvent pas du même rôle.
Cette distinction rend la plateforme plus lisible pour les personnes qui l’utilisent au quotidien, surtout lorsque le projet ne suit pas un parcours idéal.
Séparer les rôles pour éviter les confusions
La plateforme reposait sur trois profils principaux : administrateur, créateur et utilisateur.
L’administrateur valide les créateurs, supervise les projets et intervient lorsque la situation demande un arbitrage. Le créateur configure son offre, vend ses services et produit les livrables. L’utilisateur achète, transmet les informations nécessaires et suit l’avancement du projet.
Les droits ne sont pas un simple détail technique
Quand plusieurs profils travaillent dans la même application, l’interface reflète les responsabilités de chacun. Il ne suffit pas de cacher quelques boutons.
Les vues, les actions, les statuts et les notifications restent cohérents avec le rôle connecté. Cette séparation rend l’application plus lisible et réduit les confusions dans les situations sensibles.
Faire du projet client le fil conducteur
Dans une marketplace de services, la transaction n’est que le point de départ. Après l’achat, il faut suivre un projet : demande initiale, échanges, versions, validations, corrections éventuelles et décision finale.
Le projet a donc été modélisé comme l’élément central. Il rassemble les informations nécessaires à la prestation, les messages, les contenus produits, les versions et les états de suivi.
Le versioning donne un cadre aux livrables
Les contenus liés aux projets pouvaient évoluer par versions. Une limite configurable permettait d’encadrer ce qui pouvait être livré, modifié ou demandé à nouveau.
Ce type de règle est important dans une plateforme de services : il évite que les échanges restent flous et donne à chacun une lecture plus nette de ce qui est inclus.
Donner de l’autonomie aux créateurs sans perdre le cadre
Les créateurs pouvaient vendre leurs services dans l’application, avec une autonomie compatible avec les règles de la plateforme.
Le modèle prévoyait des domaines d’action, des prix suggérés et la possibilité de définir ses propres prix autour de cette base. Cela donne de la souplesse aux créateurs sans retirer à l’administration sa capacité de cadrage.
La validation protège la qualité du réseau
L’administration intervenait dans la validation des créateurs. Ce point dépasse le workflow interne : il conditionne la confiance dans la marketplace.
Un créateur validé peut ensuite opérer dans son espace, vendre ses prestations et suivre ses projets avec les outils prévus.
Garder les échanges dans le contexte du projet
La messagerie sert à garder les échanges dans le contexte du projet. Elle permet de retrouver les demandes, les précisions, les décisions et les points de désaccord sans sortir de la plateforme.
Ce rattachement est particulièrement important lorsqu’un litige apparaît. Les messages deviennent alors une partie du contexte d’arbitrage.
La collaboration prévoit aussi le désaccord
Un parcours idéal ne suffit pas à construire une application solide. Il faut prévoir les questions, les retards, les incompréhensions et les différends.
La gestion des litiges et l’arbitrage ont donc été intégrés au produit, avec des états et des actions dédiés, plutôt que d’être renvoyés à des échanges extérieurs.
Traiter la facturation comme un sujet produit
La marketplace demandait une facturation pensée selon ses contraintes locales. Ce sujet ne pouvait pas être traité comme une simple génération de PDF.
Les rôles, les paiements, les commissions éventuelles, les vendeurs, les acheteurs et les obligations locales influencent la manière de structurer les factures.
Un point à traiter avec prudence
La conformité d’un système de facturation dépend du contexte légal, fiscal et opérationnel du projet. Le développement prévoit donc les bons objets, les bonnes traces et les bons états, tout en laissant les validations réglementaires aux conseils compétents.
Dans cette fiche, aucune promesse de conformité n’est inventée. Le point important est que la facturation a été traitée comme un sujet de produit à part entière.
Une marketplace cadrée après l’achat
Son intérêt se joue dans les moments moins visibles : une information à retrouver, une version à comparer, une décision à justifier, une facture à produire ou un différend à traiter. Ce sont ces moments qui font la différence entre un tunnel de vente et une application métier.
Les points structurants
La marketplace tient surtout par ce qu’elle rend lisible après le paiement : responsabilités, échanges, versions, décisions et facturation.
- Une marketplace de services traite l’après-achat aussi sérieusement que le paiement.
- Des rôles clairs évitent de mélanger production, validation et arbitrage.
- Le versioning et les limites configurables rendent les livrables plus faciles à suivre.
- La facturation se cadre avec les contraintes légales du projet, sans improvisation.
Vous avez un sujet proche ?
Nous pouvons cadrer une plateforme SaaS lorsque votre service implique plusieurs rôles, des paiements, des projets suivis et des règles d’administration précises.