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.

La série « Volez cette idée » : une section d'app qu'on décrit à l'AI Extension Builder, qu'on construit pour de vrai, et dont on vous livre le prompt complet à la fin, prêt à coller. Après le quiz ciné de l'été et le compte à rebours de la reprise du club de sport, direction la salle : le défi de la rentrée.

Chaque matin, une seule chose à faire. La carte du jour affiche l'action — Go to bed 30 minutes earlier tonight., Take a 10-minute walk after lunch. — un geste qui tient dans une journée normale, sans matériel et sans chrono. On appuie sur Mark done today, la série s'incrémente, et la carte change d'état : Done for today — come back tomorrow. Le bouton se verrouille jusqu'au lendemain. C'est toute l'idée : on ne peut pas « avaler » le défi un dimanche soir — une action par jour de calendrier, et le rendez-vous se recrée chaque matin.

En dessous, la vue mensuelle aligne les trente cases : les jours faits se remplissent, celui du jour est cerclé. Appuyer sur un jour coché réaffiche son action et sa date. Et la section se souvient : l'adhérent ferme l'app, revient le lendemain, tout l'attend — sa série, ses coches, son jour en cours — sur son téléphone, sans compte à créer et sans rien à administrer côté accueil.

Studio Forma, la salle de ces captures, est inventée pour l'exemple — tout ce qu'on y voit est fictif.

Le bénéfice n'est pas la prouesse technique, c'est le calendrier : un défi de trente jours, ce sont trente ouvertures d'app par adhérent. Une affiche à l'accueil se lit une fois ; un message dans le groupe de discussion se noie le jour même. Une action qui se débloque chaque matin, elle, installe une habitude — et l'habitude, c'est précisément ce que vend une salle de sport en septembre.

La douceur n'est pas un supplément d'âme, c'est le mécanisme. Marcher vingt minutes, s'étirer cinq, poser une bouteille d'eau sur le bureau : des actions si simples qu'on les fait vraiment — et chaque case cochée donne envie de la suivante. La bannière de la section donne le ton d'elle-même : Build gentle momentum, one day at a time. Aucune promesse de résultat, aucune intensité imposée : chacun adapte ou saute ce qui ne lui convient pas, et le défi reste un plaisir plutôt qu'un reproche.

Quant à la vue mensuelle, c'est le tableau de fierté : à mi-parcours, une grille à moitié remplie dit mieux que n'importe quelle relance « continue, ça tient ».

Regardez la capture : six jours faits, un dimanche sauté — la série affiche toujours 6, et propose simplement l'action suivante. C'est un choix de conception, écrit noir sur blanc dans le prompt : rater un jour met la série en pause, ne l'efface jamais. Le défi attend, et reprend là où l'adhérent l'a laissé.

Même logique au départ : le jour 1, c'est la première action cochée, quelle que soit la date. Celui qui découvre le défi le 10 septembre n'a pas neuf jours de retard — il a son jour 1 devant lui. Personne n'est disqualifié d'avance, et c'est exactement ce qu'on demande à un défi de rentrée : ramener les gens, pas les trier.

Si vous préférez la version stricte — une série qui retombe à zéro au premier jour manqué — c'est une phrase à changer dans le prompt. Nous assumons la version douce : elle correspond mieux à ce qu'une salle veut dire à ses adhérents en septembre.

Le prompt complet est plus bas. Si vous l'adaptez, quatre phrases portent l'essentiel — gardez-les.

1. « Only one action can be completed per calendar day […] the check-off button stays disabled until the calendar date changes at local midnight. » La règle qui fabrique le rendez-vous quotidien. Sans elle, le défi se coche en une soirée et l'app ne revoit personne.

2. « Day 1 is the member's first completed action, whatever the date. » Le départ libre. Le numéro du jour et la date du calendrier sont deux choses différentes — cette phrase le dit au générateur, et vos adhérents en profitent : chacun démarre quand il veut.

3. « Missing a day pauses it, but it never resets and past progress is never erased. » La douceur, codée. La série attend au lieu de punir.

4. « When the 30th action is completed, a congratulations screen takes over from the daily card. » La fin remplace l'invite quotidienne — pas de « revenez demain » une fois le défi bouclé.

Dernier détail : le prompt annonce I will provide the list of 30. La génération pose d'abord des actions d'exemple ; votre liste arrive juste après, en second message, et elle est reprise mot pour mot — majuscules et ponctuation comprises. Écrivez chaque ligne exactement comme vous voulez la lire à l'écran.

Pas une ligne de code derrière cette section : un brief, remis à l'AI Extension Builder. Le voici en entier.

Quand la section est générée, envoyez la liste en second message. Voici la nôtre — trente gestes doux autour de la marche, des étirements, de l'eau et du sommeil, écrits pour tenir dans une journée normale. Volez-la telle quelle, ou réécrivez-la avec vos cours et vos habitudes de salle : gardez juste la douceur.

Le jour 30 ne demande pas un exploit : il invite à choisir l'action qu'on garde, et à passer le dire à l'accueil. C'est la boucle complète — l'app ramène à la salle.

Une section générée se vérifie comme on vérifie une recrue : on lui fait faire le geste une fois. Cochez l'action du jour — la carte doit passer en Done for today et le bouton se désactiver. Rouvrez la section : toujours verrouillée. Avancez d'un jour la date de votre téléphone, le temps du test : l'action suivante doit s'offrir, la série avoir grandi. Trente secondes, et vous savez que le rendez-vous quotidien tiendra un mois.

Si votre génération laisse passer deux coches le même jour, inutile de repartir de zéro ni de réécrire le prompt : demandez la retouche en décrivant ce que vous constatez et ce que vous attendez. Voici la nôtre, prête à coller :

La recette vaut pour n'importe quelle retouche d'une section générée : le symptôme constaté, le comportement attendu, et le mot qui lève l'ambiguïté — ici, « aujourd'hui », qui désigne la date du calendrier et jamais le numéro du jour. C'est un réflexe qui rend service bien au-delà de ce défi.

Et mesurez ce que ces trente secondes remplacent. Un verrou quotidien, si vous deviez maintenir le code vous-même, c'est un état daté qui survit aux visites, un passage de minuit à gérer, une annulation qui ne défait que le jour même — le genre de détail qui occupe une soirée et se re-teste à chaque retouche. Ici, il se décrit en une phrase du prompt, se vérifie en trente secondes, et s'ajuste en une autre phrase.

Quand la trentième action est cochée, la carte quotidienne s'efface et laisse place à l'écran de félicitations : Challenge complete — 30 of 30 done. La série affiche 30, la barre de progression est pleine, et il n'y a plus de « revenez demain » : le défi se termine, proprement.

C'est le bon moment pour donner suite — dans la vraie salle d'abord (le jour 30 y envoie de lui-même), puis dans l'app : en janvier, le même prompt et trente nouvelles lignes suffisent à générer le défi suivant. Le squelette ne bouge pas ; vos trente lignes, si.

Une action par jour, une série qui grandit, un verrou calendaire : la mécanique dépasse largement le fitness. Un studio de yoga en fera un mois de respiration, une école de musique trente jours de pratique, une médiathèque un défi lecture, une boutique un calendrier de l'avent en décembre. Partout où l'on veut transformer une bonne résolution en habitude — et une app en rendez-vous quotidien.

Pour ce studio de yoga justement, voici comment monter l'application qui portera ce mois de respiration : créer une application de yoga pour vos élèves.

• Prompt teardown : GPS, memory, and Maps from a single sentence — la série sœur : on prend un prompt et on l'explique ligne par ligne.
• L'AI Extension Builder — décrivez une section, obtenez-la dans votre app.
• Pour les curieux d'ingénierie (en anglais) : We let an AI write code inside our no-code platform. Generating it was the easy part. — les coulisses, sur dev.to.

Le défi de la rentrée n'est qu'un point de départ. Le mois sans sucre de la diététicienne, les trente jours d'écriture de l'atelier, le défi photo du club — décrivez la section comme vous brieferiez un coach : le rythme, la règle du jour manqué, ce qui doit rester vrai quoi qu'il arrive. Si ça se décrit, ça peut être une section de votre app : créez une app avec GoodBarber.

