PME 2026 : site web, application mobile ou les deux ?

PME 2026 : site web, application mobile ou les deux ?

Un site web se découvre. Une application mobile se télécharge. Ce sont deux stratégies différentes, avec des budgets, des canaux et des ROI différents.

Chaque PME pose la même question en 2026 : faut-il investir dans un site web, une application mobile, ou les deux ? La mauvaise réponse coûte cher : un site qui ne convertit pas, ou une app que personne ne télécharge.

Ce que vous allez apprendre : les fourchettes de prix 2026 (nos grilles publiques), les cas d'usage typiques, la méthode de décision en 4 questions, et quand le « les deux » devient rationnel. Avec des cas documentés : Tontineo (app + web + admin), PANIGASPI (app) et FocusLock (app).

Les deux stratégies ne répondent pas au même besoin

Avant de parler prix, il faut poser le vrai clivage : un site web et une application mobile n'ont ni le même canal d'acquisition, ni le même rapport à l'utilisateur, ni le même cycle de vie.

Le site web est un espace public. Il s'ouvre depuis n'importe quel navigateur, se partage par lien, se trouve sur Google, se lit sur mobile, tablette ou ordinateur. Son cycle de vie : découverte → information → action (achat, RDV, contact). Sa valeur se mesure en visites, conversion et référencement.

L'application mobile est un espace privé. Elle s'installe sur le téléphone, demande des permissions, envoie des notifications, garde l'utilisateur connecté. Son cycle de vie : téléchargement → installation → usage répété → rétention. Sa valeur se mesure en téléchargements, rétention et fréquence d'usage.

Ce n'est pas une question de « mieux » — c'est une question d'objectif : voulez-vous être trouvé, ou voulez-vous être utilisé ?

Le site web : la porte d'entrée trouvable

Un site web se fait trouver. Sur Google, depuis les réseaux sociaux, par le bouche-à-oreille. Il est le socle de votre présence : votre marque, vos services, vos prix, votre contact. Sans lui, une application mobile perd son principal canal d'acquisition.

Nos grilles publiques s2 (SaaS / web) en 2026 :

Cas documenté : la plateforme e-learning (id 33) et la plateforme d'albums photo pro (id 35) — deux livraisons web en Next.js.

Offres s2 : 2 000, 3 500 et 5 000 € pour le web — grille commerciale publique, pas une médiane de devis

Ce que le site web apporte concrètement

Le site web est l'infrastructure de confiance : c'est là que le client vérifie avant d'acheter. Trois rôles qu'aucune app ne remplace :

1. Le rôle de preuve : avant de télécharger votre app ou de vous contacter, le prospect cherche votre site, vos avis, vos références. Un site absent ou daté tue la conversion même quand l'app est excellente.
2. Le rôle SEO : sur les requêtes métier (« kiné Nantes », « développeur Flutter »), c'est le site qui apparaît dans Google, pas l'app. C'est le canal d'acquisition le moins cher quand il est bien construit (contenu, maillage, performances).
3. Le rôle de standard : prix, horaires, CGV, mentions légales — le site héberge l'information stable, partagée en un lien, indexée, mise à jour.

Et un atout économique décisif : un site web se met à jour en continu sans validation de store. Corriger un prix, ajouter un service, publier un article : tout passe en production en quelques minutes, sans période de revue Apple ou Google.

L'application mobile : l'outil d'usage répété

Une application mobile s'installe. Elle crée une présence permanente sur le téléphone de l'utilisateur : notifications, raccourci, authentification. Elle n'apparaît pas dans Google (ou très peu). Vous devez donc la vendre autrement : store, QR code, recommandations.

Nos grilles publiques s3 (Flutter) en 2026 :

Cas documentés : PANIGASPI (id 7), FocusLock (id 28) et Tontineo (id 30) en Flutter. Le modèle Flutter vs React Native détaille le choix technique.

Offres s3 : 2 000, 3 500 et 5 000 € pour le mobile Flutter — grille commerciale publique

Ce que l'app apporte concrètement

L'app excelle là où le web est faible : la récurrence. Quatre capacités propres :

1. Les notifications push : un rappel de tontine, une livraison en cours, une séance reportée — l'app touche l'utilisateur même écran éteint. Le web ne peut pas faire ça (les notifications web existent mais peinent à convaincre les utilisateurs de les activer).
2. L'authentification persistante : connecté une fois, l'utilisateur reste connecté. Les frictions disparaissent — c'est le levier des usages transactionnels répétés (payer, réserver, commander).
3. Les capacités natives : caméra (scan QR, photo de justificatif), GPS (géolocalisation livraison), capteurs, paiement mobile. Le web cerne ces capacités sans les égaler.
4. Le raccourci permanent : l'icône sur l'écran d'accueil transforme un canal en habitude. La rétention est structurellement meilleure.

