Tester votre Custom Code GoodBarber avec un membre connecté

Ecrit par 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é.

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 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, 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 temporairementgb.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 :

Gardez tout derrière l'unique flag PREVIEW_TESTING et passez-le à false avant de publier.
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.

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 — récupérer l'utilisateur actuellement connecté.
GBUser — le modèle utilisateur et la façon dont ses attributs changent selon l'api_version.
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 — 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