Que se passe-t-il si un adhérent rate un jour ?

Rien d'irréversible : la série se met en pause et l'attend. Sa prochaine visite lui propose simplement l'action suivante, et rien de ce qui est fait n'est effacé. C'est le réglage que nous avons choisi pour une rentrée en douceur — si vous préférez une série stricte qui retombe à zéro, c'est une phrase à changer dans le prompt.

Un adhérent peut-il rattraper plusieurs jours d'un coup ?

Non, et c'est voulu : une action par jour de calendrier, c'est la règle qui crée le rendez-vous quotidien. Après la coche du jour, le bouton se verrouille jusqu'au lendemain — c'est la première chose à vérifier avant d'annoncer le défi.

Chaque adhérent a-t-il son propre défi ?

Oui. La liste des trente actions est commune — c'est vous qui l'écrivez. La progression, la série et l'écran final sont personnels : chacun coche sur son téléphone, sans compte à créer.

Peut-on changer une action en cours de défi ?

Oui, en une phrase de retouche. Nous l'avons fait pendant la construction : remplacer la liste n'a pas touché aux jours déjà cochés par nos testeurs.

Peut-on relancer le défi en janvier ?

Le plus simple : générez la section de janvier avec le même prompt et trente nouvelles lignes — quelques minutes, et le défi repart de zéro. Le squelette resservira autant de fois que vous avez de bonnes résolutions à proposer.

Les stores n'ont pas pris de vacances, commencez donc par les rattraper. Apple et Google durcissent leurs exigences chaque année : niveaux d'API cibles, règles de confidentialité, échéances de SDK. Une application qui ne bouge pas ne reste pas identique, elle dérive lentement hors des clous, et l'essentiel des dégâts est invisible jusqu'au jour où il devient coûteux. Nous avons détaillé ce qui casse en silence quand vous ne mettez pas à jour votre application, et la version courte est : recompilez et resoumettez avant que les stores ne décident à votre place.

Si votre application tourne sur GoodBarber, l'essentiel de cette maintenance s'est fait cet été sans que vous vous en aperceviez, et c'est exactement le but. Ouvrez tout de même vos consoles de stores une fois, pour vérifier que rien ne vous attend.

Rien ne dit « application à l'abandon » comme une bannière de soldes d'été en septembre. Faites sortir la saison : mettez à jour vos sections d'accueil, archivez les promos de juillet, remplacez les photos de plage et rafraîchissez tout ce qui porte une date.

Si vous vendez via votre application, c'est aussi le moment de charger les offres de rentrée et de revérifier chaque prix avant l'arrivée du trafic d'automne. Avec un vrai CMS derrière votre application, c'est le point le plus rapide de toute la liste : quinze minutes, grand maximum.

Certains de vos utilisateurs n'ont pas ouvert votre application depuis juin, et une notification push bien envoyée reste le moyen le moins cher de les faire revenir. Prévoyez une campagne de réengagement début septembre, et rendez-la utile plutôt qu'insistante : ce qui est nouveau, ce qui arrive cet automne, ce qu'ils ont manqué. Un push pertinent vaut mieux que cinq push génériques.

Si vous proposez des abonnements ou du contenu premium, associer notifications push et système d'abonnements est l'une des combinaisons au meilleur levier : les personnes les plus susceptibles de revenir sont celles qui se sont déjà engagées une fois.

Septembre amène une vague de nouveaux utilisateurs, et les nouveaux utilisateurs se font une opinion très vite. Faites donc le test que tous les créateurs sautent : téléchargez votre propre application comme si vous ne l'aviez jamais vue. Le premier écran se comprend-il tout seul ? L'inscription est-elle aussi courte que possible ? L'application montre-t-elle sa valeur avant de demander quoi que ce soit ?

Chaque friction supprimée maintenant sera multipliée par tous les nouveaux arrivants du Q4. Une heure au calme dans l'app builder à réordonner vos premiers écrans est l'un des meilleurs retours sur temps du mois.

Votre fiche sur les stores est une vitrine, et il se peut qu'elle soit encore habillée pour juillet. Vérifiez vos captures d'écran : montrent-elles vos contenus actuels et vos meilleures fonctionnalités ? Relisez votre description : la première ligne dit-elle ce que fait l'application et à qui elle s'adresse ? Repassez sur vos mots-clés : sont-ils les termes que les gens taperont cet automne ?

L'App Store Optimization n'est pas un réglage à faire une fois, c'est un entretien saisonnier. Notre guide ASO pour augmenter vos téléchargements passe chaque élément en revue. Si vous ne faites qu'une chose, refaites les captures d'écran : ce sont elles qui convainquent.

Le Black Friday s'exécute en novembre mais se gagne en septembre. Si vous gérez une application ecommerce, esquissez votre calendrier de promotions maintenant, pendant qu'il reste du temps pour tout tester calmement.

Deux mécanismes méritent d'être armés tôt. Un programme de fidélité a besoin de quelques semaines de fonctionnement avant les fêtes pour paraître naturel à vos utilisateurs. Et les e-mails de panier abandonné ont pratiquement été inventés pour l'acheteur du Black Friday qui s'éclipse en plein paiement. Configurez-les en septembre et ils feront tranquillement leur travail quand le rush arrivera.

L'été a été une expérience naturelle : votre application a tourné avec moins de marketing que d'habitude, donc ce que les gens ont utilisé, ils l'ont utilisé d'eux-mêmes. Ce signal vaut de l'or. Quelles sections ont gardé leur audience en août ? D'où sont venus les nouveaux utilisateurs ? À quoi ressemblait la rétention quand vous ne regardiez pas ?

Nous avons listé les données à suivre pour mieux décider si vous voulez un cadre complet. La version pratique : choisissez la métrique que vos données d'été désignent comme la plus prometteuse, et faites-en votre unique priorité de l'automne.

Si une application attend toujours sur votre liste « un jour », c'est le meilleur mois pour vous lancer. Lancez en septembre et vous aurez octobre pour apprendre et ajuster : votre application abordera le Q4 rodée plutôt que toute neuve. Attendre novembre, c'est déboguer votre lancement pendant vos semaines les plus chargées.

Si vous avez passé l'été à comparer les outils gratuits, commencez par notre bilan honnête de ce que les app builders gratuits incluent réellement, puis regardez ce que « gratuit » veut vraiment dire chez GoodBarber : la plateforme complète, gratuite pendant 30 jours, sans carte bancaire. Et quand vous serez prêt, la page de tarifs est sans astérisque.

Bonne rentrée. Votre application est prête pour son meilleur trimestre.

TL;DR : vous pouvez créer et prévisualiser une application gratuitement avec plusieurs outils no-code. Publier une application native sur l'App Store et Google Play exige une offre payante chez tous les grands app builders, plus deux frais qu'aucun éditeur ne peut supprimer : le compte développeur Apple à 99 $ par an et l'inscription unique à Google Play à 25 $. Les offres gratuites sont réellement utiles pour valider une idée. Elles ne permettent pas de faire tourner une application en production.

Oui, vous pouvez créer une application gratuitement. Non, vous ne pouvez pas la publier gratuitement. Toute l'histoire tient dans cette distinction.

Les offres gratuites du marché no-code couvrent le même périmètre : vous concevez votre application dans un éditeur, vous la prévisualisez sur votre téléphone et, dans certains cas, vous la partagez sous forme d'application web portant la marque de l'outil. Dès que votre application doit atteindre de vrais utilisateurs, trois portes se ferment en même temps : la publication sur les stores, la suppression du badge de l'éditeur et l'envoi de notifications push. Ce sont des fonctionnalités payantes partout, et il y a une raison à cela : la soumission aux stores, l'hébergement et la compilation native représentent des coûts réels et récurrents pour la plateforme.

Même Adalo, qui vend pourtant sa propre offre gratuite, l'écrit noir sur blanc dans son comparatif des app builders gratuits (mars 2026) : « publier sur l'App Store d'Apple ou sur Google Play nécessite toujours une offre payante ».

Nous avons vérifié les pages de tarifs publiques des principaux app builders gratuits le 26 août 2026. Voici ce que chaque offre gratuite inclut, fonctionnalité par fonctionnalité.

