CookiesNous déposons des cookies de mesure d’audience (Google Analytics) pour comprendre comment le site est utilisé. Rien n’est déposé sans votre accord.
Applications mobiles
Native, hybride ou PWA : on vous dit laquelle correspond à votre projet, puis on la développe. Une seule base de code, iPhone et Android, publiée sur les stores.
L’essentiel
Une application mobile se développe de quatre façons : native, cross-platform, hybride ou PWA. Elles diffèrent par le nombre de codes à écrire et à maintenir, l’accès au matériel du téléphone et le passage par les stores.
Un code Swift pour iPhone, un code Kotlin pour Android. Deux codes à écrire, deux codes à maintenir. En échange : les meilleures performances et l’accès à tout le matériel du téléphone.
Un seul code, compilé pour les deux stores. C’est aujourd’hui le choix par défaut de la grande majorité des applications métier.
Un site web emballé dans une coquille native. Le moins cher pour être présent sur les stores, et celui qui se voit le plus à l’usage.
Un site web installable depuis le navigateur. Ni store, ni commission — mais un accès au matériel limité et une visibilité très faible sur iPhone.
Le vrai arbitrage ne porte pas sur la technologie mais sur trois questions : combien vous coûte la deuxième plateforme, de quel matériel vous avez besoin, et si vos utilisateurs vont réellement installer quelque chose. Le tableau ci-dessous répond aux deux premières, le sélecteur plus bas répond à la troisième.
Le comparatif
Fourchettes indicatives pour une application de production, back-end compris. Le détail du chiffrage est sur notre page combien coûte une application mobile.
Dans le détail
Un code Swift pour iPhone, un code Kotlin pour Android. Vous écrivez deux fois, vous testez deux fois, vous maintenez deux fois. En échange, vous obtenez ce que la plateforme fait de mieux : des animations parfaitement fluides, l’accès à tous les capteurs, et une intégration complète avec le système — widgets, montre connectée, raccourcis vocaux.
Le vrai coût du natif n’est pas le développement initial, c’est la maintenance. Chaque évolution, chaque correctif, chaque mise à jour de système est à traiter deux fois, pendant toute la vie de l’application. C’est ce qui explique l’écart de budget sur trois ans, bien plus que le devis de départ.
Un seul code, compilé pour les deux stores. Contrairement à l’hybride, il n’y a pas de navigateur caché à l’intérieur : React Native pilote directement les composants natifs du téléphone, et Flutter dessine son interface avec son propre moteur graphique. Résultat : l’utilisateur ne distingue pas une application cross-platform d’une application native, et surtout, il ne cherche pas à le faire.
C’est notre choix par défaut chez OTTOPILOTE. Pour une application métier — comptes, données, formulaires, paiements, notifications — le cross-platform livre le même produit qu’un développement natif pour un budget et une maintenance divisés par deux.
Un site web enfermé dans une coquille native, affiché par un navigateur invisible. C’est la solution la moins chère pour être présent sur les stores, et c’est aussi celle qui se remarque : le défilement accroche légèrement, les transitions ne sont pas tout à fait celles du système, l’application se comporte comme un site.
Attention au vocabulaire. Beaucoup d’agences vendent du « hybride » en parlant en réalité de Flutter ou de React Native, qui n’ont rien à voir sur le plan technique. Demandez toujours quelle technologie exacte sera utilisée : l’écart de qualité perçue est réel, l’écart de prix aussi.
Un site web que l’utilisateur installe sur son écran d’accueil depuis son navigateur. Il s’ouvre en plein écran, sans barre d’adresse, fonctionne hors ligne, et se met à jour tout seul : vous déployez, tout le monde a la nouvelle version. Pas de validation Apple, pas de commission sur les paiements, et un contenu que Google peut indexer.
Le point que peu d’agences vous diront sur iPhone : les notifications push fonctionnent depuis iOS 16.4, mais uniquement si l’utilisateur a lui-même ajouté la PWA à son écran d’accueil via le menu Partager. En pratique, presque personne ne le fait spontanément. Si les notifications sont au cœur de votre usage et que vos clients sont majoritairement sur iPhone, la PWA n’est pas le bon choix — et c’est la seule vraie raison de l’écarter.
Le raccourci
Répondez en trente secondes — on vous dit quelle approche correspond à votre projet, et pourquoi.
Votre usage est ponctuel et ne dépend ni du matériel ni des notifications : demander à vos clients de télécharger une application ajouterait une friction pour un bénéfice faible. Une PWA vous coûtera deux à quatre fois moins cher, restera trouvable sur Google, et pourra évoluer vers une vraie application plus tard si l’usage décolle.
Usage régulier, iPhone et Android à couvrir, budget à tenir : une base de code unique en Flutter ou React Native vous donne le même produit qu’un développement natif, pour un budget et une maintenance divisés par deux. C’est ce qu’on recommande à la majorité de nos clients.
Vos besoins matériels ou de performance sortent du périmètre confortable du cross-platform. C’est plus cher, et c’est assumé : mieux vaut payer le bon outil que reprendre le projet dans un an.
Avec un usage ponctuel et ce budget, une application mobile a peu de chances d’être rentable : il faut la faire télécharger, la faire garder, la faire rouvrir. Un site rapide et bien conçu obtiendra de meilleurs résultats pour moins cher. On préfère vous le dire avant le devis.
La question avant la question
Une application doit être téléchargée, gardée, puis rouverte. Trois étapes, et on perd des utilisateurs à chacune. Si votre service s’utilise deux ou trois fois par an, l’application native la mieux réalisée du monde finira désinstallée — alors qu’un site rapide aurait fait le travail.
Le test est simple : est-ce que vos clients ouvriraient ça au moins une fois par semaine ? Si la réponse est non, la bonne réponse n’est pas « native, hybride ou PWA ». C’est « pas encore d’application ». On préfère vous le dire avant le devis qu’après la mise en ligne.
Ce qu’on construit
Chacune répond à un usage précis. L’approche se choisit d’après cet usage, pas d’après la mode.
Interventions du jour, photos avant et après, signature du client, bon d’intervention : tout se remplit depuis le téléphone, y compris en zone blanche. La fiche part au bureau dès que le réseau revient.
Approche conseillée : cross-platform
Commander, payer, suivre une commande, prendre rendez-vous : vos clients ouvrent votre application plutôt que de vous appeler. La notification arrive sur l’écran du téléphone, là où un email attend dans une boîte.
Approche conseillée : cross-platform
Votre application web ou votre SaaS a déjà ses comptes et ses données. L’application mobile s’y connecte : valider une demande, consulter un dossier, recevoir une alerte, sans ouvrir un ordinateur.
Mêmes comptes, mêmes donnéesOuvrir →
Lire un badge NFC, dialoguer en Bluetooth avec un capteur, poser un objet en réalité augmentée : quand le cœur de l’application est le matériel du téléphone, le natif se justifie. On vous le dit dès le premier échange.
Approche conseillée : native
Réserver, consulter, commander quelques fois par an : un site qui s’installe sur l’écran d’accueil suffit. Pas de store, pas de commission, et un contenu que Google peut indexer.
Approche conseillée : PWA
Ce qui est inclus
Le choix de l’approche d’abord, écrit et argumenté. Puis tout ce qu’il faut pour que l’application vive sur les deux stores.
Méthode
Le délai typique d’une application cross-platform est de 8 à 12 semaines, de la première réunion à la publication sur l’App Store et Google Play. Voici comment elles se passent.
01S1
Ce que l’application doit faire, pour qui, sur quels téléphones. On tranche entre native, cross-platform, hybride et PWA, raisons écrites. Un périmètre, un prix plafonné.
02S2
Les écrans et les parcours dessinés et validés ensemble. Corriger une maquette coûte une réunion ; corriger un écran codé coûte des jours.
03S3 → S8
Back-end, comptes, écrans, notifications, connexions à vos outils. Une version à installer sur votre téléphone à chaque sprint.
04S9
Les parcours rejoués sur les deux plateformes, les écarts corrigés avant la soumission aux stores.
05S10 →
Soumission à l’App Store et à Google Play, mise en ligne, remise du code et des accès. Trente jours de corrections, puis suivi en option.
Technologies
Les briques qu’on emploie pour vos applications. Répandues, documentées, reprenables par une autre équipe si vous le souhaitez.
Budget
Les fourchettes indicatives du comparatif, approche par approche. Le devis, lui, part de votre projet.
Native
40 000 → 80 000 €
Cross-platform · notre choix par défaut
30 000 → 60 000 €
Hybride (WebView)
20 000 → 40 000 €
PWA
10 000 → 25 000 €
Fourchettes indicatives pour une application de production, back-end compris. Le détail du chiffrage est sur notre page « Combien coûte une application mobile ». Devis gratuit et plafonné sous 24 h.
Chez OTTOPILOTE
Une base de code, iPhone et Android, un budget et une maintenance divisés par deux par rapport au natif — pour un résultat que vos utilisateurs ne distinguent pas d’une application native.
Jeu, réalité augmentée, matériel pointu, intégration système poussée. On le dit dès le premier échange, parce que c’est plus cher et que vous devez savoir exactement pourquoi.
On le dit aussi. Vendre une application native à quelqu’un qui n’en a pas besoin, c’est gagner un projet et perdre un client.
Le prix maximal est connu avant de commencer : gratuit, plafonné, sous 24 h.
Code source, accès et documentation remis à la livraison, une fois le projet réglé. Vous restez libre de changer de prestataire ou de faire évoluer l’application en interne.
Une première lecture honnête, un ordre de grandeur et les premiers risques. Pas de PowerPoint, juste une réponse claire.
Questions fréquentes
Une autre question ? Écrivez-nous : réponse humaine sous 24 h ouvrées.
La native est écrite dans le langage de chaque plateforme : deux codes, les meilleures performances, le budget le plus élevé. L'hybride est un site web emballé dans une coquille native : un seul code, le budget le plus bas, une fluidité inférieure. La PWA est un site web installable depuis le navigateur, sans passer par les stores. Entre les deux, le cross-platform (Flutter, React Native) offre un code unique avec un rendu natif — c'est le meilleur compromis pour la plupart des projets.
La PWA, puis l'hybride, puis le cross-platform, puis le natif. Mais le bon critère n'est pas le prix du devis : c'est le coût sur trois ans. Une application native coûte environ 30 % de plus au départ, et surtout deux fois plus cher à faire évoluer, puisque chaque changement est à faire deux fois.
Pour un usage ponctuel — consulter, réserver, commander — oui, largement. Pour un usage quotidien qui repose sur les notifications, la géolocalisation en arrière-plan ou du matériel spécifique, non. La limite n'est pas la qualité de la PWA, c'est ce qu'iOS l'autorise à faire.
Oui depuis iOS 16.4, mais à une condition : l'utilisateur doit avoir ajouté la PWA à son écran d'accueil via le menu Partager de Safari. Tant qu'elle reste un simple onglet, aucune notification n'est possible. En pratique, très peu d'utilisateurs font cette manipulation seuls — c'est la principale limite des PWA sur iPhone.
Les deux sont matures et conviennent à la majorité des projets. React Native s'intègre naturellement si votre équipe travaille déjà en JavaScript ou TypeScript. Flutter donne un contrôle plus fin sur l'interface et un rendu identique sur les deux plateformes. Le choix dépend plus de votre écosystème existant que d'une supériorité technique de l'un sur l'autre.
Oui, et c'est souvent la bonne séquence. La PWA valide l'usage réel à moindre coût. Si les chiffres suivent, le passage au cross-platform ou au natif se fait avec un vrai socle de données et une connaissance précise de ce que vos utilisateurs font — au lieu de le deviner en amont.
Pour aller plus loin
Nos guides sur le développement mobile : les fourchettes de prix réelles, les délais, le choix technologique et les critères pour choisir un prestataire. Écrits pour décider, pas pour meubler.
Coût, performance, accès au matériel et hors-ligne : le comparatif pour trancher.
Fourchettes réelles, tarifs horaires et coûts cachés, avec la méthode pour estimer.
MVP, app standard, app complexe : les délais réels et les causes de dérapage.
De l’idée au lancement : validation, technologie, design, tests, publication.
Ce que recouvre le sur-mesure mobile, du design au dépôt sur les deux stores.
Sept critères, les questions à poser et le comparatif agence contre freelance.
Démarrer
Décrivez le projet en quelques minutes. On revient avec une première lecture honnête, un ordre de grandeur et les premiers risques. Pas de PowerPoint, juste une réponse claire.
OTTOPILOTE