Pwa: tous les articles et actualités

Une application pour église coûte de 36 €/mois avec un builder no-code, 119 $ et plus sur une plateforme dédiée. Prix réels 2026, frais cachés, dons.

Vous envisagez ce que beaucoup appellent une membership app ? Choisissez entre abonnement payant et communauté privée, puis structurez contenu, accès et push.

L’essentiel. La plupart des petites entreprises n’ont pas besoin d’un site plus gros. Elles ont besoin du bon : trouvable sur Google, capable de prendre des rendez-vous, livré sous forme de PWA, un site qui s’installe aussi comme une app. Une PWA GoodBarber est rendue côté serveur : elle se référence comme n’importe quel site. Et GoodBarber la livre au sein d’une app Content : PWA plus apps natives iOS et Android, à partir d’une seule configuration. Vous vendez des produits ? C’est une app séparée : l’app eCommerce GoodBarber, avec son catalogue et son paiement.Dans un fil intitulé are we massively overengineering websites for small businesses? (« sur-dimensionne-t-on massivement les sites web des petites entreprises ? »), publié en juillet 2026 sur le forum r/nocode, un créateur de sites demande pourquoi on vend à un comptable, un plombier ou un toiletteur de quartier des animations sur mesure, un CMS complexe et des dizaines de pages. La réponse la plus votée estime que la plupart de ces clients seraient mieux servis par une fiche Google Business Profile et une simple page de liens que par le site de huit pages qu’ils sont venus commander. Un autre commentaire résume le vrai mal : on confond ce qui impressionne les développeurs et ce qui sert les clients.Le fil a raison sur le problème et s’arrête à un pas de la solution. La bonne question n’est pas la taille du site. C’est l’outil qui accomplit les trois travaux d’une activité de services : être trouvée par de nouveaux clients, prendre des rendez-vous sans ping-pong téléphonique, et rester présente sur le téléphone des habitués. C’est une question de forme. Et un objet du marché a exactement cette forme.Le vocabulaire vous manque ? Les trois définitions, l’explication SEO et le tableau comparatif complet site web vs application vs PWA sont réunis dans notre guide de décision. Cet article-ci reste sur le cas de la petite entreprise de services.

La version courte. Pas à ce qu'on attend. Les grands app builders IA vous laissent réellement exporter votre code ; en août 2026, Lovable synchronise vers GitHub sur tous ses plans, y compris le gratuit, et sa documentation promet noir sur blanc : « never locked in ». Le lock-in vit ailleurs : dans le backend managé où dorment vos données, dans l'hébergement et l'authentification qu'il faudrait remplacer, dans la boucle d'édition IA qui ne part pas avec vous, et dans la base de code écrite par l'IA dont vous devenez seul responsable dès que vous franchissez la porte. Posséder le code n'a jamais voulu dire pouvoir partir.Le lock-in désignait autrefois une chose simple : votre travail est piégé dans un format propriétaire, et la porte de sortie est verrouillée. Les app builders IA ont changé la forme du problème. La porte est ouverte. La question, c'est ce qui passe par cette porte.Une app, c'est trois possessions différentes sous un seul nom : le code source, le système en production qui sert de vrais utilisateurs, et le business que l'app porte. L'export déplace la première. Il ne déplace pas les deux autres. La frustration qui traverse les fils de migration de cet été vient de la découverte tardive de cette distinction.

Site web vs application vs PWA : ce que fait chacun, ce que ça coûte de le faire vivre, comment choisir. Une PWA rendue côté serveur est site et app à la fois.

Replit construit des outils de développement dans le navigateur depuis 2016. Début 2026, la plateforme a ajouté une offre mobile, sous une page intitulée « Idea to Mobile App in Minutes » — ce qui la place, pour la première fois, sur le terrain des app builders.Nous avons donc passé notre brief habituel dans la machine : AURORA, l'app de guide de voyage haut de gamme que nous construisons sur chaque outil de cette série. Pas une grille de fonctionnalités — une vraie app, qui doit atteindre les stores, être mise à jour chaque semaine, et être pilotée par quelqu'un qui n'écrit pas de code.Ce que produit Replit est solide. C'est aussi, sans ambiguïté, une base de code : un projet React Native, un cloud facturé à l'usage, une console de développement. Toute la comparaison tient dans cette phrase — Replit vous répond en langage naturel, puis vous confie ce qui ressemble à un projet d'ingénierie. Savoir si c'est un cadeau ou un problème dépend entièrement de qui devra faire tourner l'app mardi prochain.

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

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

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

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

