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.

IndexNow est un protocole ouvert qui inverse la démarche. Plutôt que d'attendre qu'un moteur vienne découvrir vos changements, votre site notifie les moteurs dès qu'une URL est créée, modifiée ou supprimée. Le moteur sait alors exactement quoi aller chercher, et quand.

Le fonctionnement est mutualisé : une seule notification est envoyée à l'endpoint IndexNow, qui la propage à l'ensemble des moteurs participants — Bing, Yandex et les autres membres du protocole. Vous prévenez une fois, tous les moteurs qui le supportent sont servis. C'est un signal direct, envoyé au moment où le changement se produit, à la place du « repassez quand vous voulez » implicite du crawl classique.

Chez GoodBarber, IndexNow s'active sans écrire une ligne de code. Rendez-vous dans votre back-office, page Référencement, onglet Sitemap : vous y trouverez une section IndexNow avec un simple interrupteur. Activez-le, renseignez votre clé IndexNow — et enregistrez.

Où trouver cette clé ? Rendez-vous sur la page officielle bing.com/indexnow/getstarted et générez-en une : côté GoodBarber, seule la première étape vous concerne. Vous récupérez la clé, vous la collez dans le back-office, et vous vous arrêtez là. L'hébergement du fichier de clé et l'envoi des URLs — les étapes suivantes du guide — c'est nous qui les prenons en charge.

Vous êtes à l'aise avec la technique ? Bing n'est pas un passage obligé : la FAQ officielle du protocole explique comment générer la clé vous-même. Un générateur de GUID/UUID ou une simple commande suffit, en respectant la même règle — 8 à 128 caractères, uniquement des lettres (minuscules ou majuscules), des chiffres et des tirets.

C'est tout ce que vous avez à faire. GoodBarber se charge du reste : le fichier de clé attendu par le protocole est publié automatiquement à la racine de votre site, et chaque notification est envoyée pour vous. Pas d'API à brancher, pas de fichier à héberger, pas de script à maintenir. Une condition à retenir : votre PWA doit être publiée pour que les notifications partent — logique, puisque IndexNow signale des URLs réellement en ligne.

Activer les notifications, c'est bien. Vérifier qu'elles produisent leur effet, c'est mieux. C'est là qu'intervient la seconde nouveauté de cette page.

À côté du champ de vérification Google Search Console, déjà présent, vous disposez désormais d'un champ dédié à la balise meta Bing. Renseignez-la pour valider la propriété de votre site auprès de Bing Webmaster Tools. Une fois cette validation faite, vous pouvez suivre côté Bing l'état des demandes d'indexation de votre contenu : quelles URLs ont été soumises, lesquelles ont été explorées, lesquelles sont indexées. IndexNow envoie le signal, Bing Webmaster Tools vous montre ce qu'il en advient.

Cette balise vous est fournie par Bing lorsque vous ajoutez votre site. La marche à suivre :

1. Créez un compte — ou connectez-vous — sur Bing Webmaster Tools, puis ajoutez votre site, soit en saisissant son URL, soit en l'important depuis votre compte Google Search Console.
2. À l'étape de vérification de propriété, choisissez la méthode « Meta tag authentication » parmi les options proposées.
3. Copiez la balise <meta> affichée : elle contient votre code de vérification personnel.
4. Collez-la dans le champ balise meta Bing de votre back-office GoodBarber, onglet Sitemap. Inutile de toucher au code de votre site : nous insérons la balise pour vous dans le <head> de vos pages.
5. Revenez sur Bing Webmaster Tools et lancez la vérification. Votre site est validé, le suivi est actif.

Une fois l'interrupteur activé, la mécanique est entièrement silencieuse. À chaque fois que vous publiez, mettez à jour ou dépubliez un contenu de votre CMS, GoodBarber détecte le changement et envoie l'URL concernée à IndexNow. Les envois sont dédoublonnés et regroupés, pour ne notifier que ce qui doit l'être, proprement.

Vous n'avez rien d'autre à faire. Vous continuez à travailler votre contenu comme d'habitude, et chaque changement pertinent devient, dans la foulée, un signal envoyé aux moteurs. C'est le principe GoodBarber jusqu'au bout : la fonctionnalité est intégrée, incluse dans votre abonnement, et elle travaille en arrière-plan sans que vous ayez à y penser.

IndexNow est déjà dans votre back-office : ouvrez Publication → Référencement → onglet Sitemap, activez le toggle IndexNow, collez votre clé — et laissez votre contenu se faire remarquer dès qu'il change.

Si vous avez publié votre PWA, elle sert un robots.txt en ce moment même — le premier fichier que lit un robot, et celui qui décide de la suite : quelles parties de votre site sont explorées, et par qui. Le vôtre dit oui à tout le monde.

Tout ce qui suit concerne cette version web de votre application. Vos applications iOS et Android ne sont explorées par personne, et l'onglet n'apparaît qu'une fois votre PWA publiée au moins une fois — avant, il n'y a pas de fichier à configurer.

C'était une réponse défendable. Ce n'était simplement pas la vôtre — et la population à laquelle elle répond a changé. Il y a quelques années, un robot sur votre contenu, c'était Google, Bing, ou un aspirateur dont vous n'aviez que faire. Aujourd'hui, une part croissante de ce trafic appartient à des entreprises d'IA, et elles n'attendent pas toutes la même chose de vos pages. Les traiter en bloc, c'est choisir entre toutes et aucune.

Le nouvel onglet les répartit en quatre familles, en français clair : Moteurs de recherche (Google, Bing et les autres moteurs qui référencent votre site dans leurs résultats), Réponses des IA (ChatGPT, Claude ou Perplexity qui citent votre site dans leurs réponses), Entraînement des IA (les robots qui collectent votre contenu pour entraîner leurs modèles d'IA) et Lecture à la demande (quand un internaute demande à une IA d'ouvrir et lire une page précise de votre site). Quatre familles, parce que ce sont quatre contrats différents.

Concrètement. OpenAI envoie GPTBot collecter des données d'entraînement, et OAI-SearchBot répondre dans ChatGPT Search — le second, lui, renvoie vers vous. Anthropic fait de même avec ClaudeBot et Claude-SearchBot. Google sépare Googlebot, qui alimente son moteur, de Google-Extended, qui alimente ses modèles. Apple sépare Applebot d'Applebot-Extended.

Même entreprise, deux robots, deux échanges radicalement différents. L'un vous amène des lecteurs. L'autre prend le contenu et ne rend rien. Un oui ou non global ne sait pas les distinguer ; un robots.txt qui les nomme un par un, si.

C'est ce qu'encodent les quatre préréglages :

• Visibilité max — ouvert à tous les robots, y compris ceux d'entraînement IA. Maximise la portée. C'est votre fichier actuel, inchangé.
• Pas d'entraînement IA — autorise les moteurs de recherche, classiques et IA, et bloque les robots d'entraînement IA. Vous gardez le trafic, vous déclinez le jeu d'entraînement.
• SEO classique uniquement — autorise Google, Bing & co. Bloque tous les assistants IA, recherche et entraînement.
• Confidentialité stricte — bloque tout. Pour une application interne ou un environnement de test.

Un seul s'applique à la fois, et vous pouvez en changer à tout moment. La plupart des éditeurs de contenu s'arrêtent sur le deuxième — et c'est tout l'intérêt de la fonctionnalité : ce choix-là était impossible à exprimer jusqu'ici.

Un préréglage, c'est une étiquette, et une étiquette, ça se lit de travers. L'onglet montre donc son travail.

Dépliez Voir le détail de ce préréglage et vous obtenez deux choses. D'abord un verdict pour chacune des quatre familles — Autorisé ou Bloqué — pour que l'arbitrage soit à l'écran plutôt que sous-entendu par un nom. Ensuite l'aperçu du fichier robots.txt généré, qui se met à jour à mesure que vous passez d'une carte à l'autre. Vous validez un fichier, pas une promesse.

Derrière ces quatre cartes, un registre de 22 robots issus de 15 éditeurs — OpenAI, Anthropic, Google, Apple, Meta, Amazon, Perplexity, Common Crawl, ByteDance, Cohere et d'autres — avec le rôle de chacun. Le tenir à jour est notre travail, pas le vôtre : quand un nouveau robot d'IA apparaît, il rejoint la bonne famille, et votre préréglage continue de vouloir dire ce que vous avez choisi. La liste complète des robots est à un clic dans l'onglet, pour qui veut voir exactement qui s'y trouve.

Il existe un second mode, et il vient avec une condition : il s'adresse à ceux qui ont déjà écrit un robots.txt.

Basculez sur Manuel et les préréglages s'effacent — vous éditez directement le fichier, une directive par ligne. Il s'ouvre pré-rempli avec les règles du préréglage sélectionné, donc vous ne partez pas d'une page blanche ; à partir de là, vous nommez les robots un par un : bloquer Common Crawl mais garder GPTBot, ralentir un robot précis avec un Crawl-delay, ouvrir un chemin que vous laisseriez fermé autrement. Ce que vous écrivez est conservé à chaque republication, et la ligne Sitemap reste en place toute seule.

Ce qui est vérifié, c'est la forme du fichier, pas sa pertinence. Le contenu est plafonné à 10 Ko, quatre directives sont acceptées — User-agent, Disallow, Allow et Crawl-delay — et tout le reste est refusé avec son numéro de ligne. C'est un contrôle de syntaxe, pas un filet de sécurité. Disallow: / est une ligne parfaitement valide, et elle sort l'intégralité de votre site de Google. L'éditeur ne vous arrêtera pas, faute de pouvoir distinguer la faute de frappe de la décision assumée. L'interface vous prévient au moment de basculer, et ce n'est pas une formule de style.

Donc, clairement : si vous n'êtes pas sûr de ce que fait une ligne, ne l'écrivez pas. Les quatre préréglages sont réversibles, ils vous montrent le fichier avant que vous ne le validiez, et ils couvrent ce dont presque tout le monde a besoin. Le mode Manuel est là pour les cas qu'ils ne savent vraiment pas exprimer — et si vous avez un cas comme celui-là, vous le savez déjà.

Un robots.txt est une déclaration, pas un pare-feu. C'est une demande publique que les robots bien élevés respectent — et la partie honnête de cette fonctionnalité, c'est que tous ne le font pas. ChatGPT-User et Perplexity-User, qui vont chercher une page parce qu'un internaute l'a demandé, annoncent qu'ils ne la suivent pas. Bytespider non plus. Common Crawl ne la respecte qu'en partie. Nous suivons ce statut robot par robot plutôt que de faire passer le fichier pour un verrou : lisez votre choix comme « qui j'ai prévenu, et de quoi », pas comme « qui j'ai arrêté ».

Deux choses fonctionnent, elles, de manière fiable. Que votre application apparaisse ou non dans les résultats de recherche ne se règle pas ici — c'est le réglage d'indexation de vos paramètres généraux, et quand l'indexation est désactivée, l'onglet s'efface et vous le dit, plutôt que de vous laisser configurer quelque chose sans effet. Et quand vous enregistrez, la copie en cache servie sur votre domaine est purgée immédiatement : vos nouvelles règles s'appliquent en quelques secondes, au lieu d'attendre que le cache expire de lui-même.

Rendez-vous dans votre back office, onglet SEO → ROBOTS.TXT, choisissez le préréglage qui correspond à votre stratégie de contenu et enregistrez : votre fichier est en ligne quelques secondes plus tard.

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.

Quatre choses se dégradent toutes seules, et chacune se voit dans vos chiffres bien avant de se voir dans un message d'erreur.

Votre application disparaît des stores

Les stores masquent et retirent activement les applications qui ne sont plus mises à jour. C'est une politique écrite, pas une rumeur. Sur Google Play, une application doit cibler une version récente d'Android pour rester pleinement visible ; Google relève cette barre chaque année, et une application en retard de plus de deux ans cesse d'être montrée aux nouveaux utilisateurs sur les appareils récents (la politique de niveau d'API cible de Google Play). Apple mène le nettoyage par l'autre bout : son programme App Store Improvements retire les applications qui n'ont pas été mises à jour depuis trois ans et passent sous un seuil minimal de téléchargements, après un préavis de 90 jours. Vu de chez vous, rien de tout cela ne ressemble à une politique. Cela ressemble à des téléchargements qui glissent sans raison, pendant que le travail ASO dans lequel vous avez investi cesse de payer, en silence.

Vos notifications push cessent d'arriver

La portée du push se dégrade même quand vous faites tout correctement. Chaque désinstallation, changement de téléphone ou restauration d'appareil tue des jetons d'abonnés ; une application vivante renouvelle son audience en permanence, une application abandonnée ne fait que la perdre. Et la tuyauterie elle-même se fait remplacer : Apple a coupé son ancien protocole push en mars 2021, et les applications dont la chaîne de livraison n'avait jamais été migrée ont simplement cessé de livrer. Vous le vivez sous la forme de taux d'ouverture qui glissent trimestre après trimestre. Vous accusez vos textes ; ça n'a jamais été vos textes.

Chaque automne, un nouvel OS apporte de nouveaux bugs

Chaque année, Apple et Google publient des versions majeures de leurs systèmes, et les applications jamais reconstruites pour elles héritent de dysfonctionnements dès le premier jour : les mises en page bougent, les demandes de permission changent, des fonctions s'arrêtent sans bruit. Quand Apple a retiré UIWebView en 2020, chaque application encore construite dessus avait une échéance ferme : se reconstruire ou mourir. Le plus cruel, c'est qui le voit en premier : vos utilisateurs les plus engagés mettent leur téléphone à jour les premiers, donc votre meilleure audience rencontre les bugs avant tout le monde.

Le jour où vous devez enfin publier, vous ne pouvez plus

Les exigences des stores s'accumulent pendant qu'une application dort, et toutes bloquent la soumission suivante. Depuis juillet 2022, Google Play exige une déclaration Sécurité des données (Data safety) complète. Depuis mai 2024, Apple exige des manifestes de confidentialité décrivant ce à quoi l'application et ses composants accèdent. Rien de tout cela n'existait quand beaucoup d'applications ont été publiées. Alors le jour où vous devez enfin livrer un changement, un nouveau logo, des mentions légales à jour, la soumission bute sur des exigences accumulées pendant que vous regardiez ailleurs. Plus le sommeil est long, plus le mur est haut.

Votre application n'a pas changé. Le sol sous elle, si. Apple et Google livrent chacun un OS majeur par an et durcissent leurs exigences au même rythme : la barre de version Android monte chaque année, les déclarations de confidentialité sont arrivées en 2022 et 2024, les protocoles push se font reconstruire tous les quelques années. Ensemble, cela forme un tapis roulant qui ne s'arrête jamais, et une application immobile sur un tapis roulant recule.

Notre équipe d'ingénierie a raconté une décennie de ces changements dans un article dédié sur dev.to (en anglais), et mené l'autopsie de ce qui casse quand personne ne touche à une application pendant trois ans (en anglais). La version courte : rester publié n'est pas un accomplissement ponctuel. C'est un abonnement au changement.

La réponse de GoodBarber au tapis roulant est structurelle : la plateforme le fait tourner pour que vous n'ayez pas à le faire. Quand Google relève la barre de version Android, quand Apple ajoute une exigence de manifeste, quand un protocole push est retiré, GoodBarber absorbe le changement une seule fois, au niveau de la plateforme, pour les milliers d'applications en production qu'elle héberge. Le correctif entre dans votre application à votre prochaine mise à jour : votre binaire est reconstruit à la demande, selon les exigences du moment, puis soumis aux stores.

Il en va de même pour la chaîne qui porte vos notifications. GoodBarber opère le pipeline push de bout en bout et livre plusieurs millions de notifications par semaine à travers ses applications ; la gestion des jetons, les migrations de protocole et les renouvellements de certificats n'ont jamais été votre travail. Même la paperasse est générée plutôt que remplie : vos déclarations de confidentialité sont dérivées des fonctionnalités que vous avez réellement activées, si bien que ce que votre application déclare correspond à ce qu'elle contient.

La soumission elle-même est un service, pas un combat. Apple rejette environ 42 % des premières soumissions traitées par l'équipe de publication de GoodBarber, la moyenne d'Apple observée sur les 12 derniers mois, et l'équipe récupère 91 % de ces rejets sans que le propriétaire de l'application ait à lever le petit doigt. Avec GoodBarber Takes Care, une mise à jour est quelque chose que vous déclenchez, pas quelque chose que vous subissez. Et tout cela vit dans l'abonnement que vous payez déjà : hébergement, infrastructure push, conformité stores, tout le tapis roulant de la maintenance. C'est la différence entre construire une application et la faire tourner, la même ligne que nous avons tracée pour les générateurs d'applications par IA.

Vous n'avez pas acheté un éditeur d'applications. Vous avez acheté quelqu'un qui garde la vôtre en vie.

GoodBarber ne peut pas faire le dernier pas à votre place. Les correctifs voyagent dans vos mises à jour, et une mise à jour part vers les stores quand vous décidez de la publier, parce que chaque nouvelle version doit être soumise à validation. La plateforme prépare tout ; vous fournissez le déclencheur.

L'habitude qui garde une application GoodBarber en bonne santé est donc sans gloire : publiez une mise à jour régulièrement, même quand rien de visible n'a changé. Une mise à jour silencieuse n'est pas une mise à jour vide. Elle apporte des mois de travail de plateforme entre les mains de vos utilisateurs, renouvelle votre statut auprès des deux stores, et remet à zéro chacune des horloges décrites plus haut. Cela prend quelques minutes dans votre back office.

Passez ces six questions en revue ; chaque oui correspond à un symptôme décrit plus haut.

• Votre dernière mise à jour sur les stores date-t-elle de plus de 12 mois ?
• Les téléchargements ont-ils glissé sans changement dans votre marketing ?
• Vos campagnes push touchent-elles moins d'appareils qu'il y a un an ?
• N'avez-vous jamais rempli, ou jamais revu, la section Sécurité des données de Google Play et les déclarations de confidentialité d'Apple ?
• Avez-vous fait l'impasse sur un test de votre application sur les dernières versions d'iOS et d'Android ?
• Des e-mails d'avertissement d'App Store Connect ou de la Google Play Console dorment-ils non lus ?

Un oui : votre application dérive. Deux ou plus : elle est à risque. Le remède est le même dans tous les cas : publiez une mise à jour.

Faut-il mettre à jour une application si rien n'a changé ?

Oui. Même si votre contenu et votre design n'ont pas bougé, les stores et les systèmes d'exploitation autour de votre application changent chaque année : règles de visibilité, exigences de confidentialité, protocoles push, nouvelles versions d'OS. Des mises à jour régulières gardent une application visible, conforme et stable. Sur GoodBarber, chaque mise à jour apporte aussi tous les correctifs de plateforme livrés depuis la précédente.

Une application peut-elle être retirée de l'App Store ou de Google Play parce qu'elle est obsolète ?

Oui. Apple retire les applications qui n'ont pas été mises à jour depuis trois ans et passent sous un seuil minimal de téléchargements, après un préavis de 90 jours. Google Play cesse de montrer aux nouveaux utilisateurs, sur les appareils récents, les applications qui ciblent une version d'Android vieille de plus de deux ans. Ces deux politiques sont publiques et réellement appliquées.

GoodBarber met-il mon application à jour automatiquement ?

GoodBarber maintient automatiquement tout ce qui entoure votre application : le code de la plateforme, l'hébergement, l'infrastructure push et les exigences des stores sont tenus à jour par son équipe d'ingénierie. La mise à jour sur les stores, elle, part quand vous la déclenchez, parce que chaque nouvelle version doit être soumise à Apple et Google pour validation. Vous publiez régulièrement ; la plateforme fait en sorte que chaque mise à jour embarque tous les correctifs accumulés.

À quelle fréquence faut-il mettre à jour une application mobile ?

Publiez une mise à jour sur les stores au moins une fois par an, idéalement tous les quelques mois. Apple et Google livrent chacun un OS majeur par an et durcissent leurs exigences au même rythme : une mise à jour annuelle est le plancher pour rester visible et conforme. Des mises à jour fréquentes signalent aussi aux deux stores que votre application est activement maintenue.

Pourquoi les téléchargements ou la délivrance des push de mon application ont-ils soudainement chuté ?

Pour une application restée longtemps sans mise à jour, les causes habituelles sont les règles de visibilité des stores et l'usure des jetons push. Google Play cesse de montrer les applications obsolètes aux nouveaux utilisateurs, ce qui érode les téléchargements, et les jetons d'abonnés push meurent à chaque désinstallation, changement de téléphone ou restauration. Des mises à jour régulières remettent les deux à zéro.

Le remède prend quelques minutes, pas une migration. Si votre application tourne sur GoodBarber, ouvrez votre back office et publiez une mise à jour aujourd'hui : elle partira avec toutes les améliorations de plateforme accumulées depuis la précédente, et l'équipe de publication peut prendre en charge la soumission de bout en bout. Si votre application vit quelque part où personne ne la maintient, regardez ce que couvre un abonnement qui inclut la maintenance.

Le Model Context Protocol s'est imposé très vite. Présenté par Anthropic en novembre 2024 puis confié à la Linux Foundation un an plus tard, MCP est aujourd'hui la manière standard de donner des outils à un agent IA, avec plus de 9 400 serveurs publics recensés dans le MCP Registry officiel en 2026. Résultat : la phrase « nous avons un serveur MCP » est discrètement devenue une case à cocher. Toutes les plateformes peuvent la cocher, et la coche ne vous apprend rien.

Les questions qui comptent se situent un cran plus bas. Que voit un agent à travers le serveur ? Que peut-il modifier ? Et quand l'agent écrit, qu'est-ce qui sépare un prompt bien tourné d'un système en production cassé ? Les réponses dépendent bien moins du protocole, identique pour tout le monde, que de l'altitude à laquelle une plateforme s'y branche.

Les plateformes de Backend-as-a-Service branchent MCP sur leur couche d'infrastructure. Le serveur MCP de Back4app, tel que sa documentation le décrit en juillet 2026, permet à un agent de créer et gérer des apps Parse, définir des schémas de base de données, interroger et modifier des objets via l'API REST de Parse, gérer les utilisateurs et les permissions, et déployer du cloud code. Le serveur MCP officiel de Supabase pointe dans la même direction : lister les tables, exécuter du SQL, lancer des migrations, gérer les branches et les Edge Functions. Ce sont des capacités réelles et utiles. Elles ont aussi une forme indéniablement backend : ce que l'agent lit et écrit, ce sont des lignes, des schémas et des déploiements. Appelons cela un MCP pour votre base de données.