Deux choses ressortent de ce tableau. D'abord, les offres gratuites sont cohérentes entre elles : créer oui, publier non. Ensuite, nous avons placé GoodBarber dans la même colonne « Non » que tous les autres pour la publication native gratuite, parce que c'est la vérité. Personne ne publie d'applications natives gratuitement. Toute page qui suggère le contraire décrit un aperçu, pas un lancement.

Avant de comparer les outils, budgétez les frais qui existent quel que soit celui que vous choisirez. Selon la page du programme développeur d'Apple (2026), un compte développeur coûte 99 $ par an. Selon les conditions de la Console Google Play (2026), l'inscription coûte 25 $, une seule fois.

Ces frais sont le moyen pour les stores de vérifier qu'un éditeur réel et identifiable se tient derrière chaque application. Une agence les paie, un fondateur solo les paie, un utilisateur no-code les paie. Un app builder qui cache ces montants derrière le mot « gratuit » ne ment pas, à proprement parler. Il vous laisse découvrir votre première facture par vous-même.

Il existe un troisième coût qu'aucune page de tarifs n'affiche : votre temps. Reconstruire votre application sur une deuxième plateforme parce que la première ne pouvait pas publier est le scénario le plus coûteux de tous. Mieux vaut savoir où s'arrête une offre gratuite avant de commencer, pas après.

Une offre gratuite est le bon choix plus souvent qu'un vendeur d'offres payantes ne devrait sans doute l'admettre. Si vous voulez vérifier que votre idée tient la route sur un écran de téléphone, une offre gratuite vous donne cette réponse pour un risque exactement nul. Si vous êtes en train d'apprendre comment raisonnent les éditeurs no-code, une offre gratuite est un professeur patient. Si votre projet ne doit jamais toucher qu'une poignée de collègues via un lien partagé, une application web gratuite peut suffire, et vous n'avez aucune raison de payer davantage.

Le test honnête tient en une seule question : cette application doit-elle être présente sur l'App Store et Google Play, à mon nom, avec des notifications push ? Si la réponse est non, utilisez une offre gratuite et gardez votre argent. Si la réponse est oui, une offre payante vous attend chez tous les app builders du marché, et la vraie comparaison porte sur ce que chaque offre payante inclut pour son prix.

GoodBarber a fait le pari inverse : au lieu d'une offre gratuite limitée pour toujours, vous obtenez la plateforme complète, gratuite pendant 30 jours, sans carte bancaire. Toutes les fonctionnalités natives, les outils de design, le e-commerce, les notifications push, tout. Pendant l'essai, vous pouvez même publier une PWA gratuite pour mettre votre projet devant un vrai public. À la fin des 30 jours, rien n'est débité, puisque nous n'avons jamais demandé de carte : soit vous choisissez une offre, soit vous repartez avec votre évaluation terminée.

Nous préférons ce modèle pour une raison qui n'a rien à voir avec la générosité. Une offre gratuite limitée vous montre un produit limité, et la frustration sert d'argument de vente. Un essai complet vous montre le vrai produit, et le produit sert d'argument de vente. Après 15 ans passés à construire cette plateforme (depuis 2011), la seconde option nous convient très bien.

Une dernière différence mérite d'être nommée, parce qu'elle change le coût total : une offre GoodBarber est tout compris. L'hébergement, les mises à jour, les notifications push, les statistiques et le support font partie de l'offre, ils ne sont pas vendus comme des abonnements séparés à empiler. Quand vous comparez les offres payantes des différents app builders, comparez la pile complète que vous paierez réellement, pas le prix mis en avant. Nos tarifs sont publics, et nous avons écrit une page honnête sur ce que le gratuit inclut vraiment si vous voulez la version résumée.

Puis-je créer une application sans rien payer du tout ?

Vous pouvez la créer et la prévisualiser, oui. Avec GoodBarber, l'essai de 30 jours vous donne la plateforme complète sans carte bancaire. Publier une application native sur les stores exige une offre payante chez tous les grands app builders, plus les frais propres à Apple et Google.

Existe-t-il un moyen de publier une application 100 % gratuitement ?

En PWA, oui : une progressive web app vit sur le web et s'installe depuis le navigateur, sans passer par les stores. GoodBarber vous permet de publier une PWA gratuite pendant l'essai. La publication native gratuite sur les stores n'existe pas sur le marché.

Pourquoi toutes les offres gratuites bloquent-elles la publication sur les stores ?

Parce que la publication concentre les vrais coûts de la plateforme : builds natifs, conformité aux règles des stores, hébergement, mises à jour. Les offres gratuites existent pour vous laisser évaluer l'éditeur de création, et elles s'arrêtent là où commencent les coûts du fournisseur.

Combien coûte le lancement réel le moins cher ?

Additionnez trois montants : la première offre payante de votre app builder, les 99 $ par an d'Apple si vous visez l'App Store, et les 25 $ versés une seule fois à Google Play. C'est ce total, pas le mot « gratuit » sur une page d'accueil, qui constitue le plancher honnête pour publier une application.

Un app builder gratuit suffit-il pour une entreprise ?

Pour valider une idée, absolument. Pour faire tourner une activité, rarement : la présence sur les stores, les notifications push et votre propre marque sont précisément les fonctionnalités que les offres gratuites bloquent, et ce sont elles qui rendent une application utile à vos clients. Nous disons cela tout en vendant l'alternative, à vous de le pondérer : notre meilleur argument est l'essai de 30 jours, pas ce paragraphe.

Envie de voir ce que la plateforme complète fait de votre idée ? Démarrez votre essai gratuit de 30 jours : toutes les fonctionnalités, aucune carte bancaire, et une réponse claire à la fin.

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

Commençons par ce qui distingue ce sujet de tous les autres de cette série. Quand iOS ou Android évolue, des fonctions peuvent cesser de répondre — c'est un problème technique, il se répare techniquement. Une règle des stores, elle, ne casse rien : votre app peut fonctionner parfaitement, chez vous comme chez vos utilisateurs, et être bloquée à la porte. Car les stores ne sont pas des étagères où l'on pose une app : ce sont des portes gardées. Rien n'atteint les utilisateurs sans passer une revue, et cette revue applique les règles du jour.

C'est une menace d'une autre nature. Elle ne se manifeste pas par un dysfonctionnement, mais par un refus, une exigence nouvelle, une case à remplir qui n'existait pas. Et elle a sa langue à elle : celle des juristes et des développeurs mélangés, dans laquelle il faudrait d'abord comprendre si l'on est concerné avant même de savoir quoi faire.

Regardez ce que les stores demandent, et un motif apparaît : leurs règles ne portent pas que sur ce que votre app fait — elles portent tout autant sur ce qu'elle déclare, demande et montre.

Ce qu'elle déclare. Quelles données elle collecte, pour quoi faire, avec qui elle les partage, à quel public elle s'adresse. Les stores exigent que la fiche dise la vérité sur l'app — et cette exigence s'épaissit d'année en année.

Ce qu'elle demande. Une permission — position, photos, micro — ne peut plus simplement être prise : il faut la demander au bon moment, pour une raison affichable, et pouvoir la justifier.

Ce qu'elle montre. Contenu, achats, prix : ce que l'app propose doit correspondre à ce qui est annoncé, et respecter ce que le store accepte de distribuer.

Ajoutez la propriété que les éditeurs découvrent souvent trop tard : ces règles s'appliquent au moment où une mise à jour se présente. Une app est examinée aux règles d'aujourd'hui, pas à celles sous lesquelles elle est née. Sur ce que cela fait, avec le temps, à une app qu'on ne met plus à jour, Pierre-Laurent a écrit l'inventaire de référence ; je n'y reviens pas.

Puisque les règles parlent de conformité plus que de code, le travail de la plateforme ne ressemble pas à de la réparation — il ressemble à de la jurisprudence.

Suivre ce que les stores publient, et surtout ce qu'ils se mettent à exiger en pratique : une revue est faite par des personnes, et la lettre d'une règle ne dit pas toujours comment elle sera appliquée. Soumettre des apps en continu, c'est accumuler précisément ce savoir-là — quelles formulations passent, quelles déclarations sont attendues, qu'est-ce qui déclenche une question de l'examinateur. Puis traduire tout cela, une fois, dans la façon dont les apps sont construites et présentées aux stores, pour que chaque app en hérite sans s'en occuper.

