Encapsuler le site, synchroniser ses articles ou le recoder : trois façons de faire de WordPress une app iOS et Android. Coût, validation Apple, entretien.

Tout outil qui transforme un site WordPress en application fait l'une de ces trois choses avec votre site : il affiche le site dans une app, il copie le contenu dans des écrans d'app, ou il repart de zéro avec du code sur mesure. Ce choix détermine ce que voient vos lecteurs, ce que dira Apple au moment de la validation et ce que vous aurez à maintenir ensuite.

Encapsuler est la voie la plus rapide : tout ce qui fonctionne sur votre site mobile fonctionne dans l'app dès le premier jour. C'est aussi sa limite : l'app est exactement aussi rapide et aussi lisible que votre thème mobile. La synchronisation vous donne de vrais écrans d'app, mais seul ce que le connecteur synchronise arrive dans l'app. Reconstruire n'a pas d'autre limite que la facture : une app sur mesure est un projet logiciel que vous payez pour le construire, puis pour le maintenir à jour à chaque nouvelle version d'iOS et d'Android.

La directive 4.2 des App Store Review Guidelines demande des fonctionnalités, des contenus et une interface qui aillent au-delà d'un simple site web reconditionné. Une app qui se contente d'afficher un site qu'un navigateur affiche déjà est le cas d'école du refus.

Les outils d'encapsulation le savent : c'est pour cela qu'ils ajoutent une navigation native, des notifications push et des écrans hors ligne autour de la WebView. Une app synchronisée part de l'autre bout : chaque écran est déjà un écran d'app, et le site web ne fournit que le contenu.

Dans les deux cas, la validation reste imprévisible. Sur les premières soumissions prises en charge par notre équipe de publication au cours des 12 derniers mois, Apple en a refusé environ 42 %, pour toutes sortes de raisons, et 91 % de ces apps ont été acceptées une fois que l'équipe est intervenue (chiffres internes, avril 2026). Si vous préférez ne pas vous en occuper, GoodBarber Takes Care se charge de la soumission pour vous.

GoodBarber a choisi la synchronisation. Le plugin GoodBarber figure dans le répertoire WordPress depuis 2012, et sa version actuelle, sortie en mars 2026, est testée avec WordPress 6.9. Il s'appuie sur JSON API, un plugin très répandu dans la communauté WordPress, et il ne fait qu'une chose : permettre à votre app de lire vos articles, de façon sécurisée.

Dans l'app, une section WordPress affiche vos articles avec tout ce qu'un lecteur attend :

• Les articles complets avec leurs images, dans la mise en page que vous choisissez pour la section. L'app ne charge pas votre thème : GoodBarber prétraite, compresse et met en cache vos contenus et vos images, si bien que les articles s'ouvrent à la vitesse d'une app, pas à celle de votre thème.
• Vos catégories comme filtres. Chaque catégorie WordPress peut devenir un onglet de la section.
• Les commentaires. Les lecteurs lisent et publient des commentaires depuis l'app, et ces commentaires arrivent dans WordPress avec les autres. Une case à cocher dans les réglages du plugin permet de les désactiver.
• Recherche, articles les plus populaires, chargement de la suite. Les lecteurs fouillent vos archives et parcourent les articles plus anciens sans quitter l'app.

L'app qui entoure cette section est native : compilée en Swift sur iOS et en Kotlin sur Android, avec en plus une version web de la même app. La section WordPress côtoie les autres sections que vous ajoutez, comme une page contact, une carte, un agenda ou des vidéos. L'extension WordPress est gratuite, pour les apps de contenu comme pour les apps eCommerce.

Il vous faut un accès administrateur à votre site WordPress et une app GoodBarber ; l'essai gratuit suffit.

1. Dans WordPress, allez dans Extensions > Ajouter une extension, cherchez « GoodBarber », installez le plugin puis activez-le.
2. Ouvrez Réglages > GoodBarber API et copiez la clé GoodBarber (GoodBarber Key) affichée en gras.
3. Dans le back office GoodBarber, ouvrez Mon app > Structure et cliquez sur Ajouter une section.
4. Choisissez WordPress, nommez la section, saisissez l'URL racine de votre site (https://www.example.com, pas une page de catégorie) et collez la clé.
5. Ajoutez des filtres qui correspondent à vos catégories WordPress, puis choisissez la mise en page de la section.
6. De retour dans les réglages du plugin, cochez l'option qui n'autorise que les serveurs GoodBarber à dialoguer avec le plugin.

Si les articles ne s'affichent pas comme prévu, vérifiez trois réglages côté WordPress : un pare-feu qui bloque les serveurs de GoodBarber, un plugin de cache qui met en cache les appels ?gbjson du plugin, et, dans Réglages > Lecture, une option réglée sur Extrait au lieu de Texte complet, qui tronque les articles. Le guide de dépannage liste les plages d'adresses IP à autoriser, et le guide pas à pas montre chaque écran.

Sur WordPress.com, où vous ne pourrez pas forcément installer de plugins, utilisez plutôt le connecteur WordPress.com : il ne lui faut que l'URL de votre blog.

Une fois la section connectée, vous continuez à publier là où vous l'avez toujours fait. Chaque nouvel article arrive tout seul dans l'app et, si le push automatique est activé pour la section, vos lecteurs reçoivent une notification avec le titre de chaque nouvel article. Pas de copier-coller, pas de second éditeur, pas de push à rédiger à la main. Pour une information urgente ou un appel aux dons, vous pouvez toujours envoyer un push manuel, immédiatement ou programmé, à tout le monde ou à un segment de votre audience.

Vos archives deviennent aussi une source que vos lecteurs peuvent interroger. L'extension Chatbot indexe le contenu de votre section WordPress et répond aux lecteurs à partir de vos propres articles, avec un lien vers la source. Chaque fois que vous publiez ou mettez à jour un article, la base de connaissances du Chatbot se met à jour.

Le plugin synchronise vos contenus. Il ne synchronise pas les personnes, et c'est la répartition logique.

• Les comptes utilisateurs restent dans WordPress. Les abonnés, les membres et leurs mots de passe ne passent pas dans l'app. Les lecteurs qui ont besoin d'un compte le créent dans l'app, avec les outils de connexion et d'espace membres propres à GoodBarber, et leurs données sont hébergées en Europe, comme le reste de l'app. Les articles réservés aux membres sur WordPress restent eux aussi sur le site, puisque seuls les articles publics sont synchronisés. Si vous vendez l'accès à des contenus, l'app dispose de ses propres abonnements et de ses achats intégrés.
• Les pages, les types de publication personnalisés et les produits restent sur le site. Votre page À propos, les événements d'un plugin d'agenda ou les produits WooCommerce ont besoin de leur propre place dans l'app : des sections natives À propos, Contact, Carte ou Agenda, ou, pour une boutique, une app eCommerce GoodBarber dont vous pouvez importer le catalogue depuis un fichier CSV.
• Votre thème et ses plugins restent sur le site. L'app affiche vos articles avec son propre design. Les fonctionnalités interactives que des plugins ajoutent à une page, comme un module de réservation ou un quiz, appartiennent au site ; l'app affiche le texte et les images de vos articles.

Si la valeur de votre site tient à ces plugins plutôt qu'à ce que vous publiez, un outil d'encapsulation ou un créateur d'apps dédié à WordPress vous servira mieux. Le comparatif ci-dessous vous dit lequel.

La même logique de synchronisation fonctionne avec d'autres plateformes, chacune avec son propre connecteur :

Un site sans aucun flux, un site vitrine statique par exemple, n'a rien à synchroniser. Ses pages sont recréées une seule fois dans le CMS de GoodBarber, et c'est de là que vous publiez ensuite.

Prix publiés en octobre 2026, pour une app sur iOS et Android.

Lisez chaque prix à la lumière de ce qu'il couvre. Une formule GoodBarber inclut l'hébergement de l'app, le back office, la version web et les notifications push (30 000 par mois en Premium) ; WPMobile.App, par exemple, envoie les push via vos propres comptes Firebase et Apple.

Pour choisir, demandez-vous où se trouve la valeur de votre site. Si elle tient à ce que vous publiez, synchronisez-le. Si elle tient à ce que font vos plugins (un tunnel de paiement, des cours ou une communauté), encapsulez-le ou choisissez un créateur d'apps qui prend en charge ces plugins. Si aucune de ces options ne couvre votre projet et que vous en avez le budget, faites-le reconstruire par un développeur.

Pour voir d'un coup d'œil ce que le plugin GoodBarber apporte à l'app, et ce qui reste sur votre site, consultez notre page consacrée à l'application mobile WordPress.

Installez le plugin, connectez une section WordPress et regardez vos propres articles dans l'aperçu de l'app avant de décider quoi que ce soit. Vous le faites vous-même, sans développeur.

Commencer gratuitement : essai gratuit de 30 jours, sans carte bancaire. Pour aller plus loin, consultez la page de l'extension WordPress ou le guide pas à pas.

Peut-on transformer son site WordPress en application gratuitement ?

Le plugin GoodBarber et l'extension WordPress sont gratuits, et vous pouvez connecter votre site pendant l'essai gratuit de 30 jours, sans carte bancaire. Pour publier, il vous faut une formule : la version web à partir de la formule Standard, les apps iOS et Android à partir de la formule Premium.

Une app WordPress créée avec GoodBarber est-elle native ou une WebView ?

Native. L'app est compilée en Swift pour iOS et en Kotlin pour Android. Vos articles sont synchronisés en tant que contenus et affichés dans les écrans propres à l'app, pas chargés comme des pages web.

Mes utilisateurs et mes membres WordPress passent-ils dans l'app ?

Non. Le plugin synchronise les contenus, pas les comptes utilisateurs. Les lecteurs qui ont besoin d'un compte en créent un dans l'app, et les articles réservés aux membres sur WordPress restent sur le site, puisque seuls les articles publics sont synchronisés.

Les pages WordPress et les produits WooCommerce sont-ils synchronisés aussi ?

Non, seuls les articles publics le sont. Les pages sont recréées avec les sections natives de l'app, comme À propos, Contact ou Carte. Une boutique passe par une app eCommerce GoodBarber, dont vous pouvez importer le catalogue depuis un fichier CSV.

Mes lecteurs sauront-ils quand je publie un nouvel article ?

Oui. Les nouveaux articles arrivent dans l'app sans aucune étape supplémentaire, et le push automatique envoie aux lecteurs une notification avec le titre de chaque nouvel article.

Créer une app : les 3 méthodes en un coup d'œil

Pour une app de contenu ou de commerce mobile, l'app builder l'emporte sur le coût et le délai. Pour un jeu ou une place de marché à la Airbnb, passez par un développement sur mesure : ce n'est pas ce que fait GoodBarber.

Aujourd'hui, le marché l'application mobile est en pleine expansion, notre société s'appuyant de plus en plus sur les smartphones et les technologies numériques en ligne.

Selon Statista, en 2023, 257 milliards d'applications ont été téléchargées sur les écrans.

Il existe clairement une forte demande d’applications, ce qui rend le marché mobile extrêmement concurrentiel.


Pour créer une application mobile, il faut avoir un projet original, de l’expertise, du temps et surtout des bonnes raisons. Nous avons trouvé au moins 5 raisons que peuvent vous motiver à créer une application mobile :

• Améliorer la visibilité et la réputation de la marque


• Offrir des fonctionnalités spécifiques à vos clients


• Générer des interactions adaptées à vos besoins


• Profiter de l'omniprésence des technologies mobiles


• Améliorer la rapidité et la qualité des interactions pour vos utilisateurs

Souvent, les gens commettent l'erreur se lancer directement au lieu de prendre le temps d'analyser leurs idées, leurs connaissances et de comprendre les différentes étapes nécessaires à la création d'une application performante.

Que vous créiez une application pour compléter votre site Web, pour toucher un nouveau public pour votre entreprise ou simplement pour avoir une bonne idée de nouvelle application, cet article est un guide simple pour les débutants qui souhaitent savoir comment démarrer une application pour la première fois et explore chaque étape du processus de création, de votre idée à la publication et à la maintenance de votre application. 

Comment créer une app en 7 étapes :

1. Mettre vos idées sur papier




2. Choisir votre technologie




3. Choisir la meilleure option pour développer votre application




4. Créer votre application avec un app builder (sans code)




5. Tester votre application




6. Publier votre application sur les stores




7. Mettre à jour et améliorer votre app

En bref : définissez le problème que votre app résout, pour qui, et dessinez ses écrans principaux avant d'ouvrir un outil.

• Définissez vos objectifs, recherchez le marché et définissez votre concept. Voici quelques-unes des principales questions que vous devrez vous poser.


•  Quel est votre public cible? Votre application doit être spécialement conçue pour ajouter de la valeur à votre audience.


•  Quelles fonctionnalités sont les plus souhaitables et vous aideront à garder vos utilisateurs engagés.


•  Découvrez s'il y a d'autres applications qui font la même chose


•  Découvrez la concurrence, leur avis, inspirez-vous pour votre design


•  Voulez-vous monétiser votre application?

• Le design : développer un prototype

1. ​​Créer une maquette de votre app: une maquette vous permet de vous concentrer sur les parties essentielles de votre interface, avant même de commencer à travailler les éléments du design et les styles. En faisant cela, il vous sera plus facile d’identifier où placer les composants clés de l’app et comment les rendre accessibles aux utilisateurs via leurs écrans. Utiliser une maquette vous permet également de faire des changements dans l’ébauche de l’interface plus rapidement que si vous travailliez directement avec la version finale.


2. ​UI design (User Interface) : l'aspect et la navigation de votre application jouent un rôle crucial dans le succès d'une application. C'est la manière dont votre application mobile interagit avec ses utilisateurs. L'interface utilisateur doit être uniforme et simple.


3. ​UX (User Experience) : c'est le point de vue de vos utilisateurs. Cela aura un impact sur la façon dont ils voient votre marque. Ce doit être sans accros. N'oubliez pas non plus que vos utilisateurs naviguent sur votre application sur un petit écran (selon les recommandations d'Apple, une taille d'environ 44 pixels carrés convient à une taille tactile.)


4. Règle des 3 clics : pour créer une app réussie, vous devez la concevoir de manière à ce qu'elle demande le moins d'efforts possible à ses utilisateurs afin de comprendre et d'apprécier l'application. Une application mobile difficile à gérer réduit leurs interactions et leur engagement. Laissez-vous guider par la règle des 3 clics qui suggère que les utilisateurs doivent pouvoir trouver n'importe quelle information sur un site Web (ou app mobile) en ne nécessitant pas plus de trois clics de souris. Ne suivez pas strictement cette règle, gardez simplement l'idée de la façon de concevoir la navigation de l'application.

En bref : une app native passe par l'App Store et Google Play et accède à tout le téléphone ; une PWA s'ouvre depuis une URL, s'installe sans store et se référence sur Google.

• Applications natives:

• Progressive Web Apps: 

• Les Progressive Web Apps se vantent d’obtenir 3 fois plus de visiteurs que les apps natives, mais les fonctionnalités disponibles dépendent des navigateurs sur lesquels elles sont utilisées.


• Les apps natives offrent l’accès à des fonctionnalités de géolocalisation (comme la technologie des geofences et des beacons) mais les publier implique des coûts additionnels significatifs ainsi que la conformité avec une tierce partie. 

En bref : trois méthodes : la développer vous-même, la confier à une agence, ou utiliser un app builder sans code. Le tableau en haut de ce guide les compare ; voici comment trancher.

• Développez votre application mobile vous-même

• Engager une agence ou un développeur 

• Utilisez un app builder.

Ces trois options se départagent surtout sur le budget et le délai. On a détaillé chacune dans nos ressources : combien coûte le développement d'une application mobile, faire développer son application, et la développer sans coder.

En bref : dans l'app builder, vous réglez le design, ajoutez vos contenus en sections, puis activez les fonctionnalités dont vous avez besoin. L'aperçu se met à jour à chaque modification.

• Design: Il y a pas mal de choses à décider ici pour la mise en forme : le thème de couleur global de l’app, le style du header, le mode de navigation, l’icône qui représentera votre app dans les stores et/ou sur l’écran principal de vos utilisateurs, l’écran de lancement, etc. Quand vous travaillez le design de ces éléments, il est toujours bon de rester consistant avec le design qui identifie déjà votre marque, comme le logo, les couleurs, les typographies, etc.

• Contenu: Il est temps d’ajouter tous les éléments que vous voulez partager à propos de votre business/projet : photos, fichiers audio, maps et plus encore. Dans certains cas, vous pourrez tout simplement créer le contenu directement depuis le back office de la plateforme. Dans d’autres cas, votre contenu pourra déjà être disponible sur une source externe et vous n'aurez plus qu'à le synchroniser (grâce à un flux RSS, un live stream, ou un média social).

• Extensions (Fonctionnalités) : en plus des sections classiques, GoodBarber propose un catalogue de fonctionnalités complémentaires pour ajouter de la valeur à votre application en fonction de vos besoins.

• Plug-ins : explorez les options de customisation offertes par notre plateforme et ajoutez les fonctionnalités ou options de design qui n'étaient pas disponibles par défaut. La personnalisation est le moyen le plus efficace de faire en sorte que votre application se démarque des autres.

En bref : testez chaque version (iOS, Android, PWA) sur de vrais appareils, avec quelques bêta-testeurs et une checklist, avant de soumettre l'app aux stores.

En bref : ouvrez un compte développeur (99 $ par an chez Apple, 25 $ une fois chez Google), préparez la fiche de chaque store, puis soumettez l'app à la revue. La PWA, elle, se publie immédiatement.

Une fois que votre application est prête, il est temps de penser à la publier. C’est une bonne idée de publier votre application sur autant de plates-formes que possible, car cela vous permettra d’atteindre autant d’utilisateurs que possible.

Publier sur les stores : ce qu'il faut prévoir

La publication d'une application peut être un processus complexe et fastidieux, à commencer par l'enregistrement en tant que développeur.

• Comptes de développeurs (étape obligatoire des deux plateformes). Pour les appareils Apple, vous vous abonnez au programme pour développeurs de l'App Store, au tarif de 99 $ par année d'abonnement. N'oubliez pas qu'Apple exige que le propriétaire du contenu de l'application corresponde à celui du compte de développeur. Par conséquent, si vous publiez plusieurs applications iOS pour différents projets, chacune d'entre elles doit disposer de son propre compte de développeur. Devenir un éditeur Google Play coûte 25 USD (une seule fois) et vous devez également posséder un compte Gmail.

• App Store: le processus de soumission d'une application sur l'App Store est complexe et nécessite une préparation complète. Apple a défini des directives strictes afin de maintenir sur l’App Store un écosystème sécurisé offrant uniquement à ses utilisateurs des applications de haute qualité.

App Store Review: Apple examine chaque application avant de la valider. Avant de soumettre votre application pour review vous devez fournir une collection d'informations (Icône, app preview / captures d'écran) et métadonnées (nom de votre application, sa catégorie, une description détaillée et des mots-clés supplémentaires pour ASO). Ne sous-estimez pas l’importance de la metadata, en particulier de la description de l’application.

Publication dans l'App Store: le processus de review peut prendre quelques jours. Apple vous avertira par mail lorsque votre application est publique. En cas de refus, vous pourrez contacter le centre de résolution pour plus d'informations et essayer de résoudre les problèmes.

Apple refuse environ 42 % des premières soumissions iOS que suit notre équipe de publication. Sur les 12 derniers mois, 91 % de ces apps refusées ont été acceptées après l'intervention de l'équipe GoodBarber Takes Care, qui peut prendre en charge toute la publication sur l'App Store et Google Play (chiffres internes, avril 2026).

GoodBarber a mis en place une review pour vous guider tout au long du processus de soumission. Notre équipe procédera à un examen détaillé de votre application pour vous assurer qu'elle est conforme aux directives de l'App Store. Si votre application ne répond pas à ces exigences, nous vous fournirons des conseils pour vous aider à améliorer votre application et à la publier avec succès.

 

• Google Play: Android propose différents choix de distribution d'applications. Toutefois, avec plus d'un milliard d'utilisateurs actifs, Google reste la première plate-forme pour les applications Android.

Store listing et informations obligatoires: après avoir créé votre application sur votre console Google, vous devrez enregistrer les informations qui seront affichées sur Google Play. Il comprend des informations obligatoires telles que: titre, description courte, description complète, éléments graphiques, catégorie, coordonnées, politique de confidentialité. Choisissez avec soin les mots-clés que vous utiliserez, l’optimisation du classement de votre application dans le Store en dépend.

Fichier APK et version de l'application: une fois la liste de la boutique complétée, il est temps de télécharger votre fichier apk. Le Android Package contient tous les éléments de votre application. Suivez ensuite le guide de la console Google pour déployer et publier votre application. Si votre application est approuvée, elle sera publiée dans quelques heures, même si Google a récemment annoncé qu’il prendrait plus de temps pour examiner les applications des développeurs qui n’avaient pas encore publié dans Google. N'oubliez pas de respecter les règles établies, car Google peut retirer votre application à tout moment par la suite, si ce n'est pas le cas.

• Progressive Web App (PWA):

 Heureusement, la publication Progressive Web App est beaucoup plus simple. Tout ce que vous avez à faire est de prendre en charge l'hébergement de l'application sur un serveur Web et d'y lier un domaine Web. Ce processus étant si simple et rapide, vous avez plus de temps à consacrer à l'optimisation de votre référencement afin que votre produit soit facilement détecté par le public.

 L'hébergement est inclus dans votre abonnement GoodBarber, et nous vous recommandons vivement d'acheter votre propre nom de domaine et de l'installer à la place de l'URL générée par GoodBarber, car cela vous permettra de créer une image plus forte sans la présence d'une autre marque.

Ne lancez pas toutes les fonctionnalités en même temps: cela vous permet de développer davantage votre application et de lancer une version mise à jour ultérieurement.

Avec le service GoodBarber Takes Care, vous laissez nos experts faire le travail à votre place. Ils se chargeront du processus de publication de votre application sur Google Play et sur l'App Store afin que vous puissiez cibler votre stratégie marketing.

En bref : suivez les avis et les statistiques d'usage, et publiez régulièrement contenus et fonctionnalités : c'est ce qui évite qu'une app soit désinstallée.

• Écoutez vos utilisateurs. Lisez les avis des stores et les retours directs.
• Suivez vos statistiques. Nombre de lancements par jour, temps passé par section : ces indicateurs montrent comment l'app est réellement utilisée.
• Publiez régulièrement. Nouveaux contenus, nouvelles fonctionnalités : faites-les savoir par notification push, ou en les mettant en avant sur la page d'accueil.

En bref : un assistant comme ChatGPT aide à préparer le projet, mais ne publie pas d'application. Dans GoodBarber, l'IA intervient sur des tâches précises de la création et de la gestion de l'app.

Ce que l'IA fait, et ce qu'elle ne fait pas:

Le design, la structure et les décisions restent les vôtres. Pour un guide pas à pas : créer votre app avec l'IA.

Des outils tels que les assistants éditoriaux d'IA et les chatbots contextuels permettent de gagner du temps et d'améliorer la qualité de l'expérience utilisateur, simplifiant des tâches qui nécessiteraient traditionnellement des compétences avancées en développement ou en design.

L'intégration de l'intelligence artificielle agit comme un multiplicateur de force dans trois domaines critiques :

• 
  

  Idéation et Stratégie : l'IA peut analyser les avis des concurrents sur les stores pour identifier les "lacunes" du marché et suggérer des fonctionnalités uniques (Unique Selling Points).



• 
  

  Design et Interface Utilisateur (UI) : il ne s'agit plus seulement de glisser-déposer (drag-and-drop). Les interfaces d'IA modernes peuvent générer des palettes de couleurs ou des mises en page complètes en se basant simplement sur le secteur d'activité indiqué par l'utilisateur, garantissant ainsi une cohérence esthétique.



• 
  

  Gestion des Contenus : la partie la plus fastidieuse d'une application est souvent l'intégration des données. Les outils d'écriture assistée et la traduction neuronale permettent de lancer des applications multilingues en une fraction du temps habituel.

Pourquoi cette approche est-elle révolutionnaire ?

• 
  

  Élimination du "Syndrome de la page blanche" : l'IA fournit une base solide, réduisant les frictions initiales liées au design.



• 
  

  Qualité "Enterprise" pour les PME : même une petite entreprise peut avoir des textes impeccables et des traductions professionnelles, autrefois réservées à ceux qui avaient le budget pour des agences externes.



• 
  

  Itération rapide : l'étape "test et publication" devient plus rapide car l'IA peut aider à identifier les incohérences techniques ou éditoriales avant même l'envoi aux stores.

1. Les applications mobiles natives

Créer une app iOS pour iPhone

Environnement de développement pour iOS

Créer une app ANDROID

Java, le plus populaire

Kotlin est intégré à Android Studio

C et C++ sont possibles avec des ajustements

C# sur Xamarin

2. Créer une Progressive Web App (Applications Web)

• Statista : téléchargements d'applications dans le monde, 2023.
• Progress Kinvey : durée moyenne de développement d'une application mobile (18 semaines).
• Google Research : première impression et complexité visuelle des pages web.
• Apple : Apple Developer Program (99 $ par an) ; App Review (délai de revue) ; conseils de design.
• Google : frais d'inscription à la Play Console (25 $) ; exigences de test des nouveaux comptes personnels ; Kotlin-first.
• Microsoft : fin du support de Xamarin.
• GoodBarber : tarifs publics sur la page Tarifs ; clients, téléchargements et extensions, données internes ; taux de refus et d'acceptation Apple, équipe de publication GoodBarber Takes Care, avril 2026.

• 7 bonnes raisons de créer une app avec GoodBarber

• Les FAQ à propos de la création d'apps mobiles 

• Comment publier votre application mobile sur Google Play et l’App Store

• Comment choisir le nom parfait pour votre app

• Tutoriel : Paramétrer le design de votre app

Nous avons transformé un calculateur de devis Excel en section d'app avec l'AI Extension Builder. Même total, au centime près. Fichiers et prompt inclus.

La plupart des tableurs que l'on veut transformer en application contiennent deux choses. Des données : une grille de prix, un catalogue de produits, un planning, un annuaire de membres. Et une logique : les formules qui transforment ces données en réponse, un devis, un total, une mensualité.

Une application a besoin des deux. Les données doivent se lire sur un téléphone, triées et consultables par recherche. La logique doit donner exactement le même résultat que le tableur, sinon personne ne lui fera confiance.

Trois chemins mènent là :

Cet article teste la troisième méthode sur un vrai fichier, du début à la fin, et montre chaque étape.

Nous avons construit le genre de classeur qu'une entreprise de rénovation garde sur son ordinateur portable. Il est en anglais et compte deux onglets :

• Price list (grille de prix) : 30 postes de travaux, de la dépose de faïence à la pose d'un plan de travail, chacun avec une référence, une catégorie, une unité (m², unité ou mètre linéaire) et un prix unitaire.
• Quote (devis) : le calculateur. Vous saisissez une référence et une quantité dans les cellules jaunes, RECHERCHEV rapporte le poste et son prix, et le reste suit : totaux de ligne, main-d'œuvre supplémentaire, remise, TVA, total et acompte de 30 %.

Le devis d'exemple du fichier est une rénovation de salle de bains : 10 lignes, 16 heures de main-d'œuvre supplémentaire à 45 € de l'heure, une remise de 5 % et une TVA à 20 %. Excel donne un total de 5 269,08 € TTC, avec un acompte de 1 580,72 €. C'est le chiffre que l'application doit retrouver.

Les deux fichiers sont en téléchargement libre pour refaire le même test : le classeur Excel et son export CSV, price-list.csv.

Le module lit des fichiers de données, CSV ou JSON, pas des classeurs Excel. La première étape consiste donc à enregistrer l'onglet des prix au format CSV : dans Excel, ouvrez l'onglet, puis Fichier > Enregistrer sous > CSV UTF-8 (délimité par des virgules).

Ouvrez ensuite le fichier dans un éditeur de texte et vérifiez la première ligne. Elle doit se lire ref,category,item,unit,unit_price. Attention : un Excel réglé en français sépare souvent les colonnes par des points-virgules, même avec ce format, et le module attend aujourd'hui des virgules. Le plus simple est alors de passer par Google Sheets : importez le classeur, puis Fichier > Télécharger > Valeurs séparées par des virgules (.csv). Google Sheets utilise toujours des virgules.