GoodBarber branche MCP à une autre altitude : l'application elle-même. Le serveur MCP de GoodBarber expose les opérations d'une app mobile finie et publiée : publier un article, programmer une notification push, créer un produit avec ses variantes, mettre à jour une commande, lire les statistiques. L'agent ne voit jamais une table. Il voit les mêmes actions produit que le propriétaire de l'app voit dans son back office. Appelons cela un MCP pour votre app.

Un MCP BaaS remet à l'agent les clés de vos données. Un MCP applicatif lui laisse piloter votre produit, en sécurité.

Côte à côte :

Même protocole, même JSON, mêmes agents à l'autre bout. Quatre choses changent du tout au tout.

La sémantique : l'agent sait ce qu'il fait

Un outil backend parle données. Un outil applicatif parle intention. Quand l'outil d'un agent est une requête SQL brute, l'agent sait qu'il insère une ligne ; que cette ligne ait un sens comme produit, abonné ou campagne est entièrement le problème du prompt. Quand un agent appelle classic_create_push_broadcast sur le serveur de GoodBarber, le nom de l'outil, son schéma typé et ses contraintes encodent déjà ce qu'est une campagne push. Il reste beaucoup moins de place pour se tromper avec aplomb, parce que la connaissance métier vit dans l'outil, pas dans le prompt.

La sécurité : où vivent les garde-fous

Les bons serveurs MCP BaaS embarquent bel et bien des contrôles, et ils comptent : Supabase, par exemple, propose un mode lecture seule et un périmètre limité au projet. Mais à l'altitude de la base de données, une écriture autorisée reste une mutation brute. Rien ne vérifie que la nouvelle ligne respecte les invariants que votre application fait respecter partout ailleurs.

Le serveur MCP de GoodBarber applique ses garde-fous au niveau du produit, côté serveur. Filtrage par fonctionnalité : un outil n'existe que si la fonctionnalité correspondante est active dans l'app, donc une app sans push configuré n'expose aucun outil push. Périmètre OAuth par app : chaque session est liée à une seule app authentifiée, un agent connecté à l'app A ne peut ni voir ni toucher l'app B, et les agences connectent chaque app cliente séparément. Écritures vérifiées : chaque écriture renvoie un indicateur côté serveur qui impose à l'agent de relire l'objet et de confirmer le résultat avant de continuer. Le succès halluciné est le mode de défaillance auquel les agents sont le plus sujets ; la réponse de GoodBarber est de faire de la vérification une clause du contrat du serveur plutôt qu'une bonne pratique laissée au prompt.

La complétude : une base de données n'est pas un produit

Un agent qui contrôle entièrement votre backend ne contrôle toujours aucun produit. L'app mobile autour de ce backend reste à votre charge : la concevoir, la construire, la connecter, la soumettre à l'App Store et à Google Play, puis la maintenir. C'est exactement l'écart que nous avons cartographié dans Les app builders IA savent créer une app. Et la faire tourner ? Un MCP applicatif démarre de l'autre côté de cet écart. L'app existe déjà : des builds natifs iOS et Android compilés plus une PWA, avec hébergement, CMS, infrastructure push et paiements inclus plutôt qu'assemblés à partir d'abonnements séparés. L'agent opère un produit en production dès le premier jour, et il ne reste rien à construire autour.

Les opérateurs : qui peut vraiment s'en servir

La documentation MCP de Back4app liste les clients pour lesquels elle est conçue : Cursor, Windsurf, VS Code, Claude Code. Des outils de développeurs, logiquement, car piloter un backend en sécurité demande le jugement d'un développeur. Un MCP applicatif remonte l'interface au niveau du langage courant. Un commerçant peut demander à Claude de changer le prix d'un produit, un éditeur peut demander à ChatGPT de publier l'article du matin et de programmer la notification push, un gérant de club peut demander les téléchargements du mois dernier, et aucun d'eux n'a besoin d'un IDE. GoodBarber a construit sa surface MCP pour cet opérateur, la même personne pour qui son back office no-code a été conçu, et elle fonctionne depuis n'importe quel client MCP, y compris des plateformes d'automatisation comme Zapier.

GoodBarber opère un serveur MCP hébergé, en production : rien à installer, rien à auto-héberger. Vous branchez l'endpoint dans votre client MCP, vous vous authentifiez via OAuth 2, et la session est limitée à votre app dès le premier appel.

L'inventaire est public et lisible par machine. La server card liste 150 outils typés métier à l'heure où nous écrivons (juillet 2026), organisés par domaine d'action : les outils préfixés cms_ couvrent le contenu (articles, événements, cartes, photos, vidéos, podcasts, y compris la publication programmée), les outils shop_ couvrent le commerce (produits et variantes, collections, commandes, codes promo, clients), et les outils classic_ couvrent le fonctionnement de l'app (diffusions push, statistiques, abonnements). La server card fait office de contrat : quand la plateforme grandit, la card grandit, et les agents connectés récupèrent automatiquement les nouveaux outils. Au-dessus du serveur, GoodBarber publie 44 Claude Skills open source qui emballent les workflows courants en recettes testées, dans la continuité de la même dynamique de plateforme agent-ready.

Ce que le serveur n'expose pas est tout aussi délibéré. Le design et la mise en page restent dans le builder, où le design system de GoodBarber peut les protéger ; faire passer du design visuel par des outils au format texte ne produit pas de bonnes apps. Et agent-ready ne veut pas dire que l'humain a quitté la pièce : vous accordez le périmètre, vous fixez les règles, et le serveur vérifie ce que l'agent fait. Les détails et la configuration client par client se trouvent sur la page MCP.

Si vous êtes développeur et construisez un logiciel sur mesure, avec votre propre modèle de données, votre propre logique métier et votre propre frontend, un serveur MCP BaaS est exactement le bon outil, et les bons sont vraiment bons. Celui de Back4app donne à votre agent de code un vrai backend Parse sur lequel construire ; celui de Supabase fait de même pour Postgres, avec des contrôles de périmètre qui montrent une catégorie en train de mûrir. GoodBarber n'est pas cet outil et ne cherche pas à l'être : la plateforme n'hébergera pas votre backend sur mesure, et elle est conçue pour les apps de contenu et le commerce mobile, pas pour du logiciel arbitraire.

Ce sont deux altitudes pour deux missions différentes, pas deux concurrents sur un même axe. Le test pratique : si votre projet a besoin d'un agent capable de toucher aux structures de données brutes, il vous faut un MCP BaaS. S'il a besoin d'un agent capable d'opérer une app mobile en production, il vous faut un MCP applicatif.

• Vous construisez un logiciel sur mesure et voulez un agent qui travaille sur votre schéma, vos données et votre cloud code : choisissez un serveur MCP BaaS comme Back4app ou Supabase.
• Vous voulez qu'un agent opère une vraie app mobile en production, sur le contenu, le catalogue, les notifications push, les commandes et les statistiques : choisissez un serveur MCP applicatif. C'est ce que GoodBarber opère.
• L'opérateur quotidien de l'app ne code pas : un MCP applicatif est la seule altitude qui fonctionne en langage courant depuis des clients grand public comme Claude et ChatGPT.
• Vous avez besoin des deux : certaines équipes les font tourner côte à côte, un MCP BaaS pour le système sur mesure qu'un développeur maintient, le serveur MCP de GoodBarber pour l'app mobile que l'entreprise opère. Le protocole est le même ; seule l'altitude diffère.

Quelle est la différence entre un serveur MCP BaaS et un serveur MCP applicatif ?

Un serveur MCP BaaS expose une infrastructure backend à un agent : tables de base de données, schémas, requêtes, fonctions cloud. Un serveur MCP applicatif expose les opérations d'un produit fini. Le serveur MCP de GoodBarber permet à un agent de publier du contenu, programmer des notifications push, gérer un catalogue et lire les statistiques d'une app mobile en production, sans jamais toucher aux structures de données brutes.

Le serveur MCP de GoodBarber donne-t-il à un agent l'accès à ma base de données ?

Non. Le serveur MCP de GoodBarber expose des opérations produit, pas du SQL. Un agent travaille avec des articles, des produits, des commandes, des campagnes push et des statistiques via des outils typés métier, et chaque appel passe par la même couche applicative que le back office, donc les règles métier et les validations s'appliquent. L'accès brut aux tables n'est jamais au menu.

Un serveur MCP sur un backend suffit-il pour faire tourner une app mobile ?

Non. Un serveur MCP backend opère la couche de données, et l'app autour reste à concevoir, construire, connecter, soumettre à l'App Store et à Google Play, puis maintenir. Un serveur MCP applicatif opère une app qui existe déjà. C'est la différence entre gérer des lignes et faire tourner un produit.

Comment GoodBarber sécurise-t-il les écritures des agents ?

Par trois couches appliquées côté serveur. Filtrage par fonctionnalité : un outil n'existe que si la fonctionnalité correspondante est active dans l'app. Périmètre OAuth par app : un agent connecté à une app ne peut pas en atteindre une autre. Écritures vérifiées : après chaque écriture, le serveur impose à l'agent de relire l'objet et de confirmer le résultat. La sécurité vit sur le serveur, pas dans le prompt.

Quel est le meilleur serveur MCP pour une app mobile no-code ?

Jugez tout candidat sur trois critères : des outils qui parlent la langue de l'app plutôt que du SQL brut, une authentification limitée à une seule app, et une vérification des écritures imposée côté serveur. Le serveur MCP de GoodBarber coche les trois cases, avec 150 outils typés métier à l'heure où nous écrivons et une server card publique qui les liste tous, pour vérifier l'inventaire au lieu de croire l'affirmation sur parole.

Constatez la différence d'altitude par vous-même. Démarrez un essai gratuit, construisez votre app, puis branchez son endpoint MCP dans Claude, ChatGPT ou n'importe quel client MCP : connecter un agent à une app en production prend environ deux minutes. Le guide MCP complet détaille la configuration client par client.

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 :

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.

Voici le point qui compte, et il est facile à manquer. Pour obtenir la position GPS, la section ne s'adresse pas directement au téléphone. Elle passe par l'app qui l'héberge.

C'est l'app qui détient l'accès au GPS, et la section l'emprunte. La conséquence est simple et rassurante : la section n'a pas de permission à elle. Ce que l'app a le droit de faire, elle en hérite ; ce que l'app n'a pas le droit de faire, la section ne peut pas le forcer. Et quelles permissions l'app demande, au départ, c'est vous qui le décidez en tant que créateur de l'app : vous les déclarez dans le Privacy Center de l'app. Une section générée reste strictement dans ce cadre ; elle n'ouvre aucune porte dérobée à côté.

C'est exactement notre philosophie de guardrails : une section générée ne peut rien faire que l'app elle-même ne s'autorise pas. On ne vous laisse pas, par prompt, franchir une limite que vous n'avez pas décidé d'ouvrir. La même logique gouverne les deux autres capacités.

La mémoire. La section retrouve la position enregistrée après qu'on a fermé et rouvert l'app. Et cette persistance, on ne l'a pas réclamée : la plateforme la met en place d'elle-même dès qu'une section manipule des données de l'utilisateur. Mieux, elle fait la part des choses — une position de parking est une donnée simple, personnelle, attachée à l'appareil : pas besoin d'une base de données comme Supabase pour ça, un stockage sur le terminal suffit, et c'est ce qu'elle choisit. C'est toute la finesse : détecter quand un vrai backend est nécessaire, et quand l'appareil suffit. Garder ce qui doit être gardé, au bon endroit, est le comportement par défaut — pas une case à cocher.

Maps. Le bouton « repartir vers la voiture » n'affiche pas de map dans la section : il ouvre l'appli Maps du téléphone, directement sur les bonnes coordonnées. Une section générée n'est pas prisonnière de son écran ; elle sait déléguer à ce que le téléphone fait déjà bien.

Trois capacités — le GPS, la mémoire, Maps — et à chaque fois le même principe : la section ne fait pas cavalier seul, elle s'appuie sur l'app qui l'entoure. De l'extérieur, pour l'utilisateur comme pour vous, c'est un seul objet cohérent. C'est ça, le vrai sujet de cet épisode — pas le parking.

Ce qui rend ce premier exemple intéressant, c'est qu'on n'a rien demandé de tout ça. On n'a pas écrit « utilise le GPS natif », ni « garde les données », ni « ouvre Maps ». La section a pris ces chemins-là toute seule, parce que ce sont ceux de la plateforme.

Autrement dit : on ne mérite pas le bon comportement à coups de précision dans le prompt. Il est le point de départ. La question intéressante devient donc l'inverse : est-ce qu'on peut, par une formulation, quitter ce bon chemin ?

La réponse est oui. Et c'est là que le prompt long de la bibliothèque devient instructif.

Le vrai prompt de « où j'ai garé ma voiture », dans la bibliothèque, est plus détaillé. La plupart de ses phrases ne font qu'enrichir ce qu'on a déjà vu : un libellé précis, un horodatage « garé il y a 23 min », une confirmation avant d'effacer. Rien qui change la nature de la section.

Sauf une ligne. Le prompt réclame un itinéraire Google Maps, calculé depuis la position actuelle jusqu'à la voiture. Et là, la section quitte le chemin intégré.

