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.

Skill GoodBarber	Avant MCP	Après MCP (agent vertical)
Commandes	Vous ouvrez chaque commande et mettez à jour la livraison à la main	L'agent consulte les commandes du jour, les passe en « traitée » et avertit chaque client
Abonnements	Vous accordez et suivez les abonnements des membres à la main	L'agent accorde ou met à jour un abonnement et consigne une note, puis vous rend compte pour révision
Actus / Contenu	Vous rédigez et programmez chaque article	L'agent rédige à partir d'un brief, publie et envoie le push
E-commerce	Vous mettez à jour les fiches produits une par une	L'agent réécrit 50 fiches à partir d'un seul prompt
Campagnes push	Vous rédigez, segmentez et programmez chaque push	L'agent planifie le calendrier hebdomadaire et s'adapte aux événements

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.

Critère	GoodBarber	BuildFire
Apps iOS	Natif Swift (compilé)	« Native » annoncé ; construction non documentée publiquement
Apps Android	Natif Kotlin (compilé)	« Native » annoncé ; construction non documentée publiquement
PWA	Oui	Oui
Hébergement inclus	Oui	Oui
Base de données incluse	Oui	Quotas de stockage par palier ; couche de données non détaillée
Notifications push	Incluses	Incluses (100 000–300 000/mois selon palier)
Paiements / e-commerce	Inclus, 0 % de commission	Achats intégrés comptés (1 sur Growth, illimités sur Scale)
Fonctions IA	IA côté back-office + serveur MCP + 30 Claude Skills	IA de gestion via intégration ChatGPT/MCP
Chatbot IA pour l'utilisateur final	Disponible	Non documenté
Plugins / extensions	190+ extensions (gratuites + payantes)	150+ plugins + SDK/API pour développeurs
Service de publication	GBTC — soumission gérée (91 % des rejets rattrapés)	Équipe de services pour la soumission
Conformité / sécurité	Hébergement 100 % UE, CMP IAB TCF v2, Apps for Kids, privacy by design	Certifié SOC 2
Modèle de revente	Forfait fixe, apps illimitées, 0 % de commission	Abonnement plateforme + montant par app active
Prix d'entrée	30 €/mois (Standard), natif dès 55 €/mois (Premium)	165 $/mois (Standard)

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 avez cette idée d'app en tête depuis des mois. Ce week-end, vous vous lancez : vous ouvrez un outil de vibe coding, vous décrivez votre projet en quelques phrases, et vous regardez l'app se construire sous vos yeux.

Dimanche soir, ça tourne sur votre téléphone. Les écrans s'enchaînent, les boutons répondent, l'animation est fluide. Lundi, vous la montrez autour de vous : tout le monde est bluffé. Et vous, vous avez cette sensation grisante: c'est presque fini.

Au début, tout va bien. Puis, au fil des jours, des détails vous chiffonnent. Le défilement accroche un peu. Le clavier met un temps de trop à monter. Une transition « sent le web ». Vous ne mettez pas tout de suite le doigt dessus, mais vos utilisateurs, eux, le ressentent. L'app a beau s'appeler « app », sous le capot c'est souvent du web embarqué ou du React Native habillé en mobile. Ça tient en démo. Ça se paie ensuite : en fluidité, en accès aux capteurs du téléphone, et au moment de la review Apple, de plus en plus stricte avec les apps « web déguisé ».
Le plus parlant, c'est que la nouvelle génération d'outils commence elle-même à l'admettre. En février 2026, Rork a fait un pari assumé : abandonner React Native pour générer du vrai code Swift, au motif que « les gens qui veulent une app iOS veulent une vraie app iOS, pas un web déguisé ». Ils ont raison. C'est exactement le pari que nous tenons, nous, depuis 2011 : chez GoodBarber, iOS est compilé en Swift, Android en Kotlin. Pas de Flutter, pas de React Native, ...
Et ce n'est pas qu'une affaire de vocabulaire technique. Le natif est ce qui rend possible la couche qui fait qu'une app est agréable : retour haptique, effets de parallaxe, motion design, une TabBar flottante, un lecteur média qui suit l'utilisateur d'un écran à l'autre. Ces détails ne s'ajoutent pas après coup avec un prompt, ils dépendent du moteur qui compile l'app. C'est la différence, sensible en une seconde d'usage, entre une app professionnelle et une app « générée ».

Admettons que la fluidité vous convienne. Vient le moment que vous attendiez : publier. Et c'est là que le vrai mur se dresse. Générer le code était une chose ; le mettre dans les stores en est une autre, et c'est elle qui arrête net la plupart des non-développeurs. Xcode, Android Studio, certificats de signature, profils de provisioning, comptes développeurs payants ... et au bout, la review Apple, imprévisible même pour des équipes aguerries.
À quel point imprévisible ? Apple rejette environ 42 % des apps lors de leur première soumission. C'est le chiffre que mesure notre équipe de publication sur les apps qu'elle a soumises ces douze derniers mois — et il s'agit d'apps préparées par des gens dont c'est le métier. Imaginez la même barrière, mais avec un code généré que vous ne maîtrisez pas et un message de refus que vous ne savez pas décoder.
La différence ne tient pas à éviter le rejet, personne n'y échappe tout à fait. Elle tient à savoir le récupérer. Sur ces premières soumissions rejetées, 91 % finissent acceptées après l'intervention de notre équipe. Et une fois la mécanique rodée, le taux de rejet sur les mises à jour tombe à 5 %, dont 100 % sont récupérées (huit derniers mois). Ce n'est pas de la chance : ce sont quinze ans passés à apprendre ce qu'Apple accepte et ce qu'il refuse, transformés en travail de prévention. Un outil qui s'arrête à la génération du code vous laisse seul devant ce mur. Le code est prêt, et pourtant votre app n'existe nulle part.

Disons que vous passez. Votre app est en ligne, vous soufflez. Sauf que la mise en ligne n'est pas l'arrivée : c'est le départ. Une app mobile, c'est ensuite des mises à jour quand les OS évoluent, de la rétrocompatibilité, des migrations de données, du contenu à publier, des notifications à envoyer, des utilisateurs à gérer. Or les outils de génération s'arrêtent presque tous à la première sortie. La suite, c'est rouvrir le code et le faire re-générer à chaque changement, en corrigeant une chose, au risque d'en casser trois autres, sans toujours comprendre pourquoi.
C'est tout le rôle d'un back-office structuré : non pas un fichier de code à reprendre sans fin, mais une interface pensée pour opérer l'app au quotidien — publier, notifier, suivre ses utilisateurs et ses ventes — et tenue, chez nous, aux mêmes exigences de design que les apps qu'elle produit. Ce travail de durée se mesure simplement : une app GoodBarber est téléchargée toutes les 4 secondes, à travers 152 pays. Ce volume ne vient pas d'apps lancées puis oubliées. Il vient d'apps qu'on fait vivre, mois après mois.

Je ne vais pas vous dire que tout est noir d'un côté et lumineux de l'autre. Le vibe coding a une vraie force : quand un besoin est précis et bien exprimé, il sait le retranscrire fidèlement, y compris une logique sur-mesure qui sort des gabarits. Cette force, nous l'avons d'ailleurs intégrée nous aussi, à l'échelle d'une section d'app : avec l'AI Extension Builder, vous décrivez la fonctionnalité qui vous manque, et elle est générée puis branchée dans votre back-office, sans écrire de code.
Aucun outil ne fait tout, et GoodBarber non plus : un jeu, une marketplace multi-faces ultra-spécifique, ce n'est pas notre terrain. Mais l'immense majorité des apps que les gens veulent réellement publier, nous savons les livrer, et surtout, les faire vivre. La question n'est donc pas « lequel est le meilleur » dans l'absolu, mais « qu'est-ce que vous voulez au bout du chemin : une démo, ou une app dans les stores ? ».

Le trajet, résumé d'un coup d'œil :

Étape	Ce que fait un générateur de code	Ce qu'exige une app en production
Concevoir l'écran	Une interface qui tourne, vite	Une interface qui tient sur tous les appareils
Obtenir une app native	Souvent du web embarqué, habillé en app	Un binaire compilé en Swift / Kotlin
Publier sur les stores	S'arrête à la génération du code	Passer la review Apple (≈ 42 % de refus au 1er dépôt)
Faire vivre l'app	Re-générer à chaque changement	Un back-office pour opérer au quotidien

La bonne question n'a jamais été « est-ce qu'une IA peut générer une app ? ». Oui, elle le peut, et c'est une vraie bonne nouvelle. La porte d'entrée s'est ouverte pour des milliers de gens qui ne se seraient jamais lancés. La vraie question, c'est : qui s'occupe du chemin d'après ? Le natif, la publication, la vie de l'app. C'est cette couche d'infrastructure invisible en démo, qui décide si votre idée devient une app ou reste un prototype sur votre disque dur.
C'est cette couche qu'une plateforme établie a déjà construite, brique par brique : tout inclus — hébergement, base de données, push, analytics, paiement — pour un coût total de l'ordre du dixième d'un développement sur-mesure. Pas par effet de mode, mais parce qu'il a fallu quinze ans pour apprendre où sont les murs, et comment les passer.
Le week-end où votre app semble « presque finie » est un beau moment. Gardez-le. Sachez seulement qu'il marque le début du chemin, pas la fin ... et qu'à partir de là, ce qui compte vraiment, c'est qui marche avec vous ;)

Les applications créées par vibe coding sont-elles vraiment natives ?

Pas toujours. Beaucoup d'outils de vibe coding génèrent du web embarqué ou du React Native habillé en app mobile, ce qui se ressent sur la fluidité, l'accès aux capteurs et au moment de la review Apple. GoodBarber compile de vrais binaires natifs. Swift pour iOS, Kotlin pour Android, depuis 2011, sans Flutter ni React.



Peut-on publier une app générée par IA sur l'App Store et Google Play ?

Générer le code ne suffit pas. La publication demande de gérer Xcode, les certificats de signature, les profils de provisioning et la review Apple, qui rejette environ 42 % des apps à leur première soumission. La plupart des outils de vibe coding s'arrêtent à la génération et laissent cette étape à l'utilisateur. GoodBarber prend en charge la publication de bout en bout : 91 % des premières soumissions rejetées par Apple finissent acceptées après l'intervention de notre équipe (étude sur les douze derniers mois).



Que devient une app générée par IA après son lancement ?

Une app doit vivre après sa sortie : mises à jour quand les OS évoluent, rétrocompatibilité, migrations de données, contenu à publier, notifications, gestion des utilisateurs. Les générateurs de code s'arrêtent le plus souvent à la première version, ce qui oblige à tout re-générer à chaque changement. GoodBarber fournit un back-office structuré pour opérer l'app au quotidien. C'est pour cela qu'une app GoodBarber est téléchargée toutes les 4 secondes, dans 152 pays.



Vibe coding ou app builder : que choisir ?

Pour traduire fidèlement un besoin précis et bien exprimé,  y compris une logique sur-mesure hors gabarit, le vibe coding est très bon, une approche que GoodBarber propose aussi à l'échelle d'une section via son AI Extension Builder. Pour livrer une app dans les stores et la faire durer, une plateforme établie gère la couche d'infrastructure : fidélité native, publication, cycle de vie, tout inclus (hébergement, base de données, push, analytics, paiement), pour un coût total de l'ordre du dixième d'un développement sur-mesure.



Chiffres de publication issus du suivi CRM de l'équipe GoodBarber (avril 2026). GoodBarber crée des applications natives iOS et Android, et des Progressive Web Apps, depuis 2011.

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 →

La réponse courte : avec MCP, c'est l'API qui s'explique à la machine — vous ne fabriquez plus les requêtes à la main.

Une intégration REST classique, c'est lire la doc d'une API, construire chaque requête HTTP, gérer l'authentification et la pagination soi-même. MCP (Model Context Protocol) inverse ce travail : votre app GoodBarber expose ses opérations comme des tools qu'un client MCP découvre et appelle tout seul. Notre app de test — une Content App — a exposé 62 tools dès la connexion : articles, paragraphes, événements, cartes, galeries, vidéos, sons.

Si n8n compte ici, c'est qu'il fait partie des rares plateformes d'automatisation dotées d'un MCP Client node natif — et que ses nodes AI Agent peuvent confier ces 62 tools à Claude en le laissant décider lesquels appeler. Les plateformes façon Zapier automatisent des apps ; n8n + MCP automatise votre app.

	REST + automatisation classique	MCP + n8n
Travail d'intégration	Une requête à fabriquer par action	Tools découverts automatiquement
Authentification	Une clé API par requête	Une seule connexion OAuth
L'IA dans la boucle	Vous parsez, l'IA voit des fragments	L'agent appelle les tools directement

Toute la connexion tient en un node et un écran OAuth. Voici la séquence que nous avons suivie sur n8n.cloud :

1. Créez un workflow, ajoutez un node AI Agent, branchez-y un modèle Claude (une clé API Anthropic dans les credentials de n8n).
2. Ajoutez un node MCP Client Tool avec l'endpoint https://mcp.goodbarber.dev/mcp/sse, le transport HTTP Streamable et l'authentification MCP OAuth2.
3. Cliquez sur Connect. n8n s'enregistre tout seul auprès du serveur GoodBarber (dynamic client registration), et une page d'autorisation GoodBarber s'ouvre.
4. Collez la Public API key de votre app — vous la générez dans le back-office, sur la page Public API / MCP server — et validez.

C'est tout. Le credential affiche « Account connected » et le node liste tous les tools que votre app expose — la page GoodBarber MCP détaille le catalogue complet par type d'app. Cinq minutes, sans code, sans gymnastique de webhooks.

L'objectif : chaque article publié dans notre section de blog anglaise reçoit une traduction française dans la section française, tous les matins à 9 h.

Notre première version était la plus évidente : un trigger Schedule et un seul AI Agent tenant tous les tools d'article — lister les articles, repérer les traductions manquantes, traduire, créer. Elle a marché au premier essai à blanc. Puis elle a heurté un mur : un agent renvoie toute sa conversation à chaque étape, et les payloads d'article sont volumineux. Nos exécutions brûlaient 40 000 à 77 000 tokens d'entrée par minute — au-delà des limites d'un compte API d'entrée de gamme, quel que soit le modèle.

La version qui tourne en production tous les jours est plus sobre, et elle nous a appris le vrai pattern : des nodes déterministes pour la tuyauterie, et le modèle seulement là où il y a du jugement. Quatre nodes HTTP Request appellent les tools MCP directement (le credential MCP OAuth2 de n8n se branche sur un simple node HTTP — c'est l'astuce), un petit node Code choisit l'article le plus ancien non traduit, et un seul appel à Claude traduit l'article entier d'un coup. Les traductions arrivent dans le CMS avec leurs images et leurs embeds préservés, pour environ 5 000 tokens par exécution au lieu de 70 000.

Deux choix de conception font tout le travail sur le coût. Nous n'exposons que les tools dont le workflow a réellement besoin — le node MCP Client de n8n accepte une sélection de tools, et ramener la nôtre aux cinq tools d'article a économisé des milliers de tokens de schéma à chaque appel au modèle. Et l'idempotence tient en une convention de slug : la version française de health-benefits-journaling est health-benefits-journaling-fr — si le slug existe, l'article est déjà fait, donc le pipeline ne traduit jamais deux fois.

Aujourd'hui le pipeline écrit des brouillons et c'est nous qui publions. C'est un choix éditorial, pas une limite technique : la qualité de traduction de Claude est assez constante pour que nous fassions confiance à ce workflow sans humain dans la boucle — directement en ligne.

Le même pattern ingère du contenu au lieu de le traduire. Le trigger RSS intégré de n8n surveille n'importe quel flux ; un node Claude reformate chaque entrée en un titre, un résumé et un corps propres ; cms_create_article et cms_create_article_paragraph créent le brouillon dans la section de votre choix. Votre équipe éditoriale ouvre le back-office le matin sur une file de brouillons préparés plutôt que sur une liste de liens à traiter.

Le reporting, c'est là que l'agent brille, parce que le nombre d'opérations reste faible. Un trigger Schedule se déclenche chaque vendredi ; l'agent appelle cms_list_articles sur la fenêtre de la semaine, Claude rédige un court digest — ce qui est paru, ce qui est encore en brouillon, ce qui est programmé — et un node Telegram le livre sur le canal de l'équipe. Dix minutes de configuration pour un battement de cœur éditorial récurrent.

L'honnêteté rend un tutoriel utile, alors voici les deux choses qui nous ont vraiment mordus.

• Les limites d'API d'entrée de gamme ne conviennent pas aux agents bavards. Sur un tier Anthropic bas, une seule exécution d'agent tout-en-un dépassait les limites de tokens par minute. Séparez la tuyauterie de l'intelligence, ou prévoyez un tier supérieur.
• Les réponses de liste sont volumineuses. Les listes d'articles renvoient le contenu complet et les jeux d'images — parfait pour un assistant interactif, lourd dans la boucle d'un agent. Récupérez un article à la fois quand le budget de tokens compte.

Notre app de test se traduit désormais toute seule chaque matin. Si vous voulez le même point de départ : la page 44 skills GoodBarber explique ce que le serveur MCP expose, Connect Claude détaille la configuration côté assistant, et le dépôt open source goodbarber-skills contient les recettes prêtes à l'emploi — dont les workflows CMS sur lesquels cet article est bâti. Et si vous vous demandez pourquoi nous avons rendu nos apps prêtes pour les agents IA en premier lieu, nous avons aussi raconté cette histoire.

Le geste que vous attendez de vos utilisateurs mérite d'être accessible en permanence, qu'ils lisent un article, parcourent une fiche produit ou passent d'un onglet à l'autre. Le Bouton flottant global lui donne exactement cette place : un bouton défini une fois, présent là où vos utilisateurs en ont besoin, sans avoir à le replacer écran par écran.

C'est un composant au niveau de l'app : vous choisissez sa destination, son libellé, son icône et sa couleur, et il s'affiche sur l'ensemble des écrans. La destination peut être une page de votre app, une action directe comme un appel ou un SMS, ou une app externe comme WhatsApp. Par défaut, le bouton reprend les couleurs de thème de votre app, dans la logique du design system de GoodBarber : il s'intègre comme un élément natif, sans réglage manuel. Une seule mise en place, et il reste accessible quelle que soit la page consultée.

Concrètement, c'est le même bouton qui suit le contexte de chacun :

• Une boutique garde « Voir le panier » accessible pendant que ses clients parcourent le catalogue.
• Un commerce de proximité met « Appeler » ou « Nous écrire sur WhatsApp » directement accessible, sans que le client cherche le numéro.
• Un salon de coiffure place « Prendre rendez-vous » sur chaque écran, vers sa section Booking.

Une seule action, mais omniprésente, sans la recopier nulle part.

C'est le cas d'usage où le Bouton flottant prend toute sa valeur. Avec l'extension RAG Chatbot, votre app embarque un assistant qui répond aux questions de vos utilisateurs à partir de votre propre contenu publié, pas de la mémoire générale d'un modèle. Réponses fiables, dans la langue de la question, avec un lien possible vers la source.

Encore faut-il que vos utilisateurs y pensent. Un Bouton flottant « Poser une question » présent sur chaque écran transforme l'assistant en réflexe, au lieu d'une section qu'il faut aller chercher dans le menu. Une app de tourisme, une plateforme de e-learning ou une base de connaissances interne donne ainsi à son assistant la place qu'il mérite : bien en vue, en permanence.

Un bouton présent partout ne doit jamais devenir une gêne, et son affichage est cadré pour ça. Deux logiques se combinent.

Certaines pages ne l'affichent jamais, sans aucune intervention de votre part : les sections qui disposent déjà de leur propre bouton flottant, pour ne jamais en montrer deux en même temps, et les pages système comme la recherche, le panier, le paiement, le profil ou la connexion.

Partout ailleurs, c'est vous qui décidez. Depuis le panneau de configuration du bouton, vous masquez son affichage section par section, et vous le gardez uniquement sur les écrans où il a vraiment du sens.

Enfin, lorsqu'une TabBar, un lecteur audio ou une bannière fixe occupe déjà le bas de l'écran, le bouton se cale juste au-dessus, sans jamais les recouvrir.

Le Bouton flottant se configure depuis le panneau Structure de votre back-office, où il apparaît comme un élément dédié, juste sous votre navigation principale. Activez-le, choisissez la destination, le libellé, l'icône et la position, et il est en ligne sur toute l'app à la prochaine publication. Désactivé, il reste visible à cet emplacement, prêt à servir le jour où vous en aurez besoin.