Gardez une seule ligne d'en-tête, une ligne par poste, aucune cellule fusionnée et aucun total en bas. Le CSV porte vos données ; les formules viennent à l'étape 3.

Dans le back office, ajoutez une nouvelle section et choisissez Créer avec l'IA, le type de section de l'AI Extension Builder. Avant d'écrire quoi que ce soit, cliquez sur le bouton trombone sous le champ du prompt et sélectionnez le CSV.

Le module connaît alors la forme du fichier : ses colonnes, leurs types, le nombre de lignes et deux lignes d'exemple. Il ne recopie pas vos 30 lignes dans son code. La section qu'il écrit charge price-list.csv à chaque ouverture : les prix vivent dans le fichier, pas dans le code.

Captures : les 30 lignes du CSV affichées en catalogue classé par catégorie, puis le même catalogue filtré par le mot « tiling » (carrelage).

C'est la partie qu'un convertisseur fait pour vous, et celle que vous faites vous-même ici : le module ne lit pas les formules, vous les décrivez. Chaque formule de l'onglet Quote devient une ligne du prompt.

Voici le prompt complet, tel que nous l'avons tapé. Il est en anglais pour cette démo ; vous pouvez écrire le vôtre en français.

La première version affichait la ligne de main-d'œuvre sous forme de taux, 16 h × 45,00 €/h, sans le montant. Un message de suivi a suffi à corriger :

Nous avons ouvert la section publiée sur un écran de la taille d'un téléphone, saisi le devis de salle de bains du fichier Excel et comparé chaque ligne. Test réalisé le 30 septembre 2026 :

Captures : les lignes du devis avec leurs quantités, puis le récapitulatif avec le même total que le fichier Excel.

Vous pouvez essayer la démo en ligne : elle tourne dans la version web d'une app de test, en anglais. Ajoutez quelques lignes et comparez avec le classeur.

• La recherche et les catégories. Tapez « tiling » et le catalogue se réduit à trois postes. Dans le tableur, vous faites défiler.
• Le devis reste sur le téléphone. Fermez l'app, revenez plus tard : les lignes, les heures et la remise sont toujours là.
• Elle ressemble au reste de votre app. La section reprend automatiquement les polices et les couleurs de votre application ; rien à styler à la main.
• Elle part avec votre app. La section fait partie de la version web sur toutes les offres, et des apps iOS et Android à partir de l'offre Premium.

• Pas de fichiers .xlsx. Le module lit le CSV et le JSON. Exportez d'abord l'onglet qui contient vos données.
• Pas de lecture des formules. Vous les décrivez. Une dizaine tient dans un prompt ; un classeur avec des centaines de formules enchaînées, des macros ou des tableaux croisés dynamiques relève d'un convertisseur qui les garde telles quelles.
• Des données modestes et stables. Une grille de prix, un catalogue, un planning. Des données que plusieurs personnes modifient chaque jour ont leur place dans une base de données, et le module peut relier une section à une base Supabase pour cela.
• Vérifiez les chiffres. L'agent écrit le code à partir de votre description. Testez-le sur un devis que vous connaissez déjà, comme nous l'avons fait ici, avant que vos clients l'utilisent.

Choisissez un onglet, celui sur lequel vos clients vous interrogent le plus : une grille de prix, une carte, des horaires. Exportez-le en CSV, ajoutez une section Créer avec l'IA et décrivez ce que l'application doit en faire. Gardez le fichier Excel ouvert à côté de l'aperçu et comparez les résultats ligne par ligne.

Démarrer gratuitement : construisez votre première section pendant l'essai gratuit de 30 jours, sans carte bancaire. Pour aller plus loin, lisez notre guide de l'AI Extension Builder ou consultez la page de l'extension.

Peut-on transformer un tableur Excel en application sans coder ?

Oui. Exportez les données en CSV, joignez le fichier à une section Créer avec l'IA dans GoodBarber et décrivez les formules en langage courant. L'AI Extension Builder écrit la section, et vous la vérifiez avec un résultat que vous connaissez déjà dans Excel.

Peut-on convertir un fichier Excel en application Android ?

Oui, sous la forme d'une section de votre application GoodBarber. GoodBarber construit et publie les apps Android et iOS à partir de l'offre Premium, et la version web sur toutes les offres. Vous ne compilez rien vous-même.

L'application lit-elle directement mon fichier .xlsx ?

Non. Le module lit les fichiers CSV et JSON. Enregistrez l'onglet qui contient vos données au format CSV UTF-8, avec des virgules comme séparateurs, et déposez ce fichier.

L'application calculera-t-elle exactement comme mon tableur ?

Seulement si le prompt décrit les formules exactement, arrondis compris. Dans notre test, l'application a retrouvé Excel sur chaque ligne, au centime près. Vérifiez toujours avec un devis que vous avez déjà calculé dans Excel.

Combien ça coûte ?

L'AI Extension Builder est une extension gratuite pour les applications Contenu et eCommerce. Vous payez l'offre GoodBarber qui publie votre application : la version web dès l'offre Standard, les apps iOS et Android à partir de l'offre Premium.

Sur l'écran de connexion, trois nouveaux boutons accompagnent le formulaire habituel : Google, Apple, et un lien de connexion envoyé par e-mail.

Continuer avec Google. Vous choisissez votre compte Google, et vous êtes connecté. Pas de nouveau mot de passe à inventer, pas de formulaire à remplir.

Connexion avec Apple. Même chose avec votre identifiant Apple, sur iPhone, sur Mac, mais aussi depuis un ordinateur Windows ou un téléphone Android.

Votre mot de passe, lui, fonctionne exactement comme avant. Rien ne vous oblige à changer vos habitudes : les nouvelles options s'ajoutent, elles ne remplacent rien.

Vous n'avez ni compte Google ni compte Apple sous la main ? Demandez un lien de connexion. Vous saisissez votre adresse, et nous vous envoyons un e-mail qui contient à la fois un lien et un code à six chiffres.

Sur l'appareil où vous lisez vos e-mails, cliquez sur le lien. Sur un autre, par exemple un ordinateur alors que l'e-mail arrive sur votre téléphone, tapez simplement le code dans les six cases. Dans les deux cas, vous êtes connecté. Le code n'est valable que 15 minutes et ne sert qu'une fois.

Nous n'avons pas voulu d'une nouveauté réservée à un seul écran. Les trois options sont disponibles sur :

• la création d'app, quand vous démarrez un nouveau projet sur goodbarber.com ;
• le back office de votre app, là où vous la concevez et la gérez au quotidien ;
• l'espace revendeur, pour les agences qui gèrent les apps de leurs clients ;
• l'app My GoodBarber et sa version Commerce, pour suivre votre app depuis votre téléphone ;
• l'app Shop Companion, celle qu'utilisent vos équipes pour gérer les commandes en boutique.

Un seul compte, une seule façon de vous connecter, quel que soit l'endroit. Si vous créez votre app avec Google ce matin, c'est avec Google que vous ouvrirez Shop Companion ce soir.

Si vous utilisez déjà GoodBarber avec un mot de passe, et que votre compte Google ou Apple porte la même adresse e-mail, nous vous reconnaissons à cette adresse et vous ramenons sur votre compte existant. Vos apps, vos réglages et votre historique restent où ils sont.

Une seule précaution s'ajoute la première fois : avant de relier Google ou Apple à un compte protégé par un mot de passe, nous vous demandons de prouver que ce compte est bien le vôtre. Vous saisissez votre mot de passe actuel, ou vous demandez un lien de confirmation, envoyé à votre adresse. Votre mot de passe n'est pas modifié. Cela ne prend que quelques secondes, et cela n'arrive qu'une fois. Les fois suivantes, un clic suffit.

Pourquoi cette étape ? Parce qu'une adresse e-mail seule ne prouve pas qui tient le clavier. Sans elle, quelqu'un qui créerait un compte Google ou Apple avec votre adresse pourrait entrer dans votre compte GoodBarber. Nous préférons vous demander une confirmation que prendre ce risque avec votre app. Et dès que Google ou Apple est relié à votre compte, nous vous envoyons un e-mail pour vous le signaler : si ce n'était pas vous, vous le savez tout de suite.

Apple vous propose de garder votre véritable adresse pour vous et de partager une adresse relais à la place. GoodBarber l'accepte : vos e-mails vous parviennent normalement, relayés par Apple.

Un conseil, si vous avez déjà un compte GoodBarber : choisissez plutôt de partager votre véritable adresse. C'est elle qui permet de vous retrouver. Avec une adresse relais, nous ne pouvons pas faire le lien, et un nouveau compte, vide, serait créé à côté du vôtre.

Un compte créé avec Google, Apple ou un lien de connexion n'a pas de mot de passe, et il n'en a pas besoin. Si vous voulez en ajouter un plus tard, par exemple pour vous connecter depuis un appareil où vous n'utilisez pas Google, rendez-vous sur la page de votre profil dans le back office. Nous vous envoyons un e-mail dès que le mot de passe est enregistré.

Vous n'avez rien à activer : les boutons sont déjà sur votre écran de connexion. La prochaine fois que vous ouvrez votre back office, choisissez Google, Apple ou le lien de connexion, et gardez votre mot de passe pour les jours où vous en avez besoin.

Vous n'avez pas encore d'app ? Démarrez votre essai gratuit sur goodbarber.com en un clic avec votre compte Google ou Apple, et construisez une première version dans la foulée.

Si quelque chose vous bloque, écrivez à notre équipe support depuis votre back office en précisant l'écran et la méthode utilisée. C'est avec vos retours que nous ajustons ces parcours.

Dois-je abandonner mon mot de passe ?

Non. Votre mot de passe continue de fonctionner partout. Google, Apple et le lien de connexion sont des options en plus.

Pourquoi me demande-t-on mon mot de passe alors que je clique sur Google ou Apple ?

Parce que l'adresse de votre compte Google ou Apple est déjà celle d'un compte GoodBarber protégé par un mot de passe. Nous vérifions une seule fois que ce compte est bien le vôtre avant de les relier. Si vous ne vous souvenez plus du mot de passe, demandez plutôt un lien de confirmation par e-mail.

Je n'ai pas reçu l'e-mail de connexion. Que faire ?

Vérifiez vos courriers indésirables, puis redemandez un code depuis l'écran de connexion, après quelques secondes d'attente. Le code n'est valable que 15 minutes : au-delà, il faut en demander un nouveau.

Est-ce que je peux me connecter avec Apple sur un téléphone Android ?

Oui. La connexion avec Apple fonctionne aussi sur Android et sur Windows, avec votre identifiant Apple habituel.

Les membres de mon équipe peuvent-ils aussi utiliser ces options ?

Oui. Chaque personne se connecte avec sa propre adresse, en choisissant la méthode qui lui convient.

Cinq voies mènent à une application de fitness, chacune avec son mode de prix : un forfait, une option de logiciel de salle, au client, à l'abonné ou sur devis. Le tableau ci-dessous compare ce que coûte chacune et le travail pour lequel elle est faite.

Cinq logiques de prix se cachent derrière ce tableau.

Les app builders no-code facturent un forfait. Vous assemblez l'application à partir de sections prêtes à l'emploi, et l'hébergement, la base de données, les mises à jour et les republications sur les stores tiennent dans cette seule ligne. Le prix ne bouge pas avec votre nombre de membres ou d'abonnés. Le cas général est dans notre article sur ce que coûte une application créée sans coder.

Les logiciels de salle vendent l'application en option d'une formule de gestion. L'un affiche des formules de 75 $ par mois jusqu'à 50 membres actifs à 200 $ de 201 à 400, et une application membres à la marque, publiée sur l'App Store et Google Play au nom de votre salle, pour 100 $ de plus par mois, le premier mois offert. Un autre démarre à 99 $ par mois et ajoute son application à la marque pour 39 $ ; un troisième facture 189 $ par mois de 101 à 200 clients actifs, et 99 $ pour l'application. Ces outils font un travail que GoodBarber ne fait pas : ils gèrent les places de cours, les listes d'attente, les cartes de séances et les paiements. Si vous en utilisez un, sa facture reste, quelle que soit l'application choisie.

Les plateformes de coaching facturent au client. L'une démarre à 19,90 $ par mois pour 3 clients et atteint 59,90 $ pour 25 clients avec des applications iOS et Android à votre marque, puis 2,40 $ par mois par client supplémentaire. Une autre démarre à 25 € par mois pour 3 clients et vend son application à la marque 95 €, une seule fois. Elles construisent les programmes d'entraînement et suivent la progression de chaque client, ce que GoodBarber ne fait pas.

Les plateformes vidéo facturent à l'abonné. L'une facture 149 $ par mois plus 1,99 $ par abonné sans application, et 449 $ par mois plus 0,99 $ par abonné avec deux applications, iOS et Android. Les deux tarifs s'entendent en facturation annuelle ; au mois, ils passent à 199 et 499 $. Ces plateformes diffusent votre vidéothèque et encaissent sur le web.

Le sur-mesure se chiffre sur devis. Quatre agences qui se classent sur cette question publient leurs propres estimations : de 30 000 à 50 000 $ pour une première version, et de plus de 75 000 à 600 000 $ pour une application complète, maintenance et mises à jour à prévoir en plus. Ce sont des estimations, pas des prix payés. Le repère de GoodBarber : un coût total de possession d'environ un dixième de celui d'un développement sur mesure.

Les prix ci-dessous viennent directement de l'API publique des tarifs de GoodBarber, le 24 septembre 2026, en euros. Le détail complet est sur la page des tarifs des Content Apps.

Live Video, une diffusion à sens unique depuis votre prestataire de streaming, est gratuite dès Premium.

Place à l'arithmétique, métier par métier. La Prise de rendez-vous construit des créneaux à partir de vos horaires d'ouverture, avec un agenda par coach ou par type de séance, et prend un rendez-vous par créneau, sans paiement : elle convient aux séances individuelles, aux séances d'essai et aux bilans de l'application d'un coach sportif, pas aux places d'un cours collectif. Le Système d'abonnements vend l'accès à vos contenus, et seulement à vos contenus, par abonnement intégré à l'application : les programmes, vidéos et audios de l'application d'un créateur. Les cours, les cartes de séances et les abonnements à la salle se paient hors de l'application, à l'accueil ou dans votre logiciel de salle. L'Authentification ouvre un espace membres aux personnes qui vous paient déjà, ce dont a besoin l'application d'une salle ou d'un studio, et la Carte de fidélité l'exige.

Trois règles en découlent. Une application native commence à Premium, parce que Standard est une web app sans aucune de ces trois extensions. Pro devient l'offre la moins chère dès que vous prenez à la fois la Prise de rendez-vous et le Système d'abonnements : 1 260 € par an, contre 1 300 € pour Premium avec les deux. Et installer le Système d'abonnements retire l'Authentification, les Groupes d'utilisateurs, la Communauté, le Chat, la Carte de fidélité, la Carte de membre et les Coupons : un créateur qui vend ses programmes par abonnement n'a pas de carte de fidélité. La façon de construire chacune de ces applications est dans notre guide de l'application de fitness.

La facturation annuelle coûte au plus dix mois du tarif mensuel. Une licence Pro à paiement unique existe aussi : 4 600 € pour dix ans.

Quel que soit l'outil retenu, certaines lignes viennent d'ailleurs.

• Apple Developer Program : 99 € par an, pour publier des applications iOS natives au nom de votre entreprise.
• Google Play Console : 25 €, une fois. Un compte Google personnel créé après le 13 novembre 2023 doit passer par un test fermé avec au moins 12 testeurs inscrits pendant 14 jours avant la mise en production ; un compte d'organisation au nom de votre entreprise n'y est pas soumis.
• La commission des stores sur les abonnements aux contenus, détaillée dans la section suivante.
• Un nom de domaine, que le Système d'abonnements exige, avec la web app. GoodBarber n'en vend pas.
• La production des contenus : tournage, montage, voix off, droits musicaux. C'est souvent la ligne la plus lourde du budget, et aucune page de tarifs ne l'affiche.
• Votre logiciel de salle, si vous le gardez pour les places de cours et les paiements.
• Les extensions qui restent payantes en Pro : la Carte de fidélité, la Carte de membre, les Coupons et le Chatbot.
• Le service de publication de GoodBarber, si vous préférez ne pas gérer les stores : 50 € les cinq crédits, un crédit par store, et il configure aussi vos abonnements sur les stores.

L'hébergement, la base de données, le CMS, les notifications push dans la limite de votre quota et les statistiques n'ajoutent aucune facture à part.

La commission ne touche qu'une chose : les abonnements à vos contenus vendus dans l'application. Les cours, les séances, les cartes de séances et les abonnements à la salle se paient hors de l'application, à l'accueil, dans votre logiciel de salle ou sur votre site, et aucun store ne prend rien dessus.

Sur les abonnements aux contenus, voici ce que disaient les pages officielles le 24 septembre 2026. Apple garde 30 % pendant la première année d'un abonné et 15 % ensuite, ou 15 % dès le premier jour si vous rejoignez son App Store Small Business Program, ouvert aux développeurs qui arrivent sur l'App Store et à ceux dont les revenus n'ont pas dépassé un million de dollars l'année précédente. Google Play prend 15 % sur les abonnements à renouvellement automatique : aux États-Unis, au Royaume-Uni et dans l'Espace économique européen, 10 % de frais de service plus 5 % de frais de facturation depuis le 30 juin 2026. GoodBarber ne prend rien sur vos ventes.

Sur un abonnement de 10 € par mois, vous recevez donc 8,50 € avant taxes sur Google Play ou avec le Small Business Program d'Apple, et 7 € pendant la première année d'un abonné chez Apple hors de ce programme. Fixez votre prix sur les stores en tenant compte de cette ligne, et rejoignez le Small Business Program avant votre première vente si vous y avez droit.

Facturation annuelle, prix GoodBarber du 24 septembre 2026, frais de stores compris.

Ces lignes couvrent l'abonnement et les frais de stores. La production des contenus, votre logiciel de salle et le domaine viennent en plus.

Pour situer les ordres de grandeur, voici ce que coûtent sur un an les outils de la première section, pour le même travail ou un travail voisin, hors taxes et hors frais de paiement : un logiciel de salle avec son application à la marque à partir de 1 656 $ (une formule à 99 $ plus une application à 39 $), 2 400 $ de 51 à 100 membres chez un autre, 3 456 $ de 101 à 200 clients chez un troisième ; une plateforme de coaching à 718,80 $ pour 25 clients, application à la marque comprise ; une plateforme vidéo avec applications à 5 388 $, plus 0,99 $ par abonné. Ce ne sont pas des comparaisons terme à terme. Chaque outil fait un travail différent, et le logiciel de salle gère les places de cours et les paiements que GoodBarber lui laisse.

• Construisez l'application pendant l'essai gratuit. Trente jours, sans carte bancaire. Un projet sans abonnement est désactivé au 30e jour et supprimé au 45e.
• Payez à l'année : au plus dix mois du tarif mensuel.
• Commencez en Premium et passez en Pro le jour où vous ajoutez à la fois la Prise de rendez-vous et le Système d'abonnements. À partir de là, Pro coûte moins cher.
• Ne comptez aucun frais par membre ni par abonné. La facture de GoodBarber ne grandit pas avec votre audience ; seule la commission des stores le fait, sur les abonnements.
• Intégrez la commission dans votre prix avant de le publier sur les stores.
• Ouvrez les comptes développeur au nom de votre entreprise dès le départ, et réglez la question du domaine avant d'activer le Système d'abonnements.

Arrêtez ensuite le budget de la seule façon qui marche : démarrez l'essai gratuit de 30 jours, ajoutez les sections dont votre activité a besoin et comptez-les. Vous saurez quelle offre il vous faut avant de payer quoi que ce soit.

Combien coûte une application de fitness ?

Avec GoodBarber, 660 € par an pour des applications natives iOS et Android plus la web app, vérifié le 24 septembre 2026. Ajoutez 150 € par an pour des séances individuelles réservables ou 490 € pour vendre des programmes par abonnement, ou prenez Pro à 1 260 € par an avec les deux. Apple ajoute 99 € par an et Google Play 25 € une fois.

Combien coûte une application de coach sportif ?

810 € par an avec l'offre Premium de GoodBarber et la Prise de rendez-vous, 934 € la première année avec les comptes Apple et Google. Les plateformes de coaching qui suivent les entraînements de chaque client publient des formules avec application à la marque à partir de 59,90 $ par mois pour 25 clients.

Combien coûte l'application à la marque d'une salle de sport ?

Chez les logiciels de gestion de salle, de 39 à 100 $ par mois en plus de la formule du logiciel, relevé le 24 septembre 2026. Ce logiciel gère les places de cours et les paiements ; GoodBarber, non.

Combien coûte le développement d'une application de fitness sur mesure ?

Il se chiffre projet par projet. Quatre agences qui se classent sur cette question publient des estimations de 30 000 à 50 000 $ pour une première version et jusqu'à 600 000 $ pour une application complète, relevées le 24 septembre 2026, maintenance et mises à jour en plus.

Apple et Google prennent-ils une commission ?

Sur les abonnements à vos contenus vendus dans l'application, oui : 15 % dans la plupart des cas, et 30 % chez Apple pendant la première année d'un abonné, sauf si vous rejoignez son Small Business Program. Rien sur les cours et les séances, payés hors de l'application. GoodBarber ne prend rien.

Paie-t-on par membre ou par abonné ?

Pas chez GoodBarber : le prix ne dépend ni de votre nombre de membres ni de votre nombre d'abonnés. Certaines plateformes de coaching et de vidéo facturent par client ou par abonné.

Peut-on payer une seule fois ?

Oui. L'offre Pro de GoodBarber existe en paiement unique, 4 600 € pour dix ans. Sinon, la facturation annuelle coûte au plus dix mois du tarif mensuel.

Coach, salle ou créateur de programmes : ce que votre application peut contenir, ce que les stores vous laissent y vendre, et comment la créer sans coder.

Vous avez déjà des clients, et l'application est pour eux. Ce qu'elle fait dépend de votre métier.

Si vous êtes coach sportif, vos clients réservent des séances individuelles et suivent le programme que vous leur avez transmis. L'application garde le lien entre deux rendez-vous : la séance à réserver, le programme de la semaine, le conseil du jeudi.

Si vous gérez une salle ou un studio, vous avez un planning de cours collectifs, des membres à fidéliser et des annonces à faire passer : un cours annulé, les horaires d'été, un nouveau coach. L'application porte ces nouvelles et affiche votre planning.

Si vous créez des programmes, vous avez tourné un cycle de huit semaines ou des routines à faire chez soi, et vous voulez les vendre par abonnement. L'application est alors votre point de vente, dans les stores.

Si votre logiciel de salle ou de coaching vous fournit déjà une application à votre nom, regardez ce qu'elle couvre avant d'en ajouter une. Si elle gère les places, les cartes de séances et le paiement des cours, gardez-la pour cela. Votre propre application se justifie pour le reste : vos contenus, vos programmes vendus dans les stores, votre identité. Vos clients n'installeront pas deux applications pour la même salle.

Deux projets que ce guide ne couvre pas. Une application grand public de suivi d'entraînement, avec séries, charges, courbes de poids, montres connectées et plans générés pour chaque utilisateur, est un produit logiciel développé sur mesure. Une place de marché qui met en relation des coachs et des clients aussi. GoodBarber construit l'application d'un coach, d'une salle ou d'un créateur, autour de ses propres contenus.

Si vous enseignez le yoga, notre guide pour créer une application de yoga suit les mêmes règles avec des exemples de studio. Et si vous hésitez encore entre un site et une application, nous y avons consacré un article.

Tout ce que vos clients font sans vous, entre deux séances, peut passer par l'application. Voici les sections qui le portent, et leurs limites.

Vos programmes en vidéo

Une section Vidéos accepte vos propres fichiers ou un code d'intégration. Rangez-les comme vos clients cherchent : par niveau, par groupe musculaire, par durée. Vingt minutes de gainage à la pause déjeuner et une séance complète du samedi matin ne se cherchent pas de la même façon. Vous pouvez préparer un cycle entier et programmer la date d'apparition de chaque séance.

Deux limites. Les vidéos se regardent en ligne, elles ne se téléchargent pas. Et une section YouTube ne peut pas être réservée aux abonnés : un programme que vous vendez doit être hébergé dans votre propre section Vidéos. Pour les tailles et les formats de fichiers, le centre d'aide fait foi.

Des séances guidées à écouter

Une section Podcasts accueille l'audio : une sortie de fractionné guidée à la voix, une routine de mobilité, une séance de récupération, un exercice de respiration. Dans les applications natives, l'audio continue quand votre client ouvre une autre application, celle qui chronomètre sa course par exemple, une option que vous activez dans le Privacy Center.

Sans connexion, votre client télécharge l'épisode avant de partir, et la section Favoris lui montre ce qui est déjà téléchargé. L'audio vous coûte un micro et une demi-heure au calme, pas une équipe de tournage.

Conseils, nutrition et technique

Une section Articles porte l'écrit : quoi manger avant une séance matinale, le placement du dos au soulevé de terre, les erreurs qui reviennent au squat. Un article court chaque semaine donne une raison d'ouvrir l'application les jours sans séance, et c'est la matière que lira votre chatbot, si vous en ajoutez un.

Défis, événements et notifications

Une section Agenda accueille un événement par date, avec des boutons, dont un lien vers votre page d'inscription : le défi du mois, la journée portes ouvertes, la fermeture d'août. Deux limites : l'Agenda n'a pas de récurrence documentée, et un import iCal n'affiche ni les événements passés ni les récurrents.

Les notifications push partent à la main ou à une heure programmée, vers les applications et vers la web app. À partir de l'offre Premium, un push automatique part à chaque nouveau contenu : la séance du lundi est annoncée sans que vous y pensiez.

Pour un défi clé en main, notre article sur le défi de 30 jours de la rentrée donne le déroulé et le prompt complet.

Le bilan de départ, par formulaire

L'extension Formulaire, gratuite, recueille ce qu'il faut savoir avant la première séance : objectif, niveau, blessures passées, disponibilités. Chaque réponse vous arrive par e-mail, et vous la retrouvez dans le back office, avec un export CSV.

Une carte de fidélité ou une carte de membre sont possibles à partir de Premium, en extensions payantes même en Pro. Elles relèvent de l'espace clients décrit plus bas, pas de l'abonnement.

Et l'IA ? Ce qu'elle fait vraiment ici

L'AI Extension Builder, gratuit. Vous décrivez en quelques phrases la section dont vous avez besoin, et elle est générée dans votre application : le tableau d'un défi, un minuteur de fractionné, un calculateur. Il fonctionne aujourd'hui avec GPT-6 Luna, le modèle d'OpenAI.

Le Chatbot, payant. Il répond aux questions de vos clients à partir des contenus que vous avez publiés, dans la langue de la question : « que manger avant la séance de 7 h ? », « quel échauffement pour le programme débutant ? ». Si vous vendez un abonnement, un non-abonné n'obtient que des réponses tirées de vos contenus gratuits.

Le serveur MCP. Il vous laisse publier un conseil ou envoyer une notification depuis Claude ou ChatGPT, sans ouvrir le back office.

Ce que l'IA ne fait pas ici : générer un plan d'entraînement personnalisé pour chaque client, ou analyser ses performances. Ce travail reste le vôtre, et c'est celui pour lequel vos clients vous paient.

Si vous vendez surtout des cours en ligne, le guide pour créer une application de cours en ligne vous ira mieux.

Comment une salle gère-t-elle ses réservations de cours dans une application sans code ? La réponse honnête tient en deux parties.

Les séances individuelles se réservent dans l'application. L'extension Prise de rendez-vous calcule les créneaux à partir de vos horaires, avec la durée de chaque prestation et un délai minimum entre deux rendez-vous. Vous ouvrez un agenda par coach ou par type de séance, synchronisé dans les deux sens avec Google Agenda. Le formulaire de réservation reprend les champs que vous choisissez (texte, e-mail, téléphone, date, lien), et un e-mail de confirmation part à vous et à votre client à chaque réservation.