Le contrepoint, en une phrase cette fois : si vous mainteniez votre app seul, cette jurisprudence serait à reconstituer par vous, refus après refus — car c'est ainsi qu'on l'apprend, quand personne ne l'a apprise avant vous.

Et la nuance honnête de toute cette série vaut ici plus qu'ailleurs : une revue garde une part d'appréciation. Le travail en amont rend les refus rares sur la partie technique et déclarative ; il ne transforme pas l'examen en formalité.

La carte complète de qui s'occupe de quoi est dans le premier article ; pour les règles des stores, elle tient en deux lignes — mais ces deux lignes sont le cœur du sujet, précisément parce que les règles parlent de vous.

Votre compte développeur. Votre app est publiée sous votre nom — c'est ce qui fait qu'elle vous appartient — et c'est donc à vous que les stores s'adressent officiellement. Ce compte se renouvelle, et il est la porte par laquelle toute mise à jour passe.

Les réponses qui portent sur votre activité. Quand une règle pose une question sur votre contenu — quelles données collectez-vous, à quel public vous adressez-vous, que vendez-vous —, la réponse ne peut venir que de vous. C'est la conséquence logique de tout ce qui précède : les stores veulent que l'app dise la vérité sur elle-même, et cette vérité-là est la vôtre.

Et si même cette part-là vous pèse, GoodBarber Takes Care est le service où notre équipe s'occupe de la soumission aux stores pour vous.

Voilà ce que tout cela change, concrètement. Quand vous publiez, votre app passe un examen dont le programme a changé depuis la dernière fois — il change toujours. Mais elle ne s'y présente pas seule : elle arrive construite et présentée selon ce que les stores exigent ce jour-là, portée par l'expérience de toutes les soumissions qui ont précédé la vôtre. Vous n'avez pas révisé ; l'app arrive préparée. Préparée, pour autant, ne veut pas dire pré-approuvée : la décision, à la porte, appartient à Apple et à Google, et à personne d'autre — aucune plateforme ne peut la promettre en leur nom, et aucune ne le devrait. Ce que la préparation change, c'est tout ce qui dépend de la préparation ; la décision elle-même, c'est précisément à cela que sert une revue.

Les règles des stores continueront de changer au même rythme, et de se durcir dans le même sens. La différence n'est pas qu'elles vous épargnent — c'est qu'elles cessent d'être votre lecture du soir.

Pour la version ingénierie — ce que trois ans de règles et de systèmes font réellement à une app —, j'ai raconté le détail côté dev.to. Et si votre app n'existe pas encore, autant la construire là où quelqu'un fait déjà cette lecture pour vous : créer mon app avec GoodBarber.

Comment savoir si une nouvelle règle d'Apple ou de Google concerne mon app ?

Vous n'avez pas à le déterminer vous-même. Les règles techniques et déclaratives sont suivies et appliquées au niveau de la plateforme, sans vous impliquer. Celles qui posent une question sur votre contenu ou vos pratiques de données se présentent, elles, dans votre compte développeur, sous la forme d'une déclaration à confirmer — et là, la réponse relève de votre activité, pas de la technique.

Un changement de règles peut-il faire refuser ma mise à jour ?

Un refus reste toujours possible : une revue est faite par des personnes, avec une part d'appréciation. Ce que la plateforme change, c'est la préparation : votre app se présente construite selon les exigences en vigueur, portée par l'expérience des soumissions précédentes. Et si la soumission elle-même vous pèse, GoodBarber Takes Care existe pour la prendre en charge.

Dois-je lire les guidelines d'Apple et de Google avant de publier ?

Pas pour la partie technique et déclarative — elle est suivie en amont, pour toutes les apps de la plateforme. En revanche, les règles qui portent sur le contenu lui-même — ce que votre app a le droit de proposer, de vendre, de montrer — parlent de votre activité, et c'est un domaine où vous restez le mieux placé.

Mon app peut-elle être bloquée alors qu'elle fonctionne parfaitement ?

Oui, et c'est la particularité des règles des stores : elles ne portent pas que sur le bon fonctionnement de l'app : elles portent aussi sur son droit à être distribuée — ce qu'elle déclare, demande et montre. C'est pour cela que la conformité est un travail à part entière, distinct de la technique : une app peut être irréprochable techniquement et se voir demander une déclaration qui n'existait pas l'an dernier.

Le projet Mobile Application Security de l’OWASP couvre des domaines techniques comme le stockage, la cryptographie, l’authentification, les communications réseau et la résistance à l’ingénierie inverse. Les propriétaires d’app interviennent généralement à un autre niveau : accès, fonctionnalités activées, services connectés et gestion des changements.

Sécurité, confidentialité et conformité se recoupent, mais répondent à des questions différentes :

Une app peut décrire correctement ses pratiques de données tout en accordant des accès trop larges. L’approbation des stores n’est pas un certificat de sécurité. Ce guide fournit une base opérationnelle ; des données sensibles, des processus réglementés ou beaucoup de code personnalisé peuvent nécessiter une évaluation qualifiée.

La responsabilité partagée devient plus facile à gérer lorsqu’elle est explicite.

GoodBarber réduit le travail d’infrastructure et de moteur natif qu’un propriétaire devrait sinon assembler. L’organisation décide toujours qui a besoin d’un accès, quelles sections sont privées et ce que les services externes font des données reçues.

Identifiez ce que vous protégez. Une app d’actualités publiques n’a pas le même profil de risque qu’une app scolaire contenant des documents destinés au personnel ou qu’une app de commerce détenant des informations clients.

Dressez un inventaire court de cinq éléments :

• Personnes : administrateurs, éditeurs, membres, abonnés, clients et prestataires externes.
• Espaces privés : sections restreintes, profils, documents internes et contenus non publiés.
• Données : informations de compte, messages, soumissions de formulaires, fichiers, localisation et transactions.
• Connexions : pages intégrées, analytics, publicité, connexion sociale, outils d’automatisation, flux personnalisés et API.
• Comptes critiques : back-office de l’app, fournisseur du domaine, consoles des stores et services externes.

Pour chaque élément, demandez-vous : que se passerait-il si la mauvaise personne pouvait le consulter, le modifier ou l’empêcher de fonctionner ? Les décisions présentant le plus de risques seront ainsi traitées en premier.

Le chemin le plus rapide vers un projet d’app peut être un ancien compte disposant de plus de permissions que nécessaire. Donnez un compte individuel à chaque collaborateur. Des identifiants partagés compliquent le retrait d’une seule personne, l’attribution d’une modification et la connaissance des accès encore actifs. Utilisez un mot de passe unique enregistré dans un gestionnaire pour chaque compte critique et activez l’authentification multifacteur partout où elle est disponible.

Selon l’offre, GoodBarber permet au propriétaire du projet d’ajouter des membres de l’équipe du back-office comme Administrateurs ou Utilisateurs, puis de personnaliser leur accès aux contenus, utilisateurs, audiences et sections CMS. Utilisez les permissions de l’équipe éditoriale pour appliquer une règle simple : accordez uniquement l’accès nécessaire au travail actuel de la personne.

Appliquez la même discipline en dehors de GoodBarber. Apple répartit les responsabilités App Store Connect entre plusieurs rôles et exige une validation en deux étapes ou une authentification à deux facteurs pour la connexion. Google recommande la validation en deux étapes pour chaque compte ayant accès à la Play Console. Supprimez les anciens collaborateurs, réduisez les permissions devenues inutiles, vérifiez les méthodes de récupération et assurez-vous que l’organisation — et non un prestataire indisponible — contrôle les comptes propriétaires.

L’authentification répond à la question qui est cette personne ? L’autorisation répond à à quoi peut-elle accéder ? Une connexion qui fonctionne ne prouve pas que les règles d’accès sous-jacentes sont correctes.

Avec l’extension Authentification de GoodBarber, toute l’app ou certaines sections peuvent exiger une connexion. L’extension Groupes d’utilisateurs permet ensuite à l’éditeur d’autoriser certains groupes à accéder à des sections privées.

Prenons une app scolaire avec des actualités communes, un espace parents et des documents réservés au personnel. Créer trois groupes n’est que l’étape de configuration. Le contrôle de sécurité consiste à tester l’app comme :