Ouvrez le panneau Structure de votre app et donnez à votre action clé la visibilité qu'elle mérite. Pas encore d'app GoodBarber ? Lancez votre essai gratuit et testez-le dès le premier écran.

Les plateformes no-code de création d'apps abordent l'intégration des agents IA de deux façons : soit elles vous aident à construire des agents, soit elles rendent votre app existante pilotable par ces agents.

	Le modèle « construction d'agents »	Le modèle « backend IA »
Ce que fait l'IA	Elle génère ou fait tourner la logique de votre app	Elle appelle les opérations de votre app, pour vous
Votre point de départ	Construire — ou reconstruire — sur leur plateforme	Votre app existante est déjà la cible
Où se loge la complexité	Dans des workflows et des bases de données que vous maintenez	Dans l'agent ; votre app se contente de répondre
Exemples	Bubble, Lovable, Base44	GoodBarber, via MCP

Le discours de Bubble est sincère et, pour son public, exact : si vous assemblez un produit logiciel sur mesure, construire des agents IA sur son moteur de bases de données et de workflows est réellement puissant. Même chose pour les outils qui génèrent une app à partir d'un prompt, quand ce qu'il vous faut, c'est un prototype pour ce soir.

Mais regardez ce que les deux exigent d'abord : construire. Un schéma de données, des workflows, des écrans — ou, a minima, une migration.

Pour un commerçant qui a déjà une app et de vrais clients, c'est le mauvais point de départ. Vous n'avez rien à reconstruire. Ce qu'il vous faut, c'est que votre app réponde aux instructions de l'IA.

Un backend IA, cela signifie que vous pilotez votre app par la conversation, depuis l'assistant IA que vous utilisez déjà — Claude, ChatGPT, Cursor :

• « Mettez en place une promo flash de 20 % sur la collection randonnée ce week-end, et annoncez-la par un push vendredi à 18 h. » — l'agent crée le code promo et programme l'envoi (les skills promo-campaign et push-broadcast).
• « Ajoutez ces 12 produits depuis ce CSV, avec les tailles et les prix. » — product-launch, douze fois, variantes comprises.
• « Qui sont mes meilleurs clients ce trimestre — et lesquels ne donnent plus signe de vie ? » — rfm-segmentation classe vos clients selon la récence, la fréquence et le montant de leurs achats.
• « Envoyez un push de réactivation à tous ceux qui n'ont pas commandé depuis 60 jours. » — push-targeted, ciblé précisément sur ce segment.
• « Donnez-moi mon rapport du lundi : ventes, trafic, meilleures ventes. » — weekly-digest, traffic-report, best-sellers.

Chacun des exemples ci-dessus correspond à l'un des 44 skills prêts à l'emploi que GoodBarber publie pour son serveur MCP. MCP — le Model Context Protocol — est le standard ouvert introduit par Anthropic fin 2024, et adopté depuis par toute l'industrie, OpenAI compris. Branchez l'endpoint sur votre assistant, connectez-vous : vous disposez d'une app mobile prête pour l'IA — une app que n'importe quel agent IA peut gérer.

Une limite, énoncée clairement : l'agent pilote vos contenus et vos données métier — catalogue, commandes, notifications push, membres, statistiques. Il ne touche ni à votre design ni à votre navigation. Tout cela reste dans le back office, entre des mains humaines. Prête pour les agents IA signifie que la porte leur est ouverte pour agir en votre nom — pas que vous avez quitté la pièce.

Connecter des agents à l'app que vous exploitez déjà vaut mieux que tout reconstruire sur une plateforme d'agents. Pour trois raisons.

1. Aucune dépendance côté IA. Les modèles vont continuer à se dépasser les uns les autres pendant des années. Avec un backend IA, vous pouvez remplacer Claude par ChatGPT, puis par ce que 2027 apportera — les skills restent, le serveur reste, votre app ne bouge pas. GoodBarber ne vous vend pas d'abonnement IA et ne prend aucune commission sur l'usage : vous venez avec l'assistant que vous payez déjà.

2. Votre équipe n'a pas à se transformer en équipe d'ingénieurs IA. Sur une plateforme de construction d'agents comme Bubble, l'agent est un logiciel de plus à votre charge : des prompts à ajuster, des workflows à déboguer, des cas limites à encaisser. Avec les skills, la recette est déjà écrite, testée et maintenue. Votre équipe n'a qu'à dire ce qu'elle veut. Depuis quinze ans, GoodBarber met des outils puissants à la portée de personnes non techniques — c'est le même mouvement, appliqué cette fois à l'IA.

3. Cela fonctionne avec l'app que vous avez déjà. Pas de migration, pas de refonte, pas de stack supplémentaire à laquelle s'abonner. Le serveur MCP et les 44 skills sont livrés avec votre app GoodBarber — aux côtés de l'hébergement, de la base de données, des paiements et de l'infrastructure push déjà compris dans l'abonnement. Si vous avez une app GoodBarber, votre app est déjà prête pour les agents IA.

Cette approche s'adresse aux entreprises qui exploitent déjà une app — pas aux équipes qui construisent un nouveau produit logiciel. Un cadrage honnête, car la distinction ne sert que si on la trace nettement.

L'approche backend IA est faite pour vous si :

• Vous exploitez une app existante, avec de vrais clients — un catalogue, des contenus, une communauté — et le travail opérationnel quotidien qui va avec.
• Vous voulez confier à un agent IA les tâches répétitives de votre app mobile : rapports, segments, paramétrage de campagnes, modifications en série.

Ce n'est pas ce qu'il vous faut si :

• Vous construisez un produit SaaS et voulez que l'IA génère le produit lui-même. C'est un vrai cas d'usage — juste un autre, et des outils comme Bubble ou Lovable y répondent très bien.
• Vous voulez une app générée à partir d'un prompt en vingt minutes. GoodBarber est conçu pour des apps que l'on exploite pendant des années, pas pour des prototypes.

Écrire cette seconde liste ne nous coûte rien : GoodBarber est fait pour les apps de contenu et le commerce mobile, exploités au quotidien. Si votre projet vit ailleurs, nous préférons que vous le sachiez dès maintenant.

Si vous avez une app GoodBarber, la partie backend est déjà faite. Trois pistes pour la suite :

1. Parcourez les 44 skills sur GitHub — chaque skill est une recette markdown lisible ; dix minutes de survol suffisent à voir ce qui est possible.
2. Connectez Claude à votre app — le court guide de configuration pour gérer votre app avec Claude.
3. Découvrez comment fonctionne GoodBarber MCP — la visite guidée du serveur, en langage clair, modèle de sécurité compris.

En 2026, tous les créateurs d'apps vous diront qu'ils sont propulsés par l'IA. La question la plus utile est ailleurs : votre app est-elle prête pour les agents ? Quand votre assistant IA tendra la main vers elle, trouvera-t-il une porte ou un mur ?

Votre app n'a pas besoin de devenir une IA. Elle a besoin de répondre quand une IA l'appelle.

Ces dernières années, plusieurs pays — à commencer par les États-Unis — ont durci leur cadre légal autour de la protection des mineurs sur les plateformes numériques. Ces lois imposent aux applications de tenir compte de la tranche d'âge de leurs utilisateurs pour adapter les fonctionnalités accessibles. Toute application qui collecte des données, affiche des publicités ou permet des interactions sociales doit appliquer des restrictions spécifiques dès lors que l'utilisateur est mineur (moins de 16 ans).

Sur une app développée sur mesure, c'est un chantier : détection de l'âge, branchements conditionnels sur chaque fonctionnalité sensible, maintenance à chaque évolution de la loi. Avec GoodBarber, la vérification d'âge est intégrée nativement dans vos applications iOS et Android. Vous activez un réglage, le reste suit.

Une activation pilotée par la loi locale

Age Protection ne s'active que sur les territoires où une loi de protection des mineurs est en vigueur. Concrètement, les SDK d'Apple et de Google ne renvoient une tranche d'âge que lorsque l'application est lancée depuis l'un de ces territoires — par exemple le Brésil ou le Texas. Ailleurs, le système d'exploitation ne communique aucune information : la fonctionnalité reste en veille et l'utilisateur est traité comme un adulte, sans aucune restriction.

Cette logique est gérée par les plateformes elles-mêmes. La liste des territoires concernés évolue avec la législation, sans action de votre part.

Détection de la tranche d'âge

Sur un territoire concerné, à chaque lancement de l'application (si la fonctionnalité est activée), l'app interroge automatiquement le système d'exploitation pour récupérer la tranche d'âge de l'utilisateur :

• Sur iOS, cette information est fournie par Apple via le compte App Store de l'utilisateur.
• Sur Android, elle est fournie par Google Play.

Si la vérification réussit, le résultat est mis en cache pour les prochains lancements. Si l'utilisateur se trouve dans un territoire concerné mais que la plateforme ne peut pas fournir l'information (compte non renseigné, version trop ancienne, etc.), l'application applique par défaut les restrictions liées aux utilisateurs de 15 ans ou moins, afin de garantir la protection des mineurs en toutes circonstances.

À noter : Si la fonctionnalité Age Protection est désactivée ou absente de votre build, l'utilisateur est considéré comme adulte par défaut.

Lorsqu'un utilisateur est identifié comme mineur, l'application adapte automatiquement son comportement sur plusieurs points :

Aucun tracking ni publicité externe

Le suivi statistique, la géolocalisation et les services publicitaires tiers sont désactivés. La popup de consentement ne s'affiche plus, car elle n'a plus de raison d'être.

Accès aux commentaires restreint

Les boutons de commentaires sont grisés et inactifs. Les mineurs ne peuvent ni lire ni écrire de commentaires dans l'application.

Chat et liste d'utilisateurs inaccessibles

Si votre application dispose d'un espace de chat ou d'une liste d'utilisateurs, un écran "Accès restreint" s'affiche à la place. Ce comportement protège les mineurs en leur évitant d'exposer des données personnelles dans des espaces conçus pour les adultes.

Contrôle parental pour les achats in-app

Si un utilisateur mineur tente de souscrire à un abonnement in-app, une validation parentale est requise avant de finaliser l'achat.

Inscription désactivée

Pour protéger les données personnelles, les mineurs ne peuvent pas créer de compte ni se connecter à votre application. Le bouton d'inscription est désactivé et la connexion via les réseaux sociaux est masquée.

L'activation se fait directement depuis votre back-office GoodBarber, dans la section Centre de confidentialité, sous la rubrique Contrôle d'âge.

Activez simplement le toggle "Activer la vérification d'âge" et sauvegardez. Le module sera automatiquement intégré à votre prochain build iOS et Android.

Important : Toute modification de ce paramètre entraînera une mise à jour de votre build. Pensez à régénérer votre certificat mobile si nécessaire.

Fonctionnalité	Utilisateur adulte (16 ans et +)	Utilisateur mineur (15 ans et -)
Tracking & stats	✅ Actif	❌ Désactivé
Publicités externes	✅ Actives	❌ Désactivées
Géolocalisation	✅ Disponible	❌ Désactivée
Popup de consentement	✅ Affichée	❌ Masquée
Commentaires	✅ Accessibles	❌ Grisés
Chat & liste utilisateurs	✅ Accessibles	🔒 Écran restreint
Achats in-app	✅ Directs	🔐 Avec validation parentale
Inscription / Connexion	✅ Disponible	❌ Désactivée

En tant que plateforme, GoodBarber a travaillé à assurer la compatibilité de ses fonctionnalités avec Age Protection : tracking, publicités, commentaires, chat, achats in-app… chacune de ces briques se comporte correctement selon la tranche d'âge détectée.

En revanche, nous ne maîtrisons pas le contenu publié dans votre application. La nature des articles, des médias, des sections et des services que vous proposez relève de votre seule responsabilité éditoriale. C'est à vous, en tant qu'éditeur de l'application, de vous assurer que le contenu que vous diffusez est adapté à votre audience cible, et de paramétrer correctement la tranche d'âge de votre application lors de sa soumission sur l'App Store et le Google Play Store.

Activer Age Protection ne dispense pas de cette démarche : c'est un outil de protection technique, pas un substitut à une politique de contenu adaptée.

Age Protection est disponible dès maintenant pour toutes les applications natives GoodBarber. Activez-le en quelques secondes depuis votre back-office, dans Centre de confidentialité → Contrôle d'âge, puis régénérez votre build : votre application est conforme dès sa prochaine mise à jour.

Trois articles ont montré comment le serveur MCP de GoodBarber fonctionne pour les créateurs. Celui-ci s'adresse à celles et ceux qui construisent par-dessus.

Pour rappel, le serveur a d'abord été lancé pour la boutique, puis a gagné votre contenu, puis les notifications push.

Pendant quinze ans, un logiciel a été quelque chose que les humains pilotent à travers un écran. Les agents changent la donne. La question que chaque plateforme se pose aujourd'hui est simple : lorsque vos utilisateurs sollicitent un assistant IA pour accomplir leurs tâches, votre produit disparaît-il derrière l'agent, ou devient-il ce que l'agent pilote ?

Nous avons choisi la seconde option. Le serveur MCP fait de GoodBarber un outil de premier plan que n'importe quel agent IA conforme peut découvrir, appeler et vérifier. Vous apportez votre propre agent — Claude, Cursor, ou tout ce qui parle le protocole — et GoodBarber expose un ensemble d'opérations structurées et authentifiées sur lesquelles il peut agir. Ce n'est pas un raccourci posé par-dessus le produit. C'est le produit, rendu pilotable.

Soyons précis, car la précision est ce dont un builder a besoin. Le serveur MCP pilote la surface opérationnelle de votre app :

• Boutique — produits, variantes, options, collections, médias, commandes, codes promo.
• Contenu (CMS) — articles, événements d'agenda, points de carte, galeries photo, vidéos, audio.
• Membres — abonnements, prospects, accès internes.
• Communauté — groupes et audiences.
• Communication — push en diffusion et ciblé, avec planification et destinations de tap.

Ce à quoi il ne touche pas : le design, la navigation et la structure de votre app. Tout cela reste dans le back office GoodBarber, là où ces éléments doivent être travaillés, pas générés. Le serveur déplace du contenu et des données métier — pas votre marque. Pour une agence, cette frontière compte : vous pouvez laisser un agent gérer le catalogue ou le calendrier éditorial d'un client sans aucun risque pour le design que vous avez livré.

Les outils bruts sont puissants mais de bas niveau. Un véritable workflow — « lancer un produit complet avec ses variantes, ses images et une fiche technique » — représente une douzaine d'appels d'outils dans le bon ordre, avec des contrôles à chaque étape. C'est précisément à cela que servent les skills.

Nous publions 44 skills, en open source, sur github.com/goodbarber/goodbarber-skills. Un skill est un fichier d'instructions au format Markdown qui enseigne à votre agent comment exécuter un workflow complet — découverte, prévisualisation à blanc, modification, puis vérification — à partir d'une simple requête en langage naturel. Ils sont regroupés par type d'app :

• eCommerce (18) — product-launch, catalog-audit, stock-check, reorder-planner, best-sellers, promo-campaign, customer-insights, rfm-segmentation, et plus encore.
• Membership (10) — subscription-audit, expiration-calendar, longest-subscribers, prospect-followup, et plus encore.
• CMS (11) — article-publish, event-publish, place-publish, gallery-builder, editorial-calendar, content-audit, et plus encore.
• Community (5) — push-broadcast, push-targeted, weekly-digest, et plus encore.

Deux choses à savoir en tant que builder. Premièrement, ils sont sûrs par conception : product-launch s'exécute d'abord à blanc — il résout vos collections et vos tags, vous montre exactement ce qu'il va créer, attend votre confirmation, puis vérifie chaque modification par une relecture. Aucun produit à moitié créé en production. Deuxièmement, ils vous appartiennent : ce sont de simples fichiers `.md`. Copiez ceux dont vous avez besoin dans le répertoire de skills de votre agent, modifiez le workflow, écrivez le vôtre. Ce sont un point de départ, pas une boîte noire.

Le serveur parle le MCP standard via SSE. La configuration tient en une ligne.

Claude Code :

claude mcp add goodbarber --transport sse https://mcp.goodbarber.dev/mcp/sse

Cursor / VS Code / Windsurf — ajoutez à .cursor/mcp.json :

{ "mcpServers": { "goodbarber": { "url": "https://mcp.goodbarber.dev/mcp/sse" } } }

La première connexion ouvre une page OAuth ; vous y collez votre Public API key (générée depuis la page Public API / MCP server de votre app) et vous êtes connecté. Aucune installation locale, aucun script à maintenir.

Voici à quoi ressemble une vraie session dans Claude Code — un seul prompt, et l'agent découvre, agit et vérifie :

> Ajoute un produit « Trail Map Poster » à 24 € dans la
 collection « Prints », avec les tailles A2 et A3.

● shop_list_collections → "Prints" found (id 4821)
● shop_create_product → "Trail Map Poster" created (id 90412)
● shop_create_option (Size) → values: A2, A3
● shop_create_variant ×2 → A2 €24 · A3 €18
● shop_get_product (90412) → verified: 2 variants, status published

Terminé. « Trail Map Poster » est en ligne avec 2 variantes, vérifié.

Cette boucle découvrir → agir → vérifier est intégrée à chaque skill : l'agent résout d'abord les véritables ID, effectue la modification, puis la relit pour confirmer. Rien n'est présumé.

Voici la partie pensée pour le programme de revente. Le serveur accepte un app ID dans l'URL :

https://mcp.goodbarber.dev/{app_id}/mcp/sse

Pointez votre agent vers l'app d'un client précis, lancez un skill d'audit sur l'ensemble du catalogue, générez un mois de calendrier éditorial, préparez une campagne promo — puis passez à l'app suivante, avec le même workflow. Les skills sont réutilisables sur chacune des apps que vous gérez. Le playbook de votre agence devient un dossier de skills.

Le serveur est référencé sur mcpservers.org, l'annuaire MCP public. Il vit dans l'écosystème où les agents et les builders cherchent des outils — visible aux côtés de tous les autres serveurs qui méritent d'être connectés.

Les trois premiers articles parlaient de réduire la friction pour une personne. Celui-ci parle de quelque chose de structurel : GoodBarber est désormais un outil sur lequel les agents peuvent construire. À mesure que les modèles deviennent meilleurs pour planifier des tâches en plusieurs étapes, la connexion que vous mettez en place aujourd'hui devient plus capable — sans rien à mettre à jour de votre côté.

Si vous construisez avec l'IA, voici votre invitation : connectez le serveur, clonez les 44 skills, et orchestrez.

Le serveur MCP modifie-t-il le design de mon app ? Non. Il pilote le contenu et les opérations métier — boutique, CMS, membres, push. Le design et la navigation restent dans le back office GoodBarber.

Quels clients fonctionnent ? Tout client conforme au MCP : Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, et d'autres.

Puis-je gérer plusieurs apps clientes ? Oui — utilisez l'endpoint {app_id}/mcp/sse et réutilisez les mêmes skills sur chaque app.

Les skills sont-ils open source ? Oui, 44 d'entre eux sur github.com/goodbarber/goodbarber-skills. Forkez-les et adaptez-les.

• Votre app obéit maintenant à la voix : le serveur MCP de GoodBarber est là
• Serveur MCP : gérez le contenu de votre app à la voix
• Le serveur MCP GoodBarber va plus loin : créez vos notifications push avec l'IA
• Zapier MCP + GoodBarber : pilotez votre app avec un agent IA

Ce mois-ci, le projecteur est braqué sur le GoodBarber MCP Server — désormais disponible pour les applications Shopping et Content — accompagné d'une longue liste de corrections sur l'ensemble de la plateforme.

• Le GoodBarber MCP Server est en ligne : connectez votre application aux assistants IA et gérez vos tâches quotidiennes en une seule phrase.
• Des notifications push plus intelligentes grâce à l'IA : le MCP server crée désormais des notifications push avec planification, destinations et ciblage précis par plateformes, groupes, abonnements ou utilisateurs spécifiques.
• Votre CMS, désormais accessible par le MCP server : articles, événements, cartes, galeries, podcasts.

Section Accueil

• Dans les widgets Article utilisant le template Visual Cards, correction d'un problème qui empêchait l'affichage du nombre de commentaires. iOS
• Dans les widgets Article utilisant le template Slideshow, correction d'un problème où le widget ne s'affichait pas correctement lorsqu'un seul élément était affiché. iOS
• Dans les widgets Article utilisant le template Visual Cards, correction d'un problème qui rendait les images floues. iOS
• Dans les widgets Article utilisant le template Une Story, correction d'un problème qui pouvait provoquer l'arrêt du défilement automatique après un balayage vers l'élément précédent ou suivant. iOS
• Dans les widgets Article utilisant le template Immersive Story, correction d'un problème qui empêchait l'ouverture de la page de détail lors d'un appui sur le contenu. iOS
• Dans les widgets Video, correction d'un problème qui maintenait l'icône de lecture visible lorsqu'aucune miniature n'était affichée. Android

