Dans cet article
- 1. Ce qu'une application coûte à construire — et à continuer de payer
- 2. Combien de vos clients l'installent vraiment
- 3. Qui ouvre encore l'application après 30 et 90 jours
- 4. Combien de visites supplémentaires il faut pour être rentable
- Quand le calcul devient rentable
- Ce qu'il faut faire avant de signer
Une agence web locale, votre fournisseur de caisse ou un consultant en franchise pose tôt ou tard la même question : voulez-vous votre propre application ? La réponse que vous obtenez est presque toujours émotionnelle — « soyez là où est votre client » — et presque jamais chiffrée. Cet article la chiffre, avec les données que l'industrie des applications publie elle-même.
Une application native semble être la suite logique de votre site web : votre client commande déjà via un écran, pourquoi pas via une icône sur son téléphone ? L'idée n'est pas le problème. Ce qui se passe ensuite l'est — et cette partie, celui qui vous vend l'application ne la mentionne presque jamais.
L'industrie des applications mobiles mesure depuis dix ans exactement ce qui arrive après une installation : combien de personnes l'ouvrent, combien restent après un mois, combien reviennent après trois. Ces chiffres sont solides, publics et remarquablement constants — et presque jamais appliqués à un seul établissement de restauration.
Cet article le fait, en quatre chiffres : ce qu'une application coûte vraiment à construire et à entretenir, quelle part de vos propres clients l'installe réellement, combien parmi eux l'ouvrent encore après 30 et 90 jours, et — la question qui compte vraiment — combien de visites supplémentaires il faut avant qu'elle ne soit rentabilisée. En bas de page, insérez vos propres chiffres dans une calculette qui utilise exactement le même calcul que le reste de cet article.
La conclusion n'est ni « jamais » ni « toujours ». Pour un établissement indépendant avec un seul point de vente, la réponse est presque toujours non — les chiffres ci-dessous montrent précisément pourquoi. Pour un groupe multi-sites ou un concept fortement axé sur la livraison avec un vrai volume de commandes répétées, le même calcul peut être rentable. La différence n'est pas l'ambition, c'est l'échelle.
Le guide ultime Tech & Données Restaurant : 6 Étapes De 7 Outils à 1 Système D'une caisse isolée à un système intégré unique : le guide complet des choix technologiques qui rapportent vraiment. Ouvrir le guide1. Ce qu'une application coûte à construire — et à continuer de payer
Un devis pour une application « simple » de commande et de fidélité pour un seul établissement varie, chez les agences spécialisées, entre environ 8 000 € et 25 000 €, selon la part de votre système existant qu'il faut y intégrer. Ajoutez les réservations, le suivi de livraison ou un programme de fidélité plus élaboré, et cela grimpe rapidement vers 40 000 € à 80 000 € — et la facture ne fait que commencer là. Comparez cela honnêtement à ce qui figure déjà sur votre liste d'abonnements logiciels : une application est rarement le premier coût que vous voulez ajouter.
Au-dessus du coût de construction viennent deux coûts récurrents qu'aucun devis ne met en avant. Apple facture environ 92 € par an pour un compte développeur, sans lequel aucune application iOS ne voit jamais le jour — un an sans paiement, et votre application disparaît de l'App Store, quel que soit le nombre de clients qui l'utilisent déjà. Google facture 23 € une seule fois pour un compte Play Console. Petite somme, mais c'est la première d'une longue série : chaque mise à jour majeure d'iOS ou d'Android impose un nouveau cycle de validation, et une application non mise à jour depuis deux ans finit par être rejetée, ou tout simplement introuvable dans la boutique.
Il existe deux voies moins chères, et toutes deux méritent une mention honnête avant de poursuivre. Une progressive web app (PWA) — « ajouter à l'écran d'accueil » directement depuis votre site existant — coûte une fraction d'une application native, car il n'y a ni validation App Store, ni deux bases de code séparées, ni facture Apple annuelle. Et si le système de réservation ou de commande que vous utilisez déjà propose une application comme fonctionnalité intégrée, son coût marginal est nul : vous la payez déjà, que vous l'utilisiez ou non.
Faites le compte : 90 € par an pour Apple, 23 € une seule fois pour Google — avant même qu'une seule ligne de code soit écrite, et sans garantie qu'un seul client ne l'ouvre jamais.
2. Combien de vos clients l'installent vraiment
Demandez à une agence d'applications le taux d'installation, et la réponse reste vague : « ça dépend ». Demandez aux plateformes de fidélité qui construisent des applications autonomes pour restaurants leurs propres chiffres, et la réponse est plus précise — mais c'est un chiffre avec une adresse. Les fournisseurs d'applications de fidélité rapportent généralement un taux d'installation de 10 à 20 %, et ce pourcentage est mesuré sur leurs meilleurs clients : des habitués. C'est le même piège que pour les bornes de commande : une technologie séduisante qui ne devient rentable que pour une frange très spécifique de vos clients.
C'est là le problème. Ces 10 à 20 % ne sont pas un pourcentage de tous vos clients, c'est un pourcentage de vos habitués — et les habitués sont eux-mêmes une minorité. Les études sur la restauration situent systématiquement la part des clients qui ne reviennent jamais à environ 70 à 77 %, et attribuent environ 65 à 80 % du chiffre d'affaires aux clients qui reviennent. Autrement dit, le groupe susceptible d'installer une application n'est lui-même qu'un cinquième à un quart de votre clientèle totale.
Superposez ces deux chiffres, et la part de votre clientèle TOTALE qui installe l'application tombe à quelques pourcents seulement — pas dix, encore moins vingt. Sur mille clients, cela représente environ deux cent vingt habitués, dont environ un sur sept installe l'application : trente-trois personnes. C'est le point de départ réaliste, pas le chiffre optimiste inscrit sur le devis.
Sur 1 000 clients, avec les proportions ci-dessus. Chaque barre est une part de l'étape précédente.
Ces chiffres sont indicatifs, pas une loi : un établissement avec des clients de livraison vraiment fidèles obtient une part d'habitués plus élevée, un établissement très touristique une part plus faible. Le schéma — un entonnoir raide du client à l'installation puis à l'usage actif — se retrouve dans presque toutes les études.
3. Qui ouvre encore l'application après 30 et 90 jours
Une installation n'est pas un utilisateur. L'industrie des applications mobiles mesure cela depuis des années via des courbes de cohorte — combien de personnes ayant installé au jour zéro reviennent ensuite — et le schéma est remarquablement constant, quelle que soit la catégorie d'application. Business of Apps et Adjust rapportent pour 2026 une rétention moyenne au jour 1 d'environ 25 % : sur tous ceux qui installent, à peu près un sur quatre rouvre un jour l'application une seconde fois.
Ensuite, la chute s'accélère. Ces mêmes sources situent la rétention moyenne au jour 30 entre 5 et 7 %, et plus de 90 % de tous les utilisateurs ont déjà abandonné l'application à ce stade. Au jour 90 — le moment où une remise pour une deuxième visite devrait vraiment commencer à rapporter — la rétention se situe, dans la plupart des catégories, entre 3 et 5 %. Ce n'est pas la malchance d'un développeur négligent ; c'est la moyenne sur des milliers d'applications, dans des dizaines de catégories.
Traduisez cela aux trente-trois installations du chiffre précédent, et il reste, trois mois plus tard, environ un utilisateur actif. Pas un pour cent, un sur trente-trois — une seule personne. C'est la réalité derrière « on construit une application pour faire revenir les clients » : la probabilité qu'un client au hasard l'ouvre encore au jour 90 avoisine un sur mille.
4. Combien de visites supplémentaires il faut pour être rentable
Une application ne se rembourse que si un utilisateur actif vient plus souvent qu'il ne l'aurait fait sans elle — pas plus souvent que la moyenne, plus souvent qu'il ne serait de toute façon venu. Cette différence n'existe dans aucune norme publiée du secteur : aucun rapport ne vous dit combien de visites supplémentaires génère réellement un utilisateur d'application, car cela varie selon l'établissement, le concept et l'offre.
Ce que l'on sait, on peut le confronter. Prenez le coût de construction, divisez-le par votre panier moyen par visite, et vous obtenez le nombre total de visites supplémentaires que l'application doit générer pour se rembourser. Divisez encore par le nombre d'utilisateurs actifs restants après 90 jours, et il apparaît clairement combien de visites supplémentaires par mois chaque utilisateur restant devrait faire — un chiffre qui, pour un établissement normal, s'avère totalement irréaliste.
Pour un établissement indépendant de taille moyenne, le délai de rentabilité s'étale sur des décennies. Non pas parce que l'application ne vaut rien, mais parce que le nombre de personnes qui l'utilisent encore au jour 90 est trop faible pour porter un coût de construction de plusieurs milliers d'euros — même si chaque utilisateur restant se révélait improbablement fidèle.
Même établissement, mêmes taux d'installation et de rétention, trois façons d'obtenir une application.
La barre PWA suppose les mêmes taux d'installation et de rétention que l'application native — seul le coût de construction diffère. En réalité, le seuil pour appuyer sur « ajouter à l'écran d'accueil » est plus bas qu'un téléchargement sur un store, donc ceci est plutôt un plancher pour la rapidité avec laquelle une PWA est rentabilisée qu'un plafond.
Calculez pour votre propre établissement
Les chiffres ci-dessus sont des moyennes. Renseignez votre propre clientèle, panier moyen et devis — tout se calcule localement dans votre navigateur.
—
Le chiffre « visites supplémentaires par mois grâce à l'application » est la seule hypothèse ici sans source publiée — renseignez-le prudemment plutôt qu'avec optimisme. Tout se calcule localement dans votre navigateur ; rien n'est envoyé ni conservé.
Quand le calcul devient rentable
Le calcul ci-dessus est écrit pour l'établissement que gère la plupart des lecteurs de cet article : un seul point de vente, quelques milliers de clients, un devis de plusieurs dizaines de milliers d'euros. Changez cette échelle, et la conclusion peut s'inverser — non pas parce que la courbe de rétention change, mais parce que le coût de construction n'est pas multiplié par point de vente, alors que la clientèle, elle, l'est.
Prenez un concept axé sur la livraison avec plusieurs points de vente et une clientèle combinée d'environ 50 000 personnes, avec une fréquence de commande plus élevée et une part d'habitués plus importante que l'établissement de restauration moyen — réaliste pour une activité qui livre régulièrement plutôt que d'accueillir des clients occasionnellement. Même application, même devis d'environ 50 000 €, mais désormais répartie sur une base d'utilisateurs actifs bien plus large.
Avec des hypothèses d'installation et de rétention tout aussi prudentes, cette application est rentable en environ 10 mois — au lieu de décennies. La différence ne tient pas à l'application, elle tient au dénominateur : à cette échelle, il reste assez d'utilisateurs actifs pour porter le coût de construction ; pour un seul établissement indépendant, non.
Ce qu'il faut faire avant de signer
Signer un devis prend une signature. Ces trois étapes prennent une heure, et elles décident si cette signature fait économiser de l'argent ou en fait perdre.
Avant de demander un devis
- Comptez combien de vos clients sont vraiment des habitués — des personnes qui reviennent au moins une fois par mois. Ce chiffre, et non votre clientèle totale, est ce sur quoi une application est réellement construite.
- Posez-vous une seule question : que fait l'application qu'une liste de diffusion WhatsApp, une carte de fidélité gratuite ou un favori sur l'écran d'accueil ne peuvent pas faire ? Si la réponse honnête est « rien de concret », l'application est une manière coûteuse de faire la même chose.
- Ouvrez la calculette ci-dessus avec vos propres chiffres avant de parler à une agence — vous saurez alors quelle réponse un devis doit vous donner, et non l'inverse.
Si vous construisez quand même
- Commencez par une PWA, pas par une application native. Si elle est réellement utilisée après six mois, vous avez une preuve avant de faire un investissement dix fois supérieur.
- Mettez dès le premier jour un avantage concret dans l'application qui n'existe nulle part ailleurs — une carte de fidélité qui ne se remplit que là, un plat visible en avant-première uniquement là. Sans raison de la garder ouverte, la courbe de cohorte ci-dessus se répète exactement.
- Réservez 15 à 20 % du coût de construction par an pour la maintenance et les mises à jour des stores — ce n'est pas un extra, c'est le prix pour rester en ligne.
La voie moins chère
- Vérifiez d'abord si le système de réservation ou de commande que vous utilisez — ou envisagez — propose déjà une application, aux côtés de l'autre automatisation qu'il vous apporte déjà. Le coût marginal est alors nul.
- Comparez honnêtement cette voie gratuite au devis : les mêmes notifications push, la même intégration de fidélité, sans facture Apple séparée.
- Découvrez ce qu'une telle application intégrée propose concrètement sur la page produit de notre propre application — la même question, sans l'agence entre les deux.
Ni non, ni oui — un calcul
Presque tous les restaurateurs qui lisent cet article reconnaissent l'impression qu'une application fait partie d'un « établissement moderne ». Cette impression n'est pas fausse — elle n'est simplement pas un modèle financier. Les quatre chiffres ci-dessus montrent ce qui se passe entre le devis et le premier bilan annuel : un entonnoir raide du client à l'installation puis à l'usage actif, et un coût de construction qu'il faut répartir sur trop peu d'utilisateurs restants.
Pour un établissement indépendant de taille moyenne, la réponse est presque toujours : pas maintenant, pas en natif, pas à ce prix. Ce n'est pas un jugement sur l'ambition — c'est ce que prédisent les courbes de cohorte de toute l'industrie des applications, appliquées à un seul établissement plutôt qu'à un public de masse.
Ce qui fonctionne, c'est le même instinct — être plus proche de son client — sans le coût de construction, la facture des stores et l'obligation de mise à jour annuelle. Notre propre application est exactement cette voie : la même fonctionnalité, intégrée à un système que vous utilisez déjà, sans seconde facture d'agence.