Une règle décide de tout : un créneau accepte un seul rendez-vous. C'est l'outil de la séance individuelle, de la séance d'essai, du bilan. La séance se paie à la salle ou par votre moyen habituel, pas dans l'application : l'extension n'encaisse rien, et l'achat intégré ne sert qu'à vendre l'accès aux contenus. Le guide de la prise de rendez-vous détaille la mise en place.

Les cours collectifs restent dans votre logiciel de salle. Les places par cours, la liste d'attente, les cartes de séances et le paiement y restent. Votre application affiche le planning, de deux façons. Soit une section URL qui ouvre la page de planning de votre logiciel ; elle demande une adresse en HTTPS et s'ouvre dans un navigateur intégré sur les applications natives. Soit un événement Agenda par cours, avec un bouton vers ce cours dans votre logiciel.

Une précaution : la page que vous affichez doit vendre des cours pris en salle. Si elle vend aussi des cours en ligne ou des vidéos, votre application contient un lien d'achat externe pour du contenu numérique, ce qu'Apple n'autorise pas en dehors du store américain. Gardez les deux catalogues séparés.

Le détail est sur les pages de l'application d'un coach sportif et de l'application d'une salle ou d'un studio.

Il existe une voie avancée : l'AI Extension Builder peut générer une section de réservation qui écrit dans votre propre base Supabase, et l'article qui la documente prend un studio de yoga en exemple. C'est du code généré, à tester, sans paiement et sans article d'aide derrière : un projet, pas une fonctionnalité.

Peut-on vendre des programmes d'entraînement par abonnement dans sa propre application ? Oui. Mais une application suit un seul modèle, et c'est la décision à prendre avant de construire.

Premier modèle : les programmes par abonnement. Vos clients souscrivent un abonnement mensuel ou annuel dans les applications iOS et Android, avec leur compte Apple ou Google. Une période d'essai gratuite est possible, et une fois abonnés, ils peuvent aussi se connecter sur la web app. Il vous faut la web app activée et un nom de domaine installé, au moins dix contenus réservés, et un seul niveau d'accès : tout le monde paie la même chose et voit la même chose. Aux non-abonnés, vous pouvez montrer un aperçu plutôt qu'une porte fermée. À anticiper : les contenus réservés ne s'ouvrent qu'une fois l'application, ou sa mise à jour, validée par les stores. La page pour vendre vos programmes d'entraînement par abonnement montre ce modèle en place.

Deuxième modèle : l'espace clients, gratuit, pour les clients qui vous paient déjà à la salle ou à la séance. L'Authentification vous donne des sections privées, et vous pouvez couper l'inscription publique pour que seuls vos clients entrent. Mettez-y le planning, les annonces, les informations pratiques, les avantages des membres. Une carte de fidélité est possible. Rien ne s'y vend.

La règle à retenir : installer le Système d'abonnements retire l'Authentification, les Groupes d'utilisateurs, la Communauté, le Chat, la Carte de fidélité, la Carte de membre et les Coupons. Les deux modèles ne se mélangent pas.

Le piège à éviter : offrir dans l'application des programmes que vos clients ont déjà payés à la salle. Apple n'autorise l'accès à un contenu acheté ailleurs que si ce même contenu est aussi vendu en achat intégré dans l'application (règle 3.1.3(b)). Si c'est votre projet, parlez-nous-en avant de le construire.

La version générale de ce choix est dans notre comparaison entre une application par abonnement et une communauté privée.

Dans GoodBarber, l'achat intégré sert à une seule chose : vendre l'accès à vos contenus. Tout ce qui a lieu à une heure donnée, en salle ou en direct, se paie ailleurs.

En pratique, la vidéothèque se vend dans l'application ; les cours et les séances se paient ailleurs. Ne construisez jamais un abonnement « salle plus vidéos » dans l'application.

Deux règles d'Apple expliquent ce partage, dans la section 3.1 Payments des App Review Guidelines. Un service consommé hors de l'application se paie hors achat intégré (3.1.3(e)). Et l'application ne doit pas contenir de lien vers l'achat d'un contenu numérique fait ailleurs, sauf sur le store américain (3.1.1). C'est la raison de la précaution sur la page de planning.

Sur la commission, la version exacte : Apple et Google prélèvent la leur sur les abonnements, 15 % dans la plupart des cas, et Apple prend 30 % pendant la première année d'un abonné, sauf programme petites entreprises. GoodBarber ne prend rien.

1. Choisissez un premier usage. Vos trois meilleurs programmes, pour vos clients actuels. Pas l'application entière : une première version qui sert tout de suite vaut mieux qu'une application complète qui sort dans six mois.
2. Choisissez votre modèle, abonnement ou espace clients, d'après la section précédente. Pour l'abonnement, activez d'abord la web app et installez un nom de domaine : ce sont deux prérequis.
3. Construisez l'arborescence. Accueil, Programmes en section Vidéos, Séances guidées en Podcasts, Conseils en Articles, Défis et événements en Agenda, Réserver une séance en Prise de rendez-vous, Planning des cours en section URL, et Infos pratiques.
4. Donnez-lui l'identité de votre salle ou de votre marque. Mises en page, couleurs, typographie. C'est ce que vos clients voient en premier, et ce qu'une application de réservation générique ne vous donne pas.
5. Chargez les contenus, classés par niveau, groupe musculaire et durée, avec des dates de publication. Pour l'abonnement, dix contenus réservés au moins.
6. Réglez les notifications. Un push automatique à chaque nouveau programme, un push programmé pour lancer le défi du mois.
7. Testez sur votre téléphone avec l'application My GoodBarber. Une réserve : le parcours d'abonnement ne se teste ni dans l'aperçu du back office ni dans My GoodBarber, seulement sur les versions de test générées.
8. Publiez. La web app d'abord, puis l'App Store et Google Play, avec des comptes développeur à votre nom ou par le service de publication de GoodBarber, qui configure aussi les abonnements sur les stores. Si votre compte Google Play est un compte personnel, prévoyez un test fermé avec 12 testeurs pendant 14 jours avant la première publication. Et les contenus des abonnés ne s'ouvrent qu'après la validation des stores.
9. Annoncez-la. Un QR code à l'accueil, un mot en fin de séance, un lien dans votre signature d'e-mail. Vos clients sont déjà là : ils n'attendent que l'adresse.

Web app, iOS et Android : que publier ?

La web app s'ouvre dans le navigateur, sans téléchargement, et s'installe sur l'écran d'accueil. Le push web fonctionne sur iPhone une fois l'application ajoutée à l'écran d'accueil. Les applications natives sont indispensables pour vendre un abonnement : c'est donc votre modèle qui décide, plus que votre budget. À savoir avant de choisir votre offre : l'offre Standard publie la web app seule, sans Prise de rendez-vous, Système d'abonnements, Authentification ni push automatique.

Une application native sur iOS et Android commence avec l'offre Premium, à 660 € par an (tarif public relevé le 24 septembre 2026, facturation annuelle). La Prise de rendez-vous et le Système d'abonnements s'y ajoutent en extensions, ou sont inclus dans l'offre Pro. Comptez aussi les comptes développeur Apple et Google, et la commission des stores sur vos abonnements.

Le budget détaillé par métier, avec les prix des autres solutions fait l'objet d'un article à part. Les tarifs complets sont sur la page des tarifs Content Apps.

Une section, trois vidéos, une notification. C'est une première version, et elle suffit à savoir si vos clients l'ouvrent. Les séances réservables viendront le mois suivant.

Si vous visez l'abonnement, préparez vos dix contenus avant de réserver quoi que ce soit, et comptez la validation des stores dans votre date de lancement.

Démarrer gratuitement : créez votre section Programmes et publiez vos trois premières séances pendant l'essai gratuit de 30 jours, sans carte bancaire.

Peut-on créer une application de fitness ou de sport sans savoir coder ?

Oui. Vous assemblez des sections depuis le back office, vidéos, audio, articles, agenda, prise de rendez-vous, puis vous publiez la web app et les applications iOS et Android. Une application grand public de suivi d'entraînement relève en revanche du développement sur mesure.

Peut-on vendre des programmes d'entraînement par abonnement dans sa propre application ?

Oui, par un abonnement mensuel ou annuel souscrit dans les applications iOS et Android, avec le Système d'abonnements. Prévoyez au moins dix contenus réservés et un seul niveau d'accès. Les stores prennent leur commission, GoodBarber aucune.

Comment une salle de sport gère-t-elle ses réservations de cours dans une application sans code ?

Elle affiche le planning de son logiciel de salle dans l'application, et garde dans ce logiciel les places, les cartes et le paiement : les cours ne se paient pas dans l'application. La Prise de rendez-vous, qui accepte un client par créneau, sert aux séances individuelles.

Mon logiciel de salle propose déjà une application : en faut-il une autre ?

Vérifiez d'abord ce qu'elle couvre. Une application à vous se justifie pour publier vos contenus à votre image ou pour vendre vos programmes dans les stores. Sinon, une seule application suffit.

L'application peut-elle suivre les performances de mes clients ?

Non : ni séries, ni charges, ni poids, ni montres connectées. Un formulaire de bilan de départ, oui. Le suivi d'entraînement relève d'un logiciel de coaching ou d'un développement sur mesure.

Puis-je diffuser une séance en direct dans l'application ?

Oui, en diffusion à sens unique et en accès libre : la section Live Video lit le flux de votre fournisseur de streaming, ce n'est pas de la visio. Le direct ne se vend pas dans l'application, puisque l'achat intégré ne vend que l'accès aux contenus.

Mes clients doivent-ils télécharger une application ?

Pas pour les contenus gratuits : la web app s'ouvre dans le navigateur et s'installe sur l'écran d'accueil. L'abonnement, lui, s'achète dans les applications iOS et Android.

Combien coûte une application de fitness ?

Une application iOS et Android commence avec l'offre Premium, à 660 € par an. La Prise de rendez-vous et le Système d'abonnements s'y ajoutent ou sont inclus dans l'offre Pro. Le budget détaillé par métier est dans notre article sur le coût d'une application de fitness.

Vos contenus sont soignés, vos couleurs choisies. Reste la barre de navigation, par laquelle vos utilisateurs passent d'une section à l'autre, et qui pèse lourd dans l'impression que laisse votre app. Chacun de ses onglets repose sur un élément conçu comme une pièce de construction : l'Item. Dans la nouvelle génération de TabBar, c'est lui qui donne à chaque navigation son caractère.

Dans un Item, chaque élément a son rôle. L'icône représente la section, le libellé affiche son nom, et l'indicateur, facultatif, signale l'onglet actif. Chacun s'affiche ou se masque séparément, ce qui donne trois compositions : icône et libellé, icône seule, libellé seul.

C'est ce qui sépare la Minimal TabBar, tout en icônes, de la Clean TabBar, tout en texte : le même élément, composé autrement.

Pour concevoir une TabBar, les designers de GoodBarber disposent de 17 propriétés : 8 pour l'Item, 6 pour son icône et 3 pour son libellé. La surface de l'Item accepte une couleur unie, un dégradé ou un effet de flou, une bordure, une ombre, des angles droits ou arrondis. Sa mise en page règle sa taille, son orientation, sa marge intérieure, qui délimite la zone tactile, et l'espacement qui fait respirer ses éléments.

Cette richesse ne vous demande pas de tout régler. Elle nous sert à composer des modèles de TabBar complets, alignés sur les codes actuels du design des apps : la Bold, la Minimal et la Clean TabBar sont les trois premiers. Quand ces codes évolueront, de nouveaux modèles naîtront du même élément, sans repartir de zéro. De quoi vous proposer des TabBar toujours dans l'air du temps.

Dans votre back-office, vous choisissez votre TabBar, puis vous l'accordez à votre identité : taille des onglets, arrondi des angles, couleurs, police des libellés, façon de signaler l'onglet actif. Vos propres icônes peuvent même côtoyer celles du système.

Un Item a deux états : par défaut et sélectionné. Pour distinguer l'onglet actif, il dispose de quatre moyens, seuls ou combinés : la couleur, le fond, la bordure et l'indicateur. Ce dernier n'apparaît que sur l'onglet sélectionné, sous trois formes : un point (Dot), un petit trait (Tiny) ou une ligne (Line).

Chaque forme a son propre mouvement. Le point et la ligne rétrécissent sur l'ancien onglet et grandissent sur le nouveau, le petit trait glisse de l'un à l'autre. Quand la sélection passe par le fond, comme sur la Bold TabBar, c'est le fond coloré qui se déplace. Des transitions courtes, qui rendent chaque changement lisible sans en faire trop.

L'Item adapte son orientation, sa marge intérieure et son espacement à chaque écran : mobile, tablette et desktop. En bas d'un téléphone, l'icône se place au-dessus du libellé. Sur desktop, la TabBar devient une barre latérale, et l'Item peut passer à l'horizontale pour s'y loger. Vous configurez votre navigation une seule fois : chaque écran reçoit la version qui lui convient.

• 3 éléments : une icône, un libellé, un indicateur (facultatif).
• 3 compositions : icône et libellé, icône seule, libellé seul.
• 17 propriétés de conception : 8 pour l'Item, 6 pour son icône, 3 pour son libellé.
• 2 états : par défaut et sélectionné.
• 4 façons de signaler l'onglet actif : la couleur, le fond, la bordure, l'indicateur.
• 3 indicateurs, chacun avec son animation : Dot, Tiny, Line.
• 3 écrans : mobile, tablette, desktop.

Après la TabBar, l'Item a sa page dans le Design System GoodBarber, et il arrive en famille. Avec l'Item Icon, l'Item Label et l'Item Indicator, il ouvre une nouvelle catégorie : les UI Elements, les briques de nos composants, chacune dédiée à un seul rôle.

Pour découvrir l'Item en détail, rendez-vous sur sa page du Design System. Et pour le voir à l'œuvre, choisissez votre TabBar dans la section Menu de votre back-office. Pas encore d'app GoodBarber ? Créez la vôtre.

OpenAI a publié GPT-6 Sol et GPT-6 Luna le 22 septembre 2026, après GPT-6 Astra, le modèle phare de la famille, sorti plus tôt dans le mois. Luna est le plus petit des trois. OpenAI le présente comme son modèle le plus efficace pour les tâches ciblées et à fort volume, et le vend moitié moins cher que GPT-5.6 Luna, qu'il remplace dans sa propre gamme.

Le lendemain matin, nous avons fait passer l'AI Extension Builder sur GPT-6 Luna, pour toutes les apps, aux quatre moments où un modèle est à l'œuvre : comprendre votre demande, écrire le code de la section, le réécrire quand vous demandez une modification, et répondre aux questions que vous posez sur ce qu'il a construit.

Rien à installer, rien à configurer. L'AI Extension Builder reste gratuit pour les apps Content et eCommerce, et les prompts que vous avez écrits le mois dernier fonctionnent comme avant.

Les sections que vous avez déjà publiées ne bougent pas. Une section publiée, c'est du code qui tourne dans votre app, et aucun modèle n'y touche après coup. GPT-6 Luna entre en jeu la prochaine fois que vous générez une nouvelle section ou que vous en retouchez une.

Ce qu'OpenAI dit de cette génération : moins d'erreurs de code que la précédente, et des réponses rapides à fort volume. Ce sont les chiffres d'OpenAI, mesurés sur les tests d'OpenAI. Nous jugerons sur vos sections, pas sur un benchmark : le temps que prend une génération, et ce que vous demandez ensuite au builder de corriger.

Le builder est une conversation. Vous décrivez une section, vous attendez quelques secondes, vous regardez l'aperçu, vous demandez un ajustement. Dans cette boucle, le temps jusqu'au premier résultat compte, et la plupart des sections, un minuteur, un suivi d'habitudes, un quiz, un compte à rebours, n'ont pas besoin d'un modèle conçu pour des tâches longues et complexes. Luna est le modèle qu'OpenAI positionne sur le travail ciblé, en volume. Une section avec un brief clair, c'est exactement ce genre de tâche.

Il existe des modèles plus gros dans la même famille, et une étape du builder peut être aiguillée vers l'un d'eux si les générations réelles en montrent le besoin. Pour l'instant, ce que nous voulons tester, c'est le rapide.

Ouvrez votre back office, ajoutez une section « Créer avec l'IA » et décrivez ce que vous voulez. Si vous préférez partir d'un exemple qui marche, la bibliothèque de prompts intégrée au builder vous donne des briefs complets à réutiliser, et notre série « Volez cette idée » livre des prompts entiers, comme le défi 30 jours de la rentrée pour votre salle de sport. Vous débutez avec le builder ? Commencez par le guide pour créer des sections avec l'IA ou par la page de l'AI Extension Builder.

Puis dites-nous ce que vous voyez. Une section mieux réussie que la semaine dernière, ou un prompt qui marchait et qui trébuche maintenant : envoyez-le à notre équipe support depuis votre back office, avec le prompt utilisé. C'est sur ces retours que le prochain réglage sera construit.

Under the hood — l'ingénierie de GoodBarber, expliquée à ceux qui font tourner des apps.

Précisons le cadre : tout ce qui suit s'est passé sur notre propre portail commercial, et c'est notre équipe qui l'a mis en place. Ce que nous avons appris sur les machines qui lisent les pages web vaut pour tous les contenus, les nôtres comme les vôtres.

À retenir, mesuré sur notre portail du 4 au 18 septembre 2026 :

• Les robots d'entraînement et d'indexation des entreprises d'IA (Amazon, Meta, OpenAI) ont lu les pages Markdown par le lien .md : environ 80 000 requêtes en deux semaines.
• Les agents de code, Claude Code en tête, demandent le Markdown par l'en-tête Accept: text/markdown et le reçoivent : environ 22 000 requêtes négociées, presque toutes de moteurs de réponse pour agents et de Claude Code.
• ChatGPT, Claude sur le web et Perplexity, quand ils répondent à une personne, ont chargé le HTML plus de 13 000 fois et le Markdown une seule fois.
• Le robot de Google n'a demandé aucune page Markdown.
• Le Markdown pèse environ 80 % de moins que la page HTML dont il vient.

GoodBarber est une plateforme de création d'applications mobiles sans code ; goodbarber.com est son site commercial, en onze langues, avec des pages marketing, un blog et un centre d'aide. Quand quelqu'un demande à un assistant IA si GoodBarber peut construire l'app qu'il a en tête, l'assistant ne lit pas notre brochure. Il va chercher nos pages, parfois des milliers par jour, et en extrait une réponse à partir du HTML. Le HTML est lourd : menus, scripts, mise en page, bandeau de cookies. Le Markdown, c'est le texte de la page et rien d'autre. Le servir quand une machine le demande, c'est lui donner le vrai contenu, plus vite, pour une fraction du poids, avec moins de risques qu'elle se trompe sur nous.

En août 2026, Pierre-Laurent avait compté qui lit notre llms.txt. Un llms.txt est un fichier texte placé à la racine d'un site, qui liste ses pages importantes à l'intention des systèmes d'IA : en quatre mois, aucun assistant n'était venu le chercher de lui-même. Les mêmes logs montraient autre chose : sur la même période, les assistants et leurs robots avaient chargé nos pages ordinaires 1,6 million de fois. Personne ne lit la carte ; tout le monde arpente les rues. La question n'était donc pas « comment leur faire lire l'index », mais « que leur donne-t-on quand ils arrivent ».

Deux portes, aucun contenu dupliqué. La première est la négociation de contenu, le mécanisme standard du web par lequel un client indique dans sa requête le format qu'il préfère recevoir : un client qui envoie l'en-tête Accept: text/markdown reçoit la version Markdown de n'importe quelle page publique, à la même adresse. La seconde est une adresse jumelle : un client qui ajoute .md à l'adresse d'une page, /pricing.md, /blog/<article>.md, reçoit la même chose. Cette page a elle-même son jumeau : ajoutez .md à son adresse. Chaque page HTML annonce son jumeau par un lien standard, comme elle annonce ses traductions. Le Markdown est généré à partir du HTML exact que la page sert déjà, il ne peut donc jamais dire quelque chose que la page ne dit pas, et il demande aux moteurs de recherche de ne pas l'indexer : la page HTML reste la seule présente dans Google.

Avant de l'activer, le test consistait à vérifier qu'un visiteur humain ne pouvait rien remarquer : réponses comparées octet par octet avec le jumeau activé et désactivé, sur tous les types de navigateurs auxquels nous avons pensé, identiques, pour un coût de quelques microsecondes par requête.

Nous n'avons rien inventé. Cloudflare convertit les pages en Markdown à la bordure de son réseau depuis février 2026, Zapier et Vercel servent les deux portes sur leurs propres sites. Si vous gérez un site web et voulez la même chose, c'est une journée de travail côté serveur, une bibliothèque de conversion, un cache, et un moyen de vérifier que rien n'a changé pour les humains. Ce que presque personne ne fait, c'est l'étape suivante : compter.

Du 4 au 18 septembre 2026, deux logs dédiés ont enregistré chaque requête d'une page Markdown, sur nos onze sites en langue, notre propre trafic retiré. Chaque « qui » ci-dessous est un nom déclaré, vérifié contre les adresses IP que son opérateur publie, comme l'avait fait Pierre-Laurent ; quand un opérateur ne publie rien, le nom reste déclaré.

Oui, et ce sont eux qui prennent le lien .md : environ 80 000 requêtes en deux semaines. La moitié vient des robots des entreprises d'IA, ceux qui constituent les jeux d'entraînement et les index de recherche : ceux d'Amazon, de Meta, d'OpenAI, tous depuis leurs adresses IP publiées. Les robots d'OpenAI trouvent la version .md parce que notre page HTML pointe vers elle : dans 99 cas sur 100, le même robot avait chargé la page HTML dans les dix minutes précédentes. Le robot de Bing est venu aussi, mais il a passé l'essentiel de sa visite sur nos pages de recherche interne, qui répondent à n'importe quelle requête tapée par n'importe qui. Le robot de Google, lui, n'a demandé aucune page Markdown.

Oui, presque systématiquement. L'en-tête a reçu environ 22 000 requêtes, quatre fois moins que le lien, et d'un autre public. Presque tout vient de deux moteurs de recherche conçus pour les agents IA, ShapBot et ExaSearchBot, et d'un seul agent de code : Claude Code, l'outil que les développeurs, et d'autres, font tourner sur leur propre machine. Claude Code a envoyé l'en-tête sur pratiquement chacune de ses quelque 1 400 requêtes de page et a reçu du Markdown 98 fois sur 100, aux trois quarts sur notre centre d'aide. C'est cohérent avec ce que Checkly avait mesuré en février 2026 : Claude Code, Cursor et OpenCode envoient l'en-tête ; Codex, Gemini CLI, Copilot et Windsurf ne l'envoient pas.

Non, aucune des deux portes. C'est le chiffre sur lequel nous aurions parié faux. En deux semaines, les requêtes émises parce que quelqu'un posait une question à ChatGPT ont chargé plus de 10 000 de nos pages HTML et une seule page Markdown, trois minutes après la mise en ligne, très probablement l'un de nous en train de tester. Claude sur le web : environ 2 700 pages HTML, zéro Markdown. Perplexity : environ 900, zéro. Ils chargent la page HTML et font leur propre nettoyage. Rien de ce que nous servons n'y change quoi que ce soit.

Qui lit quoi, et pour quel usage :

Deux faits plus petits. Le Markdown pèse environ 80 % de moins que la page HTML dont il vient, près de 85 % sur le centre d'aide. Et avant que nous servions le moindre Markdown, nos logs contenaient déjà environ 900 requêtes vers des adresses .md qui n'existaient pas, README.md, agents.md, CLAUDE.md, tentées par des outils qui s'attendent à ce qu'un site web soit un dépôt de code ; l'un d'eux avait deviné les adresses exactes que nous avons publiées un mois plus tard.

Trois choses, tirées de nos logs plutôt que des slides de qui que ce soit.

Votre HTML est ce que lisent les assistants. ChatGPT, Claude et Perplexity chargent la page qu'une personne voit. Une page propre, à jour et bien structurée, c'est ce qui leur parvient ; un jumeau Markdown, non, du moins pas aujourd'hui. Pierre-Laurent a écrit comment corriger les contenus que les assistants citent quand ils se trompent sur votre activité ; ce travail porte sur le HTML, et c'est celui qui paie.

Les robots suivent les liens que vous publiez. Les robots d'OpenAI ont pris le lien .md parce que la page le leur proposait. Si vous indiquez une direction aux robots, ils la prennent. C'est aussi pour ça qu'un llms.txt vaut encore la peine : depuis que nos pages pointent vers lui, les robots d'OpenAI y arrivent depuis notre propre site, là où ils passaient auparavant par des annuaires tiers.

Les agents de code demandent le Markdown par son nom. Si les développeurs font partie de votre public, les agents qu'ils utilisent envoient Accept: text/markdown et se servent de ce qu'ils reçoivent. Notre centre d'aide est l'endroit où ils sont allés.

Si vous faites tourner une app GoodBarber, sa version web est déjà la page qu'un assistant peut charger et citer, et GoodBarber MCP permet à un assistant de vous aider à garder ce contenu à jour. Les pages que les assistants lisent réellement sont celles que vous publiez déjà.

Est-ce que ça concerne les apps créées avec GoodBarber ?

Pas directement : cet article parle de notre propre portail. Ce qui s'applique déjà à votre app, c'est la leçon : les assistants lisent la page HTML qu'une personne voit, donc garder ce contenu à jour est ce qui compte.

Le site de GoodBarber est-il lisible par les agents IA ?

Oui. Depuis septembre 2026, chaque page publique de goodbarber.com existe en Markdown, par l'en-tête Accept: text/markdown ou en ajoutant .md à son adresse, et chaque page HTML annonce cette version par un lien standard. Le site publie aussi un llms.txt et un llms-full.txt, régénérés chaque nuit à partir des pages, et chaque page y renvoie.

Un agent IA peut-il travailler avec une app GoodBarber ?

Oui, par GoodBarber MCP : un assistant comme Claude ou ChatGPT peut se connecter à votre app pour lire et modifier ses contenus, publier un article ou programmer une notification, avec votre validation. C'est un autre sujet que celui de cet article, et il est décrit sur la page GoodBarber MCP.

Les assistants IA lisent-ils les versions Markdown des pages web ?

Pas les assistants grand public, dans nos logs de septembre 2026. ChatGPT, Claude sur le web et Perplexity ont chargé nos pages HTML plus de 13 000 fois en deux semaines, et nos pages Markdown une fois. Les robots d'indexation et les agents de code, eux, ont utilisé le Markdown.

Servir du Markdown aide-t-il pour Google ?

Non, et ce n'est pas le but. Nos pages Markdown demandent aux moteurs de recherche de ne pas les indexer et renvoient vers la page HTML. Le robot de Google n'en a jamais demandé une.

Faut-il ajouter un llms.txt à mon site ?

Ça coûte peu, et les robots le lisent bien quand vos pages pointent vers lui. Dans nos logs, il est lu par des robots, des annuaires et des outils SEO, pas par les assistants qui répondent aux questions des gens.

Une app peut fonctionner partiellement ou entièrement sans connexion si les données et les fonctions nécessaires à une tâche sont disponibles sur l'appareil. Un guide peut afficher une page déjà consultée. Une app de podcasts peut lire un épisode téléchargé à l'avance. Un outil de terrain conçu pour fonctionner d'abord hors ligne peut même enregistrer une action localement et la synchroniser plus tard.

Ces situations correspondent à trois promesses techniques différentes :

1. Contenu mis en cache : un élément précédemment chargé depuis le réseau reste temporairement disponible sur l'appareil.
2. Contenu enregistré volontairement : l'utilisateur choisit un article, un fichier audio ou un autre élément compatible à conserver pour plus tard.
3. Fonctionnement « offline-first » : l'app exécute tout ou partie de ses fonctions essentielles à partir de données locales. Si elle accepte aussi des modifications hors ligne, celles-ci doivent être synchronisées et les éventuels conflits résolus au retour de la connexion.

Notre extension Hors-ligne prend en charge les deux premières approches pour les contenus compatibles : elle permet de retrouver des contenus déjà chargés et d'enregistrer volontairement certains éléments dans les Favoris.