Section Articles

• Dans les widgets Article utilisant le template Enriched, correction d'un problème qui empêchait l'affichage correct de l'arrière-plan de la page. PWA

Section Videos

• Correction d'un problème qui maintenait l'icône de lecture visible lorsqu'aucune miniature n'était affichée. Android

Section Events

• Correction d'un problème qui provoquait un plantage de l'application. Android
• Dans les listes utilisant le template Classic, correction d'un problème qui pouvait tronquer le texte « charger plus ». iOS
• Correction d'un problème qui pouvait empêcher l'affichage de la date du premier événement. Android
• Dans les pages de détail d'événement, correction d'un problème qui faisait apparaître en noir un arrière-plan transparent. iOS

Section Map

• Correction d'un problème qui pouvait provoquer un scintillement des images. iOS

Section Photos

• Dans les pages de détail, correction d'un problème qui faisait que les photos mettaient du temps à charger. PWA

Menus TabBar

• Le flou est désormais disponible sur les appareils Android compatibles avec Android 12 et versions ultérieures. Android
• Correction d'un problème qui faisait apparaître le menu Autre sous l'en-tête. PWA
• Correction d'un problème d'affichage lorsque la PWA est installée sur le home screen et sur certains appareils Android. PWA

Extension App Walkthrough

• Correction d'un problème qui empêchait le balayage entre les étapes. iOS
• Correction d'un problème qui empêchait l'affichage du texte. iOS

Extensions Custom code

• Correction d'un problème qui pouvait empêcher l'affichage des sections Custom code. Android
• Correction d'un problème qui pouvait empêcher l'affichage des widgets Custom code. Android
• Correction d'un problème qui pouvait empêcher le chargement correct des ressources. iOS

Autres corrections et améliorations

• Correction d'un problème qui pouvait provoquer un plantage de l'application. iOS
• Correction d'un problème qui affichait le contenu derrière la zone de sécurité supérieure dans les web apps ajoutées au home screen. PWA
• Correction d'un problème où les liens externes ne pouvaient pas s'ouvrir correctement dans le navigateur mobile iOS Safari. PWA

Section Accueil

• Dans les widgets Article utilisant le template Visual Cards, correction d'un problème qui empêchait l'affichage du nombre de commentaires. iOS
• Dans les widgets Article utilisant le template Slideshow, correction d'un problème où le widget ne s'affichait pas correctement lorsqu'un seul élément était affiché. iOS
• Dans les widgets Article utilisant le template Visual Cards, correction d'un problème qui rendait les images floues. iOS
• Dans les widgets Article utilisant le template Une Story, correction d'un problème qui pouvait provoquer l'arrêt du défilement automatique après un balayage vers l'élément précédent ou suivant. iOS
• Dans les widgets Article utilisant le template Immersive Story, correction d'un problème qui empêchait l'ouverture de la page de détail lors d'un appui sur le contenu. iOS
• Dans les widgets Video, correction d'un problème qui maintenait l'icône de lecture visible lorsqu'aucune miniature n'était affichée. Android

Section Articles

• Dans les widgets Article utilisant le template Enriched, correction d'un problème qui empêchait l'affichage correct de l'arrière-plan de la page. PWA

Section Videos

• Correction d'un problème qui maintenait l'icône de lecture visible lorsqu'aucune miniature n'était affichée. Android

Section Events

• Correction d'un problème qui provoquait un plantage de l'application. Android
• Dans les listes utilisant le template Classic, correction d'un problème qui pouvait tronquer le texte « charger plus ». iOS
• Correction d'un problème qui pouvait empêcher l'affichage de la date du premier événement. Android
• Dans les pages de détail d'événement, correction d'un problème qui faisait apparaître en noir un arrière-plan transparent. iOS

Section Map

• Correction d'un problème qui pouvait provoquer un scintillement des images. iOS

Section Photos

• Dans les pages de détail, correction d'un problème qui faisait que les photos mettaient du temps à charger. PWA

Menus TabBar

• Le flou est désormais disponible sur les appareils Android compatibles avec Android 12 et versions ultérieures. Android
• Correction d'un problème qui faisait apparaître le menu Autre sous l'en-tête. PWA
• Correction d'un problème d'affichage lorsque la PWA est installée sur le home screen et sur certains appareils Android. PWA

Extension App Walkthrough

• Correction d'un problème qui empêchait le balayage entre les étapes. iOS
• Correction d'un problème qui empêchait l'affichage du texte. iOS

Extensions Custom code

• Correction d'un problème qui pouvait empêcher l'affichage des sections Custom code. Android
• Correction d'un problème qui pouvait empêcher l'affichage des widgets Custom code. Android
• Correction d'un problème qui pouvait empêcher le chargement correct des ressources. iOS

Autres corrections et améliorations

• Correction d'un problème qui pouvait provoquer un plantage de l'application. iOS
• Correction d'un problème qui affichait le contenu derrière la zone de sécurité supérieure dans les web apps ajoutées au home screen. PWA
• Correction d'un problème où les liens externes ne pouvaient pas s'ouvrir correctement dans le navigateur mobile iOS Safari. PWA

Thunkable arrive avec un pedigree que peu d'app builders peuvent revendiquer : il est issu de MIT App Inventor, le projet qui a appris à toute une génération à assembler des apps à partir de blocs visuels. Onze millions d'apps plus tard, cet héritage se voit — l'éditeur drag-and-drop est réellement accessible, et la nouvelle couche AI Builder (« iOS and Android—built by chatting ») abaisse encore la barrière. Quand nous nous sommes installés pour construire AURORA dessus, obtenir un premier écran fonctionnel a été rapide et, franchement, plaisant.

La question qu'AURORA nous a forcés à poser n'était pas « puis-je construire la première version ? » — c'était « qu'est-ce que je publie exactement sur l'App Store, et que se passe-t-il quand l'app grossit ? ». Le marketing de Thunkable affirme produire de vraies apps natives. Les avis de la communauté décrivent une couche d'interprétation de blocs qui ralentit à mesure que la logique s'étoffe. Cet écart — entre la promesse du natif et l'expérience de faire tourner une vraie app à grande échelle — c'est le sujet de cette comparaison.

Cet article fait partie de notre série, où nous appliquons honnêtement le même brief AURORA à chaque outil. Si vous évaluez aussi Adalo, Glide, FlutterFlow ou Bubble, vous y retrouverez la même méthode.

• Thunkable construit les apps en assemblant des composants visuels et en reliant des blocs de logique. C'est accessible au départ, mais les utilisateurs rapportent de façon constante que les apps complexes deviennent difficiles à gérer et lentes à mesure que le nombre de blocs augmente.
• L'architecture runtime de Thunkable est disputée : l'entreprise commercialise une sortie réellement native, tandis que plusieurs sources communautaires décrivent une couche d'interprétation de blocs / WebView avec un plafond de performance sur les apps volumineuses. GoodBarber compile en binaires natifs Swift (iOS) et Kotlin (Android) — sans ambiguïté.
• Thunkable ne permet pas d'exporter votre code source — votre app vit uniquement dans leur plateforme. Les apps publiées nécessitent en outre un abonnement actif pour rester en ligne.
• Les données vivent dans des services externes (Firebase, Airtable, Google Sheets). Il n'y a pas de CMS éditorial dédié ni de back-office opérationnel pour le contenu, les campagnes push et l'e-commerce.
• Thunkable n'a pas de module e-commerce intégré documenté. GoodBarber inclut le tunnel de commande avec 0 % de commission et 22 moyens de paiement.
• Thunkable est un excellent environnement d'apprentissage et de prototypage avec un vrai héritage MIT. GoodBarber est conçu pour publier, exploiter et faire évoluer une app grand public pendant des années.

AURORA est le test que nous appliquons à chaque outil de la série : un guide de voyage luxe. Il exige une navigation multi-rubriques, une identité visuelle personnalisée (couleurs, typographie, logo), des comptes utilisateurs avec authentification, des notifications push, une couche de gestion éditoriale pour des mises à jour régulières, une couche de monétisation, une intégration de données en temps réel, un chatbot IA et une publication sur l'App Store et Google Play.

AURORA n'est pas un projet d'école ni un prototype de week-end. C'est le type d'app qu'une marque média ou une entreprise de voyage publie sous son propre nom, puis maintient pendant des années — en ajoutant des destinations, en lançant des promotions, en traitant des commandes, en livrant des mises à jour. Le brief est exigeant à dessein : ce sont les exigences qui font apparaître les vraies différences entre les outils.

GoodBarber : une plateforme gérée pour les apps natives grand public

GoodBarber construit des outils de création d'apps depuis 2011, avec un objectif unique : permettre à des créateurs non techniques de publier une app native professionnelle sur l'App Store et Google Play, puis de la faire tourner indéfiniment sans aide de développeur. iOS compile en Swift natif, Android en Kotlin natif — des binaires compilés, pas des couches interprétées. Le back-office gère le contenu, les notifications push, l'e-commerce, les utilisateurs et les statistiques, et la même configuration génère aussi une PWA. La couche IA couvre la création (l'AI Extension Builder, créer des sections par prompt) et l'exploitation (le serveur MCP avec 30 Skills Claude, pour que des agents IA opèrent l'app en production).

Thunkable : un builder par blocs avec un héritage MIT et une nouvelle couche IA

Thunkable a été fondé en 2015 par des anciens de MIT App Inventor, et cet ADN le définit : les apps s'assemblent à partir de composants visuels, avec une logique câblée via des blocs en drag-and-drop. C'est un modèle réellement accessible — les débutants atteignent un écran fonctionnel rapidement, et la plateforme est de longue date un favori dans l'éducation. Récemment, Thunkable s'est repositionné autour de l'IA : la page d'accueil ouvre désormais sur « Welcome to Thunkable AI », et un AI Builder transforme les prompts en points de départ. Pour l'apprentissage, le prototypage et les apps simples, le modèle par blocs de Thunkable est rapide et indulgent.

Nous avons déroulé les exigences d'AURORA dans l'éditeur de Thunkable. Les premières étapes ont été fluides ; la friction est apparue exactement là où les avis l'annonçaient.

Navigation et branding : Assembler la navigation multi-rubriques d'AURORA avec des composants a été simple, et le branding personnalisé est disponible à partir du plan Builder. L'AI Builder nous a donné un premier brouillon utilisable rapidement. C'est Thunkable au meilleur de lui-même.

Authentification et données : Les comptes utilisateurs fonctionnent via des composants de connexion, et Thunkable se connecte gratuitement à des données externes — Firebase, Airtable, Google Sheets — même sur les plans inférieurs. C'est une force réelle. Mais cela signifie aussi que le contenu d'AURORA vit dans un tableur ou un projet Firebase que vous configurez et maintenez séparément. Il n'y a pas de CMS éditorial dans Thunkable ; publier un nouveau guide de destination revient à éditer une source de données externe.

Notifications push : Prises en charge nativement — un vrai plus pour une app grand public.

E-commerce : Là, AURORA a heurté un mur. Thunkable n'a pas de module commerce intégré documenté. La couche de monétisation devrait être assemblée à partir d'intégrations API vers un prestataire de paiement externe — viable pour un créateur à l'aise avec la technique, lourd pour une équipe non technique.

Logique et montée en charge : À mesure que nous ajoutions les écrans et la logique d'AURORA, le canvas de blocs s'est densifié. Cela correspond à ce que les avis rapportent de façon constante : « gérer des dizaines de blocs interconnectés devient ingérable à mesure que la logique grandit », et « la couche d'interprétation des blocs peut ralentir les apps complexes ». Une app de voyage avec du contenu, des comptes, des réservations et des données en temps réel est précisément le genre de projet où ce plafond apparaît.

Publication : Thunkable publie sur l'App Store et Google Play (plan Builder et au-dessus pour une app en ligne), et il vous faudra vos propres comptes développeur Apple et Google. Une réserve structurelle : pas d'export du code source, donc l'app existe uniquement dans Thunkable, et elle doit conserver un abonnement actif pour rester en ligne.

La différence qui a le plus compté pour AURORA, c'est ce qui se passe après le prototype — quand « natif » cesse d'être un mot marketing pour devenir une revue en store, un budget de performance et cinq ans de mises à jour.

GoodBarber compile AURORA en Swift natif sur iOS et en Kotlin natif sur Android. Pas une couche d'interprétation de blocs, pas une coque WebView — des binaires compilés qui se comportent comme les relecteurs de l'App Store et vos utilisateurs l'attendent. Cela compte pour la performance quand l'app grossit, pour l'intégration au niveau de l'OS, et pour l'approbation en store. Sur ce dernier point, le service GBTC de GoodBarber gère directement le processus de revue Apple — Apple rejette environ 42 % des premières soumissions, et GoodBarber en récupère 91 %. Avec Thunkable, vous naviguez ce processus seul.

L'écart opérationnel est tout aussi concret. Le contenu d'AURORA vit dans un vrai back-office CMS dans GoodBarber — les éditeurs créent des rubriques et publient des guides sans toucher à un tableur ni à une console Firebase. Le même back-office envoie les campagnes push aux utilisateurs finaux et gère l'e-commerce, entièrement inclus : tunnel de commande avec 0 % de commission sur les transactions et 22 moyens de paiement couvrant les marchés mondiaux et régionaux. Dans Thunkable, ce sont des services externes que vous assemblez et maintenez.

Sur le coût, la comparaison mérite d'être faite honnêtement. Le premier palier de Thunkable avec une app publiée en ligne (Builder) est à 37 $/mois en facturation annuelle ; les apps publiées illimitées nécessitent le plan Advanced à 99 $/mois annuel — et vos données vivent dans des services que vous payez à part. Le plan Premium de GoodBarber à 70 €/mois inclut l'hébergement, la base de données, le push, le CMS, l'e-commerce et les builds iOS + Android natifs dans un seul abonnement. Et là où Thunkable n'offre aucun export du code source et lie l'app en ligne à un abonnement actif, la valeur de GoodBarber est la stack gérée elle-même — vous ne maintenez ni base de code ni assemblage de services.

Le RAG chatbot dont AURORA a besoin — répondre aux questions des voyageurs à partir du contenu publié de l'app — est une fonctionnalité native de GoodBarber, pas une intégration à construire.

