La plupart des apps Bubble en production ont un problème de sécurité qu'aucun test fonctionnel ne détecte : masquer un bouton "Admin" pour les non-admins ne bloque pas un utilisateur qui appelle directement l'API Bubble. La visibilité conditionnelle n'est que du CSS côté navigateur. Les privacy rules, elles, bloquent côté serveur avant que les données partent. Cette distinction est le premier réflexe à avoir en configurant l'authentification d'une app Bubble.
Le type User natif : ce que Bubble prend en charge
Bubble crée automatiquement un type de données "User" dans chaque application. Ce n'est pas un type ordinaire : il bénéficie d'une gestion sécurisée des identifiants. Les mots de passe sont convertis en hash à sens unique avec salage avant stockage - même un développeur avec un accès direct à la base Bubble ne peut pas retrouver le mot de passe original d'un utilisateur. C'est documenté dans la documentation officielle Bubble sur les comptes utilisateurs.
Le type User contient trois champs natifs : l'email (identifiant unique par app), le mot de passe (hashed, jamais accessible en clair), et un booléen "Email confirmed". Les sessions sont gérées automatiquement selon trois règles :
- Utilisateurs temporaires non inscrits : session de 72 heures
- Utilisateurs inscrits sans "Rester connecté" : session de 24 heures
- Utilisateurs inscrits avec "Rester connecté" activé : session de 12 mois
En dehors de ces champs natifs, vous pouvez ajouter autant de champs personnalisés que nécessaire au type User - y compris le champ "Rôle" qui va structurer l'ensemble du contrôle d'accès.
Un cas d'usage utile documenté dans Bubble : les utilisateurs temporaires reçoivent un cookie de session dès leur première visite. Quand ils s'inscrivent ensuite, les données de leur session temporaire (panier, préférences) sont transférées automatiquement vers leur compte permanent.
Créer des rôles avec les Option Sets
La première erreur est de stocker les rôles comme du texte libre : un champ "Rôle" de type text où on stocke "admin", "Admin" ou "ADMIN" selon l'humeur. Les comparaisons deviennent fragiles et une faute de frappe dans un workflow crée silencieusement un trou dans les permissions.
La bonne approche est un Option Set. Dans Bubble, allez dans Data > Option Sets et créez un Option Set nommé "Rôle". Ajoutez vos options - par exemple "Administrateur", "Éditeur", "Lecteur". Retournez ensuite dans Data > Data Types > User et ajoutez un champ "Rôle" de type "Rôle" (votre Option Set).
L'avantage des Option Sets : les valeurs sont prédéfinies et sélectionnées via un menu déroulant dans l'éditeur. Impossible de créer une valeur incorrecte par erreur. Les comparaisons dans les workflows et les privacy rules utilisent des opérateurs stricts ("is", "is not") sans risque de casse ni de troncature.
Pour assigner un rôle lors de l'inscription, ajoutez dans le workflow "Sign the user up" une action "Make changes to current user" qui fixe le champ Rôle à la valeur par défaut (ex : "Lecteur"). Les admins peuvent ensuite être promus depuis votre backoffice interne via la même action.
Si vous avez besoin de multi-rôles, le champ devient une "list of Rôle" : un utilisateur peut avoir [Éditeur, Reviewer] simultanément. Les conditions dans les privacy rules s'adaptent : "Current User's Rôles contains Administrateur" au lieu de "Current User's Rôle is Administrateur".
Privacy Rules : le verrou côté serveur
Bubble évalue les privacy rules avant de renvoyer les données depuis la base. Peu importe ce qui se passe dans l'interface, si une privacy rule interdit, les données ne partent pas vers le navigateur. C'est la différence fondamentale avec la visibilité conditionnelle, qui n'est que du rendu CSS local.
Pour configurer les privacy rules, allez dans Data > Privacy. Chaque type de données a ses propres règles. Par défaut, Bubble applique des règles restrictives, mais il faut créer des règles explicites pour les accès cross-utilisateurs.
Exemple pour une app où les admins voient toutes les commandes :
- Créez une règle sur le type "Order" avec la condition "Current User's Rôle is Administrateur"
- Cochez "Find this in searches" et "View all fields" pour cette règle
- Ajoutez une deuxième règle "Creator" pour que chaque utilisateur voie uniquement ses propres commandes
Les privacy rules supportent des conditions imbriquées : vous pouvez combiner rôle, statut de connexion, appartenance à un groupe, ou des valeurs dynamiques. Pour des architectures avec logique backend séparée, voir comment Bubble et Xano se combinent pour isoler les règles métier du frontend.
Visibilité conditionnelle selon le rôle
Une fois les privacy rules en place, la visibilité conditionnelle complète l'expérience utilisateur côté interface. Sélectionnez un élément dans l'éditeur Bubble, allez dans l'onglet "Conditional" et ajoutez :
Condition : "Current User's Rôle is not Administrateur"
Action : "This element is visible" = No
Ce pattern s'applique à n'importe quel élément : boutons, groupes, icônes de suppression. Pour restreindre une page entière, ajoutez un workflow "Page is loaded" avec une condition sur le rôle et l'action "Go to page" qui redirige vers votre page d'accueil publique. Bubble évalue ce workflow à chaque chargement de page.
Pour aller plus loin sur la structure d'une app Bubble depuis le départ, l'article sur le guide complet Bubble couvre les décisions d'architecture fondamentales. Et pour les implications budgétaires selon les plans, voir le détail des coûts d'une application Bubble.
OAuth : les 9 plugins officiels
Bubble fournit 9 plugins d'authentification OAuth officiels maintenus par l'équipe Bubble : Facebook, Google, Instagram, LinkedIn, Pinterest, Slack, Wistia, YouTube et Fitbit. Ces plugins restent compatibles après les mises à jour Bubble et leur communication avec les providers tiers est chiffrée et routée via les serveurs Bubble. La liste complète avec la documentation de chaque provider est disponible dans les docs officielles.
Le flux OAuth fonctionne en trois étapes : redirection vers la page de connexion du provider, génération d'un token d'accès après confirmation, récupération des informations du compte (email, nom, photo de profil). Tout passe par les serveurs Bubble, pas directement depuis le navigateur de l'utilisateur.
Un point à anticiper : si un utilisateur sans compte passe par le flux OAuth, Bubble crée automatiquement un nouveau compte. Pour permettre à un utilisateur existant de lier son compte Google à son compte email/mot de passe, c'est un workflow de fusion de comptes à concevoir explicitement - Bubble ne le gère pas nativement.
Au-delà de l'authentification, certains plugins ajoutent des actions supplémentaires : le plugin Slack permet par exemple d'envoyer des messages de bot depuis un workflow Bubble. C'est le même plugin qui gère connexion Slack et notifications Slack dans votre app.
2FA et plans Bubble : ce qui est disponible à quel niveau
La 2FA native pour les utilisateurs finaux de votre app - confirmation par QR code avec Google Authenticator ou Authy - est une fonctionnalité disponible sur les plans avancés de Bubble. La documentation des paramètres applicatifs Bubble détaille la configuration et les prérequis de plan exacts. Pour la facturation : le plan Starter démarre à 29 $ par mois en facturation annuelle (web uniquement), le plan Growth à 119 $ par mois, le plan Team à 349 $ par mois, selon la grille tarifaire officielle Bubble.
L'environnement de développement inclut 100 000 workload units mensuels sur tous les plans payants. En production, l'allocation augmente selon le plan choisi.
Pour les apps qui gèrent des comptes administrateurs ou des données sensibles, vérifier que la 2FA est bien activée sur les comptes à forts privilèges. Un admin sans second facteur dont le compte est compromis peut accéder à la totalité des données via les privacy rules configurées pour son rôle.
Les magic login links - un lien de connexion envoyé par email, sans mot de passe - sont disponibles sur tous les plans. C'est une alternative adaptée pour les apps à large audience où la friction à la connexion est un problème, sans imposer un second facteur systématique.
3 erreurs classiques
Confondre visibilité et sécurité. Masquer un bouton ne bloque pas l'API. Un utilisateur qui connaît l'endpoint API Bubble peut contourner toute l'interface. Toujours valider les accès via les privacy rules, pas uniquement dans les conditions de workflow ou la visibilité d'élément.
Rôles en texte libre. "admin", "Admin" et "ADMIN" sont trois valeurs distinctes pour Bubble. Une faute de frappe dans un workflow ou une action "Make changes" manuelle crée silencieusement un trou dans les permissions. Utilisez systématiquement les Option Sets.
Pas de protection sur les API endpoints exposés. Si vous activez l'API Bubble (Settings > API) pour une intégration tierce, vérifiez que les privacy rules couvrent bien les données exposées. L'API Bubble respecte les privacy rules - mais un endpoint "public" sans règle restrictive expose vos données à n'importe qui avec l'URL de votre app.
Pour les projets avec authentification complexe dès le départ, l'article sur la méthode MVP Bubble en 2 semaines aborde comment dimensionner la structure de données initiale pour ne pas tout refactorer à la première montée en charge.
Questions fréquentes
Comment gérer la suppression d'un compte en respectant le RGPD ?
Supprimer un compte utilisateur dans Bubble ne supprime pas automatiquement les données liées (commandes, commentaires, fichiers). Il faut créer un workflow explicite qui supprime toutes les données associées avant de supprimer le compte. Ce flux de droit à l'effacement doit être opérationnel dès le lancement si vous traitez des données de résidents européens.
Est-il possible de déléguer la gestion des rôles sans accès à l'éditeur Bubble ?
Oui. Créez une page "Admin" dans votre app avec une liste d'utilisateurs et un sélecteur de rôle (dropdown lié à votre Option Set). Les actions de modification du champ Rôle restent dans vos workflows Bubble, l'admin utilise simplement l'interface que vous avez construite. Protégez cette page avec la privacy rule et la redirection conditionnelle.
Comment tester les privacy rules sans deployer en production ?
Bubble permet de créer plusieurs comptes test directement dans l'éditeur en mode Development. Créez un compte "test-admin" et un compte "test-lecteur", assignez les rôles correspondants, et naviguez dans votre app en étant connecté avec chacun. Les privacy rules s'appliquent identiquement en mode Dev et en production - ce que vous voyez en Dev est ce que vos utilisateurs verront.
Les plugins OAuth tiers sont-ils fiables ?
Les 9 plugins officiels Bubble sont maintenus par l'équipe Bubble et mis à jour à chaque changement d'API des providers. Les plugins tiers (Apple Sign-In, Microsoft, etc.) dépendent de mainteneurs externes. Avant d'utiliser un plugin tiers pour l'authentification, vérifiez la date de dernière mise à jour dans le Bubble Plugin Store et la compatibilité déclarée avec la version Bubble actuelle.
