Nommez n'importe quelle section de contenu de votre app dans votre prompt, et l'AI Extension Builder construit une section qui affiche ce contenu — dans la mise en page exacte que vous avez décrite. Vos articles, votre template, toujours à jour. Chaque section de contenu d'une app GoodBarber est livrée avec une gamme de templates soigneusement conçus. Vous en choisissez un, et ça fonctionne — c'est tout l'intérêt d'une plateforme intégrée. Mais la mise en page que vous avez en tête n'est pas toujours dans la liste. Vous imaginez peut-être vos derniers articles façon magazine : une grande photo de couverture avec le titre en surimpression, des cartes plus petites en dessous. Ou vos événements en agenda compact, avec seulement la date et le lieu. Jusqu'ici, vous preniez le template qui s'en approchait le plus.Ce que beaucoup d'utilisateurs de l'AI Extension Builder n'ont pas encore découvert, c'est que cette limite a disparu. Le builder ne crée pas seulement des widgets autonomes — il sait lire le contenu des sections existantes de votre app. Ce qui en fait quelque chose de plus intéressant qu'un générateur de widgets : un outil pour concevoir vos propres templates d'affichage.

Le référencement d'une PWA repose sur un principe simple : pour qu'une page apparaisse dans les résultats de recherche, un moteur doit d'abord la visiter, la lire et l'indexer. Ce passage — le crawl — n'est pas déclenché par vous. C'est le moteur qui décide quand il repasse, à son propre rythme.Pour un site figé, cette attente n'a pas grande importance. Pour une app dont le contenu vit — un média qui publie plusieurs fois par jour, une boutique dont les prix et les stocks changent, un agenda dont les événements arrivent et expirent — c'est un vrai frein. Vous avez déjà fait le travail : le contenu est en ligne, à jour, prêt à être trouvé. Mais il reste en attente d'un robot qui n'est pas encore repassé. Pendant ce temps, c'est parfois une ancienne version de la page, ou rien du tout, qui ressort dans les résultats.

Recherche, citation, entraînement : trois contrats différents. Choisissez quels moteurs de recherche et robots d'IA accèdent à votre PWA, avec quatre préréglages ou le fichier robots.txt brut.

En résumé. Une application mobile qui n'est pas mise à jour ne reste pas figée : elle se dégrade. Les notifications push cessent d'arriver, les nouveaux utilisateurs ne la trouvent plus, et les stores finissent par la masquer ou la retirer. Sur GoodBarber, la plateforme absorbe chaque évolution des OS et des stores et livre le correctif avec votre prochaine mise à jour : une année de bouleversements mobiles vous parvient sous la forme d'une note de version. La seule chose qui reste à faire : mettre à jour régulièrement.Votre application fonctionne aujourd'hui. Laissez-la un an sans y toucher : elle s'ouvrira toujours, aura toujours la même allure, fera toujours son travail sur votre propre téléphone. Rien dans votre tableau de bord ne vous alerte. C'est là le piège.Car pendant que votre application restait immobile, tout ce qui la porte a bougé. Apple et Google ont livré de nouveaux systèmes, réécrit les règles de leurs stores, retiré la vieille tuyauterie. Vous vous en apercevez des mois plus tard, à travers des symptômes qui ressemblent à un problème marketing : les téléchargements s'essoufflent, les campagnes push touchent de moins en moins de monde, un utilisateur fidèle vous écrit que l'application se comporte mal sur son nouveau téléphone. La dégradation est réelle, et elle n'a rien à voir avec la qualité de votre contenu.

Un MCP backend donne à l'agent votre base de données. Le MCP applicatif GoodBarber lui confie votre app en production : OAuth par app, écritures vérifiées.