Mais l'app a un coût invisible : le coût d'acquisition. Personne ne télécharge une app par hasard. Il faut un store (être trouvé), un QR code (être scanné), une campagne (être incité). Chaque téléchargement a un prix — à intégrer dans le business case.

Le cas particulier des apps métier internes

Une app mobile pour vos employés (chantiers, livraisons, tournées, inventaires) change la donne : le coût d'acquisition disparaît (votre équipe installe l'app, point), l'usage est obligatoire, et les capacités natives (GPS, caméra, hors-ligne) ont une vraie valeur métier. C'est aujourd'hui le cas le plus rentable d'app pour une PME — notre fiche id 28 (FocusLock) et notre article sur le développement d'app métier posent le cadre.

La méthode de décision en 4 questions

flowchart TD
    A[Projet digital PME] --> B{Le besoin : être trouvé ou être utilisé ?}
    B -->|Être trouvé / SE / vitrine| C[Site web]
    B -->|Usage répété / notif / scan| D[Application mobile]
    C --> E{Budget : < 2 000 €?}
    E -->|Oui| F[Site vitrine simple]
    E -->|Non| G[SaaS Standard à Premium]
    D --> H{Le client téléchargera-t-il ?}
    H -->|Oui / déjà décidé| I[Flutter MVP à Premium]
    H -->|Incertain| J[Commencer par un site + PWA]
    I --> K[Prévoir admin + stores + analytics]
    J --> K

(Arbre de décision rendu par le MCP Mermaid — la version intégrée est l'image ci-dessous.)

4 questions : trouvable vs utilisé, budget, téléchargement, périmètre

Question 1 : être trouvé ou être utilisé ?

• Trouvable : site web. C'est là que Google, LinkedIn ou une pub amènent un inconnu.
• Utilisé : application mobile. On la retrouve sur le téléphone, on y revient.

La question n'est pas rhétorique : la réponse détermine tout le reste. Une PME de services (plomberie, comptabilité, coiffure) répond « trouvé » : les clients viennent ponctuellement, sur besoin. Une PME de produits ou d'abonnement (tontine, livraison, coaching) répond « utilisé » : le client revient chaque semaine.

Les deux réponses possibles ne sont pas exclusives — mais l'ordre compte : le trouvable précède presque toujours l'utilisé.

Question 2 : quel budget convertible ?

Sous 2 000 €, un site vitrine bien fait bat de loin une app mal faite. Au-delà, la grille s2/s3 donne des fourchettes claires. Notre article prix d'un site web et prix d'une app Flutter détaillent.

Attention à un piège de lecture des grilles : 2 000 € d'app et 2 000 € de site ne couvrent pas le même périmètre. Le site s2 MVP est une vitrine fonctionnelle (jusqu'à 6 écrans, SEO). L'app s3 MVP est un produit installable (10 écrans iOS+Android) — mais sans l'écosystème (admin, stores, notifications, analytics), l'app reste une coquille. Le coût complet d'une app « utilisable » commence à l'offre Standard (3 500 €), souvent plus avec les frais de stores (99 $/an Apple, 25 $ uniques Google).

Question 3 : l'utilisateur téléchargera-t-il ?

C'est LA question qui tue la plupart des projets d'app. Si l'usage est ponctuel (voir un horaire), une PWA suffit. Si l'usage est répété et enrichi de notifications (tontine, panier, coaching), l'app devient rationnelle.

Le test honnête : « Est-ce que moi-même, je téléchargerais cette app ? » Si la réponse est « pour la tester une fois », le projet est mort. Si c'est « pour l'ouvrir tous les jours », il est vivant. Les apps qui survivent ont un usage quotidien ou hebdomadaire prouvé — pas un usage « de temps en temps ».

La PWA (Progressive Web App) est le pont : installable sur l'écran d'accueil, notifications web, fonctionne hors connexion partielle — le tout sans store. C'est le bon premier pas quand l'incertitude domine, et elle peut se transformer en app native plus tard si l'usage confirme le besoin.

Question 4 : y a-t-il un admin à prévoir ?

Chaque app sérieuse a besoin d'un back-office : gérer les utilisateurs, les contenus, les transactions. Le cas Tontineo (ids 30, 31, 32) montre les trois briques : app mobile, landing page web, et admin web.

Sous-estimer l'admin est l'erreur n°1 des premiers projets d'app : on chiffre l'app, on oublie que chaque action utilisateur (inscription, paiement, modération) produit une donnée à gérer. L'admin représente souvent 20 à 30 % du budget total d'un écosystème mobile.

App mobile (Flutter) + landing web + admin : le modèle Tontineo documenté dans nos fiches 30, 31, 32

Quand « les deux » est rationnel

Combiner site + app est rationnel dans deux cas :

