BDEASY
Mon app de BDE devenue un produit white-label, vendu et déployé aux couleurs de chaque association
App StoreEssaie-le
Le build white-label en ligne sur bdeasy.fr. Clique, navigue, tout répond.
Démarrage de l’app…
Le contexte
J'ai d'abord codé une app pour mon propre BDE, à l'IUT MMI : feed, boutique, calendrier, carte de membre. Elle a été le produit phare de notre campagne, et elle a marché. Puis j'ai réalisé que tous les BDE ont le même manque : pas d'app du tout, ou une app bricolée qui meurt à la passation. Refaire ce travail à la main pour chaque association n'avait aucun sens. La vraie question est devenue : comment livrer cette app à n'importe quel BDE, à sa marque, sans tout réécrire ?
Mon approche
J'ai transformé l'app en template white-label. Une seule base de code Flutter, une architecture multi-tenant sur Supabase : chaque BDE est un tenant isolé, avec ses couleurs, son logo et ses données, sans qu'aucun ne puisse voir celles d'un autre. L'isolation est verrouillée côté base (RLS et colonne tenant_id), parce que sur du multi-tenant, une fuite entre clients n'est pas une option. Ensuite, je suis allé vendre : site vitrine avec la démo jouable dans le navigateur, démarchage des BDE, devis, et déploiement de leur instance.
Ce que j'en retire
Des BDE ont acheté leur app, à Toulouse comme en école d'ingénieurs. Chacun a la sienne, à ses couleurs, avec ses données. C'est le projet qui m'a fait passer de « je code une app » à « je vends un produit » : cadrer un besoin, chiffrer, livrer, assurer le suivi. Le code n'est que la moitié du travail, et je ne l'aurais jamais compris sans me confronter à de vrais clients.
Les écrans
À quoi ça ressemble
Le feed : posts, sondages et événements du BDE
Sous le capot
Comment c'est construit
Multi-tenant plutôt que N copies
Une seule base de code sert toutes les associations. Chaque BDE est un tenant : ses couleurs, son logo, ses modules et ses données. Livrer un nouveau client, c'est provisionner une instance, pas dupliquer un projet à maintenir en double.
L'isolation verrouillée côté base
Chaque table porte une colonne de tenant, les règles de sécurité Postgres filtrent les lignes, et un déclencheur refuse toute écriture qui sortirait du tenant. Une fuite de données entre deux BDE n'est pas un bug acceptable : la garantie ne peut pas reposer sur le code de l'app.
Configurable sans redéployer
Couleurs, logo, modules activés et contenus se règlent en base. Un BDE change son thème sans que je republie quoi que ce soit sur les stores.
Le paiement et les points, côté serveur
Tout ce qui touche à l'argent et aux points de fidélité est calculé sur le serveur. Un utilisateur qui bidouille l'app ne peut pas se créditer lui-même.
Application
Back-end
Services