Selon la définition d'Android, une app « offline-first » doit permettre d'utiliser sans Internet toutes ses fonctions essentielles, ou au moins une partie critique de celles-ci. Cette architecture nécessite des sources de données locales. Si l'app accepte aussi des modifications hors ligne, elle doit prévoir leur synchronisation et la gestion des conflits au retour de la connexion. C'est bien plus que la mise en cache d'une page.

Cette distinction compte au moment de choisir un créateur d'apps ou de décrire votre propre app. « Disponible hors ligne » doit désigner une tâche précise, et non laisser penser que chaque écran et chaque action fonctionne comme avec une connexion.

Imaginez un visiteur qui ouvre un guide local avant d'entrer dans une zone mal couverte. Il peut avoir besoin de relire la description d'un sentier, de vérifier les horaires chargés lors de sa dernière connexion ou d'écouter un audioguide enregistré. Il ne s'attend probablement pas à pouvoir regarder un direct, se connecter à son compte ou envoyer un formulaire sans réseau.

Définissez en une phrase la tâche essentielle à préserver :

Quand la connexion disparaît, l'utilisateur doit encore pouvoir ______.

La réponse détermine le niveau d'accès hors ligne nécessaire. Pour « relire un guide préparé à l'avance », le cache ou l'enregistrement volontaire peuvent suffire. Pour « saisir un compte rendu d'inspection et l'envoyer plus tard », il faut une saisie locale et une synchronisation pensées pour le hors ligne.

Dans une app GoodBarber, les contenus déjà chargés peuvent rester accessibles quand le réseau disparaît. Les Favoris offrent aux lecteurs un moyen volontaire de conserver des éléments compatibles pour les retrouver plus tard. Ensemble, ces possibilités aident un guide, un magazine ou une app de podcasts à rester utile lorsque la couverture est incertaine.

Par exemple, un voyageur peut rouvrir un article consulté avant d'entrer dans une zone mal couverte ; le lecteur d'un magazine peut retrouver un article ou une photo enregistré dans ses Favoris ; et un auditeur peut écouter un épisode de podcast qu'il y a conservé pour le trajet. Dans tous les cas, le contenu doit avoir été préparé pendant que l'app était connectée.

Au niveau des sections, quelques exemples permettent de comprendre la différence : les sections Articles, Photos et À propos peuvent afficher des contenus chargés au préalable. Un épisode de podcast n'est accessible hors ligne depuis les Favoris que s'il y a d'abord été enregistré. À l'inverse, les sections Formulaire, Vidéo et Live Audio nécessitent une connexion.

Des notifications push peuvent encore être envoyées pendant qu'un utilisateur est hors ligne, mais il ne pourra les consulter qu'après s'être reconnecté. Le premier chargement et les nouvelles mises à jour demandent également une connexion. Pour le comportement précis de chaque section et type de contenu, consultez notre aide sur le mode hors ligne et notre aide sur les Favoris.

Un accès partiel hors ligne est précieux lorsque les utilisateurs peuvent se préparer avant d'entrer dans une zone peu couverte.

Rendez visible l'étape de préparation tant que les utilisateurs ont encore une connexion. Pour les informations sensibles au temps, précisez que la version hors ligne affiche le dernier contenu chargé, et non une source actualisée en direct.

Une expérience hors ligne échoue quand l'interface donne l'impression qu'un contenu indisponible est cassé, ou laisse commencer une action impossible à terminer. Certains états hors ligne sont gérés par le framework de l'app plutôt que par son éditeur : testez donc le comportement de votre app finalisée et ajoutez des explications là où votre configuration le permet.

Rendez la préparation facile à trouver

Placez la section Favoris à un endroit visible et expliquez pourquoi il peut être utile d'enregistrer des contenus avant de perdre la connexion. Vous pouvez renommer la section selon un résultat compréhensible, comme « À garder pour plus tard ».

Définissez les attentes avant la perte du réseau

Expliquez qu'un premier lancement et le chargement initial nécessitent une connexion. Pour les formulaires et les autres actions disponibles seulement en ligne, prévenez l'utilisateur avant qu'il ne commence et indiquez clairement comment se reconnecter. Ne promettez pas que les données saisies seront conservées si vous n'avez pas testé et documenté ce comportement.

Distinguez l'indisponible du dysfonctionnement

Une action désactivée accompagnée d'une brève explication est plus claire qu'un indicateur de chargement qui ne s'arrête jamais. Dites à l'utilisateur s'il doit se reconnecter, charger d'abord l'élément ou choisir un format compatible.

Intégrez la fraîcheur des informations à l'expérience

Un contenu mis en cache peut devenir obsolète. Quand la date compte, affichez celle de la dernière mise à jour connue ou conseillez un rafraîchissement avant le départ. Ne présentez jamais un ancien horaire comme une information en direct.

Les apps GoodBarber peuvent être publiées sur iOS, Android et le web. Testez la tâche hors ligne retenue dans chaque version utilisée par votre audience, y compris après avoir fermé puis rouvert l'app. Un test réussi sur un appareil ne garantit pas le même résultat chez tous les utilisateurs.

• Définissez en une phrase la tâche essentielle à préserver hors ligne.
• Distinguez le contenu mis en cache du contenu enregistré volontairement.
• Expliquez le premier lancement connecté et la préparation nécessaire.
• Ne présentez pas les actions en direct, authentifiées ou transactionnelles comme utilisables hors ligne.
• Prévenez les utilisateurs avant une action qui nécessite une connexion.
• Testez le parcours hors ligne principal après un redémarrage complet sur chaque plateforme publiée.
• Nommez précisément la fonction disponible hors ligne, sans promesse générale.

Une bonne expérience hors ligne ne cherche pas à reproduire toute l'app connectée. Elle protège la tâche qui compte lorsque le réseau manque.

Découvrez notre extension Hors-ligne pour voir comment aider vos lecteurs à continuer d'utiliser les contenus préparés quand la connexion disparaît.

Quelle différence entre une app accessible hors ligne et une app « offline-first » ?

Une app peut offrir un accès limité hors ligne grâce au cache ou à l'enregistrement de certains contenus. Une app « offline-first » est conçue pour que toutes ses fonctions essentielles, ou une partie critique de celles-ci, utilisent des données locales sans réseau. Si elle accepte des modifications hors ligne, celles-ci doivent être synchronisées au retour de la connexion.

Une app GoodBarber peut-elle fonctionner sans Internet ?

Oui. Une app GoodBarber peut conserver l'accès à des contenus déjà chargés et aider les lecteurs à retrouver les éléments compatibles enregistrés dans les Favoris. Le premier chargement et les nouvelles mises à jour exigent une connexion ; notre aide sur le mode hors ligne donne les détails.

Une PWA peut-elle fonctionner hors ligne ?

Oui. Une PWA peut rendre certains contenus accessibles sans connexion. Testez la tâche précise dans votre PWA publiée avant de promettre une expérience hors ligne.

L'accès hors ligne signifie-t-il que toutes les fonctions marchent sans connexion ?

Non. L'accès hors ligne désigne les tâches encore possibles lorsque le réseau disparaît ; il ne signifie pas que toute l'app est « offline-first ». Expliquez ce que les utilisateurs peuvent préparer à l'avance et consultez notre aide sur le mode hors ligne pour connaître précisément la couverture du produit.

Quatre voies mènent à une application de musée à des prix sans commune mesure : de 36 € par mois chez un builder no-code à 91 400 € HT en marché public en 2026.

Derrière ce tableau se cachent quatre logiques de prix.

Les builders no-code facturent un abonnement forfaitaire. Vous assemblez l'application à partir de sections prêtes à l'emploi, et l'hébergement, la base de données, les mises à jour et la republication dans les stores tiennent dans cette seule ligne. Le cas général est traité dans notre article sur combien coûte la création d'une application sans codage.

Les plateformes mutualisées publient des paliers. L'une d'elles affiche la gratuité pour un seul parcours, puis 1 800, 3 500 et 9 500 £ par an, et un palier sur mesure communiqué sur demande, l'écriture des textes, la production et la traduction restant chiffrées à part à chaque palier. L'audience déjà présente sur la plateforme est un vrai avantage, et votre guide y est publié sous le nom de la plateforme.

Les prestataires spécialisés vendent un marché, pas une grille. Une ville française a attribué 91 400 € HT en juillet 2026 pour la fourniture, la mise en œuvre, l'hébergement et la maintenance de la solution de médiation numérique de son musée-château, dont 47 200 € seulement en tranche ferme : le reste se répartit entre une tranche optionnelle portant sur un second site et une part à bons de commande plafonnée. À l'autre bout du marché, un musée national parisien a plafonné à 800 000 € HT sur six ans la seule part à bons de commande de la refonte de son audioguide (avis d'appel à la concurrence envoyé le 19 mars 2024) : un plafond sur une ligne de marché, pas un prix payé, et pas l'échelle que budgète un petit musée. Tous les montants de marchés publics cités ici sont français et relevés dans les avis ; ceux du musée-château (91 400 €) et du musée national parisien (800 000 €) sont donnés hors taxes par les avis eux-mêmes, les autres ne précisent pas le traitement de la TVA.

Le développement sur mesure, c'est un autre métier. Une agence vend un projet, pas un abonnement, et chaque évolution ultérieure se refacture. C'est la bonne voie pour ce qu'aucun builder ne couvre : la billetterie vendue dans l'application, l'audio déclenché devant une œuvre, le guidage à l'intérieur du bâtiment. GoodBarber ne fait rien de tout cela.

Les prix ci-dessous sortent directement de l'API tarifaire publique de GoodBarber, en euros. Le détail complet est sur la page tarifs des Content Apps.

La ligne la moins chère d'une page tarifs n'est pas celle d'un musée, et voici l'arithmétique que personne ne publie. Le socle minimal d'un guide de musée tient en six sections : Articles, Podcasts pour l'audioguide, Carte, Agenda, Lecteur de QR Code et Favoris. Chaque section compte dans les extensions incluses de votre offre, et Standard en autorise cinq : la sixième coûte donc un emplacement supplémentaire à 100 € par an, soit 460 € par an pour une web app de musée, et non 360 € (dès que vous ajoutez une section Menu ou Contributions, comme le fait notre guide pour créer une application de musée, vous passez à Premium). Les 200 € qui séparent ce total de Premium achètent le reste de la liste, les apps natives sur l'App Store et Google Play, vingt emplacements gratuits au lieu de cinq, trois accès collaborateurs au lieu d'un, et un quota de 30 000 notifications push par mois. C'est pour cela qu'une application de musée destinée aux stores commence à Premium.

La facturation annuelle revient à peu près à dix mensualités. Une licence Pro à paiement unique existe aussi (4 600 €, dix ans), bonne à connaître pour un établissement qui budgète à l'échelle de la décennie.

Quel que soit l'outil retenu, certaines lignes viennent d'ailleurs.

• Apple Developer Program : 99 € par an, pour publier des applications iOS natives au nom du musée. Apple en exonère une association, un établissement d'enseignement accrédité ou une entité publique qui ne vend rien de numérique dans ses applications, et revérifie chaque année : vendre l'accès dans l'application et garder l'exonération s'excluent.
• Google Play Console : 25 €, une seule fois. Un compte Google personnel créé après le 13 novembre 2023 doit en plus mener un test fermé avec au moins 12 testeurs inscrits pendant 14 jours consécutifs avant de passer en production ; un compte d'organisation au nom du musée n'y est pas soumis. Une web app ne paie ni l'un ni l'autre.
• Les extensions payantes, si vous allez en chercher une. Les six sections ci-dessus sont gratuites sur toutes les offres, mais des ajouts comme l'identification des utilisateurs sont payants sur Premium (120 € par an) et inclus sur Pro, quand d'autres, comme la carte de fidélité, restent payants sur les deux (40 € par an).
• Un nom de domaine. GoodBarber n'en vend pas, et un sous-domaine d'un domaine que vous possédez déjà ne coûte rien de plus. C'est lui qui permet à un QR code imprimé d'ouvrir l'application native : arrêtez-le avant que quoi que ce soit parte à l'impression.
• Une nouvelle version dans les stores le jour où vous activez l'écoute écran verrouillé : cette option vit dans le binaire. Par le service de publication GoodBarber, cela vaut un crédit par store, 50 € les cinq.

L'hébergement, la base de données, le CMS, les notifications push dans votre quota et les statistiques n'ajoutent aucune facture séparée. Le monde physique, lui, en ajoute : l'impression et la pose des QR codes, une clé d'API cartographique pour la web app, les droits sur vos images et sur vos voix, et le temps de vos équipes, réduites sur Standard à un seul accès collaborateur.

Un point que ce tableau ne tranche pas : si la couverture réseau de vos salles est catastrophique, demandez au support GoodBarber, qui peut rendre vos contenus disponibles hors connexion quelle que soit la configuration. La technologie déplace la ligne matériel, pas la ligne contenu, et c'est la ligne contenu qui pèse. Un musée municipal français a passé un accord-cadre en deux lots pour ses audioguides : 22 000 € pour la fourniture des boîtiers et l'intégration des parcours, 18 000 € pour la création des parcours sonores, c'est-à-dire l'écriture et l'enregistrement (avis d'attribution publié le 15 février 2024). Le poste des voix a presque égalé celui des boîtiers et de leur installation.

Certains musées achètent désormais les deux d'un coup. Une ville française a attribué 369 913 € en 2026, contre une estimation publiée à 250 000 €, pour un audioguide associant une petite flotte de boîtiers et une web app sur le téléphone des visiteurs (avis d'attribution publié le 2 juin 2026).

Ce que le natif apporte à la visite est détaillé dans notre guide ; le choix plus large est traité dans site web, application ou les deux.

Une application a une seule langue d'interface, et elle ne suit pas celle du téléphone du visiteur. Notre guide décrit les deux structures possibles, une section Menu par langue ou une application par langue ; voici ce que chacune change à la facture.

Une section Menu par langue. Un seul abonnement couvre les deux langues. La section Menu prend un emplacement d'extension de plus, 100 € par an sur Standard et gratuit dans les vingt de Premium, et chaque piste est réenregistrée.

Une application par langue. Un abonnement pour chacune : deux projets Premium reviennent à 1 320 € par an. Les pages d'aide de GoodBarber documentent une remise de 50 % sur chaque projet de langue supplémentaire, calculée sur votre abonnement initial et à obtenir auprès du support avant de payer : faites-en la demande, mais les budgets ci-dessous n'en tiennent pas compte. Dupliquer le premier projet dans le second coûte 40 € une fois.