Critère	GoodBarber	Thunkable
Sortie iOS	Swift natif (binaire compilé)	Natif revendiqué ; couche d'interprétation de blocs / WebView selon la communauté (disputé)
Sortie Android	Kotlin natif (binaire compilé)	Natif revendiqué ; même débat que pour iOS
PWA	Oui — incluse, même back-office	Oui — sortie web sur tous les plans
Modèle de construction	Configurer des fonctionnalités intégrées	Assembler des composants visuels + blocs de logique
Hébergement	Inclus	Inclus (tant que l'abonnement est actif)
Base de données	Incluse	Externe — Firebase, Airtable, Google Sheets
Notifications push	Incluses	Incluses (natives)
E-commerce / paiement	Inclus, 0 % de commission, 22 moyens de paiement	Pas de module intégré — via intégration API
CMS back-office éditorial	Oui — conçu pour éditeurs non techniques	Non — contenu dans des sources de données externes
Export du code source	Non applicable (plateforme gérée)	Non — pas d'export, vendor lock-in
Fonctionnalités IA	AI Extension Builder, RAG chatbot, serveur MCP + 30 Skills	AI Builder (prompt-to-app), Discuss Mode, génération d'images
Soumission App Store	Prise en charge (service GBTC)	À gérer soi-même — comptes développeur requis
Tarif (premier palier app en ligne)	70 €/mois Premium (tout inclus)	37 $/mois annuel Builder (1 app en ligne) ; services data en plus
Période d'essai	Oui	Plan gratuit (sans publication en stores)

Les deux outils assemblent des apps sans codage traditionnel, mais ils visent des lignes d'arrivée différentes. Thunkable optimise pour un canvas de construction accessible et flexible, avec un héritage pédagogique ; GoodBarber optimise pour un produit compilé, exploitable et tout-inclus, qui se publie en stores et tourne pendant des années.

Le thème le plus constant dans les avis de Thunkable n'est pas une fonctionnalité manquante — c'est une courbe. Le modèle par blocs est merveilleux au départ et plus difficile à gérer à mesure que l'app grandit. « Les choses les plus avancées demandent plus de compétences techniques. » « Gérer des dizaines de blocs interconnectés devient ingérable. » « La couche d'interprétation des blocs peut ralentir les apps complexes. » Aucun de ces points n'est rédhibitoire pour un projet d'école ou un MVP. Tous comptent pour AURORA.

C'est la différence structurelle entre assembler des blocs atomiques et configurer des fonctionnalités intégrées. Avec la construction par blocs, le travail croît avec la complexité de l'app — plus d'écrans et plus de logique signifient plus de blocs à câbler, déboguer et maintenir performants. Avec l'approche intégrée de GoodBarber, des fonctionnalités comme l'e-commerce, le push et la gestion de contenu arrivent pré-conçues pour encaisser la charge et les cas limites, de sorte que la complexité de l'app ne se traduit pas directement en charge de maintenance pour vous. Quand un besoin précis sort du périmètre intégré, l'Extension Store et le builder d'extensions assisté par IA comblent l'écart.

Pour un prototype, le plafond des blocs est invisible. Pour une app grand public que vous comptez faire grandir, c'est toute la question — et elle est aggravée par le fait que vous ne pouvez pas exporter le code et partir si vous l'atteignez.

• Vous apprenez à construire des apps ou vous en enseignez la création — l'héritage MIT App Inventor et le modèle par blocs de Thunkable en font l'une des meilleures portes d'entrée de la catégorie.
• Vous voulez un canvas ludique et accessible pour prototyper des apps simples à modérées, et vous appréciez les intégrations tierces gratuites même sur les plans inférieurs.
• Votre projet a peu de chances de devenir une grande app riche en logique où apparaissent le plafond d'interprétation des blocs et les soucis de performance.
• Vous êtes à l'aise pour gérer votre propre backend de données (Firebase, Airtable, Sheets) et n'avez pas besoin d'un CMS ou d'un module e-commerce intégré.
• Vous n'avez pas besoin de portabilité du code source et acceptez de garder l'app dans la plateforme Thunkable.

• Vous voulez des apps iOS et Android sans ambiguïté natives — Swift et Kotlin compilés — publiées sous votre propre marque et conçues pour performer à mesure que l'app grandit.
• Vous êtes une équipe non technique — éditeur de contenu, commerçant, marque hôtelière, commerce local — qui doit gérer contenu, push et e-commerce depuis un back-office, pas un tableur et un canvas de blocs.
• Vous construisez pour le long terme : une app que vous exploiterez au quotidien et ferez évoluer pendant des années, pas un prototype ou un projet d'apprentissage.
• Votre app inclut de l'e-commerce et vous avez besoin de 0 % de commission avec des moyens de paiement intégrés pour vos marchés.
• Vous voulez que toute votre stack — hébergement, base de données, push, CMS, paiements, statistiques — soit couverte par un seul abonnement, sans assembler ni maintenir des services externes.

Thunkable mérite sa réputation de l'une des façons les plus accessibles de commencer à construire une app, et son ascendance MIT n'est pas un hasard — pour l'apprentissage, le prototypage et les projets plus simples, le modèle par blocs est un vrai plaisir. L'axe du choix, c'est ce qui se passe après le départ. Les forces de Thunkable sont concentrées en amont, dans la construction ; les questions de performance native à grande échelle, d'outillage opérationnel, d'e-commerce et de portabilité du code sont là où AURORA sépare les deux plateformes.

Si votre projet est une app grand public qui doit être indéniablement native en stores et tourner pendant des années, commencez votre essai gratuit et construisez AURORA sur une plateforme qui compile en vrais binaires natifs et vous donne le back-office pour les exploiter.

• GoodBarber vs Bubble
• GoodBarber vs Base44
• GoodBarber vs Glide
• GoodBarber vs Rork
• GoodBarber vs Emergent
• GoodBarber vs FlutterFlow
• GoodBarber vs Adalo
• GoodBarber vs Bolt.new
• GoodBarber vs AppSheet
• Les 10 meilleurs app builders No-Code en 2026

Thunkable produit-il de vraies apps natives ?

Thunkable commercialise sa sortie comme de vraies apps natives iOS et Android. Cependant, plusieurs sources communautaires décrivent une couche runtime d'interprétation de blocs / WebView qui introduit un plafond de performance sur les apps volumineuses. L'architecture runtime est disputée entre les sources officielles et tierces. GoodBarber compile en binaires natifs Swift et Kotlin, sans cette ambiguïté.

Peut-on exporter son code source depuis Thunkable ?

Non. Thunkable ne permet pas l'export du code source brut, donc l'app existe uniquement dans leur plateforme, et une app publiée nécessite un abonnement actif pour rester en ligne. C'est fréquemment cité par les utilisateurs comme du vendor lock-in.

Thunkable inclut-il l'e-commerce et un CMS ?

Thunkable n'a pas de module e-commerce intégré documenté ni de CMS éditorial dédié ; le contenu est géré via des sources de données externes comme Firebase, Airtable ou Google Sheets, et une couche de paiement devrait être assemblée par intégration API. GoodBarber inclut à la fois un back-office CMS structuré et une couche e-commerce complète avec 0 % de commission et 22 moyens de paiement.

Quelle est la vraie différence de coût ?

Le premier palier de Thunkable autorisant une app publiée en ligne (Builder) est à 37 $/mois en facturation annuelle, avec des apps publiées illimitées sur le plan Advanced à 99 $/mois annuel — et votre backend de données est payé à part. Le plan Premium de GoodBarber à 70 €/mois inclut l'hébergement, la base de données, le push, le CMS, l'e-commerce et les builds iOS + Android natifs dans un seul abonnement.

Quand Thunkable est-il le meilleur choix ?

Thunkable est un excellent choix pour apprendre à construire des apps, enseigner et prototyper des projets plus simples — son héritage MIT App Inventor et son modèle par blocs en font l'une des portes d'entrée les plus accessibles de la catégorie. GoodBarber est le meilleur choix pour une app grand public qui a besoin d'une sortie sans ambiguïté native, d'un back-office pour l'exploitation quotidienne, d'un e-commerce intégré et de la capacité à monter en charge et évoluer pendant des années.

AppSheet est un produit Google, ce qui lui confère d'emblée une crédibilité que peu de concurrents peuvent revendiquer. Il est intégré dans Google Workspace, soutenu par l'infrastructure Google Cloud, et utilisé par Airbus, Husqvarna ou Solvay. Ce pedigree est réel. Quand nous avons appliqué notre brief AURORA à la plateforme, nous avons compris rapidement que cette crédibilité était méritée — juste sur un terrain différent de celui que nous explorions.

AppSheet est conçu pour les outils internes : une app d'inventaire pour vos équipes d'entrepôt, un formulaire d'inspection pour vos techniciens terrain, un CRM pour vos commerciaux. AURORA est une app mobile grand public — elle se télécharge sur l'App Store sous votre marque, par des clients que vous n'avez jamais rencontrés, et doit être opérée au quotidien par une équipe marketing qui ne verra jamais une feuille de calcul. Ce sont deux problèmes différents. Que les deux s'appellent "no-code" est précisément la source de confusion que cet article veut clarifier.

Cet article fait partie de notre série — même brief AURORA, même honnêteté, appliqués à chaque outil évalué. Si vous comparez en parallèle Adalo, Glide, Bubble ou d'autres plateformes, vous y trouverez le même cadre de lecture.

• AppSheet est conçu pour les outils internes — des apps distribuées au sein d'une organisation, utilisées par des membres authentifiés. Il n'est pas conçu pour des apps grand public publiées sous votre marque sur l'App Store et Google Play.
• Les apps AppSheet tournent dans le conteneur AppSheet ou sont distribuées sous forme d'APK/IPA privé pour la distribution interne. Les listings en stores pour des apps grand public indépendantes ne sont pas le cas d'usage standard.
• La tarification est à l'utilisateur : 10 $/utilisateur/mois en plan Core. Une équipe interne de 200 personnes coûte 2 000 $/mois. Une app grand public avec des milliers d'utilisateurs anonymes ne peut pas être tarifée ainsi.
• Il n'existe pas de module e-commerce intégré, pas de campagnes push vers les utilisateurs externes, pas de CMS éditorial back-office dans AppSheet.
• AppSheet s'intègre profondément avec Google Workspace — c'est le bon choix si votre organisation tourne sous Google Sheets et a besoin d'automatiser des processus internes rapidement.
• GoodBarber compile des apps Swift (iOS) et Kotlin (Android) natives, gère la soumission en stores et fournit un back-office pour la gestion quotidienne du contenu, des push et de l'e-commerce — dans un seul abonnement.

AURORA est le test que nous appliquons à chaque outil de la série : un guide de voyage luxe. Il exige une navigation multi-rubriques, une identité visuelle personnalisée (couleurs, typographie, logo), des comptes utilisateurs avec authentification, des notifications push, une couche de gestion éditoriale pour des mises à jour régulières, une couche de monétisation, une intégration de données en temps réel, un chatbot IA et une publication sur l'App Store et Google Play.

AURORA n'est pas un outil interne. Ses utilisateurs sont des clients qui n'ont jamais eu de compte Google au sein d'une organisation. Ils parcourent des guides de destinations, réservent des expériences, reçoivent des campagnes push promotionnelles et effectuent des achats. Ce brief représente le type d'application qu'une marque média, une entreprise de voyage ou un commerce local publierait et opérerait pendant des années — pas un outil de workflow pour une équipe de techniciens terrain.

GoodBarber : une plateforme gérée pour les apps mobiles grand public

GoodBarber construit des outils de création d'apps depuis 2011, avec une cible fixe : les créateurs et entreprises qui veulent publier une app professionnelle sur l'App Store et Google Play, puis la gérer indéfiniment sans aide de développeur. Le back-office prend en charge le contenu, les notifications push, l'e-commerce, les utilisateurs et les statistiques. iOS compile en Swift natif, Android en Kotlin natif. La même configuration génère également une PWA. Quinze ans d'itération sur ce cas d'usage précis — les apps mobiles grand public opérées par des équipes non techniques — se reflètent dans la plateforme.

AppSheet : une plateforme no-code alimentée par Google pour les processus métier internes

AppSheet a été fondé en 2014 et acquis par Google en 2020, désormais profondément intégré dans Google Cloud et Google Workspace. Sa promesse en page d'accueil est directe : "Supercharge your work with no-code." Le mot "work" n'est pas là par hasard — AppSheet est un outil pour automatiser et mobiliser des processus métier : formulaires, collecte de données, inventaire, inspections, workflows CRM, coordination terrain. Gemini peut désormais générer des apps depuis des descriptions en langage naturel, et la prise en charge native des codes-barres, NFC, GPS et du mode hors-ligne reflète le focus terrain de la plateforme. Pour ce cas d'usage, AppSheet est réellement rapide et puissant.

En travaillant le brief AURORA face aux capacités d'AppSheet, l'expérience n'a pas tant révélé des choses difficiles à construire qu'une inadéquation fondamentale de conception.

Authentification et données : AppSheet exige une source de données — une feuille Google Sheets, un fichier Excel, une base de données connectée — avant de pouvoir construire quoi que ce soit. Nous avons connecté un Google Sheet. L'authentification utilisateur fonctionnait via les comptes Google. Mais chaque contenu d'AURORA — guides de destinations, rubriques éditoriales, tarifs — devait d'abord vivre dans un tableur. C'est fonctionnel pour des données métier structurées. C'est un frein pour du contenu éditorial.

Gestion de contenu : Il n'existe pas de CMS éditorial dans AppSheet. Publier un nouveau guide de destination pour AURORA signifie ajouter des lignes dans une feuille de calcul. C'est une approche viable pour une équipe déjà native Google Sheets ; c'est un point de friction significatif pour une équipe éditoriale habituée à une interface de publication dédiée.

Notifications push : AppSheet prend en charge le push pour les utilisateurs internes authentifiés. Pour la base utilisateurs d'AURORA — des clients anonymes ayant téléchargé l'app — le push n'est pas disponible. C'est un manque fondamental pour le marketing d'une app grand public.

E-commerce : Il n'existe pas de module e-commerce intégré. AppSheet n'a ni couche de paiement, ni catalogue produit, ni tunnel de commande. La couche de monétisation d'AURORA nécessiterait de construire cela from scratch ou de connecter un service entièrement externe.

Distribution en stores : Les apps AppSheet sont distribuées via l'app conteneur AppSheet (disponible sur l'App Store et Google Play sous la marque AppSheet), ou sous forme d'APK/IPA privé pour la distribution interne. Elles ne sont pas listées de façon indépendante comme des apps grand public sous votre propre marque. AURORA a besoin de son propre listing App Store, sa propre icône, sa propre page de store. Ce n'est pas le modèle d'AppSheet.

Ce qui fonctionne bien : Pour une application à usage interne, AppSheet est rapide. L'intégration Google Workspace est sans friction. Si AURORA avait été un outil opérationnel pour les équipes internes d'une agence de voyage, AppSheet aurait été un bon point de départ.

La différence qui a compté pour AURORA n'était pas une fonctionnalité isolée — c'était l'ensemble du modèle : à qui s'adresse l'app.

GoodBarber est conçu pour la distribution grand public. Chaque app est publiée de façon indépendante sur l'App Store sous le nom de la marque, avec sa propre icône, sa propre description en store. Le service GBTC de GoodBarber gère le processus de revue Apple — un processus qui rejette environ 42 % des premières soumissions. Ceux qui ne connaissent pas les directives de revue d'Apple naviguent avec de l'aide ; notre taux de récupération sur les soumissions rejetées est de 91 %.

Pour la gestion de contenu, le back-office de GoodBarber fonctionne comme un CMS — les éditeurs créent des rubriques, publient des articles, planifient des mises à jour — sans toucher un tableur. Le même back-office envoie des campagnes push directement aux utilisateurs finaux d'AURORA, avec segmentation et planification. Pour l'e-commerce, GoodBarber inclut un tunnel de commande complet avec 0 % de commission sur les transactions et 22 moyens de paiement, couvrant les marchés mondiaux et régionaux.

Sur la tarification, les modèles sont structurellement différents. Le plan Core d'AppSheet coûte 10 $/utilisateur/mois. Pour un outil interne utilisé par 50 personnes, c'est 500 $/mois. Pour une app grand public avec des milliers d'utilisateurs anonymes, ce modèle ne s'applique pas. Le plan Premium de GoodBarber à 70 €/mois couvre un nombre illimité d'utilisateurs finaux, avec des builds iOS et Android natifs, le push, le CMS et l'e-commerce inclus.

Le RAG chatbot dont AURORA a besoin — qui répond aux questions des voyageurs à partir du contenu publié de l'app — est une fonctionnalité native de GoodBarber. Le serveur MCP avec 30 Skills Claude étend cela à la gestion de l'app en production par des agents IA.

Critère	GoodBarber	AppSheet
Sortie iOS	Swift natif (binaire compilé, listing App Store propre)	App conteneur (marque AppSheet) ou IPA privé pour distribution interne
Sortie Android	Kotlin natif (binaire compilé, listing Play Store propre)	App conteneur (marque AppSheet) ou APK privé pour distribution interne
PWA	Oui — incluse, même back-office	Non documenté comme sortie native
Utilisateur cible	Grand public (utilisateurs anonymes, téléchargement public)	Interne (membres authentifiés, distribution privée)
Hébergement	Inclus	Inclus (Google Cloud)
Base de données	Incluse	Partielle — connexion Google Sheets / BD externe ; BD native incluse avec limites
Push (utilisateurs grand public)	Oui — campagnes vers utilisateurs finaux externes	Non — utilisateurs internes authentifiés uniquement
E-commerce / paiement	Inclus, 0 % de commission, 22 moyens de paiement	Pas de module intégré
CMS back-office éditorial	Oui — conçu pour éditeurs non techniques	Non — contenu dans les feuilles de calcul connectées
Fonctionnalités IA	AI Extension Builder, RAG chatbot, serveur MCP + 30 Skills	Génération d'app avec Gemini, ML (Enterprise Plus uniquement)
Modèle tarifaire	Par app (70 €/mois Premium)	Par utilisateur (10 $/utilisateur/mois Core) ou 50 $/mois/app (Publisher Pro)
Intégration Google Workspace	Partielle — pas de connexion native Sheets/Drive	Profonde — Sheets, Drive, Gmail, Calendar, Docs
Période d'essai	Oui	Oui (jusqu'à 10 utilisateurs de test)

AppSheet et GoodBarber partent d'hypothèses différentes sur qui utilise l'app. AppSheet suppose des collègues authentifiés dans une organisation gérée ; GoodBarber suppose des clients anonymes dans un marketplace public. Aucun n'est dans l'erreur — ils sont calibrés pour des missions genuinement différentes.

La façon la plus claire de comprendre cette comparaison passe par le comptage des utilisateurs. La tarification par utilisateur d'AppSheet est parfaitement logique quand votre app compte 20 techniciens terrain qui se connectent chaque jour et dont l'accès est contrôlé par votre IT. Elle devient inapplicable à l'instant où votre app touche des milliers de clients qui n'ont jamais figuré dans votre annuaire.

Le plan Publisher Pro d'AppSheet reconnaît cette tension : 50 $/mois/app pour des apps grand public sans limite d'utilisateurs. Mais Publisher Pro n'ajoute pas les notifications push pour les utilisateurs externes, ni le module e-commerce, ni un listing App Store sous votre propre marque. Il supprime la contrainte de tarification par utilisateur sans ajouter la suite de fonctionnalités d'une app grand public.

Ce n'est pas une faiblesse d'AppSheet — c'est le reflet de ce pour quoi la plateforme a été conçue. Les limites des app builders no-code pour les apps grand public sont les mêmes que celles qui rendent AppSheet rapide et fiable pour les outils internes : une audience définie, des données structurées, des interactions pilotées par des processus. Les apps grand public nécessitent du branding, de la découverte, de l'acquisition et de la rétention — des dimensions que les outils internes n'ont tout simplement pas besoin d'adresser.

• Vous construisez un outil interne — une app utilisée par votre équipe, distribuée en privé au sein de votre organisation, pas publiée comme produit grand public en stores.
• Votre organisation tourne sous Google Workspace et vous voulez une app qui lit et écrit dans Google Sheets, Drive ou des bases de données connectées sans overhead d'intégration.
• Votre cas d'usage implique des opérations terrain : inventaire, inspections, collecte de données avec codes-barres, NFC, GPS, ou accès mobile hors-ligne — AppSheet excelle sur ces points.
• Votre base d'utilisateurs est un groupe défini et authentifié (employés, prestataires, partenaires) où la tarification par utilisateur est prévisible et maîtrisable.
• Vous avez besoin d'automatisations de workflows étroitement intégrées aux services Google — déclencheurs email, actions conditionnelles, synchronisation de données.

• Vous voulez une app grand public publiée sur l'App Store et Google Play sous votre propre marque, avec votre propre icône et votre propre page de store.
• Vous êtes une équipe non technique — un éditeur de contenu, un commerçant, une marque hôtelière, un commerce local — qui a besoin de gérer du contenu, d'envoyer des campagnes push et de faire de l'e-commerce depuis un back-office, pas un tableur.
• Votre app s'adresse à des utilisateurs externes anonymes — des clients qui ont téléchargé votre app, pas des employés qui se connectent avec un compte professionnel.
• Votre app inclut de l'e-commerce et vous avez besoin de 0 % de commission sur les transactions avec des moyens de paiement intégrés pour vos marchés.
• Vous voulez que toute votre stack — hébergement, base de données, push, CMS, paiements, statistiques — soit couverte par un seul abonnement.

AppSheet et GoodBarber répondent tous les deux légitimement à "je veux créer une app no-code" — mais à deux versions différentes de cette question. AppSheet répond à : "Je veux mobiliser un processus métier pour mon équipe, rapidement, dans mon infrastructure Google existante." GoodBarber répond à : "Je veux publier un produit que mes clients peuvent découvrir, télécharger et acheter."

AURORA, c'est la deuxième question. Si votre question est la première — et beaucoup d'organisations se posent genuinement cette première question — AppSheet mérite d'être sérieusement considéré, surtout si vos données vivent déjà dans Google Sheets.

Si votre question est la seconde, commencez votre essai gratuit et construisez AURORA sur la plateforme pensée pour le moment où un client ouvre votre app pour la première fois sur l'App Store.

• GoodBarber vs Bubble
• GoodBarber vs Base44
• GoodBarber vs Glide
• GoodBarber vs Rork
• GoodBarber vs Emergent
• GoodBarber vs FlutterFlow
• GoodBarber vs Adalo
• Les 10 meilleurs app builders No-Code en 2026

AppSheet peut-il publier des apps sur l'App Store et Google Play sous votre propre marque ?

Pas via le workflow standard. Les apps AppSheet sont distribuées via l'app conteneur AppSheet (sous la marque AppSheet) ou sous forme d'APK/IPA privé pour la distribution interne. Publier une app grand public indépendante sous votre propre marque en stores n'est pas le cas d'usage conçu par AppSheet.

AppSheet est-il gratuit ?

Le plan Core d'AppSheet est inclus dans la plupart des comptes Google Workspace payants. Une phase de prototype gratuite permet de tester avec jusqu'à 10 utilisateurs. Le déploiement complet commence à 5 $/utilisateur/mois (Starter) ou 10 $/utilisateur/mois (Core). Un plan pour apps publiques (Publisher Pro) est disponible à 50 $/mois par app pour des utilisateurs illimités.

AppSheet prend-il en charge les notifications push pour les apps grand public ?

Le push dans AppSheet est conçu pour les utilisateurs internes authentifiés — pas pour les utilisateurs externes anonymes d'une app grand public. Si votre app doit envoyer des campagnes push promotionnelles ou éditoriales à des clients qui l'ont téléchargée sur l'App Store, AppSheet ne couvre pas ce cas d'usage.

Quelle est la différence entre AppSheet et GoodBarber pour l'e-commerce ?

AppSheet n'a pas de module e-commerce ou de paiement intégré. GoodBarber inclut une couche e-commerce complète avec 0 % de commission sur les transactions et 22 moyens de paiement dans chaque plan eCommerce Apps.

Quand choisir AppSheet plutôt que GoodBarber ?

AppSheet est le meilleur choix pour construire un outil interne destiné à une équipe définie d'utilisateurs authentifiés — inspections terrain, gestion d'inventaire, workflows CRM, collecte de données — surtout si votre organisation tourne déjà sous Google Workspace. GoodBarber est le meilleur choix pour construire une app mobile grand public destinée à des utilisateurs externes, avec distribution en stores, contenu éditorial, campagnes push marketing et e-commerce.

Bolt.new était impossible à ignorer depuis son lancement en octobre 2024. 20 millions de dollars d'ARR en deux mois, sept millions d'utilisateurs en moins d'un an — nous avons décidé de le tester sérieusement, pas d'y faire un tour rapide. Nous avons appliqué le même brief qu'à toute notre série : AURORA, un guide de voyage luxe avec distribution native en stores, mises à jour éditoriales quotidiennes, campagnes push, gestion des utilisateurs et couche e-commerce.

Nous avons construit AURORA sur Bolt.new. Nous l'avons construit sur GoodBarber. Ce qui suit est le récit honnête des deux expériences — avec les moments où Bolt nous a impressionnés, et ceux où les chemins ont divergé de façon à rendre les deux outils incomparables.

Cet article fait partie de notre série — même brief, même grille de lecture, appliqués à chaque outil majeur que nous avons évalué. Si vous regardez aussi Base44, Emergent, Adalo ou FlutterFlow, vous y retrouverez un cadre cohérent.

• Bolt.new est rapide. Nous avions un prototype web fonctionnel en moins d'une heure. La qualité du rendu après import Figma nous a surpris.
• Mettre ce prototype sur iOS et Android a nécessité d'installer un outillage de développeur en local, créer des comptes Apple et Google, configurer des certificats de signature de code, et soumettre manuellement. Bolt génère le code — le pipeline en stores est entièrement à votre charge.
• Il n'existe pas de back-office dans Bolt. Chaque mise à jour de contenu d'AURORA après le lancement passe par le code. Les notifications push nécessitent une intégration tierce. Il n'y a pas de CMS.
• Le modèle à tokens a rendu nos coûts d'itération imprévisibles. Dès qu'on touchait à une fonctionnalité complexe et qu'on devait aller-retour avec l'IA, on sentait le compteur tourner.
• Dans GoodBarber, le contenu, le push et l'e-commerce d'AURORA ont tous été gérés depuis le même back-office, sans jamais ouvrir un éditeur de code. Les builds iOS et Android natifs sont passés par le service GBTC.
• Les deux outils sont légitimes — ils résolvent des problèmes différents pour des opérateurs différents. La question, c'est lequel est le vôtre.