La raison n'a rien de technique : on a nommé un service précis. Demander « Google Maps », c'est demander Google Maps — le service en ligne, avec son adresse web — et non « la map », qui aurait laissé la plateforme ouvrir celle du téléphone. La section est donc allée chercher ce service à l'extérieur de l'app. Et comme toute section qui s'adresse à un service extérieur, elle a dû en demander l'autorisation : la plateforme a affiché le domaine google.com et attendu votre feu vert avant de la laisser sortir. (Là encore, les guardrails : rien ne quitte le cadre de l'app sans votre accord explicite.)

On a obtenu exactement ce qu'on avait demandé. On a aussi quitté l'app pour le web et ajouté un domaine à valider. Ce n'est ni un bug ni une bonne ou une mauvaise nouvelle : c'est un échange, et autant le faire en connaissance de cause.

D'où la seule règle à retenir de cet épisode : décrivez le résultat que vous voulez, pas la façon de l'obtenir. La version courte, qui disait simplement « repartir vers la voiture », a laissé la plateforme choisir — et elle a ouvert la Maps du téléphone, sans rien aller chercher dehors. On ne nomme un service ou une techno précise que lorsqu'on a une raison que la plateforme, elle, ne peut pas connaître.

Si vous voulez partir de la version complète et la modifier, la voici — c'est celle de la bibliothèque, à un clic dans l'AI Extension Builder :

Build a "remember where I parked" helper. Show a big primary button labeled "Save my parking spot" that captures the device's current GPS coordinates and stores them persistently on the device. Once a location is saved, swap the UI to show the saved coordinates, a timestamp ("Parked 23 min ago"), and a second button "Find my car" that opens Google Maps directions from the user's current location to the saved spot. Include a discreet "Clear" link to forget the saved location. Handle the no-permission case gracefully with an explanation.

Le plus instructif n'est pas de copier ce prompt, c'est de le tordre. Remplacez la voiture par un vélo, un emplacement de camping, une place de marché. Enlevez la ligne Google Maps et regardez la section revenir d'elle-même à la Maps du téléphone. Changez « garé il y a 23 min » par autre chose et voyez le format suivre.

La bibliothèque en réserve d’autres à décortiquer de la même façon : un quiz ciné à partager, un clone de Flappy Bird jouable avec classement, ou une section qui exploite vos propres fichiers.

L'AI Extension Builder est en bêta, ouvert à tout le monde.

Une section générée par IA peut-elle utiliser le GPS du téléphone ?

Oui. Elle n'y accède pas directement : elle passe par l'app qui l'héberge, et hérite de la permission de localisation de cette app.

Est-ce que la section demande sa propre autorisation de localisation ?

Non. Elle s'appuie sur celle de l'app. Si l'app a l'accès, la section l'emprunte ; si l'app ne l'a pas, la section ne peut pas le forcer.

Une section générée peut-elle conserver des données après la fermeture de l'app ?

Oui. La plateforme met cette persistance en place dès qu'une section manipule des données de l'utilisateur, et choisit le bon niveau : un stockage sur l'appareil pour une donnée simple, un vrai backend quand c'est nécessaire.

Une section générée peut-elle ouvrir Maps ?

Oui. Elle ouvre l'appli Maps du téléphone, directement sur les coordonnées voulues.

Comment écrire un bon prompt pour une section d'app ?

Décrivez le résultat que vous voulez, pas la façon de l'obtenir. La plateforme choisit alors le chemin le plus intégré. Ne nommez un service ou une techno précise que si vous avez une raison particulière de le faire.

Tout commence sur un écran d'intro : six tuiles d'humeur colorées — couleurs et icônes originales, pas d'affiches, pas de visuels de studio — et une promesse : 6 blockbusters sont en salles cet été — 7 questions rapides pour trouver le vôtre.

Puis sept questions, et aucune ne parle de cinéma. C'est le secret d'un quiz de personnalité : il parle de vous. « C'est vendredi soir — quel est le programme ? » « Choisissez votre bande-son de l'été. » Quatre réponses à taper, une barre de progression, des transitions fluides, un court « calcul de votre vibe… » — puis la révélation : votre film, votre persona (« The Explorer », « The Trendsetter », « The Big Kid »…), une description personnalisée aux couleurs du film, plus une ligne « second rôle », parce qu'on est tous un peu deux choses à la fois.

Deux boutons bouclent la boucle. Partager copie une phrase prête à poster — « I got Project Hail Mary — The Explorer! Which 2026 summer blockbuster is your vibe? 🎬 » — et Recommencer, parce que la moitié du plaisir, c'est de répondre à la place de votre meilleur ami.

Les quiz de personnalité sont le format fétiche de la presse pop-culture, et ce n'est pas un hasard. Compris instantanément, étrangement irrésistibles, faits pour être partagés — une carte de résultat est une capture d'écran en puissance, et chaque partage, c'est votre app qui voyage vers quelqu'un de nouveau.

Et parce que c'est une section dans votre app — pas un embed venu d'un site de quiz — elle hérite de tout ce que votre app possède déjà : votre design system, votre navigation, votre audience. L'engagement se passe dans votre produit, pas chez quelqu'un d'autre.

Il n'y a pas une ligne de code derrière ce quiz : juste un brief écrit, confié à l'AI Extension Builder. Le voici — long à dessein (le flow, les règles, les garanties), en anglais dans le texte, légèrement remis en forme pour la lecture :

Si vous l'adaptez, quatre passages font l'essentiel du travail — gardez-les :

1. Demandez des garanties, pas seulement des fonctionnalités. Le brief n'explique jamais comment coder le scoring. Il énonce ce qui doit toujours être vrai : un ordre de départage fixe pour qu'il n'y ait jamais de résultat vide, chacun des six résultats réellement atteignable, des taps rapides qui ne cassent pas le flow. Décrivez les invariants ; le builder écrit le code.

2. Énoncez le flow, écran par écran. Intro, questions, révélation, résultat : le prompt nomme chaque écran et ce qu'il doit contenir. Vous n'écrivez pas du code — vous écrivez le storyboard, et le builder construit dessus.

3. Pensez capture d'écran dès le brief. « Une carte de résultat propre, prête à être capturée » est une instruction, pas un accident. Si vous voulez des partages, demandez la partageabilité.

4. Encodez les règles légales. De vrais titres, cités de façon éditoriale — et une interdiction explicite des logos, affiches, images de films et personnages. Tous les visuels sont originaux. Le prompt est l'endroit où « éditorial de fan, pas contrefaçon » se décide.

Transparence totale : Claude m'a aidé à mettre de l'ordre dans mes idées et à écrire ce prompt. Faites-en autant — décrire ce qu'on veut, il se trouve que l'IA sait très bien aider à ça aussi.

Les films sont saisonniers ; la machine ne l'est pas. Remplacez six blockbusters par six destinations de voyage, six recettes, six styles d'entraînement, six vins, six quartiers — la mécanique (questions d'humeur, réponses pondérées, révélation, partage) ne change pas, et le squelette du prompt non plus. C'est ce que le prompt-to-section change pour les formats éditoriaux : ils deviennent quelque chose qu'on lance pour un moment, pas quelque chose qu'on planifie un trimestre à l'avance. Un quiz pour les sorties de l'été. Un autre pour la saison des récompenses. Retiré quand le moment passe, régénéré quand le suivant arrive.

Un conseil si vous partez sur du saisonnier : écrivez d'abord les six résultats — nom du persona, deux lignes d'ambiance, couleur d'accent — avant de toucher aux questions. Les questions sont faciles une fois les personas nets ; six personas nets, c'est tout le quiz.

• Can a no-code app builder make Flappy Bird? I tried — le cousin plus sauvage de ce build.
• We let an AI write code inside our no-code platform — generating it was the easy part — l'ingénierie qui rend les sections générées sûres à publier, sur dev.to.
• L'AI Extension Builder — construisez des sections sur mesure en les décrivant. En bêta, ouvert à tous.

Apportez à l'Extension Builder la fonctionnalité qu'aucun catalogue ne vous offrira jamais — un quiz pour votre niche, un calculateur pour votre service, un compte à rebours pour votre saison. Décrivez-la comme vous brieferiez un collègue : le flow, les règles, les garanties. Si ça peut se décrire, ça peut être une section de votre app dès cet après-midi.

Faut-il coder pour construire ce quiz ? Non. Tout ce qui est décrit ici — flow, scoring, animations, partage — est sorti du brief écrit ci-dessus, confié à l'AI Extension Builder de GoodBarber. Bien prompter, c'est du product thinking, pas de la programmation.

Puis-je citer de vrais titres de films dans mon app ? Les références éditoriales — comme un magazine qui parle des sorties de l'été — sont une pratique standard du contenu de fan, et le prompt interdit tout le reste : ni logos, ni affiches, ni images, ni personnages. Pour votre cas précis, voyez avec votre conseil.

Le quiz s'accordera-t-il au look de mon app ? Oui. La section est générée dans votre app GoodBarber et thémée à vos couleurs — elle atterrit dans votre design system, pas à côté.

Quelqu'un a posé très exactement cette question sur r/nocode en juin 2026, et la façon dont les réponses se répartissent vaut la lecture à elle seule. Presque personne ne prétend que ces outils ne servent à rien. Presque personne ne prétend qu'ils suffisent. Les réponses réfléchies convergent vers la même ligne : oui pour un prototype, pas encore pour la production. Deux personnes dans le fil racontent avoir publié de vraies apps sur Google Play et l'App Store avec l'aide de l'IA, sans aucun bagage de développement, et toutes deux décrivent la même expérience : ça a marché, et ça a pris des mois.

La réponse la plus utile ne répond pas à la question. Elle la remplace. La question, observe un commentateur, n'est plus de savoir si l'IA peut créer une app. C'est de savoir si l'IA peut créer une app prête pour de vrais clients.

C'est la bonne question, et elle mérite sa forme complète. Tout le monde a passé deux ans à demander si l'IA pouvait créer une app. Presque personne n'a demandé si l'IA pouvait la faire tourner. Créer, c'est un effort concentré qui se termine. Faire tourner, c'est un travail qui ne se termine jamais. L'essentiel des déceptions autour des app builders IA vient de là : on achète le premier et on a besoin du second. Cet article parle des deux moitiés.

Évitons la caricature. Ces outils sont bons, et prétendre le contraire est le meilleur moyen de perdre toute crédibilité auprès de quiconque en a utilisé un.

Ils écrasent la distance entre une idée et quelque chose que vous pouvez regarder. Vous décrivez un produit, et quelques minutes plus tard il y a un écran à cliquer, à montrer à un collègue, à commenter. Le coût d'entrée est proche de zéro. Quand vous vous demandez encore si une idée mérite vos six prochains mois, cette vitesse n'est pas un gadget. C'est tout l'intérêt, et c'est difficile à battre.

Ils ont aussi tué l'excuse. Vous ne pouvez plus dire que l'idée est morte parce que la vérifier coûtait trop cher.

« L'interface, c'est en général la partie facile maintenant », résume une réponse de ce fil r/nocode, avant de lister là où les gens calent vraiment : l'authentification, les paiements, les permissions, les intégrations, le déploiement, et les détails de backend dont dépendent les vrais utilisateurs.

C'est l'implication inconfortable pour tous ceux qui vendent de la création d'apps, nous y compris. Si une interface fonctionnelle est désormais à un prompt de distance, l'interface n'est plus l'endroit où loge la difficulté. Générer un écran, c'est réglé. Ce qui n'a jamais été la partie difficile vient de devenir plus facile, et ce qui a toujours été la partie difficile n'a pas bougé.

C'est pour cela que la conversation sur les comparaisons a changé de terrain. Placez GoodBarber à côté de n'importe quel générateur prompt-to-app : les différences intéressantes ne sont pas dans ce qui apparaît à l'écran pendant les dix premières minutes. Elles sont dans tout ce qui se passe après.

Nous avons écrit la version longue ailleurs, alors voici la carte plutôt que la visite. Entre un prototype généré par prompt et une app que vos utilisateurs téléchargent, cinq choses reviennent.

La propriété. Si vous ne pouvez pas inspecter, exporter et posséder réellement le projet sous-jacent, vous louez un résultat sur lequel vous ne pouvez pas raisonner. Le jour où quelque chose casse d'une façon que le prompt ne sait pas réparer, vous êtes coincé.

L'authentification et l'état persistant. De vrais comptes, des sessions, des permissions et des données qui survivent à un rechargement, c'est un problème d'ingénierie très différent de l'affichage d'un écran. C'est le point de blocage le plus signalé, de loin, et c'est celui qui transforme une démo convaincante en chantier à refaire.

Les données réelles et les cas limites. La production, c'est surtout le reste ingrat : l'état vide, la commande en double, l'utilisateur avec une mauvaise connexion, la ligne qui ne devrait pas exister. Les démos n'en contiennent jamais. Les utilisateurs en produisent dès le premier jour.

La publication sur les stores. C'est le point que la discussion sous-estime systématiquement, parce qu'il est invisible depuis le web. Un aperçu dans un navigateur n'est pas une app. iOS et Android exigent des binaires natifs signés, des métadonnées de store, des déclarations de permissions, des mentions de confidentialité, et un processus de validation qui a des opinions bien à lui. Apple a rejeté environ 42 % des premières soumissions traitées par notre propre équipe de publication sur les douze derniers mois.

La maintenance. Dans six mois, quelqu'un est responsable de ce code. S'il a été généré plutôt que conçu, et si régénérer une section réécrit en silence les parties qui marchaient, ce quelqu'un a un problème qui fait boule de neige.

Le témoignage le plus concret de ce fil r/nocode vient d'un menuisier, pas d'un développeur, qui a bel et bien mis une app sur Google Play avec l'aide de l'IA. Le prompt, dit-il, était la partie facile. Le vrai travail, c'était affiner les fonctionnalités, corriger les bugs, tester, recueillir les retours et gérer les exigences des stores. Cela a pris des mois et, selon son propre décompte, probablement des milliers de prompts. C'est une histoire de réussite. C'est aussi la description précise d'un travail que l'IA n'a pas supprimé.

Si vous voulez le traitement complet, chiffres à l'appui, nous avons cartographié les sept murs entre un prototype et les stores et, spécifiquement pour le mobile, ce que les outils de vibe coding oublient de vous dire. Cet article, lui, s'intéresse à ce qui vient après, une fois cette liste acceptée.

Demandez-vous ce dont votre app a besoin un mardi ordinaire, six mois après le lancement. Presque rien ne relève de la génération. Il s'agit de publier un article. D'envoyer une notification push au bon segment. De corriger un prix. De lire les chiffres de la veille. Cette charge de travail est la partie que personne ne montre en démo, les outils prompt-to-app ne la couvrent pas, par construction, et c'est là que la réponse de GoodBarber tient en deux moitiés, l'une et l'autre porteuses.

Première moitié : le résultat est une vraie app. GoodBarber compile des binaires natifs, iOS en Swift et Android en Kotlin, pas une web view encapsulée dans une coque. La même configuration produit aussi une Progressive Web App. Hébergement, base de données, CMS, notifications push, statistiques et traitement des paiements sont inclus dans l'abonnement, au lieu d'être assemblés chez quatre autres fournisseurs avec quatre autres factures. Ce n'est pas une préférence philosophique. C'est ce qui permet à quelqu'un qui ne code pas de publier, d'exploiter et de mettre à jour l'app, et c'est pourquoi les apps construites ainsi sont téléchargées toutes les 4 secondes dans 152 pays.

Seconde moitié : l'app est pilotable par des agents IA. GoodBarber fait tourner un serveur Model Context Protocol hébergé, en production, et n'importe quel assistant compatible MCP, Claude, Cursor, ChatGPT ou un autre, peut donc piloter une app GoodBarber en service, en langage naturel. Vous connectez l'endpoint à votre client IA, vous vous identifiez via OAuth, et le mardi tient en une phrase :

« Publiez le brouillon d'annonce, programmez la notification push de lancement pour 18 h, passez le produit mis en avant à 29 €, et dites-moi comment s'est passée la semaine dernière. »

Voici ce que cette phrase devient en coulisses, dans les noms d'outils du serveur lui-même :

1. cms_create_article publie l'annonce dans le CMS de l'app.
2. classic_create_push_broadcast programme la notification push de 18 h.
3. shop_update_product écrit le nouveau prix dans le catalogue en ligne.
4. classic_list_page_views et classic_list_downloads relisent la semaine écoulée et la restituent dans un résumé en langage clair.

Puis le détail qui sépare la production du simple tour de magie : après chaque écriture, le serveur exige une relecture de vérification. L'agent relit l'article qu'il a créé, la notification push qu'il a programmée, le prix qu'il a modifié, et confirme chaque élément par rapport à votre demande ; si un appel échoue, il signale l'échec au lieu d'improviser pour le contourner. Cette règle est imposée côté serveur, elle n'est pas laissée aux bonnes manières de l'agent. L'inventaire complet des outils, lisible par machine, est public, sur la server card : contenu, push, statistiques, membres, boutique, commandes, codes promo, clients. Ce que le serveur ne couvre volontairement pas : le design et la mise en page, qui restent dans l'outil de création, là où un design system peut les protéger. Au-dessus du serveur, GoodBarber publie 44 Claude Skills prêtes à l'emploi dans un dépôt open source, pour que les workflows courants arrivent sous forme de recettes testées plutôt que de prompts à inventer.

Les détails sont sur la page MCP et dans le guide complet.

Une clarification mérite d'être faite, parce que la catégorie est bruyante et imprécise. Agent ready ne signifie pas que l'humain a quitté la pièce. Chaque action est cantonnée à votre app, un agent connecté à une app ne peut pas en atteindre une autre, et le serveur vérifie après chaque écriture. C'est toujours vous qui concevez l'app, fixez les règles et relisez ce que fait l'agent. La porte est ouverte pour que des agents agissent en votre nom. C'est autre chose que de prétendre que l'app tourne toute seule, et nous n'allons pas le prétendre.

La recommandation honnête n'est pas « arrêtez d'utiliser les app builders IA ». C'est d'utiliser chaque outil pour le travail qu'il fait bien.

Utilisez un app builder IA pour savoir si votre idée mérite d'être poursuivie. Cette boucle est rapide, peu coûteuse, et meilleure que tout ce qui existait il y a trois ans. Une fois que la réponse est oui, déplacez l'idée vers quelque chose de construit pour survivre au contact des vrais utilisateurs, des vrais stores et des vrais mardis.

Changer de plateforme ne veut pas dire renoncer au prompt, d'ailleurs. GoodBarber l'a gardé, cantonné à l'endroit où il gagne sa place : la fonctionnalité qui n'existe pas encore. Décrivez une section sur mesure à l'AI Extension Builder (en bêta) : il écrit le code et l'affiche en direct, dans votre app. Il peut même travailler à partir de vos propres fichiers : déposez votre logo et vos données, et la section générée les utilise à la place d'éléments factices. La différence avec un générateur prompt-to-app, c'est tout ce qui entoure le prompt : la section se branche sur les API de GoodBarber et hérite de l'hébergement, du design system, de la compilation native et du pipeline de publication de la plateforme. Le prompt écrit ce qui n'appartient qu'à vous ; la plateforme porte ce qui relève de l'ingénierie. Le prompt seulement là où il est nécessaire, une plateforme partout où ça compte : le meilleur des deux mondes, sans rien assembler.

Soyons tout aussi honnêtes sur l'endroit où ça s'arrête. GoodBarber est construit pour les apps de contenu et le commerce mobile. Il ne crée pas de jeux, et ce n'est pas le bon outil pour recréer une marketplace complexe avec plusieurs types d'utilisateurs, comme Airbnb ou Booking.com, où tout le produit est de la logique métier sur mesure. Si c'est cela que vous construisez, aucun app builder n'est la réponse, et vous devriez l'entendre de notre bouche plutôt que le découvrir au quatrième mois. Si vous lancez du contenu, une communauté ou une boutique mobile, c'est exactement la bonne forme. Notre guide des meilleurs app builders no-code en 2026 montre comment la catégorie se compare.

Un app builder IA se juge sur ce qu'il génère. Une app en production se juge sur ce qui vient ensuite : qui la possède, qui la publie, qui la met à jour un mardi, et qui répond quand elle casse.

Prototypez avec l'IA. Publiez et pilotez avec GoodBarber. Ces deux phrases ne s'opposent pas. Elles s'enchaînent.

Un app builder IA peut-il créer une app complète si vous ne savez pas coder ?

Il peut créer un prototype fonctionnel, souvent convaincant. Là où il s'arrête, c'est la production : posséder et inspecter le projet, l'authentification, des données qui persistent correctement, les cas limites, la publication de binaires natifs signés sur l'App Store et Google Play, et la maintenance du résultat dans la durée. Pour valider une idée, oui. Pour une app dont dépendent de vrais utilisateurs, pas tout seul.

Quelles sont les limites des app builders IA pour une app mobile ?

La plupart sont de bons générateurs de code orientés web, rapides pour produire une interface fonctionnelle. Les manques propres au mobile : ils produisent des projets web plutôt que des binaires natifs iOS et Android compilés, et ils s'arrêtent à la génération, donc l'hébergement, la base de données, la soumission aux stores, les notifications push et l'exploitation quotidienne restent à assembler et à faire tourner vous-même. Nos pages de comparaison détaillent les différences fonctionnalité par fonctionnalité.

Quel est le meilleur app builder no-code pour les agents IA en 2026 ?

Le critère utile est de savoir si la plateforme expose les opérations de l'app à un agent via un protocole ouvert, pas si elle utilise l'IA pour générer l'app. GoodBarber fait tourner un serveur Model Context Protocol de production qui permet à Claude, Cursor, ChatGPT et aux autres clients compatibles MCP de piloter une app en service, en langage naturel, plus 44 Claude Skills open source pour les workflows courants. Vérifiez la server card de chaque candidat avant de croire une promesse.

Un agent IA peut-il vraiment faire tourner mon app à ma place ?

Il peut faire le travail d'exploitation : publier du contenu, programmer des notifications push, mettre à jour produits et prix, traiter des commandes, lire les statistiques. Il ne vous remplace pas comme opérateur. C'est vous qui fixez les règles, relisez les actions et restez responsable de l'app. Le terme chez GoodBarber est agent ready : la porte est ouverte pour que des agents agissent en votre nom, pas la promesse d'une app autonome.

Faut-il choisir entre la vitesse de l'IA et une vraie app de production ?

Non, et poser la question comme un choix est justement l'erreur. Utilisez les app builders IA pour la phase où la vitesse fait toute la valeur : découvrir si l'idée mérite d'être construite. Utilisez une plateforme pensée pour tout le cycle de vie une fois que la réponse est oui. GoodBarber place aussi l'IA de son côté de la ligne : l'AI Extension Builder crée des sections sur mesure par prompt, et le serveur MCP rend l'app en production pilotable par la conversation.

Prêt à voir l'autre moitié ? Démarrez un essai gratuit, construisez l'idée que vous avez prototypée le week-end dernier, et connectez votre client IA à l'endpoint MCP de votre app. Le prototype a pris un après-midi. Le faire tourner ne devrait pas exiger un développeur.

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.

Les captures d'écran ont deux rôles à la fois : convaincre quelqu'un de télécharger votre application, et aider Apple à comprendre ce qu'elle fait pendant la revue. Mettez en avant vos fonctionnalités principales et la valeur qu'elles apportent plutôt que de montrer des écrans au hasard — si votre application a quelque chose de différenciant, un workflow unique, une fonctionnalité communautaire, un cas d'usage particulier, assurez-vous qu'il soit visible.

Un détail qui piège plus de monde qu'on ne le pense : vos captures d'écran doivent correspondre à la version de l'application que vous soumettez réellement. Il est étonnamment fréquent de refondre une partie de l'application, de soumettre un nouveau build, et d'oublier de mettre à jour les captures d'écran de l'App Store — un décalage important entre ce qui est montré et ce qui est réellement revu peut soulever des questions pendant l'App Review. Apple propose aussi des gabarits produits officiels pour présenter vos captures d'écran de façon propre et cohérente, à utiliser si ce n'est pas déjà fait. Une dernière chose signalée par nos ingénieurs iOS : des captures d'écran montrant le produit ou le service d'un concurrent ont déjà posé problème en revue, mieux vaut donc les éviter complètement.

Vous n'avez besoin d'un numéro D-U-N-S que si vous voulez vous inscrire au Apple Developer Program en tant qu'Organisation. Si vous publiez en tant qu'individu, vous n'en avez pas besoin du tout.

Pour obtenir un compte Organisation, vous devez d'abord enregistrer votre structure auprès de Dun & Bradstreet (ou d'un partenaire local) — l'obtention du numéro D-U-N-S prend généralement autour de deux semaines, et Apple peut demander des informations complémentaires pendant l'inscription. En contrepartie, un compte Organisation apporte de vrais avantages : votre organisation apparaît comme développeur sur l'App Store plutôt que votre nom personnel, c'est généralement plus adapté aux entreprises et aux équipes (notamment si la propriété change au fil du temps), cela facilite la démonstration de la propriété de votre marque et de votre contenu pendant la revue, et dans certains pays, cela peut vous rendre éligible à une exonération des frais du Apple Developer Program. Si vous êtes un développeur indépendant qui publie ses propres applications, en revanche, un compte Individuel est parfaitement valable et vous dispense entièrement du numéro D-U-N-S.

Une source de confusion récurrente : les erreurs cryptiques de Transporter au moment d'envoyer un build. Voici les trois plus courantes, décryptées :

• « No suitable application records were found » → la fiche de l'application n'existe probablement pas encore dans App Store Connect.
• « Potential loss of keychain » → généralement un simple avertissement, déclenché quand l'application a été transférée entre comptes développeur Apple.
• « Redundant binary upload » → vous êtes probablement en train d'envoyer un build avec le même numéro de version ou de build qu'un build déjà présent.

C'est l'une des questions qu'on nous pose le plus souvent. D'après ce qu'on observe en accompagnant nos clients dans la publication, la plupart des revues sont bouclées en 24 à 48 heures, même si cela peut prendre plus de temps selon l'application et la charge de travail d'Apple.

Si vous avez une échéance — un événement de lancement, une date de sortie — soumettez le plus tôt possible plutôt que d'attendre la dernière minute. Ainsi, si Apple demande des modifications avant d'approuver, vous aurez encore le temps de les traiter. Et si votre calendrier devient vraiment serré, Apple propose une demande de revue accélérée pour les situations urgentes. Ce n'est pas garanti, mais cela vaut la peine d'essayer dès que vous avez une date fixe à respecter.

Le bon moment pour quitter la bêta n'est pas quand votre application est parfaite — c'est quand elle est prête pour de vrais utilisateurs. En pratique : l'expérience principale est solide, l'application contient déjà du contenu pertinent, et vos utilisateurs bêta reviennent parce qu'elle résout réellement un problème pour eux.

Le deuxième point compte tout autant : ne publiez pas sans plan de lancement. Une erreur fréquente consiste à concentrer toute son énergie sur l'obtention de l'approbation, pour se rendre compte ensuite que personne ne sait que l'application existe. Une cible claire et une réponse claire à la question « pourquoi quelqu'un choisirait cette application plutôt qu'une autre » a un impact bien plus important sur la traction que de sortir quelques jours plus tôt. Cette réponse ne sert pas seulement au marketing, d'ailleurs : elle tend aussi à correspondre à ce qu'Apple recherche pendant l'App Review. Les applications qui apportent quelque chose de réellement utile ou distinctif ont généralement un parcours plus fluide que celles qui ressemblent à une énième variante de quelque chose qui existe déjà.

Les deux plateformes peuvent être délicates, mais chacune à sa manière. D'après ce que nous observons, les premières soumissions sont plus souvent rejetées du côté d'Apple que de Google Play — mais cela ne veut pas dire que Google Play est plus simple. Il a ses propres contraintes, qui peuvent créer tout autant de friction selon le type de compte développeur et la configuration de l'application. Pour les mises à jour, le taux de rejet est généralement bien plus proche entre les deux.

Un utilisateur GoodBarber de longue date a bien résumé ce compromis dans le fil de discussion : publier sur Apple est tout un processus, et il y a toujours une raison pour laquelle une application se fait signaler — mais disposer de la documentation et du support de GoodBarber pour s'y retrouver enlève l'essentiel du stress, et garantit que l'application reste conforme aux règles des stores dans la durée. Il a aussi souligné que Google Play, autrefois la plateforme la plus simple, est également devenu plus strict : les applications doivent désormais être mises à jour régulièrement, sous peine de voir le compte développeur signalé. Un support fiable sur les deux fronts, selon lui, n'a pas de prix.

Il y a vraiment beaucoup à dire sur Google Play en particulier — assez pour qu'on prévoie un AMA dédié à ce sujet plutôt que de tout mélanger ici.

Tout ce qui précède, c'est exactement ce que notre équipe support gère au quotidien — c'est d'ailleurs pour ça que ce service existe en tant qu'offre dédiée : GoodBarber Takes Care (GBTC). Plutôt que de gérer l'App Review vous-même, l'équipe GBTC soumet l'application à l'App Store et à Google Play pour vous, de bout en bout. Apple rejette en moyenne environ 42 % des premières soumissions — souvent pour des raisons difficiles à anticiper — mais sur les 12 derniers mois, l'équipe GBTC a obtenu l'acceptation finale de 91 % de ces premières soumissions rejetées. Sur les mises à jour, un travail de prévention en amont fait descendre le taux de rejet à seulement 5 %. Si vous préférez laisser l'App Review à une équipe qui vit dedans au quotidien, c'est exactement à ça que sert GBTC.

Voilà pour le récapitulatif, mais le fil de discussion original mérite toujours d'être lu pour le détail complet de chaque réponse — et il reste ouvert, donc si vous avez une question qu'on n'a pas couverte, vous pouvez toujours la poster là-bas : AMA sur la publication App Store, sur r/GoodBarber.

C'était notre deuxième AMA en direct. Dites-nous en commentaire quel sujet vous aimeriez qu'on aborde la prochaine fois.

Le 2 février 2025, Andrej Karpathy a donné un nom au phénomène : « Il existe un nouveau genre de programmation que j'appelle le "vibe coding" : on s'abandonne complètement aux vibes, on embrasse les exponentielles, et on oublie jusqu'à l'existence du code. » Neuf mois plus tard, « vibe coding » était élu mot de l'année par le dictionnaire Collins. Peu de termes tech ont voyagé aussi vite — parce que peu d'expériences tech sont aussi grisantes.

Les chiffres racontent la même histoire. Lovable a atteint 100 millions de dollars de revenus récurrents annuels huit mois après son lancement, avec plus de 10 millions de projets créés sur la plateforme. Bolt.new a atteint environ 40 millions de dollars d'ARR en cinq mois environ. Replit a multiplié son chiffre d'affaires par dix en six mois après le lancement de son agent. Des millions de personnes ont tapé une phrase et regardé un logiciel apparaître.

Cette euphorie, nous la comprenons. C'est la même que ressentent nos utilisateurs quand ils décrivent une fonctionnalité et la voient tourner dans leur app. Voir son idée fonctionner — pas maquettée, en marche — change ce qu'on se croit capable de construire. Cette partie-là ne mérite aucune ironie.

Mais Karpathy avait glissé la réserve dans le même post : le vibe coding n'est « pas si mal pour les projets jetables du week-end ». Ceux qui le vivent au quotidien le disent avec moins de retenue. Un créateur sur r/nocode a titré son post « J'ai essayé Bolt.new. Je me suis pris pour un dieu. Puis la réalité m'a giflé. » et résumé la gueule de bois : « D'un coup, le rêve du "codage propulsé par l'IA" s'est mué en "anxiété propulsée par l'IA". »

La démo n'est pas un mensonge. L'erreur, c'est de la lire comme un produit fini.

Le vibe coding est-il production-ready ? Pour les prototypes et les outils internes, oui — brillamment. Pour une app publiée sur les stores, avec de vrais utilisateurs et de vraies données, pas à lui seul. Les vraies limites du vibe coding ne sont pas dans le code qu'il écrit ; elles sont dans tout ce que la production exige autour de ce code.

L'industrie du no-code elle-même a commencé à nommer la fracture. Le State of No-Code 2026 de Caspio décrit une IA qui tire le marché dans deux directions à la fois, et conclut par une formule sans détour : « La ligne de partage n'est pas "IA bonne contre IA mauvaise". Elle sépare le jetable du durable » (disposable vs. durable).

Alors, qu'est-ce qui rend un prototype vibe-codé jetable ? Pas la démo — tout ce qui l'entoure. Sept murs, chacun invisible sur l'écran d'un laptop, chacun bien réel le jour où vous tentez de publier. Trois d'entre eux — le code natif, la soumission aux stores et le cycle de vie d'une app — sont si spécifiques au mobile que nous leur avons consacré une analyse complète ; ici, ils prennent leur place dans le tableau d'ensemble.

Mur 1 — Hébergement et propriété

Soyons justes avec ces outils : en général, votre code vous appartient. La documentation de Lovable le dit explicitement, et vous pouvez l'exporter vers GitHub. Ce qui ne vous appartient pas, c'est tout ce dont ce code a besoin pour tourner. Par défaut, votre app vit sur le cloud managé de l'éditeur — Lovable Cloud, l'hébergement Bolt, Vercel — avec un backend, une base de données et une chaîne de build opérés par lui, à ses tarifs, selon ses conditions. Posséder le code source d'une app dont l'infrastructure appartient à quelqu'un d'autre, c'est posséder les plans d'une maison construite sur un terrain loué. La production, c'est quelqu'un qui répond de cette infrastructure pendant des années : disponibilité, sauvegardes, renouvellements, factures. Dans la démo, personne ne s'en charge.

La mutualisation. Une plateforme SaaS fait tourner une seule infrastructure pour toutes ses apps, opérée par une équipe dont le métier, à plein temps, est de la maintenir en ligne — et son coût est intégré à l'abonnement, pas découvert après coup. Toutes les apps que nous avons publiées tournent sur ce modèle depuis le premier jour.

Mur 2 — Backend et données

La couche de données d'un prototype est optimisée pour la démo : elle existe, elle répond, elle fait illusion. Les données de production ont des exigences plus rudes — migrations, sauvegardes, environnements qui séparent les essais de la réalité. En juillet 2025, la leçon a fait les gros titres quand l'agent de Replit a supprimé une base de données de production en plein gel de code explicite, effaçant les fiches de plus de 1 200 dirigeants. Replit a réagi en annonçant la séparation automatique entre bases de développement et de production — comblant un manque que les systèmes de production considèrent comme le minimum syndical.

Et au-delà de la base de données, la production est le territoire des problèmes opérationnels ingrats. L'e-mail transactionnel est le grand classique : un fondateur de SaaS rapportait sur r/SaaS « souvent moins de 50 % de taux de délivrabilité » sur une infrastructure e-mail partagée. Aucun prompt ne répare la délivrabilité.

Un backend né avant votre app. Sur une plateforme managée, la couche de données — migrations, sauvegardes, séparation entre tests et production — a été conçue une fois, par des professionnels, et elle est éprouvée chaque jour par toutes les apps qui y tournent ; notre module e-commerce tourne à lui seul en production pour des milliers de marchands. La plomberie ingrate est le quotidien d'une équipe plateforme, pas votre mauvaise surprise de la troisième semaine.

Mur 3 — Authentification et sécurité

C'est le mur le mieux documenté, parce que les chercheurs ne cessent de le mesurer. L'étude 2025 de Veracode, menée sur plus de 100 modèles, a montré que le code généré par IA introduisait des vulnérabilités du Top 10 OWASP dans 45 % des tâches testées. Un benchmark académique publié en décembre 2025 a mesuré l'écart dans sa version la plus crue : le meilleur agent produisait des solutions fonctionnellement correctes 61 % du temps, mais seulement 10,5 % de ses solutions étaient sécurisées. Et en 2025, une CVE a été déposée pour documenter l'absence de Row-Level Security dans des apps générées par Lovable — le chercheur en sécurité Matt Palmer en a scanné 1 645 et en a trouvé 170 qui exposaient des données, dont des clés API et des informations financières. Quand Escape.tech a scanné plus de 5 600 apps vibe-codées en ligne en octobre 2025, le résultat : plus de 2 000 vulnérabilités et plus de 400 secrets exposés.

Rien de tout cela ne signifie que les modèles sont mauvais. Cela signifie que la revue de sécurité est une exigence de production qu'un prototype, par définition, n'a jamais traversée.

Une sécurité écrite une fois, héritée par tous. L'authentification d'une plateforme, c'est un code unique durci par des années de trafic réel ; quand quelque chose doit être corrigé, le correctif est écrit une fois — déployé côté serveur immédiatement, embarqué dans le prochain build de chaque app. C'est la différence structurelle entre un login maintenu par des ingénieurs et des milliers de logins générés, chacun réinventant seul ses règles d'accès.

Mur 4 — Soumission aux stores

Voici le fait que la plupart des tutoriels de vibe coding passent sous silence : la plupart des outils prompt-to-app construisent des apps web, pas des apps mobiles. La FAQ de Lovable le dit sans détour : « Non, Lovable est centré sur les applications web. » v0 génère du code web déployé sur Vercel. Bolt est l'exception partielle — son intégration Expo génère du vrai code React Native — mais la compilation des binaires, les comptes développeur et la review d'Apple restent entièrement votre problème.

Le contournement le plus souvent suggéré — encapsuler l'app web dans une coquille native — se heurte à la règle 4.2 d'Apple : « Votre app doit proposer des fonctionnalités, du contenu et une interface qui l'élèvent au-delà d'un simple site web reconditionné. » L'expérience de notre équipe publication le confirme : les reviewers testent régulièrement les apps hors ligne ; une coquille qui affiche un écran blanc leur dit tout ce qu'ils voulaient savoir. Et la review ne pardonne pas, même aux vraies apps : Apple rejette environ 42 % des premières soumissions (référence Apple, mesurée sur les apps soumises par notre équipe publication ces 12 derniers mois). Nous avons écrit un guide sur les raisons pour lesquelles Apple rejette des apps, et comment rebondir.

La soumission comme processus industriel. Une plateforme compile des binaires conçus pour passer la review, et quand Apple ou Google relève la barre — nouvelles étiquettes de confidentialité, nouvelles échéances de SDK, nouveaux contrôles de complétude — elle se met à jour une fois, et chaque app qu'elle publie hérite du correctif. Quinze ans de soumissions aux stores, c'est un capital qu'aucun prompt ne peut générer.

Mur 5 — Fonctionnalités natives de l'appareil

Les fonctionnalités qui justifient une app mobile face à un site web sont précisément celles avec lesquelles une app web encapsulée se débat. Les notifications push en sont l'exemple le plus tranchant : sur iOS, le push web ne fonctionne que pour les apps web installées manuellement sur l'écran d'accueil — jamais dans le navigateur. Caméra, mode hors ligne, biométrie : chacune exige des plugins natifs à ajouter, configurer et maintenir à la main, en dehors de tout ce que l'IA a généré. Une démo web « adaptée au mobile » et une app native sont deux espèces différentes qui portent la même interface.

Natif par construction. Sur une plateforme qui compile du vrai Swift et du vrai Kotlin, le push, la caméra, le hors ligne et les retours haptiques sont des composants pré-construits, entretenus à chaque version d'iOS et d'Android — la couche qui donne à une app son allure professionnelle est le point de départ, pas une pièce rapportée.

Mur 6 — Regeneration drift : le code qui se réécrit tout seul

Appelons cela la regeneration drift — la dérive de régénération : chaque nouveau prompt régénère le code dans un contexte légèrement différent, et le correctif d'hier peut disparaître en silence dans la génération d'aujourd'hui. Addy Osmani, engineering lead sur Google Chrome, a nommé le schéma « deux pas en arrière » : « Vous essayez de corriger un petit bug… L'IA propose une modification qui semble raisonnable… Ce correctif casse autre chose. » Les données vont dans le même sens : l'analyse de 211 millions de lignes de code modifiées menée par GitClear a vu les blocs d'au moins cinq lignes dupliquées multipliés par 8 en 2024, et la part du code retouché moins de deux semaines après son écriture a presque doublé depuis 2020. Un code qui ne tient pas en place est un code sur lequel vous ne pouvez rien promettre — surtout pas à un utilisateur qui a trouvé un bug.

Des fondations qui ne bougent pas. Sur une plateforme, l'IA ne génère que la fine couche personnalisée posée sur un socle versionné et testé — l'authentification, le paiement, le CMS, le design system font partie du socle qu'aucun prompt ne régénère jamais. La dérive reste confinée à cette fine couche au lieu de gagner toute votre app : le tunnel de paiement sur lequel vous comptez ne peut pas se réécrire en douce.

Mur 7 — Confidentialité et conformité

Une app publiée porte des obligations légales qu'une démo ne croise jamais. Les étiquettes de confidentialité d'Apple comme le formulaire Data safety de Google Play vous demandent de déclarer quelles données vous collectez, où elles vont et qui les traite — des questions auxquelles une stack vibe-codée ne sait souvent pas répondre, parce qu'un réglage par défaut, quelque part, a placé les données de vos utilisateurs sur une infrastructure que vous n'avez jamais choisie. Le RGPD monte encore la barre : un consentement spécifique et non groupé, une localisation des données que vous pouvez réellement énoncer, une liste de sous-traitants que vous connaissez réellement. Rien de tout cela n'apparaît dans une démo. Tout apparaît lors de la review du store — ou pire, dans une plainte.

La conformité traitée une fois, en amont. Un seul effort juridique et technique au niveau de la plateforme — dans notre cas, toutes les données hébergées en Europe, la gestion du consentement intégrée, la détection automatique des permissions requises par chaque fonctionnalité — sert toutes les apps, et reste à jour quand les règles évoluent. Nos moteurs de compilation vont un cran plus loin : une librairie n'est embarquée dans le binaire que si la fonctionnalité qui l'utilise est activée. Les apps ne se contentent pas de déclarer moins : elles contiennent moins.

Les sept murs du vibe coding — récapitulatif

Sept murs, sept questions. Les réponses « plateforme » ci-dessus sont les nôtres ; ces questions-là sont les vôtres. Posez-les à votre prototype :

1. Qui opère l'infrastructure sur laquelle elle tourne — et l'opérera-t-il encore dans deux ans ?
2. Où vivent les données, et que se passe-t-il le jour où le schéma doit changer ?
3. Quelqu'un qui sait lire du code a-t-il relu l'authentification et les règles d'accès ?
4. Peut-elle produire un binaire iOS et Android signé qui passe la review des stores ?
5. Peut-elle envoyer une notification push sur un téléphone verrouillé ?
6. Pourrez-vous corriger un bug dans six mois sans tout régénérer — et tout recasser ?
7. Le parcours de consentement et le traitement des données survivraient-ils à une plainte RGPD ?

Trois « non » (ou « je ne sais pas ») ou plus, et ce que vous avez entre les mains est un prototype. Ce n'est pas un échec — un prototype est un objet réellement utile. Il valide une idée en un après-midi, pour presque rien. L'échec ne tient qu'à la confusion : bâtir un lancement, une base d'utilisateurs et un business sur quelque chose de conçu pour être jetable.

La conclusion n'est pas « évitez l'IA ». Nous utilisons la génération de code par IA tous les jours dans nos propres équipes d'ingénierie — notre CMO le disait déjà en avril 2025, avec la réserve que l'industrie a depuis confirmée : « Sans connaissances en programmation, on peut vite se retrouver dépassé ou bloqué, car l'IA peut créer des incohérences importantes si elle est utilisée sans supervision humaine experte. »

La conclusion, c'est de braquer la vitesse de l'IA sur des fondations qui savent publier. C'est toute la logique de l'AI Extension Builder (actuellement en bêta, disponible pour tous les clients), la réponse de GoodBarber à la question du prompt-to-app : vous décrivez une fonctionnalité en langage naturel, un agent IA la construit — mais il la construit dans une plateforme, contre des API documentées, si bien que le résultat hérite de tout ce qui manque à un prototype. Le design suit automatiquement le design system de votre app. La section est livrée en vrais binaires Swift et Kotlin, via la même chaîne de publication que nous opérons depuis 2011 — avec une équipe publication qui rattrape 91 % des rejets d'Apple en première soumission quand ils surviennent (12 derniers mois).

Les murs 2 et 3 — backend et sécurité — reçoivent le même traitement. Quand une section construite par IA doit stocker des données, l'intégration Supabase crée la structure de base de données pour vous, dans votre propre projet Supabase, sur une infrastructure que vous contrôlez — et chaque table est livrée avec des règles de Row-Level Security par défaut. C'est exactement le mode de défaillance documenté par la CVE Lovable, traité avant même que vous sachiez qu'il fallait poser la question. Et le cœur de la plateforme — hébergement, base de données, notifications push, statistiques et paiements — est inclus dans un seul abonnement : pas de pile de services tiers à assembler, sécuriser et payer séparément. Coût total de possession : environ un dixième d'un développement sur mesure.

Il y a des limites, bien sûr. GoodBarber est conçu pour les apps de contenu et le commerce mobile ; un jeu ou une marketplace très spécifique sort de ce périmètre, et pour ces projets-là, un prototype vibe-codé confié à une équipe de développement est une voie plus naturelle. Dans ce périmètre, en revanche, l'approche plateforme est ce qui transforme la vitesse de l'IA en une app que vous pouvez publier — et faire vivre dans la durée.

La prochaine étape, concrètement : démarrez un essai gratuit, ouvrez une section « Create with AI » et décrivez la fonctionnalité que vous avez vibe-codée le week-end dernier. Les mêmes cinq minutes. Cette fois, le résultat a une chaîne de publication derrière lui.

Peut-on publier une app créée en vibe coding sur l'App Store ?

Pas directement, dans la plupart des cas. Lovable et v0 produisent des applications web — il n'y a pas de binaire iOS ou Android à soumettre. Encapsuler l'app web dans une coquille native est possible, mais la règle 4.2 d'Apple rejette les apps qui se résument à « un site web reconditionné ». Bolt peut générer du code React Native via Expo, mais les builds, les comptes développeur et la review des stores restent à votre charge. Les voies fiables : recruter des développeurs pour industrialiser le code, ou reconstruire sur une plateforme qui compile des binaires natifs et gère la soumission. Pour l'analyse complète côté mobile, lisez ce que les outils de vibe coding oublient de vous dire sur les apps mobiles.

Le vibe coding est-il production-ready ?

Pour les prototypes, les outils internes et les projets du week-end — oui, et il y excelle. Pour des apps de production avec de vrais utilisateurs, la réponse mesurée est : pas sans revue d'ingénierie. Le code généré par IA introduit des vulnérabilités de sécurité dans 45 % des tâches testées (Veracode, 2025), et un benchmark académique a trouvé les solutions de son meilleur agent fonctionnellement correctes 61 % du temps, mais sécurisées seulement 10,5 % du temps (arXiv, décembre 2025). Être production-ready, ce n'est pas la question de savoir si le code tourne — c'est l'hébergement, les données, la revue de sécurité, la soumission aux stores, les fonctionnalités natives, la stabilité du code et la conformité : les sept murs du vibe coding.

Qu'est-ce que la regeneration drift dans le vibe coding ?

La regeneration drift — la dérive de régénération — c'est ce qui se produit quand chaque nouveau prompt régénère le code dans un contexte légèrement différent : le correctif d'hier peut disparaître en silence dans la génération d'aujourd'hui. Addy Osmani appelle la boucle qui en résulte le schéma des « deux pas en arrière » ; l'analyse de 211 millions de lignes modifiées menée par GitClear en a mesuré l'empreinte — des blocs de code dupliqués multipliés par 8 en 2024. C'est la raison principale pour laquelle une app vibe-codée devient plus difficile à maintenir à mesure que vous continuez à prompter.

Apple a-t-il banni les apps créées en vibe coding ?

Non — et la nuance compte. En mars 2026, Apple a bloqué les mises à jour des apps des plateformes de vibe coding comme Replit et Vibecode, au titre de la règle 2.5.2, qui interdit aux apps de télécharger et d'exécuter du code. La mesure vise les outils en tant qu'apps iOS, pas les apps construites avec l'IA. Apple a indiqué à MacRumors n'avoir aucune règle visant spécifiquement les apps issues du vibe coding. Une app individuelle construite par IA affronte la barre ordinaire : fonctionnalité minimale (4.2), spam (4.3) et complétude — la même review que toutes les apps.

Quand passer d'un prototype vibe-codé à un app builder ?

Au moment où le prototype doit devenir l'outil quotidien de quelqu'un : de vrais utilisateurs, une présence sur les stores, des mises à jour, un backend qui persiste. C'est un seuil de responsabilité, pas un seuil de compétence — le jour où d'autres personnes dépendent de l'app, quelqu'un doit répondre de ses sept murs. Gardez le prototype ; il a fait son travail en validant l'idée. Puis reconstruisez l'app là où ces murs sont déjà le travail de quelqu'un d'autre — binaires natifs, soumission aux stores, hébergement et maintenance compris. Comme le disait notre CMO, le vibe coding s'adresse à un public expert ; un app builder est construit pour tous les autres.

Combien coûte réellement la publication sur les stores ?

Un compte Apple Developer coûte 99 $ par an ; un compte développeur Google Play, 25 $ une seule fois. Vient ensuite le vrai coût : préparer les builds, les captures d'écran, les déclarations de confidentialité, et survivre à la review — Apple rejette environ 42 % des premières soumissions (référence Apple, mesurée sur les apps soumises par notre équipe publication ces 12 derniers mois). Notre guide de publication pas à pas couvre le processus, et notre service de publication s'en charge pour vous.

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.

Une section de jeu, embarquée dans une app, en trois écrans qui s'enchaînent :

• L'accueil. Un titre, une accroche, un champ pseudo, un bouton « Jouer ». Rien d'autre.
• Le jeu. Plein écran, de bord à bord. Un oiseau jaune tombe sous l'effet de la gravité ; chaque tap lui donne une impulsion. Des tuyaux verts défilent, le score grimpe à chaque passage. On touche un tuyau, le sol ou le plafond : la partie s'arrête.
• Les résultats. Le score final en grand, le top 10 du meilleur au moins bon, votre ligne surlignée dans le classement, et un bouton « Rejouer » qui relance aussitôt.

Le tout dans un look arcade rétro assumé : ciel bleu, oiseau jaune, tuyaux verts, difficulté volontairement douce pour que ce soit agréable et pas frustrant. Jouable au doigt, fluide.

Mais le détail qui change tout n'est pas à l'écran. C'est que le classement est partagé et persistant. Votre score ne reste pas dans votre téléphone : il rejoint un tableau que voient tous les autres joueurs, et il y reste après que vous avez fermé l'app. Sans ça, Flappy Rush serait un jouet solitaire. Avec, c'est une compétition entre toute votre communauté.

On y revient plus bas — parce que c'est la partie la plus intéressante. D'abord, le prompt.

Voici, dans les grandes lignes, ce qu'on a écrit dans le builder. Pas une ligne de code : une description, structurée comme on décrirait le jeu à quelqu'un.

Ce prompt paraît long, mais il ne dit jamais comment coder quoi que ce soit. Il décrit une expérience. Et quatre réflexes suffisent à le comprendre — ce sont eux qu'il faut retenir, bien plus que ce jeu précis.

1. Décrire des écrans, pas du code. Le cœur du prompt, c'est une machine à états : trois écrans, un seul visible à la fois. On ne parle pas de variables ni de boucles — on décrit ce que l'utilisateur voit à chaque étape, et dans quel ordre. Le builder traduit ça en code.

2. Régler le ressenti en langage humain. La difficulté n'est pas donnée en chiffres mais en intentions : « trou large », « défilement lent », « gravité faible », « agréable, pas frustrant ». Vous dirigez le game-feel avec des mots. C'est ce qui sépare un jeu qu'on garde d'un jeu qu'on ferme au bout de dix secondes.

3. Demander le niveau de finition attendu. « Plein écran, de bord à bord », « tactile », « soigné ». Le builder a besoin d'une direction claire sur la qualité perçue, pas seulement sur les fonctionnalités. Une phrase suffit.

4. Nommer les données partagées — et laisser le builder s'en occuper. Une seule ligne fait tout le travail invisible : « un classement partagé et persistant que voient TOUS les joueurs ». C'est elle qui transforme un jeu solo en compétition collective. Et c'est elle qui déclenche la partie la plus technique — celle dont on parle maintenant.

Un score que vous êtes seul à voir n'est pas un classement. S'il disparaît quand vous fermez l'app, ou repart de zéro sur le téléphone du voisin, il n'y a plus de compétition — juste un compteur privé.

Pour qu'un classement existe vraiment, il faut un endroit où stocker les scores de tout le monde, des règles pour décider qui peut lire et écrire, et une connexion permanente entre l'app et ces données. Cette couche — un backend — c'est précisément la partie difficile, celle qui, hier encore, imposait un développeur.

L'AI Extension Builder la met en place lui-même, grâce à sa nouvelle intégration avec Supabase. Quand le prompt réclame « un classement partagé et persistant », le builder comprend que ces données doivent survivre et être visibles par tous, crée le stockage correspondant, le sécurise avec des règles d'accès par ligne (Row-Level Security), gère les clés de connexion et relie le tout à la section. Vous décrivez le classement ; il construit ce qu'il y a derrière.

C'est exactement le cas d'usage « classements et tableaux des scores » que le builder sait désormais couvrir — au même titre qu'un sondage, un livre d'or ou une liste de réservations. Le jeu n'est qu'une façon spectaculaire de le montrer.

Le jeu n'était qu'un prétexte. Ce que Flappy Rush démontre vraiment, c'est qu'une section avancée, interactive et dotée de vraies données partagées est désormais à portée de prompt — là où il fallait, avant, un cahier des charges et un développeur.

Et si l'envie vous prend, un mini-jeu peut tout à fait trouver sa place dans un coin de votre app : aux couleurs de votre marque pendant un événement, en « jouez pour gagner » qui récompense les meilleurs scores, ou en classement communautaire qui donne une raison de rouvrir l'app. Mais l'essentiel est ailleurs — dans le fait que vous n'avez plus à renoncer à une fonctionnalité parce qu'elle sort du catalogue.

Cette section n'est d'ailleurs pas un bout de code isolé à héberger dans son coin. Elle s'intègre à votre app comme n'importe quelle autre : hébergement GoodBarber inclus, système Smart Design respecté, et embarquée dans vos apps iOS, Android et web, distribuées sur les stores comme les 190+ extensions du catalogue. C'est une section vivante dans une vraie app, pas une démo à brancher.

Ce qui répond à une objection légitime : pourquoi créer un mini-jeu dans une plateforme, plutôt que de le coder soi-même de A à Z ? Parce que ce choix est un faux dilemme. L'essentiel de ce dont une app a besoin — hébergement, gestion de contenu, comptes utilisateurs, notifications push, paiements, publication sur les stores — est identique d'une app à l'autre, et c'est déjà construit et maintenu pour vous. La part réellement propre à votre idée n'est qu'une fine couche par-dessus. Une plateforme vous permet de tenir ces 80 % communs pour acquis et de concentrer votre énergie sur les 20 % qui sont les vôtres — et désormais, ces 20 %, vous pouvez aussi les générer au prompt. Ni « la plateforme fait tout », ni « débrouillez-vous seul » : la plateforme porte le commun, vous écrivez la part qui vous appartient vraiment.

C'est le prolongement direct de ce que GoodBarber fait depuis 2011 : des apps professionnelles sans écrire une ligne de code, dans 152 pays. Quand une fonctionnalité manque au catalogue, vous ne la mettez plus de côté : vous la décrivez, et elle s'ajoute à votre app.

• Vous débutez ? Commencez par comprendre comment fonctionne l'AI Extension Builder — les bases du prompt-to-section sur lesquelles cet article s'appuie.
• L'intégration derrière le classement : ajoutez une base Supabase à votre app — comment la couche de données partagée est mise en place et sécurisée.

Ouvrez l'AI Extension Builder dans votre back-office GoodBarber (ou démarrez un essai gratuit) et décrivez une section que vous aviez rangée dans les « trop compliqué » — un jeu, un classement, un sondage, un livre d'or. La première fois qu'elle aura besoin de mémoriser ou de partager des données, connectez Supabase en deux clics, et regardez-la prendre vie. Puis dites-nous ce que vous avez construit : c'est ce qui façonne la prochaine version.

Peut-on vraiment créer un jeu avec GoodBarber ?

Pas un jeu autonome, non : GoodBarber n'est pas un moteur de jeu, et votre app ne devient pas un jeu. Ce que permet l'AI Extension Builder, c'est d'inclure un mini-jeu à l'intérieur d'une page de votre app — une section interactive, ici un Flappy Bird avec classement partagé, décrite en langage courant et construite sans coder. Le jeu vit dans l'app, aux côtés de vos autres contenus ; il n'en est pas le produit principal.

Faut-il savoir coder ?

Non. Vous décrivez le jeu en langage naturel — les écrans, les règles, le ressenti — et le builder génère le code et l'affiche en direct. Vous pouvez ensuite affiner le prompt, ou éditer le code directement si vous le souhaitez.

Comment le classement est-il partagé entre tous les joueurs ?

Grâce au connecteur Supabase de l'AI Extension Builder. Quand le prompt demande un classement partagé et persistant, le builder crée la base de données qui stocke les scores, la sécurise avec des règles d'accès, et la relie à la section — pour que chaque joueur voie le même tableau, mis à jour au fil des parties.

Où « vit » le jeu une fois créé ?

À l'intérieur de vos apps publiées — iOS, Android et web. La section hérite de l'hébergement GoodBarber, suit le système Smart Design de votre app et part sur les stores via la même chaîne de déploiement que toutes les autres extensions.

Faut-il un compte Supabase ?

Oui. La première fois qu'une section a besoin de stocker des données, le builder vous demande de connecter Supabase — une plateforme de backend open source dotée d'une offre gratuite généreuse. Vous vous identifiez une fois, et chaque section suivante réutilise cette connexion en un clic.

Peut-on adapter ce principe à autre chose qu'un jeu ?

Oui. La grammaire du prompt est réutilisable : décrivez des écrans, réglez le ressenti en mots, nommez les données à partager. Le même raisonnement produit un quiz, un tirage au sort, un mur de votes ou n'importe quelle mécanique d'engagement dotée d'un classement.

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

Prenez un studio de yoga qui veut une section de réservation de cours intégrée à son app. Vous la décrivez : « une liste des cours de la semaine, et un bouton pour que les membres réservent une place, avec le nombre de places restantes qui se met à jour au fil des réservations. »

Le builder planifie la fonctionnalité, comprend que les réservations doivent persister et être visibles par tout le monde, et met en place un endroit pour les stocker. Quand un membre réserve le mardi, le gérant du studio le voit le mercredi, et le membre suivant voit une place de moins. Les données sont réelles, partagées, et elles survivent — parce que la section dispose maintenant d'un backend relié, pas seulement d'un écran.

Vous décrivez ce que la fonctionnalité fait. Le builder détermine les données dont elle a besoin et les construit lui aussi.

La première fois qu'une de vos sections a besoin de stocker des données, le builder vous demande de connecter Supabase — une plateforme de backend open source très répandue, dotée d'une offre gratuite généreuse. Vous cliquez sur Connecter, vous vous identifiez une fois via la connexion propre à Supabase (le même type d'étape « connectez votre compte » que vous connaissez déjà quand vous reliez un service), et vous revenez dans le studio. Chaque section qui aura ensuite besoin de données réutilise cette même connexion en un seul clic.

Derrière ce clic unique, le builder prend en charge les parties qui sont d'ordinaire délicates et faciles à rater :

• Il crée la structure de données à votre place. Vous décrivez la fonctionnalité ; le builder détermine de quoi se compose une « réservation », un « vote » ou une « inscription », et met en place le stockage correspondant.
• Il sécurise les données. Chaque table est livrée avec des règles d'accès (Row-Level Security, des règles d'accès par ligne) pour que vos données ne restent pas grandes ouvertes — lectures et écritures sont encadrées dès le départ.
• Il gère les clés de connexion. Le builder distingue la clé que l'on peut sans risque embarquer dans votre app de celle qui doit rester privée, et s'en charge lui-même.
• Il vous demande avant toute modification sensible. Si une évolution de votre fonctionnalité venait à altérer ou supprimer des données déjà présentes, le builder s'arrête et vous consulte, en langage clair, avant d'y toucher.

Le tout s'affiche en direct dans l'aperçu pendant que vous l'affinez, et part dans votre app publiée.

C'est le point qui compte. La section produite par le builder n'est pas un bout de code isolé qu'il faudrait héberger, déployer ou maintenir quelque part. C'est une partie à part entière de votre app : elle hérite de l'hébergement GoodBarber, suit le système Smart Design, et part dans vos apps iOS, Android et web publiées via la même chaîne de déploiement sur les stores que toutes les autres extensions du catalogue de plus de 190 extensions de l'Extension Store.

La couche de données suit la même logique. Le builder ne vous tend pas une base de données en vous laissant la brancher. Il provisionne le stockage, le sécurise, le relie à la section et dépose la fonctionnalité finie dans votre app. Vous obtenez une fonctionnalité qui marche, présente sur les stores, pas un projet technique à assembler.

Supabase est l'une des plateformes de backend open source les plus utilisées dans le monde du développement. Sous le capot, c'est PostgreSQL — la base de données éprouvée qui fait tourner des logiciels sérieux un peu partout — enveloppée d'une API instantanée, d'une authentification, d'un stockage de fichiers et de mises à jour en temps réel. Sa fiabilité tient justement à ce qu'elle est ouverte, standard, et pas une boîte noire.

Ce que GoodBarber ajoute, c'est tout ce qui rend d'habitude cette fondation difficile à exploiter — la mise en place, les règles de sécurité, la connexion à votre app — pour que vous profitiez de la puissance de Supabase sans jamais toucher à son tableau de bord.

La règle est simple : si une fonctionnalité doit mémoriser quelque chose, ou montrer la même chose à plusieurs personnes, elle a désormais un foyer. Quelques exemples de ce qui devient possible rien qu'en le décrivant :

• Livres d'or, murs de commentaires et avis — un visiteur laisse un message, tout le monde le voit.
• Sondages, votes, enquêtes et notes — recueillez les réponses et affichez le décompte en direct.
• Formulaires d'inscription, listes d'attente et confirmations de présence — collectez des inscriptions que vous pourrez vraiment récupérer plus tard.
• Réservations et prises de rendez-vous — créneaux de cours, réservations de table, disponibilités partagées entre tous les utilisateurs.
• Classements et tableaux des scores — des meilleurs scores communs à tous, qui se mettent à jour au fil des parties.
• Chat en direct et forums de discussion — une conversation en temps réel au sein de votre app.
• Listes collaboratives et notes partagées — un wiki communautaire, une to-do commune, tout ce qui s'édite à plusieurs mains.

Les fonctionnalités vraiment personnelles — un suivi d'habitudes privé, une calculatrice, la progression d'un jeu en solo — n'ont besoin de rien de tout cela, et le builder n'ajoutera pas de backend là où il n'a pas lieu d'être. La couche de données apparaît quand la fonctionnalité appelle des informations partagées ou durables, et s'efface quand ce n'est pas le cas.

• Les données vivent dans votre propre projet Supabase. Vous connectez votre compte Supabase, donc les données de votre fonctionnalité restent sous votre contrôle, sur une infrastructure qui vous appartient. L'offre gratuite de Supabase couvre déjà beaucoup de terrain avant qu'un plan payant n'entre en jeu. (C'est distinct du contenu de votre app GoodBarber, qui reste hébergé par GoodBarber.)
• Les règles d'accès sont configurées pour vous, et méritent qu'on s'y intéresse. Chaque table reçoit d'emblée des politiques de lecture/écriture sensées. À mesure que vos fonctionnalités se développent, il est utile de comprendre ce que font ces règles — le builder fait du chemin sécurisé l'option par défaut.