• un visiteur sans compte ;
• un parent inscrit ;
• un membre du personnel ;
• un utilisateur valide affecté au mauvais groupe.

Ne testez pas uniquement le menu. Ouvrez un lien direct, la destination d’une notification push et un ancien favori pointant vers la section restreinte. Testez les refus d’accès aussi volontairement que les accès réussis. Pour les utilisateurs déjà connectés, les modifications des droits de groupe peuvent prendre jusqu’à 24 heures pour s’appliquer ; recommencez les tests après ce délai.

Si l’app utilise plutôt le Système d’abonnements, testez l’accès des abonnés et des non-abonnés, y compris les contenus de prévisualisation. Le Système d’abonnements GoodBarber est incompatible avec Authentification et Groupes d’utilisateurs : ce sont des architectures d’accès alternatives. Testez le parcours correspondant à votre app et conservez des règles faciles à expliquer.

Chaque fonctionnalité activée ajoute un comportement ; certaines ajoutent des permissions de l’appareil ou des composants tiers. Appliquez le principe du moindre privilège : ne demandez que les accès nécessaires à une fonctionnalité réellement utilisée par l’app.

Le Privacy Center de GoodBarber inventorie les permissions associées à la configuration de l’app. La plateforme décrit également une approche conditionnelle des bibliothèques intégrées : un composant est inclus lorsque sa fonctionnalité est activée, puis retiré lors de la recompilation si elle est désactivée. Cela réduit le code inutile au niveau de la plateforme, mais le propriétaire décide toujours quelles fonctionnalités appartiennent au projet.

Vérifiez que chaque permission correspond à une fonctionnalité visible, retirez les anciens services d’analytics, de publicité ou de connexion sociale, et déterminez si la désactivation d’une fonctionnalité exige un nouveau build natif pour supprimer son composant. Utilisez ensuite notre checklist de confidentialité pour application mobile afin d’aligner politique de confidentialité et déclarations des stores. La cohérence en matière de confidentialité soutient le travail de sécurité ; elle ne le remplace pas.

La limite apparaît clairement lorsque l’app ouvre un élément que GoodBarber n’a pas construit : site web, service de formulaires, JavaScript personnalisé, API, automatisation ou système partenaire.

Pour chaque surface externe, consignez son propriétaire et vérifiez :

• que l’URL utilise HTTPS et pointe vers le domaine prévu ;
• que les accès à son compte d’administration sont toujours appropriés ;
• qu’aucune clé ou aucun jeton confidentiel n’est intégré au code côté client ; toute clé API visible par le client doit être destinée à un usage public et restreinte autant que son fournisseur le permet ;
• que les informations collectées vont uniquement vers la destination prévue ;
• que le fournisseur, le plugin ou le script est toujours maintenu et que la connexion peut être révoquée.

Pour les contenus et services essentiels à l’activité, documentez ce qui peut être exporté, comment restaurer les accès et ce que fera l’organisation si un prestataire connecté devient indisponible.

HTTPS protège les données en transit. Il ne prouve pas que la destination traite les données de façon sûre, que ses droits d’accès sont corrects ou que son code est exempt de vulnérabilités.

GoodBarber fournit automatiquement des certificats SSL pour le domaine PWA par défaut et les domaines personnalisés connectés. La documentation HTTPS clarifie également la limite : un certificat de la plateforme sécurise l’adresse web gérée par GoodBarber. Vérifiez séparément chaque point de terminaison externe.

La même limite s’applique au développement personnalisé. GoodBarber prend en charge les sections de code personnalisé, widgets, navigation et API, mais sa documentation sur le code personnalisé précise que l’éditeur est responsable du code externe. Faites examiner par une personne qualifiée le code qui traite des informations sensibles ou une logique métier critique.

Toutes les modifications n’atteignent pas une app native installée de la même manière. Les contenus peuvent se mettre à jour automatiquement, certains paramètres doivent être publiés, et une nouvelle fonctionnalité ou une évolution du moteur natif peut nécessiter un nouveau build. Consultez le panneau de mise à jour après l’ajout ou le retrait d’une fonctionnalité et testez le build ad hoc avant l’envoi lorsqu’une recompilation est requise. Le guide de mise à jour des apps natives explique chaque parcours ; notre article dédié détaille ce qui se dégrade silencieusement lorsqu’une app n’est pas mise à jour.

Conservez une trace succincte des contrôles importants :

Cette trace évite que « nous l’avons vérifié une fois » devienne le processus de sécurité permanent.

Un plan d’incident peut tenir sur une page. Identifiez la personne responsable de l’app et des comptes des stores, celle qui peut modifier la configuration et les prestataires à contacter.

Définissez à l’avance les premières actions :

1. Conservez les faits : ce qui a été observé, quand et par qui.
2. Révoquez l’accès de l’utilisateur ou de l’administrateur concerné.
3. Renouvelez les identifiants, jetons ou clés exposés, puis désactivez la connexion touchée si cela réduit le préjudice.
4. Contactez le support GoodBarber lorsque le projet ou la plateforme gérée peut être impliqué.
5. Demandez à des conseillers qualifiés si les utilisateurs, autorités, stores ou partenaires doivent être informés.

GoodBarber décrit ses mesures de sécurité et de sauvegarde au niveau de la plateforme dans son Accord sur le traitement des données. Ne supposez pas qu’elles couvrent un système personnalisé ou un fournisseur tiers.

Utilisez ce contrôle final pour faire rapidement émerger les actions nécessaires.

• Chaque collaborateur du back-office a toujours besoin de son compte et de ses permissions actuelles.
• Les comptes Apple, Google, domaine et services externes ont des responsables actuels et une protection de connexion robuste.
• Les accès publics, authentifiés et restreints ont été testés avec des comptes distincts.
• Chaque permission activée correspond à une fonctionnalité encore utilisée.
• Les pages externes, formulaires, analytics, automatisations et codes personnalisés ont un responsable identifié.
• Chaque destination externe utilise HTTPS et le domaine attendu.
• Aucun identifiant confidentiel n’est intégré au code personnalisé côté client ; les clés API publiques sont correctement restreintes.
• Le panneau de mise à jour et les versions actuellement disponibles sur les stores ont été vérifiés.
• Une personne désignée coordonne les incidents et peut révoquer les accès critiques.
• La date, le relecteur et les preuves de ce contrôle ont été consignés.

Chaque échec devient une action assortie d’un responsable et d’une échéance. Pour une app sensible ou fortement personnalisée, l’étape suivante peut être une évaluation technique indépendante plutôt qu’une nouvelle vérification des paramètres.

Créez votre app, définissez ses règles d’accès et vérifiez sa base de sécurité

Comment sécuriser une application mobile ?

Commencez par répertorier les comptes critiques, espaces privés, données et services connectés de l’app. Limitez les accès administratifs, testez l’authentification et l’autorisation avec plusieurs profils, retirez les permissions inutiles, examinez le code externe et les prestataires, maintenez l’app publiée à jour et préparez un plan de contact en cas d’incident. Les tests techniques doivent être proportionnés à la sensibilité et au degré de personnalisation de l’app.

Une app no-code est-elle moins sûre qu’une app développée sur mesure ?

Pas nécessairement. Un app builder géré peut standardiser l’infrastructure, la compilation et les composants courants. Le développement personnalisé donne davantage de contrôle, mais rend l’équipe responsable de plus de code, de services et de maintenance. La sécurité dépend de la plateforme, de la configuration, des services connectés et des vérifications. Notre article sur les limites des app builders no-code analyse ce compromis.

GoodBarber sécurise-t-il tout ce qui se trouve dans mon app ?

Aucune plateforme ne peut sécuriser les choix et services qu’elle ne contrôle pas. GoodBarber gère son infrastructure et son moteur d’app, et fournit des contrôles pour les accès de l’équipe, l’authentification, les groupes, les permissions et HTTPS. Le propriétaire configure ces contrôles et reste responsable des pages externes, du code personnalisé, des prestataires connectés et des exigences propres au projet.

Ai-je besoin d’un test professionnel de sécurité mobile ?