AURORA est le test que nous appliquons à chaque outil de la série : un guide de voyage luxe. Il exige une navigation multi-rubriques, une identité visuelle personnalisée (couleurs, typographie, logo), des comptes utilisateurs avec authentification, des notifications push, une couche de gestion éditoriale pour des mises à jour régulières, une couche de monétisation, une intégration de données en temps réel (météo ou équivalent), un chatbot IA, et une publication sur l'App Store et Google Play.

Nous avons choisi ce brief exprès. AURORA n'est pas un jouet. Il représente le type d'application qu'une vraie entreprise devrait lancer et maintenir pendant des années — pas une preuve de concept, pas un outil interne. La comparaison ne devient intéressante que quand le brief est suffisamment exigeant pour révéler de vraies différences.

GoodBarber : une plateforme gérée pour le cycle de vie complet

GoodBarber construit des outils de création d'apps depuis 2011. Son pari a toujours été le même : un créateur non technique doit pouvoir lancer une app mobile native professionnelle — et ensuite la faire tourner, sans aide de développeur, indéfiniment. La plateforme compile les apps iOS en Swift natif et les apps Android en Kotlin natif. Le back-office gère le contenu, les push, l'e-commerce, les utilisateurs et les statistiques — dans une seule interface, incluse dans l'abonnement. Une PWA est également générée depuis la même configuration.

La couche IA s'étend dans les deux directions : un AI Extension Builder pour créer des sections personnalisées par prompt, et un serveur MCP avec 30 Skills Claude publiés qui permettent à des agents IA d'opérer une app en production par langage naturel. Le RAG chatbot — qui répond aux questions des utilisateurs à partir du contenu publié de l'app — est une fonctionnalité structurée, pas une intégration personnalisée à construire.

Bolt.new : un générateur de code de niveau professionnel, accessible à tous

Bolt.new est construit sur StackBlitz, une entreprise avec un long historique d'outils de développement dans le navigateur. Cet héritage est visible partout. La synchronisation bidirectionnelle avec GitHub est réelle. L'import de frames Figma a fonctionné mieux qu'on ne le prévoyait. La possibilité de basculer entre Claude Opus, Sonnet et Haiku en cours de session est une fonctionnalité pour utilisateurs avancés. La description que la plateforme fait d'elle-même — "vibe coding goes pro" — est juste : Bolt n'est pas un jouet pour générer des landing pages. Il génère du code de qualité professionnelle et vous le remet entre les mains.

C'est précisément ce remise en main qu'il faut prendre le temps d'examiner.

Nous avons ouvert Bolt.new, décrit AURORA dans un prompt et regardé apparaître une app React structurée en une dizaine de minutes. Le résultat avait une vraie ossature : navigation multi-rubriques, mise en page propre, design responsive. Quand nous avons importé un frame Figma existant pour l'identité visuelle, Bolt l'a traduit fidèlement. Cette partie de l'expérience était franchement bonne.

L'authentification fonctionnait d'emblée. Nous avons demandé des comptes utilisateurs, Bolt les a créés.

La gestion de contenu, c'est là que les choses ont commencé à changer. AURORA a besoin qu'une équipe éditoriale mette à jour des guides de destinations sans passer par un développeur. Il n'y a pas de CMS dans Bolt — le contenu est dans le code. Chaque mise à jour éditoriale implique une modification du code, un redéploiement, et quelqu'un capable de faire tout ça. Nous avons demandé à Bolt de connecter un CMS headless externe ; il a généré l'intégration, mais nous avions désormais une deuxième plateforme à gérer.

Les notifications push ont suivi le même schéma. Bolt n'inclut pas le push. Nous avons suivi le chemin documenté via Progressier — ça fonctionne, mais ça a ajouté un compte, une couche de configuration et un coût mensuel qui n'apparaît pas sur la page de tarification de Bolt.

L'e-commerce est passé par Stripe. Bolt l'a connecté proprement. Mais c'est une intégration, pas un module — elle repose sur un compte Stripe, des frais Stripe, et l'interface Stripe pour gérer les commandes et les virements. Pour la gestion e-commerce quotidienne d'AURORA, nous nous retrouvions à jongler entre trois tableaux de bord différents.

La publication en stores, c'est là que nous nous sommes arrêtés pour reconsidérer la situation. Le chemin mobile de Bolt passe par Expo et React Native. La documentation est honnête sur ce que ça implique : Node.js, EAS CLI et Git installés en local ; un compte Apple Developer (99 $/an) ; un compte Google Play Developer (25 $ unique) ; des certificats de signature de code à configurer ; et des soumissions manuelles dans App Store Connect et la Google Play Console. Apple a rejeté notre première soumission — ce qui arrive à environ 42 % des premières soumissions, quel que soit l'outil utilisé. Mais sans équipe de support pour naviguer dans le processus, nous avons géré seuls. Le slug, une fois défini, ne peut plus être modifié — un détail qui devient une contrainte la première fois qu'on veut renommer l'app.

La version web d'AURORA était prête rapidement. L'app native en stores a demandé beaucoup plus de temps, un travail technique significatif, et aurait été très difficile à mener à bien pour quelqu'un sans compétences de développeur.

Quand nous avons construit AURORA dans GoodBarber, la différence la plus marquante était le back-office. Pas seulement qu'il existe — mais ce qu'il couvre. Envoyer une notification push à tous les utilisateurs qui ont visité la rubrique Paris cette semaine est une opération de trois minutes dans le back-office de GoodBarber. Dans une app générée par Bolt, c'est une configuration Progressier, une logique de segmentation à construire quelque part, et un envoi qui se fait dans un tableau de bord tiers.

La sortie native a fait une différence visible pour la soumission en stores. Les apps GoodBarber compilent en Swift natif et en Kotlin natif — pas des wrappers React Native. Quand nous avons soumis AURORA via le service GBTC, l'équipe a géré le processus de revue Apple, récupéré un build rejeté, et obtenu la mise en ligne. Le bilan de GoodBarber : 91 % de taux de récupération sur les rejets de première soumission, et 5 % de taux de rejet sur les mises à jour suivantes. Nous n'avons configuré aucun certificat.

Sur la tarification, la comparaison mérite d'être faite sérieusement. Le plan Pro de Bolt est à 25 $/mois. Ça couvre l'hébergement, une base de données et des statistiques. Le push nécessite Progressier (coût séparé). Un CMS en production nécessite un service headless (coût séparé). Stripe prend des frais de transaction. Une fois qu'AURORA tourne à pleine vitesse — campagnes push, publication de contenu, traitement e-commerce — la stack Bolt coûte davantage que la ligne d'abonnement ne le laisse penser.

Le plan Premium de GoodBarber à 70 €/mois inclut hébergement, base de données, push (30 000/mois), CMS, e-commerce à 0 % de commission, authentification utilisateurs, achats in-app et module fidélité. C'est la stack opérationnelle complète d'AURORA, sur une seule facture.

Côté IA : le RAG chatbot dont AURORA avait besoin — un chatbot qui répond aux questions des voyageurs à partir des guides publiés dans l'app — est une fonctionnalité native de GoodBarber. Nous l'avons activé depuis le back-office. Avec Bolt, nous aurions généré une intégration personnalisée contre une API LLM, payé ces appels API séparément, et été responsables de maintenir cette intégration à chaque changement d'API.

Critère	GoodBarber	Bolt.new
Sortie iOS	Swift natif (binaire compilé)	React Native via Expo — pipeline de déploiement à la charge de l'utilisateur
Sortie Android	Kotlin natif (binaire compilé)	React Native via Expo — pipeline de déploiement à la charge de l'utilisateur
PWA	Oui — incluse, même back-office	Via intégration tierce (Progressier)
Hébergement	Inclus	Inclus (Bolt Cloud)
Base de données	Incluse	Incluse
Notifications push	Incluses (10 000 à 250 000/mois selon le plan)	Externe uniquement — service tiers requis
Gestion de contenu (CMS)	Oui — back-office structuré, sans code	Non — le contenu est dans le code source
Paiements / e-commerce	Inclus, 0 % de commission, 22 moyens de paiement	Via intégration Stripe (externe, frais de transaction)
Back-office d'exploitation quotidienne	Oui — conçu pour des opérateurs non techniques	Non — tâches post-lancement dans le code ou via services externes
Soumission en stores	Prise en charge (service GBTC)	À la charge de l'utilisateur — outillage local + comptes stores
Fonctionnalités IA	AI Extension Builder, RAG chatbot, serveur MCP + 30 Skills	Génération de code, Design System Agents, choix de modèle
Propriété du code	Non applicable (plateforme gérée)	Totale — code source exportable via GitHub
Modèle tarifaire	Abonnement mensuel fixe (70 €/mois Premium)	À la consommation — 25 $/mois Pro, 10 M tokens/mois
Période d'essai	Oui	Plan gratuit (1 M de tokens/mois)

Le tableau de Bolt n'est pas faible — la propriété du code, l'import Figma et la synchronisation GitHub sont des capacités réelles qu'aucune plateforme comparable ne propose. Ce tableau reflète deux outils genuinement différents, et le bon choix dépend du projet.

Ce que Bolt vous donne — la propriété totale du code généré, librement exportable, définitivement à vous — est un avantage réel pour un certain type de projet. Si vous êtes un développeur en train de valider une idée avant de la confier à une équipe d'ingénieurs, si vous construisez un outil interne qu'une personne technique maintiendra, ou si vous avez besoin d'une portabilité maximale et de la capacité à modifier la stack sous-jacente, le modèle de Bolt a du sens.

AURORA un mois après le lancement, c'est un autre scénario. Quelqu'un dans l'équipe doit publier de nouveaux guides de destinations ce jeudi. Quelqu'un doit envoyer une campagne push pour une promotion du week-end. Quelqu'un doit traiter un retour, vérifier les stats de conversion, et soumettre une mise à jour en App Store avant la fin de la semaine. Dans une base de code générée par Bolt, chacune de ces tâches passe soit par une modification du code et un redéploiement, soit par un tableau de bord tiers que l'équipe a dû apprendre séparément.

Nous avons lu les avis sur G2 et Trustpilot pendant que nous construisions. Le schéma était cohérent : des utilisateurs qui adoraient Bolt pour leur premier prototype ont rencontré des frictions quand le projet a mûri — tokens consommés plus vite que prévu, support difficile à joindre, une modification à un endroit qui casse quelque chose d'inattendu ailleurs. Ce ne sont pas des plaintes inhabituelles pour un outil qui génère du code plutôt que de gérer un produit. Le code grossit ; le rôle de l'outil s'arrête.

Une plateforme conçue pour l'exploitation n'a pas ce problème — parce que l'exploitation a été pensée dès le départ.

• Vous construisez une application web — un site, un outil, un produit web — pas une app mobile native pour la distribution en stores.
• Vous voulez avancer vite sur un prototype ou un MVP et avoir quelque chose d'utilisable rapidement. Bolt est réellement plus rapide que tout ce que nous avons testé pour la vitesse de premier build.
• Vous êtes à l'aise avec le code, ou vous avez un développeur qui prendra le relais après la phase de génération.
• La portabilité du code compte pour vous — vous voulez tout posséder, tout exporter sur GitHub, être libre de l'étendre ou de le transmettre.
• Votre projet ne nécessite pas qu'un opérateur non technique gère du contenu, des push ou de l'e-commerce au quotidien via une interface.

• Vous voulez des apps iOS et Android natives en stores — compilées en Swift et Kotlin, avec la soumission App Store gérée par des gens qui connaissent le processus de revue Apple.
• Vous êtes un opérateur non technique — un éditeur de contenu, un commerçant, une collectivité, une association — qui a besoin de gérer du contenu, des campagnes push et de l'e-commerce depuis une interface, pas une base de code.
• Vous construisez une app pour le long terme : quelque chose que vous exploiterez quotidiennement, mettrez à jour régulièrement, et ferez évoluer pendant des années.
• Votre app inclut du commerce en ligne et vous avez besoin de 0 % de commission sur les transactions avec 22 moyens de paiement intégrés sur les marchés mondiaux et régionaux.
• Vous voulez que toute votre stack opérationnelle — hébergement, base de données, push, CMS, paiements, statistiques — soit couverte par un seul abonnement, sans assembler des services externes.

Bolt.new est la chose la plus rapide que nous ayons testée pour aller d'une idée à un prototype fonctionnel. Cette rapidité est réelle, et nous le disons comme un vrai compliment. Le code qu'il produit est de niveau professionnel. L'import Figma fonctionne. La synchronisation GitHub est utile. Pour une équipe technique qui veut avancer vite et prendre la propriété du résultat, Bolt est un choix sérieux.

AURORA est un autre brief. C'est une app qui doit être en stores le trimestre prochain et opérée par une équipe marketing pendant les cinq années suivantes. Pour ce projet, la question n'est pas seulement "peut-on livrer la première version ?" — c'est "qui gère la campagne push mardi prochain, la mise à jour de contenu d'après, et la revue App Store le mois suivant ?"

GoodBarber a été conçu pour ce deuxième ensemble de questions. Commencez votre essai gratuit et construisez AURORA sur la plateforme pensée pour ceux qui font tourner des apps, pas seulement pour ceux qui les démarrent.

• GoodBarber vs Bubble
• GoodBarber vs Base44
• GoodBarber vs Glide
• GoodBarber vs Rork
• GoodBarber vs Emergent
• GoodBarber vs FlutterFlow
• GoodBarber vs Adalo
• Les 10 meilleurs app builders No-Code en 2026

Bolt.new crée-t-il des apps iOS et Android natives ?

Bolt.new génère des applications web. La distribution native en stores est possible via Expo et React Native, mais l'intégralité du pipeline de déploiement — compte Apple Developer, compte Google Play, configuration du code signing, EAS CLI, soumissions manuelles — est à la charge de l'utilisateur. Nous avons traversé ce processus pour AURORA : il demande un travail technique réel.

Quelle est la différence entre la tarification à tokens de Bolt.new et l'abonnement GoodBarber ?

Bolt.new facture à la consommation de tokens : le plan Pro inclut 10 millions de tokens par mois à 25 $. En pratique, le développement itératif sur une fonctionnalité complexe épuise cette allocation rapidement. GoodBarber facture un abonnement mensuel fixe (à partir de 70 €/mois pour le plan Premium) qui couvre l'ensemble des usages sans variabilité à la consommation — vous savez ce que vous payez chaque mois.

Bolt.new inclut-il un CMS pour gérer le contenu après le lancement ?

Non. Le contenu d'une app générée par Bolt vit dans le code source. Le mettre à jour après le lancement implique une modification du code et un redéploiement, ou de connecter un CMS headless externe. GoodBarber inclut un back-office CMS structuré dans tous les plans — les opérateurs mettent à jour le contenu, publient des rubriques et gèrent les articles sans toucher au code.

Peut-on envoyer des notifications push avec Bolt.new ?

Pas nativement. Le push nécessite un service tiers comme Progressier. GoodBarber inclut les campagnes de push dans tous les plans, directement depuis le back-office, sans service externe requis.

GoodBarber convient-il aux développeurs qui souhaitent accéder au code ?

GoodBarber est une plateforme gérée et n'expose pas le code source. Si la propriété totale du code est une exigence — parce qu'une équipe de développeurs étendra l'app ou parce que la portabilité est une priorité — Bolt.new est le choix le plus adapté. GoodBarber est conçu pour des opérateurs qui veulent un produit géré, pas une base de code à maintenir.

Créer une notification push peut sembler simple au départ : écrire un message, choisir une audience, envoyer.

Mais dans un usage réel, les demandes sont souvent plus précises :

• envoyer la notification demain matin ;
• cibler uniquement les utilisateurs iOS et Android ;
• ouvrir une section précise de l’app ;
• rediriger vers un article, un produit ou une URL ;
• cibler un groupe d’utilisateurs ;
• envoyer un message à un utilisateur spécifique ;
• programmer l’envoi selon l’heure locale des utilisateurs.

Jusqu’ici, ce type de configuration demandait de passer manuellement par plusieurs réglages. Avec le serveur MCP enrichi, l’utilisateur peut formuler son besoin dans une phrase naturelle.

Par exemple :

“Envoie une notification push vendredi à 10h aux utilisateurs iOS et PWA pour leur annoncer la sortie de ma nouvelle émission, et ouvre la section Web TV quand ils cliquent.”

L’assistant doit alors comprendre trois éléments essentiels :

1. le message à envoyer ;
2. l’audience concernée ;
3. l’action à déclencher au clic.

C’est précisément ce qui rend cette mise à jour intéressante : l’IA ne se contente pas d’écrire un texte. Elle interprète une intention de communication complète.

Le timing est un élément central dans une stratégie push.

Une notification envoyée immédiatement peut être utile pour une information urgente : une breaking news, une offre limitée, un changement de programme.

Mais de nombreux cas nécessitent une programmation : lancement de contenu, rappel d’événement, annonce commerciale, relance d’abonnés.

La nouvelle version permet de gérer plusieurs types de planification :

• envoi immédiat ;
• envoi à une date et une heure précises ;
• programmation le lendemain ;
• programmation un jour donné de la semaine ;
• prise en compte de l’heure locale des utilisateurs.

Ce dernier point est particulièrement utile pour les apps dont l’audience est répartie sur plusieurs fuseaux horaires.

Vous pouvez demander un envoi à 10h “heure locale des utilisateurs”, afin d’éviter qu’une notification pertinente arrive au mauvais moment dans certaines zones.

Exemple :

“Programme une notification mardi 2 juin à 10h, heure locale des utilisateurs, pour annoncer la nouvelle fonctionnalité, et ouvre l’article associé quand la notification est ouverte.”

L’assistant peut ainsi aider à passer d’une intention éditoriale à une notification opérationnelle.

Une bonne notification push dépend autant de son audience que de son message.

Envoyer la même notification à tous les utilisateurs peut être pertinent dans certains cas : annonce importante, information générale, lancement majeur.

Mais dans beaucoup de situations, il est préférable de segmenter.

La nouvelle version du MCP permet de couvrir des scénarios de ciblage beaucoup plus fins.

Vous pouvez cibler selon :

• la plateforme : iOS, Android, PWA ou combinaison de plateformes ;
• les groupes d’utilisateurs ;
• le nombre de lancements de l’app sur les 30 derniers jours ;
• les utilisateurs qui n’ont jamais reçu de push ;
• la langue de l’appareil ;
• la position géographique ;
• un utilisateur identifié ;
• des prospects ou clients ;
• le statut d’abonnement dans les apps avec membership.

Cela ouvre des cas d’usage plus proches des besoins quotidiens des éditeurs, commerçants et créateurs d’apps.

Un média peut relancer les lecteurs peu actifs.

Une communauté peut contacter un groupe précis.

Une app de contenu premium peut parler différemment aux abonnés actifs, expirés ou non abonnés.

Une boutique peut cibler des clients ou prospects autour d’un produit.

Ce niveau de précision permet d’éviter les notifications trop générales.

Le message peut devenir plus utile, plus contextuel et plus respectueux de l’attention de l’utilisateur.

Une notification push ne doit pas seulement informer.

Elle doit aussi guider l’utilisateur vers la bonne action.

C’est souvent là que la configuration devient plus délicate. Le clic peut ouvrir :

• l’application ;
• une URL externe ;
• une section de l’app ;
• un article ;
• un point de carte ;
• une page produit ;
• un contenu spécifique.

La mise à jour du serveur MCP permet de mieux gérer ces destinations.

L’utilisateur peut demander directement à l’assistant d’ouvrir une section ou un contenu précis quand la notification est cliquée.

Exemple pour une app de contenu :

“Envoie une notification aux utilisateurs PWA pour annoncer notre nouvel article, et ouvre directement cet article quand ils cliquent.”

Exemple pour une app eCommerce :

“Programme une notification pour annoncer une promotion sur ce produit, et ouvre la page produit quand la notification est ouverte.”

Cette logique est importante : elle réduit le nombre d’étapes entre l’intérêt de l’utilisateur et l’action attendue.

Un lecteur arrive sur le bon article. Un client arrive sur le bon produit. Un abonné arrive sur le contenu qui le concerne.

L’intérêt de cette mise à jour est qu’elle ne concerne pas un seul type d’app.

Pour une app de contenu, le MCP peut aider à annoncer un nouvel article, une vidéo, une émission, un événement ou un point d’intérêt.

L’assistant peut comprendre que la notification doit ouvrir une section CMS ou un contenu précis.