Hors abonnement, une langue de plus est une production de plus. Un musée national parisien a attribué un lot distinct à 15 936 €, sous un plafond de 30 000 €, pour les contenus de son audioguide en langue des signes française (avis d'attribution publié le 22 août 2025).

Ces trois lignes couvrent l'abonnement et les frais de stores, rien d'autre. La remise multilingue et les 40 € de duplication déplaceraient toutes deux la deuxième ligne ; l'écriture, l'enregistrement, la traduction, l'impression et le temps de vos équipes viennent par-dessus, et les marchés cités plus haut disent leur poids. Les prix sont en euros ; la page tarifs, elle, les affiche dans votre devise.

• Construisez un vrai parcours pendant l'essai. Trente jours, gratuits, sans carte bancaire. Un projet sans abonnement est désactivé au trentième jour et supprimé au quarante-cinquième : demandez une prolongation au support si votre comité ne se réunit qu'une fois par mois.
• Arrêtez le nom de domaine et l'option d'écoute écran verrouillé avant la première soumission, car en changer ensuite veut dire une nouvelle version dans les stores.
• N'imprimez les QR codes qu'une fois. Construits sur le domaine que vous avez arrêté, les mêmes codes fonctionnent encore le jour où les applications natives arrivent dans les stores.
• Une section Menu par langue avant une application par langue, et payez à l'année plutôt qu'au mois.
• Ouvrez les comptes développeur au nom du musée dès le premier jour, et demandez l'exonération à Apple si vous y avez droit, en sachant qu'elle interdit de vendre quoi que ce soit de numérique dans l'application.

Puis tranchez la question du budget de la seule façon qui marche : lancez l'essai gratuit de 30 jours, ajoutez les sections dont votre musée a réellement besoin, et comptez-les. Ce décompte vous dit sur quelle offre vous êtes, avant d'avoir payé quoi que ce soit.

Combien coûte une application de musée ?

Avec GoodBarber, 70 € par mois ou 660 € par an pour des applications natives iOS et Android plus la web app, vérifié le 18 septembre 2026. Une web app seule revient à 460 € par an sur Standard, une fois ajouté l'emplacement d'extension dont un guide de musée à six sections a besoin. Apple ajoute 99 € par an, sauf si votre musée a droit à l'exonération, et Google Play 25 € une seule fois.

Existe-t-il une application de musée gratuite ?

L'essai GoodBarber est gratuit pendant 30 jours et ne demande pas de carte bancaire, mais aucune offre gratuite ne lui succède. Les plateformes de guides mutualisées affichent bien un palier gratuit, en général un seul parcours, sous le nom de la plateforme.

Combien coûtent les applications natives par rapport à la web app ?

Les deux viennent avec l'offre Premium de GoodBarber à 70 € par mois : la différence n'est donc pas l'abonnement. Ce sont les 99 € d'Apple, les 25 € de Google et la validation par les stores. Ce que le natif apporte à la visite est détaillé dans notre guide pour créer une application de musée.

Faut-il payer une application par langue ?

Non si vous créez une section Menu par langue dans une même application : un seul abonnement couvre l'ensemble, et cette section prend un emplacement d'extension de plus. Oui si vous publiez une application par langue, chacune avec son abonnement, même si les pages d'aide de GoodBarber documentent une remise de 50 % sur chaque projet de langue supplémentaire, à demander au support au préalable.

Un audioguide sur smartphone coûte-t-il moins cher que des boîtiers prêtés ?

Il supprime les boîtiers, la charge et la maintenance, pas l'écriture, les voix ni les langues : dans l'accord-cadre en deux lots d'un musée français, la création des parcours sonores a coûté 18 000 € contre 22 000 € pour la fourniture des boîtiers et leur mise en place.

Qui paie les comptes développeur Apple et Google ?

Votre musée, directement : 99 € par an à Apple, exonérés pour les associations, les établissements d'enseignement et les entités publiques éligibles qui ne vendent rien de numérique dans leurs applications, et 25 € une seule fois à Google. Une web app n'a besoin ni de l'un ni de l'autre.

Peut-on payer une seule fois ?

Oui. L'offre Pro de GoodBarber existe en paiement unique à 4 600 € pour dix ans. Sinon, la facturation annuelle revient à peu près à dix mensualités.

Jour 1 095 — ce qui arrive à une app dans les trois ans qui suivent son lancement.

Vous la connaissez, cette petite gêne. La keynote fait les titres, votre téléphone se met à jour tout seul pendant la nuit, et au réveil, une pensée : et mon app, dans tout ça ? Est-ce qu'elle marche encore ? Est-ce que j'aurais dû préparer quelque chose ?

L'instinct n'est pas mauvais. Quelque chose change bel et bien : votre app repose sur des centaines de fonctions fournies par le système — afficher une carte, envoyer une notification, demander une permission — et c'est ce socle, précisément, qui vient de bouger. La question n'est donc pas « est-ce qu'il se passe quelque chose ? » — il se passe quelque chose. La question est : qui doit s'en occuper ?

Deux mouvements, presque toujours.

Des fonctions s'arrêtent. Pas avec fracas : une fonction que votre app utilisait cesse simplement d'être disponible, et ce qui s'appuyait dessus ne répond plus. Rien ne « plante » à l'écran ; quelque chose ne se produit plus, voilà tout. C'est la panne la plus sournoise qui soit, parce qu'elle ne laisse aucune trace visible.

D'autres deviennent obligatoires. Le système introduit une nouvelle façon de faire — plus sûre, plus respectueuse de la vie privée — et la rend progressivement incontournable. Pas du jour au lendemain : une échéance est posée, parfois à plusieurs mois, et elle finit toujours par tomber.

Le point qui rassure et inquiète à la fois : ces mouvements sont, pour la plupart, annoncés à l'avance. Apple et Google publient ce qui va s'arrêter et ce qui va devenir obligatoire bien avant que ce soit effectif. Tout est donc lisible — à condition que quelqu'un lise. Et le rythme ne s'arrête jamais : deux systèmes, une version majeure chacun par an, des ajustements entre les deux.

C'est ici que le fait d'être sur une plateforme change la nature du problème.

Ces annonces, quelqu'un les lit — avant qu'elles prennent effet, parce que c'est son métier. Quand une fonction est en sursis, le composant qui l'utilise est réécrit une fois, dans le moteur qui construit les apps. Quand une exigence devient obligatoire, elle est intégrée au même endroit, une fois. Et chaque app de la plateforme hérite de ces adaptations à sa construction suivante — la vôtre comme toutes les autres.

Ce que vous n'avez pas fait mérite d'être énuméré, parce que c'est ça, le produit : vous n'avez pas lu les notes de version. Vous n'avez pas cherché lesquelles des fonctions concernées votre app utilisait. Vous n'avez pas arbitré entre l'ancienne et la nouvelle façon de faire. Vous n'avez même pas su qu'il y avait un arbitrage.

Une précision honnête, parce qu'elle compte : cette veille n'a rien d'une assurance tous risques. Elle n'attrape que ce qui a été annoncé ou repéré — c'est un travail continu, exercé par des gens, pas une garantie magique. Mais c'est exactement pour cela qu'elle a de la valeur : elle existe, elle ne s'interrompt pas, et elle n'est pas à votre charge.

Posons le contrepoint, parce qu'il donne la mesure. Si c'est vous qui maintenez le code source de votre app — écrit par un prestataire, ou généré à partir d'un prompt —, septembre a un tout autre visage. Il faut lire ce qui change, identifier ce qui vous concerne parmi des centaines d'annonces, modifier le code, reconstruire, re-soumettre. Puis recommencer pour Android. Puis l'année suivante. Que vous ayez quelque chose de neuf à publier ou non : le rendez-vous est fixé par les systèmes, pas par votre calendrier.

Ce rendez-vous annuel existe aussi sur une plateforme — simplement, il est chez nous. C'est toute la différence entre posséder un problème et bénéficier de sa solution.

Les articles de cette série se terminent d'habitude par la liste de ce que personne ne peut faire à votre place — la carte complète est dans le premier article. Pour les évolutions d'iOS et d'Android, cette liste a une particularité : elle est vide.

Aucune décision à prendre, aucune échéance à suivre, aucun réglage à modifier. C'est la seule des grandes forces qui pèsent sur une app dans la durée pour laquelle votre part du travail est nulle — et c'est précisément pour cela que cet article existe : pour que vous sachiez que cette question-là, vous avez le droit de ne plus vous la poser.

Le seul geste qui reste vôtre est celui qui l'a toujours été : décider quand publier une mise à jour. Les adaptations, elles, sont prêtes et attendent — votre app les embarque à sa prochaine construction, que vous publiiez pour cette raison ou pour n'importe quelle autre.

Le bénéfice tient en une image : la keynote redevient un spectacle. Vous pouvez la regarder par curiosité, vous réjouir d'une nouveauté, ou l'ignorer complètement — aucun des trois choix n'a de conséquence pour votre app. Le mois où tout l'écosystème mobile retient son souffle est, pour vous, un mois comme les autres.

Pour ceux que la mécanique intéresse, j'ai raconté côté ingénierie ce que trois ans d'évolutions des systèmes font réellement à une app — et le travail, peu spectaculaire, qui permet de l'absorber.

Et si vous n'avez pas encore d'app, autant la construire à un endroit où septembre ne sera jamais votre problème : créer mon app avec GoodBarber.

Une fonction utilisée par mon app peut-elle s'arrêter du jour au lendemain ?

C'est rare. La plupart des retraits sont annoncés à l'avance par Apple et Google, avec une échéance — c'est ce qui rend la veille possible : lire ces annonces avant qu'elles prennent effet, et remplacer le composant concerné en amont, pour toutes les apps de la plateforme. Le scénario du « tout s'arrête un matin sans prévenir » est précisément celui que ce travail existe pour empêcher.

Que se passe-t-il pour mon app le jour où un nouvel iOS ou Android sort ?

De votre côté, rien à faire. Un nouveau système ne supprime pas votre app et n'efface rien. Les adaptations qu'il rend nécessaires sont préparées dans le moteur qui construit les apps, et la vôtre les embarque à sa prochaine construction — qu'elle soit motivée par cette raison ou par une simple mise à jour de routine.

Mon app peut-elle être « en retard » de plusieurs versions d'iOS ?

Elle peut, si elle n'a pas été reconstruite depuis longtemps — et ce n'est pas une impasse. Le moteur, lui, est resté au niveau : à la reconstruction suivante, votre app ressort adaptée au système actuel, quel que soit le nombre de versions écoulées entre-temps. Le rattrapage ne se paie pas au prorata du retard.

Une nouvelle version d'Android peut-elle rendre quelque chose obligatoire pour mon app ?

Oui, c'est même le mouvement le plus courant : une nouvelle exigence — souvent liée à la sécurité ou à la vie privée — devient progressivement incontournable, avec une échéance. Sur une plateforme, cette exigence est intégrée une fois, en amont, pour toutes les apps ; la vôtre s'y conforme à sa construction suivante, sans que vous ayez eu à en connaître l'existence.

Un morceau de musique dure trois minutes et s'écoute d'un bloc. Un épisode de podcast en dure quarante, la rediffusion d'une matinale le double, et ça s'écoute en trois fois : vingt minutes dans le métro, dix en cuisinant, le reste au lit.

Ce sont deux usages différents, et jusqu'ici ils partageaient les mêmes commandes. Le lecteur de votre app proposait morceau précédent et morceau suivant, hérités des lecteurs de musique. Sur un épisode de quarante minutes ou sur la rediffusion d'une émission, ces deux boutons ne servent à rien : personne ne veut passer à l'épisode suivant, tout le monde veut revenir sur la phrase qu'il vient de manquer.

Le lecteur existe maintenant en deux versions, et le choix se fait section par section : Music player, celle que vous connaissez, qui reste la version par défaut et ne change rien à vos apps actuelles, et Podcast player, qui remplace les commandes de playlist par celles qu'attend un auditeur de podcast.

Ce choix par section compte dès que votre app mélange les genres. Une radio qui publie ses rediffusions dans une section et ses playlists dans une autre règle chacune de son côté. Le direct, lui, garde son propre lecteur : il n'est pas concerné par ce réglage, mais il hérite du jeu d'icônes dont il est question en fin d'article.

Précédent et suivant laissent la place à deux boutons de saut : retour en arrière et avance rapide, à l'intérieur du même épisode.

Les valeurs par défaut sont celles du marché : 15 secondes en arrière, 30 secondes en avant. Vous les changez dans le bloc Sauts rapides de votre section, de 10 à 60 secondes par pas de 5. Le nombre choisi s'inscrit dans l'icône, l'auditeur sait donc de combien il va sauter avant d'appuyer.

C'est la commande la plus utilisée d'une app de podcast. Elle rattrape un nom propre mal entendu, passe un générique ou un tunnel de publicité, revient sur une explication. Sans elle, il ne reste que la barre de progression, et viser 15 secondes au doigt sur une barre de quarante minutes ne fonctionne pas.

Votre auditeur ferme l'app au milieu d'un épisode. Il la rouvre le lendemain, lance le même épisode, et la lecture repart à la position qu'il avait quittée. Sans manipulation, et sans message.

Dans les listes, le compteur de durée change de sens quand une position est enregistrée : au lieu de la durée totale, il affiche le temps restant. Un épisode entamé annonce « Il reste 12 min ». D'un coup d'œil sur sa liste, l'auditeur voit ce qu'il a commencé et ce qu'il n'a pas ouvert.

Une précision utile : la position est enregistrée sur l'appareil. Un auditeur qui écoute sur son téléphone puis ouvre votre app sur sa tablette recommence l'épisode au début. La reprise suit l'appareil, pas le compte.

Un bouton de vitesse s'ajoute aux commandes. Il ouvre un menu qui s'ancre sous lui, identique du téléphone au bureau.

Six vitesses y sont proposées : 0.8x, 1x, 1.2x, 1.5x, 1.8x et 2x. Un appui applique la vitesse et referme le menu. Sous ces raccourcis, une ligne de réglage fin avec un moins et un plus déplace la valeur de 0,1 à chaque pression, en gardant le menu ouvert. L'amplitude complète va de 0.5x à 3x, soit vingt-six vitesses accessibles.

Il n'y a ni bouton Enregistrer ni bouton Terminé : la vitesse s'applique à l'instant où on la choisit, et la confirmation, c'est la voix elle-même. La valeur active reste inscrite sur le bouton, l'auditeur sait donc en permanence à quelle vitesse il écoute.

Entre l'auditeur qui rattrape deux heures de matinale à 1.5x et celui qui ralentit un entretien dense ou une langue étrangère à 0.8x, c'est la même commande qui sert deux publics opposés.

Le minuteur de sommeil coupe la lecture au bout d'un temps choisi. Le menu propose 5, 10, 15, 30 et 45 minutes, 1 heure, et une entrée qui change tout : fin de l'épisode.

La différence entre les deux compte. Une durée est une horloge : elle tourne quoi qu'il arrive, même en pause, et coupe ce qui est en train de jouer quand elle expire. Fin de l'épisode est une condition de position : elle n'avance que si l'épisode avance, elle se fige quand on met en pause, et elle suit l'épisode que l'auditeur décide d'écouter. Quelqu'un qui s'endort au milieu d'une fiction ou d'un documentaire ne veut pas être coupé à une minute de la fin.

Une fois le minuteur armé, le décompte s'affiche sous l'icône, au format heures minutes secondes. Il indique toujours le temps restant avant l'arrêt, jamais le nom du réglage. Rouvrir le menu fait apparaître une entrée Désactiver en tête de liste.

Le minuteur appartient au lecteur, pas à l'écran. Changer d'épisode, revenir à la liste, naviguer dans l'app : rien ne le désarme. Seuls le choix explicite de le désactiver et la fermeture du lecteur y mettent fin.

Une réserve sur les sorties : le minuteur de sommeil est une fonctionnalité native, il fonctionne sur les apps iOS et Android. Le réglage Mode veille reste accessible dans le back office et le bouton s'affiche dans la preview, mais sur la PWA la commande n'est pas active côté auditeur. Les deux autres réglages, sauts rapides et vitesse de lecture, valent pour les trois sorties.

Le téléchargement d'un épisode n'était possible que depuis sa fiche. Il est maintenant proposé dans la liste elle-même, sur tous les layouts de liste de dernière génération.

Ça change le nombre de gestes pour qui prépare un trajet, un vol, une zone sans réseau. Avant, il fallait ouvrir un épisode, le télécharger, revenir à la liste, ouvrir le suivant, et recommencer. Maintenant l'auditeur parcourt sa liste et emporte trois émissions sans jamais en sortir.

Les icônes du lecteur audio étaient jusqu'ici figées. Elles sont maintenant remplaçables depuis le panneau Icônes de votre app, dans une nouvelle collection Media : Lecture, Pause, Fermer le player, Son précédent et Son suivant.

Le changement vaut aussi pour les lecteurs qui n'ont pas la version podcast : le Live audio, le Live +, le lecteur transversal qui reste affiché pendant la navigation, l'affichage de podcast des générations précédentes et les cellules de son dans les résultats de recherche. C'est ce qui aligne le direct et les rediffusions d'une même app : deux lecteurs différents, un seul jeu d'icônes, y compris sur la barre de lecture qui suit l'auditeur d'écran en écran.

Tout se règle dans le design de votre section audio, sur l'écran de détail : « Modifier le design », puis Page Son. Le bloc Player y propose Music player ou Podcast player. Passez sur Podcast player et trois réglages apparaissent : Sauts rapides, avec l'avance rapide et le retour en arrière, puis Vitesse de lecture et Mode veille, chacun avec son interrupteur et ses couleurs d'icônes. Mode veille est le nom du réglage côté back office, vos auditeurs, eux, ouvrent un menu intitulé Minuteur de sommeil.

Les trois commandes sont indépendantes : rien ne vous oblige à toutes les proposer. Un lecteur avec les sauts rapides seuls, sans vitesse ni minuteur, reste un choix valable, et c'est même le bon réglage pour une section de chroniques de trois minutes.

Une précision qui a son importance : comme pour toute nouvelle fonctionnalité, vos auditeurs ne la verront qu'après une nouvelle génération de votre app, sur iOS, sur Android et sur la PWA.

Siri Actions, c'est un ensemble de questions auxquelles votre app sait répondre à voix haute. Quelqu'un dit « Dis Siri, quoi de neuf sur GoodBarber News ? », et Siri répond en annonçant le nombre de nouveautés, cite la plus récente et la rubrique dont elle vient, puis affiche une carte : vignette, badge de rubrique, titre, une ligne de résumé, jusqu'à cinq lignes. L'app n'a pas besoin d'être ouverte, ni d'avoir été lancée dans la semaine. Cela fonctionne sur les iPhone à partir d'iOS 17, à partir des widgets de contenu de la page d'accueil de votre app. Siri étant l'assistant d'Apple, cette version ne concerne qu'iOS : votre app Android reste inchangée.

Dessous, il y a le framework App Intents d'Apple, la manière moderne pour une app de rendre ses actions et ses contenus disponibles en dehors d'elle-même : vous déclarez ce que l'app sait faire sous une forme structurée, et le système le rend accessible à Siri. Siri Actions ne demande rien à votre compte développeur Apple, et rien à vous dans le back-office.

Votre app reçoit Siri Actions sans le moindre travail de votre part, parce que toutes les apps iOS GoodBarber sont compilées par le même moteur natif. Vous concevez votre app dans le back-office, ce design devient une configuration, et un moteur iOS natif unique la restitue. Une capacité construite dans le moteur n'est ni une extension à acheter, ni un plugin à installer : elle est dans votre prochain build, comprise dans l'abonnement que vous payez déjà. Vous ne changez rien, et l'app se met à répondre.

C'est précisément ce qu'un journal local, une radio ou un club sportif ne pourrait pas s'offrir séparément. Une intégration Siri demande du développement iOS natif, une maîtrise d'App Intents, des tests sur appareils physiques, et un travail à part sur les phrases que les gens prononcent réellement. Ce dernier point est le plus coûteux et le moins visible : une phrase de déclenchement est confrontée à une vraie voix, et si elle est grammaticalement juste mais que personne ne la dirait à voix haute, Siri ne la reconnaît jamais.

Siri lit les widgets de contenu de la page d'accueil de votre app, les fusionne, retire les doublons, trie du plus récent au plus ancien et filtre selon l'abonnement du lecteur. Interroger tout le contenu et trier par date était la réponse évidente ; lire votre page d'accueil était la bonne, parce que c'est le seul endroit où vous avez déjà dit ce qui compte. Vous l'avez organisée, vous avez décidé de ce qui ouvre, et construire un second classement à côté reviendrait à défaire une décision que vous aviez déjà prise. Un article mis en avant dans deux widgets n'est cité qu'une fois. Les contenus réservés aux abonnés sont filtrés selon la personne qui tient le téléphone : un abonné entend parler de ce qu'il paie, et un non-abonné ne s'entend pas annoncer un article sur lequel il buterait contre le paywall.

Le reste du travail a porté sur la retenue. Quand il n'y a rien de neuf, Siri le dit en une phrase et s'arrête, sans question de relance ni proposition de réessayer. Articles, vidéos, photos et podcasts sont pris en compte ; les événements et les points de carte ne le sont pas, parce que la date d'un événement dit quand la chose a lieu, pas quand elle a été publiée, et qu'un classement « quoi de neuf » par cette date ferait du festival de l'été prochain l'actualité la plus fraîche du jour. Les événements appellent leur propre question, plus proche de « qu'est-ce qu'il y a ce week-end ? », et c'est un chantier distinct.

Deux limites de Siri elle-même ont façonné le reste. Siri ne se souvient pas de ce qu'elle vient de vous dire : demandez les nouveautés, écoutez la réponse, puis dites « ouvre la troisième », et il ne se passe rien, parce que chaque requête repart de zéro. Et quand la carte s'affiche après une demande vocale, elle est là pour être lue, pas touchée. Ces deux limites ont poussé la conception dans la même direction : un échange unique, complet en lui-même, sans rien qui reste en suspens sur une relance qui ne fonctionnera pas.

Siri Actions s'adresse à votre audience ; le serveur MCP s'adresse à vous. Depuis le lancement du serveur MCP en mai 2026, l'assistant que vous utilisez déjà peut piloter votre app : publier un article, programmer une push, vérifier une commande ou sortir les chiffres de la semaine, sous votre contrôle. Le connecter relève désormais d'une recherche plutôt que d'une URL à coller, puisque GoodBarber figure dans l'annuaire des connecteurs de Claude et dans l'annuaire d'apps de ChatGPT. Cette surface-là, c'est vous qui parlez à un assistant à propos de votre app, celle qui fait de l'app que vous gérez déjà un backend pour l'IA. L'autre, c'est Siri Actions : votre audience qui parle à son téléphone à propos de votre app.

Les deux reposent sur la même idée, prise par deux bouts : une application vue comme une liste d'actions qu'autre chose peut découvrir et appeler. Apple définit App Intents ; Anthropic a défini le Model Context Protocol, aujourd'hui placé sous la gouvernance de la Linux Foundation. Avec App Intents, c'est l'app elle-même qui publie ses actions, compilées dans son binaire ; avec MCP, c'est un service qui les publie via un serveur hébergé. Siri, Spotlight et l'app Raccourcis appellent les premières ; n'importe quel assistant compatible MCP, Claude ou ChatGPT parmi d'autres, appelle les secondes.

Dans les deux cas, l'app devient quelque chose à qui l'on peut poser une question, et c'est en ce sens que Siri Actions est le MCP de votre app iOS. Le back-office a répondu à la conversation en premier ; l'app publiée le fait à son tour. C'est le même pari que celui décrit par notre Head of Frontend Engineering, Mathieu Poli, quand il a raconté pourquoi nous sommes restés natifs pendant que l'industrie partait puis revenait : construire sur la couche que la plateforme entretient elle-même, c'est garder votre app à portée de tout ce que la plateforme bâtira dessus ensuite.

La fonctionnalité est développée, et elle arrive par étapes. Les App Shortcuts sont compilés dans le binaire : Siri apprend les phrases d'une app au moment de l'installation, à partir de données inscrites dans le build. Il n'y a pas d'interrupteur à distance. Chaque app est compilée avec ou sans la fonctionnalité, ce qui veut dire qu'elle vous parvient par une mise à jour sur le store, pas du jour au lendemain.

La première app à répondre est la nôtre. GoodBarber News est l'app d'actualités que nous publions nous-mêmes sur l'App Store, et elle reçoit la fonctionnalité avant que l'activité de quiconque en dépende. La phase une concerne ensuite un groupe pilote d'apps, et la phase deux fait passer le choix dans le back-office, pour que vous décidiez vous-même, avec un build et une soumission sur le store derrière.

D'autres questions arrivent. La prochaine est déjà en développement : « Quel est le dernier article dans [rubrique] ? », qui ajoute un ciblage par rubrique et une étape de confirmation permettant d'ouvrir l'élément à la voix. Au-delà, les types de contenu que cette première version laisse de côté sont ceux que nous aimerions le plus faire entrer. Les événements ont leurs questions naturelles, « qu'est-ce qu'il y a ce week-end ? » et « qu'est-ce qu'il y a près d'ici ? », et y répondre correctement suppose de traiter la date et le lieu d'un événement pour ce qu'ils sont, au lieu de les fondre dans une liste triée par date de publication.

Il y a une chose que nous ne pouvons pas terminer seuls : les phrases. Ce que votre audience dit réellement à son téléphone différera de ce que nous avons imaginé, et une fois la fonctionnalité arrivée dans votre app, c'est ce que nous souhaitons le plus recevoir en retour.

Demandez ce que l'app expose à un assistant, parce qu'il y a deux réponses distinctes et qu'une plateforme peut avoir l'une sans l'autre. Les réponses vocales sur iOS viennent d'App Intents compilé dans le binaire. Le pilotage de l'app par la conversation vient d'un serveur MCP côté plateforme, et tous les serveurs MCP ne se situent pas à la même altitude. « Nous avons un serveur MCP » ne dit presque rien en soi, et c'est pourquoi la vraie question prend la forme d'un test en cinq points sur la compatibilité avec les agents.

Si vous avez déjà une app GoodBarber, il n'y a rien à faire pour l'instant : la fonctionnalité arrive avec le déploiement décrit plus haut, et nous vous préviendrons quand votre build sera prêt. Pour l'entendre avant, installez GoodBarber News : elle y arrivera à la prochaine mise à jour. Si vous n'avez pas encore d'app, lancez un essai gratuit, construisez une première version et installez-la sur votre téléphone ; quand la fonctionnalité atteindra la plateforme, elle atteindra aussi cette app.

Dois-je configurer quelque chose pour activer Siri Actions dans mon app ?

Non. Siri Actions est compilé dans le moteur natif GoodBarber : la fonctionnalité arrive avec le prochain build de votre app et sa mise à jour sur le store. Pendant le pilote, c'est GoodBarber qui l'active ; une fois l'option dans le back-office, vous choisirez si votre app répond à Siri.

Siri Actions demande-t-il quelque chose à mon compte développeur Apple ?

Non. Siri Actions utilise le framework App Intents d'Apple, qui ne réclame aucune autorisation particulière sur votre compte. Votre app reste publiée sous votre propre compte développeur Apple, exactement comme avant.

Siri va-t-elle lire mes contenus payants à des lecteurs qui n'ont pas souscrit ?

Non. Siri Actions filtre la réponse selon l'abonnement de la personne qui tient le téléphone. Un abonné entend parler des contenus qu'il paie ; un non-abonné ne s'entend pas annoncer un article sur lequel il buterait contre le paywall.

Siri Actions fonctionne-t-il sur Android ?

Non. Siri et App Intents sont des technologies Apple : Siri Actions fonctionne sur les iPhone à partir d'iOS 17. Votre app Android reste inchangée.

Quelle est la différence entre Siri Actions et le serveur MCP de GoodBarber ?

Celui qui pose la question. Siri Actions permet à vos lecteurs de poser une question à votre app publiée, à la voix, depuis leur iPhone. Le serveur MCP de GoodBarber vous permet, à vous qui gérez l'app, de la piloter depuis un assistant IA comme Claude ou ChatGPT : publier du contenu, programmer une push, vérifier une commande. L'un s'adresse à votre audience, l'autre à vous.

Imaginez un auditeur qui interroge un assistant sur une émission en septembre 2026 et reçoit sa grille de 2025. La page citée était exacte au moment de sa publication. Rien n’y indique que l’information a expiré, l’assistant la considère donc comme actuelle. L’auditeur manque l’émission, ou écrit à votre équipe pour savoir quelle version est la bonne. Une ancienne offre d’adhésion ou l’adresse d’un ancien studio produisent la même confusion.

Carolyn Shelby a soulevé ce problème dans Search Engine Journal le 7 septembre 2026 : des informations contradictoires sur une marque peuvent induire en erreur la recherche par IA. Trois mécanismes expliquent pourquoi vos propres pages se retrouvent dans la réponse :

• Les assistants retrouvent les pages par leur formulation. Une question qui emploie l’ancien nom d’une émission mène tout droit à une archive qui le contient encore.
• Ils fusionnent plusieurs sources en une seule réponse. Les dates qui distinguaient ces sources deviennent difficiles à voir.
• Une nouvelle page ne retire pas l’ancienne. La grille actuelle et l’ancienne mention restent disponibles toutes les deux, et rien ne dit à l’assistant laquelle s’applique.

Commencez donc par la source citée par l’assistant. Quelle phrase de cette page ne décrit plus votre service ? Cette phrase a besoin d’une date et d’un chemin vers la réponse actuelle.

Prenez cette station fictive. En mars 2026, elle déplace une émission en soirée et la rebaptise Édition du soir. L’app affiche la nouvelle grille. Un article d’archive de 2025, un dossier de presse téléchargeable et un profil social décrivent encore l’Édition du matin.

Chaque copie appelle un traitement différent. L’archive reste en place, avec une note datée qui renvoie à la page Programmes actuelle. Le dossier de presse et le profil social servent encore, ils sont donc mis à jour. Un PDF qui mérite d’être conservé reste en ligne, clairement étiqueté comme archive.

Trouver chaque article concerné est la partie qui prend du temps. Après quelques années de publication, personne ne se souvient de quels articles mentionnent l’Édition du matin. C’est là qu’un agent connecté devient utile.

Si votre app tourne sur GoodBarber, ses articles vivent dans le gestionnaire de contenu intégré, le CMS. Toute modification faite à cet endroit arrive immédiatement dans l’app native et dans sa version web, sans mise à jour sur les stores. Nous avons construit GoodBarber MCP pour qu’un assistant comme Claude ou ChatGPT puisse se connecter à ce CMS et vous aider à entretenir le contenu.

MCP, le Model Context Protocol, est le standard qui permet à l’assistant de lire et de modifier vos articles à travers cette connexion. Vous fournissez l’information actuelle. L’agent lit les articles, repère les passages qui la contredisent et prépare une liste de corrections. Demandez-lui de proposer d’abord et de n’écrire que ce que vous approuvez.

Pour la station fictive, donnez à l’assistant la page Programmes actuelle et cette consigne :

Utilisez cette page Programmes comme référence. Lisez les articles du CMS de mon app, texte complet inclus, et trouvez toutes les mentions de l’Édition du matin. Montrez-moi les passages à mettre à jour et proposez une note qui renvoie à la grille actuelle. Laissez intactes les références historiques exactes. Ne modifiez rien pour l’instant. Dites-moi quels articles vous avez vérifiés et lesquels vous n’avez pas pu consulter.

Voici le genre de correction qu’il vous propose en retour.

Avant, dans un article d’archive de 2025 :

L’Édition du matin est diffusée chaque matin en semaine.

Note à ajouter au-dessus de ce passage :

Grille archivée de 2025. Depuis mars 2026, l’Édition du matin s’appelle Édition du soir et est diffusée en soirée. Consultez la page Programmes actuelle pour la grille du jour.

Le texte d’origine reste intact et la note explique ce qui a changé. Une fois la proposition relue, demandez à l’agent d’ajouter la note avec un lien vers la page actuelle, puis de relire l’article mis à jour pour que vous puissiez vérifier le résultat. Par GoodBarber MCP, il effectue ces modifications sans que vous ayez à ouvrir chaque article dans le back-office.

La connexion donne à l’agent accès au contenu du CMS que vous autorisez, et à lui seul. Les PDF, les fiches sur les stores et les profils sociaux demandent leurs propres outils. Demandez à l’agent de lister tout ce qu’il n’a pas pu vérifier, pour que ces copies restent sur votre liste.

Si vous n’avez jamais connecté d’assistant à votre app, ce guide pour ChatGPT détaille la configuration, sans code.

Une fois le processus testé sur une émission, ces cinq étapes l’étendent au reste de votre contenu.

1. Partez des questions que pose votre audience

Listez les informations dont votre audience a besoin : horaires, tarifs, noms, adresses.

Servez-vous des messages reçus par le support pour capter leur formulation. « L’Édition du matin existe-t-elle encore ? » a sa place dans la relecture, même si votre équipe a abandonné ce nom depuis des mois. Pour chaque information, donnez à l’agent la réponse actuelle et la date à laquelle elle a pris effet.

Les données d’usage de l’app vous disent quelles pages sont encore ouvertes. Relisez celles-là en premier.

2. Trouvez chaque endroit qui répète une information

Demandez à l’agent de chercher, dans le contenu auquel il accède, la formulation actuelle comme les anciens noms.

Gardez une liste plus large pour tout le reste : site web, fiches sur les stores, PDF, profils externes, et toute page citée par un assistant.

Pour chaque occurrence, demandez la référence de l’article, le passage exact et un verdict : actuel, historique, ou à corriger. Relisez ensemble les changements proposés avant toute écriture.

3. Donnez à chaque information une page de référence et un responsable

Choisissez une page qui porte la réponse actuelle, et nommez la personne qui en a la charge.

Le responsable des programmes possède la grille, et chaque nouvelle saison déclenche une relecture. Partout où c’est possible, les autres pages renvoient à cette référence au lieu de la répéter. Là où l’information doit figurer en entier, comme une fiche sur les stores, ajoutez cette copie à la liste de mise à jour du responsable.

4. Expliquez le lien entre anciens et nouveaux noms

Partout où un ancien nom peut dérouter un lecteur, ajoutez une courte explication : le nom précédent, son remplaçant et la date du changement. Si l’offre a changé elle aussi, précisez quelles conditions s’appliquent aux membres existants.

Ces exemples fictifs montrent le format :

Conservez le récit d’origine d’un événement passé. Ajoutez sa date et un chemin clair vers l’information actuelle.

5. Vérifiez régulièrement les anciens noms

Gardez une courte liste des noms précédents pour la prochaine relecture de l’agent.

Un contrôle mensuel est un bon point de départ. Incluez les autres versions linguistiques de votre contenu et toute correction restée inachevée. Si vous voulez que la relecture tourne seule, planifiez-la dans un assistant ou un outil d’automatisation qui accepte les exécutions programmées ; la connexion MCP lui donne accès à votre app.

Reposez de temps en temps les questions de votre audience à un assistant, et notez les réponses et les sources citées. Vous saurez ainsi si les pages périmées ressortent encore.

Gardez vos articles de référence accessibles dans la version web de votre app autant que dans l’app native. Une adresse web publique est ce qu’un assistant peut lire, citer et transmettre à vos auditeurs. La documentation de Google sur les fonctionnalités d’IA dans la recherche confirme que les mêmes règles d’éligibilité s’appliquent que pour les résultats classiques.

Intégrez cette relecture à votre routine de publication, au même titre que l’entretien de l’app sur le long terme et les mises à jour régulières. Conservez les consignes données à votre assistant, pour que le prochain changement de grille démarre avec une relecture déjà définie.

Choisissez une émission récemment renommée ou une offre qui a changé. Suivez le guide de connexion MCP, donnez à votre assistant l’information actuelle et la page de référence, puis utilisez la consigne ci-dessus.

Relisez ses suggestions, approuvez les bonnes modifications et inspectez le résultat. La prochaine fois qu’un auditeur ouvrira cette ancienne grille, il devrait trouver un chemin clair vers l’émission qu’il peut écouter aujourd’hui.

Pourquoi un assistant IA donne-t-il des informations périmées sur mon entreprise ?

Le plus souvent parce qu’une page, un document ou un profil que vous publiez encore présente une information passée comme actuelle. Vérifiez les sources citées par l’assistant à la recherche de passages périmés. D’autres causes existent, commencez donc par ce que vous pouvez vérifier.

Publier une nouvelle page suffit-il à corriger une réponse d’IA erronée ?

Pas à elle seule. La nouvelle page fournit l’information actuelle, mais les copies anciennes restent accessibles. Mettez à jour celles qui servent encore et ajoutez des notes datées aux archives qui méritent d’être gardées. Votre contenu devient sans ambiguïté ; le moment où la réponse d’un assistant change ne dépend pas de vous.

À quelle fréquence auditer ces informations ?

Un contrôle mensuel est un bon point de départ. Relisez aussi les pages concernées à chaque changement de grille, d’offre ou de lieu, et contrôlez plus souvent les informations qui évoluent vite.

Un agent IA peut-il auditer et corriger mon contenu GoodBarber ?

Oui. Par GoodBarber MCP, un agent connecté peut lire vos articles du CMS, les comparer à l’information actuelle que vous fournissez et proposer des corrections. Demandez-lui de n’appliquer que les changements que vous approuvez, puis de relire les articles modifiés. Sa relecture couvre le contenu auquel il a accès.

Imaginez une association professionnelle qui publie une actualité dès que quelqu’un en a le temps : trois mises à jour pendant la semaine d’un congrès, puis plus rien pendant un mois. Les membres ne peuvent pas prévoir ce que l’app va leur apporter. L’équipe éditoriale ne sait pas quels efforts méritent d’être poursuivis.

Une stratégie de contenu pour application mobile définit le résultat que le contenu doit produire, les besoins récurrents auxquels il répondra, les formats et le rythme que l’équipe peut maintenir, la manière dont les publications seront diffusées et les signaux disponibles qui conduiront à une décision.

Ce guide porte sur le contenu publié et consulté dans une application mobile, et non sur le content marketing destiné à promouvoir une app. Les captures des stores, les campagnes d’acquisition et les publications sociales peuvent attirer les utilisateurs. La stratégie étudiée ici commence après leur arrivée.

Un calendrier n’est que la partie visible. La stratégie est le raisonnement qui détermine ce qui mérite d’y figurer.

« Maintenir l’engagement des utilisateurs » est trop vague pour guider une équipe éditoriale. Remplacez cette intention par un résultat qui relie un besoin de l’audience à la finalité de l’app.

Choisissez un résultat principal pour l’ensemble du dispositif éditorial. L’app d’une association peut aider ses membres à agir face aux évolutions de leur secteur ; une app de tourisme peut faciliter la découverte locale. Toutes deux peuvent publier des articles, des contenus audio et des événements, mais les mêmes formats n’y remplissent pas le même rôle.

Le résultat détermine aussi ce qu’il ne faut pas publier. Une interview peut être intéressante sans avoir sa place dans une app conçue autour de briefings pratiques. La discipline éditoriale commence par un refus utile.

Un pilier éditorial est un sujet dont l’audience a régulièrement besoin et que l’équipe peut traiter avec crédibilité dans la durée. Ce n’est ni le thème ponctuel d’une campagne, ni une étiquette assez large pour accueillir n’importe quel contenu.

Pour notre association professionnelle, quatre piliers pourraient être retenus :

1. Ce qui a changé : de courtes explications sur les évolutions réglementaires ou du marché.
2. Comment l’appliquer : des checklists, des exemples et des leçons pratiques.
3. Ce qui se prépare : les événements, échéances et opportunités.
4. Ce que les membres ont appris : des interviews et des retours de terrain.

Ne conservez un pilier que s’il répond à un besoin récurrent, contribue au résultat principal de l’app et peut être alimenté avec une expertise suffisante pour rester utile.

Trois piliers solides valent mieux que dix catégories mises à jour occasionnellement. Les catégories organisent une bibliothèque ; les piliers organisent une promesse éditoriale.

Choisissez un format parce qu’il aide l’audience à utiliser l’information, et non simplement parce que le CMS le propose.

Une même idée n’a pas besoin d’être déclinée dans tous les formats. Une interview enregistrée peut donner lieu à un épisode monté et à un court résumé écrit. C’est une réutilisation utile ; la dupliquer sur chaque support ne l’est pas.

Définissez ensuite le rythme minimal que l’équipe peut tenir pendant un mois ordinaire. Une publication quotidienne peut avoir du sens pour une rédaction qui promet une information chaque jour. Un éditeur spécialisé créera peut-être davantage de valeur avec une analyse fiable par semaine. Aucune fréquence universelle ne compense un contenu peu pertinent.

Construisez le calendrier par couches : des contenus structurants qui remplissent la promesse récurrente, des contenus pratiques auxquels les utilisateurs peuvent revenir, des contenus d’actualité dont la valeur dépend d’une date et, plus ponctuellement, des contenus de fond.

Si le rythme s’effondre dès que l’activité se charge, ce n’est pas encore une stratégie. Réduisez la promesse avant de réduire la qualité.

Décidez ce que le lecteur peut raisonnablement faire ensuite. Un briefing réglementaire peut conduire à une checklist pratique ; un événement à des informations de préparation ; un point de carte à une autre étape située à proximité.

Gardez une action proportionnée au contenu. Un article n’a pas besoin de demander simultanément au lecteur de s’abonner, de créer un compte, de commenter, de partager et d’activer les notifications.

Dans une App de Contenu GoodBarber, les liens vers des contenus associés, les widgets de la page d’accueil, les catégories, la Recherche, les Favoris et les commentaires peuvent faciliter ces prolongements. Utilisez-les lorsqu’ils raccourcissent le chemin vers l’étape utile suivante.

La publication rend le contenu disponible. La diffusion détermine comment les utilisateurs le découvrent. Ce sont deux décisions éditoriales différentes.

Un nouveau contenu peut apparaître dans sa section, être mis en avant sur la page d’accueil, ressortir dans la Recherche ou être annoncé par une notification. Le choix dépend de l’urgence, de l’audience et de la durée pendant laquelle le contenu restera utile.

La fréquence de publication et la fréquence des notifications ne sont pas la même chose. Une app peut publier chaque jour sans envoyer un push quotidien. Les notifications doivent être réservées aux contenus dont la pertinence et le timing justifient une interruption.

GoodBarber permet d’envoyer des notifications push manuelles ou programmées. L’extension Push automatiques peut créer une règle d’envoi lors de la publication d’un nouveau contenu dans une section donnée. Les Push automatiques sont disponibles pour les Apps de Contenu à partir de l’offre Premium. Ils peuvent être configurés pour les apps natives comme pour les PWA.

L’automatisation supprime une tâche répétitive ; elle ne décide pas si chaque publication mérite un push. Ne l’activez que pour les sections dont la promesse éditoriale le justifie.

Le plan de mesure doit être aussi réaliste que le plan de publication. Un indicateur n’est utile que si l’équipe sait ce qu’il pourrait l’amener à modifier.

Les statistiques internes de GoodBarber donnent une vue directionnelle des sessions, des sessions uniques, des pages vues, de la durée des visites et des jours les plus actifs. Elles font ressortir des évolutions générales entre des périodes comparables, sans attribuer précisément un résultat à un format ni fournir un entonnoir de complétion du contenu.

Les statistiques Push répondent à une question plus ciblée. Pour chaque notification, GoodBarber indique le nombre d’envois, les ouvertures, le taux de clic, la performance attendue d’après les campagnes précédentes et la répartition des ouvertures par heure. Une ouverture ou un clic montre que la notification a suscité une réaction ; cela ne prouve pas que le contenu de destination a été lu en entier ni qu’il a produit le résultat attendu.

Pour analyser des événements précis, la complétion des contenus ou des parcours détaillés, connectez un outil d’analytics externe adapté à la question. Notre guide sur les analytics d’application mobile explique où s’arrêtent les statistiques intégrées et quand une instrumentation supplémentaire devient nécessaire.

Définissez la période d’analyse et les conditions de décision avant de publier. Les exemples ci-dessous illustrent une logique, pas des seuils universels : chaque équipe doit déterminer quelle évolution est significative au regard de son audience et de son coût de production.

Avant de réagir à une évolution, vérifiez que la période, l’audience, l’emplacement et la diffusion étaient comparables. Choisissez ensuite une seule réponse : poursuivre, modifier ou arrêter.

Le CMS intégré prend en charge les articles, vidéos, podcasts, photos, événements et points de carte. Les équipes éditoriales peuvent les organiser en sections et catégories, les programmer et les mettre à jour sans soumettre à nouveau l’app aux stores. Notre guide consacré au CMS GoodBarber présente en détail ces fonctions de production.

La page d’accueil peut donner une hiérarchie visible aux piliers, tandis que la Recherche et la navigation associée maintiennent l’utilité de la bibliothèque lorsqu’un contenu n’y est plus mis en avant.

L’Assistant IA de GoodBarber peut faciliter la rédaction, la reformulation et la traduction dans le processus éditorial. Le choix du sujet, les preuves, le jugement éditorial et la validation restent sous la responsabilité de l’éditeur.

Le serveur MCP de GoodBarber peut également créer, modifier et programmer des contenus CMS, puis préparer les notifications correspondantes par l’intermédiaire d’un assistant IA. Il reste une couche d’exécution au service d’une stratégie préalablement approuvée par l’éditeur. Notre article sur la gestion du calendrier éditorial d’une app avec un agent présente séparément ce workflow.

Le produit facilite l’exécution du système. C’est toujours l’éditeur qui décide quelle promesse compte et quelle publication mérite d’interrompre l’audience.

À un intervalle adapté au rythme de publication, comparez des périodes équivalentes et prenez une décision pour chaque pilier :

• Poursuivre : le besoin reste important et le format retient durablement l’attention.
• Modifier : le besoin est valide, mais le format, l’emplacement, la cadence ou la diffusion sont peut-être inadaptés.
• Arrêter : le contenu ne contribue plus au résultat principal ou ne peut plus être produit avec suffisamment de crédibilité.

Consignez la raison, puis ne modifiez qu’une variable majeure à la fois. Si le sujet, le format, l’emplacement et la notification changent simultanément, la prochaine revue ne permettra pas de comprendre ce qui a fonctionné.

• Le système poursuit un résultat principal et repose sur des piliers crédibles.
• Chaque pilier possède un format principal adapté.
• La cadence minimale reste réaliste pendant une période d’activité ordinaire.
• Chaque publication propose une prochaine action utile.
• La page d’accueil et l’organisation des sections reflètent les priorités éditoriales.
• Les décisions de publication et de notification sont prises séparément.
• Les Push automatiques sont limités aux sections dans lesquelles chaque nouveau contenu justifie un envoi.
• Chaque indicateur est relié à une décision et reste interprété comme une tendance lorsque l’attribution n’est pas disponible.
• Des analytics externes ne sont ajoutés que pour répondre aux questions qui les exigent.
• Chaque revue se termine par une décision : poursuivre, modifier ou arrêter.

Une stratégie solide ne cherche pas à maximiser la quantité de contenu. Elle crée une promesse que l’audience peut reconnaître et un système que l’éditeur peut tenir.

Créez et gérez votre App de Contenu avec GoodBarber

Qu’est-ce qu’une stratégie de contenu pour application mobile ?

Une stratégie de contenu pour application mobile définit ce que l’app publiera, les besoins récurrents de l’audience auxquels elle répondra, les formats et la cadence utilisés, la manière dont le contenu sera diffusé et les éléments qui conduiront à une décision éditoriale. Elle concerne le contenu consulté dans l’app, et non le contenu marketing destiné à acquérir des utilisateurs.

À quelle fréquence une application mobile doit-elle publier du nouveau contenu ?

Adoptez le rythme minimal et fiable qu’exige la promesse de l’app. Un briefing quotidien peut nécessiter des mises à jour chaque jour, tandis qu’une app spécialisée dans l’apprentissage créera peut-être davantage de valeur avec une leçon solide par semaine. La régularité et la pertinence comptent davantage qu’une fréquence universelle.

Quels types de contenus une application mobile peut-elle publier ?

Une App de Contenu peut associer des articles, des contenus audio, des vidéos, des photos, des événements et des informations cartographiques. Choisissez chaque format selon la tâche : expliquer, montrer, enseigner, organiser une activité datée, faciliter la découverte locale ou présenter une preuve visuelle.

Chaque nouvelle publication doit-elle faire l’objet d’une notification push ?

Non. La publication rend le contenu disponible ; un push interrompt l’audience pour l’annoncer. N’envoyez ou n’automatisez une notification que si l’importance, le timing et l’audience du contenu justifient cette interruption.

Comment GoodBarber facilite-t-il une stratégie de contenu pour application mobile ?

GoodBarber réunit dans un même back-office plusieurs formats de contenu, la programmation, l’organisation, la présentation sur la page d’accueil, la Recherche, les notifications et des statistiques directionnelles sur le trafic. Son Assistant IA et son serveur MCP peuvent également faciliter l’exécution d’un plan éditorial après sa définition et sa validation par l’éditeur.

Google demande une chose simple, formulée de façon intimidante : avant de pouvoir demander l'accès à la production, votre app doit avoir vécu un test fermé avec au minimum 12 testeurs inscrits en continu pendant au moins 14 jours.

Source : Play Console Help — App testing requirements for new personal developer accounts, consultée le 11 septembre 2026.

Deux précisions qui évitent beaucoup d'angoisse. D'abord, le compteur suit l'inscription des testeurs, pas vos versions : publier une nouvelle build sur la piste fermée pendant les 14 jours ne remet rien à zéro. Ensuite, ce sont bien 12 comptes Google inscrits, pas 12 appareils, pas 12 avis cinq étoiles.

La règle est vécue comme un jugement sur la qualité de l'app. Elle n'en est pas un. Google ne vous demande pas de réussir votre lancement : il vérifie que votre app a tourné sur de vrais téléphones, entre les mains de vraies personnes, et que vous savez raconter ce qui s'est passé. Personne ne note votre taux de rétention.

Le vrai coût n'est d'ailleurs pas les 14 jours. Ce sont les examens de Google qui les encadrent : jusqu'à sept jours pour valider la piste fermée avant que vos testeurs puissent installer quoi que ce soit, puis généralement sept jours ou moins pour la demande d'accès à la production, puis autant pour la version de production elle-même. Comptez quatre à six semaines entre le premier clic et l'app publique — et calez votre communication dessus plutôt que sur le chiffre 14.

Reste l'autre façon de lire la contrainte. Douze personnes qui utilisent votre app pendant deux semaines, c'est le test utilisateur que vous n'auriez jamais organisé tout seul, et que la plupart des projets solo n'ont jamais. Vous allez apprendre où les gens se perdent sur le premier écran, quel mot de votre menu ne veut rien dire pour eux, et si votre app survit à un téléphone Android de 2019 avec 8 % de batterie. Google vous oblige à faire ce que vous auriez dû faire de toute façon.

Le format attendu par Google est l'Android App Bundle (.aab), pas l'APK. C'est la partie que la plateforme prend en charge de bout en bout.

Avant de soumettre quoi que ce soit, générez et installez la version Ad Hoc de votre app Android sur votre propre téléphone. C'est votre dernier filet : ce que vous ne voyez pas dans l'aperçu du back-office, vous le verrez là.

Ensuite, dans le back-office : Canaux de vente > App Android > Mettre à jour, puis « Soumettre mon application ». La page Soumission à Google Play s'ouvre et vous rend votre fichier .aab en un clic. Rangez-le quelque part d'accessible, vous allez le téléverser dans la minute.

Vous n'ouvrez ni Android Studio, ni Gradle, ni ligne de commande. GoodBarber compile un binaire Android natif en Kotlin et vous le rend prêt à téléverser — c'est exactement le fichier que la Play Console attend.

Un détail qui vous fera gagner du temps plus loin dans le parcours : les moteurs de compilation n'embarquent une librairie que si la fonctionnalité correspondante est activée dans votre back-office. Désactivez-la, la plateforme recompile, la librairie disparaît du binaire. La section « Sécurité des données » de la Play Console, que beaucoup de créateurs solo redoutent, porte donc sur ce que votre app fait réellement — pas sur un paquet de SDK génériques livrés d'office avec le builder.

Les six vérifications avant de créer la piste fermée

1. La version Ad Hoc tourne sur un vrai appareil Android. Pas seulement dans l'aperçu.
2. Les visuels sont prêts : icône 512 × 512 px, image de présentation 1024 × 500 px, et 2 à 8 captures d'écran de téléphone.
3. La fiche Play Store est remplie : nom, description courte, description complète, catégorie, adresse e-mail de contact.
4. La section « Contenu de l'application » est complète : politique de confidentialité, sécurité des données, publicités, audience cible.
5. Les pays et régions de la piste fermée sont sélectionnés — et c'est le piège numéro un. Play Console se base sur le pays du compte Google du testeur, pas sur l'endroit où il se trouve. Votre cousin installé au Québec avec un compte Google canadien ne verra rien si vous n'avez coché que la France. Dans le doute, cochez tous les pays : une piste fermée n'est visible que par vos testeurs.
6. Le canal de retour est renseigné (une adresse e-mail ou une URL). Google le demande, et c'est par là que va arriver la matière du questionnaire final.

Le tutoriel complet, écran par écran, vit dans notre centre d'aide : Publier votre app sur Google Play avec un compte personnel.

Visez 15 à 20 personnes. Pas par excès de zèle : par arithmétique. Sur dix personnes qui vous disent oui, une vous donnera une adresse e-mail qui n'est pas son compte Google, une autre ne cliquera jamais sur le lien d'inscription, une troisième se désinscrira au bout de six jours en faisant le ménage dans son téléphone. Si vous partez à 12 pile, vous découvrez le problème au douzième jour et vous recommencez.

Un point à comprendre avant de démarcher qui que ce soit : vous demandez une inscription, pas une corvée. Vos testeurs installent l'app depuis le Play Store comme n'importe quelle autre, après un clic sur un lien. Il n'y a pas de fichier à charger à la main, pas de manipulation obscure, pas de risque pour leur téléphone. Le dire dès la première phrase double le taux de oui.

Deux mises en garde honnêtes sur ces canaux.

r/androiddev n'est pas le bon endroit pour recruter. C'est un forum de discussion technique, les demandes de test y sont retirées. Les communautés dédiées citées ci-dessus existent précisément parce que cette règle Google a créé le besoin.

Le test croisé remplit le compteur, pas le questionnaire. Douze développeurs qui installent votre app pour que vous installiez la leur satisfont Google sur le nombre — mais le formulaire d'accès à la production vous demandera quels retours vous avez reçus et ce que vous avez changé. Mélangez : quelques testeurs croisés pour atteindre le seuil, quelques personnes réellement concernées par votre sujet pour avoir quelque chose à raconter. Et quand vous allez chercher ces dernières dans une communauté, apportez quelque chose avant de demander. Un message qui ne sert qu'à placer un lien se fait retirer, et c'est justice.

Le message qui obtient un oui

Court, précis, avec le coût réel annoncé. Quelque chose comme : « Je sors une app pour [le sujet]. Google me demande 12 personnes qui l'installent et la gardent 14 jours. Concrètement : un clic sur un lien, l'installation depuis le Play Store, et vous la laissez sur votre téléphone deux semaines. Il me faut l'adresse Gmail de votre téléphone Android. Si vous l'ouvrez deux ou trois fois et que vous me dites ce qui vous agace, c'est parfait. »

Si votre offre GoodBarber inclut les apps natives, elle inclut aussi la PWA générée depuis la même configuration. Envoyez ce lien web avant de demander l'inscription : les gens disent beaucoup plus facilement oui à une app qu'ils ont déjà vue tourner dans leur navigateur.

La Play Console accepte deux façons de désigner vos testeurs : une liste d'adresses e-mail, ou l'adresse d'un groupe Google. Choisissez le groupe, pour une raison très concrète : avec une liste, chaque nouveau testeur vous oblige à rouvrir la piste, modifier la liste et enregistrer ; avec un groupe, vous collez une adresse une seule fois dans la Play Console, et vous gérez ensuite les arrivées depuis Google Groupes. Sur trois semaines de recrutement décalé, c'est une dizaine d'allers-retours en moins.

1. Rendez-vous sur groups.google.com et créez un groupe — par exemple testeurs-monapp@googlegroups.com.
2. Dans les paramètres d'accès, autorisez-vous à ajouter directement des membres : vos testeurs n'auront aucune démarche à faire de leur côté.
3. Ajoutez les adresses Gmail que vous avez collectées, au fur et à mesure.
4. Dans la Play Console, ouvrez Tester et publier > Tests > Tests fermés, puis l'onglet Testeurs de votre piste, et déclarez le groupe par son adresse e-mail.
5. Enregistrez, puis envoyez les modifications pour examen.

Éviter l'erreur « Application non disponible »

C'est le message que voient vos testeurs quand ils cliquent trop tôt, et c'est de loin le plus démoralisant de l'opération : vous avez fait le travail, et les dix premières personnes que vous avez sollicitées vous répondent que ça ne marche pas.

La règle tient en une phrase : on publie d'abord, on envoie le lien ensuite. Tant que votre piste fermée affiche l'état « Brouillon », Google est encore en train de l'examiner et le lien ne mène nulle part. Attendez que l'état passe à « Test fermé » — c'est le signal, et il peut prendre jusqu'à sept jours.

Si le message persiste une fois la piste publiée, la cause est presque toujours dans cette liste :

• le testeur n'a pas ouvert le lien d'inscription « Join on Android » avant d'aller chercher l'app dans le Play Store ;
• il est connecté au Play Store avec un autre compte Google que celui inscrit dans votre groupe ;
• le pays de son compte Google ne fait pas partie des pays/régions cochés sur la piste ;
• il vient d'être ajouté au groupe et la propagation n'est pas terminée : laissez passer quelques minutes à quelques heures.

Le réflexe naturel est de relancer tous les jours. C'est le meilleur moyen de faire désinstaller votre app par les gens qui vous aiment. Trois messages suffisent, et chacun a un rôle différent.

Jour 0 — le lien et une seule question. Le lien d'inscription, la marche à suivre en deux lignes, et une question précise plutôt qu'un « dites-moi ce que vous en pensez » qui n'obtient jamais de réponse. « Sur le premier écran, qu'est-ce que vous ne comprenez pas ? » produit dix réponses utilisables.

Jour 7 — montrez que ça bouge. C'est le moment où l'app disparaît mentalement du téléphone de vos testeurs, et c'est là que la plateforme vous aide. Publiez du contenu neuf depuis le CMS : il arrive dans l'app immédiatement, sans nouvelle build, sans nouvel examen de Google. Accompagnez-le d'une notification push à vos testeurs. Vous venez de prouver que l'app est vivante sans avoir rien resoumis.

Si vous voulez pousser une vraie mise à jour du binaire — un bug corrigé, un écran retravaillé — repassez par Canaux de vente > App Android > Mettre à jour, récupérez le nouveau .aab et déposez-le comme une nouvelle version sur la même piste fermée. Vos testeurs la reçoivent automatiquement, et, encore une fois, cela ne remet pas le compteur des 14 jours à zéro.

Jour 12 — le dernier appel. Demandez un retour final, et surtout demandez explicitement à chacun de rester inscrit jusqu'au jour 15. Deux jours de marge coûtent un message et vous évitent de découvrir un désistement au moment de cliquer sur « Demander l'accès à la production ».

Entre ces trois messages, tenez un journal. Une ligne par retour : la date, qui l'a dit, ce qu'il a dit, ce que vous avez changé, dans quelle version. Ce fichier n'est pas de la bureaucratie — c'est littéralement la réponse à la troisième section du questionnaire, et vous l'aurez écrite sans effort.

Une fois les 14 jours écoulés, ouvrez le tableau de bord de la Play Console et cliquez sur « Demander l'accès à la production ». Google pose ses questions en trois blocs.

Votre test fermé. Comment vous avez recruté vos testeurs, quel a été leur niveau d'engagement, quels retours vous avez reçus. Soyez factuel et chiffré : « 24 personnes sollicitées, 17 inscrites, 15 encore inscrites au terme des 14 jours ; recrutées dans mon entourage professionnel et sur deux communautés de testeurs Android ; 11 ont ouvert l'app plus de trois fois. »

Votre app. L'audience visée, ce que l'app apporte, et une estimation du nombre d'installations attendu. Une estimation modeste et argumentée passe mieux qu'un chiffre rond sorti de nulle part.

Votre préparation à la production. Ce que les retours ont changé, et pourquoi vous considérez l'app prête. C'est ici que votre journal paie : citez deux ou trois retours précis et le correctif qui a suivi.

La checklist avant d'envoyer :

• au moins 12 testeurs encore inscrits au moment de la demande ;
• des réponses spécifiques, jamais génériques — une réponse en deux lignes vagues est le premier motif de second tour ;
• des retours réels cités, pas résumés ;
• au moins un changement concret attribué à un retour, avec la version qui le porte ;
• aucun chiffre gonflé : n'annoncez pas 20 testeurs si vous en avez eu 15.

Comptez généralement sept jours ou moins pour la réponse, envoyée par e-mail au propriétaire du compte. En cas d'approbation, direction Tester et publier > Production : vous créez une version, vous y ajoutez depuis la bibliothèque le dernier App Bundle utilisé en test fermé, et vous envoyez pour examen final.

Le seul poste sur lequel vous avez la main, c'est le recrutement. Lancez-le le jour où vous envoyez la piste fermée à l'examen, pas le jour où elle est validée : les deux compteurs tournent alors en même temps.

Les 14 jours démarrent-ils à la soumission ou à l'inscription des testeurs ?

À l'inscription des testeurs. Il faut 12 comptes inscrits en continu pendant 14 jours : le jour 1 est celui où le douzième testeur est inscrit, pas celui où vous avez envoyé votre app à l'examen.

Puis-je publier une mise à jour pendant le test fermé ?

Oui, et c'est même recommandé. Vous déposez une nouvelle version sur la même piste. Le compteur porte sur l'inscription de vos testeurs, pas sur vos versions.

Est-ce 12 testeurs ou 12 appareils ?

12 comptes Google inscrits à votre piste fermée. Une même personne avec deux téléphones reste un testeur.

Mon compte est-il concerné ?

Si c'est un compte développeur personnel créé à partir du 13 novembre 2023, oui. Les comptes créés avant cette date et les comptes organisation ne sont pas soumis à cette exigence.

Un compte organisation permet-il d'éviter la règle ?

Techniquement oui, mais ce n'est pas un raccourci : un compte organisation suppose une entité juridique enregistrée et un numéro D-U-N-S vérifié. Si vous publiez à titre personnel, la voie du test fermé reste la plus courte. Et la règle porte sur le compte, pas sur la personne qui appuie sur le bouton — déléguer la publication ne la fait pas disparaître.

La même contrainte existe-t-elle sur l'App Store ?

Non. Apple n'impose ni nombre minimum de testeurs, ni durée de test avant publication. Le parcours iOS a ses propres exigences, décrites dans notre guide Publier votre App iOS en Solo.

Et si Google refuse ma demande d'accès à la production ?

Vous pouvez redemander. Reprenez les trois sections en remplaçant chaque formulation générale par un fait : un chiffre, un retour cité, un changement daté. Le refus sanctionne presque toujours une réponse trop vague, rarement l'app elle-même.

Je préfère ne pas m'en occuper. C'est possible ?

Oui : l'option GBTC confie la publication à l'équipe de GoodBarber. Attention toutefois : si votre compte développeur est un compte personnel récent, l'exigence des 12 testeurs sur 14 jours reste attachée à ce compte.

La partie technique de cette histoire — compiler une app Android native, produire un .aab conforme, le régénérer à chaque mise à jour — est celle qui bloquait le plus de créateurs solo il y a dix ans. C'est aujourd'hui un bouton dans un back-office. Ce qui reste entre vous et le Play Store, ce sont douze personnes et quatorze jours, et vous savez maintenant comment les obtenir.

Votre projet est prêt ? Ouvrez Canaux de vente > App Android > Mettre à jour dans votre dashboard GoodBarber et récupérez votre fichier .aab. Pas encore d'app ? Démarrez gratuitement — 30 jours, sans carte bancaire.

Une app iOS créée avec GoodBarber est compilée en Swift. Une app Android est compilée en Kotlin. Ce sont les langages qu'Apple et Google utilisent pour leurs propres apps, et le résultat est une vraie application native : un binaire que vous soumettez à l'App Store et à Google Play, exactement comme le ferait une agence de développement. Un troisième moteur produit une Progressive Web App pour le navigateur et l'ordinateur. Les trois sont générés depuis le même back-office : vous concevez votre app une fois, et chaque moteur la rend correctement pour sa plateforme. Le détail de cette technologie est sur notre page technologie native.

Les frameworks cross-platform, React Native ou Flutter par exemple, empruntent une autre voie : un seul code partagé, affiché sur les deux plateformes à travers une couche intermédiaire. C'est une approche légitime, et pendant des années elle a été la plus pragmatique pour une entreprise qui construit une seule app. C'est aussi celle que nous avons choisi de ne pas prendre.

Quand nous avons construit nos premiers moteurs, la question n'était pas quelle technologie produisait la meilleure app cette année-là. C'était quelle couche serait encore là dans dix ans. Les plateformes le seraient : Apple et Google n'allaient pas abandonner leurs systèmes, leurs outils, leurs SDK. Tout ce qu'il y avait entre les deux, les frameworks qui promettaient d'épargner les plateformes aux développeurs, devait encore gagner sa décennie d'existence. Nous avons donc construit directement sur la couche dont nous étions sûrs qu'elle resterait, et traité tout ce qui s'empilait dessus comme temporaire.

Les années suivantes ont mis cette lecture à l'épreuve. Tous les deux ou trois ans, un nouveau framework était présenté comme l'avenir du mobile : PhoneGap, React Native, Xamarin, Flutter. Nous avons évalué les plus sérieux et passé notre tour à chaque fois, sur la même question de durée de vie. Puis les réponses sont arrivées : Adobe a arrêté PhoneGap en 2020, Microsoft a mis fin au support de Xamarin en 2024. La couche intermédiaire n'a pas arrêté de changer de nom. iOS et Android ont gardé le leur.

Ce pari a un prix. Trois moteurs, ce sont trois équipes, trois expertises et trois implémentations à garder au pas, et c'est précisément pour cela que la plupart des entreprises qui construisent une seule app ne pouvaient pas se le permettre. Une plateforme le peut : les moteurs sont construits une fois et amortis sur chaque app qu'elle produit. Quinze ans d'expertise en création d'apps natives reposent sur cette arithmétique, et c'est aussi pourquoi ce coût ne vous atteint jamais. Les moteurs, l'hébergement, l'infrastructure de notifications push et la publication sur les stores sont compris dans l'abonnement.

Votre app repose sur la fondation qu'Apple et Google entretiennent eux-mêmes, pas sur une couche dont l'avenir dépend de la feuille de route d'une troisième entreprise. Quand un framework est abandonné, il ne se passe rien pour votre app. Quand iOS ou Android évolue, nos moteurs adoptent le changement une fois, de façon centralisée, et votre app est régénérée dans la nouvelle version sans que vous ayez à y toucher. Une app configurée il y a des années est une app à jour aujourd'hui.

Ça se voit aussi dans ce que vos utilisateurs ressentent, en dessous de ce que la plupart des gens savent nommer : un défilement qui suit exactement la physique du système, des transitions qui appartiennent au système d'exploitation, le retour haptique, une barre d'onglets flottante, un lecteur média qui continue quand l'écran s'éteint, des notifications locales qui se déclenchent depuis l'app elle-même quand quelqu'un entre dans une zone géographique, sans aucun serveur. Rien de tout cela ne se configure. Ça vient avec la façon dont l'app est construite, et vos utilisateurs le résument en un mot : « professionnel ».

Quelque chose a changé cette année dans la façon dont les équipes techniques parlent du mobile. En septembre 2026, Shopify a annoncé le retour de toutes ses apps mobiles vers Swift et Kotlin, six ans après avoir adopté React Native, et sa raison n'est pas que le natif se soit soudain amélioré. C'est que l'IA a supprimé la principale raison de l'éviter : le coût de construire la même app deux fois. Quand des modèles et des agents prennent en charge l'essentiel de la traduction et des tests entre plateformes, le code partagé perd son argument économique, et le langage propre à chaque plateforme redevient le choix par défaut.

Nous n'avons jamais eu à faire ce voyage, et le pari a payé d'une façon que nous n'avions pas prévue : nous comptions sur le temps pour le prouver, et la preuve est venue de l'IA. Notre Head of Frontend Engineering, Mathieu Poli, raconte cette histoire de l'intérieur, y compris les frameworks que nous avons évalués en chemin : Tout le monde revient au natif. Nous, on n'est jamais partis.

Posez une seule question : que produit réellement la plateforme ? Un binaire Swift compilé et un binaire Kotlin compilé, soumis aux deux stores en votre nom, sont un objet différent d'une app web emballée pour le mobile. Demandez à voir une app tourner sur un vrai téléphone, et prêtez attention au défilement, aux transitions et à la barre d'onglets. Si la réponse est « natif », vous le sentirez avant qu'on vous l'explique.

Vous pouvez le tester vous-même : démarrez un essai gratuit, construisez une première version de votre app, et installez-la sur votre téléphone.

Les apps GoodBarber sont-elles vraiment natives ?

Oui. L'app iOS est compilée en Swift et l'app Android en Kotlin, et les deux sont soumises à l'App Store et à Google Play sous forme de vrais binaires, en votre nom. Le troisième moteur, la Progressive Web App, tourne dans le navigateur, et c'est voulu.

Application native ou PWA, que choisir ?

Les deux sortent du même projet GoodBarber, la question se pose donc rarement en ces termes ; choisir entre un site web, une app et une PWA a son propre article. Les apps natives sont celles que vos utilisateurs trouvent dans les stores et celles qui vous donnent le défilement, les transitions et les fonctions de l'appareil propres à chaque plateforme ; la PWA ajoute le navigateur et l'ordinateur.

Une application native coûte-t-elle plus cher ?

Pas avec un app builder. Les moteurs sont construits une fois et amortis sur toutes les apps de la plateforme, si bien que leur coût, avec l'hébergement, l'infrastructure push et la publication sur les stores, est compris dans l'abonnement. Le prix de construire deux fois ne concerne que le développement sur mesure, et c'est la raison pour laquelle le secteur a cherché des alternatives.

Imaginez une app de formation. Un nouvel apprenant arrive pour suivre une courte leçon sur un sujet précis. Avant de pouvoir commencer, l’app affiche cinq écrans d’introduction, lui demande de s’inscrire, sollicite l’autorisation d’envoyer des notifications, puis ouvre un fil d’actualités générique. Chaque écran peut être bien conçu, mais la première session a échoué : l’apprenant n’a toujours pas trouvé de leçon.

L’onboarding mobile est le parcours qui va du premier lancement à un premier résultat utile : la première valeur. La réalisation de l’action qui produit ce résultat correspond à l’activation.

L’onboarding est souvent réduit au guide présenté au premier lancement, mais les deux notions ne se confondent pas. Un guide interactif n’est qu’une façon d’accompagner le parcours : une courte séquence d’écrans qui apporte le contexte essentiel avant l’entrée dans l’app. Avec GoodBarber, l’extension Guide Interactif permet de créer cette introduction. Son utilité dépend de ce qui sépare un nouvel utilisateur de la première valeur.

Ne commencez pas par décider quels écrans d’introduction créer. Demandez-vous d’abord ce qu’un nouvel utilisateur doit être capable d’accomplir. Cet objectif définit le parcours d’onboarding et permet de déterminer si un guide interactif, des indications contextuelles ou un accès direct constituent le meilleur choix.

Les recommandations d’Apple sur l’onboarding préconisent de rendre l’app compréhensible par l’usage et de garder tout parcours d’introduction bref et facultatif. Un guide est utile lorsqu’il lève une incertitude ; dans le cas contraire, il ne fait que retarder l’accès au produit.

« Comprendre l’app » est un objectif trop vague pour être conçu ou mesuré. Choisissez une action qui relie la première session à la finalité de l’app.

Pour l’app de formation, « consulter la page d’accueil » ne suffit pas. « Commencer une leçon pertinente » est plus significatif, car cette action correspond à la raison pour laquelle l’apprenant a installé l’app.

Remontez ensuite le parcours à partir de cette action. L’apprenant devra peut-être comprendre que les cours sont classés par objectif, choisir une catégorie et reconnaître la carte d’une leçon. En revanche, il n’a pas nécessairement besoin d’un compte, d’autoriser les notifications ou de connaître tous les formats disponibles.

Donnez un seul objectif principal à la première session. Les réglages supplémentaires peuvent attendre jusqu’au moment où ils débloquent un bénéfice visible.

Le modèle le plus adapté dépend de ce qu’une personne doit savoir ou faire avant d’atteindre la première valeur.

Vous pouvez combiner plusieurs modèles, mais chaque ajout doit avoir une raison d’être. L’app de formation pourrait présenter deux écrans centrés sur les bénéfices avant une page d’accueil organisée par objectif pédagogique. Une app privée destinée aux employés peut expliquer le service avant l’authentification, puisqu’aucun contenu ne peut être public.

1. Présentez le résultat avant la fonctionnalité

« Accédez à des articles, vidéos et podcasts » décrit un catalogue. « Commencez une leçon adaptée à votre emploi du temps » décrit un résultat. Commencez par ce que l’utilisateur peut accomplir, puis présentez uniquement la fonctionnalité nécessaire à l’action suivante.

Pour l’app de formation, expliquez que les leçons sont classées par objectif et par durée. Le profil, les Favoris et les notifications peuvent attendre.

2. Donnez un seul rôle à chaque écran

Un écran d’onboarding doit communiquer une promesse, demander une décision ou expliquer une action. Supprimez ceux qui sont purement décoratifs ou qui répètent la fiche du store. Il est plus important de réduire les décisions inutiles que le nombre brut d’écrans.

3. Gardez une sortie visible

Un guide interactif doit aider la personne à entrer dans le produit, pas le dissimuler derrière une présentation. Proposez une option Ignorer clairement visible et assurez-vous que la page d’accueil permet toujours d’identifier l’étape suivante.

4. Demandez les autorisations dans leur contexte

Reliez chaque demande système à la fonctionnalité qu’elle active. La localisation a du sens lorsqu’une personne recherche du contenu à proximité ; l’autorisation d’envoyer des notifications est plus facile à comprendre une fois que l’app a montré ce qu’elle peut apporter.

Apple recommande de demander un accès pendant l’onboarding uniquement lorsqu’une donnée privée ou une ressource est indispensable au fonctionnement de l’app ; sinon, attendez que la personne atteigne la fonctionnalité concernée. Android recommande de même d’expliquer une autorisation au moment où elle devient nécessaire.

5. Reportez l’inscription lorsque le service le permet

Un compte se justifie lorsque l’identité fait partie du service : ressources privées, contributions des utilisateurs, progression synchronisée ou transactions protégées. Un apprenant peut parcourir un catalogue et ouvrir une leçon gratuite avant de s’identifier ; une app de formation interne contenant des documents confidentiels peut légitimement exiger une authentification dès le départ.

Dans une app eCommerce, laissez les visiteurs découvrir les produits avant de leur demander de créer un compte. Avec GoodBarber, le passage en caisse peut autoriser les commandes invitées ou exiger un compte client, selon l’expérience que vous souhaitez proposer.

6. Concevez la première page d’accueil et les états vides

L’onboarding ne s’arrête pas lorsque le dernier écran d’introduction disparaît. L’écran suivant doit prolonger la même promesse.

Rendez la première action utile facile à trouver. Donnez des noms précis aux sections et expliquez les états vides. « Aucun favori » décrit un état ; « Enregistrez une leçon pour la retrouver ici » enseigne l’action.

Dans notre app de formation, la page d’accueil doit mettre en avant les objectifs pédagogiques et une première leçon adaptée. Envoyer l’apprenant vers un fil générique romprait le parcours construit par le guide.

7. Intégrez l’accessibilité au premier parcours

La première action doit rester utilisable avec un texte agrandi, des technologies d’assistance et différents modes de saisie. Vérifiez les contrastes, les libellés, l’ordre de focus, les zones tactiles, les mouvements et les alternatives aux médias sur l’ensemble du parcours. Notre checklist d’accessibilité des apps mobiles distingue les réglages centralisés des tests à effectuer dans l’app publiée.

L’extension Guide Interactif de GoodBarber propose une séquence d’introduction pour les Apps de Contenu et les Apps eCommerce. Vous pouvez créer jusqu’à cinq étapes, choisir entre deux modes d’affichage, ajouter des images ou des animations Lottie, personnaliser la typographie et les couleurs, afficher un indicateur de pages et inclure un bouton Ignorer.

Le Guide Interactif apparaît au premier lancement après l’installation. Il est disponible sur mobile, mais pas sur iPad. Sur une PWA, il apparaît dans la version ouverte dans le navigateur, mais pas dans la version autonome installée.

Pour l’app de formation, deux étapes peuvent suffire :

1. Expliquez le résultat : trouver une leçon adaptée à l’objectif actuel et au temps disponible.
2. Expliquez l’organisation : choisir un objectif, puis ouvrir une leçon pour commencer.

La page d’accueil doit tenir cette promesse. Utilisez Mon app > Style de l'app pour définir les couleurs, les polices et les boutons globaux de l’interface, puis alignez les réglages visuels du Guide Interactif sur ce système. Vous créerez ainsi une continuité visuelle entre l’introduction et l’app. La documentation sur le Style de l’app explique comment les choix globaux s’appliquent aux différentes sections.

L’authentification nécessite une décision distincte. L’extension Authentification de GoodBarber est disponible pour les Apps de Contenu et peut protéger toute l’app ou certaines zones ; l’accès peut également rester facultatif. Si l’app entière est verrouillée, le Guide Interactif s’affiche avant l’écran de connexion.

GoodBarber applique aussi un ordre documenté autour du Guide Interactif. Les fenêtres de consentement relatives aux cookies ou à Funding Choices s’affichent avant lui. Les demandes concernant les SMS, les notifications push, la localisation et l’installation apparaissent après. Concevez les messages du Guide Interactif en tenant compte de cet ordre : le parcours ne doit pas laisser croire que chaque demande peut être placée à n’importe quelle étape.

Après la première session

Une fois la première valeur atteinte, l’apprenant peut enregistrer une leçon ou s’abonner à une mise à jour utile. Écartez ces actions du premier lancement tant qu’elles ne sont pas nécessaires. Notre guide sur la personnalisation d’une app mobile aborde cette relation dans la durée.

Mesurez le parcours jusqu’à l’action que vous avez définie, pas le simple affichage de chaque écran d’introduction.

Les statistiques intégrées de GoodBarber présentent les lancements, les sessions uniques, les pages vues, les téléchargements et la durée des visites, calculés chaque jour pour la veille. Elles révèlent les évolutions générales, mais ne constituent pas automatiquement un entonnoir d’onboarding écran par écran.

Pour l’app de formation, mesurez si un nouvel apprenant commence la première leçon. Si l’intégration choisie expose cet événement, comparez-le aux premiers lancements et aux étapes qui le précèdent. Testez une seule modification à la fois : retirer un écran, clarifier une catégorie ou remonter la première leçon.

Pour une app eCommerce, la première action utile peut être de consulter un produit pertinent ou de l’ajouter au panier, et non de finaliser tout l’achat pendant la première session.

Connectez un outil d’analytics externe lorsque la question exige d’analyser les parcours événement par événement, l’activation ou la rétention. Le guide des analytics d’app mobile explique les rôles complémentaires des statistiques internes de GoodBarber et des outils connectés.

• La première action utile est définie en termes observables.
• La première session a un seul objectif principal.
• Chaque écran d’introduction lève une véritable incertitude.
• Un guide interactif n’est utilisé que si l’accès direct n’est pas plus clair.
• Le guide propose une option Ignorer visible.
• Chaque écran communique une seule idée ou action.
• L’inscription n’est obligatoire que si le service a besoin de l’identité à ce stade.
• Chaque demande d’autorisation a une finalité compréhensible liée à une fonctionnalité.
• La première page d’accueil prolonge la promesse faite pendant l’onboarding.
• Les états vides expliquent l’action utile suivante.
• L’accessibilité de l’ensemble du parcours a été vérifiée.
• L’action d’activation et les principaux points d’abandon peuvent être mesurés avec la configuration d’analytics choisie.

Présentez le parcours finalisé à une personne qui n’a jamais vu l’app. Ne lui donnez aucune explication. Observez où elle s’arrête et si elle atteint la première valeur.

Le meilleur onboarding n’est pas celui qui enseigne le plus. C’est celui qui devient inutile le plus vite.

Créez votre app et concevez un premier parcours utilisateur plus clair

Combien d’écrans d’onboarding une app mobile doit-elle comporter ?

Utilisez uniquement les écrans nécessaires avant la première action utile. Certaines apps n’en ont besoin d’aucun. Le Guide Interactif de GoodBarber accepte jusqu’à cinq étapes, mais il s’agit d’une capacité maximale, pas d’un objectif.

Faut-il obliger les utilisateurs à créer un compte pendant l’onboarding ?

Seulement lorsque l’identité est nécessaire pour fournir le service ou protéger le contenu. Sinon, montrez d’abord une valeur publique utile. L’Authentification GoodBarber peut protéger toute une App de Contenu ou certaines zones et autoriser un accès facultatif.

Toutes les apps ont-elles besoin d’un guide interactif ?

Non. Si la page d’accueil, la navigation et la première action se comprennent d’elles-mêmes, un accès direct peut constituer un meilleur onboarding. Utilisez un guide lorsqu’un minimum de contexte raccourcit réellement le chemin vers la première valeur.

Comment mesurer la réussite de l’onboarding d’une app mobile ?

Définissez une action d’activation, puis examinez combien de nouveaux utilisateurs l’accomplissent, le temps nécessaire, les points d’abandon, la réaction aux demandes d’autorisation essentielles et le retour après la première utilisation. Associez chaque question aux données réellement disponibles dans votre configuration d’analytics.

1. Pouvez-vous concevoir votre application vous-même ?
2. Ce que coûte le design d'une application, et le temps qu'il prend
3. Les six décisions qui vous appartiennent vraiment
4. Ce que vous n'avez pas à décider
5. Android, iPhone et le web
6. Et Figma, alors ?
7. La checklist avant de vous lancer
8. Questions fréquentes
9. Par où commencer

Presque tout ce qui s'écrit sur la conception d'une application s'adresse à des designers. Étudiez vos utilisateurs, cartographiez les parcours, esquissez des wireframes, passez en haute fidélité, transmettez à l'équipe technique. C'est une vraie méthode et c'est la bonne pour une équipe de design.

Ce n'est pas une réponse pour quelqu'un qui a un projet, un budget, et aucune formation en design.

La question de fond est plus simple. Pouvez-vous concevoir votre application vous-même, ou faut-il payer quelqu'un ? Les deux réponses se défendent. Voici ce que chacune coûte, et en quoi consiste réellement le travail de design une fois qu'on en retire tout ce qu'un système sait faire à votre place.

Pour une application de contenu ou de commerce, oui.

Applications d'actualité, de communauté, de médias et de podcasts, de cours en ligne, de commerce de proximité, boutiques. Elles sont faites de pièces que tout le monde reconnaît : des listes, des pages d'article, des fiches produit, un panier, un profil, une recherche. Le problème de design est bien connu, et il a été résolu des milliers de fois.

Pour un jeu, non. Pour une place de marché du type Airbnb ou Booking, non plus. Ces applications tiennent leur valeur d'une logique métier sur mesure plutôt que de leurs écrans, et il leur faut un développeur et un designer qui travaillent ensemble sur quelque chose qui n'existe pas encore. Si c'est votre projet, recrutez l'équipe. Cet article ne vous aidera pas.

Si la première liste est aujourd'hui à votre portée, ce n'est pas parce que le design est devenu facile. C'est parce que le travail de design a été systématisé. Le métier appelle ça un design system : un ensemble de fondations, de composants et de règles qui produisent des écrans cohérents sans que personne les redessine à chaque fois. Apple en a un. Google en a un. Toutes les équipes produit sérieuses en ont un.

Ce qui devient intéressant, c'est quand le design system se trouve à l'intérieur de l'outil qui fabrique l'application, et non dans un fichier que votre designer vous remet à la fin.

C'est la question à laquelle personne ne répond par un chiffre. Voici donc trois grilles publiées par des studios qui affichent leurs tarifs.

Les délais concordent d'une source à l'autre : quatre à huit semaines pour un MVP cadré, six à douze pour un projet plus large. Il s'agit de la phase de design seule, avant qu'une ligne de l'application ne soit fabriquée. Les montants sont en dollars parce que ces grilles sont américaines.

Ce sont des chiffres de design. Ils couvrent la phase de design et rien d'autre. Ni développement, ni back-end, ni tests, ni publication sur les stores, ni maintenance. Un devis de design n'est pas le prix d'une application.

Ces chiffres se lisent avec une réserve. Ils sont publiés par des studios qui vendent du design. Ils sont donc fiables sur leurs propres tarifs, et optimistes sur la quantité de design dont votre projet a besoin.

Le chiffre le plus parlant est celui de l'écran. Il révèle le modèle de facturation : chaque écran est dessiné, donc chaque écran est facturé. Vingt écrans ne coûteront pas exactement vingt fois un écran, mais la facture suit la quantité de dessin produite plutôt que le nombre de décisions que vous avez prises, et elle grimpe à chaque section ajoutée.

C'est ce modèle qu'il vaut la peine d'éviter. Pas en dessinant des écrans moins bons, mais en n'en dessinant pas la plupart.

Chez GoodBarber, il n'y a pas de ligne « design » sur la facture, parce qu'il n'y a pas d'écrans à facturer. Le design system fait partie de l'abonnement : les applications de contenu démarrent à 30 € par mois avec un engagement annuel, et les offres qui publient en natif sur iOS et Android à 55 €. L'hébergement, les mises à jour et les trois moteurs applicatifs sont compris dans le même prix.

Voici ce qu'il reste du travail de design une fois que le système a pris sa part. Six décisions. Vous pouvez toutes les prendre en un après-midi, et revenir sur n'importe laquelle plus tard sans refaire l'application.

1. Ce que contient l'application

Vos sections, et leur ordre. Une décision de contenu avant d'être une décision de design, et celle qui détermine le plus si l'application tombe juste. Cinq sections qui méritent chacune leur place valent mieux que quinze qui ne le méritent pas.

Partez de ce que les gens viendront y faire. Le reste relève de la navigation secondaire.

2. Comment on y circule

Une barre d'onglets en bas, un menu latéral, ou les deux. C'est la décision la plus visible d'une application mobile, et celle que l'utilisateur ressent avant de remarquer quoi que ce soit d'autre.

La règle empirique : une barre d'onglets pour trois à cinq destinations entre lesquelles les gens font des allers-retours en permanence, un menu pour tout ce qu'on visite de temps en temps.

3. À quoi ressemble une liste

C'est la décision qui fait le plus de travail, et celle qu'on sous-estime.

Une application de contenu, c'est surtout des listes. Listes d'articles, grilles de produits, listes d'épisodes, listes d'événements. Choisissez la présentation d'une liste et vous avez choisi l'allure de la plus grande partie de votre application : image à gauche ou pleine largeur, une colonne ou deux, titre au-dessus ou en dessous, combien de texte s'affiche avant la coupe.

GoodBarber propose plus de 100 layouts prêts à l'emploi, et vous en choisissez un par section. Une grille magazine pour vos dossiers, une liste compacte pour l'actualité, un carrousel à grande image pour votre accueil. Le même contenu, trois applications différentes selon ce que vous prenez.

4. La couleur

Vous choisissez quatre couleurs, pas trente.

Un thème GoodBarber définit quatre rôles de couleur sémantiques, appliqués partout de la même façon. Sémantique veut dire que chaque couleur a un métier plutôt qu'une position : l'une est la couleur de vos actions, l'autre celle de vos surfaces. Modifiez le rôle et tous les écrans qui s'en servent suivent.

Si choisir quatre couleurs qui vont ensemble est précisément la partie qui vous inquiétait, Genius Palette est une IA maison entraînée sur la couleur lisible en application. Et si vous savez exactement ce que vous voulez, vous pouvez reprendre la main sur chaque couleur, jusqu'à l'affectation élément par élément.

5. La typographie

Une police, ou deux si vous voulez que les titres contrastent avec le texte courant.

Vous ne choisissez pas les tailles. La typographie de GoodBarber est un système de 18 niveaux sémantiques, du grand titre jusqu'au badge, chacun calibré par appareil pour le téléphone, la tablette et le bureau, avec un interligne de 1,2. Vous choisissez la police. L'échelle est déjà construite.

6. Votre icône et votre écran de démarrage

Les deux images qu'aucun système ne peut décider à votre place, parce qu'elles portent votre identité et non votre interface.

L'icône est la chose la plus difficile de cette liste, et celle sur laquelle il vaut la peine de passer du temps ou de mettre de l'argent. Elle doit tenir à 60 pixels, à côté d'Instagram, sur l'écran d'accueil de quelqu'un. Une forme simple, peu de couleurs, pas de texte, reconnaissable d'un coup d'œil.

Tout ce qui suit est pris en charge par le système, sur chaque écran, sans un réglage à apprendre.

Les espacements. Un système de gouttière s'adapte à l'appareil à partir d'une valeur de base : 16 px sur mobile, 20 px sur tablette et sur bureau, avec des paliers en demi et en double et des pas verticaux. Une seule configuration produit les bons espacements sur tous les formats.

La hiérarchie typographique. Les 18 niveaux gardent leurs rapports entre eux quelle que soit la police que vous choisissez.

La lisibilité. Les palettes sont construites en tenant compte des contrastes, et chaque contrôle conserve une zone de tap confortable même quand l'élément paraît petit.

Les formes, les ombres, les bordures et les états. Définis une fois comme des atomes et réutilisés partout, pour qu'un bouton se comporte comme un bouton dans toute l'application.

La cohérence entre les écrans. C'est ce qui distingue une application qui a l'air dessinée d'une application qui a l'air assemblée, et c'est aussi ce qu'un designer doit entretenir à la main. Ici, c'est acquis par construction.

Vous concevez une fois. Une seule configuration produit trois sorties : une application iOS native, une application Android native, et une progressive web app.

Ce qui diffère entre elles relève des plateformes, pas de vous. Les deux stores ont leurs conventions, et le système les respecte. Vous n'entretenez pas trois designs, et vous n'avez pas à choisir entre une application juste sur iPhone et une application juste sur Android.

Un point à anticiper : ajouter une fonctionnalité ou modifier votre design demande une recompilation, et cela vaut pour les trois sorties, la web app comprise. C'est une seule action, mais elle n'est pas instantanée.

Figma est l'outil du métier, et il est excellent dans ce pour quoi il est fait. Si vous recrutez un designer, il y a toutes les chances qu'il travaille dessus, et que ce soit ce qu'il vous remette à la fin.

La distinction utile avant d'y passer des semaines : Figma produit un fichier de design, pas une application. Un fichier magnifique, précis, entièrement spécifié. Quelqu'un doit ensuite le construire, et c'est là qu'apparaît le second budget, en général plus élevé que le premier.

Figma est le bon outil quand votre application a besoin d'écrans qui n'existent pas encore, et que vous avez l'équipe technique pour fabriquer ce que vous dessinez. Pour une application faite de listes, d'articles, de produits et d'un panier, dessiner ces écrans en partant de zéro est un travail que vous payez deux fois : une fois pour le concevoir, une fois pour le réaliser.

Et si vous avez déjà un fichier Figma remis par un designer, il n'est pas perdu. Vos couleurs, votre police et vos préférences de mise en page sont exactement les six décisions ci-dessus, déjà prises.

Huit réponses, et votre design est fait.

1. À quoi sert l'application, et qui l'ouvre ? Tout le reste en dépend.
2. Quelles sections méritent leur place, et dans quel ordre ? Cinq qui font chacune un travail, pas quinze qui remplissent un menu.
3. Lesquelles vont dans la barre d'onglets ? Trois à cinq destinations entre lesquelles on passe constamment. Le reste va dans le menu.
4. Quel layout pour chaque section ? Un choix par section, et il décide de l'allure de la plus grande partie de l'application.
5. Quelles couleurs prennent les quatre rôles sémantiques ? Commencez par la couleur de vos actions et celle de vos surfaces.
6. Une police, ou deux ? Deux si vous voulez que les titres contrastent avec le texte courant. Vous ne choisissez pas les tailles.
7. Votre icône, et votre écran de démarrage. L'icône tient-elle à 60 pixels, à côté d'Instagram ? Forme simple, peu de couleurs, pas de texte.
8. Y a-t-il là-dedans quelque chose de vraiment sur mesure ? Si une partie demande un développeur et un designer, mieux vaut le savoir maintenant qu'après.

Peut-on concevoir une application soi-même sans être designer ?

Pour une application de contenu ou de commerce, oui. Ces applications sont faites de pièces que tout le monde reconnaît : des listes, des pages d'article, des fiches produit, un panier, un profil, une recherche. Un design system prend en charge le travail répétitif, les espacements, la hiérarchie, les contrastes et la cohérence entre les écrans, et il vous laisse six décisions. Pour un jeu ou une place de marché, non. Ces produits tiennent leur valeur d'une logique métier sur mesure, et ils demandent un développeur et un designer.

Combien coûte le design d'une application ?

Les grilles publiées par les studios situent une application simple entre 5 000 et 15 000 dollars chez un indépendant, et entre 15 000 et 40 000 en agence. Une application complexe monte de 40 000 à 80 000. Ce sont des montants de design seul. Le développement, les tests, la publication et la maintenance sont des budgets à part. Quand le design system est intégré à l'outil qui fabrique l'application, il n'y a plus de facture de design par écran.

Combien de temps prend le design d'une application ?

Quatre à huit semaines pour un MVP cadré, six à douze pour un projet plus large. Il s'agit de la phase de design seule, avant qu'une ligne de l'application ne soit fabriquée. Choisir à l'intérieur d'un design system qui existe déjà se fait en un après-midi, parce que les fondations et les composants sont déjà là.

Quelles sont les six décisions du design d'une application ?

Ce qui entre dans l'application et dans quel ordre, comment on y circule, l'allure des listes, la couleur, la typographie, et votre icône avec votre écran de démarrage. Tout le reste, les espacements, la hiérarchie typographique, la lisibilité, les formes et les états, la cohérence entre les écrans, est pris en charge par le design system plutôt que décidé par vous.

Qu'est-ce qu'un design system ?

Un ensemble de fondations, de composants et de règles qui produisent des écrans cohérents sans que personne ait à les redessiner à chaque fois. Apple en a un, Google en a un, et toute équipe produit sérieuse aussi. Quand le design system est logé dans l'outil qui fabrique l'application plutôt que dans un fichier livré à la fin, la plupart des écrans ne sont jamais dessinés.

Faut-il Figma pour concevoir une application ?

Non. Figma est excellent et c'est ce qu'un designer vous livrera, mais il produit un fichier de design, pas une application. Il reste à fabriquer ce que le fichier décrit, et ce second budget est en général plus lourd que le premier. Pour une application faite de listes, d'articles, de produits et d'un panier, un design system intégré au constructeur produit directement les écrans finis.

Combien de couleurs pour une application ?

Moins qu'on ne le croit, et ce qui compte n'est pas le nombre mais le fait que chaque couleur ait un rôle. Un thème GoodBarber définit quatre rôles de couleur sémantiques appliqués partout de la même façon : l'une est la couleur de vos actions, une autre celle de vos surfaces. Changez le rôle et tous les écrans qui l'utilisent suivent. Trente couleurs choisies une par une, ce n'est pas de la richesse, ce sont trente choses à tenir cohérentes à la main.

Quelle différence entre le design et le développement d'une application ?

Le design est l'ensemble des décisions qui donnent son organisation et son allure à l'application : les sections, la navigation, les layouts, la couleur, la typographie, l'icône. Le développement, c'est fabriquer le logiciel : le code, le back-end, les intégrations, les tests, la publication sur les stores. Les montants cités dans cet article sont des montants de design. Le développement est un budget distinct.

Peut-on changer le design une fois l'application fabriquée ?

Oui. Les six décisions reposent sur un design system, donc changer un layout, un rôle de couleur ou une police se propage à tous les écrans concernés. Appliquer le changement demande de recompiler l'application iOS, l'application Android et l'application web. C'est une seule action, mais elle n'est pas instantanée.

Quand faire appel à un designer professionnel ?

Quand la valeur de l'application tient à quelque chose qui n'existe pas encore : des interactions inédites, des parcours complexes, une logique métier lourde et sur mesure. Un jeu, une place de marché façon Airbnb ou Booking. Pour une application bâtie sur des motifs conventionnels, sous-traiter le dessin des écrans revient surtout à payer un travail que le design system fait déjà.

Ouvrez une section, choisissez un layout, changez les quatre couleurs et regardez votre propre contenu dedans. Un quart d'heure vous en apprendra plus sur le design de votre application qu'une semaine de lecture sur le design.

Dessiner l'application, c'est une moitié de la question. Si vous en êtes encore à l'autre moitié, la façon dont elle se fabrique et se publie, elle a son propre guide : comment créer une application.

Vous pouvez démarrer un essai gratuit de 30 jours sans carte bancaire et sans engagement. Et si vous voulez mesurer la profondeur du système avant d'y toucher, il est entièrement public : fondations, atomes, composants et les principes qui les tiennent, sur goodbarber.com/uxdesign.

Sources. Chiffres de coût et de délai compilés en septembre 2026 à partir de trois grilles tarifaires publiées par des studios : Parallel, Orbix Studio et DesignMonks. Ils sont fiables sur leurs propres tarifs, et optimistes sur la quantité de design dont un projet donné a besoin. Le design system GoodBarber cité tout au long de cet article est public : fondations, atomes, composants et les principes qui les sous-tendent.

Imaginez que nous sommes dimanche soir. L'app de votre boutique est en ligne depuis un an, les commandes tombent tous les jours, et vous vous dites depuis des semaines qu'il faudrait essayer cette chose dont tout le monde parle : piloter l'app en discutant avec Claude. Vous ouvrez claude.ai, et vous vous arrêtez. Par où commencer ? Comment ajouter un connecteur personnalisé ? Vous voyez un champ qui attend une URL que vous n'avez pas et ... vous fermez l'onglet. Le lundi, vous reprenez la gestion de votre boutique depuis le back office et l'application Shop Companion, comme d'habitude.

Bonne nouvelle, c'est désormais beaucoup plus simple de brancher Claude à votre app GoodBarber !

GoodBarber figure dans l'annuaire des connecteurs Claude. Vous cherchez « GoodBarber », vous cliquez sur "Connect to Claude", vous vous connectez. La page d'autorisation GoodBarber s'ouvre, vous y collez le jeton Public API créé dans votre back office (Settings > Other settings > MCP Server & Public APIs), et Claude est relié à votre app. Cette connexion de votre app avec Claude fonctionne sur le web, dans l'application de bureau et sur votre téléphone.

Une adresse, ça se copie. Un nom, ça se retient. Et GoodBarber, ça se retient bien :)