• AI Extension Builder : créez des sections avec l'IA — comment fonctionne le builder, si vous partez de zéro.
• L'AI Extension Builder gère maintenant l'envoi de fichiers — l'étape précédente dans l'évolution de ce même outil.
• Les limites des créateurs d'apps no-code — les contraintes que cette nouveauté fait reculer.
• L'extension ChatGPT pour votre app — une autre façon d'ajouter des fonctionnalités boostées à l'IA à ce que vous publiez.

Qu'est-ce que le connecteur Supabase dans l'AI Extension Builder ?

C'est une intégration qui permet à l'AI Extension Builder de doter une section générée d'un vrai backend. Quand vous décrivez une fonctionnalité qui doit stocker ou partager des données, le builder met en place les tables de base de données nécessaires, les sécurise et les relie à votre section — pour que la fonctionnalité puisse mémoriser des informations et les montrer à chaque utilisateur, et pas seulement à une personne sur un seul appareil.

Faut-il savoir coder, ou écrire du SQL ?

Non. Vous décrivez la fonctionnalité en langage courant. Le builder détermine les données dont elle a besoin, crée la structure, fixe les règles d'accès et écrit le code qui lit et écrit dedans. Vous vérifiez le résultat en direct dans l'aperçu, sur des données d'exemple simulées.