Pour une app communautaire, il devient possible de formuler des demandes de ciblage plus naturelles : envoyer un message à un groupe, à certains utilisateurs, ou à une audience définie par son comportement.

Pour une app avec abonnements, les notifications peuvent être utilisées pour parler aux abonnés actifs, aux abonnés expirés ou aux utilisateurs sans abonnement.

C’est particulièrement utile pour annoncer de nouveaux contenus premium, encourager une réactivation ou maintenir l’engagement.

Pour une app eCommerce, les scénarios se concentrent sur la mise en avant de produits, de collections, d’articles liés à la boutique ou d’informations commerciales.

Une notification peut annoncer une promotion et ouvrir directement la page produit concernée.

Cette polyvalence est importante pour GoodBarber : le serveur MCP ne sert pas seulement à “faire une action technique”. Il s’adapte aux usages réels des apps créées avec la plateforme.

Avec cette nouvelle version, le serveur MCP GoodBarber franchit une étape importante.

Après avoir permis de piloter l’app et de gérer des contenus CMS, il devient capable d’accompagner la création de notifications push plus précises. Les utilisateurs peuvent formuler des demandes complètes : message, horaire, audience, plateforme et destination.

C’est une évolution naturelle pour GoodBarber.

Une app n’est pas seulement un espace de publication. C’est aussi un canal de relation directe avec ses utilisateurs.

Les notifications push jouent un rôle central dans cette relation, à condition d’être bien préparées.

Grâce au MCP, cette préparation devient plus fluide. Vous pouvez passer d’une intention simple — “prévenir mes abonnés”, “annoncer un produit”, “relancer un groupe”, “ouvrir cet article” — à une notification structurée, prête à être utilisée dans votre app.

Si vous utilisez déjà le serveur MCP GoodBarber, cette mise à jour ouvre de nouveaux scénarios de communication à tester.

Si vous découvrez encore le MCP, c’est une bonne occasion de voir comment l’IA peut vous aider à gérer votre app de manière plus directe, plus naturelle et plus efficace.

Parmi les trois layouts de lancement de la nouvelle génération de TabBar, Clean TabBar est celui qui exprime le plus clairement une recherche de sobriété et de précision.

Ici, la navigation ne s’appuie ni sur des icônes très démonstratives, ni sur un fond fort pour signaler l’état actif. Elle repose sur une écriture plus discrète, plus textuelle, plus élégante. C’est un layout qui donne à la tabBar une place très lisible dans l’interface, tout en conservant une présence mesurée.

Clean TabBar fonctionne particulièrement bien dans les apps qui veulent laisser plus de place au contenu, au rythme de la page et à la qualité globale de la composition.

Le principe de Clean TabBar est simple : la navigation s’exprime d’abord par le texte.

Les intitulés deviennent les repères principaux. Cette approche donne immédiatement à la tabBar une tonalité plus éditoriale, plus posée, presque plus calme. La navigation paraît moins chargée, plus directe, et souvent plus naturelle dans les interfaces où le contenu, la mise en page et la typographie occupent déjà une place importante.

Ce choix change aussi le rythme visuel de l’écran. La barre de navigation devient plus légère dans sa construction, sans perdre en lisibilité. Elle accompagne l’interface avec discrétion, mais reste parfaitement identifiable.

Dans Clean TabBar, l’état actif n’est pas marqué par un fond appliqué au texte ou à l’icône. Il s’exprime de manière plus subtile, grâce à un indicateur de sélection.

Le composant permet ici de jouer avec plusieurs styles d’indicateurs :

• Dot
• Tiny
• Line

Cette variété est particulièrement intéressante, car elle permet d’ajuster très finement le niveau d’accent donné à l’item actif. Selon l’univers graphique de l’app, la sélection peut rester très discrète ou au contraire un peu plus affirmée, tout en conservant l’élégance propre au layout.

C’est l’un des points forts de Clean TabBar : elle montre qu’il est possible d’avoir une navigation très lisible sans passer par des effets visuels trop appuyés.

Comme les autres layouts de cette nouvelle génération de TabBar, Clean TabBar bénéficie d’animations de sélection qui s’adaptent au style retenu.

Ici, ces animations prennent tout leur sens, justement parce que la navigation repose sur des signes plus subtils. Le mouvement accompagne donc la sélection avec précision, sans surjouer l’effet. Il renforce la lisibilité du changement d’état et prolonge la sensation de finesse portée par le layout.

Cette cohérence entre dessin, indicateur de sélection et animation contribue beaucoup à la qualité perçue du composant.

Les effets haptics participent eux aussi à cette qualité d’exécution, en apportant une réponse tactile discrète et cohérente avec l’élégance du layout.

Le menu "More" de Clean TabBar, pour l'accès aux onglets masqués, prolonge cette même recherche de sobriété.

Lui aussi privilégie une présentation simple, très lisible, avec une hiérarchie visuelle nette et un dessin épuré. Il reste dans la continuité du layout, sans introduire de rupture de style avec la barre principale.

Sur mobile comme sur desktop, cette continuité fonctionne particulièrement bien. Le menu "More" conserve la même retenue, la même clarté, et la même qualité de présentation que la navigation elle-même. Il permet d’ouvrir l’arborescence sans alourdir l’expérience, ce qui correspond parfaitement à l’esprit du layout.

Clean TabBar montre qu’une navigation peut être à la fois très simple dans son apparence et très travaillée dans sa conception.

Avec son approche text-only, ses indicateurs de sélection, son absence de fond sur l’état actif et son menu "More" dans la continuité du layout, elle propose une lecture particulièrement élégante de la navigation mobile.

Pour les apps qui recherchent une navigation plus éditoriale, plus sobre et plus raffinée, Clean TabBar constitue une base particulièrement solide.

Quand quelqu'un dit qu'il veut "créer une app sans coder", la vraie question n'est pas de savoir quel outil est le plus intuitif. La vraie question, c'est : que se passe-t-il après la première publication ? Qui gère la mise à jour des contenus le mardi ? Qui envoie la notification push le vendredi ? Qui comprend pourquoi l'app ralentit avec cinq mille utilisateurs simultanés ?

Adalo et GoodBarber permettent tous les deux à un fondateur non technique de publier une app à l'apparence native en quelques jours — pas en quelques mois. Mais ils répondent à la question opérationnelle de façon très différente. Adalo vous donne un canvas et des briques pour assembler votre app. GoodBarber vous livre un produit déjà conçu, avec le back-office pour le faire vivre.

Pour mettre cette différence à l'épreuve, nous avons soumis les deux plateformes au même projet : AURORA — un guide de voyage de luxe avec des exigences précises en matière de design, de distribution et de gestion quotidienne.

• Adalo produit des apps React Native (hybrid) ; GoodBarber compile des binaires natifs Swift (iOS) et Kotlin (Android)
• Les notifications push nécessitent le plan Professional d'Adalo (52 $/mois) ; chez GoodBarber, elles sont incluses dès le tier Premium
• L'intégration des paiements Adalo passe par un compte Stripe externe ; GoodBarber inclut 22 passerelles de paiement avec 0 % de commission sur les transactions
• Adalo a un plafond de scalabilité documenté autour de 5 000 utilisateurs actifs — partiellement adressé par la refonte infrastructure 3.0 (fin 2025), mais les incidents de fiabilité de base de données restent une préoccupation réelle
• Les deux plateformes incluent une base de données intégrée ; GoodBarber y ajoute un CMS éditorial et un workflow de publication dédié
• Les deux incluent de l'IA dans le back-office de création ; GoodBarber étend l'IA aux utilisateurs finaux via un chatbot RAG et ouvre l'app aux agents IA via un serveur MCP

Pour rendre les comparaisons concrètes d'un article à l'autre, tous les articles de la série testent le même projet : AURORA, un guide de voyage de luxe. Le cahier des charges est volontairement exigeant — il couvre toutes les dimensions d'un projet éditorial ou commercial réel :

• Navigation multi-sections
• Design de marque sur mesure (couleurs, typographie, logo)
• Comptes utilisateurs et authentification
• Notifications push
• Gestion de contenu (CMS éditorial pour une publication régulière)
• Couche e-commerce ou monétisation
• Intégration de données en temps réel (météo ou équivalent)
• Chatbot IA pour les utilisateurs finaux
• Publication sur l'App Store et Google Play

Même cahier des charges, testé plateforme par plateforme — les comparaisons tiennent tout au long de la série.

GoodBarber : un produit intégré, pas un kit à assembler

Le postulat de GoodBarber est simple : un fondateur non technique ne devrait pas avoir à penser comme un architecte logiciel. Les fonctionnalités — notifications push, CMS, e-commerce, authentification — sont livrées pré-conçues et pré-intégrées. Vous configurez ; vous n'assemblez pas. Il n'y a pas de schéma de base de données à concevoir, pas d'écrans à câbler, pas d'API à connecter. Cette approche échange une flexibilité architecturale totale contre de la fiabilité à chaque phase du cycle de vie : du premier lancement à la troisième année d'exploitation quotidienne. Fondé en 2011, GoodBarber affine depuis quinze ans la même promesse : un abonnement, un back-office, tout inclus.

Adalo : le canvas visuel comme métaphore principale

Le positionnement d'Adalo est tout aussi clair : "Design native iOS, Android, and web apps on a visual multi-screen canvas with AI that builds alongside you." Le canvas est le produit. Vous faites glisser des composants, définissez vos collections de données, et câblez des actions conditionnelles entre les écrans — une approche plus granulaire, mais aussi plus ouverte que les constructeurs intégrés. L'assistant Ada AI, disponible sur tous les plans, peut générer une app multi-écrans complète à partir d'une description textuelle (Magic Start) ou ajouter des fonctionnalités en langage naturel (Magic Add). La contrepartie : chaque décision structurelle — forme de la base de données, logique d'écran, flux d'actions — revient au créateur.

La navigation multi-sections au cœur d'AURORA — c'est là qu'Adalo se montre dans son élément. On définit un schéma de collections (destinations, sections, hébergements), on construit les vues de liste et de détail, on câble la navigation. En quelques heures, l'architecture de l'information est en place. Le système de composants drag-and-drop gère la mise en page, et le marketplace de 50+ composants couvre les besoins moins courants comme les évaluations par étoiles ou la messagerie de groupe.

Le design de marque passe par les réglages de style d'Adalo — couleurs, polices, placement du logo — appliqués sur le canvas. Le niveau de contrôle visuel est réel, mais il opère composant par composant : il n'existe pas d'architecture de tokens de design globale appliquant la hiérarchie typographique et la sémantique des couleurs à l'échelle de l'app. Pour le positionnement luxe d'AURORA, maintenir la cohérence visuelle sur chaque écran demande de la rigueur manuelle plutôt qu'un système qui l'impose.

Les comptes utilisateurs et l'authentification sont inclus, tout comme la base de données pour stocker les profils. Les notifications push sont disponibles — mais uniquement à partir du plan Professional (52 $/mois). Sur le plan Starter (36 $/mois), l'équipe éditoriale d'AURORA n'a aucun moyen de contacter ses utilisateurs par push.

Pour la gestion de contenu, la base de données intégrée d'Adalo fait office de réservoir de contenus. Mais il n'existe pas de CMS éditorial dédié — pas de workflow pour les brouillons, les validations ou la publication programmée. Un éditeur met à jour les enregistrements directement dans l'interface de la base de données, ce qui fonctionne pour des cas simples, mais manque du cycle structuré qu'un guide de voyage avec plusieurs contributeurs appellerait.

E-commerce : Adalo supporte Stripe pour les paiements ponctuels et les abonnements via des composants marketplace, ainsi qu'IAPHub pour les achats intégrés. Ces intégrations fonctionnent — mais chacune nécessite de configurer un compte Stripe ou IAPHub séparé, de câbler le composant, et de gérer les cas limites de façon autonome. Pas de checkout unifié.

Données en temps réel (météo, contenu live) : accessibles via les External Collections d'Adalo, qui exposent des appels REST depuis n'importe quelle vue de liste. C'est flexible, mais cela suppose de connaître la forme de l'API et de construire l'appel manuellement.

Chatbot IA pour les utilisateurs finaux : non disponible. Ada opère uniquement dans le back-office de création. Les voyageurs qui utilisent AURORA n'auraient pas d'assistant IA intégré à l'app.

Publication : Adalo compile l'app React Native et gère le pipeline de build, mais les soumissions App Store et Google Play restent la responsabilité du créateur — avec les coûts associés (Apple Developer à 99 $/an, Google Play à 25 $ en one-time).

AURORA a deux vies : le jour du lancement, et tous les jours qui suivent.

Pour le design, le système Smart Design de GoodBarber transforme l'équation dès le premier écran. Plutôt que de gérer la cohérence visuelle composant par composant, les quatre meta-cells et les 80 templates appliquent les règles de marque — typographie, espacements, couleurs — à l'ensemble de l'app en une seule configuration. La conformité WCAG est appliquée automatiquement. Pour une marque de voyage de luxe où la présentation est le produit, cela compte autant à l'écran 40 qu'à l'écran 1.

Pour la gestion de contenu, le CMS intégré de GoodBarber donne à l'équipe éditoriale un vrai workflow : créer des sections, rédiger du contenu, programmer la publication, publier dans l'app — sans jamais toucher un schéma de base de données. Une équipe de contributeurs peut gérer la bibliothèque de destinations d'AURORA depuis une interface éditoriale pensée pour ça.

Pour l'exploitation quotidienne, les notifications push sont incluses dès le tier Premium. La couche e-commerce — pour des packages voyage, des expériences ou de la boutique — repose sur le checkout natif de GoodBarber, qui supporte 22 passerelles de paiement à 0 % de commission. Pas de compte Stripe externe à configurer, pas de frais de plateforme par transaction.

Pour l'IA côté utilisateur, le chatbot RAG de GoodBarber permet aux voyageurs qui utilisent AURORA de poser des questions auxquelles l'app répond à partir de son propre contenu publié — descriptions d'hôtels, guides de destinations, fiches d'activités. Ada chez Adalo reste côté back-office.

Pour les opérations pilotées par l'IA, GoodBarber livre un serveur MCP open source et 30 Claude Skills prêts à l'emploi. N'importe quel assistant compatible MCP — Claude, Cursor, ChatGPT — peut piloter l'app en langage naturel : programmer des pushs, traiter des commandes, interroger les statistiques. Adalo n'a pas d'équivalent.

Sur le plan technique, GoodBarber compile de vrais binaires natifs Swift (iOS) et Kotlin (Android). L'output React Native d'Adalo produit des apps validées par les stores — mais la pile native de GoodBarber offre une intégration OS plus profonde et un comportement plus prévisible lors des reviews App Store.

Critère	GoodBarber	Adalo
Output iOS	Swift natif (compilé)	React Native (hybrid)
Output Android	Kotlin natif (compilé)	React Native (hybrid)
PWA	Oui	Oui
Hébergement inclus	Oui	Oui (Postgres cloud)
Base de données incluse	Oui	Oui (intégrée + REST externe optionnel)
Notifications push	Incluses dès Premium	Plan Professional uniquement (52 $/mois)
Paiements / e-commerce	Inclus, 0 % de commission, 22 passerelles	Via Stripe (compte propre requis)
CMS / workflow éditorial	Oui, intégré	Non — gestion d'enregistrements en base de données
Chatbot IA utilisateurs finaux	Oui (chatbot RAG)	Non disponible
IA back-office	Oui (AI Extension Builder)	Oui (Ada : Magic Start, Magic Add, X-Ray)
Prêt pour les agents IA	Serveur MCP + 30 Claude Skills	Non disponible
Plan gratuit	Oui (construction et test, sans publication)	Oui (construction et test, sans publication)
Prix de départ (app native)	70 €/mois (Premium, mensuel)	52 $/mois (Professional, annuel)

Les deux plateformes ont des philosophies distinctes sur ce que le créateur doit apporter lui-même. Adalo lui donne un canvas et des composants pour concevoir la logique de l'app de zéro. GoodBarber livre des fonctionnalités pré-construites que le créateur configure selon son projet. Le bon choix dépend de si le projet exige une architecture sur mesure ou une profondeur fonctionnelle intégrée et fiable.

L'observation la plus constante dans les avis utilisateurs d'Adalo touche à deux points liés : le plafond de scalabilité et la fiabilité de la base de données. Des ralentissements sont signalés à partir d'environ 5 000 utilisateurs actifs, et des incidents de perte de données — dont un cas documenté de 70 % des enregistrements disparus — ont été rapportés à plusieurs reprises. La refonte infrastructure 3.0 d'Adalo (fin 2025) a amélioré significativement les performances, mais ces constats reflètent une réalité structurelle du modèle d'assemblage granulaire : la responsabilité de l'infrastructure repose sur le créateur.

L'architecture intégrée de GoodBarber fait un autre pari. Les fonctionnalités — le système push, le checkout e-commerce, le CMS — sont conçues pour la production par l'équipe d'ingénierie de GoodBarber, pas assemblées au cas par cas par chaque client. La contrepartie est une flexibilité architecturale moindre ; le bénéfice est une infrastructure identique pour tous les clients à l'échelle, sans plafond documenté.

C'est l'axe qui sépare le plus clairement les deux plateformes : Adalo vous laisse construire l'infrastructure dont vous avez besoin ; GoodBarber vous la livre déjà construite. Comme nous l'explorons dans notre analyse des limites des app builders no-code, le coût d'une approche par assemblage granulaire ne se manifeste généralement pas au lancement — mais au premier cycle de mise à jour de contenu, au premier pic de trafic, et la première fois qu'un contributeur doit modifier une fiche destination sans se connecter à une base de données.

• Vous construisez un prototype ou un MVP et voulez valider un concept rapidement, sans planification d'infrastructure
• Votre app nécessite une architecture de données sur mesure — relations multi-tables, logique conditionnelle complexe — que des modules fonctionnels pré-conçus ne couvriront pas
• Vous voulez garder le contrôle direct du schéma de base de données et des flux d'actions
• Votre projet est un outil interne ou une app de niche verticale qui correspond précisément aux composants du marketplace Adalo
• Votre équipe a une légère culture technique et est à l'aise pour gérer des comptes vendeurs séparés (Stripe, Apple Developer, Google Play)

• Vous créez une app de contenu, d'édition ou de communauté, et vous avez besoin d'un CMS éditorial prêt à l'emploi
• Vous lancez une app de commerce mobile et vous voulez un checkout unifié à 0 % de commission, sans configurer Stripe de votre côté
• Vous avez besoin des notifications push, de l'analytique et de la gestion des utilisateurs dès le départ, sans devoir upgrader en cours de route
• Votre audience est en Europe et la souveraineté des données a de l'importance : GoodBarber héberge toutes les données exclusivement sur des serveurs européens
• Vous voulez une app pilotable par des agents IA : votre équipe utilise Claude, Cursor ou des outils similaires et veut gérer l'app en langage naturel via MCP
• Vous pensez sur le long terme — une plateforme conçue pour opérer au quotidien, évoluer pendant des années, et croître sans se heurter à des limites d'infrastructure documentées

Adalo et GoodBarber livrent tous les deux des apps à l'apparence native, sans une ligne de code. La différence, c'est ce que chaque plateforme considère comme "terminé". Pour Adalo, terminé signifie que le canvas est publié. Pour GoodBarber, terminé inclut le back-office, le CMS, le système push, la couche paiement — tout opérationnel dès le premier jour.

Si vous testez un concept, le canvas visuel d'Adalo et Ada AI offrent un raccourci efficace de l'idée à l'app publiée. Si vous construisez quelque chose que vous prévoyez d'exploiter au quotidien, de faire grandir au-delà d'une première base d'utilisateurs, et d'enrichir en contenu et en fonctionnalités pendant des années — l'architecture intégrée de GoodBarber est la fondation la plus solide.

Démarrez votre essai gratuit et construisez AURORA — ou votre propre projet — sans toucher une seule ligne de code.

• GoodBarber vs Bubble
• GoodBarber vs Base44
• GoodBarber vs Glide
• GoodBarber vs Rork
• GoodBarber vs Emergent
• GoodBarber vs FlutterFlow
• Les 10 meilleurs app builders No-Code en 2026

Adalo produit-il de vraies apps natives ?

Adalo produit des apps React Native — un framework hybrid qui compile pour les stores iOS et Android. L'output est accepté par les stores et fonctionne bien pour la plupart des cas d'usage, mais il diffère de l'approche GoodBarber, qui compile de vrais binaires Swift (iOS) et Kotlin (Android) depuis le même projet.

Les notifications push sont-elles incluses dans le plan de base d'Adalo ?