Ce n'est d'ailleurs pas une première. Le plugin officiel GoodBarber figure depuis le mois d'août dans l'annuaire de plugins de ChatGPT : on le trouve par son nom, sans mode Développeur, et un compte ChatGPT gratuit suffit. Codex, l'application de développement d'OpenAI, se branche au même serveur en une commande, comme le détaille le guide ChatGPT et Codex.

Revenons au dimanche soir. Votre serveur MCP propose au moment où j'écris 150 outils utilisables sur votre app. Une fois connecté, vous demandez à Claude : « Quels sont les produits que j'ai le plus vendus la semaine dernière ? » Claude lit les statistiques et répond. Les outils de lecture sont sélectionnés et exécutés sans rien demander de plus. La réponse vous permet d'identifier que votre "Slim fit viscose shirt" en rouge est un best seller, mais pas le bleu. Vous décidez de baisser son prix pour booster ses ventes. Vous dites à Claude « Passe le bleu à 29 euros. » Cette fois, Claude s'arrête, reformule votre instruction et vous demande de confirmer. Pourquoi ? Tout simplement parce que chaque outil qui crée, modifie ou supprime quelque chose dans votre back office est identifié comme tel, la question vient donc avant l'action, pas après. Vous confirmez. Le prix change dans l'app en ligne, et Claude vous le relit. Trois phrases, aucun menu de réglages, et la soirée est toujours à vous.