1. Un écosystème à forte répétition : la tontine (id 30) a besoin de la landing pour recruter, de l'app pour les paiements récurrents, de l'admin pour gérer. Trois briques, trois grilles.
2. Un modèle freemium ou SaaS mobile-first : le web sert au SEO, l'app sert à la rétention et aux notifications.

La règle : le web vient d'abord, sauf si l'usage répété prouve déjà le besoin d'app. Personne ne télécharge une app pour un achat unique.

Site web : trouvable, SEO, faible coût. App : rétention, notifications, store, coût d'acquisition

Les trois combinaisons types

Le « les deux » n'est pas la seule option. Trois architectures couvrent la plupart des cas PME :

1. Site seul : vitrine + contentu + RDV. Pour 80 % des PME de services, c'est suffisant. L'acquisition passe par Google et les avis.
2. Site + PWA : le site enrichi d'une version installable. Pour les usages répétés qui ne justifient pas encore une app native. C'est la voie de transition raisonnable.
3. Site + App native + Admin : l'écosystème complet. Pour les modèles transactionnels récurrents (tontine, abonnement, livraison, coaching). Le modèle Tontineo (ids 30, 31, 32).

Le budget annuel complet : ne regardez pas que la construction

Le prix de construction n'est que le début. Le coût annuel d'un site ou d'une app comprend :

