Au départ, il n’y a pas un produit, il y a un besoin très concret : mon BDE, à l’IUT MMI Montaigne, avait besoin d’une app pour sa campagne. Feed, boutique, calendrier, carte de membre. Je l’ai codée, publiée sur l’App Store, et elle a marché. C’est en la regardant tourner que la vraie idée est arrivée : ce n’était pas l’app « de mon BDE » qui avait de la valeur, c’était le fait que tous les BDE ont exactement le même manque.
D’abord, une app pour un seul BDE
Le premier objectif était simple : une app que les étudiants peuvent télécharger, utiliser, et qui rende la campagne tangible avant même le vote. Flutter + Dart pour iOS et Android avec un seul codebase, parce que je n’avais pas le temps de doubler le travail en deux stacks natives pour une deadline de campagne. UI déclarative, hot reload pour itérer vite, et une chaîne de build jusqu’au store.
Côté backend, j’ai posé Firebase : Authentication pour les comptes, Firestore pour le temps réel (feed, likes, événements), Storage pour les médias. Ça a parfaitement fait le job, pour un BDE. C’est exactement là qu’était la limite que je ne voyais pas encore.
Le déclic : tous les BDE ont le même manque
La plupart des BDE n’ont pas d’app, ou une app bricolée qui ne tient pas la saison. Refaire ce travail à la main, association par association, n’avait aucun sens : je réécrirais cinquante fois la même chose. La vraie question est devenue celle d’un produit, pas d’un projet : comment livrer cette app à n’importe quel BDE, à sa marque, sans tout réécrire ?
C’est ce changement de question qui m’a fait passer de « je code une app » à « je conçois un produit ». Et un produit pour plusieurs clients, ça change l’architecture en profondeur.
Du mono-BDE au multi-tenant : changer de fondations
Une app pensée pour un seul client mélange tout dans la même base. Pour servir N associations depuis un seul codebase, il faut isoler chaque BDE : c’est le multi-tenant. J’ai fait évoluer le socle vers Supabase (Postgres), où chaque association est un « tenant » identifié par une colonne tenant_id présente sur chaque table de données.
Le point non négociable, c’est l’isolation : aucun BDE ne doit jamais voir les données d’un autre. Sur du multi-tenant, une fuite entre clients n’est pas un bug, c’est une faute. L’isolation est donc verrouillée côté base de données, pas seulement côté application, avec le Row Level Security de Postgres et un trigger qui force le tenant_id, pour qu’une requête mal écrite côté client ne puisse pas contourner la cloison.
-- Chaque table de données porte un tenant_id, et RLS le verrouille.
alter table posts enable row level security;
create policy "isolation_par_tenant" on posts
using (tenant_id = current_tenant_id());
-- Une requête d'un BDE ne renverra JAMAIS les lignes d'un autre.White-label : une base de code, N marques
Côté interface, « white-label » veut dire que chaque BDE retrouve l’app à ses couleurs, son logo, son identité, sans qu’on touche au code. Le thème (palette, logo, libellés) est une donnée du tenant, pas une constante dans le code. Un nouveau BDE, ce n’est plus un nouveau projet : c’est une nouvelle instance configurée.
Le site bdeasy.fr présente le produit et embarque une démo Flutter cliquable directement dans le navigateur, pour montrer l’app sans forcer l’installation. Le binaire iOS/Android reste la cible principale ; le web sert de vitrine.
L’App Store, toujours le plus long
Le code des features, je l’ai bouclé dans des fenêtres courtes. Ce qui prend proportionnellement le plus de temps, c’est Apple : compte développeur, certificats, profils de provisioning, conformité aux guidelines, métadonnées, captures aux bonnes tailles, politique de confidentialité, et la boucle des rejets avec des messages parfois cryptiques. Chaque rejet est une mini-formation. La leçon : prévoir systématiquement du buffer « store » dans l’estimation.
“Le déclic : arrêter de livrer un projet, commencer à livrer un produit. La même app, déclinable à l’infini, chaque BDE chez lui. C’est exactement ça, le white-label.”
Et maintenant : la refonte
BDEASY tourne déjà (App Store + démo en ligne), mais en grandissant le produit a accumulé des écrans pensés au coup par coup. J’ai donc lancé une refonte complète, pilotée sur Figma : design system propre, parcours utilisateur repensés écran par écran, contenu et performance retravaillés, et une exigence d’accessibilité dès la maquette plutôt qu’en rattrapage. L’objectif : passer d’une app « qui marche » à un produit pensé de bout en bout.
Ce que ce projet m’a appris dépasse Flutter ou Supabase : concevoir pour plusieurs clients, c’est raisonner déploiement, isolation des données et image de marque par client, pas juste « faire un écran ». C’est le projet qui m’a fait basculer du dev au produit.
“Une app pour mon BDE, c’était un projet. La même app déployable par n’importe quel BDE, à sa marque, sans réécrire le code : c’est devenu un produit.”