Non. Les notifications push chez Adalo sont disponibles à partir du plan Professional (52 $/mois, facturation annuelle). Le plan Starter (36 $/mois) ne les inclut pas. Chez GoodBarber, les notifications push sont incluses dès le tier Premium.

Adalo prend-il une commission sur les ventes réalisées dans l'app ?

Adalo ne prélève pas de commission sur les transactions. Cependant, l'intégration des paiements nécessite un compte Stripe externe, et les frais de traitement Stripe s'appliquent. GoodBarber prend également 0 % de commission et inclut 22 passerelles de paiement dans l'abonnement, sans configuration de compte tiers.

Est-il possible d'ajouter un chatbot IA pour les utilisateurs de mon app avec Adalo ?

L'IA d'Adalo (Ada) opère dans le back-office de création — pour générer des écrans et des fonctionnalités pendant la phase de construction. Il n'existe pas de chatbot IA intégré pour les utilisateurs finaux. GoodBarber inclut un chatbot RAG qui répond aux questions des utilisateurs à partir du contenu publié dans l'app.

Quelles sont les limites de scalabilité d'Adalo ?

La refonte infrastructure 3.0 d'Adalo (fin 2025) a significativement amélioré les performances. Avant cette mise à jour, des ralentissements étaient signalés à partir d'environ 5 000 utilisateurs actifs. L'infrastructure de GoodBarber ne présente pas de plafond documenté en nombre d'utilisateurs, et ses fonctionnalités pré-construites sont maintenues pour la production à l'échelle par l'équipe GoodBarber.

Il existe quatre chemins réalistes pour une petite entreprise qui veut créer une application : les app builders no-code, les outils assistés par IA, la conversion de site web en app, ou l'embauche d'un développeur. Le bon choix dépend d'une question plus que de toute autre — votre application est-elle destinée à vos clients, ou à vos équipes internes ? Ces deux cas tirent dans des directions opposées sur les coûts, le choix des outils et la définition même du succès. Nous créons des apps natives iOS et Android depuis 2011, et dans ce guide nous analysons chaque chemin honnêtement — y compris à qui chaque outil est réellement destiné.

• Les 4 chemins comparés — et comment choisir le bon
• Chemin 1 : Les app builders no-code — le bon choix pour la plupart des apps orientées clients
• Chemin 2 : Les outils IA — rapides, mais avec de vraies limites pour les apps natives
• Chemin 3 : PWA et conversion de site web — quand c'est vraiment suffisant
• Chemin 4 : Faire appel à un développeur ou une agence — quand ça vaut le coût
• Quel chemin pour quel type d'entreprise
• Comparaison honnête des coûts
• Comment démarrer : le bon ordre des étapes
• FAQ

Avant de choisir un outil, répondez à deux questions :

Qui utilise l'application ?

• Vos clients — des personnes qui réservent, commandent, naviguent ou accumulent des points de fidélité. Ils téléchargent votre app depuis l'App Store ou Google Play. Vous avez besoin de notifications push, d'Apple Pay et de la crédibilité des stores.
• Votre équipe — des collaborateurs qui gèrent les stocks, les plannings ou des workflows internes. Un outil web est généralement suffisant. La distribution native n'est pas nécessaire.

Quelle est la complexité de la logique ?

• Un système de réservation, une interface de commande, un programme de fidélité — ce sont des flux bien définis que les outils no-code gèrent entièrement.
• Une marketplace multi-acteurs, un algorithme de mise en relation en temps réel, ou un backend fortement personnalisé — cela nécessite du développement sur mesure.

Pour la plupart des petites entreprises — restaurants, salons, commerces de détail, salles de sport, prestataires de services — la réponse est : app orientée clients, workflows standards. Cela pointe directement vers le Chemin 1.

Les plateformes no-code vous permettent de construire, configurer et publier une application mobile sans écrire de code. Vous configurez vos fonctionnalités via une interface back-office ; la plateforme s'occupe de la sortie native iOS et Android, de la soumission aux stores et de l'hébergement.

Ce qui distingue les apps orientées clients des outils internes :

La plupart des outils no-code se répartissent en deux catégories qui se ressemblent en apparence mais répondent à des besoins différents :

Les builders "spreadsheet-to-app" (Glide, AppSheet, Noloco) sont conçus pour transformer un Google Sheet ou une base Airtable en interface pour vos équipes. Ils fonctionnent bien pour les tableaux de bord internes, les portails collaborateurs et les outils de saisie de données — mais ils sont web ou PWA-first, pas des apps mobiles natives. Ils ne conviennent pas quand vous souhaitez que vos clients téléchargent votre app depuis l'App Store.

Les app builders natifs mobiles sont conçus pour la distribution orientée clients. L'app est construite pour iOS et Android, soumise à l'App Store et Google Play, et optimisée pour le paiement, les notifications push et l'expérience mobile en situation réelle.

GoodBarber appartient à cette deuxième catégorie. La plateforme crée des apps natives iOS et Android depuis 2011 — et le produit est conçu spécifiquement pour les cas d'usage dont les petites entreprises ont réellement besoin :

• Restaurant ou commerce alimentaire : commande mobile, retrait en caisse, livraison, notifications push de suivi de commande en temps réel, programme de fidélité. La plateforme inclut un vertical restaurant prêt à l'emploi, permettant d'échapper aux commissions de 15–30% prélevées par les plateformes de livraison tierces.
• Commerce de détail ou e-commerce : catalogue produits, checkout Apple Pay / Google Pay (un tap, sans saisie de carte), récupération de paniers abandonnés par push, TPV en magasin pour les retraits, 22 passerelles de paiement sans frais supplémentaires.
• Salon, clinique ou prestataire de services : calendrier de disponibilité en temps réel, prise de rendez-vous, synchronisation Google Calendar, rappels push qui réduisent les no-shows, extensions carte de fidélité et coupons.
• Contenu, médias ou communauté : articles, podcasts, vidéo, paywalls d'abonnement in-app via Apple StoreKit et Google Play Billing.

L'avantage 0% de commission : GoodBarber facture un abonnement mensuel — à partir de 55 €/mois (annuel) pour un Content App (Premium) et 90 €/mois pour un eCommerce App (Premium) — et ne prélève aucune commission sur les transactions. Pas de partage de revenus, pas de coupe sur chaque vente. Les seuls frais sont les coûts standards de traitement des paiements (Stripe, PayPal, etc.) et, pour les abonnements in-app, les 15–30% qu'Apple et Google retiennent sur chaque plateforme — une règle des stores qu'aucun app builder ne peut contourner.

Ce que proposent les autres builders no-code : Adalo et FlutterFlow produisent également des apps mobiles natives, mais avec moins de support vertical intégré pour le retail, la restauration et les services. Bubble est un puissant builder d'apps web no-code, mais il ne produit pas d'apps natives iOS ou Android — il fonctionne dans un navigateur. Si votre business a besoin qu'un client télécharge une app et paye en Apple Pay, Bubble n'est pas le bon outil.

Plan minimum : Content App Premium (70 €/mois en facturation mensuelle, moins en annuel) pour les réservations, le contenu et la communauté. eCommerce App Premium (90 €/mois en facturation mensuelle) pour la vente de produits et la commande en restauration.

Les app builders IA (Replit, Lovable, Bolt, v0) vous permettent de décrire une app en langage naturel et de générer automatiquement des écrans, de la logique et un backend. La catégorie évolue vite et les outils sont véritablement impressionnants pour les prototypes.

Ce en quoi ils excellent :

• Générer une première version d'un outil interne ou d'une app web en quelques heures
• Tester des idées avant de s'engager sur une plateforme plus structurée
• Les fondateurs avec un bagage technique qui peuvent revoir et ajuster le code généré

Les limites honnêtes pour les cas d'usage petites entreprises :

• Les builders IA génèrent principalement des apps web. Obtenir une app native iOS et Android soignée et conforme à l'App Store depuis ces outils demande un travail supplémentaire significatif.
• Les achats in-app (pour les abonnements), le checkout Apple Pay et l'infrastructure de notifications push nécessitent des SDK natifs que les apps web générées par IA n'ont pas.
• Ces outils sont avant tout utiles pour un proof of concept — pas pour l'app client prête à la production dont un restaurant ou un salon a besoin dès le premier jour.

Si vous souhaitez tester un concept avant de vous engager sur une plateforme no-code, les builders IA peuvent être une première étape utile. Mais pour une app de petite entreprise déployée avec de vrais clients, prévoyez de passer sur une plateforme dédiée.

Une Progressive Web App (PWA) est un site web qui se comporte comme une app mobile — les utilisateurs peuvent l'ajouter à leur écran d'accueil, recevoir des notifications push (limitées) et y accéder hors ligne. Les convertisseurs site-to-app (MobiLoud, Median.co) encapsulent un site existant dans une coque native.

Quand ce chemin fait sens :

• Votre app est avant tout un hub de contenu — actualités, articles, menus, catalogues — avec peu de complexité transactionnelle
• Vous avez déjà un bon site mobile et souhaitez une présence rapide sur les stores
• Le budget est la contrainte principale et vous acceptez les compromis

Les compromis honnêtes :

• Les PWA ne supportent pas le checkout Apple Pay ou Google Pay de la même façon que les apps natives
• La portée des notifications push sur iOS est nettement inférieure sur PWA par rapport aux apps natives
• Le signal de confiance "téléchargé depuis l'App Store" est absent pour les PWA
• Les wrappers de sites dépendent de la performance de votre site — ils n'améliorent pas l'expérience sous-jacente

Le plan Standard de GoodBarber produit une PWA en plus des apps natives — si vous souhaitez commencer par là et passer à la distribution native ensuite, ce chemin est disponible sans reconstruire.

Le développement sur mesure est pertinent quand votre app nécessite une logique qu'aucune plateforme ne peut gérer : une marketplace multi-acteurs avec un matching personnalisé, une intégration profonde avec du matériel propriétaire, ou un système temps réel avec des exigences strictes de performance.

Fourchettes de coûts réalistes :

Scope	Coût typique
MVP no-code par un freelance	2 000–10 000 €
App cross-platform (Flutter / React Native)	15 000–60 000 €
App native custom complète	50 000–150 000 €+
Maintenance annuelle	15–20% du coût de développement

Quand ça ne fait pas sens : Si votre app est un système de réservation, un programme de fidélité, une interface de commande ou un abonnement à du contenu — tous ces cas sont des problèmes résolus sur les plateformes no-code. Payer 50 000 € pour développer sur mesure une app de commande pour restaurant est difficile à justifier quand une plateforme no-code à 90 €/mois le gère avec de meilleures fonctionnalités.

Une heuristique utile : si vous pouvez décrire la fonction principale de votre app en une phrase ("les clients réservent des rendez-vous et reçoivent des rappels push"), c'est presque certainement un problème no-code, pas un problème de développement sur mesure.

Type d'entreprise	Chemin recommandé	Pourquoi
Restaurant / café	No-code natif (vertical e-commerce)	Commande, livraison, fidélité, 0% de commission vs plateformes de livraison
Salon / beauté / clinique	No-code natif (réservations)	Calendrier, rappels push, planning
Commerce de détail / boutique	No-code natif (e-commerce)	Catalogue, checkout Apple Pay, push paniers abandonnés
Salle de sport / fitness	No-code natif (contenu + réservations)	Cours, abonnements, push
Prestataire de services local	No-code natif (réservations)	Demandes de devis, prise de RDV, portail client
Éditeur / média	No-code natif (contenu)	Articles, podcasts, paywall d'abonnement in-app
Outil interne pour les équipes	No-code web (Glide, AppSheet)	Données tableur, usage interne, pas besoin de store
Plateforme web complexe	No-code web (Bubble)	Logique custom, forte composante base de données
Prototype pré-revenus	Builder IA (Replit, Lovable)	Rapidité avant la solidité, tester avant d'investir
Logique custom unique	Agence / freelance	Quand aucune plateforme ne couvre vos besoins spécifiques

Chemin	Coût mensuel	Mise en place	Distribution store
No-code natif (GoodBarber)	55 €/mois (annuel) · 70 €/mois	Quelques heures à quelques jours	iOS + Android complet
No-code web (Glide free tier)	0–49 €/mois	Quelques heures	Web / PWA uniquement
No-code web (Bubble)	29–349 €/mois	Jours à semaines	Web uniquement
Convertisseur site-to-app	50–300 €/mois	Quelques heures	iOS + Android (via wrapper)
MVP freelance	2 000–10 000 € une fois + maintenance	Semaines	iOS + Android
App custom agence	15 000–150 000 €+ une fois + maintenance	Mois	iOS + Android

Le chiffre que la plupart des entreprises sous-estiment : le développement sur mesure n'est pas un coût ponctuel. La maintenance, les mises à jour, la compatibilité avec les nouvelles versions iOS/Android et les corrections de bugs représentent typiquement 15–20% du coût de développement chaque année. Une app custom à 50 000 € coûte 7 500–10 000 € par an rien que pour rester opérationnelle — avant toute nouvelle fonctionnalité.

Une plateforme no-code gère toutes les mises à jour, la compatibilité OS et l'infrastructure dans le cadre de l'abonnement mensuel.

Étape 1 : Définissez votre cas d'usage principal en une phrase.

"Les clients réservent des rendez-vous et reçoivent des rappels push." "Les clients commandent à emporter et cumulent des points de fidélité." Si vous ne pouvez pas faire ça, vous n'êtes pas encore prêt à construire — passez plus de temps sur le problème.

Étape 2 : Identifiez si c'est orienté clients ou interne.

Orienté clients → vous avez besoin de la distribution sur les stores, de notifications push et d'un tunnel de paiement. C'est une plateforme no-code native. Interne → un outil web est plus rapide et moins cher.

Étape 3 : Choisissez le jeu de fonctionnalités minimum viable.

Réservation + rappels. Pas réservation + rappels + fidélité + analytics + portail collaborateur. Construisez une chose. Ajoutez le reste après que vos premiers vrais utilisateurs aient validé la valeur principale.

Étape 4 : Choisissez une plateforme no-code adaptée à votre vertical.

Ne choisissez pas l'outil le plus puissant — choisissez celui qui correspond le mieux à votre cas d'usage. Un restaurant n'a pas besoin du moteur logique de Bubble. Un salon n'a pas besoin d'un développement Flutter sur mesure.

Étape 5 : Lancez, mesurez, puis décidez d'investir davantage.

Beaucoup de petites entreprises n'ont jamais besoin d'aller au-delà d'une app no-code bien configurée. Celles qui évoluent vers le sur-mesure disposent de vraies données d'usage pour justifier l'investissement.

À lire aussi :

• Combien coûte la création d'une application sans codage ?
• Quelles sont les limites des app builders no-code ?
• Créateur d'app no-code vs agence de développement : comment choisir
• Comment gagner de l'argent avec une app mobile sans coder

Quelle est la façon la moins chère pour une petite entreprise de créer une app ?

Un app builder no-code est le chemin le plus économique pour la plupart des petites entreprises — à partir de 55 €/mois en annuel (70 €/mois sans engagement) pour une app native iOS et Android, sans développeur nécessaire et sans commission sur les transactions. Les seuls coûts récurrents sont l'abonnement et les frais standards de traitement des paiements (Stripe, PayPal, etc.). Le développement sur mesure commence typiquement à 15 000–50 000 € pour une app simple, auxquels s'ajoute une maintenance annuelle de 15–20% du coût de développement.

Faut-il un développeur pour créer une app pour une petite entreprise ?

Non — pour les cas d'usage standards comme la réservation, la commande, la fidélité et le contenu, les plateformes no-code gèrent tout de la construction à la soumission sur les stores. Un développeur devient pertinent quand votre app nécessite une logique véritablement custom qu'aucune plateforme ne couvre — ce qui est rarement le cas pour les commerces locaux et les petites structures e-commerce.

Une app no-code peut-elle être publiée sur l'App Store et Google Play ?

Oui, si la plateforme no-code produit une sortie native iOS et Android. C'est le cas de GoodBarber, Adalo et FlutterFlow. Glide, AppSheet et Bubble produisent principalement des apps web ou des PWA — ils ne soumettent pas de binaires natifs à l'App Store et Google Play. Vérifiez toujours le format de sortie d'une plateforme avant de vous engager.

Combien de temps faut-il pour créer une app pour une petite entreprise ?

Avec une plateforme no-code, la construction prend quelques jours à quelques semaines selon la configuration de votre contenu et catalogue. La revue de l'App Store ajoute 1–3 jours pour la première soumission. Délai total du démarrage à la mise en ligne : 2–4 semaines est typique pour une app no-code bien définie.

Quelles fonctionnalités une app de petite entreprise doit-elle inclure au lancement ?

Commencez par l'action client la plus importante : réservation, commande, ou accès à du contenu. Ajoutez : les notifications push (la fonctionnalité avec le meilleur ROI dans toute app mobile), les profils utilisateurs si nécessaire, et une intégration paiement si des transactions sont impliquées. La fidélité, l'analytics avancée et les fonctionnalités secondaires peuvent venir en version deux, une fois que vous savez que le cœur fonctionne.

Quelle est la différence entre un app builder no-code et une agence ?

Un app builder no-code vous donne un cadre préconfiguré que vous adaptez à votre business — la plateforme gère le code sous-jacent, l'hébergement et l'infrastructure. Une agence écrit du code sur mesure selon vos spécifications. Le no-code est le bon choix quand votre cas d'usage correspond à des patterns standards (réservation, commande, contenu, fidélité). Le développement sur mesure fait sens pour des besoins véritablement uniques qu'aucune plateforme ne couvre.

• Pourquoi les apps mobiles monétisent mieux que les sites web
• Les 5 modèles de monétisation comparés côte à côte
• Modèle 1 : E-commerce mobile — vendez des produits, gardez la marge
• Modèle 2 : Abonnements contenu premium — Apple et Google font le travail
• Modèle 3 : Publicité — transformez votre audience en revenus sans rien vendre
• Modèle 4 : Services et réservations — faites payer votre temps ou votre expertise
• Modèle 5 : Dons — laissez votre communauté soutenir votre travail
• Comment choisir le bon modèle pour votre projet
• FAQ

Avant de choisir un modèle, il vaut la peine de comprendre pourquoi le canal mobile convertit différemment — et généralement mieux.

Les notifications push changent la relation. Un site attend que l'utilisateur revienne. Une app mobile native envoie une notification push et le fait revenir. Cela change fondamentalement l'économie de la rétention. Un utilisateur réactivé ne coûte rien au-delà du push ; un internaute qui part peut ne jamais revenir.

Le paiement se fait en un tap. Pour le e-commerce comme pour les abonnements, les apps natives iOS et Android ont accès à Apple Pay et Google Pay — des moyens de paiement déjà enregistrés sur l'appareil. L'utilisateur n'a ni numéro de carte à saisir ni adresse de facturation à renseigner. Un tap, c'est fait. Les taux de conversion mobile sur les apps natives avec Apple Pay / Google Pay surpassent régulièrement les checkouts web dans des proportions significatives.

La présence sur les stores inspire confiance. Être référencé sur l'App Store ou Google Play porte un signal de crédibilité implicite qu'un site web seul n'a pas. Pour les créateurs, les petites entreprises et les éditeurs qui cherchent à monétiser une nouvelle audience, ce signal a une valeur commerciale réelle.

Aucun de ces points ne nécessite un développeur. Tout cela est disponible dans une app no-code native bien construite.

Modèle	Idéal pour	Source de revenus	Commission GoodBarber	Coût plateforme tierce
E-commerce	Boutiques, restaurants, commerces	Ventes de produits	0%	Frais de paiement uniquement (Stripe, PayPal…)
Abonnements premium	Éditeurs, créateurs, formateurs	Abonnements mensuels/annuels	0%	15–30% (stores Apple / Google)
Publicité	Apps de contenu à fort trafic	Impressions et clics publicitaires	0%	0% (AdMob, Ad Manager)
Réservations / services	Salons, cabinets, consultants	Rendez-vous pris	0%	Frais de paiement uniquement
Dons	Associations, foi, créateurs	Contributions volontaires	0%	Selon la plateforme (Buy Me a Coffee)

Un point essentiel de ce tableau : GoodBarber ne prend aucune commission sur ces flux de revenus. Vous payez l'abonnement mensuel ; tous les revenus vous reviennent. Les seules retenues tierces sont les frais standard de traitement des paiements (Stripe, PayPal, etc.) et les 15–30% qu'Apple et Google prélèvent sur les achats intégrés — ce sont des règles des stores qui s'appliquent à tous les app builders, sans exception.

Le modèle de monétisation le plus direct : créez une boutique mobile, listez vos produits, et vendez.