Peut-être. Demandez l’avis d’un spécialiste pour des informations très sensibles ou réglementées, un volume important de code personnalisé, des systèmes externes critiques ou des parcours dont l’utilisation abusive pourrait causer un préjudice significatif. Cette checklist n’est ni un test d’intrusion ni une certification.

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

Le scénario est toujours le même. Le site fonctionnait hier. Personne n'a touché à rien — ni au contenu, ni aux réglages, ni au code. Et ce matin, chaque visiteur tombe sur un avertissement en plein écran, avec un bouton « Revenir en arrière » que la plupart s'empressent de cliquer. Rien n'est cassé, au sens propre : tout est encore là, intact. Une date est passée, c'est tout.

Votre app aussi a une face web : sa PWA — la version de votre app qui se visite dans un navigateur, à votre adresse, sur votre domaine. Cette adresse est protégée par le même mécanisme que le reste du web : un certificat. La question de cet article tient donc en une ligne : ce certificat a une date de fin ; qui s'occupe de la suivante ?

Un certificat SSL — le nom vient du protocole des débuts du web ; il a depuis été remplacé par son successeur, TLS, mais l'usage a conservé « SSL » — fait deux choses : il prouve que l'adresse que visite votre utilisateur est bien la vôtre, et il chiffre les échanges. C'est lui, le cadenas dans la barre d'adresse.

Et il expire. Ce n'est ni un défaut ni une négligence : c'est le modèle de sécurité. Un certificat volé ou compromis est dangereux aussi longtemps qu'il est valide — plus sa vie est courte, plus la fenêtre de risque est étroite. Let's Encrypt, l'autorité qui sécurise une grande partie du web, émet des certificats de 90 jours, exprès.

Et le mouvement s'accélère. En 2025, l'industrie — navigateurs et autorités de certification réunis au sein du CA/Browser Forum — a acté un raccourcissement par paliers de la durée de vie maximale des certificats publics : 398 jours aujourd'hui, 200 en 2026, 100 en 2027, 47 jours à partir de mars 2029. À cet horizon, un certificat se renouvelle environ huit fois par an. Le web n'a pas seulement accepté que les certificats expirent : il a décidé qu'ils expireraient de plus en plus souvent.

Une date n'est dangereuse que si personne ne tient le calendrier. L'industrie vient de multiplier les dates.

Imaginez que vous mainteniez vous-même votre app et son infrastructure. Ce calendrier serait le vôtre. Obtenir le certificat, l'installer, prouver à chaque renouvellement que le domaine est bien à vous, recommencer avant chaque échéance. Mettre en place une automatisation, bien sûr — puis surveiller l'automatisation elle-même, car c'est le grand classique du genre : le script de renouvellement qui a cessé de tourner depuis des mois, et qu'on découvre le matin où le certificat expire. Les avertissements, eux, partent vers une adresse e-mail consultée une fois par an.

À 90 jours de durée de vie, ce travail est déjà une astreinte. À 47 jours, il change de nature : le renouvellement manuel cesse d'être une option, même mauvaise. Tenir ce calendrier devient un métier — ou une chose qu'on confie à quelqu'un dont c'est le métier.

Quand vous connectez votre nom de domaine, le certificat de ce domaine est provisionné automatiquement — vous n'avez rien à acheter, rien à installer. Sa date d'expiration est ensuite suivie comme un état du système, et le certificat est renouvelé avant l'échéance : l'incident n'est pas réparé rapidement, il est anticipé. C'est toute la différence entre réagir à une panne et faire en sorte qu'elle ne se produise pas.

C'est aussi pour cela que cette famille d'incidents se prête si bien à être prise en charge : c'est la panne la plus prévisible du monde. Tout est daté, tout est connu d'avance. Il faut seulement que quelqu'un en fasse son travail — chaque jour, pour toutes les apps à la fois, y compris quand les échéances se rapprocheront.

La carte complète de qui s'occupe de quoi est dans le premier article ; pour les échéances, elle est courte.

Votre nom de domaine. Il est enregistré chez votre registrar, à votre nom — c'est ce qui fait qu'il est à vous — et il se renouvelle. Un domaine expiré emporte tout ce qui vit dessus, quelle que soit la santé du reste. Ce renouvellement-là ne peut venir que de vous.

Votre compte développeur Apple et Google. Même logique, même conclusion — il est à votre nom, et sa date est la vôtre. La règle vaut pour toute cette série : ce qui est commun à toutes les apps vit côté plateforme ; ce qui est enregistré à votre nom vit chez vous.

Le bénéfice, comme souvent dans cette série, est invisible : le cadenas est dans la barre d'adresse ce matin, comme hier, comme au prochain renouvellement — et il n'y a rien d'autre à raconter. Pendant que les durées de vie raccourcissent, la seule chose qui change pour vous est : rien.

Pour la version ingénierie de ce qui expire et se dégrade sur trois ans, le détail est côté dev.to. Et si votre app n'existe pas encore, autant la construire là où le calendrier est tenu pour vous : créer mon app avec GoodBarber.

Faut-il acheter un certificat SSL pour votre PWA ?

Avec GoodBarber, non : quand vous connectez votre nom de domaine, un certificat est provisionné automatiquement, puis renouvelé avant chaque échéance. Si vous maintenez votre infrastructure vous-même, l'obtention, l'installation et chaque renouvellement sont à votre charge.

Que se passe-t-il quand un certificat SSL expire ?

Les navigateurs affichent un avertissement en plein écran — « Votre connexion n'est pas privée » — et la plupart des visiteurs rebroussent chemin. Rien n'est cassé : le site et son contenu sont intacts, une date est simplement passée. La remise en route consiste à renouveler le certificat ; sur une plateforme qui tient le calendrier, ce renouvellement précède la date.

Pourquoi les certificats SSL expirent-ils de plus en plus vite ?

Parce que c'est plus sûr : un certificat compromis est dangereux tant qu'il est valide, et une vie courte réduit cette fenêtre. L'industrie a acté en 2025 un raccourcissement par paliers, de 398 jours aujourd'hui vers 47 jours en 2029. Conséquence pratique : le renouvellement manuel devient intenable, et l'automatisation du calendrier cesse d'être un confort pour devenir la seule approche viable.

Mon app native est-elle concernée ?

L'écran « Votre connexion n'est pas privée » est une histoire de navigateur : il concerne votre PWA et les pages web liées à votre app. Votre app native, installée depuis les stores, ne l'affichera pas — mais elle communique elle aussi par des connexions chiffrées, et une partie de ses appels s'appuie sur le même certificat que votre PWA. Le calendrier dont parle cet article la concerne donc aussi.

Un enseignant recherche des documents réservés au personnel, un parent consulte le calendrier et un élève enregistre un guide de travail. Envoyer chaque notification à ces trois profils serait simple, mais de moins en moins utile. La bonne question n’est pas de savoir combien de données vous pouvez collecter. Il faut déterminer quelle partie de l’expérience doit réellement changer :

• certaines sections sont partagées, tandis que d’autres dépendent du rôle de l’utilisateur ;
• les notifications sont envoyées uniquement au public concerné ;
• chaque message arrive au bon moment et ouvre une destination utile ;
• les utilisateurs choisissent les mises à jour récurrentes et les contenus qu’ils souhaitent conserver.

Voilà ce qu’est une personnalisation concrète d’app mobile. Aucun modèle de notation opaque n’est nécessaire.

Trois notions proches sont souvent considérées comme synonymes :

• La customisation est une action directe de l’éditeur ou de l’utilisateur de l’app, par exemple modifier un réglage, choisir des thèmes de notification ou enregistrer un contenu.
• La segmentation organise les utilisateurs en groupes qui partagent une caractéristique utile, comme leur rôle, leur langue, leur localisation ou leur niveau d’activité.
• La personnalisation est l’adaptation qui en résulte : l’app modifie les accès, la communication ou la découverte en fonction d’un segment, d’un contexte ou d’une préférence déclarée.

Ce guide traite d’une personnalisation maîtrisée, et non d’un algorithme qui reconstruirait la page d’accueil ou prédirait un flux de contenus unique pour chaque personne.

