Développement d'application mobile : décider avant de coder

À retenir

• Le choix natif ou cross-platform se décide sur vos fonctions clés — scan, hors-ligne, temps réel — pas par idéologie.
• Une app se justifie par les capacités mobiles : stores, push, hors-ligne, matériel. Sinon, une application web suffit souvent.
• Le bon chiffre n'est pas le devis mais le coût total de possession : OS, stores et maintenance font partie du budget.
• La publication n'est pas un détail : guidelines, revue Apple et Google, conformité — cela se prépare dès la conception.
• La propriété — code, dépôts, comptes développeur — doit être chez vous dès le premier jour.

En résumé : un projet mobile réussi commence par une question de pertinence honnête, se chiffre en TCO, choisit sa technologie sur des critères fonctionnels, et prévoit sa vie post-lancement avant la première ligne de code. La suite déroule ces décisions dans l'ordre où vous les rencontrerez.

Sommaire

• Natif ou cross-platform : la vraie question
• Quand une application mobile se justifie
• Quand il ne faut pas construire d'app
• Natif, cross-platform, PWA : le comparatif
• Coût et coût total de possession
• La publication sur les stores
• Maintenance et mises à jour d'OS
• Sécurité et données
• Cinq questions à poser avant de signer
• Trois apps, trois usages
• FAQ

Natif ou cross-platform : la vraie question

Le cross-platform — React Native, Flutter — écrit une seule base de code pour iOS et Android : délais raccourcis, budget mutualisé, évolutions synchrones. Le natif — Swift sur iOS, Kotlin sur Android — parle directement la langue de chaque plateforme : performances maximales, accès complet au matériel, expérience au pixel près.

La bonne question n'est pas « lequel est le meilleur ? » mais « qu'exigent vos fonctions clés ? ». Trois signaux poussent vers le natif : un usage intensif du matériel (scan, caméra, capteurs), un vrai mode hors-ligne, et le temps réel exigeant. Pour la majorité des applications métier et grand public, le cross-platform livre l'essentiel pour une fraction de l'effort — c'est le choix par défaut de notre offre de développement mobile, le natif restant l'outil des cas qui le méritent. Entre les deux frameworks eux-mêmes, le choix se joue sur votre équipe et vos fonctions clés — notre comparatif React Native vs Flutter déroule les critères.

Ce choix n'est pas définitif au niveau du produit : une app peut naître cross-platform pour valider son marché, puis migrer des modules critiques en natif. L'inverse — partir natif « pour être sûr » — coûte deux bases de code dès le premier jour.

Quand une application mobile se justifie

Une app n'est pas un badge de modernité : c'est un canal qui se mérite. Elle se justifie quand votre usage a besoin des capacités que seul le mobile offre :

• Vos utilisateurs reviennent plusieurs fois par semaine — l'icône sur l'écran d'accueil est un raccourci qui compte.
• Le service vit de notifications push : réservations, statuts de commande, alertes métier.
• Le terrain impose le hors-ligne : entrepôts, chantiers, zones blanches.
• Le matériel fait le service : caméra, scan, géolocalisation continue, paiement in-app.
• La présence sur les stores est un canal d'acquisition ou une exigence de vos clients.

FlySpa illustre le cas d'école : une plateforme de réservation de soins dont l'usage récurrent, le paiement intégré et les notifications justifient pleinement l'app — nous l'avons construite puis opérée comme un produit, pas comme un livrable.

Quand il ne faut pas construire d'app

L'honnêteté commerciale oblige : beaucoup de projets d'app devraient être des applications web. Trois contre-indications reviennent constamment.

L'usage est occasionnel. Un utilisateur qui vient une fois par trimestre ne télécharge pas une app — ou la supprime au premier nettoyage. Un site mobile-first ou une application web le sert mieux, sans friction d'installation.

Aucune capacité mobile n'est requise. Pas de push, pas de hors-ligne, pas de matériel : l'app n'apporte que des coûts — double publication, revue des stores, maintenance d'OS — sans bénéfice d'expérience.

Le budget ne couvre que la V1. Une app vit au rythme d'iOS et d'Android : sans budget de maintenance, elle se dégrade jusqu'au rejet de mise à jour. Mieux vaut un périmètre plus petit et vivant qu'une app complète et orpheline.

Natif, cross-platform, PWA : le comparatif