Plus personne ne doute qu'une IA génère du code capable — même « vibe codé », ça marche, et parfois très bien. La question intéressante n'est plus là. Elle est : une fois générée, qu'est-ce que cette section fait vraiment à l'intérieur de votre app ? Reste-t-elle un bloc isolé dans son coin, ou exploite-t-elle ce que le device et l'app savent déjà faire ? La façon la plus honnête d'y répondre, c'est de prendre un prompt et de le décortiquer, ligne par ligne.C'est à ça que sert cette nouvelle rubrique. À chaque épisode, on prendra un prompt de la bibliothèque de l'AI Extension Builder et on le décortiquera : où il fait confiance à la plateforme, où il la force, et ce que la section obtenue sait vraiment faire. Pour commencer, l'un des prompts d'exemple de la bibliothèque : « où j'ai garé ma voiture ».Voici le prompt le plus court qu'on puisse écrire pour ça :Build a "remember where I parked" helper.C'est tout. Une phrase, pas un cahier des charges. Et voilà ce qui en sort :Un bouton pour enregistrer sa position. Une section qui retrouve ce point à la réouverture de l'app. Un bouton pour repartir vers la voiture. Un lien discret pour effacer. Et, si on refuse la localisation, un écran qui l'explique au lieu de planter.La surprise n'est pas que sept mots suffisent à dessiner un écran. C'est que cette section, née d'une phrase, exploite déjà les capacités du terminal : elle lit le GPS, elle garde une mémoire, elle ouvre Maps. On n'a demandé aucune de ces trois choses explicitement.

Un quiz de personnalité — « Which 2026 Summer Blockbuster Is Your Vibe? » — construit entièrement en le décrivant à l'AI Extension Builder de GoodBarber. Le quiz, pourquoi le format marche, et le prompt exact à voler pour votre app.

Prototyper, les app builders IA savent faire. La production est un autre métier. GoodBarber livre une app native que les agents IA savent piloter.

Nous avons organisé un AMA en direct sur r/GoodBarber, ouvert à toute question sur la publication d'une application sur l'App Store — App Review, App Store Connect, comptes développeur, tout y est passé. Les réponses venaient directement de l'équipe support qui gère les soumissions App Store et Google Play au quotidien, avec les ingénieurs iOS sollicités dès qu'une question devenait technique. Voici le récapitulatif. On nous pose souvent cette question, alors nous avons étudié nos propres dossiers de support des 18 derniers mois. Les motifs de rejet les plus fréquents sont moins spectaculaires qu'on ne l'imagine :Des métadonnées App Store incomplètes ou inexactes — informations, captures d'écran ou descriptions manquantes ou trompeuses.Un formulaire App Privacy mal configuré.Des applications qu'Apple considère incomplètes ou pas totalement fonctionnelles au moment de la revue.Au-delà de ça, on voit régulièrement des rejets liés aux droits de contenu (audio ou vidéo en particulier), à des applications dans des secteurs réglementés qui ne répondent pas aux attentes d'Apple, ou jugées trop proches de quelque chose qui existe déjà.Pour une première soumission, tout commence par les métadonnées : mettez en avant la valeur réelle de votre application plutôt qu'une promotion générique, et suivez les guidelines d'Apple — elles sont la base de tout le reste. Et si vous êtes rejeté, pas de panique. Un rejet n'est pas une impasse, c'est généralement une étape normale du processus. Lisez attentivement le retour d'Apple, traitez chaque point, puis soumettez à nouveau — nous avons vu de nombreuses applications être approuvées après un ou plusieurs cycles de revue.Si vous êtes convaincu qu'un reviewer s'est trompé, restez factuel. Expliquez clairement pourquoi vous pensez que votre application respecte la guideline en question, et appuyez votre argumentation avec tout ce qui peut aider — captures d'écran, enregistrement d'écran, identifiants de test, instructions étape par étape si une fonctionnalité n'est pas évidente. Si la discussion n'avance plus, vous pouvez demander un appel avec un représentant Apple via l'App Resolution Center dans App Store Connect — une conversation directe permet souvent de clarifier un malentendu plus vite qu'un échange écrit. En dernier recours, vous pouvez faire appel auprès de l'App Review Board, où un membre senior de l'équipe Apple réexamine le dossier. Dans tous les cas, l'objectif n'est pas de prouver qu'Apple a tort, mais de permettre au reviewer de comprendre le plus facilement possible pourquoi votre application est conforme.

Le vibe coding transforme une idée en démo fonctionnelle en quelques minutes. La publier est une autre histoire : les sept murs entre un prototype généré par IA et une vraie app sur les stores.

