--- title: "Tester votre Custom Code GoodBarber avec un membre connecté" description: "Vous voulez que votre Custom Code GoodBarber se comporte différemment pour un utilisateur connecté — afficher du contenu premium, accueillir un membre par son n" canonical_url: "https://fr.goodbarber.com/blog/tester-votre-custom-code-goodbarber-avec-un-membre-connecte-a1389/" lang: fr date: 2026-06-26 last_updated: 2026-07-17 --- # Tester votre Custom Code GoodBarber avec un membre connecté [Retour](/blog/reussir-mon-app-r13/) # Tester votre Custom Code GoodBarber avec un membre connecté Ecrit par [Mathieu Poli](https://fr.goodbarber.com/blog/author/mathieu-poli/) le Vendredi 26 Juin 2026 ## Vous voulez que votre Custom Code GoodBarber se comporte différemment pour un utilisateur connecté — afficher du contenu premium, accueillir un membre par son nom, masquer une section aux visiteurs anonymes ? Que vous ayez écrit ce code vous-même ou que vous l'ayez généré avec l'AI Extension Builder, il demande à l'App API qui est connecté via gb.user.getCurrent(). Mais la preview du back-office n'a pas de véritable connexion : pour les apps Membership, cet appel tombe donc toujours dans le cas d'erreur. Ce guide explique comment se comporte l'utilisateur courant dans la preview pour chaque type d'app, et vous donne une méthode prête à copier-coller pour tester en tant que membre connecté. ![](https://cmsphoto.ww-cdn.com/superstatic/40142/art/grande/97133647-67674216.jpg?v=1782463727.2083821) Beaucoup de Custom Code a besoin de savoir **qui utilise l'app à l'instant T** : afficher du contenu premium, accueillir les membres par leur nom, masquer une section aux visiteurs anonymes, adapter un tunnel de commande. L'App API de GoodBarber vous donne accès à l'utilisateur courant via `gb.user.getCurrent()`. Et le Custom Code n'est plus seulement quelque chose que vous écrivez à la main. Avec l'**[AI Extension Builder](https://fr.goodbarber.com/blog/ai-extension-builder-creer-des-sections-avec-l-ia-sans-coder-a1338/)** de GoodBarber, vous décrivez en langage naturel la section que vous voulez et l'assistant génère l'extension à votre place — du code qui se branche directement sur la même App API de GoodBarber. Écrit à la main ou généré par l'IA, il appelle `gb.user.getCurrent()` de la même manière, et vous le testez de la même manière. Ce guide s'applique donc, que vous ayez tapé le code ou que vous l'ayez obtenu via un prompt. Mais voici l'écueil que tout développeur finit par rencontrer : **dans la preview du back-office, il n'y a aucun utilisateur connecté.** La preview n'est qu'un rendu de votre app — pas d'écran de connexion, pas de session, rien sur quoi s'authentifier. Pour la plupart des types d'apps, GoodBarber contourne discrètement le problème à votre place, si bien que tester « en tant qu'utilisateur connecté » fonctionne tout seul. Pour l'extension **[Membership](https://fr.goodbarber.com/blog/le-systeme-d-abonnements-est-la-a1078/)**, ce n'est pas le cas — et c'est voulu. Cet article passe en revue le comportement de l'utilisateur courant dans la preview pour chaque type d'app, et vous donne une méthode simple, prête à copier-coller, pour tester le cas le plus délicat : un **membre** connecté. ## Petit rappel : gb.user.getCurrent() L'App API de GoodBarber permet à votre Custom Code de demander « qui utilise l'app à l'instant T ? » via une seule méthode : gb.user.getCurrent( (user) => { // Un utilisateur est connecté. // `user` est un objet GBUser — lisez ses attributs ici. console.log(user.email); }, (error) => { // Aucun utilisateur n'est connecté. console.log(`Response status: ${error.code}`); console.log(`Response message: ${error.message}`); } ); Elle prend **deux callbacks** : un callback de succès (appelé avec un objet `GBUser` lorsque quelqu'un est connecté) et un callback d'erreur (appelé lorsque personne n'est connecté). Elle fonctionne par callbacks — elle ne renvoie **ni** valeur **ni** Promise. **L'objet *GBUser* change de forme selon le type d'app** Le modèle `GBUser` porte une propriété `api_version` qui indique de quel type d'app il provient : | `api_version` | Type d'app | | ------------- | --------------------------------------------- | | `1` | App de contenu **+ extension Authentication** | | `2` | App **eCommerce** | | `3` | App de contenu **+ extension Membership** | La liste des attributs dépend de cette version. Pour une app **Membership** (`api_version: 3`), un `GBUser` ressemble à ceci : { id: 123, api_version: 3, login: "member@example.com", email: "member@example.com", username: "John Doe", firstname: "John", lastname: "Doe", picture_url: "https://example.com/picture.jpg", access_levels: ["premium"] // 👈 le champ clé pour Membership } Le tableau `access_levels` est ce qui rend Membership particulier : il liste les niveaux d'accès que l'utilisateur possède actuellement. C'est presque toujours là-dessus que votre Custom Code se branche (« cet utilisateur a-t-il `premium` ? alors j'affiche le contenu bonus »). En pratique, votre code lit `access_levels` pour décider quoi afficher : gb.user.getCurrent( (user) => { if (user.access_levels.includes("premium")) { console.log("Le membre a premium — afficher le contenu premium"); } else { console.log("Connecté, mais pas de premium — afficher l'invitation à passer à l'offre supérieure"); } }, (error) => { console.log("Personne n'est connecté — afficher l'invitation à se connecter"); } ); Gardez ceci en tête — c'est précisément ce code que le mock ci-dessous va alimenter. ## Comment se comporte l'utilisateur courant dans la preview La preview du back-office est un bac à sable. Elle affiche votre app, mais elle n'a **aucun mécanisme de connexion** — il n'y a aucun moyen d'y authentifier réellement un vrai utilisateur. Pour que le développement reste confortable malgré tout, GoodBarber **injecte un faux utilisateur** pour certains types d'apps, afin que `getCurrent()` renvoie *quelque chose* d'exploitable : | Type d'app | Dans la preview, `getCurrent()`… | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | Add-on **Authentication** (`api_version: 1`) | ✅ Renvoie un **faux utilisateur** automatiquement — votre callback de succès se déclenche. | | App **eCommerce** (`api_version: 2`) | ✅ Renvoie un **faux client** automatiquement — votre callback de succès se déclenche. | | Extension **Membership** (`api_version: 3`) | ❌ Ne renvoie **rien** — votre callback d'**erreur** se déclenche avec `"There's no user logged in the app."` | Donc si votre app utilise **Authentication** ou **eCommerce**, vous pouvez tester votre logique « utilisateur connecté » dans la preview immédiatement — un faux utilisateur vous est fourni gratuitement, sans aucune configuration. Si votre app utilise l'extension **Membership**, c'est différent : **aucun faux utilisateur n'est injecté.** Si votre callback de succès ne se déclenche jamais dans la preview et que vous tombez systématiquement dans le cas d'erreur, c'est normal — il n'y a tout simplement aucun utilisateur courant à renvoyer, et contrairement aux deux autres types d'apps, aucun n'est simulé pour vous. Le reste de cet article se concentre sur ce cas Membership, car c'est celui qui demande un peu de travail. Vous avez deux façons de le gérer. ## Option 1 — Tester dans l'app MyGoodBarber (conditions réelles) La façon la plus fidèle de tester est de faire tourner votre app à l'intérieur de l'app **MyGoodBarber** (disponible sur iOS et Android). Elle charge votre vraie app, avec le vrai flux de connexion et le vrai backend. Vous vous connectez en tant que membre réel, et `getCurrent()` renvoie votre véritable `GBUser` avec vos véritables `access_levels`. Utilisez cette méthode quand vous voulez valider *l'ensemble* du flux de bout en bout avant de publier. C'est ce qui se rapproche le plus de la production. L'inconvénient : la boucle de feedback est plus lente. Vous ne pouvez pas itérer sur un ajustement CSS ou une condition aussi vite que dans la preview. C'est là qu'intervient l'option 2. ## Option 2 — Simuler getCurrent() dans la preview Pour itérer rapidement, vous pouvez **remplacer temporairement** `gb.user.getCurrent` par votre propre version qui renvoie un faux membre de votre choix. Votre vraie logique reste strictement identique — votre Custom Code continue d'appeler `gb.user.getCurrent(success, error)` comme d'habitude. Vous ne faites que substituer *ce que fait la méthode* pendant vos tests. **Étape 1 — Insérer le mock en haut de votre code** Ajoutez ce bloc tout au début du JavaScript de votre Custom Code, avant tout appel à `getCurrent()` : // ⚠️ TEST EN PREVIEW UNIQUEMENT — à retirer (ou passer à false) avant de publier ! const PREVIEW_TESTING = true; if (PREVIEW_TESTING && typeof gb !== "undefined" && gb.user) { gb.user.getCurrent = function (successCallback, errorCallback) { const fakeUser = { id: "123", api_version: 3, login: "member@example.com", email: "member@example.com", username: "Test Member", firstname: "Test", lastname: "Member", picture_url: "", access_levels: ["premium"] // 👈 modifiez ceci pour tester différents cas }; successCallback(fakeUser); }; } > 💡 `"premium"` n'est qu'un exemple. Utilisez les **identifiants de niveaux d'accès réellement configurés dans votre app** — sinon vos conditions ne correspondront à rien. Vous vous demandez peut-être : mon code ne pourrait-il pas simplement détecter la preview et n'appliquer le mock que là ? Malheureusement non — aucun signal fiable n'est exposé à votre Custom Code pour dire « ceci est la preview » (`gb.platform()` renvoie `"web"` dans la preview, exactement comme une vraie PWA en production), et du seul point de vue de `getCurrent`, la preview est indiscernable d'un utilisateur réellement déconnecté (les deux déclenchent le callback d'erreur). C'est pourquoi nous utilisons un flag que vous basculez **à la main** : c'est explicite, et cela ne peut pas être déclenché par accident en production. C'est tout. Désormais, partout dans votre Custom Code où vous appelez : gb.user.getCurrent(onUserFound, onNoUser); …votre callback `onUserFound` reçoit le faux membre ci-dessus — exactement comme si un vrai membre `premium` était connecté. **Vous ne changez rien à votre logique métier** ; vous avez seulement ajouté le bloc de mock par-dessus. **Étape 2 — Tester les cas qui comptent** Tout l'intérêt du code Membership est de réagir à *différents* utilisateurs. Il suffit de modifier le mock pour couvrir chaque scénario : **Un membre abonné (avec des niveaux d'accès) :** access_levels: ["premium"] **Un utilisateur connecté sans abonnement :** access_levels: [] **Plusieurs niveaux d'accès à la fois :** access_levels: ["free", "premium", "vip"] **Personne n'est connecté** — ici, vous simulez le cas d'*erreur* plutôt que celui de succès : gb.user.getCurrent = function (successCallback, errorCallback) { errorCallback({ code: 1, message: "There's no user logged in the app." }); }; Basculez entre ces cas pour vous assurer que votre Custom Code se comporte correctement dans chaque état — et pas seulement dans le scénario idéal. **Étape 3 (facultatif) — Simuler aussi *gb.membership.getAccessLevels()*** Certains codes Membership lisent les niveaux d'accès via la méthode Membership dédiée plutôt que via l'objet utilisateur : gb.membership.getAccessLevels( (access_levels) => { console.log(access_levels); }, (error) => { console.log(error.message); } ); Si vous l'utilisez, simulez-la de la même façon : if (PREVIEW_TESTING && typeof gb !== "undefined" && gb.membership) { gb.membership.getAccessLevels = function (successCallback, errorCallback) { successCallback(["premium"]); }; } ## ⚠️ Avant de publier : désactivez le mock C'est la seule règle que vous ne pouvez pas ignorer. Le mock est une béquille de développement — **il ne doit jamais arriver en production.** Si vous le publiez, chaque utilisateur de l'app sera traité comme votre faux membre `premium`, quel que soit ce qu'il a réellement payé. Deux habitudes sûres : 1. Gardez tout derrière l'unique flag `PREVIEW_TESTING` et passez-le à `false` avant de publier. 2. Mieux encore, **supprimez complètement le bloc de mock** une fois vos tests terminés. Lorsque `PREVIEW_TESTING` vaut `false` (ou que le bloc a disparu), `gb.user.getCurrent` revient à l'implémentation réelle de GoodBarber, et votre Custom Code fonctionne avec les vrais membres connectés. Prêt à essayer ? Ouvrez la section **Custom Code** dans votre back-office GoodBarber, collez le bloc de mock en haut de votre JavaScript, et définissez les `access_levels` pour le cas que vous voulez tester. Une fois que tout se comporte correctement, passez `PREVIEW_TESTING` à `false` (ou supprimez le bloc) et publiez. Pour la référence complète, consultez la [documentation de l'App API](https://app.goodbarber.dev/v2/documentation/). Et si vous préférez ne pas écrire l'extension à la main, c'est précisément là qu'intervient l'**AI Extension Builder** : décrivez en langage naturel la section que vous voulez, et il génère l'extension, la branche sur les APIs de GoodBarber et l'affiche en direct dans votre app. Il s'appuie sur la même App API — la technique présentée plus haut est donc toujours à portée de main dès que vous voulez prévisualiser le comportement de votre extension pour un membre connecté. ## Pour aller plus loin - [`gb.user.getCurrent`](https://app.goodbarber.dev/v2/documentation/#tag/user-methods/operation/gb.user.getCurrent) — récupérer l'utilisateur actuellement connecté. - [`GBUser`](https://app.goodbarber.dev/v2/documentation/#tag/user-models/operation/GBUser) — le modèle utilisateur et la façon dont ses attributs changent selon l'`api_version`. - [`gb.membership.getAccessLevels`](https://app.goodbarber.dev/v2/documentation/#tag/membership-methods/operation/gb.membership.getAccessLevels) — lire directement les niveaux d'accès (disponible uniquement avec l'add-on Memberships). - [GoodBarber pour les développeurs : plus de liberté et des outils pour les utilisateurs avancés](https://fr.goodbarber.com/blog/goodbarber-open-davantage-de-liberte-pour-les-developpeurs-et-les-utilisateurs-experts-a1233/) — ce que vous pouvez créer au-delà de l'éditeur no-code. ## Récapitulatif - Dans la preview du back-office, il n'y a **aucune véritable connexion**. - Pour les apps **Authentication** et **eCommerce**, GoodBarber injecte un faux utilisateur automatiquement, si bien que tester en tant qu'utilisateur connecté fonctionne tout seul. - Pour l'extension **Membership**, **aucun faux utilisateur n'est fourni** — `getCurrent()` déclenche le callback d'erreur. - Pour tester rapidement dans la preview, **remplacez temporairement `gb.user.getCurrent`** (et `gb.membership.getAccessLevels` si vous l'utilisez) pour renvoyer un faux membre avec les `access_levels` que vous souhaitez tester. - Pour une vérification réelle, de bout en bout, faites tourner votre app dans l'app **MyGoodBarber**. - **Retirez toujours le mock avant de publier.** ## FAQ **Pourquoi `gb.user.getCurrent()` renvoie-t-il une erreur dans la preview pour mon app Membership ?** Parce que la preview du back-office n'a aucun mécanisme de connexion, et que pour les apps Membership (`api_version: 3`), GoodBarber n'injecte pas de faux utilisateur. Comme personne n'est connecté, la méthode appelle votre callback d'erreur avec `"There's no user logged in the app."` — c'est un comportement attendu, pas un bug. **Pourquoi le même code fonctionne-t-il dans la preview pour une app Authentication ou eCommerce ?** Pour les apps Authentication (`api_version: 1`) et eCommerce (`api_version: 2`), GoodBarber injecte automatiquement un faux utilisateur (ou un faux client) dans la preview, si bien que votre callback de succès se déclenche sans aucune configuration. **Comment tester un membre connecté sans publier mon app ?** Soit en faisant tourner votre app dans l'app MyGoodBarber (iOS/Android) pour tester en conditions réelles, soit en remplaçant temporairement `gb.user.getCurrent` dans votre Custom Code pour renvoyer un faux membre avec les `access_levels` que vous souhaitez tester. **Qu'est-ce que `access_levels` dans l'objet `GBUser` ?** C'est un tableau des niveaux d'accès qu'un utilisateur Membership possède actuellement (par exemple `["premium"]`). Votre Custom Code se branche généralement dessus pour décider quel contenu afficher. Un tableau vide (`[]`) signifie un utilisateur connecté mais sans abonnement actif. **`gb.user.getCurrent()` renvoie-t-il une Promise ?** Non. Elle fonctionne par callbacks : vous passez un callback de succès et un callback d'erreur. Elle ne renvoie pas de valeur, vous ne pouvez donc pas l'`await`. **Que se passe-t-il si j'oublie de retirer le mock avant de publier ?** Chaque utilisateur de votre app sera traité comme le faux membre que vous avez codé en dur — ils obtiendraient tous, par exemple, l'accès `premium` quel que soit ce qu'ils ont réellement payé. Passez toujours `PREVIEW_TESTING` à `false` ou supprimez le bloc de mock avant de publier. - [#Comment faire](https://fr.goodbarber.com/blog/tags/comment%20faire) ![Mathieu Poli](https://blog.goodbarber.com/_public/profile/65/6553d00ecdbe15f8aac2da7dddcff47648fdd791-default.jpg) À propos de l'auteur[Mathieu Poli](https://fr.goodbarber.com/blog/author/mathieu-poli/)Head of Frontend Engineering Je suis Head of Frontend Engineering chez GoodBarber. Je supervise les équipes qui conçoivent les moteurs de rendu au cœur de notre plateforme no-code : ce sont eux qui donnent vie aux projets de nos utilisateurs et les transforment en applications natives, fluides et soignées. Tout ce que l'on voit et manipule à l'écran passe entre leurs mains. Pionnier du no-code mobile, passionné d'architecture logicielle et de design produit, je forme aussi en universités et écoles privées. J'écris ici sur l'ingénierie front, le design produit et l'IA — et sur tout ce qui se passe quand ces trois mondes se rencontrent. [En savoir plus](https://fr.goodbarber.com/blog/author/mathieu-poli/) [![LinkedIn](https://portal.ww-cdn.com/portal_static/svg/base2021/linkedin.3ed8162e2a2b.svg)](https://www.linkedin.com/in/hellomathieup)[![X](https://portal.ww-cdn.com/portal_static/svg/base2021/x.820492c586dd.svg)](https://x.com/hellomathieup/)