Votre idée dans toutes les poches.
Une app mobile n'est pas un site mobile-friendly. C'est un produit à part entière — avec ses contraintes (stores, permissions, batterie, offline), ses codes UX (navigation gestuelle, haptic feedback, notifications), et ses business models (in-app purchase, abonnement, pub). Notre méthode couvre le choix natif vs cross-platform, la publication stores et la maintenance sur plusieurs années.
Ce que couvre ce guide
Les 6 piliers à maîtriser
Natif vs cross-platform : qui gagne en 2026
React Native (Expo) et Flutter couvrent la plupart des besoins PME : code unique iOS et Android, time-to-market réduit, maintenance plus simple. Natif (Swift / Kotlin) reste pertinent pour les apps à forte exigence perf (jeux, vidéo, AR/VR) ou accès profond aux APIs système (HealthKit, Wallet, CarPlay, Android Auto).
UX mobile-first : les codes à respecter
Les patterns diffèrent entre iOS (bottom tabs, back gesture, haptic feedback) et Android (Material Design 3, bottom nav, back stack). À éviter : hamburger menu (taux d'utilisation très faible), touch targets sous 44 pt, latence perceptible au tap. À favoriser : skeleton screens au lieu de spinners, gestion offline avec SWR ou React Query.
Notifications push : utiles vs spam
Une notification push a un coût : un refus utilisateur = perte définitive du canal (iOS opt-in rate modéré). Stratégie : ne demander la permission qu'après le premier moment de valeur (onboarding complété), segmenter (transactionnel vs marketing), laisser l'utilisateur choisir les sujets, respecter le rythme (rare). Outils : OneSignal, Firebase Cloud Messaging, Expo Notifications.
Publication stores : ce qui bloque
L'App Store rejette une partie non négligeable des premières soumissions. Causes fréquentes : permissions demandées sans justification claire, IAP contournées, crash au lancement, données santé sans HealthKit, screenshots non conformes, références externes à des achats. Le Play Store est plus permissif mais cache mieux les apps récentes. Notre process : checklist avant soumission.
Offline-first et synchronisation
Les utilisateurs sont souvent en mauvaise connexion (métro, campagne, roaming). Une app qui ne marche qu'en ligne frustre. Pattern offline-first : cache local (SQLite, MMKV, AsyncStorage), queue de synchronisation, résolution des conflits (last-write-wins, CRDTs, merge manuel). Librairies : WatermelonDB, RxDB, PowerSync.
In-app purchase et abonnements
Apple et Google prennent une commission sur les IAP (commission réduite sous certains seuils ou pour les small business programs). Outils pour gérer proprement abonnements, essais gratuits, upgrades et churn : RevenueCat, Adapty. Tracking côté backend obligatoire pour pouvoir réagir aux events (cancel, refund, pause).
Comment nous procédons
Spécification + choix techno
Cadrage fonctionnel, personas, choix natif vs cross-platform justifié par les contraintes (perf, API système, équipe), choix des OS ciblés et versions minimum supportées.
Design mobile
Wireframes en respectant les Human Interface Guidelines Apple + Material Design Google, prototypes Figma testables sur device réel, micro-interactions, design system mobile.
Développement + QA
Sprints courts, tests automatisés (Jest, Detox, Maestro), recettage manuel sur appareils réels représentatifs (iPhone SE à Pro Max, entry-level Android jusqu'au flagship).
Soumission stores
Compte App Store Connect et Play Console configurés, métadonnées optimisées (ASO), screenshots conformes, textes de localisation, build de production via fastlane, passage de la review.
Monitoring + mises à jour
Crashlytics, Sentry ou Bugsnag pour tracker les crashs, analytics (Firebase, Amplitude), mises à jour régulières, réponse aux avis stores, roadmap d'évolution.
Mythes vs réalité
Ce qu'on entend souvent, et ce qui se passe vraiment dans nos projets.
Mythe
« iOS est plus compliqué à développer qu'Android. »
Réalité
Le développement natif iOS (Swift + Xcode) est souvent plus rapide en solo grâce à l'homogénéité matérielle. Android doit gérer des milliers d'appareils différents, des fragmentations OS, des skins fabricants. Pour les petits projets natifs, iOS peut être plus simple. Pour cross-platform, Android se rapproche.
Mythe
« Une PWA suffit à la place d'une vraie app. »
Réalité
Une PWA installable couvre de nombreux cas et économise les frais de dev natif. Mais elle reste limitée : pas de publication store (découverte réduite), notifications push plus fragiles sur iOS, pas d'accès Bluetooth complet, pas de HealthKit ni d'Apple Pay natif. Pour de l'engagement long terme, une vraie app reste supérieure.
Mythe
« L'App Store rejette les apps aléatoirement. »
Réalité
Les rejets sont quasi toujours documentables : section 4.3 (apps spam), 3.1.1 (contournement IAP), 2.1 (crash), 5.1.1 (permissions injustifiées). Apple publie la section exacte du guideline en cause. Avec une checklist pré-soumission sérieuse, le taux de rejet drops. Le Play Store est similaire mais moins verbeux.
Mythe
« Cross-platform = performance inférieure. »
Réalité
Plus vrai en 2026. React Native (New Architecture + JSI + Hermes) et Flutter atteignent des performances très proches du natif sur la majorité des scénarios. Shopify a migré son app de native vers React Native. Instagram, Discord, Bloomberg tournent sur React Native. Les cas où le natif gagne vraiment sont des niches : 3D, vidéo intensive, AR/VR.
Services complémentaires
Notre blog sur le sujet
Trouvez la page qui correspond
Villes desservies