Si vous êtes déjà connecté depuis Codex, Claude Code, Cursor, n8n ou Zapier, il n'y a rien à refaire. Le point d'accès est le même, https://mcp.goodbarber.dev/mcp/sse, les outils sont les mêmes, et le chemin manuel décrit dans le guide MCP fonctionne toujours pour tous les clients qui n'ont pas d'annuaire. Votre jeton vient toujours de votre back office ; révoquez-le et la connexion s'arrête, quel que soit le client qui l'utilise. Et les 44 skills open source (au moment où j'écris ce billet) continuent d'assembler ces mêmes outils en workflows complets.

Qu'est-ce que l'annuaire des connecteurs Claude ?

Un catalogue de serveurs MCP auxquels Claude peut se connecter, commun à claude.ai, à l'application de bureau et à l'application mobile. Y figurer signifie qu'un utilisateur trouve GoodBarber par son nom et l'ajoute depuis la fiche, sans l'URL et sans le formulaire de connecteur personnalisé.

Que peut faire Claude une fois connecté ?

Boutique : produits, variantes, collections, codes promo, commandes. Contenu : articles, événements, lieux, médias. Notifications push, clients et membres, statistiques. Les outils de lecture répondent directement ; les outils qui écrivent demandent d'abord. Tous les serveurs MCP n'exposent pas la même chose : celui-ci expose les opérations de votre app, jamais sa base de données.