Vous voulez que votre Custom Code GoodBarber se comporte différemment pour un utilisateur connecté — afficher du contenu premium, accueillir un membre par son nom, masquer une section aux visiteurs anonymes ? Que vous ayez écrit ce code vous-même ou que vous l'ayez généré avec l'AI Extension Builder, il demande à l'App API qui est connecté via gb.user.getCurrent(). Mais la preview du back-office n'a pas de véritable connexion : pour les apps Membership, cet appel tombe donc toujours dans le cas d'erreur. Ce guide explique comment se comporte l'utilisateur courant dans la preview pour chaque type d'app, et vous donne une méthode prête à copier-coller pour tester en tant que membre connecté. Beaucoup de Custom Code a besoin de savoir qui utilise l'app à l'instant T : afficher du contenu premium, accueillir les membres par leur nom, masquer une section aux visiteurs anonymes, adapter un tunnel de commande. L'App API de GoodBarber vous donne accès à l'utilisateur courant via gb.user.getCurrent().Et le Custom Code n'est plus seulement quelque chose que vous écrivez à la main. Avec l'AI Extension Builder de GoodBarber, vous décrivez en langage naturel la section que vous voulez et l'assistant génère l'extension à votre place — du code qui se branche directement sur la même App API de GoodBarber. Écrit à la main ou généré par l'IA, il appelle gb.user.getCurrent() de la même manière, et vous le testez de la même manière. Ce guide s'applique donc, que vous ayez tapé le code ou que vous l'ayez obtenu via un prompt.Mais voici l'écueil que tout développeur finit par rencontrer : dans la preview du back-office, il n'y a aucun utilisateur connecté. La preview n'est qu'un rendu de votre app — pas d'écran de connexion, pas de session, rien sur quoi s'authentifier.Pour la plupart des types d'apps, GoodBarber contourne discrètement le problème à votre place, si bien que tester « en tant qu'utilisateur connecté » fonctionne tout seul. Pour l'extension Membership, ce n'est pas le cas — et c'est voulu. Cet article passe en revue le comportement de l'utilisateur courant dans la preview pour chaque type d'app, et vous donne une méthode simple, prête à copier-coller, pour tester le cas le plus délicat : un membre connecté.

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.

La Coupe du Monde 2026 a commencé, et les matchs vont capter l'attention de tous : une occasion de fidéliser votre audience autant que d'en attirer une nouvelle, directement dans votre app. Voici comment y ajouter une section calendrier et résultats — le score de chaque match, prochain match mis en avant, heure de coup d'envoi au fuseau local — en partant d'un simple prompt, grâce à l'AI Extension Builder de GoodBarber. 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.

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.

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.

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.

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.

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 :le message à envoyer ;l’audience concernée ;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.

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

Il existe cinq façons éprouvées de monétiser une application mobile sans écrire une ligne de code : vendre des produits, faire payer l'accès à du contenu premium, diffuser de la publicité, vendre des services ou accepter des dons. Le bon modèle dépend de ce que vous proposez — et la bonne plateforme détermine quelle part de ces revenus vous conservez réellement. Nous construisons des apps natives iOS et Android depuis 2011, et dans ce guide nous décortiquons chaque modèle honnêtement : ce qu'il rapporte, ce qu'il coûte, et ce que vous pouvez mettre en place avec un app builder no-code aujourd'hui. Pourquoi les apps mobiles monétisent mieux que les sites webLes 5 modèles de monétisation comparés côte à côteModèle 1 : E-commerce mobile — vendez des produits, gardez la margeModèle 2 : Abonnements contenu premium — Apple et Google font le travailModèle 3 : Publicité — transformez votre audience en revenus sans rien vendreModèle 4 : Services et réservations — faites payer votre temps ou votre expertiseModèle 5 : Dons — laissez votre communauté soutenir votre travailComment choisir le bon modèle pour votre projetFAQ