Avec GoodBarber, cette personnalisation maîtrisée peut intervenir à plusieurs niveaux de l’expérience. L’éditeur définit les règles d’accès et de communication. Les utilisateurs peuvent sélectionner des campagnes de notification et enregistrer leurs contenus favoris. Un assistant conversationnel peut retrouver une réponse contextualisée lorsqu’une personne pose une question.

La langue d’un appareil peut aider à sélectionner les destinataires d’un push ; elle ne traduit ni ne réorganise automatiquement l’app. L’usage peut guider une campagne ; il ne génère pas un flux personnalisé.

Un segment n’est utile que s’il modifie une décision. Le personnel de différents établissements peut avoir besoin d’informations propres à chaque site ; parents et enseignants peuvent nécessiter des ressources privées distinctes ; un public international peut bénéficier d’une diffusion à l’heure locale. Partez de la différence à créer, puis identifiez le signal minimal nécessaire.

L’extension Authentification de GoodBarber permet de définir des champs de profil personnalisés et de les rendre publics, privés ou visibles uniquement par le propriétaire de l’app. Utilisez-les pour des informations déclarées qui servent réellement le service, pas pour construire un questionnaire sans objectif opérationnel.

Un champ de profil ne crée pas automatiquement un groupe dynamique. Dans le fonctionnement standard, l’éditeur attribue les utilisateurs à un ou plusieurs groupes depuis le back-office, individuellement ou par lots.

Authentification permet d’identifier la personne qui utilise l’app. Groupes d’utilisateurs permet ensuite à l’éditeur de déterminer les sections privées accessibles à chaque groupe.

Reprenons l’exemple de l’application scolaire. Sa structure pourrait être la suivante :

Une personne peut appartenir à plusieurs groupes. Un enseignant qui encadre un club peut donc cumuler les deux ensembles de droits, gérés depuis la liste des utilisateurs.

Il s’agit d’une personnalisation de l’accès au contenu, pas d’une recommandation au niveau de chaque élément. GoodBarber détermine si une section est accessible selon les droits configurés ; la plateforme ne prédit pas qui est susceptible de lire un article précis.

Les règles d’accès restent faciles à expliquer et à tester. Avant de créer un groupe, terminez cette phrase : « Ce public a besoin d’une section différente parce que… » Si la justification est faible, conservez le contenu partagé.

Les accès déterminent ce que les utilisateurs peuvent consulter. La personnalisation des push détermine qui mérite d’être interrompu.

Les Notifications push de GoodBarber permettent de cibler les destinataires selon des critères comprenant l’usage de l’app, la langue de l’appareil, la version de l’app, l’appareil ou le système d’exploitation, ainsi que la localisation géographique. Lorsque Authentification et Groupes d’utilisateurs sont activés, une campagne peut également cibler un groupe défini.

Certaines options de ciblage et de localisation dépendent de la plateforme et de l’offre de l’app. Le ciblage géolocalisé atteint uniquement les utilisateurs qui ont activé les services de localisation sur leur appareil.

Construisez chaque notification à partir de quatre décisions :

1. Public : Qui peut agir à partir de cette information ?
2. Message : Qu’est-ce qui est utile à ce public maintenant ?
3. Moment : Faut-il l’envoyer immédiatement, le programmer, le diffuser à l’heure locale ou le déclencher avec une règle de publication ?
4. Destination : Où l’utilisateur doit-il arriver après l’ouverture ?

« Une nouvelle information est disponible » ne répond à aucune de ces questions. « Enseignants : le nouvel emploi du temps de demain est prêt — ouvrez le planning du personnel » relie un public connu à une action précise.

Les notifications manuelles et programmées couvrent les communications ponctuelles. L’extension Push automatique crée des règles récurrentes liées à la publication de contenus, avec des paramètres de public et de diffusion. Une app média pourrait utiliser des règles distinctes pour le sport local et la culture.

Vous pouvez configurer et envoyer ces campagnes directement depuis le back-office ou avec un assistant IA connecté à votre app via le serveur MCP de GoodBarber. Une demande en langage naturel suffit alors à définir le message, le public, le moment et la destination.

Authentification redonne aussi le contrôle à l’utilisateur. Depuis son profil, il peut consulter les campagnes automatiques disponibles et choisir celles qu’il souhaite suivre.

La localisation peut ajouter du contexte, mais le ciblage géographique à distance, le geofencing et les iBeacons répondent à des besoins différents et impliquent des autorisations distinctes. Notre guide consacré au marketing géolocalisé pour les applications mobiles explique quand utiliser chaque approche.

Toutes les différences pertinentes ne nécessitent pas une règle d’audience. Parfois, le meilleur signal est un choix effectué directement dans l’app.

L’extension gratuite Favoris permet aux utilisateurs d’enregistrer des articles, des vidéos, des photos et des podcasts dans une même section. Le catalogue reste identique, mais chacun crée son propre chemin pour retrouver ce qui compte pour lui.

C’est une personnalisation contrôlée par l’utilisateur : avant d’essayer de prédire ses attentes, laissez-le les exprimer par une action simple.

Le RAG Chatbot apporte une autre forme de pertinence. Il recherche des informations dans les articles, événements et points de carte sélectionnés pour répondre à la question d’un utilisateur. C’est la question, et non un profil prédictif, qui détermine ce qui est affiché.

Dans une architecture Authentification, l’accès au chatbot peut être réservé aux utilisateurs connectés ou à certains Groupes d’utilisateurs. Dans une architecture Système d’abonnements, les réponses tiennent compte du statut d’abonnement : les abonnés peuvent recevoir des réponses fondées sur l’ensemble des contenus indexés, tandis que les réponses destinées aux non-abonnés ne révèlent que le texte de prévisualisation gratuit, même lorsque le chatbot recommande un contenu premium pertinent.

Cela ne transforme pas le reste de l’app en une interface générée individuellement. Cette fonctionnalité ajoute un espace de découverte contextuelle au sein d’une base de connaissances contrôlée par l’éditeur.

GoodBarber prend en charge deux architectures d’accès distinctes, et non un ensemble à combiner.

L’extension Système d’abonnements n’est pas compatible avec Authentification, Groupes d’utilisateurs, Communauté ou Chat. Choisissez l’architecture qui correspond au modèle économique avant de construire les accès.

Si un employeur attribue les accès par service, utilisez Authentification et Groupes d’utilisateurs. Si l’accès dépend d’un abonnement, utilisez le Système d’abonnements. Notre guide pour choisir entre une application par abonnement et une communauté privée détaille cette décision.

Chaque règle doit produire un bénéfice que l’utilisateur peut reconnaître.

Mesurez l’action que chaque règle est censée améliorer.

La fonctionnalité intégrée Statistiques & Dashboard de GoodBarber indique les lancements, les sessions uniques, les pages vues, la durée des visites, les plateformes, les pays, les villes et les langues. L’historique des push ajoute les taux d’ouverture et de clic.

Pour une campagne ciblée, comparez la réaction au push avec l’activité sur sa destination. Un taux de clic élevé suivi de peu d’utilisation révèle une destination peu convaincante.

Les statistiques peuvent guider la règle suivante, mais elles ne transforment pas automatiquement les comportements observés en Groupes d’utilisateurs. Le guide complet consacré aux statistiques d’app mobile explique comment relier les signaux d’usage à une expérimentation.

Collectez un champ de profil uniquement s’il modifie l’accès ou le service, et demandez la localisation seulement si le lieu améliore réellement l’expérience.

Expliquez la finalité, respectez les choix des utilisateurs et alignez l’app avec ses informations de confidentialité et les déclarations fournies aux stores. Le Privacy Center de GoodBarber centralise les autorisations, les bibliothèques externes et les informations de confidentialité ; la checklist de confidentialité pour les apps mobiles couvre la vérification avant publication.

Utilisez uniquement les données nécessaires au service proposé.

Avancez progressivement :

1. Identifiez un besoin utilisateur mal satisfait.
2. Choisissez un ou deux segments, ou un choix explicite de l’utilisateur.
3. Modifiez un seul élément : l’accès, la communication, le moment ou la découverte.
4. Sélectionnez un indicateur permettant de savoir si ce changement a aidé.
5. Analysez le résultat avant d’ajouter une nouvelle règle.

L’objectif est de rendre le bon moment plus pertinent, pas de différencier chaque écran.