Ai-je toujours besoin du jeton Public API ?

Oui. Il se génère dans le back office (Settings > Other settings > MCP Server & Public APIs), et c'est lui qui relie la connexion à votre app et aux droits que vous avez choisis. L'annuaire supprime l'étape de l'URL, pas la clé.

La complexité de connexion n'est plus la raison pour laquelle vous renoncez à piloter votre app avec Claude. La fiche est ici : branchez-vous, et commencez par la question que vous auriez posée à un collègue lundi matin.

Android 17 est sorti le 16 juin 2026 sur les appareils Pixel compatibles, les autres constructeurs suivant au fil des mois.

Android 17 rend l'accès à la position plus visible. Un indicateur permanent apparaît dès qu'une app non système accède à la position d'un utilisateur. Un appui dessus affiche les apps qui l'ont utilisée récemment et permet de gérer les autorisations dans la foulée.

La position approximative devient aussi plus protectrice. Android utilisait jusqu'ici une grille fixe de 2 km ; la zone s'adapte désormais à la densité de population, pour une confidentialité plus homogène en ville comme à la campagne. La fenêtre d'autorisation distingue par ailleurs plus nettement « Précise » et « Approximative ».

De notre côté, le chantier a commencé bien avant la sortie publique : lire la documentation développeur, identifier les changements qui concernent les apps GoodBarber, mettre à jour le moteur Kotlin et tester les versions produites. Nous avions fait de même pour Android 15 et son affichage edge-to-edge, puis pour Android 16 et la navigation predictive back.

Une app Android GoodBarber est compilée nativement, et non enveloppée dans une WebView. Le travail lié au système se joue donc dans le moteur, pas dans le back-office de chaque client. Vous continuez à configurer et à faire vivre votre app ; nous mettons à jour le moteur qui la génère.

Beaucoup de fonctionnalités n'ont besoin de la position exacte qu'au moment où l'utilisateur le demande : recentrer une carte, trouver le lieu le plus proche, valider une action de fidélité sur place. Android 17 introduit un location button affiché par le système pour ces usages ponctuels.

L'utilisateur appuie sur le bouton et accorde la position précise pour la session en cours. L'app n'a pas besoin de conserver une autorisation de position précise permanente pour cette action. Android fournit l'icône et une liste de libellés prédéfinis, si bien que les utilisateurs retrouvent un contrôle identifiable d'une app à l'autre.

Pour les apps ciblant Android 17 ou une version ultérieure, Google Play impose ce bouton lorsque la position précise ne sert qu'à une action ponctuelle déclenchée par l'utilisateur. L'app déclare ce périmètre dans son manifeste, via le flag onlyForLocationButton.

Google Play demande désormais aux apps de s'en tenir au périmètre de localisation minimal dont leurs fonctionnalités ont besoin : l'approximative plutôt que la précise quand c'est possible, et le location button pour un accès précis ponctuel.

Google décrit deux parcours. Pour un accès précis ponctuel, l'app générée déclare dans son manifeste le périmètre restreint du location button. Si une app conserve la position précise en dehors de ce parcours, la Play Console lui demande pourquoi la position approximative ou une demande ponctuelle ne suffiraient pas à une fonctionnalité essentielle.

Le calendrier est court. À partir du 27 octobre 2026, des contrôles préalables dans la Play Console signaleront les problèmes potentiels de politique de localisation avant soumission. La déclaration elle-même devient disponible en novembre 2026. La conformité est obligatoire pour toutes les apps le 27 janvier 2027, avec une extension de 30 jours en libre-service.

La migration du moteur Android est allée plus loin qu'un changement de SDK cible.

Dans le back-office, l'autorisation de localisation se divise désormais en accès approximatif et accès précis, au lieu d'un choix unique du tout ou rien. Quand une app n'a besoin de la position précise que pour une action ponctuelle, la version générée utilise le flag qui signale ce périmètre restreint à Google Play.

Dans l'app, le location button apparaît sur les écrans qui utilisent la position : sections carte, événements, annuaires d'utilisateurs et validation géolocalisée d'une carte de fidélité. Le contrôle étant affiché par le système, son icône et son comportement restent familiers, tandis que son libellé peut correspondre à l'action.

Si un utilisateur n'accorde que la position approximative, l'app continue de fonctionner sans afficher de fausse précision : les distances sont arrondies et présentées comme telles, par exemple « plus d'1 km ».

Deux fonctionnalités GoodBarber conservent la position précise en dehors du parcours du bouton : le géofencing et les beacons. Une notification qui se déclenche quand un client entre dans une zone définie, ou quand son téléphone détecte un beacon, suppose que la position soit disponible sans nouvel appui à cet instant. Le location button ne peut pas s'y substituer.

Ces fonctionnalités donnent à l'éditeur une justification concrète, ancrée dans le produit, à porter dans la Play Console : décrire la fonctionnalité sur laquelle les utilisateurs comptent, et expliquer pourquoi une position approximative ou ponctuelle ne permettrait pas de l'assurer. Google examine toujours la déclaration, mais la raison de conserver la position précise est précise et directement rattachée à une fonctionnalité visible.

Les outils de prompt-to-app sont réellement rapides pour produire une première version. Ce qui se passe ensuite dépend de l'outil et de l'organisation de développement : quand un système d'exploitation évolue, il faut toujours que quelqu'un mette à jour les SDK, teste l'app et soumette une nouvelle version.

GoodBarber est conçu pour le cycle de vie complet d'une app. La maintenance du moteur accompagne les apps natives générées, l'hébergement, la base de données, le back-office et les circuits de publication inclus dans la plateforme — autant de briques qui, ailleurs, correspondent à autant de services et de factures distincts. Une sortie d'Android devient le travail de notre équipe d'ingénierie plutôt qu'un projet de migration pour chaque éditeur.

GoodBarber maintient ses moteurs d'app depuis 2011, pour des clients répartis dans 152 pays. C'est cette expérience qui permet aux apps existantes de générer de nouvelles versions au rythme des évolutions des plateformes mobiles.

Ouvrez votre back-office, générez une nouvelle version de votre app Android et soumettez-la à Google Play. Les changements de moteur y sont déjà.

Si votre app utilise le géofencing ou les beacons, examinez la nouvelle déclaration de localisation dès son apparition dans la Play Console. Décrivez la fonctionnalité dont vos utilisateurs dépendent et expliquez pourquoi une position approximative ou ponctuelle ne permettrait pas de l'assurer.

Vous avez sans doute passé l'été à entendre la même chose : il faut mettre de l'IA dans votre app. Un chatbot, un assistant, un bouton qui brille. Ce qu'on vous dit moins, c'est où le mettre, à quoi il ressemble une fois posé sur un écran, et ce qu'il fait au reste de l'interface.

Je lis chaque semaine ce qui se publie sur le design d'app : les articles de Nielsen Norman Group, UX Collective, Smashing Magazine et Muzli, les notes de version des grandes apps, et les planches publiées sur Dribbble. Voici ce que l'été 2026 a changé, et ce que la rentrée en a déjà confirmé.

C'est la tendance la plus dense de l'été, et elle se lit d'abord sur les écrans. ChatGPT, Grok, Claude, Gemini et Pi s'ouvrent tous sur la même page presque vide : un logo ou une question, un champ de saisie, aucun onglet au premier niveau. Cinq produits, une seule décision. Quand la conversation est le produit, l'interface s'efface derrière elle.

La théorie a suivi. Nielsen Norman Group a posé cinq qualités pour juger un chatbot, et UX Collective a demandé ce qui reste de la métaphore du bureau, les fenêtres, les menus, les dossiers, quand on parle à une app au lieu de la parcourir. Le plus frappant est la relecture de la loi de Jakob, celle qui dit que les usagers passent leur temps sur d'autres produits et attendent donc partout les mêmes conventions. Si tout le monde s'habitue à tout faire depuis une fenêtre de discussion, c'est cette fenêtre qui devient la convention. Les écrans, titrait un autre article, sont rétrogradés.

Puis l'assistant a cessé de répondre pour se mettre à faire. Google Maps réserve un hôtel ou commande un repas sans quitter la carte. Google AI Mode suit le prix d'un vol et réserve sans renvoyer vers un site tiers. Booking.com pose son bouton d'itinéraire par IA au milieu de l'écran d'accueil, pas dans un chatbot séparé. Cloudflare est allé au bout de la logique avec Kitesurf, un navigateur construit pour des agents plutôt que pour des humains.

Le contrepoint est arrivé en même temps, et il tient en une phrase : plus l'IA agit, plus elle doit montrer ce qu'elle fait. Un cadre de permission propose quatre niveaux, automatique, aperçu, confirmation, annulation, selon la réversibilité de l'action, et des apps comme Atoms ou World of Hyatt l'appliquent déjà. DeepSeek, Manus, ChatGPT et Notion affichent leur raisonnement, étape par étape, avant de répondre. L'Europe a précisé qu'une mention IA doit être une vraie étiquette, pas une icône qui scintille.

Et pour votre app. Chez nous, l'assistant qui parle à vos utilisateurs est une section, le chatbot RAG, et il répond avec ce que vous publiez, pas avec la mémoire générale d'un modèle. Il a sa place dans la navigation comme n'importe quelle section. C'est un choix de lecture : dans une app de contenu, l'entrée reste le contenu, et l'assistant vient après.

Plus large, et je l'assume. Rien, cet été, ne prouve qu'une entrée conversationnelle doive remplacer les onglets et les sections qui structurent une app de contenu ou de communauté. Les assistants généralistes ont vidé leur écran d'accueil parce que leur produit est la conversation. Le vôtre, c'est votre contenu. Ce que Google Maps et Booking.com montrent, l'action IA posée dans le parcours plutôt que dans un onglet à part, est la question que ce mouvement nous pose à tous. Je la pose sans la trancher.

Le deuxième mouvement de l'été est moins visible et plus profond. Le design system a changé de nature : ce n'est plus une bibliothèque de composants qu'on consulte, c'est une règle qui gouverne ce que l'IA produit.

Le point de départ est un problème de vitesse. L'IA génère des écrans et du code plus vite que n'importe quelle équipe ne peut les évaluer. Nielsen Norman Group a donné un nom à ce qui s'accumule derrière, la dette UX de l'IA, et décrit des équipes design condamnées à nettoyer en continu. Un design system qui ne sert qu'à vérifier après coup a déjà perdu.

D'où la question qui a occupé les articles de l'été : où vit la vérité d'un composant ? Ni dans Figma ni dans le code, répond UX Collective, mais dans un contrat qui fait autorité pour les deux, parce que deux copies qui dérivent l'une de l'autre ne s'arbitrent plus à la main. Nielsen Norman Group a fourni la grille de lecture avec un référentiel de maturité en six dimensions, un outil d'audit qui mesure la gouvernance et l'adoption autant que la cohérence. Et le procès intenté à Figma sur le consentement des données d'entraînement a rappelé que la gouvernance n'est pas un mot : qui décide des règles, et à qui elles profitent.

Ce contrat a déjà une forme concrète, et elle tient dans un fichier texte. DESIGN.md, publié en open source par Google Labs en avril, décrit les couleurs, la typographie, l'espacement et les composants d'une marque dans un format que les agents de codage lisent avant de générer un écran. Stitch le produit, Claude Code et Cursor le consomment, des plugins Figma le génèrent depuis une maquette, Claude Design en extrait un d'un fichier .fig. L'été a fait de ce fichier le centre de la discussion : un seul fichier standard porte l'identité visuelle, pour les humains comme pour les agents. Le design system n'est plus un livrable, c'est un texte qu'une machine lit avant d'agir.

En deux mois, il est passé de bibliothèque à organisme vivant, et c'est l'IA qui l'a poussé là.

Et pour votre app. Chez nous, la couleur, la typographie, l'espacement, la forme et l'ombre sont définis une fois, comme des rôles, et le moteur les applique directement à chaque écran, sur iOS, sur Android et en PWA. La dérive entre la maquette et le code, celle que le contrat cherche à résoudre, ne se pose pas de la même façon. Ce que vous réglez est ce qui s'affiche.

Plus large, et c'est le vrai sujet. Le vocabulaire du contrat et du fichier unique devient utile le jour où un agent IA externe doit lire les règles d'une marque pour construire quelque chose de correct. C'est exactement la question que pose notre serveur MCP, qui permet aujourd'hui à un agent d'opérer le contenu d'une app, ses articles, ses push, sa boutique, pendant que le design reste dans le builder. Rendre nos règles de design lisibles par une machine est une piste que l'été a rendue plus concrète. Je l'écris comme une piste.

Les deux mouvements de l'été n'ont pas ralenti. L'IA agit maintenant dans le produit sans étape de validation : plusieurs articles racontent la même bascule, un canevas qui agit à partir du contexte sans instructions pas à pas, un ingénieur qui perd le pouvoir de dire qu'une chose est impossible. Une fonctionnalité IA se juge désormais à ce qu'elle fait à la place de l'utilisateur, pas à ce qu'elle lui suggère.

Le design system, lui, est devenu la règle qui encadre l'IA. Tous les outils de génération sortent le même résultat par défaut, une police Inter, un héros centré, un bouton bleu indigo, si personne ne leur donne une règle contraire. La réponse n'est plus un guide de style qu'on relit, c'est un fichier de règles écrit pour être lu par l'IA. Le système gagne en écrivant des règles, pas en publiant des composants.

Deux choses nouvelles sont apparues. La première prolonge le placement : la barre d'assistant s'intègre à l'écran principal. Trois tableaux de bord, comptabilité, gestion d'entreprise, suivi cérébral, posent un champ « demandez n'importe quoi » directement sous les chiffres, sans bouton pour ouvrir un chat séparé, et Notion comme Meta AI ont le même réflexe. L'assistant devient un champ de plus sur l'écran d'accueil, pas une destination.

La seconde va à l'inverse de tout le reste : un mouvement anti-IA. Dezeen recensait cinq objets de design pensés pour résister à l'IA, dont une police conçue pour tromper le scraping automatique. Une fatigue nette, encore réservée aux créateurs. Reste à voir si elle infuse jusqu'aux produits grand public.

Cette section n'a pas de lien avec notre produit et n'en cherche pas. C'est mon regard de designer sur ce que la saison installe côté couleur.

Pantone a retenu Cloud Dancer, un blanc cassé aérien, et c'est la première fois que la couleur de l'année est un blanc. Le milieu l'a accueilli froidement, ce qui se comprend : une couleur de l'année sert d'abord à être vue. Sa gamme automne-hiver dit pourtant la même chose autrement, en opposant quatre terreux, argile éteinte, épice, acajou, olive brûlée, à quatre saturés que rien n'adoucit. Les premiers tiennent les surfaces, les seconds tiennent les points d'appui. Ce qui bouge en ce moment n'est pas l'accent, c'est le fond sur lequel on le pose.

Le référentiel que je regarde le plus pour l'écran vient de WGSN et Coloro, parce qu'il vise plus loin. Après Transformative Teal, il annonce Luminous Blue, un cobalt de la famille du lapis, puis Radiant Earth, un rouge terreux posé non comme un accent mais comme un neutre. Un rouge sur lequel on bâtit une interface entière, pas seulement un bouton : c'est ce geste-là qui compte.

Côté écran, le mouvement le plus net est la fin du noir pur en mode sombre. Le #000 est dur et laisse des traînées grises au défilement sur les dalles OLED. À sa place, des fonds ambiants profonds, bleu nuit, vert forêt, charbon, parfois modulés selon l'heure. Le blanc pur recule de la même façon devant des neutres réchauffés, et chaque couleur doit désormais exister en clair, en sombre et en contraste élevé : celle qui n'a qu'une version casse dès que l'utilisateur change de mode.

Deux courants sortent du rang. Les palettes générées par IA proposent des associations qu'un humain n'aurait pas tentées, sauge avec mauve et bleu acier, et certaines tiennent debout. À l'inverse, un néo-brutalisme assumé revient sur les apps qui cherchent à ne ressembler à aucune autre, en fintech et dans le Web3.

Quatre palettes m'ont paru utilisables telles quelles, chacune avec ce à quoi elle sert.

Un dernier point, et c'est celui qui s'applique demain matin. Les accents terreux passent rarement le rapport de contraste de 4,5:1 sur un fond crème : gardez-les pour les surfaces et les bordures, jamais pour du texte. Et sur mobile, montez le contraste de vos boutons d'action au-dessus de ce minimum, parce que le contraste perçu s'effondre en plein soleil. Une couleur validée sur votre écran peut être illisible dans la rue.

La barre d'assistant intégrée à l'écran d'accueil va-t-elle remplacer le bouton de chat séparé ? Le placement a gagné chez Google Maps, Booking.com et Notion. Reste à savoir si les apps qui ne sont pas des assistants suivent, ou si le champ « demandez n'importe quoi » reste l'apanage des tableaux de bord.

L'exécution directe par l'IA, réserver, commander, suivre un prix, va-t-elle réclamer un nouveau pattern de confirmation avant l'action ? Le cadre à quatre niveaux existe. Reste à voir qui l'adopte au moment où l'action devient irréversible.

L'obligation européenne d'étiquetage IA va-t-elle s'étendre aux outils IA internes, au-delà des générateurs d'images ? La question se pose pour toute app dont un contenu généré touche un utilisateur final.

Ces trois questions ont une échéance, l'automne, et la première nous concerne autant que les autres. D'ici là, si vous ne retenez qu'une chose de cet été pour votre app : une fonctionnalité IA se juge à ce qu'elle fait pour vos utilisateurs, pas à ce qu'elle brille. Chez nous, aujourd'hui, elle répond avec ce que vous publiez. Ce que l'automne dira, c'est où elle devra se poser.

Prompt teardown, épisode 4. La série où l'on décortique des prompts de l'AI Extension Builder pour lire ce qu'ils déclenchent vraiment : ce que chaque phrase obtient, les choix que la génération fait sans qu'on les lui dicte, ce que la section sait faire une fois en place. Aujourd'hui : un seul prompt, collé à l'identique dans deux apps démo fictives — et une question qu'on ne lui a jamais posée : à quoi la section doit-elle ressembler ?

La section demandée s'appelle « Today & tomorrow » : le programme des deux jours qui viennent, lu dans l'agenda de l'app, entre lequel on navigue d'un onglet ; on épingle ce qu'on ne veut pas rater, et l'app retient cette sélection d'une visite à l'autre. Le prompt — il est en fin d'article — décrit cet usage, et rien d'autre. Relisez-le : il ne contient pas un mot sur l'apparence.

On l'a collé dans deux apps construites pour se tourner le dos. « Pastries' House », pâtisserie fictive : fond crème, typo toute en rondeurs, rose bonbon et chocolat. « Radio Alba », radio locale fictive : écran nuit, titres blancs, ambre et rouge. Si la génération n'avait que le prompt pour travailler, les deux sections devraient sortir identiques.

Chez « Pastries' House », la section arrive en crème : cartes blanches posées sur le fond de l'app, heures dorées, épingles et onglets rose bonbon — deux pilules arrondies, « Today » et « Tomorrow », qui reprennent la grammaire de la barre de navigation. Les événements affichés sont les vrais : les fournées et les ateliers saisis dans l'agenda de l'app, avec leurs vignettes. La sélection épinglée s'installe en bas, dans un bandeau « Pinned for later » — et comme elle n'appartient qu'au visiteur, elle vit sur son téléphone, retrouvée à chaque visite, sans compte ni question posée.

Chez « Radio Alba », même prompt, autre tempérament. La section sort en sombre : cartes anthracite, dates et heures en ambre, l'onglet actif en rouge — les accents de la radio, pas ceux de la pâtisserie. Et ce n'est pas la même section repeinte : la mise en page change aussi. L'heure s'aligne à droite de la carte, les deux onglets se logent dans un sélecteur compact, la carte entière répond au doigt pour épingler. Jusqu'au sous-titre, écrit par la génération et différent d'une app à l'autre : « What's happening now and next » ici, « See what's on, and keep a short list… » là-bas.

Deux apps, deux habillages, deux interprétations — et toujours zéro consigne de style dans le prompt.

Le prompt que vous écrivez n'est pas le seul texte que la génération reçoit. À chaque demande, la plateforme y joint la fiche d'identité visuelle de votre app : sa palette, rôle par rôle — le fond, les surfaces, la couleur des actions, celle des titres, les séparateurs — avec une consigne simple : la section doit avoir l'air née dans cette app. C'est pour cela que le rose bonbon se retrouve sur les épingles de la pâtisserie et le rouge sur l'onglet actif de la radio : chacune a lu sa propre fiche.

Dans l'article qui présentait l'AI Extension Builder, Jerome le disait d'une phrase : le style global de l'app — couleurs, espacements, contrastes — suit automatiquement. La partie invisible du prompt, c'est exactement ça. Et elle ne s'arrête pas au style : quand votre description cite une section de l'app par son nom — ici « Events » —, la génération reçoit aussi de quoi la lire. C'est pour cela que le programme affiché est le vrai, vignettes comprises.

Et si vous deviez maintenir le code vous-même ? Ce travail-là a un nom : une charte graphique à transcrire en variables, chaque composant à passer en revue, et tout à repasser au premier changement de charte. Ici, il est refait à chaque génération — sans occuper une ligne de votre prompt. Collez demain le même prompt dans une troisième app : c'est sa fiche à elle que la génération lira.

Tout ne suit pas le design de l'app, et c'est voulu. La typo signature de la pâtisserie — ces titres gourmands, tout en rondeurs — reste aux écrans natifs ; les sections générées écrivent dans la police du système, le registre natif de chaque téléphone, lisible partout. Même chose pour le socle : tailles tactiles confortables, contrastes suffisants, états de chargement et écrans vides prévus d'office. Cette part-là ne se négocie pas dans le prompt — elle protège la section, et vos utilisateurs, quelle que soit l'app.

Le plus parlant est de mettre côte à côte deux écrans de la même app : l'agenda natif de la pâtisserie — bannières roses, typo maison — et la section générée. Mêmes contenus, mêmes vignettes, deux registres typographiques — et une seule maison.

Le voici tel qu'il a été collé, deux fois, sans une ligne de plus :

Entre les deux résultats, pas un caractère du prompt n'a changé. Seule l'app a changé — et c'est elle qui a fait tout le style.

Prenez ce prompt, remplacez « Events » par le nom d'une section de votre app, et collez-le : la section sortira chez vous, à vos couleurs. Puis faites l'exercice inverse : demandez un écart volontaire — un bouton d'épinglage impossible à manquer, un encart qui tranche avec le reste — et regardez ce qui bouge, et ce qui tient. C'est la meilleure façon de sentir où finit votre prompt et où commence ce que la plateforme lit toute seule.

Le premier épisode de la série décortiquait une section qui retient une place de parking et va chercher le GPS et Maps du téléphone : Prompt teardown : GPS, mémoire et Maps à partir d'une seule phrase. Et le quiz d'été de la série voisine montrait déjà le même réflexe : généré dans une app, habillé par elle.

L'AI Extension Builder est en bêta, ouvert à tous : créez une app avec GoodBarber et décrivez votre première section.

Faut-il décrire le design de son app dans le prompt ?

Non. La palette de l'app est lue à chaque génération, sans que vous ayez à la rappeler : décrivez l'usage, le style suit. Si vous voulez orienter l'apparence — une ambiance, un détail qui compte pour vous —, dites-le comme le reste : votre description reste la spécification.

Que devient la section si je change ensuite le design de l'app ?

L'habillage d'une section est posé au moment où elle est générée. Après une refonte de votre thème, demandez simplement une itération — « harmonise la section avec le nouveau design » — et la génération relit la fiche de l'app, mise à jour.

Peut-on vouloir une section qui tranche avec le reste de l'app ?

Oui. L'écart voulu se décrit comme n'importe quelle exigence : un encart promotionnel qui doit contraster, un bouton qui doit dominer l'écran. La génération part toujours de l'identité de l'app — c'est votre phrase qui définit l'écart, et le socle de lisibilité reste en place.

Pourquoi la section n'utilise-t-elle pas la police de mes titres ?

Les sections générées écrivent dans la police du système du téléphone : le registre des interfaces natives, lisible et cohérent sur iOS comme sur Android. Votre typo signature reste celle de vos écrans natifs — les deux cohabitent dans la même app, chacune à sa place.