Pourquoi l'AI Extension Builder utilise-t-il Supabase ?

Supabase est un backend open source très répandu, bâti sur PostgreSQL, avec base de données, authentification, stockage et fonctions en temps réel. Construire le connecteur sur une plateforme fiable et standard signifie que vos données reposent sur une fondation portable et bien maintenue — tandis que GoodBarber s'occupe de la mise en place, de la sécurité et de l'intégration pour que vous n'ayez jamais à travailler directement dans Supabase.

Faut-il un compte Supabase ?

Oui. La première fois qu'une section a besoin de stocker des données, le builder vous demande de connecter Supabase — une plateforme de backend open source dotée d'une offre gratuite généreuse. Vous vous identifiez une fois via la connexion propre à Supabase, et chaque section suivante réutilise cette connexion en un clic.

Où sont stockées les données de mon app, et à qui appartiennent-elles ?

Dans votre propre projet Supabase, sous votre compte, sur une infrastructure que vous contrôlez. C'est distinct du contenu de votre app GoodBarber (articles, produits, médias), qui reste hébergé par GoodBarber.

Pourquoi je ne vois pas mes données dans Supabase quand je teste dans l'aperçu ?

Parce que l'aperçu ne touche jamais à votre projet Supabase. Pendant que vous construisez et testez, la section fonctionne avec des données d'exemple simulées, conservées dans le navigateur : les lectures et écritures restent locales et se réinitialisent à chaque rechargement de l'aperçu. Vous pouvez donc tester librement, sans écrire d'entrées de test dans votre vraie base. Les véritables lectures et écritures Supabase commencent dès que la section est publiée dans votre app — les données apparaissent alors dans votre tableau de bord Supabase.

Les données sont-elles sécurisées ?

Chaque table créée par le builder est livrée avec des politiques Row-Level Security, si bien que les lectures et les écritures sont encadrées dès le départ plutôt que laissées ouvertes. À mesure que vos fonctionnalités se développent, il vaut la peine de comprendre ce que font ces règles — le builder fait de la configuration sécurisée l'option par défaut.

Quels types de fonctionnalités puis-je construire avec ?

Tout ce qui doit mémoriser quelque chose ou le partager entre utilisateurs : livres d'or, murs de commentaires, sondages et enquêtes, formulaires d'inscription et listes d'attente, confirmations de présence, réservations et prises de rendez-vous, classements, chat en direct et listes collaboratives. Les fonctionnalités purement personnelles — une calculatrice, un suivi d'habitudes privé, un jeu en solo — n'en ont pas besoin, et le builder n'ajoutera pas de backend là où il n'a pas lieu d'être.

Plusieurs sections peuvent-elles partager la même base de données ?

Oui. Après la première connexion, chaque nouvelle section qui a besoin de données réutilise votre projet Supabase existant en un clic, tout en gardant ses propres données séparées.

Ouvrez l'AI Extension Builder dans votre back office GoodBarber et décrivez une fonctionnalité que vous aviez classée dans les « trop compliquées » — le sondage lecteurs, la confirmation de présence à un événement, la liste de réservations, le livre d'or. La première fois qu'elle aura besoin de données, connectez Supabase en deux clics, et regardez la fonctionnalité prendre vie avec un vrai backend derrière elle. Dites-nous ensuite ce que vous avez construit, et ce que vous aimeriez qu'elle fasse ensuite — c'est ce qui façonne la prochaine version.

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

• Les widgets Articles utilisant le template Une Story s'affichent désormais correctement dans les langues qui se lisent de droite à gauche. PWA
• Les widgets Articles utilisant le template Slideshow ouvrent désormais le détail du contenu lorsqu'on les touche. iOS
• Plus de fiabilité lorsqu'on touche les liens des widgets. Android

• Défilement plus fluide, sans ouvrir accidentellement le bouton « supprimer l'article ». PWA

• La page Commandes affiche désormais le bon message lorsque vous n'avez pas encore de commande. PWA

• Le bouton d'achat utilise désormais le bon style dans les listes utilisant le template Classic. iOS
• Les événements en cours affichent désormais « NOW » au lieu de la date du jour dans les listes utilisant le template Condensed. iOS

• La liste conserve désormais sa position de défilement lorsque vous revenez de la page de détail d'un point. PWA
• Les pages de détail de la carte utilisant le template ToolbarUp Banner n'affichent plus de texte parasite dans la bannière. iOS

• Les liens directs vers l'application Telegram sont désormais pris en charge. Android

• Apparaît désormais même lorsque le menu est réglé sur « Custom Code » ou « No menu ». PWA

• Le flou est désormais disponible sur Android 12 et versions ultérieures. Android

• Une nouvelle propriété avancée vous permet de bloquer l'enregistrement d'écran de l'application. Android

• S'affiche désormais correctement lorsque le menu sélectionné est une Floating TabBar. PWA

• Le widget Custom code se recharge désormais correctement lorsque vous revenez à la Section Accueil. Android

• La demande d'autorisation App Tracking Transparency apparaît désormais de façon fiable lorsqu'elle est requise. iOS
• Le formulaire de consentement n'apparaît désormais qu'une seule fois. iOS
• Vous pouvez désormais ouvrir le menu racine depuis une URL, à l'aide du paramètre de requête openMenu=1. Android
• Les vidéos contenues dans des iframe se lisent désormais directement dans l'application au lieu d'ouvrir le navigateur. Android
• Les onglets de catégories s'affichent désormais correctement lorsqu'ils sont centrés avec de nombreuses catégories sur ordinateur, dans toutes les sections de contenu. PWA

• Les widgets Articles utilisant le template Une Story s'affichent désormais correctement dans les langues qui se lisent de droite à gauche. PWA
• Les widgets Articles utilisant le template Slideshow ouvrent désormais le détail du contenu lorsqu'on les touche. iOS
• Plus de fiabilité lorsqu'on touche les liens des widgets. Android

• Le bouton d'achat utilise désormais le bon style dans les listes utilisant le template Classic. iOS
• Les événements en cours affichent désormais « NOW » au lieu de la date du jour dans les listes utilisant le template Condensed. iOS

• La liste conserve désormais sa position de défilement lorsque vous revenez de la page de détail d'un point. PWA
• Les pages de détail de la carte utilisant le template ToolbarUp Banner n'affichent plus de texte parasite dans la bannière. iOS

• La lecture d'un podcast mis en favori ouvre désormais le bon contenu. Android

• Plus de fiabilité lors de recherches nombreuses au fil du temps. iOS
• Les polices des onglets restent désormais cohérentes. PWA

• Les liens directs vers l'application Telegram sont désormais pris en charge. Android

• Apparaît désormais même lorsque le menu est réglé sur « Custom Code » ou « No menu ». PWA

• Le flou est désormais disponible sur Android 12 et versions ultérieures. Android

• Une nouvelle propriété avancée vous permet de bloquer l'enregistrement d'écran de l'application. Android

• S'affiche désormais correctement lorsque le menu sélectionné est une Floating TabBar. PWA

• Consultation des coupons plus fiable. Android

• Le widget Custom code se recharge désormais correctement lorsque vous revenez à la Section Accueil. Android

• Les publicités Interstitial et App Open s'affichent désormais correctement pour les utilisateurs situés hors de l'EEA. iOS

• Les titres d'album apparaissent désormais sur les systèmes embarqués des voitures lorsqu'ils sont disponibles. iOS
• Le titre de la section est désormais utilisé par défaut comme titre de la page. iOS
• Vous pouvez désormais masquer les pochettes de flux dans les notifications. Android

• Le contenu de la page reste désormais correctement centré. PWA

• Validation des tampons plus fiable. Android

• Le contenu payant s'affiche désormais correctement, sans plus aucun scintillement. iOS

• La demande d'autorisation App Tracking Transparency apparaît désormais de façon fiable lorsqu'elle est requise. iOS
• Le formulaire de consentement n'apparaît désormais qu'une seule fois. iOS
• Vous pouvez désormais ouvrir le menu racine depuis une URL, à l'aide du paramètre de requête openMenu=1. Android
• Les vidéos contenues dans des iframe se lisent désormais directement dans l'application au lieu d'ouvrir le navigateur. Android
• Les onglets de catégories s'affichent désormais correctement lorsqu'ils sont centrés avec de nombreuses catégories sur ordinateur, dans toutes les sections de contenu. PWA

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.

Le panneau Assets vit dans la barre latérale du menu Code de l'Extension Builder. On y dépose des fichiers, on les voit listés, on les supprime. Et surtout : l'IA en a connaissance au moment de générer le code.

Concrètement, à chaque génération, l'assistant reçoit la liste de vos fichiers — nom, type, URL — et l'instruction de les utiliser tels quels. D'où trois différences qui comptent :

Vos fichiers, pas des placeholders. Le logo affiché est le vôtre. Les données affichées sont les vôtres. Plus besoin de remplacer l'image ou les valeurs de démo après coup.

Des URL stables, sur votre domaine. Chaque fichier reçoit une adresse canonique servie depuis le domaine de votre app, pas depuis un service tiers. L'URL ne change pas quand vous régénérez le code, et le fichier est embarqué avec l'extension : aucune dépendance externe, aucun risque de lien mort.

Une mention rapide dans le prompt. En écrivant votre demande, tapez @ suivi du début d'un nom de fichier : la liste apparaît, vous choisissez, le nom s'insère. Pas besoin de recopier une URL à la main.

Quelques exemples express : déposez votre logo et vos images, et une section sort déjà à votre charte ; importez un fond, une bannière ou une illustration qui n'appartient qu'à vous ; ou — celui qui débloque le plus — confiez vos données à l'assistant.

Un nombre surprenant de sections ne sont, au fond, que vos données bien présentées : une grille tarifaire, un planning, un annuaire, des résultats, un catalogue. Jusqu'ici, les faire entrer dans une app no-code voulait dire les retaper à la main ou reconstruire un tableau cellule par cellule.

Désormais, vous importez un .csv ou un .json, vous décrivez la section en langage naturel, et l'assistant en construit une qui lit votre fichier et l'affiche. Changez un prix, ajoutez une ligne, mettez une date à jour — vous modifiez le fichier, la section suit. Pas de copier-coller, pas de tableau manuel, pas de développeur dans la boucle.

Si votre point de départ est un tableur, c'est un terrain que GoodBarber connaît bien : transformer une feuille de calcul en app mobile. Le gestionnaire de fichiers porte la même idée à l'intérieur de l'AI Extension Builder : vos données, votre section, générées sur-le-champ.

