Tôt ou tard, quelqu'un le dit en réunion : « Nos clients nous demandent une app. » La phrase sonne comme un cahier des charges. C'en est rarement un. Avant de demander une soumission à un développeur de logiciel sur mesure, ou d'en accepter une, il vaut la peine de savoir ce que le client imagine quand il dit « app », parce que la réponse change le projet du tout au tout.
Il y a trois façons d'y répondre : une application native publiée dans l'App Store et sur Google Play, une application web que le client installe depuis son navigateur, ou un meilleur site. Ce qui a changé, c'est ce qu'une application web sait faire sur un iPhone, et la plupart des comparatifs en ligne n'ont pas suivi.
La réponse courte, pour les pressés
Quand un client demande une « app », il veut presque toujours quatre choses : une icône sur son écran d'accueil, des notifications, rester connecté et un accès rapide, parfois hors ligne. Une application web installable les donne aujourd'hui sur les deux plateformes. Depuis iOS 26, tout site ajouté à l'écran d'accueil d'un iPhone s'ouvre comme une application, et les notifications web y fonctionnent depuis iOS 16.4, à condition que l'utilisateur ait d'abord ajouté le site. Sur Android, Chrome propose lui-même l'installation. Les magasins restent nécessaires pour être découvert par des inconnus, pour des fonctions de l'appareil absentes de Safari, comme le Bluetooth ou le NFC, et pour vendre du contenu numérique. En octobre 2026, ils coûtent 99 $ US par année chez Apple et 25 $ US une fois chez Google, une révision à chaque mise à jour, des commissions de 15 à 30 % sur les ventes numériques, et deux applications à remettre aux normes chaque année.
Ce que « une app » veut dire, une fois qu'on pose la question
Demandez ce que l'app ferait que le site ne fait pas. Les réponses se regroupent presque toujours en quatre besoins.
L'icône. Retrouver l'entreprise d'un geste, sans taper l'adresse ni passer par Google.
Les notifications. Être prévenu que la commande est prête, que le rendez-vous est demain, qu'il reste deux places au cours de samedi.
Rester connecté. Ne pas retaper son mot de passe chaque fois qu'on ouvre son dossier.
La vitesse, et parfois le mode hors ligne. Voir l'information tout de suite, même dans un sous-sol sans réseau.
Remarquez ce qui manque : personne ne demande de passer par un magasin d'applications. Le magasin est la solution qu'on imagine, et aucun des quatre besoins ne l'exige.
Deux de ces besoins ne demandent même pas d'application. Rester connecté dépend de la durée de session que le site accorde. La vitesse est souvent un reproche adressé au site actuel, qu'une application contourne à grands frais sans le corriger. La vitesse d'un site se mesure et se corrige. C'est la troisième réponse, parfois la bonne.
Ce qu'une application web installée fait aujourd'hui
L'ajout d'un site à l'écran d'accueil d'un iPhone existe depuis 2008. Pendant 17 ans, l'icône n'ouvrait le site en mode application que si le développeur l'avait prévu. Depuis iOS 26, sorti en septembre 2025, tout site ajouté à l'écran d'accueil s'ouvre par défaut comme une application web, séparée de Safari. L'équipe de WebKit, le moteur de Safari, le résume ainsi : il n'y a plus aucune exigence d'« installabilité » dans Safari.
Les notifications sont arrivées avant, avec iOS 16.4, en 2023. Elles s'affichent comme les autres, sur l'écran verrouillé, dans le centre de notifications et sur une Apple Watch jumelée, et passent par le même service que celles des applications natives. Il n'est pas nécessaire d'être membre du programme pour développeurs d'Apple.
Deux conditions comptent. La demande de permission doit suivre un geste de l'utilisateur, comme un toucher sur un bouton « M'avertir ». Et sur iPhone, les notifications ne fonctionnent que pour un site ajouté à l'écran d'accueil. Or le site ne peut pas déclencher cet ajout : Safari ne lui donne pas de bouton d'installation, et l'utilisateur doit passer par le menu Partager. C'est le vrai point faible de l'application web sur iPhone. Il faut enseigner le geste, par exemple juste après une première réservation.
Sur Android, Chrome fait ce travail. Quand le site est en HTTPS, qu'il déclare un nom et des icônes, et que l'utilisateur a touché la page et l'a regardée au moins 30 secondes, Chrome propose l'installation. Le site peut aussi afficher son propre bouton « Installer ». Les notifications, elles, fonctionnent dans Chrome même sans installation.
La limite est ailleurs. Selon les données de compatibilité de MDN, Safari ne prend en charge ni le Bluetooth web, ni la lecture NFC, ni la synchronisation en arrière-plan.
Ce que seuls les magasins donnent
Les magasins donnent trois choses : les fonctions de l'appareil que le web n'atteint pas sur iPhone, la vente de contenu numérique avec leur système de paiement, et la découverte. Quelqu'un qui ne vous connaît pas cherche « réservation yoga » dans l'App Store et vous trouve. Pour une application destinée à vos clients existants, ce dernier avantage ne vaut presque rien : ils connaissent déjà votre nom.
Si aucune ne s'applique, reste la tentation d'emballer le site existant dans une application. Apple l'a prévue. Sa règle 4.2 sur la fonctionnalité minimale demande qu'une application offre des fonctions, du contenu et une interface qui l'élèvent « au-delà d'un site web reconditionné », faute de quoi elle peut être refusée. La règle 4.2.6 refuse les applications tirées d'un gabarit commercial, sauf si le fournisseur du contenu les soumet lui-même. L'« app à petit prix » qui glisse votre site dans une coquille est exactement ce que la révision d'Apple cherche à filtrer.
Ce que coûtent les magasins
En octobre 2026, le programme pour développeurs d'Apple coûte 99 $ US par année, facturés en devise locale là où c'est offert. Google demande 25 $ US, une seule fois, pour ouvrir un compte sur Google Play.
Le contrat d'Apple prévoit une commission de 30 % sur les ventes, et de 15 % sur les renouvellements d'abonnement après un an. Son programme pour petites entreprises ramène le taux à 15 % tant que les revenus nets restent sous un million de dollars américains par année. Chez Google, pour le Canada, c'est 15 % sur le premier million de dollars américains de revenus annuels pour un développeur inscrit à ce palier, 30 % au-delà, et 15 % sur les abonnements. Une nouvelle grille s'applique déjà aux États-Unis, dans l'Espace économique européen et au Royaume-Uni depuis le 30 juin 2026, et en Australie et au Japon depuis le 30 septembre. Pour le Canada, Google n'indique pas encore de date.
Pour la plupart des PME, ces commissions ne s'appliquent pas. Apple exige que les biens physiques et les services consommés hors de l'application soient payés autrement, par exemple par Apple Pay ou par carte de crédit. Google exempte de sa facturation les biens physiques et des services comme le ménage, l'abonnement au gym ou les billets de spectacle. Un garage, une clinique ou un restaurant ne verse donc aucune commission au magasin sur ce qu'il vend dans son application.
Le coût qui reste, c'est la révision. Chaque nouvelle version passe par Apple, qui dit traiter au moins 50 % des applications soumises en moins de 24 heures et 90 % en moins de 48 heures. Google prévient que, pour certains comptes, la révision peut prendre jusqu'à sept jours. Sur un site web, une correction est en ligne en quelques minutes.
La facture qui revient chaque année
On imagine une application comme un objet qu'on construit une fois. Les magasins la traitent comme un abonnement à leurs mises à jour.
Chaque année, Apple et Google relèvent le minimum. Depuis le 28 avril 2026, toute application téléversée chez Apple doit être compilée avec Xcode 26 et le kit de développement d'iOS 26. Depuis le 31 août 2026, Google exige que les nouvelles applications et les mises à jour visent Android 16, et qu'une application existante vise au moins Android 15 pour rester offerte aux nouveaux utilisateurs dont le téléphone a une version d'Android plus récente.
Une application qu'on ne touche pas pendant deux ans ne reste donc pas figée : pour corriger un bogue, il faut d'abord la remettre aux normes.
Une application native, ce sont deux bases de code (ou un cadre multiplateforme qui les rapproche), deux comptes, deux révisions et deux calendriers d'exigences. Le site web, lui, continue d'exister. Ça fait trois surfaces à garder cohérentes, et c'est la troisième qu'on oublie dans le budget.
Trois cas qu'on voit souvent
Le portail client. C'est le meilleur candidat à l'application web installable. Les utilisateurs sont déjà clients et se connectent pour suivre un dossier ou voir une facture. Une notification « votre document est prêt » et une icône couvrent l'essentiel. On a décrit ce qu'on met dans un portail client, et comment le relier à vos logiciels par une intégration API.
La réservation. Un client réserve quelques fois par année. Lui faire télécharger une application avant de prendre rendez-vous ajoute une étape que vos concurrents n'imposent pas. La réservation doit vivre sur le site, là où les gens la cherchent déjà par votre nom. Les rappels par courriel ou par texto rejoignent aussi ceux qui n'ont rien installé.
La carte de fidélité. C'est le cas où l'application est le plus souvent une erreur. Apple Wallet et Google Wallet acceptent des cartes de fidélité distribuées par un lien sur votre site ou par courriel, sans application. La carte vit dans le portefeuille que le client ouvre déjà à la caisse, et elle peut afficher le solde à jour. Les règles qui encadrent les points au Québec sont dans notre article sur les cartes-cadeaux et la fidélité.
Une application native se justifie quand elle est le produit : vous vendez du contenu numérique à des gens qui vous découvriront dans le magasin, ou votre service doit parler à un appareil Bluetooth ou lire une puce NFC sur iPhone. Elle mérite alors un budget et un responsable pour des années, et les tests de notre article sur le sur mesure ou le SaaS s'appliquent.
Par où commencer
Avant toute soumission, posez à vos clients la question des quatre besoins. Si la liste tient en une icône, des notifications, une connexion qui tient et de la vitesse, commencez par une application web installable, et mesurez combien de clients l'installent. Si un besoin résiste (Bluetooth, NFC, vente numérique, découverte par des inconnus), vous aurez une raison précise d'aller dans les magasins, et un cahier des charges plus court.
Chez Peich, on construit des portails et des applications web de ce genre, et on vous dira quand un meilleur site suffit.
→ Parlons de l'app que vos clients demandent
Écrit parXavier Peich