Créez votre app et configurez sa première expérience personnalisée

Qu’est-ce que la personnalisation d’une app mobile ?

La personnalisation d’une app mobile adapte une partie de l’expérience selon un segment utile, un signal contextuel ou un choix explicite de l’utilisateur. Elle peut agir sur les accès aux contenus, la communication, le moment, les destinations ou la découverte, sans nécessiter de moteur de recommandation individuel.

Quelle est la différence entre customisation et personnalisation d’une app ?

La customisation est une action directe, comme modifier un réglage, sélectionner un thème de notification ou enregistrer un contenu. La personnalisation est l’adaptation qui en résulte : les accès, la communication ou la découverte changent selon un segment, un contexte ou une préférence déclarée. Modifier les couleurs de l’app relève de la customisation ; réserver une section du personnel à un groupe d’employés est une personnalisation fondée sur les droits d’accès.

GoodBarber personnalise-t-il automatiquement le contenu pour chaque utilisateur ?

Non. GoodBarber ne génère pas automatiquement une page d’accueil ou un flux de recommandations individuel à partir du comportement de chaque utilisateur. La plateforme permet une personnalisation maîtrisée grâce aux accès aux sections, aux notifications ciblées par audience, aux campagnes choisies par les utilisateurs, aux Favoris et aux réponses contextuelles de RAG Chatbot.

GoodBarber peut-il cibler des notifications push personnalisées ?

Oui. Les destinataires peuvent être sélectionnés selon des critères comme l’usage de l’app, la langue, la version de l’app, l’appareil, le système d’exploitation ou la localisation. Avec Authentification et Groupes d’utilisateurs, les campagnes peuvent aussi cibler un groupe défini. Dans une app utilisant le Système d’abonnements, elles peuvent plutôt cibler les utilisateurs selon leur statut d’abonnement. Depuis leur profil Authentification, les utilisateurs choisissent les campagnes de notifications automatiques qu’ils souhaitent suivre.

Puis-je utiliser le Système d’abonnements et Groupes d’utilisateurs dans la même app ?

Non. Le Système d’abonnements constitue une architecture d’accès distincte, fondée sur les souscriptions, et n’est pas compatible avec Authentification, Groupes d’utilisateurs, Communauté ou Chat. Choisissez Groupes d’utilisateurs lorsque l’éditeur attribue les accès, et le Système d’abonnements lorsqu’ils dépendent du statut de souscription.

La personnalisation d’une app mobile nécessite-t-elle de l’intelligence artificielle ?

Non. Les personnalisations les plus utiles commencent généralement par des règles d’accès simples, un ciblage d’audience pertinent et des choix explicites de l’utilisateur. L’IA peut ajouter une découverte contextuelle avec RAG Chatbot, mais elle n’est pas indispensable pour rendre l’expérience plus pertinente.

Au début, une liste de favoris fonctionne toute seule. Dix contenus, un ordre chronologique, tout se retrouve d'un coup d'œil.

Puis elle grossit. Des articles, des podcasts, des vidéos, des événements, des adresses, empilés dans la même colonne. Au bout de quelques mois, l'utilisateur qui cherche l'épisode gardé pour son trajet fait défiler cinquante lignes avant de tomber dessus. Le contenu qu'il avait pris la peine de sauvegarder devient plus difficile à retrouver que s'il ne l'avait jamais mis de côté.

C'est exactement ce point que la nouvelle section Favoris corrige.

En haut de la liste, une barre d'onglets permet de n'afficher qu'un type de contenu à la fois. Articles, vidéos, podcasts, événements, lieux : votre utilisateur isole ce qu'il cherche au lieu de faire défiler l'ensemble.

Sa particularité : elle se construit à partir des favoris réellement enregistrés. Un onglet n'apparaît que si au moins un contenu de ce type a été sauvegardé, et il disparaît quand le dernier est retiré. Personne ne tombe sur un onglet vide.

La barre suit donc l'usage de chacun. Un utilisateur qui ne sauvegarde que des podcasts ne voit aucun filtre, puisqu'il n'a rien à filtrer. Le jour où il met un premier événement de côté, l'onglet correspondant apparaît.

Un menu de tri s'ouvre depuis la liste et permet de choisir l'ordre d'affichage. Le bouton reflète toujours le tri appliqué : l'icône et le libellé changent en même temps que la liste, personne n'a besoin de rouvrir le menu pour savoir où il en est.

Quatre ordres sont proposés : du plus récent au plus ancien, du plus ancien au plus récent, de A à Z et de Z à A. Ce choix se fait onglet par onglet, et il est mémorisé d'une session à l'autre. Un utilisateur peut donc afficher ses podcasts du plus récent au plus ancien et ranger ses articles par ordre alphabétique : chaque onglet garde son réglage et le retrouve à la prochaine ouverture de l'app.

Vous définissez de votre côté le tri par défaut, celui qui s'applique tant que l'utilisateur n'a rien changé. Si vous préférez une liste sans réglage, le bouton de tri peut être masqué : la liste utilise alors le tri que vous avez choisi, sans que rien ne soit exposé.

Une vidéo, un podcast et un événement n'ont pas les mêmes repères. Les cellules de la liste s'adaptent maintenant au type de contenu qu'elles affichent.

Une vidéo montre sa durée et son icône de lecture. Un son ou un podcast affiche son lecteur et sa durée, directement dans la liste. Un événement porte son adresse et sa date. Un lieu affiche son adresse et la distance à laquelle il se trouve. Seuls le titre et l'icône de favori restent communs à tous.

La conséquence est très concrète : on reconnaît un contenu sans l'ouvrir, et on lance un épisode sans quitter ses favoris.

Sur les onglets Lieux et Événements, une action supplémentaire permet de basculer la liste en carte. Les favoris s'affichent alors comme dans une section Map classique, l'écran entier étant consacré à la carte. Le même bouton ramène à la liste.

Pour un utilisateur qui a mis de côté quinze adresses pendant la préparation d'un week-end, c'est la différence entre une liste de noms et une vue géographique de ce qu'il a prévu.

L'icône de favori reste visible sur chaque cellule : un tap suffit pour retirer un contenu de la liste, sans passer par sa fiche.

Le retrait est accompagné d'une animation qui suit la structure de la liste : glissement vers la gauche sur Enriched et Condensed, fondu sur Visual Card. Un toast s'affiche ensuite en bas de l'écran avec une action d'annulation.

C'est le filet de sécurité qui manquait. Un favori supprimé par erreur se récupère immédiatement, sans avoir à retrouver le contenu d'origine dans l'app. Quand plusieurs retraits s'enchaînent, le toast suit le dernier en date.

Pour les sons et les podcasts, un indicateur signale l'état de téléchargement de chaque épisode : téléchargé, ou téléchargement en cours. Il se met à jour en temps réel, et le lecteur s'active dès que le fichier est disponible.

Avant de descendre dans le métro ou de prendre l'avion, l'utilisateur voit d'un regard ce qu'il pourra écouter hors connexion. Il n'a plus à ouvrir chaque épisode pour le vérifier.

Le premier passage dans les favoris se fait forcément sur une liste vide. Cet écran est désormais un vrai contenu : une icône, un titre, une description et un bouton d'action, tous personnalisables.

Vous décidez de ce que dit cet écran et de l'endroit où le bouton envoie. Par défaut, il ramène à l'accueil de l'app. À vous de le pointer vers la section qui donne le plus envie de sauvegarder un premier contenu.

La section s'appuie sur les layouts de liste de la dernière génération : Enriched, Condensed et Visual Card. Tous partagent la même logique de filtres, de tri et d'actions, et se distinguent par leur densité et leur composition.

Condensed pour une liste dense où l'on retrouve beaucoup de contenus rapidement, Enriched pour donner de l'espace à chaque élément, Visual Card pour une lecture par l'image. Vos favoris s'alignent ainsi sur le reste de votre app au lieu de rester une liste à part.

La section Favoris est disponible sur iOS, Android et PWA. Les réglages, du layout à l'écran vide en passant par la barre de filtres, le compteur d'éléments et le tri par défaut, se font dans le design de votre section de favoris, celle dont le type est Bookmark, quel que soit le nom que vous lui avez donné dans votre app.

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