L'AI Extension Builder n'écrit pas du code dans le vide : il produit du code qui parle nativement à la plateforme GoodBarber, et hérite donc de son hébergement, de son design system et de sa publication sur les stores. Le gestionnaire de fichiers prolonge cette logique. Vos assets ne sont pas hébergés ailleurs : ils vivent sur l'infrastructure GoodBarber, scellés à votre section, embarqués dans l'extension. Rien à brancher, rien à payer en plus, rien à maintenir de votre côté.

C'est la différence entre une IA qui génère un bout de code à copier-coller et une IA qui livre une section vivante dans une vraie app — et cela s'inscrit dans l'ensemble des fonctionnalités d'IA de GoodBarber, de la rédaction de contenu au chatbot RAG.

Quels formats de fichiers puis-je importer ? Des images (PNG, JPG, GIF, WebP, SVG, AVIF) et des fichiers de données (JSON, CSV, TSV).

Où mes fichiers sont-ils hébergés ? Sur l'infrastructure de GoodBarber, servis depuis le domaine de votre app — pas par un service tiers. Chaque fichier reçoit une URL canonique stable et est embarqué dans votre extension : aucune dépendance externe, aucun risque de lien mort.

La section générée est-elle prête pour la production ? Oui. C'est une extension qui hérite de l'hébergement, du design system, de la compilation et de la publication sur les stores de GoodBarber — le même pipeline que n'importe quelle autre section, pas un extrait à copier-coller.

L'assistant peut-il exploiter les données structurées de mon CSV ou JSON ? Aujourd'hui, l'assistant référence vos fichiers de données par leur URL et les lit (par exemple via fetch()) pour afficher du contenu. Un traitement plus poussé des données structurées — analyser vos colonnes et injecter les lignes directement — est la prochaine étape sur la feuille de route.

L'AI Extension Builder est en Beta, accessible à tous les clients depuis le back-office. Le panneau Assets y est déjà : ouvrez une section, déposez un fichier, et demandez à l'assistant de l'utiliser. Prochaine étape sur la feuille de route : un traitement plus profond des données structurées — pour que vos fichiers CSV et JSON deviennent de vraies sources de contenu, et plus seulement des fichiers référencés.

Importez un fichier, écrivez un prompt, regardez votre marque entrer dans le code.

« Affiche le contenu de ma section Actualités en liste à deux colonnes. »

Plusieurs questions tournaient autour du même besoin — un fil social, un mur, une couche de contenu que les utilisateurs peuvent alimenter depuis l'application. La réponse à toutes : la même capacité à venir — l'intégration de Supabase.

Dans une prochaine version, l'AI Builder détectera quand votre application a besoin d'une base de données et proposera de connecter un projet Supabase. Vous vous connectez à votre compte Supabase, et le builder s'occupe du reste — créer la structure de la base, la relier à votre application et l'utiliser comme couche de données.

Cela ouvre la porte exactement aux expériences dynamiques et data-driven décrites : fils sociaux, murs, et bien plus. Nous explorons même les Edge functions, avec des premiers résultats très encourageants. Des exemples suivront dès que ce sera disponible.

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

L'App API de GoodBarber permet à votre Custom Code de demander « qui utilise l'app à l'instant T ? » via une seule méthode :

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 :

La liste des attributs dépend de cette version. Pour une app Membership (api_version: 3), un GBUser ressemble à ceci :

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 :

Gardez ceci en tête — c'est précisément ce code que le mock ci-dessous va alimenter.

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 :

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.

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.

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() :

💡 "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 :

…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) :

Un utilisateur connecté sans abonnement :

Plusieurs niveaux d'accès à la fois :

Personne n'est connecté — ici, vous simulez le cas d'erreur plutôt que celui de succès :

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 :

Si vous l'utilisez, simulez-la de la même façon :

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.

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

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

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

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.

Voici un chiffre qui mérite qu'on s'y arrête. Gartner prévoit que 33 % des logiciels d'entreprise intégreront de l'IA agentique d'ici 2028, contre moins de 1 % en 2024. Ce n'est pas une prévision lointaine — ce sont les deux prochains cycles budgétaires.

Et le marché évolue dans le même sens. Le marché des agents IA pesait déjà environ 7,6 milliards de dollars en 2025 et grimpe rapidement (Grand View Research). « Vertical » est le mot clé : non pas un chatbot généraliste qui répond à des questions de culture générale, mais un assistant qui ne connaît que votre activité — vos produits, vos commandes, vos membres.

Et voici ce que la plupart des propriétaires d'app ne voient pas. Si vous faites tourner une app GoodBarber, vous possédez probablement déjà un agent vertical sans le savoir. Vos Skills — le publieur de contenu, le catalogue produits, le moteur de push — sont exactement les briques dont un agent vertical a besoin. Elles sont simplement restées inactives. Réveillons-les.

L'IA horizontale apporte des réponses larges sur n'importe quel sujet ; l'IA verticale réalise des actions précises au sein d'un seul domaine métier.

Voyez cela comme un couteau suisse face à un scalpel. ChatGPT, dans sa forme généraliste, est le couteau suisse — il peut écrire un poème, expliquer la photosynthèse et suggérer une recette pour le dîner, le tout dans un seul outil. Une polyvalence impressionnante. Mais lorsque vous avez besoin d'une incision précise à un endroit unique, ce n'est pas la polyvalence que vous recherchez.

Un agent vertical, c'est le scalpel — conçu pour une seule tâche, dans un seul domaine, et bien exécutée. Un agent de traitement des commandes n'écrit pas de poésie. Il consulte les commandes du jour, met à jour leur statut de livraison et avertit chaque client. Il connaît votre flux de traitement — en attente, traitée, livrée — parce que c'est le seul univers dans lequel il évolue.

L'IA horizontale répond aux questions. L'IA verticale accomplit des tâches. Cette distinction compte plus qu'il n'y paraît.

Pour une petite entreprise, les tâches qui dévorent votre semaine ne sont pas des questions de culture générale — ce sont des corvées opérationnelles répétitives. Mettre à jour des fiches produits. Programmer le push hebdomadaire. Envoyer un code promo pour une vente. Un assistant horizontal peut vous expliquer comment faire ces choses. Un agent vertical connecté à votre app peut réellement les faire, à l'intérieur de votre app, avec vos données.

C'est pourquoi le vertical l'emporte pour le travail métier. La valeur n'est pas dans le savoir — elle est dans le faire.

Un agent vertical a besoin de quatre choses : une connaissance métier, la capacité d'agir, des données en temps réel et la répétabilité.

S'il en manque une, vous retombez sur un chatbot habile. Voici les quatre critères, chacun associé à la manière dont vos Skills GoodBarber y répondent déjà.

1. Une connaissance métier spécifique. L'agent doit comprendre une activité en profondeur plutôt que tout en surface. Un agent de restaurant connaît votre menu, vos catégories et vos prix — pas le droit fiscal. Voici comment les Skills GoodBarber y répondent : vos Skills produits et contenu encodent déjà votre catalogue et vos rubriques, si bien qu'un agent qui les opère hérite de ce contexte métier dès le premier jour.

2. La capacité d'action. Un véritable agent vertical agit — il ne se contente pas de décrire. La différence entre « vous devriez envoyer un push » et un push réellement parti, c'est tout l'enjeu. Voici comment les Skills GoodBarber y répondent : le Skill push permet à un agent de rédiger, programmer et envoyer une notification, transformant une recommandation en une campagne effectivement diffusée.

3. L'intégration avec des données en temps réel. L'agent doit lire et écrire vos données actuelles, pas une copie périmée. Le stock d'hier est pire que pas de stock du tout. Voici comment les Skills GoodBarber y répondent : le Skill e-commerce lit votre catalogue en temps réel, donc lorsqu'un agent réécrit une description produit, il modifie la fiche que vos clients voient réellement en cet instant.

4. La répétabilité et l'automatisation. Une tâche que vous faites une fois est un service rendu ; une tâche qu'un agent répète de façon fiable est un système. Le gain se cumule chaque semaine. Voici comment les Skills GoodBarber y répondent : le Skill contenu peut faire tourner votre calendrier éditorial selon un planning, en rédigeant et publiant au même rythme sans que vous ayez à rouvrir le tableau de bord à chaque fois.

Quatre critères. Vos Skills cochent déjà toutes les cases. La seule pièce manquante, c'est la connexion qui permet à un agent de les atteindre.

Chaque Skill GoodBarber devient un agent vertical dès qu'une IA peut l'opérer — et cet interrupteur est déjà en place.

Un Skill est une capacité précise au sein de votre app : contenu, produits, commandes, push, abonnements. Seul, un Skill est quelque chose que vous opérez à la main dans le tableau de bord. Connectez-y une IA grâce au langage que votre IA parle à votre app, et ce même Skill devient quelque chose qu'un agent peut faire tourner pour vous. Même capacité, nouvel opérateur.

Le changement se voit le plus clairement côte à côte.

Relisez la colonne de droite. Aucune de ces actions ne nécessite un nouveau logiciel. Elles nécessitent un agent capable d'atteindre les Skills que vous payez déjà.

C'est ce que nous voulons dire quand nous disons que votre app est prête pour les agents. La porte est ouverte pour qu'un agent IA opère votre app — mais vous restez le chef d'orchestre. L'agent rédige les 50 fiches produits ; vous les approuvez. L'agent planifie le calendrier de push ; vous validez avant que quoi que ce soit ne parte. L'humain reste dans la boucle, à réviser et approuver. « Prête pour les agents » signifie que l'IA peut agir, pas que vous cessez de décider.

Le panorama complet de ce qu'un agent peut atteindre se trouve dans notre décryptage de la façon dont votre app GoodBarber est devenue prête pour les agents IA avec 44 Skills pour Claude Code, Cursor et n'importe quel client MCP. Ces 44 Skills sont open source et publiés sur GitHub — une véritable bibliothèque, inspectable, et non un chiffre marketing.

Vos Skills sont des agents compétents depuis le premier jour — ils étaient simplement endormis, aucune IA ne pouvant les réveiller.

Imaginez un assistant qui travaille dans votre boutique depuis des années. Il connaît vos produits, vos habitués, vos mardis creux. Il pourrait faire tourner la moitié de vos opérations les yeux fermés. Mais jusqu'à présent, personne ne lui avait jamais confié les clés ni dit de s'y mettre. C'est exactement l'état dans lequel se trouvaient vos Skills GoodBarber.

La capacité a toujours été là. Produits, contenu, push, commandes — entièrement construits, pleinement opérationnels, attendant derrière un tableau de bord que vous seul pouviez cliquer. Ce qui manquait, c'était un moyen pour une IA de les atteindre et d'agir en votre nom.

Cette pièce manquante, c'est le signal de réveil. En rendant votre app opérable grâce au langage que votre IA parle à votre app, le serveur MCP de GoodBarber confie les clés à votre assistant endormi — et le guide complet du MCP GoodBarber détaille tout ce qu'il peut faire. Rien de nouveau n'est construit. Quelque chose qui existait déjà ouvre simplement les yeux.

La question n'est plus « que devrais-je construire ? » mais « qu'est-ce que je veux que mon assistant prenne en charge en premier ? »

Vous pouvez activer votre premier agent vertical dès aujourd'hui, sans code et sans nouvel outil — juste une connexion et un prompt.

Voici le chemin honnête, sans code.

Étape 1 — Choisissez une tâche que vous répétez. Pas toute votre activité. Une corvée. Rédiger le push hebdomadaire, ou mettre à jour une poignée de fiches produits. Commencer de façon ciblée, c'est la manière dont un agent vertical fonctionne le mieux.

Étape 2 — Connectez une IA que vous utilisez déjà. Si vous avez ChatGPT, notre guide expliquant comment utiliser ChatGPT avec GoodBarber pour faire tourner votre app sans code vous accompagne pas à pas avec des prompts à copier-coller. Pas de terminal, pas de fichiers de configuration. Vous préférez parler à votre app ? L'article de lancement sur la commande de votre app à la voix avec le serveur MCP de GoodBarber donne un premier aperçu de l'exploitation d'une app par la conversation.

Étape 3 — Donnez une instruction claire. Quelque chose comme : « Rédige la notification push de cette semaine annonçant notre vente du vendredi, puis montre-la-moi avant de la programmer. » En langage courant. Aucune syntaxe à apprendre.

Étape 4 — Révisez avant de publier. L'agent rédige ; vous lisez, ajustez et approuvez. Cette étape n'est pas optionnelle, et ce n'est pas une limitation — c'est ainsi que vous gardez le contrôle pendant que l'agent fait le gros du travail.

Étape 5 — Répétez et élargissez. Une fois que le push hebdomadaire vous paraît fiable, confiez la corvée suivante. Les fiches produits. Le calendrier éditorial. Vous élargissez à votre propre rythme.

Dix minutes pour votre première tâche déléguée. Aucun développeur requis, aucune plateforme vers laquelle migrer. L'agent dont vous aviez besoin se trouvait déjà à l'intérieur de votre app.

Faut-il être développeur pour utiliser un agent IA vertical avec GoodBarber ?

Non. Si vous savez écrire une phrase claire à un collègue, vous savez donner des instructions à un agent vertical. Le chemin sans code utilise des outils que vous possédez probablement déjà — comme ChatGPT — avec des prompts à copier-coller et des instructions en langage courant. Pas de terminal, pas de code, et aucune installation au-delà de la connexion de votre app. La tuyauterie technique est gérée pour vous ; votre rôle est de décrire ce que vous voulez et d'approuver le résultat.

Quels Skills GoodBarber fonctionnent avec MCP ?

Les Skills qui font tourner le cœur d'une app de contenu ou de commerce — la publication d'actus et de contenu, la gestion des produits e-commerce, le traitement des commandes, les codes promo, les campagnes push et la gestion des membres, entre autres. Chacun est une capacité précise qu'un agent peut opérer en votre nom, de la rédaction d'un article à la mise à jour de la livraison d'une commande. La bibliothèque open source de 44 Skills sur GitHub montre l'ensemble complet auquel un client IA peut accéder. De nouveaux Skills sont ajoutés à mesure que la plateforme grandit.

Est-ce différent de l'AI Extension Builder ?

Oui. L'AI Extension Builder vous aide à créer une nouvelle fonctionnalité pour votre app. Un agent vertical opère des fonctionnalités que vous avez déjà — il fait tourner vos Skills existants au lieu d'en construire de nouveaux. L'un ajoute des capacités à votre app ; l'autre met vos capacités actuelles au travail par la conversation. Ils sont complémentaires : construisez avec l'un, puis exploitez ce que vous avez construit avec l'autre.

Mon agent peut-il se tromper et publier un contenu erroné ?

Pas sans votre validation, si vous gardez un humain dans la boucle. « Prête pour les agents » signifie que l'IA peut rédiger et préparer des actions, mais vous révisez et approuvez avant que quoi que ce soit ne parte vers vos utilisateurs. Le flux de travail recommandé fait toujours en sorte que l'agent vous montre son travail d'abord — le push hebdomadaire, la fiche produit réécrite, l'article rédigé — pour que vous repériez tout problème avant publication. L'agent fait le gros du travail ; vous restez l'éditeur.

En quoi un agent vertical GoodBarber diffère-t-il d'un chatbot ?

Un chatbot répond aux questions ; un agent vertical accomplit des tâches. Un chatbot orienté client, comme notre extension RAG Chatbot, répond à vos utilisateurs à partir de votre contenu publié. Un agent vertical travaille côté opérateur — il agit à l'intérieur du tableau de bord de votre app, rédigeant des pushs, mettant à jour des produits et publiant des articles pour vous. L'un parle à vos clients ; l'autre effectue votre travail de back-office.

Dernière mise à jour : juin 2026

Une app, c'est facile. Dix, c'est un tapis roulant.

Chaque app cliente a son propre back-office, alors chaque matin se déroule la même boucle, dix fois de suite : se connecter, jeter un œil aux installations de la veille, vérifier que rien n'a cassé, voir si la dernière campagne a bougé quelque chose. Le temps d'avoir fait le tour, la moitié de la matinée est passée — et rien là-dedans n'était le travail pour lequel les clients vous paient. Les offres revendeur de GoodBarber sont conçues pour porter un portefeuille — 100 Go de stockage, des comptes collaborateurs illimités, jusqu'à 500 000 notifications push par mois — mais cette marge de manœuvre vous permet de prendre plus de clients ; elle ne vous rend pas les heures qu'ils dévorent. C'est cette partie-là qu'un agent vous retire des épaules.

La mécanique est plus simple qu'il n'y paraît. Chaque app GoodBarber expose son propre point d'accès MCP — une URL qui porte l'identifiant unique de cette app, et qui se trouve dans le back-office de l'app elle-même. Pour mettre tout un portefeuille devant un seul assistant, un revendeur ajoute le point d'accès de chaque client à un unique client IA, comme Claude. Cet assistant voit désormais les dix apps et peut agir sur chacune par son nom. Aucun portail à construire, aucun nouvel outil à apprendre — vous connectez des URL que vous possédez déjà.

L'isolation qui protège vos clients est précisément ce qui rend tout cela responsable à grande échelle. Chaque connexion est authentifiée via OAuth et délimitée à une seule app : un agent connecté à l'app A ne peut pas atteindre l'app B. L'agent travaille en travers de votre portefeuille, mais rien ne fuite latéralement d'un client à l'autre.

Vous n'ouvrez pas dix back-offices. Vous ouvrez une seule conversation.

Une seule demande : « Donne-moi la revue de ce matin sur tous mes clients. » Pour chaque app, l'agent récupère les mêmes chiffres — installations, utilisateurs actifs, pages vues, temps de session, répartition des appareils — et vous rend une synthèse, quelque chose comme :

• Riverside FC — stable ; sessions en hausse après le post sur les matchs de samedi.
• Atelier No.6 — calme : rien de publié depuis huit jours, pages vues en baisse.
• Coastline News — le push d'information de dernière minute d'hier a provoqué un pic de sessions net.

Vous lisez trois lignes, pas dix tableaux de bord — et le client qui a besoin de vous est déjà en haut de la liste.

Et cela ne s'arrête pas à la lecture. La même surface qui lit les chiffres peut agir dessus — mettre en file d'attente un push de réengagement pour l'app devenue silencieuse, ou lui programmer un nouvel article (la boucle éditoriale qu'un agent peut faire tourner à l'intérieur de n'importe quelle app) — sur votre simple accord.

Vingt minutes, dix clients, une tasse de café.

1. Récupérez l'URL MCP de chaque app. Elle se trouve dans le back-office de chaque app, et porte l'identifiant unique de celle-ci.
2. Ajoutez-les à un seul client IA. Collez chaque URL dans Claude (ou votre assistant) et connectez-vous une fois par app via OAuth.
3. Briefez la revue du matin. Demandez la synthèse multi-clients, puis approuvez les actions qu'il propose. C'est toute la boucle quotidienne.

C'est tout — aucune intégration à construire, aucun tableau de bord à câbler. Le portefeuille que vous gérez déjà devient un portefeuille que vous pouvez passer en revue dans une seule conversation.

L'agent ne remplace pas le chargé de clientèle. Il supprime la couche mécanique — les connexions, la collecte, les recoupements — pour que votre équipe passe sa matinée sur des décisions et des clients plutôt que sur des tableaux de bord.

C'est toujours vous qui définissez ce qu'est la « normale » pour chaque app. C'est toujours vous qui approuvez chaque action avant qu'elle ne parte ; la plateforme signale chaque écriture pour vérification et attend votre feu vert. Vous gardez la relation client, le jugement et la marge. Ce que vous arrêtez de dépenser, c'est l'heure qu'il fallait pour découvrir quel client avait besoin de vous aujourd'hui.

Voilà pourquoi c'est la manière la plus rentable d'exploiter la couche agent : elle transforme la croissance d'un portefeuille, jusque-là plafonnée par le nombre de collaborateurs, en quelque chose qu'un seul gestionnaire peut faire passer à l'échelle. Si vous êtes sur une offre revendeur, les points d'accès existent déjà — et comme les 44 Claude Skills qui encapsulent ces workflows sont open-source et redistribuables, vous pouvez les rebaptiser à vos couleurs et les remettre à vos propres clients sous votre nom.

Un seul agent IA peut-il gérer plusieurs apps GoodBarber ?

Oui. Chaque app GoodBarber a son propre point d'accès MCP, que l'on trouve dans son back-office. Ajoutez plusieurs points d'accès à un unique assistant IA et il pilote toutes les apps du portefeuille — chacune délimitée à elle-même.

Est-il sûr de connecter des apps clientes à un agent IA ?

Oui. Chaque connexion est authentifiée via OAuth et isolée à une seule app : un agent connecté à l'app d'un client ne peut pas atteindre celle d'un autre. Chaque modification est signalée pour vérification, et vous approuvez les actions avant qu'elles ne partent.

Que peut faire l'agent à travers un portefeuille ?

Il lit les statistiques de chaque app — installations, utilisateurs actifs, pages vues, temps de session, répartition des appareils — et fait ressortir ce qui a changé. Il peut aussi agir : programmer du contenu et envoyer des notifications push, app par app, depuis un seul endroit.

Les revendeurs peuvent-ils proposer cela en marque blanche à leurs propres clients ?

Oui. Les 44 Claude Skills qui encapsulent ces workflows sont open-source et redistribuables sous votre propre marque, sans obligation d'attribution — pour que la couche agent devienne une partie de votre offre, et pas seulement de votre boîte à outils.

Imaginez une association de protection des océans, deux personnes. L'une gère les opérations, l'autre le terrain. À elles deux, elles font aussi tourner une app : un fil d'actualité, une liste de causes, un agenda d'événements, des notifications push vers quelques milliers de soutiens.

Chaque semaine, la même routine. Rédiger le compte rendu du nettoyage du week-end, le mettre en forme, choisir une catégorie, décider de ce qui se publie maintenant et de ce qui attend la date de campagne, ajouter le prochain rendez-vous à l'agenda, programmer un push pour que les gens viennent. Rien de difficile là-dedans. Mais tout cela prend du temps — pris sur la cause. Les outils no-code ont rendu chaque étape plus simple ; ils n'ont jamais rendu la personne optionnelle. C'est précisément cette partie-là qu'un agent change.

Faire tourner votre app comme une rédaction, cela veut dire que vous arrêtez de manipuler le CMS à la main pour commencer à briefer un rédacteur en chef qui le fait à votre place. Vous décrivez la semaine en langage courant ; l'agent l'exécute à travers votre app ; vous relisez.