Ce que vous pouvez vendre : Produits physiques (mode, alimentation, beauté, matériel, tout ce qui s'expédie), produits numériques, épicerie, commandes de restaurant en click & collect ou livraison — l'eCommerce App GoodBarber supporte tout cela nativement, avec des configurations verticales dédiées pour les restaurants et les commerces d'alimentation.

Ce qui rend le canal mobile différent d'un site web :

• Checkout en 1 tap avec Apple Pay et Google Pay — réduit drastiquement l'abandon de panier
• Notifications push pour récupérer les paniers abandonnés (automatisées, aucune intervention manuelle requise)
• « Acheter à nouveau » — réachat en un tap pour les clients aux achats récurrents
• Push de suivi de commande en temps réel à chaque étape de la livraison

Le calcul sur les commissions : GoodBarber prélève 0% sur chaque transaction — en ligne ou hors ligne. Un client qui paie dans l'app via Stripe ou PayPal : 0% pour nous, frais de traitement Stripe/PayPal standards uniquement. Un client qui règle en boutique au retrait : 0% pour qui que ce soit. Les restaurants utilisant notre plateforme échappent aux 15–30% de commission prélevés par les plateformes de livraison tierces comme Uber Eats ou Deliveroo — cette marge reste intégralement chez le restaurateur.

22 passerelles de paiement, toutes gratuites : Stripe, PayPal, Apple Pay, Klarna, Amazon Pay, Revolut Pay, Alipay & WeChat Pay, iDeal, Bancontact, et bien d'autres — toutes installables depuis l'Extension Store en un clic, sans frais de licence supplémentaires.

Plan minimum : eCommerce App, niveau Premium (à partir de 90 €/mois en mensuel, ou 70 €/mois en annuel).

Si votre app publie du contenu — articles, vidéos, podcasts, cours, médias exclusifs — vous pouvez faire payer l'accès à un niveau premium. Ce modèle fonctionne pour les éditeurs, les formateurs, les podcasteurs, les stations de radio, les créateurs de contenu, et toute app où « plus de contenu » ou « meilleur contenu » est le produit.

Comment ça fonctionne techniquement : GoodBarber intègre nativement Apple StoreKit et Google Play Billing. L'abonné tape « S'abonner » dans l'app, le store gère la facturation (le moyen de paiement de l'utilisateur est déjà enregistré), et la section premium se déverrouille immédiatement. Pas de page de paiement externe, pas de création de compte, pas de formulaire à remplir. Ce parcours en un tap est le principal atout de ce canal.

Ce que l'extension couvre : L'extension Abonnements (49 €/mois) vous permet de définir vos offres d'abonnement, de fixer les tarifs mensuels ou annuels indépendamment pour l'App Store et Google Play, et de configurer quelles sections de votre app sont conditionnées à l'abonnement. La plateforme gère côté serveur la validation des reçus, les renouvellements et les cas de remboursement — rien à opérer de votre côté.

Le coût honnête : Apple et Google prélèvent 15% à 30% sur chaque abonnement intégré. Ce n'est pas une politique GoodBarber — c'est une règle Apple/Google qui s'applique à toutes les apps de leurs plateformes. La fourchette dépend de la plateforme, de l'éligibilité de votre entreprise au programme PME, et de la durée de l'abonnement. Prévoyez une retenue d'environ 30% sur la plupart des abonnements standards comme base prudente.

Pourquoi ça vaut quand même le coup : Les tunnels d'abonnement web convertissent à une fraction de ce que font les parcours intégrés aux apps, précisément à cause de la friction au paiement. Pour le bon contenu et la bonne audience, la surconversion apportée par le checkout en un tap compense largement la retenue des stores par rapport à l'alternative — envoyer l'utilisateur vers un checkout web où la conversion chute brutalement.

Ce que proposent les autres app builders no-code : Adalo supporte les achats intégrés via IAPHUB, ce qui nécessite une configuration supplémentaire. Glide est en PWA uniquement et ne peut pas proposer d'achats natifs intégrés (les PWA ne sont pas distribuées sur les stores). Bubble a récemment ajouté un wrapper mobile natif, mais l'intégration des abonnements reste plus complexe à configurer.

Plan minimum : Content App, niveau Premium (à partir de 55 €/mois en annuel (70 €/mois en mensuel)) + extension Abonnements (49 €/mois).

Si votre app construit une audience — une app d'actualités, une app de podcasts, une plateforme communautaire, un guide local — la publicité est une couche de monétisation qui ne demande rien à vos utilisateurs : pas d'abonnement, pas d'achat, pas de friction.

Trois solutions publicitaires, toutes gratuites :

Google AdMob est la régie publicitaire mobile la plus utilisée. Vous connectez votre compte AdMob depuis le back-office en un clic, définissez les emplacements bannières et interstitiels, et les enchères de Google remplissent automatiquement votre inventaire. Les revenus évoluent avec le trafic ; aucune gestion manuelle nécessaire.

Google Ad Manager est la couche programmatique au-dessus d'AdMob, adaptée aux apps avec un trafic significatif qui veulent superposer des campagnes vendues en direct aux remplissages programmatiques. Plus de contrôle sur l'inventaire, les prix planchers et les formats publicitaires.

La régie publicitaire interne vous permet de vendre et de diffuser de la publicité directement — sans passer par les enchères de Google. Si vous avez des sponsors, des annonceurs locaux ou des partenaires qui veulent un emplacement garanti dans votre app, la régie interne vous permet de configurer des campagnes (format, calendrier, ciblage) depuis le back-office et de conserver 100% de ce que vous facturez.

La nuance importante : Les revenus publicitaires évoluent avec l'audience. Une app avec 500 utilisateurs actifs mensuels gagnera très peu avec AdMob. Ce modèle a un sens financier à des niveaux de trafic significatifs — typiquement plusieurs milliers d'utilisateurs actifs ou plus. Si vous démarrez, la publicité fonctionne mieux comme couche de revenus secondaire en complément d'abonnements ou d'e-commerce, pas comme stratégie principale.

Plan minimum : Content App, n'importe quel niveau — les extensions publicitaires sont disponibles dès le Standard (PWA), bien que les formats natifs nécessitent Premium pour la distribution iOS/Android.

Pour les entreprises de services — salons, cabinets médicaux, consultants, coachs, professeurs, services de réparation — l'application mobile n'est pas seulement un canal marketing. C'est l'interface de réservation.

Ce que le module de réservation couvre : Les clients ouvrent l'app, voient vos disponibilités en temps réel et prennent rendez-vous directement. L'extension supporte plusieurs agendas (pour différents prestataires ou types de services), la synchronisation bidirectionnelle avec Google Agenda, des créneaux configurables, des horaires d'ouverture, des fermetures exceptionnelles, et un catalogue de prestations avec descriptions et tarifs.

Pourquoi ça convertit mieux qu'un appel téléphonique ou un formulaire web : Réservation en libre-service 24h/24 — les clients réservent à minuit le dimanche, sans que vous décrochiez un téléphone. Les rappels push réduisent les absences. Les extensions carte de fidélité et couponing se greffent par-dessus pour encourager les réservations répétées.

Commission : 0% sur toute réservation ou paiement transitant par GoodBarber. Si vous intégrez Stripe pour les paiements dans l'app, les frais de traitement standard Stripe s'appliquent ; rien ne nous revient.

Plan minimum : Content App, niveau Premium + extension Prise de rendez-vous (15 €/mois).

Pour les associations, les communautés religieuses, les créateurs indépendants et les organisations communautaires, les dons sont un flux de revenus légitime et souvent significatif — et la barrière pour en mettre un en place dans une app no-code est minimale.

Buy Me a Coffee est disponible comme extension gratuite dans l'Extension Store GoodBarber. Elle intègre un bouton « soutenez-moi » directement dans votre app, renvoyant vers votre page Buy Me a Coffee où vos fans peuvent contribuer ponctuellement ou régulièrement. La configuration prend quelques minutes.

Quand ce modèle est adapté : Les apps qui existent pour servir une communauté (une app d'église, une app d'association locale, une app de podcast indépendant) et où facturer l'accès irait à l'encontre de la mission. Les dons permettent à l'audience de choisir son niveau de soutien sans créer de mur payant.

Limite honnête : Les revenus de dons sont imprévisibles et généralement plus faibles par utilisateur que les abonnements. Pour les apps où les revenus sont critiques, les dons fonctionnent mieux en complément d'un autre modèle (un niveau gratuit financé par les dons + un niveau payant optionnel) que comme stratégie principale.

Le meilleur modèle de monétisation est celui qui correspond à la façon dont votre audience échange naturellement de la valeur — pas celui qui offre le revenu théoriquement le plus élevé.

Votre situation	Modèle recommandé
Vous vendez des produits physiques ou numériques	E-commerce
Vous produisez du contenu pour lequel les gens paient (presse, vidéo, cours)	Abonnements premium
Vous construisez une app de contenu avec une large audience gratuite	Publicité (secondaire : abonnements)
Vous gérez une entreprise de services (salon, cabinet, coaching)	Réservations
Vous gérez une communauté, une association ou une organisation religieuse	Dons + abonnements optionnels
Vous gérez un restaurant ou une activité de livraison locale	E-commerce (vertical Restaurant)

Note sur la combinaison des modèles : Ils ne sont pas mutuellement exclusifs. Une app de presse peut combiner un niveau gratuit financé par la pub et un abonnement premium pour le contenu exclusif. Un créateur peut combiner des dons (Buy Me a Coffee) et un abonnement premium pour du contenu exclusif. Un commerce local peut combiner e-commerce et module de réservation pour ses services. GoodBarber supporte toutes ces combinaisons depuis le même back-office.

Ce qu'il faut chercher dans un app builder no-code pour la monétisation :

• Sortie native iOS et Android (indispensable pour les achats intégrés et le checkout Apple Pay / Google Pay)
• 0% de commission sur les transactions — certaines plateformes prélèvent 2–5% en plus des frais de paiement
• Passerelles de paiement intégrées (plutôt que des flux Zapier tiers)
• Support des achats intégrés via Apple StoreKit / Google Play Billing (la plupart des app builders no-code ne l'ont pas)
• Notifications push pour stimuler le réengagement et récupérer les paniers abandonnés

À lire aussi :

• Quelles sont les limites des app builders no-code ?
• Combien coûte la création d'une app sans coder ?
• App builder no-code vs agence de développement : comment choisir
• Les meilleures façons pour une petite entreprise de créer sa propre application

Peut-on vraiment gagner de l'argent avec une app no-code ?

Oui — les capacités de monétisation d'une app no-code native bien construite sont comparables à celles d'une app développée sur mesure. L'e-commerce, les abonnements intégrés via Apple StoreKit et Google Play Billing, la publicité et les réservations sont tous pleinement supportés. La contrainte n'est pas le modèle de revenus ; c'est la taille de l'audience. Une app monétisée a quand même besoin d'utilisateurs.

GoodBarber prend-il un pourcentage sur mes revenus ?

Non. GoodBarber facture un abonnement mensuel pour la plateforme. Nous prenons 0% sur les transactions e-commerce, 0% sur les revenus publicitaires, 0% sur les réservations et 0% sur les dons. Les seules retenues tierces sont les frais standard de traitement des paiements (Stripe, PayPal, etc.) et les 15–30% qu'Apple et Google prélèvent sur les achats intégrés — ce sont des règles des stores qu'aucun app builder ne peut contourner.

Faut-il une app native iOS et Android pour vendre des abonnements intégrés ?

Oui. Les achats intégrés via Apple StoreKit et Google Play Billing ne fonctionnent que sur des apps natives distribuées via l'App Store et Google Play. Les apps en PWA uniquement ne peuvent pas proposer ce modèle. Il faut au minimum un plan Content App Premium.

Quel est le modèle de monétisation le plus rapide à mettre en place avec GoodBarber ?

La publicité (AdMob) et les dons (Buy Me a Coffee) sont les plus rapides — tous deux sont disponibles sur n'importe quel plan, s'installent en un clic depuis l'Extension Store, et ne nécessitent ni catalogue produit ni structure tarifaire à configurer. L'e-commerce et les abonnements demandent plus de configuration initiale mais débloquent un revenu significativement plus élevé par utilisateur.

Peut-on combiner plusieurs modèles dans la même app ?

Oui. Une app de presse typique peut faire tourner AdMob sur le contenu gratuit et un mur payant pour les sections premium. Une app de restaurant peut vendre des produits en ligne et accepter des paiements en boutique. Une app de créateur peut combiner un bouton de don Buy Me a Coffee et un abonnement premium pour du contenu exclusif. GoodBarber supporte ces combinaisons depuis la même configuration du back-office.

Comment suis-je payé ?

Pour l'e-commerce et les réservations : directement depuis votre passerelle de paiement connectée (Stripe, PayPal, etc.) — les fonds arrivent sur votre compte Stripe/PayPal selon leur calendrier standard de versements. Pour les abonnements intégrés : versements mensuels d'Apple et Google, après leur retenue de 15–30%. Pour AdMob : versements mensuels Google selon le calendrier AdMob standard. Pour Buy Me a Coffee : directement de Buy Me a Coffee sur votre compte bancaire lié.

Si vous publiez du contenu dans une app GoodBarber, vous connaissez le scénario. Un nouveau sentier de randonnée ouvre dans votre région, et vos lecteurs voudront le savoir avant le week-end. Aucune tâche n'est compliquée. Un article avec une photo et une description du parcours. Un événement de randonnée guidée le samedi matin. Trois points d'intérêt en chemin — la source, le belvédère, la vieille chapelle.

Mais chacune de ces tâches signifie la même chose : ouvrir un ordinateur, se connecter, trouver la bonne rubrique, remplir un formulaire, ordonner les blocs du corps de page, enregistrer. Recommencer pour l'événement. Recommencer pour la carte. Le temps d'avoir tout fait, l'après-midi est passée — ou l'idée a glissé dans une liste qui ne se raccourcit jamais.

Quand nous avons introduit le serveur MCP de GoodBarber, nous avons réglé ce problème côté boutique de la plateforme. Le retour nous a appris quelque chose que nous aurions dû voir plus tôt : la valeur d'agir sur votre app par une phrase n'était pas limitée au commerce. Elle s'appliquait tout autant à tout le reste que gère le back-office. Nous avons donc étendu le serveur MCP pour couvrir le contenu.

MCP — le Model Context Protocol ouvert, introduit par Anthropic fin 2024 — est le pont. C'est un standard qui permet à un assistant IA comme Claude ou ChatGPT de se connecter en toute sécurité à un service externe et d'y effectuer des actions réelles. Branchez le serveur MCP de GoodBarber dans votre assistant, et il accède directement à votre app. Nous avons décrit toute l'histoire dans l'article de lancement du serveur MCP — et avant que GoodBarber ait son propre serveur, nous avions montré comment piloter une app via le relais MCP de Zapier, encore utile lorsque vous souhaitez enchaîner des actions GoodBarber avec d'autres outils.

Ce qui est nouveau, c'est l'étendue. La connexion qui gérait déjà votre boutique atteint désormais chaque section de contenu de votre app. Rien ne change pour les utilisateurs Shop — les outils catalogue, commandes, marketing, clients et statistiques sont exactement là où ils étaient. Il y a juste plus de matière au bout de la même ligne.

Le serveur MCP est le pont : une seule connexion entre votre assistant IA et votre app entière — Shop et contenu.

Voici l'étendue complète du contenu, et le type de phrase qui pilote chaque partie :

Section de contenu	Capacités	Exemple de prompt conversationnel
Articles & Actualités	Créer et mettre à jour des articles, construire des mises en page par blocs (texte, photos, citations, embeds), réordonner les paragraphes et configurer un accès premium avec aperçu de paragraphes gratuits.	"Crée un article premium sur le sentier avec un aperçu gratuit de 2 paragraphes, et insère un bloc photo après l'introduction."
Agenda & Événements	Créer, reprogrammer et lister les événements du calendrier de votre app avec date, heure et adresse.	"Déplace l'événement de randonnée guidée de samedi 9h à dimanche prochain 10h."
Cartes & Points d'intérêt	Placer des coordonnées géographiques, ajouter des lieux avec une adresse physique et une note courte.	"Ajoute un nouveau point sur la carte pour 'La Source' au 12 rue du Sentier avec la note : 'Point d'eau potable'."
Galeries médias	Créer et alimenter des galeries photos, uploader des vidéos, organiser des sections audio/podcast.	"Crée une nouvelle galerie photo intitulée 'Vues du sentier' et uploade les trois dernières photos que je t'ai envoyées."

Prenons un exemple concret, tiré de notre propre feuille de route. Votre app vient d'avoir un nouveau chatbot IA, et vous voulez l'annoncer. Voici le back-office qu'il fallait avant — et la phrase qu'il faut maintenant.

"Crée un article dans la section Actualités intitulé 'Meet our new AI chatbot'. Ajoute un paragraphe d'introduction court et trois sections de texte sur : ce qu'il fait, comment l'utiliser, et confidentialité & confiance."

L'assistant construit le tout et fait son rapport : l'article publié dans Actualités, l'intro et les trois sections en place. Une phrase, un article fini.

À partir de là, c'est une conversation, plus un formulaire. Le corps d'un article est une séquence de blocs, et vous les réagencez de la même façon que vous les avez écrits — en demandant :

"Dans cet article, déplace la photo d'introduction au-dessus de la première section de texte."

L'assistant n'a pas les pleins pouvoirs. Chaque action est limitée au périmètre de votre app, et les opérations sensibles demandent votre confirmation avant de s'exécuter. Vous restez l'éditeur. Vous arrêtez juste de naviguer.

Avant, le travail de contenu se déroulait par sessions dédiées. Vous vous installiez, ouvriez le back-office, et passiez à travers votre liste. Ça marche pour le travail planifié. Mais une bonne partie de la publication est réactive — un sentier ouvre, un horaire d'événement change, un lecteur vous signale un lieu à ajouter sur la carte.

Maintenant, ça se passe quand la pensée arrive. Vous êtes déjà dans votre assistant IA. Vous ajoutez une phrase, l'assistant le fait, vous continuez votre travail. Shop et contenu vivent dans la même conversation : vous pouvez vérifier une commande et publier un article dans la même foulée.

Il y a une seconde retombée. Les articles, événements et points sur la carte que vous créez de cette façon sont exactement ce que le RAG Chatbot de GoodBarber utilise pour répondre à vos utilisateurs. Publiez l'article du sentier à la voix, et un randonneur qui demande à votre app "Le Ridge Loop est-il ouvert ?" obtient une réponse fondée sur ce que vous venez d'écrire. Vous gérez le contenu dans une conversation ; votre app tient une conversation à elle avec les gens qui la lisent.

Si vous utilisez déjà le serveur MCP pour votre boutique, il n'y a rien à faire — les outils contenu font partie de la même connexion. Demandez simplement à votre assistant ce qu'il peut gérer comme contenu.

Si vous partez de zéro, la configuration prend environ trois minutes : ajoutez l'URL du serveur MCP à votre client IA, connectez-vous via OAuth avec votre compte GoodBarber, et posez votre première question. "What content can you manage on my app?" est une bonne entrée — l'assistant liste tout ce qu'il peut atteindre.

C'est le motif que nous voulons garder : quand votre app grandit, le serveur MCP grandit avec elle, sur la même connexion que vous avez déjà configurée. Et à mesure que les modèles IA s'améliorent dans la planification de tâches multi-étapes, cette connexion devient plus capable sans que vous ayez quoi que ce soit à mettre à jour.

Nous construisons des outils pour les créateurs d'apps depuis 2011, avec une seule constante — plus de puissance, moins de complexité. Votre back-office a appris à écouter. Il sait maintenant écrire.

Connectez votre app aujourd'hui et commencez à parler à votre contenu.

Le serveur MCP peut-il créer des articles, des événements et des cartes ?

Oui. Le serveur MCP de GoodBarber expose le CMS complet — articles (avec blocs texte, photo, citation et embed), événements de l'agenda, points d'intérêt sur les cartes, galeries photos, vidéos et sections audio — comme actions qu'un assistant IA peut effectuer sur votre app.

Faut-il une configuration séparée pour les outils contenu ?

Non. Si vous avez déjà connecté le serveur MCP pour votre boutique, les outils contenu sont sur la même connexion. Les nouveaux utilisateurs ajoutent l'URL du serveur à leur client IA et se connectent via OAuth — environ trois minutes.

Quels assistants IA fonctionnent avec ?

Tout client qui supporte le Model Context Protocol — Claude, ChatGPT et d'autres. Vous apportez votre IA ; GoodBarber fournit la connexion à votre app.