FlutterFlow ouvre sa page d'accueil sur une promesse : Own your code, no vendor lock-in. Le message est réel, et pour un public bien précis, c'est la bonne réponse. Mais il porte une signification cachée : posséder le code, c'est aussi posséder tout ce qui arrive après — les bugs, les updates de la plateforme qui cassent votre projet, les heures de développeur, le CMS externe qu'il faut câbler soi-même. Posséder le code est une forme de propriété. Il en existe une autre : posséder l'exploitation — publier du contenu, envoyer des notifications push, encaisser des commandes, chaque jour, pendant des années, sans jamais ouvrir un IDE. Nous avons testé les deux plateformes sur le même brief pour voir laquelle de ces deux propriétés chacune délivre réellement. Nous avons construit AURORA — une application guide de voyage haut de gamme — sur FlutterFlow et sur GoodBarber, à partir d'un cahier des charges identique. La méthode est détaillée dans notre comparatif des app builders en 2026.

La réponse courte que la plupart des articles évitent de donner : vous ne pouvez pas. Pas vraiment. Uber, Airbnb et Instagram sont des produits sur mesure représentant des centaines de millions de dollars de R&D;, une infrastructure conçue pour une échelle globale et des équipes d'ingénieurs spécialisés. Aucune plateforme no-code ne reproduit cela. Mais ce n'est presque sûrement pas ce que vous cherchez à construire. Voici donc l'analyse honnête — ce que le no-code peut et ne peut pas faire pour des projets inspirés de ces apps, et comment choisir le bon outil pour ce que vous voulez réellement lancer.

Il y a deux ans, obtenir un prototype fonctionnel en quelques heures relevait de l'exploit. Aujourd'hui, c'est la norme. Lovable y est pour beaucoup : vous décrivez ce que vous voulez, ça prend forme sous vos yeux, vous affinez par la conversation. La promesse — "permettre aux 99 % qui ont des idées mais pas les compétences techniques de les concrétiser" — est tenue, au moins pour la première étape.Mais ce comparatif cherche à répondre à une question différente. Pas "est-ce que Lovable peut générer une application ?" — il le peut, et de façon convaincante — mais : que se passe-t-il après le prototype ? Qui gère le contenu, planifie les notifications push, soumet l'app sur l'App Store, et fait tourner l'expérience un an plus tard ?Pour y répondre, nous avons appliqué le même cahier des charges aux deux plateformes : AURORA, un guide de voyage de luxe. Un ensemble de critères fixes, testés systématiquement. Ce que ça révèle dépasse largement un tableau de fonctionnalités.

Emergent a atteint 100 millions de dollars d'ARR huit mois après son lancement. Une traction de cette ampleur, ça ne s'explique pas par le hasard — elle traduit un vrai changement dans la façon dont les gens veulent créer des logiciels. Nous avons testé les deux plateformes sur le même brief pour comprendre où l'avantage de vitesse tient vraiment, et où les choix produit spécifiques d'Emergent créent des frictions qui s'accumulent avec le temps.**Les outils de création d'applications par IA répondent rarement à une question pourtant essentielle : qu'est-ce qu'on fait avec l'app le lendemain de son lancement ? Emergent est l'un des outils les plus impressionnants sur le plan technique que nous ayons testés pour passer d'une idée à une application fonctionnelle en moins de trente minutes. Mais 100 millions d'ARR en huit mois signifie aussi que l'équipe a eu le temps de faire des choix délibérés sur ce qu'elle construit — et sur ce qu'elle ne construit pas. L'absence de back-office dans Emergent n'est pas un oubli. C'est une philosophie produit. La comprendre, c'est le vrai enjeu de cette comparaison.Nous avons construit la même application sur les deux plateformes — AURORA, un guide de voyage de luxe — pour comprendre non seulement ce que chaque outil génère au jour 1, mais ce qu'il rend possible au jour 30. La méthodologie est détaillée dans notre comparatif des app builders 2026.