Tout cela fonctionne parce que chaque app GoodBarber est agent-ready : elle expose ses opérations via un serveur Model Context Protocol public — 150 au total, dont 61 pour le seul CMS — pour qu'un assistant que vous utilisez déjà, comme Claude, puisse gérer votre contenu par la conversation au lieu que vous cliquiez dans un tableau de bord. Alors nous avons essayé. Pas sur une maquette — sur une app en conditions réelles.

Nous avons connecté Claude à une app de démo réelle, celle d'une association de protection des océans, et nous lui avons donné un seul brief :

« Publie maintenant le compte rendu du nettoyage de Calvi de ce week-end. Prépare notre article pour la campagne Plastic Free July et programme-le pour le 1er juillet à 8 h. Et mets le nettoyage entre bénévoles du 21 juin à l'agenda. »

Voici ce qu'il a fait, dans l'ordre.

Il a d'abord appris à connaître la rédaction. Avant d'écrire un mot, l'agent a listé les rubriques de contenu de l'app — À propos, Nos combats — il a affiché l'agenda des événements et lu les articles existants. Un agent sur le point de publier en votre nom prend ses repères comme l'aurait fait un nouveau rédacteur.

Il a publié le compte rendu — en ligne. L'article sur le nettoyage est parti dans Nos combats, avec un chapeau et des métadonnées SEO, statut publié. En ligne immédiatement, à sa propre URL, dans le fil que les soutiens étaient déjà en train de lire.

Il a programmé l'article de campagne. L'article Plastic Free July, lui, n'est pas passé en ligne. L'agent l'a réglé sur programmé avec une date de publication au 1er juillet, 8 h. Il attend désormais dans la file d'attente et se publiera tout seul le matin de la campagne — personne n'a à se souvenir d'appuyer sur un bouton à 8 h.

Il a mis l'agenda à jour. Le nettoyage entre bénévoles du 21 juin a atterri dans le calendrier des événements avec son horaire de début, sa plage de trois heures et son lieu à Calvi — venant se glisser entre le gala, la course de kitesurf et le reste de la saison.

Et la plateforme l'a obligé à prouver son travail. Chaque écriture est revenue signalée pour vérification, alors l'agent a relu la file des articles programmés et l'article publié avant de faire son rapport.

Une phrase de plus suffit à boucler la boucle : « programme le push de lancement pour le 1er juillet à 8 h. » La même surface MCP envoie les notifications — une diffusion avec une heure d'envoi programmée — pour que la campagne se publie et que les soutiens en soient avertis d'un même mouvement.

Trois phrases de brief. Une semaine de calendrier éditorial, réglée.

C'est là que l'inquiétude se loge en général : si l'agent fait tout ça, qu'est-ce qu'il me reste à moi ? La réponse, c'est justement la partie qui a toujours été le vrai métier.

L'agent prend la mécanique — la mise en forme, le timing, la file d'attente, le push. Vous gardez le jugement — ce qui mérite d'être publié, ce que dit la campagne, quel événement compte. Cette répartition n'est pas une simple promesse, elle est imposée : la plateforme signale chaque écriture pour vérification, et vous pouvez demander à l'agent de tout préparer en brouillon, pour que vous l'approuviez avant qu'un seul élément ne passe en ligne. Rien ne se publie sans votre feu vert.

Ce n'est donc pas « l'agent fait tourner l'app à votre place ». C'est l'agent qui fait, pendant que vous, vous décidez. Vous cessez d'être celui qui clique sur publier ; vous restez celui qui dit ce qui se publie. Pour une association de deux personnes, c'est toute la différence entre une semaine passée dans l'outil et une semaine passée sur la cause.

Si vous gérez une app de contenu, vous avez déjà la rédaction. Pour lui adjoindre un rédacteur en chef : connectez votre assistant IA au point d'accès MCP de votre app — l'adresse se trouve dans votre back-office — ou partez des 44 Claude Skills prêtes à l'emploi qui encapsulent ces workflows. Puis briefez-le comme vous briefieriez un collègue.

Envie de le voir d'abord à l'œuvre sur votre propre contenu ? Lancez un essai gratuit d'une Content App, connectez un assistant, et donnez-lui une semaine pour faire ses preuves.

Comment automatiser le calendrier éditorial de mon app ?

Connectez un assistant IA compatible MCP (comme Claude) au point d'accès MCP de votre app GoodBarber, puis briefez-le en langage courant : ce qu'il faut publier maintenant, ce qu'il faut programmer, ce qu'il faut mettre à l'agenda, et quand pousser une notification. L'agent appelle les mêmes opérations CMS que le back-office et exécute la semaine à votre place.

Un agent IA peut-il programmer des articles de blog et des notifications push ?

Oui. Via le serveur MCP, un agent peut créer un article ou un événement avec une date de publication future — il reste hors du fil jusque-là et se publie tout seul — et mettre une notification push en file d'attente avec une heure d'envoi, pour qu'une campagne et son alerte passent en ligne ensemble.

Qu'est-ce qu'un workflow éditorial sous MCP ?

C'est le fait de faire tourner le travail éditorial de votre app — publication, programmation, agenda, push — via le Model Context Protocol plutôt qu'à la main. Vous donnez des instructions à un assistant IA ; il appelle directement les opérations CMS de l'app ; vous relisez et vous approuvez. Plus de copier-coller entre un brouillon et un tableau de bord.

Une IA peut-elle publier dans le CMS d'une app mobile sans code ?

Oui. GoodBarber expose 61 opérations CMS via MCP — créer et mettre à jour des articles, construire et réorganiser leur contenu, gérer des événements, manipuler photos et vidéos — toutes appelables en langage naturel par un assistant, délimitées à votre app, sans code et sans intégration séparée à développer.

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.

• Même philosophie, exécution différente. Les deux permettent de configurer des fonctionnalités toutes faites plutôt que de bâtir une base de données — mais ils s'écartent sur la qualité des apps produites, ce qui est compris dans l'abonnement et la structure des tarifs.
• De vraies apps natives. GoodBarber compile de vraies apps natives, en Swift (iOS) et Kotlin (Android), plus une PWA, depuis une seule configuration. BuildFire annonce des « native mobile apps » mais ne documente pas publiquement la façon dont ses apps sont construites.
• Tout compris contre budget de plugins. GoodBarber comprend l'hébergement, la base de données, les notifications push et les paiements (0 % de commission) dans l'abonnement. Chez BuildFire, une bonne partie des fonctions se débloque via des quotas de plugins par palier.
• Conformité et données. GoodBarber héberge les données exclusivement en Europe (RGPD, BDSG) et intègre la confidentialité dès la conception — un vrai atout pour le marché européen et les secteurs réglementés. BuildFire, de son côté, met en avant une certification SOC 2, surtout attendue par les services achats des grands comptes.
• Une économie de revente opposée. L'offre Reseller de GoodBarber est un forfait fixe pour un nombre illimité d'apps ; BuildFire facture un abonnement plateforme plus un montant par app active.

Dans cette série, nous construisons la même app sur chaque plateforme, pour ancrer la comparaison dans un vrai projet plutôt que dans une liste de cases à cocher. AURORA est une app de guide de voyage haut de gamme. Il lui faut :

• une navigation de contenu en plusieurs rubriques ;
• un design de marque sur mesure — couleurs, typographie, logo ;
• des comptes utilisateurs et de l'authentification ;
• des notifications push ;
• un CMS éditorial pour gérer le contenu ;
• une intégration météo / données en temps réel ;
• un chatbot IA ;
• la publication sur l'App Store et Google Play.

Le cahier des charges est volontairement complet : assez de contenu pour exiger une vraie structure, et assez de fonctions différentes pour mettre chaque plateforme à l'épreuve sur toute son étendue.

GoodBarber : intégré dès la conception, natif par défaut

Le pari de GoodBarber : la plupart des gens qui créent une app de contenu ou de vente n'ont aucune envie de devenir architectes logiciels. La plateforme livre donc des fonctionnalités complètes et déjà pensées — navigation, CMS, push, e-commerce, comptes utilisateurs — qu'on configure au lieu de les assembler. Ce qui la distingue dans cette catégorie, c'est son niveau d'exigence : des apps compilées en natif et un back-office conçu comme un produit à part entière, pas comme une simple interface d'administration. La promesse : une app native de qualité professionnelle, qui reste facile à faire vivre et à faire évoluer pendant des années — pour environ un dixième du coût total d'un développement sur mesure.

BuildFire : une plateforme d'apps pilotée par les plugins

BuildFire se positionne autour des « native mobile apps as a business advantage » et de la promesse de « build, publish, and manage an iOS & Android app ». Sa vraie force, c'est l'étendue : une large marketplace de plugins (prise de rendez-vous, fil communautaire, coupons, annuaire, drip content…), un SDK et une API pour les développeurs qui veulent créer leurs propres plugins, et une équipe de services pour ceux qui préfèrent déléguer entièrement la fabrication. Avec plus de 5 000 apps à son actif et une note de 4,7/5 sur G2, la maturité et la richesse fonctionnelle sont bien réelles. C'est un choix crédible — en particulier pour ceux qui apprécient l'écosystème de plugins et la possibilité de payer pour un développement sur mesure.

BuildFire gère sans peine l'ossature d'AURORA. On assemble les écrans, on configure les plugins, on règle la navigation et on applique la marque dans un éditeur visuel avec aperçu en temps réel — l'approche intégrée tient sa promesse, et c'est précisément ce que saluent les avis. « The ease and quick ability to design, build and publish an app is second to none », écrit un client sur Capterra (un pasteur). Pour du contenu en plusieurs rubriques, les plugins de dossiers et de contenu couvrent bien la structure éditoriale d'AURORA.

Contenu et CMS. Les plugins de contenu (Directory, Document Management, Drip Content) épousent proprement les rubriques d'AURORA. C'est le terrain de prédilection de BuildFire.

Notifications push. Incluses, avec des quotas mensuels qui augmentent selon le palier — de 100 000 sur Standard jusqu'à 300 000 sur Scale.

Le commerce, si vous en avez besoin. AURORA ne vend rien, mais beaucoup de projets, eux, vendent — et c'est là que le modèle de BuildFire se resserre. Les achats intégrés sont comptés : un seul sur le palier Growth (315 $/mois), illimités seulement sur Scale (440 $/mois). Un projet où la vente pèse lourd se retrouve vite poussé vers les paliers supérieurs.

Design. Vous disposez de templates, de thèmes et de nombreuses options de personnalisation pour habiller AURORA aux couleurs de la marque.

Chatbot IA. BuildFire a récemment lancé une IA côté gestion — « BuildFire is now live in ChatGPT », via une intégration MCP — pensée pour gérer l'app. En revanche, un chatbot IA destiné aux utilisateurs finaux, intégré dans AURORA, n'est pas documenté comme une fonction native.

Publication. BuildFire publie sur les deux stores et propose des services pour prendre en charge les soumissions.

Deux réserves reviennent dans les retours d'utilisateurs. D'abord le coût : la note Trustpilot de BuildFire s'établit à 2,8/5 sur plus de 170 avis, et plusieurs trouvent les tarifs « way too high » au regard d'outils comparables. Ensuite la fiabilité : « All the information in my app disappeared and literally nobody has been able to give a competent reply as to what happened », rapporte un avis Capterra. Quant au support, les signaux sont partagés — salué par les uns, critiqué par les autres (« takes days on average to respond »).

Comme les deux outils partagent la même méthode, la question n'est pas de savoir si AURORA peut être construite — les deux la construisent. La différence se joue dans les couches du dessous.

Les apps produites. GoodBarber compile AURORA en une app native Swift pour iOS et une app native Kotlin pour Android — plus une PWA — depuis une seule et même configuration. Ce sont trois moteurs de génération à part entière : le natif est ce que la plateforme compile dès le palier Premium, et non une couche ajoutée par-dessus une app web. Pour une app de voyage, où la fluidité du défilement, la performance des cartes et l'intégration au système font l'expérience, la façon dont l'app est construite n'a rien d'anecdotique.

La mise en ligne. GoodBarber propose un service de publication géré, GBTC (GoodBarber Takes Care), qui prend en charge la soumission sur l'App Store et Google Play à votre place. Les chiffres parlent : Apple rejette environ 42 % des premières soumissions, et l'équipe GBTC parvient à faire accepter 91 % de ces apps rejetées. Un accompagnement humain jusqu'aux stores existe donc des deux côtés.

Ce qui est compris — et l'addition. C'est l'avantage du tout-inclus, et il est concret. Chez GoodBarber, l'hébergement, la base de données, les notifications push et l'encaissement des paiements sont compris dans un seul abonnement, avec 0 % de commission sur les transactions e-commerce — ainsi, le jour où un projet a besoin de vendre, la plateforme ne prélève rien. L'Extension Store comporte bien des extensions payantes (à côté de nombreuses gratuites) pour des besoins pointus — tout n'est donc pas gratuit — mais le socle dont chaque app a besoin pour fonctionner est, lui, dans l'abonnement de base. Chez BuildFire, une plus grande part de ces fonctions reste conditionnée à des quotas de plugins par palier et au décompte des achats intégrés.

La conformité. GoodBarber héberge toutes les données de ses clients et de leurs utilisateurs exclusivement sur des serveurs situés en Europe (socle RGPD et BDSG), n'embarque dans ses apps que le code réellement utilisé (aucun SDK inutile dans le binaire), intègre une plateforme de gestion du consentement conforme à l'IAB TCF v2 dans son Privacy Center, et permet de déclarer une app conforme « Apps for Kids » dès la conception. De son côté, BuildFire avance sa certification SOC 2 — une exigence des services achats dans certaines organisations. Les deux mettent simplement l'accent sur des terrains différents : souveraineté des données et privacy by design d'un côté, attestation pour grands comptes américains de l'autre.

Et l'échelle de GoodBarber n'a rien de théorique : toutes les quatre secondes, une app créée avec la plateforme est téléchargée sur l'App Store ou Google Play. GoodBarber compte des clients actifs dans 152 pays et existe depuis 2011.

Deux philosophies bien réelles se cachent derrière ce tableau. BuildFire mise sur un large catalogue de plugins et une formule clés en main payante. GoodBarber mise sur un ensemble plus resserré où tout est compris, avec de vraies apps natives et des tarifs publics. Aucun n'a « plus raison » que l'autre — ils sont taillés pour des profils différents.

Le reproche qui revient le plus souvent dans les avis sur BuildFire, c'est le prix : 2,8/5 sur Trustpilot, des tarifs que plusieurs utilisateurs jugent « way too high » au regard d'outils comparables. Mais au-delà du montant affiché, c'est surtout une question de structure.

Chez BuildFire, l'addition grandit avec ce que vous activez : les achats intégrés sont comptés (un seul jusqu'au palier Growth, illimités seulement sur Scale), certaines fonctions se débloquent par paliers de plugins, et les offres revente et entreprise se négocient sur devis. On sait par où l'on commence, rarement où l'on s'arrête.

GoodBarber fait le choix inverse : un abonnement, des tarifs publiés, et l'essentiel compris dedans — hébergement, base de données, push, encaissement des paiements, sans commission sur les transactions e-commerce. Vous savez ce que vous payez avant de vous lancer, et le montant ne grimpe pas parce que votre app marche bien. Pour une agence ou un revendeur qui gère un parc d'apps, cette prévisibilité finit par peser lourd dans la marge.

• Vous voulez une formule clés en main : une équipe qui développe, designe et soumet l'app à votre place. GoodBarber, lui, est 100 % en autonomie et ne vend pas de prestation de développement sur mesure.
• Votre service achats exige une certification SOC 2 affichée : BuildFire la met en avant, là où GoodBarber communique plutôt sur l'hébergement des données en Europe et le privacy by design.
• Vous préférez un modèle de revente au coût par app active, avec un ticket d'entrée bas et des conditions négociées avec un commercial, plutôt qu'un forfait fixe.
• Vous tenez spécifiquement à un éditeur basé aux États-Unis et à un support sur les fuseaux horaires américains.

• Vous comptez faire vivre l'app dans la durée — publier du contenu, envoyer des push, suivre les statistiques — et vous voulez un back-office structuré, pas seulement un outil de création.
• Vous avez besoin de vraies apps natives (Swift et Kotlin compilés) et d'une PWA, depuis une seule configuration.
• Vous voulez un abonnement tout compris — hébergement, base de données, push, paiements — avec des tarifs publics et sans commission par transaction.
• Vos clients ou vos utilisateurs sont en Europe ou dans des secteurs réglementés, et l'hébergement des données dans l'UE compte pour vous.
• Vous êtes une agence, un freelance ou un revendeur qui se constitue un parc d'apps et veut une économie prévisible, à forfait fixe : apps illimitées, 0 % de commission, marque blanche par défaut.

GoodBarber et BuildFire sont d'accord sur le plus difficile : créer une app ne devrait pas obliger à devenir ingénieur. Ils divergent sur le niveau d'exigence qu'ils placent au-dessus de ce raccourci. BuildFire mise sur l'étendue de son catalogue et sur une formule clés en main. GoodBarber mise sur des apps compilées en natif, un abonnement tout compris à prix prévisible et sans commission par transaction, et des données conservées en Europe — une plateforme pensée non seulement pour lancer une app, mais pour la garder conforme et facile à faire évoluer pendant des années.

Si votre projet doit durer — comme AURORA —, le vrai critère de choix, c'est la solidité du résultat dans le temps, pas la rapidité du premier jet. Lancez un essai gratuit de GoodBarber et construisez votre propre AURORA de bout en bout : configurez votre app, publiez sur les deux stores, et jugez le résultat sur votre écran avant de décider.

• GoodBarber vs Bubble
• GoodBarber vs Base44
• GoodBarber vs Glide
• GoodBarber vs Rork
• GoodBarber vs Emergent
• GoodBarber vs FlutterFlow
• GoodBarber vs Adalo
• Les 10 meilleurs créateurs d'app No-Code en 2026

BuildFire crée-t-il de vraies apps natives ?

BuildFire annonce des « native mobile apps » et publie sur l'App Store et Google Play, mais ne documente pas publiquement la façon dont ses apps sont construites. GoodBarber, lui, compile de vraies apps natives en Swift (iOS) et Kotlin (Android) — le natif n'est pas une option ajoutée, c'est le mode de production par défaut — plus une PWA depuis la même configuration.

BuildFire est-il plus cher que GoodBarber ?

Les formules en autonomie de BuildFire démarrent à 165 $/mois, et plusieurs avis jugent ses tarifs élevés par rapport à des outils comparables (Trustpilot 2,8/5). GoodBarber démarre à 30 €/mois, avec des apps natives iOS et Android dès 55 €/mois, et publie tous ses tarifs.

Lequel convient le mieux à une agence qui gère plusieurs apps ?

L'offre Reseller de GoodBarber est un forfait fixe couvrant un nombre illimité d'apps, en marque blanche et sans commission — le coût ne bouge pas quand le parc grandit. BuildFire facture un abonnement plateforme plus un montant par app active, et propose en plus une équipe de services si vous préférez déléguer la fabrication.

Qu'est-ce qui est compris dans l'abonnement de chaque plateforme ?

GoodBarber comprend l'hébergement, la base de données, les notifications push et l'encaissement des paiements (0 % de commission) dans un seul abonnement — certaines extensions spécialisées restent payantes. Chez BuildFire, une bonne partie des fonctions se débloque via des quotas de plugins par palier et des achats intégrés comptés.

Les deux plateformes peuvent-elles ajouter un chatbot IA pour les utilisateurs de l'app ?

GoodBarber propose une IA côté back-office, un serveur MCP et un chatbot IA destiné aux utilisateurs finaux. L'IA de BuildFire reste pour l'instant côté gestion (via une intégration ChatGPT/MCP) ; un chatbot intégré dans l'app pour l'utilisateur final n'est pas documenté.

Du 11 juin au 19 juillet 2026, 48 équipes et des dizaines de matchs vont rythmer six semaines d'attention mondiale. Pendant ce temps, votre communauté suit les scores sur cinq autres applications. Aucune ne porte votre nom.

Une section calendrier et résultats : exactement le genre de page qui, hier encore, demandait un développeur. Aujourd'hui, vous la décrivez, et elle se construit. Voici comment.

Une seule page, qui défile :

• Les matchs déjà joués d'abord, les matchs à venir ensuite. À l'ouverture, la page se positionne directement sur le prochain match : le dernier résultat juste au-dessus, la suite juste en dessous.
• Regroupés par jour, avec un titre de date clair.
• Score final pour les matchs terminés, heure de coup d'envoi au fuseau horaire local du visiteur pour les matchs à venir.
• Une carte arrondie par match, avec les deux équipes et leurs drapeaux, et une mise en avant discrète du prochain match.
• Un design sporty, mobile-first.

Et surtout : des données réelles, jamais inventées. Pendant le chargement, des placeholders ; en cas d'échec, un message clair avec un bouton « Réessayer » — pas de faux scores.

Deux façons d'y arriver.

Idéale pour obtenir un résultat rapidement.

1. Dans votre back-office GoodBarber, ajoutez une section et choisissez « Créer avec l'IA » (l'AI Extension Builder).
2. Ouvrez la bibliothèque d'exemples.
3. Sélectionnez l'exemple « Coupe du Monde 2026 — Calendrier & Résultats ».
4. L'assistant génère le code et affiche le résultat en direct, dans le contexte de votre app.

Pas de configuration, pas d'API à brancher, pas une ligne de code. L'exemple embarque déjà le bon prompt — celui qu'on décortique juste en dessous. Vous pouvez le garder tel quel, ou l'ajuster aux couleurs de votre app.

C'est le scénario « un clic » : la section existe en moins d'une minute. Mais comprendre comment l'exemple est écrit, c'est ce qui vous permettra ensuite d'en créer d'autres — pour votre championnat national, votre ligue locale, ou les matchs de votre seul club.

Voici le prompt exact qui se cache derrière l'exemple. Il tient en quelques lignes, et chaque ligne a une raison d'être.

Ce qui rend ce prompt fiable, ce sont cinq réflexes simples. Ce sont eux qu'il faut retenir, bien plus que ce cas précis.