On a demandé à l'AI Extension Builder de GoodBarber un jeu d'arcade complet : un Flappy Bird jouable au doigt, plein écran, avec un classement partagé entre tous les joueurs. Voici le résultat, le prompt exact qui l'a produit, et ce que cette preuve de concept révèle : avec l'AI Extension Builder, à peu près tout ce qui se décrit peut devenir une section de votre app. Un jeu vidéo, ce n'est pas ce qu'on attend d'un app builder.C'est précisément ce qui en fait un bon test. Pour savoir ce que l'AI Extension Builder a dans le ventre, mieux vaut lui demander l'improbable qu'une section de plus. On lui a donc décrit un jeu d'arcade complet — jouable au doigt, plein écran, un classement partagé entre tous les joueurs — et on a regardé jusqu'où il tiendrait.Il a tenu. La leçon n'est pas « publiez des jeux », mais « le plafond est bien plus haut que vous ne le croyez » : ce qui vaut pour un Flappy Bird vaut pour la fonctionnalité pointue dont votre app a réellement besoin. Tout lui a été décrit en français, en quelques paragraphes. Voici le résultat.

L'AI Extension Builder vous permet déjà de créer une section sur mesure en la décrivant en langage courant. Désormais, ces sections savent mémoriser et partager de vraies données. Demandez un sondage, une liste de réservations ou un livre d'or : le builder met en place les données qui vont derrière et les relie à votre app en ligne, grâce à une nouvelle intégration avec Supabase. Jusqu'ici, l'AI Extension Builder excellait dans un exercice précis : transformer une phrase en une section fonctionnelle. Décrivez un compte à rebours, un mood board, un mini-jeu, et il apparaît dans votre app, habillé pour s'y intégrer parfaitement. Mais chaque section qu'il produisait vivait entièrement sur l'appareil du visiteur. Rien de ce qu'il générait ne pouvait conserver une information ni la faire circuler d'une personne à l'autre.C'était là sa limite. Demandez un « sondage lecteurs » et vous obteniez un sondage qui fonctionnait très bien pour une personne, sur un seul appareil. Les votes restaient dans le navigateur. On ferme l'app, ils disparaissent. On l'ouvre sur un autre téléphone, le compteur repart de zéro. Un livre d'or que vous seul pouvez lire n'est pas un livre d'or. Une liste de réservations qui se remet à zéro sur chaque appareil n'est pas une liste de réservations.La raison était toujours la même : ces fonctionnalités ont besoin d'un endroit où stocker leurs données, et d'un jeu de règles pour décider qui peut les lire et les écrire. Cette couche — un backend — c'est la partie difficile, et c'est précisément le genre de chose qui figurait parmi les limites des créateurs d'apps no-code. Le nouveau connecteur Supabase l'apporte directement dans le builder. L'AI Extension Builder construit désormais la couche de données en même temps que la section, dans la même conversation, avant même d'écrire une ligne de code.(Si vous découvrez cette façon de créer des sections, commencez par comprendre comment fonctionne l'AI Extension Builder — cet article prend la suite. C'est le même outil qui a récemment appris à gérer l'envoi de fichiers, et qui gagne aujourd'hui une couche de données.)

Les nouveautés de ce mois-ci sont centrées sur la visibilité, la conformité et l'expérience utilisateur — de nouvelles façons de mettre en avant les actions clés, de protéger les plus jeunes et de fluidifier les interactions quotidiennes dans votre application. Voici les nouveautés : Nouveau Floating Button global : mettez en avant une action clé dans toute votre application, configurée une seule fois depuis le Structure panel. Age Protection : une nouvelle fonctionnalité pour vous conformer aux lois régionales de vérification de l'âge et protéger automatiquement les utilisateurs les plus jeunes. Vignettes des événements sur la carte : les événements affichés sur une carte peuvent désormais apparaître sous la forme de leur propre image en vignette plutôt qu'avec un repère standard, pour que chacun soit immédiatement reconnaissable. Afficher/masquer le mot de passe : vos utilisateurs peuvent désormais toucher l'icône en forme d'œil pour afficher ou masquer leur mot de passe sur n'importe quel écran de connexion ou d'inscription, pour qu'une faute de frappe ne les bloque plus jamais.