Les postes qui différencient vraiment : la maintenance (l'app iOS/Android exige des mises à jour de compatibilité plus fréquentes) et l'acquisition (le SEO est gratuit une fois construit, le store et les campagnes se paient en continu). Voir aussi notre analyse du coût de maintenance des apps.

Les 8 critères de comparaison détaillés

Pour trancher entre site et app, comparez les deux options sur les 8 dimensions qui déterminent réellement le choix :

Ce tableau est l'outil de travail : remplissez-le pour votre cas (volumes, panier, fréquence), pas pour « les PME en général ». Le critère décisif n'est jamais un seul poste — c'est l'étape de votre modèle : acquérir (le site gagne), fidéliser (l'app gagne), ou les deux.

Les erreurs classiques sur l'acquisition mobile

Le coût d'acquisition est le poste le plus mal évalué des projets d'app. Trois erreurs reviennent systématiquement :

1. « On mettra un QR code sur la vitrine » : le QR code ne suffit pas. Un utilisateur qui scanne un QR code en vitrine doit avoir une raison forte d'installer — une remise, un service exclusif, un gain immédiat. Sans incitation, le taux d'installation dépasse rarement quelques pourcents.
2. « On sera sur les stores, donc on sera trouvés » : être sur l'App Store et Google Play ne garantit aucune visibilité. L'ASO (optimisation de la fiche store) est un métier à part entière, concurrentiel, et le store favorise les apps à fort volume — pas les petites nouveautés.
3. « Nos clients installeront parce qu'ils nous aiment » : l'affection ne survit pas à la friction du téléchargement. Le taux de rétention après installation est le vrai arbitre : une app non ouverte 30 jours après l'installation est un échec, quel que soit le motif de l'installation.

La bonne pratique : construire le business case de l'app avec un coût d'acquisition par utilisateur actif (téléchargements × taux de rétention), pas un coût par téléchargement. C'est le seul chiffre qui recoupe le site web.

Le SEO : l'avantage invisible (et rentable) du site

Le site web a un avantage que les budgets app ignorent : le SEO continue de travailler après la construction. Trois dynamiques spécifiques 2026 :

1. Le contenu long format : les guides, comparatifs et FAQ (comme cet article) attirent des visiteurs sur des requêtes métier, des mois après publication. C'est de l'acquisition gratuite récurrente — le store n'a pas d'équivalent.
2. Le maillage interne : chaque page produit des liens vers les autres, renforçant l'autorité du domaine. Le site devient une machine à classer, pas une simple vitrine.
3. La recherche locale et IA : les moteurs et assistants (Google, Bing, ChatGPT) citent de plus en plus les sources web de confiance. Un site bien structuré (données structurées, contenu factuel) est cité ; une app n'est jamais citée.

En pratique : un site bien construit génère un flux de demandes entrantes avec un coût marginal proche de zéro après la construction. Une app génère des coûts d'acquisition tant qu'elle vit. C'est la raison structurelle pour laquelle le web vient d'abord — sauf usage répété prouvé.

Les questions à poser à votre agence avant de signer

Que vous partiez sur un site, une app ou les deux, posez ces 6 questions au prestataire :

1. Quel périmètre exact ? Écrans, intégrations, admin, stores — demandez la décomposition en ligne, pas un forfait flou.
2. Qui possède le code ? Le livrable complet (repo, base, config) vous appartient-il dès la livraison ?
3. Quelles performances SEO ? Le site est-il construit avec le SEO en tête (SSR, métadonnées, données structurées) ou en SPA vide pour Google ?
4. Quel coût de maintenance ? Taux mensuel, heures d'évolution comprises, SLA de réponse ?
5. Quels frais récurrents ? Hébergement, stores, services tiers (paiement, notifications) — ligne par ligne.
6. Comment passe-t-on du site à l'app plus tard ? La stack (Next.js, API) est-elle pensée pour réutiliser la logique métier dans la future app Flutter ?

Nos articles sur le choix d'une agence de développement mobile et le prix d'un site sur mesure approfondissent chaque question.

L'exemple d'un écosystème complet : Tontineo

Le modèle Tontineo (fiches ids 30, 31, 32) illustre ce que « les deux » signifie concrètement pour une PME :

• La landing web (id 31) : le canal de recrutement. SEO, présentation du service, FAQ, CTA de téléchargement. C'est elle qui amène les nouveaux membres en continu.
• L'app Flutter (id 30) : le produit. Cotisations récurrentes, notifications de rappel, suivi des cycles de tontine, historique des paiements. C'est elle qui fidélise.
• L'admin web (id 32) : le back-office. Gestion des membres, des cycles, des paiements, des litiges. C'est lui qui rend le modèle opérationnel.

Chaque brique répond à un besoin distinct — et les trois se justifient économiquement parce que la tontine est un usage hebdomadaire ou mensuel récurrent. Sans cette récurrence, la brique app n'aurait pas de sens.

Le même raisonnement s'applique à la livraison (suivi de courses + choix du créneau), au coaching (programme + rappels + paiement), à l'abonnement (contenu + renouvellement + notifications). Repérez l'usage répété : c'est lui qui décide de la brique app.

Le calendrier recommandé de déploiement

L'ordre de construction recommandé pour un projet « site + app » sur 12 mois :

Ce calendrier évite l'erreur la plus coûteuse : développer l'app avant d'avoir prouvé l'usage avec le site. Pendant les mois M4–M8, le site sert de sonde : si les demandes répétées n'apparaissent pas à l'usage réel, l'app n'aurait pas survécu non plus — mais elle aurait coûté 3 500 € de plus.

Fréquemment oublié : les frais annuels des stores et services

Le budget PME et les stores ne font pas bon ménage quand ils sont oubliés. Récapitulatif des frais récurrents qui apparaissent au bout de 12 mois :

• Apple Developer Program : 99 $/an — obligatoire pour publier sur l'App Store.
• Google Play : 25 $ uniques — modeste, mais à prévoir.
• Push notifications et services tiers : 0 – 100 €/mois (Firebase, OneSignal, Fournisseur) selon le volume.
• Hébergement API + base de données de l'app : 10 – 80 €/mois selon le volume.
• Renouvellement du compte développeur : annuel, facile à oublier après la première année.

Cumulés, ces postes représentent souvent 300 – 1 500 €/an selon l'écosystème — à intégrer dans le business case avant la décision, pas après la première année de surprise. Notre grille s3 Standard inclut la soumission aux stores, mais pas ces frais : ils restent à votre charge, conformément à nos CGV de l'offre mobile.

Les chiffres de nos fiches

Nos fiches publiques (registre 13 septembre 2026) documentent :

• Web : plateforme e-learning Next.js 15 (id 33), albums photo pro (id 35), plugin WordPress (id 16).
• Mobile Flutter : PANIGASPI (id 7), FocusLock (id 28), Tontineo (id 30).

Sous le seuil de 5 fiches par segment, aucun agrégat tarifaire n'est publié — seule la grille commerciale publique s'applique. Cette règle de transparence est notre réponse au « combien coûtent vos projets réels ? » : au-delà des cas documentés, nous publions les grilles, pas des moyennes inventées.

Sources

• Grilles publiques : src/data/servicesData.ts (s2 web, s3 mobile), 2026.
• Fiches portfolio : ids 7, 16, 28, 30, 31, 32, 33, 35.
• Registre BOVO : docs/seo/data-evidence/register.json.

Conclusion

Pour une PME en 2026, la réponse n'est presque jamais « l'app d'abord ». Commencez par un site web trouvable (2 000 à 5 000 €), validez l'usage, puis ajoutez une application Flutter (2 000 à 5 000 €) dès que la répétition et les notifications justifient le téléchargement. L'application n'est pas un budget — c'est la conséquence d'un usage prouvé.

En résumé : site web seul si l'on veut être trouvé, site + PWA si l'usage s'esquisse, écosystème complet (site + app + admin) si l'usage est déjà prouvé. Et dans tous les cas : comptez le coût annuel (maintenance, acquisition, stores), pas seulement la construction.

Suite : prix d'un site web sur mesure, prix d'une application mobile Flutter, ou choisir une agence de développement mobile.