1. Décrire le résultat, pas le code. On ne dit jamais à l'assistant comment faire. On lui dit ce que l'utilisateur doit voir : une liste qui défile, les matchs joués d'abord, l'ouverture calée sur le prochain match. Vous décrivez une expérience ; l'assistant écrit le code.

2. Pointer vers une vraie source de données — et la respecter. Le prompt donne un lien de données en direct et une instruction non négociable : Utilise des données réelles et en direct — n'invente jamais de scores ni de matchs., utilise-le tel. C'est le garde-fou anti-hallucination. À chaque ouverture, la page lit la source réelle ; elle n'invente jamais un score. (Pour un autre événement, c'est cette ligne que vous changez : votre championnat, votre ligue, votre club.)

3. Anticiper les cas particuliers. En 2026, beaucoup de matchs des phases finales n'ont pas encore d'équipes attribuées — vous verrez passer des libellés du type « Group A Winner ». Le prompt l'a prévu : afficher ces matchs sans drapeau, et surtout qu'un match inhabituel ne casse jamais le reste de la liste. Une seule donnée bancale ne doit pas faire tomber toute la page.

4. Soigner les états vides et les erreurs. Pendant le chargement : des placeholders. En cas d'échec : un message clair et un bouton « Réessayer ». Jamais de fausses données pour combler un trou. C'est ce qui sépare une vraie section d'une démo qui plante en réunion.

5. Cadrer le style en une phrase. Mobile-first, cartes arrondies. L'assistant a besoin d'une direction artistique courte et nette, pas d'un cahier des charges.

Ces cinq réflexes ne valent pas que pour le football. Reprenez-les pour un calendrier d'événements, une liste de produits, un tableau de scores interne : c'est la même grammaire de prompt.

Générer du code avec une IA, beaucoup d'outils le font. La différence tient à où atterrit ce code.

Ici, l'assistant n'écrit pas dans le vide. La section générée s'intègre directement à votre app : l'hébergement est inclus, elle adopte le système Smart Design de votre application, et elle est embarquée dans votre app — sur iOS, Android et en PWA — puis distribuée sur les stores comme le reste. Le résultat n'est pas un bout de code à copier-coller : c'est une section vivante dans une vraie app.

Et ce n'est qu'un début : une section construite ainsi peut aussi puiser dans les capacités de la plateforme — géolocalisation, contenu, notifications push, etc. Notre exemple s'en passe — il lit directement sa source de scores — mais vous pouvez construire des pages qui vont beaucoup plus loin dans l'intégration à votre app.

C'est aussi ce qui explique la promesse historique de GoodBarber — des apps professionnelles sans écrire une ligne de code, depuis 2011, avec aujourd'hui un téléchargement toutes les 4 secondes dans 152 pays. L'AI Extension Builder prolonge cette logique : quand une fonctionnalité manque au catalogue de 190+ extensions, vous ne dépendez plus d'un développeur — vous la décrivez, et elle s'ajoute à votre app.

La Coupe du Monde 2026 dure six semaines. La fenêtre d'attention, elle, est ouverte maintenant.

Ouvrez l'AI Extension Builder dans votre back-office (ou démarrez un essai gratuit), choisissez l'exemple « Coupe du Monde 2026 » dans la bibliothèque, et publiez votre section calendrier et résultats avant le prochain coup d'envoi. Puis ré-utilisez les cinq réflexes du prompt pour la prochaine fonctionnalité qui manque à votre app.

Les résultats sont-ils à jour ?

À chaque ouverture de la page, la section lit une source de données en direct. Les scores et les horaires affichés sont ceux renvoyés par cette source — jamais des données inventées.

Faut-il savoir coder ?

Non. Vous décrivez la section en langage naturel ; l'assistant génère le code et l'affiche en direct. Vous pouvez ensuite affiner le prompt, ou éditer le code directement si vous le souhaitez.

Puis-je l'adapter à un autre événement ou à mon championnat ?

Oui. La structure du prompt est réutilisable : changez la source de données et le style pour couvrir une autre compétition, une ligue locale ou les seuls matchs de votre club.

Vous gérez une app. Chaque semaine, vous ouvrez un tableau de bord, vous publiez deux ou trois choses, vous programmez un push, vous regardez les chiffres de la veille, vous corrigez un prix. Ce tableau de bord est devenu plus convivial d'année en année — c'est toute la promesse du no-code, et elle a tenu. Des millions de personnes gèrent aujourd'hui des apps professionnelles sans écrire une ligne de code.

Mais celui qui pilote est en train de changer. Les gens commencent à confier cette routine hebdomadaire à un assistant IA : « Publie ces trois articles, programme un push pour chacun, et dis-moi quelle rubrique a perdu des lecteurs la semaine dernière. » L'assistant, lui, ne réclame pas un tableau de bord plus convivial. Il réclame une interface qu'il peut appeler.

Ce simple fait rebat toutes les cartes. L'interface qui gagnera la prochaine décennie n'est pas celle que les humains préfèrent. C'est celle qu'un agent sait conduire.

Une app est agent-ready lorsqu'un agent IA externe peut la piloter pour le compte de son propriétaire — lire ses données et y effectuer de vraies actions — via une interface appelable par une machine, en toute sécurité et dans les limites fixées par ce propriétaire.

Relisez cette phrase, parce qu'elle prend le contre-pied de l'évidence. Une app sur laquelle on a greffé un chatbot n'est pas agent-ready. Une app dotée de « fonctionnalités IA » à l'intérieur de son propre tableau de bord ne l'est pas non plus. Ça, c'est de l'IA que vous utilisez à l'intérieur de l'app. Agent-ready, c'est l'inverse : votre app devient utilisable par l'IA avec laquelle vous travaillez déjà — Claude, ChatGPT, Cursor, quel que soit l'assistant qui rythme vos journées.

Agent-ready, ce n'est pas de l'IA dans votre app. C'est votre app dans votre IA.

« Agent-ready » est en train de devenir une étiquette qu'on colle un peu partout. Voici donc un test concret. Une app ne passe le test que si les cinq conditions sont réunies :

1. Une interface appelable. Des opérations exposées comme des fonctions qu'un agent invoque — pas un écran qu'il doit déchiffrer.
2. Un standard ouvert. Elle parle le Model Context Protocol (MCP), pour que n'importe quel assistant se connecte sans développement sur mesure à chaque fois.
3. Un accès authentifié et délimité. L'agent se connecte au nom du propriétaire (OAuth) et n'agit que dans les limites fixées par celui-ci.
4. De vraies opérations, pas seulement de la lecture. Elle peut publier, programmer, notifier, vendre, faire un bilan — pas seulement récupérer des données.
5. Vérifiable et réversible. L'agent confirme avant d'agir et rend compte après ; l'humain reste dans la boucle.

S'il en manque une seule, vous n'avez pas une app agent-ready. Vous avez une app sur laquelle on a collé une étiquette « IA ».

Lundi, 9 h. Vous dites à votre assistant : « Publie les trois brouillons dans mon dossier, programme un push de lancement pour chacun, et dis-moi quelle rubrique a perdu des lecteurs la semaine dernière. » Quatre-vingt-dix secondes plus tard, il vous fait son rapport : trois articles en ligne, trois pushes en file d'attente, une rubrique signalée comme en perte de vitesse — avec, déjà rédigé, un post pour la relancer. Vous n'avez pas ouvert le back-office.

Ce n'est pas un concept. Chaque app GoodBarber tourne derrière un serveur Model Context Protocol public — le standard ouvert du test ci-dessus — qui expose les opérations dont un agent a besoin, sous OAuth, et délimité à une seule app. Nous l'avons présenté comme un pilotage à la voix et par agent, et il couvre déjà toute la boucle : un agent peut gérer votre contenu par la conversation, le programmer, déclencher un push, gérer un catalogue, lire les sessions de la semaine passée. En bref : 150 opérations, 44 Claude Skills prêtes à l'emploi sur GitHub, et vous connectez l'assistant que vous payez déjà — nous ne revendons pas le modèle.

Les cinq critères ne sont donc pas une liste de souhaits ici ; ils sont le cahier des charges. Et vous restez aux commandes : l'agent vérifie avant d'agir, et vous relisez ce qu'il a fait.

Nous n'avons pas greffé de l'IA sur le produit. Nous avons fait du produit quelque chose qu'une IA peut faire tourner.

Deux phénomènes ont convergé. Les assistants capables de tenir un objectif et d'appeler des outils sont devenus grand public. Et le protocole qui les relie aux vrais logiciels — MCP — est devenu un standard de fait dans toute l'industrie. Séparément, chacun était intéressant. Ensemble, ils renversent une habitude.

En 2026, celui qui choisit un logiciel peut désormais poser une question impensable en 2023 : « Est-ce que mon agent peut faire tourner ça ? » De plus en plus, c'est la première qu'il pose. Un logiciel qui répond non donnera vite la même impression qu'un logiciel sans API il y a dix ans : utilisable, mais du mauvais côté de l'histoire.

Cela ne pèsera pas du jour au lendemain pour tout le monde, et nous n'allons pas prétendre le contraire. Une petite boutique avec cinq produits a le temps. Mais le sens de la marche est à voie unique : une app ne devient jamais moins pilotable, et les équipes qui délèguent leur routine dès aujourd'hui sont celles qui auront le plus de temps regagné dans un an.

Si vous gérez une app GoodBarber, la couche agent existe déjà — vous vous y connectez, vous ne la construisez pas. Découvrez les opérations exactes qu'un agent peut exécuter sur la page MCP, pointez votre assistant vers votre app, et briefez-le comme un collègue. Si vous préférez partir d'une recette toute prête, les workflows sont packagés sous la forme d'un agent IA que vous pouvez piloter dès aujourd'hui.

L'app que vous gérez à la main aujourd'hui, c'est l'app que votre agent fera tourner l'an prochain. La seule question qui vaille la peine d'être posée maintenant, c'est de savoir si la vôtre est prête.

Que signifie « agent-ready » pour une app ?

Une app est agent-ready lorsqu'un agent IA externe — comme Claude, ChatGPT ou Cursor — peut la piloter pour le compte de son propriétaire : lire ses données et y effectuer de vraies actions via une interface appelable par une machine, en toute sécurité et dans les limites fixées par ce propriétaire. C'est toute la différence entre un logiciel dans lequel une personne clique et un logiciel qu'un agent peut conduire.

Une app agent-ready, est-ce la même chose qu'avoir un chatbot IA ?

Non — les deux pointent dans des directions opposées. Un chatbot, c'est de l'IA que vous utilisez à l'intérieur de votre app. Agent-ready, cela veut dire que votre app peut être utilisée par l'IA avec laquelle vous travaillez déjà, depuis l'extérieur. Une app peut avoir un chatbot sans pour autant être agent-ready, et l'inverse est tout aussi vrai.

Qu'est-ce que le Model Context Protocol (MCP) ?

MCP est un standard ouvert qui permet aux assistants IA de se connecter à des logiciels externes et d'en appeler les opérations comme des outils. Parce qu'il est partagé, n'importe quel assistant compatible MCP peut piloter une app équipée de MCP sans intégration développée sur mesure à chaque fois. C'est le connecteur qui rend « agent-ready » concret plutôt que du cousu main.

Qu'est-ce qui rend les apps GoodBarber agent-ready ?

Chaque app GoodBarber se trouve derrière un serveur MCP public qui expose 150 opérations, authentifiées via OAuth et délimitées à chaque app, plus 44 Claude Skills prêtes à l'emploi sur GitHub. Un agent peut publier et programmer du contenu, envoyer des notifications, gérer un catalogue et lire les statistiques — et vous connectez l'IA que vous payez déjà, sans aucune infrastructure supplémentaire à héberger.

Agent-ready, est-ce que ça veut dire que l'IA fait tourner mon app sans moi ?

Non. Agent-ready signifie que la porte est ouverte pour qu'un agent agisse en votre nom — pas que vous avez quitté la pièce. C'est vous qui concevez l'app, qui fixez les règles et qui relisez ce que l'agent fait. L'agent confirme avant d'agir et rend compte après.

Si vous tenez une boutique en ligne ou un commerce de proximité, vous savez déjà quelle image votre marque doit renvoyer. La vision n'est pas le plus difficile. Le plus difficile, c'est de la traduire en une application soignée, écran après écran, quand le design n'est pas votre métier. Quelles couleurs associer ? Quelle taille donner aux titres ? Comment rester cohérent d'un écran à l'autre ? Pour la plupart des marchands, c'est là que le projet s'enlise : non pas dans la construction de l'application, mais dans sa conception.

Partir d'une page blanche a des airs de liberté créative. C'est le plus souvent un frein. Ce qui fait vraiment avancer un projet, c'est un point de départ crédible : un rendu qui a déjà belle allure, prêt à être adapté à votre marque et à votre catalogue plutôt qu'à assembler pièce par pièce.

Un thème GoodBarber est précisément pensé pour cela. Ce n'est pas un cadre vide à remplir, mais une direction artistique aboutie : la palette de couleurs, la typographie, les images et le ton sont choisis pour fonctionner ensemble, afin que votre application donne l'impression d'une vraie marque, cohérente dès le premier écran.

C'est ce qui distingue un thème d'un simple modèle. Un modèle vous donne une structure et vous laisse gérer tout l'habillage. Un thème prend les décisions de design à votre place, avec le goût d'un professionnel, et les applique de manière cohérente sur chaque écran et chaque appareil, du mobile à la tablette.

Au cœur de tout cela, le système Smart Design de GoodBarber garde un résultat soigné quoi que vous changiez. Le contraste, l'échelle typographique et les espacements sont gérés en coulisses : vos choix restent créatifs, l'application reste professionnelle. Rien de tout cela n'est nouveau dans la bibliothèque. Les derniers thèmes ne font que l'étendre à de nouveaux styles et de nouveaux usages.

Les thèmes ci-dessous sont les dernières nouveautés de la bibliothèque GoodBarber. Ce sont des exemples, pas le catalogue complet : un échantillon choisi pour montrer à quel point une boutique GoodBarber peut être variée. Chacun forme un univers visuel complet, avec son ambiance, sa mise en page et son expérience d'achat, que vous pouvez adapter à vos propres produits. Les noms de marque ne sont là qu'à titre d'illustration : voyez chacun comme une direction de style, pas comme une limite de catégorie.

Élégant et chaleureux, d'inspiration méditerranéenne. Une typographie raffinée et un rendu tactile, presque éditorial, pour les marques qui cultivent le soin du détail.

Moderne, minimal, contemporain. De larges espaces blancs et une mise en page sobre, centrée sur le produit, pour une boutique épurée et orientée design.

Doux, premium et tout en délicatesse. Des tons subtils et une mise en page aérée qui installent une expérience d'achat haut de gamme et désirable.

Fun, ensoleillé et décontracté. Des couleurs vives et joueuses et une navigation pleine d'énergie, pour les marques au caractère affirmé et au ton convivial.

Artisanal, frais et authentique. Une palette chaude et naturelle, un esprit généreux, pour les marques qui veulent un rendu fait main et sincère.

Coloré, joyeux et gourmand. Un style chaleureux et accueillant, une navigation enjouée, pour les marques au caractère ludique.

Pratique et accueillant, avec une mise en page épurée pensée pour parcourir vite et commander en un éclair. Idéal pour les boutiques qui misent avant tout sur la rapidité et la simplicité.

Naturel, immersif et végétal. De grandes images immersives et une mise en page éditoriale et enveloppante, pour les marques qui veulent une boutique audacieuse et immersive.

Des ambiances différentes, des univers bien distincts, et une seule et même plateforme pour les faire vivre. Cet ensemble n'est qu'un aperçu de la bibliothèque GoodBarber, une collection bien plus large qui couvre de nombreux styles et secteurs. Choisissez le thème le plus proche de votre marque, puis faites-le vôtre : modifiez les couleurs, affinez les détails. À chaque étape, les règles du Smart Design veillent à ce que tout reste impeccable.

Votre boutique n'a pas à attendre un design que vous n'avez pas le temps de créer. Ouvrez GoodBarber, choisissez un thème et lancez votre essai gratuit dès aujourd'hui. Votre application eCommerce prend forme rapidement, à votre image. Il ne reste plus qu'à la soumettre à l'App Store et à Google Play, et à la mettre en ligne sur le web.

Posons-le tout de suite, parce que c'est le malentendu qui bloque tout le monde : vous n'avez besoin d'aucune compétence technique. Pas de terminal, rien à installer, aucune ligne de commande. Si vous savez écrire un message, vous savez piloter votre app.

Le « MCP » dont parlent nos autres articles, c'est simplement le pont sécurisé entre ChatGPT et votre app. Vous n'aurez jamais à le manipuler, ni même à retenir ce que ces trois lettres veulent dire. Vous le branchez une fois, et vous l'oubliez.

Ce que vous utilisez, vous, c'est ChatGPT : l'assistant d'OpenAI que vous avez peut-être déjà ouvert cent fois. La même fenêtre de discussion. La seule différence, après l'avoir connecté à votre app, c'est qu'il sait désormais agir dessus.

Nous construisons des outils pour des créateurs non techniciens depuis 2011. Celui-ci suit la même règle que les autres : plus de pouvoir, moins de complexité.

Imaginez. Vous êtes sur un marché, et votre stock de miel part plus vite que prévu. Vous sortez votre téléphone, vous ouvrez ChatGPT, et vous écrivez :

« Augmente le prix du Miel corse de 5 euros et envoie un push pour l'annoncer. »

ChatGPT retrouve le produit à 18 €, vous montre ce qu'il s'apprête à faire — le passer à 23 € et notifier vos clients — et attend votre validation. Vous confirmez. C'est fait. Vous n'avez ouvert aucun ordinateur, navigué dans aucun menu, rempli aucun formulaire.

C'est le vrai changement : les petites tâches se font au moment où vous y pensez, pas le soir venu, devant le back-office, en rattrapant une liste qui ne raccourcit jamais. Une commande à expédier, un article à publier, un prix à ajuster : vous le dites, c'est fait.

Et parce que c'est votre boutique, deux garde-fous restent en place. ChatGPT vous demande toujours confirmation avant une action sensible. Et la connexion est limitée à votre seule app — il ne peut rien voir ni toucher d'autre.

Il vous faut deux choses, et vous en avez probablement déjà une.

• Un compte GoodBarber avec au moins une app active, et un accès administrateur à cette app. Peu importe son type : les fonctionnalités Shop, CMS, Community et Membership sont toutes prises en charge.
• Un compte ChatGPT. L'offre gratuite suffit. Il faudra simplement activer le « Developer mode » dans les réglages — on y vient.

Un mot sur ce fameux Developer mode. Oui, ça porte un nom qui fait peur. Ne vous laissez pas intimider : c'est une simple case à cocher dans les réglages de ChatGPT, à activer une fois. Vous n'écrirez pas une ligne de code. C'est juste l'endroit où OpenAI range, pour l'instant, les connecteurs comme le nôtre — la fonctionnalité est encore en version bêta.

Ensuite, dans ChatGPT :

1. Allez dans Réglages → Apps & Connectors → Advanced settings et activez le Developer mode.
2. Revenez dans Apps & Connectors et cliquez sur Create pour ajouter un connecteur.
3. Donnez-lui un nom : GoodBarber.
4. Collez l'adresse du serveur GoodBarber : https://mcp.goodbarber.dev/mcp/sse
5. Réglez l'authentification sur OAuth.
6. Confirmez, puis connectez-vous à GoodBarber et autorisez l'accès.
7. Dans n'importe quelle conversation, ouvrez le menu +, activez le connecteur GoodBarber, et commencez à parler à votre app.

Comptez quelques minutes, une seule fois. Si vous préférez vous laisser guider, le pas-à-pas complet avec captures d'écran est sur notre page Connecter ChatGPT à votre app.

Une fois connecté, parlez à ChatGPT comme à un assistant. Voici cinq demandes prêtes à l'emploi — remplacez ce qui est entre crochets par vos informations.

1. « Liste mes derniers produits avec leur prix et leur stock. » — un coup d'œil sur votre catalogue, depuis votre téléphone, sans rien ouvrir d'autre.
2. « Augmente le prix de [produit] de 5 euros. » — une modification en une phrase, sans naviguer dans le back-office.
3. « Crée un article publié intitulé [titre] annonçant [message]. » — publier un contenu en une seule demande, sur le moment.
4. « Montre-moi mes commandes récentes et leur statut d'expédition. » — suivre vos commandes sans même vous connecter au tableau de bord.
5. « Envoie une notification push à mes clients pour annoncer [message]. » — toucher votre audience immédiatement, quand l'info est chaude.

Pour chaque action sensible — créer, modifier, supprimer, envoyer un push — ChatGPT vous demande confirmation avant d'agir. Vous proposez, vous validez, vous gardez la main.

Envie d'aller plus loin que ces exemples ? Nos recettes prêtes à l'emploi, les 44 skills open source pour les assistants IA, sont sur GitHub.

C'est la première question d'un commerçant, et elle est légitime. Quatre choses à retenir.

• Tout est limité à vos droits. L'assistant ne peut faire que ce que votre propre compte GoodBarber autorise — rien de plus, et uniquement sur l'app que vous avez connectée.
• Aucun mot de passe n'est transmis à ChatGPT. La connexion passe par OAuth, un standard reconnu : vous vous identifiez sur GoodBarber et vous approuvez l'accès, sans jamais confier vos identifiants à l'assistant.
• Vous pouvez tout révoquer à tout moment, en déconnectant GoodBarber depuis ChatGPT. La porte que vous ouvrez, vous pouvez la refermer.
• Rien de sensible ne se fait sans vous. ChatGPT propose une action, vous la confirmez. Vous restez l'éditeur de votre app, à chaque étape.

Cette même connexion ne se limite pas à votre boutique : elle gère aussi tout le contenu de votre app — articles, événements, galeries — comme nous le détaillons dans Gérer le contenu de votre app à la voix. Vous préférez Claude ? Le guide est ici. Et si vous êtes une agence, vous pouvez aller jusqu'à automatiser des tâches répétitives avec n8n — mais ça, c'est une autre histoire, et elle attendra que vous soyez à l'aise avec la première.

Vous avez déjà une app GoodBarber. Il ne vous manque que quelques minutes. Ouvrez ChatGPT, activez le connecteur GoodBarber en suivant les étapes ci-dessus, et parlez à votre app — pour de vrai, dès aujourd'hui.

Connecter ChatGPT à votre app →