Quand nous avons lancé l'AI Extension Builder, il savait déjà construire une section sur mesure à partir d'un simple prompt. Il manquait une pièce : votre propre matière. Jusqu'ici, l'assistant partait d'une feuille blanche, écrivait le code, l'affichait en direct — mais avec ses propres images de remplacement. Pour y mettre votre logo ou vos données, il fallait pointer vers une URL externe, un lien fragile hébergé ailleurs. Le nouveau gestionnaire de fichiers supprime cette étape.Prenons un club de course à pied qui veut une section « Calendrier des courses » dans son app.Le gérant ouvre le panneau Assets, glisse deux fichiers : logo.png et un courses.csv avec les dates et les lieux. Puis il écrit à l'assistant :« Affiche les courses à venir à partir de ce CSV, avec notre logo en haut. »L'assistant connaît déjà ces fichiers. Il ne les invente pas, ne les recrée pas, ne les encode pas en base64 : il les référence par leur URL exacte — logo.png dans une balise <img>, courses.csv via un fetch(). La section s'affiche en direct, aux couleurs du club, avec ses vraies dates.Quelques jours pour un développeur, quelques minutes ici. Et le résultat n'est pas une maquette : c'est une extension native, hébergée par GoodBarber, qui part dans l'app publiée comme n'importe quelle autre section.

Récemment, nous avons organisé un AMA sur r/GoodBarber, consacré à l'AI Extension Builder — la fonctionnalité en beta qui transforme une description en langage naturel en une véritable section intégrée à votre application. Mieux encore : les développeurs qui ont conçu la fonctionnalité étaient présents dans le fil, pour répondre directement. Les questions étaient excellentes : précises, concrètes, et souvent posées par des personnes qui avaient déjà construit quelque chose. Voici ce qu'il en est ressorti. Un constat revient souvent chez celles et ceux qui testent le builder : multiplier les itérations ne donne pas forcément un meilleur résultat. Passé un certain point, les changements perdent en pertinence — et repartir d'un prompt plus clair vaut souvent mieux que de corriger sans fin un prompt existant. Notre point de vue : l'itération fonctionne le mieux quand vous affinez l'intention de départ. Quand chaque tour change la direction du projet, il est généralement plus efficace de recommencer. La qualité de ce premier prompt a un impact déterminant — plus vous êtes clair sur ce que vous voulez construire, sur les fonctionnalités attendues et sur l'expérience utilisateur, meilleur sera le résultat.

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

Gartner prévoit que 33 % des logiciels d'entreprise intégreront l'IA agentique d'ici 2028. Vos Skills GoodBarber sont déjà prêtes — activez-les, sans code.

Agences et revendeurs : passez une revue quotidienne sur toutes vos apps clientes depuis un seul agent IA. Gérez plusieurs apps GoodBarber avec une IA via MCP.

Publication de contenu par IA pour éditeurs et associations : laissez un agent publier, programmer et gérer le calendrier éditorial de votre app via MCP.

La plupart des comparatifs d'app builders opposent deux philosophies contraires : un outil qui vous oblige à concevoir une base de données, face à un autre qui vous livre des fonctionnalités toutes faites. GoodBarber et BuildFire ne relèvent pas de cette opposition. Ils sont d'accord sur la méthode : on configure des fonctionnalités prêtes à l'emploi au lieu d'assembler des briques élémentaires, et on obtient vite une app publiable. C'est justement ce point commun qui rend le choix intéressant : quand deux outils empruntent le même raccourci, la vraie question n'est plus « quelle approche choisir », mais « qu'obtenez-vous au bout du compte, et est-ce que ça tient dans le temps ? »Pour y répondre concrètement, nous avons confié le même cahier des charges aux deux plateformes : AURORA, l'app de test qui nous sert de fil rouge tout au long de cette série.BuildFire est une plateforme mature et solide : des milliers d'apps en production et un catalogue de plugins fourni. Honnêtement, les deux outils s'adressent à des profils différents — et les vraies lignes de partage se situent du côté de la qualité des apps produites, de ce qui est compris dans l'abonnement, et du coût d'exploitation d'un parc d'apps sur la durée.