Ces options se combinent : beaucoup de produits vivent très bien avec une app cross-platform pour les utilisateurs récurrents et un web mobile soigné pour les autres.

Coût et coût total de possession

Les fourchettes d'abord : sur notre page service, les formats publiés démarrent à 29 900 CHF pour un MVP resserré, 59 900 CHF pour une application complète et 99 900 CHF pour un projet sur mesure complexe — le chiffre ferme sort toujours du cadrage, sur le périmètre réel. Notre guide du coût d'une application mobile détaille chaque facteur et le calcul complet.

Mais le devis n'est que le début de l'histoire. Le coût total de possession d'une app inclut ce que le mobile a de spécifique : les montées de version d'iOS et d'Android, la conformité continue aux exigences des stores, les correctifs sur appareils réels, et les évolutions produit. Le raisonnement TCO que nous détaillons pour le développement sur mesure s'applique au mobile avec un facteur de plus : vous ne contrôlez ni le rythme d'Apple ni celui de Google.

Cinq facteurs font bouger le chiffre : le nombre d'écrans et de parcours, les fonctions natives (paiement, scan, hors-ligne, temps réel), le back-office et les intégrations avec votre SI, le niveau de finition attendu, et la stratégie de test sur appareils réels.

La publication sur les stores

Publier n'est pas cliquer sur « envoyer ». L'App Store et Google Play imposent des guidelines — confidentialité, achats, contenu, permissions — et une revue qui peut rejeter une app pour un écran mal justifié. Cela se prépare dès la conception : choix des permissions, textes de confidentialité, fiches store, captures, conformité.

Chez PULSE, la mise en store fait partie du projet : préparation des fiches, soumission, suivi de la revue Apple et Google, itérations si nécessaire — sur vos comptes développeur, à votre nom. La présence store vous appartient au même titre que le code.

Maintenance et mises à jour d'OS

Une application mobile n'est jamais « finie » : iOS et Android évoluent chaque année, les API se déprécient, les exigences des stores se durcissent. Sans maintenance, une app accumule les avertissements, puis les rejets de mise à jour — et l'investissement initial se dégrade en silence.

C'est pourquoi le support post-lancement fait partie de l'offre : correctifs, montées de version, supervision des crashs, adaptation aux nouvelles versions d'OS. Pour les plateformes dont l'app n'est qu'une partie — back-office, API, données — l' exploitation managée complète le dispositif côté serveur.

Sécurité et données

Une app embarque souvent des données personnelles et transite par des API : la sécurité se conçoit, elle ne se rajoute pas. Authentification robuste, chiffrement en transit et au repos, gestion fine des permissions, stockage local maîtrisé — et côté conformité, la LPD suisse et le RGPD imposent de savoir ce qui est collecté, où, et comment l'effacer. Les stores le vérifient aussi : les fiches « confidentialité » d'Apple et Google engagent ce que votre app fait réellement.

Cinq questions à poser avant de signer

• « Natif ou cross-platform — et pourquoi pour mon cas ? » — la réponse doit citer vos fonctions clés, pas une préférence d'atelier.
• « Qui possède le code et les comptes développeur ? » — vous, contractuellement, dès le premier jour.
• « Comment testez-vous ? » — sur appareils réels, pas seulement en simulateur ; builds essayables chaque semaine.
• « Qui gère la revue des stores, et que se passe-t-il en cas de rejet ? » — la publication doit être une responsabilité du prestataire, pas la vôtre.
• « Que coûte l'année 2 ? » — un devis sans maintenance ni montées d'OS vend une V1, pas une application.

Ces questions valent pour tout le développement sur mesure — notre guide de décision logiciel les approfondit — mais au mobile, la dépendance aux plateformes les rend non négociables.

Trois apps, trois usages

FlySpa est l'app produit : réservation de soins à domicile, paiement intégré, parcours fluide — construite puis opérée dans la durée, avec la plateforme SaaS derrière.

RM26 est l'app d'audience : l'application officielle de Riyad Mahrez, où l'expérience de marque et l'engagement des fans dictent les choix — contenu riche, temps réel, robustesse en pics.

Migros Vaud est l'app événementielle : 75ᵉ anniversaire, fort trafic sur une fenêtre courte — un cas où la fiabilité sous charge et la simplicité du parcours priment sur tout le reste.

Questions fréquentes