Application mobile vs application web : quand créer laquelle (et combien cela coûte)

L'une des décisions les plus déterminantes que vous prendrez lors de la conception d'un produit numérique n'est pas le choix de la couleur de votre bouton d'appel à l'action, ni même celui de la base de données sous-jacente. C'est la question de savoir s'il faut créer une application mobile, une application web, ou quelque chose entre les deux — et la plupart des équipes tranchent trop vite, trop émotionnellement, ou en se laissant trop influencer par ce que font les concurrents en apparence.

Nous avons observé cette erreur plus de fois qu'il n'est possible de compter. Un fondateur nous arrive convaincu qu'il lui faut une application iOS dès le premier jour parce que « c'est ce qu'attendent les clients ». Six mois et 80 000 dollars plus tard, l'application est dans le store, elle enregistre deux téléchargements par semaine, et l'entreprise n'a plus de budget marketing pour alimenter l'acquisition. Nous avons également observé l'inverse — une société SaaS B2B qui repoussait son lancement parce qu'elle attendait d'avoir une couverture Android native complète, pendant que son application web, terminée et non testée, attendait dans un environnement de staging.

Le choix entre mobile et web n'est pas une question d'ambition ou de sophistication technique. C'est une question de savoir où se trouvent réellement vos utilisateurs, ce qu'ils ont besoin de faire, et ce que vous êtes en mesure de soutenir dans la durée. Répondez-y correctement et vous livrerez plus vite, dépenserez moins et toucherez davantage de personnes. Répondez-y mal et vous passerez des années à maintenir deux bases de code pour un produit qui aurait parfaitement fonctionné en tant que site web.

Ce guide est notre tentative honnête de vous transmettre le cadre que nous utilisons en interne lorsque nous conseillons nos clients. Nous définirons clairement les options, analyserons les compromis, partagerons des chiffres de coûts réels et vous fournirons un cadre décisionnel que vous pourrez appliquer à votre propre produit — dès aujourd'hui.

---

Les options définies

Avant de pouvoir comparer quoi que ce soit, nous devons nous accorder sur ce que nous comparons. Ces termes sont souvent utilisés de manière approximative, et cette imprécision coûte de l'argent.

Application mobile native (iOS et/ou Android)

Une application mobile native est conçue spécifiquement pour un système d'exploitation en utilisant ses outils et langages privilégiés. Les applications iOS sont développées en Swift ou Objective-C avec Xcode et les frameworks UIKit ou SwiftUI d'Apple. Les applications Android sont développées en Kotlin ou Java avec Android Studio et Jetpack Compose ou le système View de Google. Une application native s'exécute directement sur le système d'exploitation de l'appareil, dispose d'un accès complet à toutes les API matérielles, et est distribuée via l'App Store ou Google Play.

Les applications natives offrent les meilleures performances, l'accès le plus complet au matériel de l'appareil et l'expérience utilisateur la plus aboutie pour chaque plateforme. Elles sont également les plus coûteuses à développer, nécessitent la plus grande expertise, et aboutissent à deux bases de code entièrement séparées si vous souhaitez être présent sur les deux plateformes.

Application mobile multiplateforme (React Native / Flutter)

Une application multiplateforme est écrite dans une base de code partagée unique, mais compilée ou rendue de façon à fonctionner à la fois sur iOS et Android. Les deux frameworks dominants sont React Native (maintenu par Meta, écrit en JavaScript/TypeScript) et Flutter (maintenu par Google, écrit en Dart). Les deux produisent des applications distribuées via les stores et peuvent accéder à la plupart — mais pas à la totalité — des fonctionnalités natives de l'appareil.

Le développement multiplateforme est présenté comme « écrire une fois, exécuter partout », bien que, comme nous le verrons, cette promesse appelle de sérieuses nuances. L'attrait principal est le coût : une seule équipe, une seule base de code, deux plateformes.

Application web progressive (PWA)

Une Application Web Progressive est un site web construit selon les standards web modernes qui peut se comporter, à bien des égards, comme une application mobile native. Les PWA peuvent être ajoutées à l'écran d'accueil d'un utilisateur, fonctionner hors ligne, recevoir des notifications push (sur Android et — avec des limitations importantes — sur iOS), et accéder à certaines fonctionnalités matérielles telles que l'appareil photo et le GPS via les API du navigateur. Elles sont délivrées via le navigateur, et non via les stores, et se mettent à jour automatiquement sans action de l'utilisateur.

Les PWA occupent un véritable terrain intermédiaire. Elles sont moins coûteuses à développer que les applications natives et ne nécessitent ni présence dans un store ni processus d'approbation, mais elles présentent de réels manques en termes de capacités — notamment sur les appareils Apple — que nous détaillerons ci-dessous.

Application web responsive

Une application web responsive est une application basée sur un navigateur qui adapte sa mise en page à différentes tailles d'écran — bureau, tablette et mobile — sans chercher à reproduire l'expérience d'une application native. Elle est accessible via une URL, nécessite une connexion internet pour fonctionner, et est utilisée depuis un navigateur. C'est la norme pour la grande majorité des outils B2B, des tableaux de bord SaaS, des panneaux d'administration et des systèmes métier internes.

Les applications web responsives sont le choix par défaut pour la plupart des produits. Elles sont les moins coûteuses à développer, les plus rapides à itérer, ne nécessitent aucune approbation de la part des gardiens des plateformes, et sont accessibles sur tout appareil disposant d'un navigateur sans code supplémentaire.

---

Quand l'application mobile native s'impose

Il existe des catégories claires de produits pour lesquels le mobile natif n'est pas une préférence — c'est une exigence. Si votre produit entre dans l'une de ces catégories, nous vous recommanderons sans hésitation de développer en natif.

L'accès au matériel est au cœur de votre produit. Si votre application nécessite un suivi GPS en continu, des services de localisation en arrière-plan, le traitement en temps réel de la caméra, des paiements NFC ou la lecture de tags, des connexions Bluetooth Low Energy, une authentification biométrique au-delà des simples invites Face ID, ou l'accès à des capteurs de santé tels que la fréquence cardiaque depuis Apple Watch ou Android Wear — vous avez besoin du natif. La plateforme web a réalisé des progrès significatifs en matière d'accès aux appareils ces dernières années, mais les API natives restent nettement plus performantes, plus fiables et mieux prises en charge. Une application de suivi de livraison, une application compagnon pour dispositif médical, un outil de paiement sans contact — ces applications ne sont pas optionnellement natives. Elles sont natives parce qu'elles ne peuvent pas l'être autrement.

Le fonctionnement hors ligne est une exigence fondamentale, pas un simple atout. Si vos utilisateurs travaillent régulièrement dans des environnements à faible connectivité ou sans connectivité — agents de terrain, opérateurs logistiques, géomètres en zone isolée, pilotes — et que votre application doit traiter des données, gérer des états complexes et se synchroniser de manière fiable lors du rétablissement de la connexion, le natif vous offre des outils nettement plus robustes pour cela. Les service workers dans les PWA gèrent les fonctionnalités hors ligne pour de nombreux cas d'usage, mais SQLite natif, Core Data, Room et les primitives de synchronisation en arrière-plan sont plus puissants et mieux éprouvés à grande échelle.

Les notifications push sont le principal mécanisme d'engagement. Oui, les notifications push web existent. Oui, les PWA les prennent en charge sur Android. Mais si l'intégralité de votre modèle d'engagement produit repose sur des notifications push fiables et ponctuelles — une application de messagerie, un outil de collaboration en temps réel, une plateforme de trading en direct — le push natif via APNs et FCM reste la voie de délivrance la plus fiable. Le web push sur iOS, introduit avec iOS 16.4, s'est amélioré, mais comporte des restrictions qui n'existent pas en natif.

Vous développez un jeu, une expérience AR/VR ou toute application gourmande en calcul. WebGL et WebAssembly ont considérablement étendu les capacités graphiques du navigateur, mais pour les expériences sensibles à la latence et intensives en GPU, le natif dispose encore de la marge de performance, de l'accès à Metal et Vulkan, et de la maturité de la chaîne d'outils dont vous avez besoin.

Votre principal canal d'acquisition est l'App Store. Si l'« App Store Optimisation » est véritablement votre levier de croissance attendu — si la découverte organique dans le store fait partie de votre stratégie de mise sur le marché — alors vous devez être présent dans le store. Une PWA installée depuis le navigateur n'apparaît pas dans les résultats de recherche de l'App Store. Si votre modèle économique requiert une distribution via les plateformes d'Apple ou de Google, le natif ou le multiplateforme est votre seule véritable option.

---

Quand une application web suffit

Pour un nombre étonnamment élevé de produits, une application web fait tout ce qui est nécessaire — souvent mieux qu'une application native, car elle supprime entièrement les frictions de distribution.

La plupart des outils B2B et des logiciels internes. Si vos utilisateurs sont des employés, des prestataires ou des clients professionnels qui accèdent à votre produit principalement depuis un bureau — même s'ils l'utilisent occasionnellement sur un téléphone — une application web responsive est presque toujours suffisante. Outils d'approvisionnement, plateformes RH, logiciels de gestion de projet, tableaux de bord CRM, systèmes de reporting financier : ces produits vivent dans des onglets de navigateur. Une application native pour un outil B2B crée une seconde surface de maintenance sans bénéfice clair pour l'utilisateur.

Tableaux de bord, panneaux d'administration et outils de reporting. Ce sont fondamentalement des interfaces riches en données et légères en interactions. Ils nécessitent souvent de grands écrans pour être véritablement utilisables, ce qui fait du mobile une plateforme secondaire au mieux. Développez bien l'application web. Rendez-la responsive. Ne créez pas d'application native pour un tableau de bord que personne n'utilisera de toute façon sur son téléphone.

Systèmes de réservation, de planification et de prise de rendez-vous. Les utilisateurs y accèdent via un lien — depuis un e-mail, un SMS, un QR code, un résultat de recherche. Le flux de réservation est court, la session est peu fréquente, et il n'y a aucune raison impérieuse de demander à un utilisateur d'installer une application pour un flux qu'il complète en trois minutes. Une page web rapide et optimisée pour mobile surpasse une application dans ce contexte simplement parce qu'elle supprime la barrière d'installation.

Les produits en phase de démarrage. Si vous validez une idée commerciale, testez la demande ou développez un MVP que vous prévoyez d'itérer rapidement, commencez par une application web. Vous avancerez plus vite, dépenserez moins et disposerez de plus de flexibilité. Vous pouvez toujours ajouter une application native plus tard, lorsque vous saurez ce que le produit doit réellement être. Nous aborderons la question de la séquence dans la FAQ en fin d'article.

Tout produit dont les utilisateurs arrivent via un lien, un e-mail ou une recherche. Si la découverte et l'accès se font via le navigateur — si votre trafic provient principalement du référencement, de l'e-mail ou de la recherche organique — une application web rencontre vos utilisateurs exactement là où ils se trouvent. Les forcer à passer par l'App Store avant de pouvoir utiliser votre produit est un tueur de conversion.

---

Les applications web progressives — Le terrain intermédiaire

Les PWA ont considérablement mûri depuis que Google a porté le concept en 2015. Lorsque nous les décrivons à nos clients, nous veillons à être précis aussi bien sur ce qu'elles peuvent faire que sur leurs limites actuelles, car l'écart entre « ce qu'une PWA peut faire en théorie » et « ce qu'elle peut faire de manière fiable sur un iPhone » demeure réel.

Ce qu'une PWA peut véritablement faire

• Fonctionnalité hors ligne — grâce aux service workers et à l'API Cache, une PWA peut mettre en cache des ressources, stocker des données dans IndexedDB et présenter une interface fonctionnelle lorsque le réseau est indisponible
• Installation sur l'écran d'accueil — sur Android via une invite du navigateur, et sur iOS via l'option « Ajouter à l'écran d'accueil » dans Safari, une PWA peut être installée comme icône sur l'écran d'accueil et lancée dans une fenêtre autonome
• Notifications push — sur Android, les notifications push des PWA fonctionnent de manière fiable via le service push du navigateur. Sur iOS (Safari 16.4+), le web push est désormais pris en charge, mais avec des mises en garde concernant la délivrance en arrière-plan et le regroupement des notifications
• Accès à l'appareil photo et au microphone — via l'API MediaDevices, les PWA peuvent accéder à l'appareil photo et au microphone. Cela est suffisant pour la capture de photos, la lecture de QR codes et les appels vidéo basiques
• Géolocalisation — fonctionne dans les PWA sur tous les principaux navigateurs, adaptée aux fonctionnalités de localisation
• Mises à jour automatiques — aucune action de l'utilisateur n'est requise. Lorsque vous déployez une nouvelle version, les utilisateurs la reçoivent lors de leur prochaine visite

Ce qu'une PWA ne peut toujours pas faire

• La synchronisation en arrière-plan sur iOS est limitée. La synchronisation en arrière-plan des service workers n'est pas entièrement prise en charge sur iOS Safari, ce qui signifie qu'une synchronisation fiable des données en arrière-plan — celle qu'une application de messagerie ou un gestionnaire de tâches requiert — n'est pas réalisable sans natif
• Aucune présence dans les stores. Les PWA ne peuvent pas être soumises à l'App Store d'Apple ni à Google Play. Cela signifie pas de découverte organique dans le store, pas d'avis dans le store, et aucune possibilité d'atteindre les utilisateurs qui n'acquièrent des applications que par ces canaux
• Aucun accès au NFC, au Bluetooth (de manière significative) ni aux API de santé avancées
• Traitement en arrière-plan limité. Les tâches qui doivent s'exécuter lorsque l'application n'est pas au premier plan — suivi de localisation, contrôles de métadonnées pour la lecture audio, interrogation de capteurs — sont restreintes dans les contextes web

Quand une PWA est le bon choix

Une PWA est le bon choix lorsque vous avez besoin d'une prise en charge hors ligne, d'une installation sur l'écran d'accueil ou de notifications push basiques, mais que vous n'avez pas besoin d'une présence dans les stores et que vos exigences matérielles se limitent à la caméra et au GPS. Une application de commande de repas pour un groupe de restaurants spécifique, un outil de collecte de données sur le terrain pour le personnel interne, un portail client pour une entreprise de services — ce sont de bons candidats pour une PWA. Vous obtenez 80 % de l'expérience d'une application native pour 40 à 50 % du coût.

---

Multiplateforme vs natif — Les véritables compromis

L'argumentaire pour React Native et Flutter est simple : écrire une base de code, livrer sur iOS et Android, économiser de l'argent. En pratique, la réalité est plus nuancée.

React Native

React Native permet aux développeurs JavaScript/TypeScript de créer des applications mobiles en utilisant une approche orientée composants de style React, avec un pont vers les API de plateforme native. L'expérience développeur s'est considérablement améliorée depuis ses débuts — le moteur Hermes, la nouvelle architecture (Fabric) et l'écosystème de bibliothèques tierces en font un choix crédible pour une large gamme d'applications.

React Native fonctionne bien pour : les applications avec des modèles d'interface standard, les équipes ayant une expertise existante en JavaScript/React, les produits pour lesquels la rapidité de mise sur le marché prime sur un rendu pixel-perfect spécifique à chaque plateforme.

React Native montre ses limites pour : les animations personnalisées complexes, l'intégration matérielle profonde, les applications qui doivent sembler véritablement natives sur les deux plateformes simultanément, et les grandes équipes travaillant sur la même base de code sans une discipline rigoureuse.

Flutter

Flutter adopte une approche différente — il rend sa propre interface entièrement, en contournant les widgets natifs de la plateforme. Cela le rend extrêmement cohérent entre les plateformes et très performant pour le rendu de l'interface, mais cela signifie que votre application n'aura pas exactement l'apparence et le comportement d'une application iOS ou Android native. Google a beaucoup investi dans Flutter, qui compile désormais vers iOS, Android, web, bureau et des cibles embarquées depuis une seule base de code.

Flutter fonctionne bien pour : les équipes à l'aise avec Dart, les applications pour lesquelles la cohérence visuelle entre les plateformes prime sur les conventions spécifiques à chaque plateforme, et les produits qui ont également besoin d'une version bureau ou web.

Flutter montre ses limites pour : les applications où les utilisateurs attendent les conventions de la plateforme native (comme les gestes de navigation spécifiques à iOS), l'intégration profonde avec les SDK iOS ou Android natifs, et l'écosystème de bibliothèques — bien qu'en croissance — plus restreint que celui de React Native.

Le mythe du partage de code à 70–80 %

Les équipes React Native et Flutter citent régulièrement un partage de code de 70 à 80 % entre les plateformes comme avantage phare. C'est techniquement exact et pratiquement trompeur. Les 20 à 30 % spécifiques à chaque plateforme tendent à être les plus difficiles — pipelines caméra, gestion des notifications push, deep linking, modes d'exécution en arrière-plan et code d'intégration aux stores. Les 70 % partagés sont principalement des composants d'interface et de la logique métier, ce qui est réellement précieux, mais vous ne devriez pas planifier un budget en supposant obtenir deux applications natives pour le prix d'une. Un projet multiplateforme réaliste coûte environ 60 à 70 % du coût de deux applications natives séparées, pas 50 %.

---

Comparaison des coûts

Ces fourchettes sont réalistes et basées sur notre propre expérience de livraison de projets et sur les tarifs actuels du marché. « MVP » désigne ici une première version complète et livrable — pas un produit finalisé et riche en fonctionnalités.

Plateforme	Coût de développement MVP (USD)	Délai	Maintenance courante (annuelle)
Application web responsive	15 000 $ – 60 000 $	8–20 semaines	5 000 $ – 20 000 $
Application web progressive (PWA)	20 000 $ – 70 000 $	10–22 semaines	6 000 $ – 22 000 $
React Native (iOS + Android)	55 000 $ – 150 000 $	18–36 semaines	18 000 $ – 45 000 $
Flutter (iOS + Android)	50 000 $ – 140 000 $	16–34 semaines	16 000 $ – 40 000 $
iOS natif + Android natif (séparés)	100 000 $ – 280 000 $+	28–52 semaines	30 000 $ – 80 000 $

Quelques remarques sur ces chiffres. La fourchette pour les applications web est large parce que la complexité varie énormément — un simple système de réservation à 15 000 $ est un produit très différent d'une plateforme SaaS multi-locataires à 60 000 $. Les fourchettes React Native et Flutter supposent une équipe de deux à trois développeurs plus design et assurance qualité. La fourchette iOS natif + Android natif suppose deux flux de développement séparés fonctionnant en parallèle ; les mener séquentiellement augmente les délais mais peut réduire les coûts de 15 à 20 % grâce aux ressources de design et aux travaux d'API partagés.

Les coûts de maintenance comprennent les mises à jour de compatibilité avec les versions du système d'exploitation, les mises à jour des dépendances, les corrections de bugs et les ajouts de fonctionnalités mineures. Ils n'incluent pas le développement de fonctionnalités majeures.

---

Coûts et contraintes des stores

Si vous envisagez de distribuer via l'App Store d'Apple ou Google Play, vous devez comprendre les coûts de plateforme au-delà de l'investissement de développement — car ils affectent votre modèle économique de manière potentiellement décisive.

Apple prélève une commission de 30 % sur les achats intégrés et les abonnements. Si votre application propose des fonctionnalités payantes vendues au sein de l'application — abonnements, crédits, contenus numériques — Apple prend 30 % (ou 15 % pour les petits développeurs et les abonnements en deuxième année). Pour un produit SaaS à 50 $/mois d'abonnement, cela représente 15 $ par utilisateur par mois prélevés avant même de payer un seul coût opérationnel. De nombreux produits B2B évitent délibérément les achats intégrés pour cette raison, en orientant les utilisateurs vers un paiement web à la place. Les directives d'Apple sont de plus en plus strictes à ce sujet — le DMA dans l'UE a modifié certaines règles pour les utilisateurs européens, mais à l'échelle mondiale, la structure de commission reste en vigueur pour la plupart des catégories.

Les délais de révision dans les stores sont réels et imprévisibles. Le processus de révision d'Apple prend en moyenne deux à quatre jours, mais peut être plus long, et un rejet peut repousser votre calendrier de publication d'une semaine ou plus. Si votre produit nécessite une itération rapide — correctifs urgents, tests A/B, feature flags — le cycle de révision de l'App Store crée des frictions qu'une application web n'a tout simplement pas. Nous avons eu des clients perdre des revenus significatifs pendant une période de vente critique parce qu'un correctif de bug était en attente de révision dans l'App Store. Ce risque n'existe pas sur le web.

Les restrictions des directives peuvent forcer des décisions architecturales. Apple dispose de règles explicites sur ce que les applications peuvent et ne peuvent pas faire — comment elles doivent gérer la suppression des données utilisateur, comment elles doivent présenter les conditions d'abonnement, quelles catégories de contenus sont autorisées, et de plus en plus, quels modes de paiement sont admissibles. Si votre produit est proche d'une catégorie réglementée ou sensible, vous pourriez constater que les directives de l'App Store façonnent votre feuille de route produit d'une manière que vous n'aviez pas anticipée.

Pour certains produits — notamment les marketplaces, les plateformes médias et les produits avec des modèles de tarification complexes — les contraintes de l'App Store constituent un argument fort en faveur de faire de l'application web le produit principal, l'application mobile jouant un rôle de canal complémentaire plutôt que de canal principal.

---

La réalité de la maintenance

Lorsque les équipes comparent les coûts de développement, elles oublient souvent que le coût de livraison n'est pas le coût de possession. Une application mobile native sur les deux plateformes crée des obligations continues qu'une application web n'impose pas.

Les mises à jour des versions du système d'exploitation sont obligatoires, pas optionnelles. Apple et Google déprécient les anciennes API, modifient leurs conventions d'interface et introduisent de nouvelles exigences système à chaque version majeure du système d'exploitation. Chaque automne apporte une nouvelle version d'iOS, et votre application devra être testée, mise à jour et soumise à nouveau pour rester fonctionnelle et conforme aux dernières directives. Ignorer ces mises à jour signifie que votre application cessera de fonctionner sur les nouveaux appareils, sera retirée du store pour non-conformité, ou développera des régressions visuelles et comportementales qui nuisent à la confiance des utilisateurs. Ce n'est pas un coût ponctuel — c'est un engagement permanent et récurrent.

Deux applications natives signifient deux flux de maintenance. iOS et Android se mettent à jour selon des cycles indépendants. Une modification qui fonctionne sur une plateforme nécessite parfois un correctif séparé sur l'autre. Les bibliothèques tierces dont dépend votre application peuvent être maintenues selon des calendriers différents pour chaque plateforme. Sur un cycle de vie produit de trois à cinq ans, le coût cumulatif de maintenance de deux applications natives peut égaler, voire dépasser, le coût de développement initial.

Les applications web se mettent à jour instantanément et silencieusement. Lorsque vous déployez un correctif ou une nouvelle fonctionnalité dans une application web, chaque utilisateur le reçoit au prochain chargement de la page. Pas de processus de révision, pas de fragmentation de version, pas d'utilisateurs tournant sous une version de votre produit datant de deux ans parce qu'ils n'ont pas mis à jour leur téléphone. Pour les équipes fonctionnant en cycles de développement itératif, c'est un avantage opérationnel significatif.

---

Notre cadre de recommandation

Utilisez ces questions dans l'ordre. Répondez honnêtement en vous basant sur votre produit tel qu'il existe aujourd'hui, et non tel que vous imaginez qu'il pourrait un jour devenir.

1. Vos fonctionnalités principales nécessitent-elles un accès matériel uniquement disponible en natif ? (GPS en arrière-plan continu, NFC, Bluetooth LE, API caméra avancées, capteurs de santé) — Si oui, développez en natif ou en multiplateforme. Si non, continuez.

2. Le fonctionnement hors ligne est-il une exigence fondamentale, pas seulement un atout ? (Les utilisateurs travaillent régulièrement dans des environnements sans connectivité et ont besoin de toutes les fonctionnalités de l'application) — Si oui, envisagez le natif ou le multiplateforme. Si non, continuez.

3. L'App Store est-il votre principal canal d'acquisition d'utilisateurs ? (Votre modèle de croissance repose sur la découverte organique dans le store) — Si oui, vous devez être présent dans le store. Si non, continuez.

4. Vos utilisateurs sont-ils principalement sur mobile, et interagissent-ils avec votre produit plusieurs fois par jour ? (Votre produit est une application grand public à usage quotidien, pas un outil occasionnel) — Si oui, envisagez une PWA ou une application multiplateforme. Si non, continuez.

5. Avez-vous besoin de notifications push comme mécanisme d'engagement fondamental ? — Si oui et que vous ciblez iOS, vous devrez choisir entre une application multiplateforme ou accepter les limitations du web push. Si non, continuez.

Si vous êtes arrivé à ce stade : une application web responsive est presque certainement votre meilleur point de départ. Développez-la bien, rendez-la rapide sur mobile, et revisitez la question de l'application mobile lorsque vos données utilisateur vous indiquent ce dont ils ont réellement besoin.

---

Comment nous abordons cette décision chez Cyberbeak

Notre recommandation par défaut est de commencer par une application web. Non pas parce que nous les préférons, et non pas parce qu'elles sont moins coûteuses à développer (bien que ce soit souvent le cas) — mais parce qu'elles éliminent une quantité considérable de risques aux premiers stades d'un produit.

Une application web peut être développée en deux fois moins de temps qu'une application native. Elle peut être mise à jour sans l'approbation d'un gardien. Elle atteint les utilisateurs sur tous les appareils sans leur demander d'installer quoi que ce soit. Et lorsque vient le moment d'ajouter une application mobile — parce que vous avez de vrais utilisateurs qui vous disent en avoir besoin, parce que vos données montrent que 80 % des sessions se font sur mobile et que l'engagement s'améliorerait réellement avec des fonctionnalités natives — vous l'ajouterez avec une connaissance du produit qu'une équipe démarrant en natif dès le premier jour ne possède tout simplement pas.

En pratique, les produits pour lesquels nous avons recommandé de démarrer avec une application mobile native dès le premier jour appartiennent à un petit nombre de catégories : les applications grand public pour lesquelles la découvrabilité dans l'App Store est centrale à la croissance, les produits qui ont véritablement besoin d'un accès matériel dès le premier jour, et les applications pour lesquelles le « ressenti » du produit est si central à la proposition de valeur que quoi que ce soit de moins que le natif le compromettrait.

Pour tout le reste — outils B2B, plateformes SaaS, systèmes de réservation et de planification, marketplaces, outils internes et produits grand public en phase de démarrage — nous commençons par le web, nous l'excellence, et nous construisons la couche mobile lorsque les données le justifient.

Lorsque le multiplateforme s'impose, nous privilégions React Native pour les équipes qui travaillent déjà en JavaScript, et Flutter lorsque le produit s'étend sur plusieurs plateformes (web, mobile et bureau) ou lorsque la cohérence visuelle est une exigence principale.

---

FAQ

Puis-je ajouter une application mobile plus tard si je commence par une application web ?

Oui, et c'est généralement la bonne séquence. Commencer par une application web ne ferme aucune option — cela vous donne les données utilisateur et la clarté produit pour prendre la décision concernant l'application mobile de manière éclairée. La couche API que vous développez pour votre application web est la même couche API que votre application mobile consommera. La seule chose que vous devrez développer from scratch est le front-end mobile, et au moment où vous le ferez, vous saurez exactement ce qu'il doit accomplir.

Et React Native — n'est-il pas pratiquement aussi bon que le natif maintenant ?

React Native s'est considérablement amélioré et constitue un framework véritablement capable pour une large gamme d'applications. Pour les produits avec des modèles d'interface standard et sans exigences matérielles profondes, il produit des résultats indiscernables du natif pour la plupart des utilisateurs. Là où il reste en deçà, c'est dans les animations complexes, les gestes de navigation personnalisés qui donnent l'impression d'être vraiment natifs sur chaque plateforme, et les applications qui doivent repousser les limites de ce que la plateforme peut faire. Si la proposition de valeur de votre application repose substantiellement sur la qualité d'interaction de l'expérience, l'écart entre React Native et le natif peut avoir de l'importance. Pour la plupart des applications métier, ce ne sera pas le cas.

Dois-je développer à la fois une application web et une application mobile en même temps ?

Presque jamais, au démarrage. Développer les deux simultanément double votre coût front-end, double votre surface d'assurance qualité, divise l'attention de votre équipe, et vous force à prendre des décisions de design pour les deux plateformes avant d'avoir des retours utilisateurs. L'exception est lorsqu'il existe un cas clairement validé pour les deux — lorsque vous savez grâce à des recherches existantes que vous avez deux groupes d'utilisateurs distincts, l'un fermement sur bureau et l'autre fermement sur mobile, chacun ayant besoin du produit dans un contexte différent. Ce scénario existe, mais c'est la minorité. Commencez par l'un, apprenez, puis étendez.

Comment le choix mobile vs web affecte-t-il mon délai de lancement ?

Une application iOS native ajoute environ huit à seize semaines à un calendrier produit typique par rapport à l'application web équivalente, selon la complexité. Le multiplateforme ajoute quatre à dix semaines. Une PWA ajoute deux à quatre semaines par rapport à une application web responsive standard. Si vous êtes soumis à un délai — un événement de lancement spécifique, un jalon de financement, une fenêtre saisonnière — cette différence peut être décisive. Nous avons vu des produits manquer entièrement leur fenêtre de marché parce que l'équipe avait insisté sur une application native pour un lancement pour lequel une application web aurait été amplement suffisante.

Qu'en est-il des applications de bureau — est-ce une conversation séparée ?

En grande partie oui, bien qu'elle soit liée. La plupart des « applications de bureau » développées aujourd'hui sont soit des applications web fonctionnant sous Electron (essentiellement un navigateur packagé), soit de véritables applications de bureau natives pour Windows et macOS. Pour la plupart des logiciels métier, Electron ou une application web est suffisant. Des outils comme Notion, Figma, VS Code et Slack sont tous des applications Electron — les limitations de performances sont réelles mais acceptables pour la plupart des cas d'usage. Le développement de bureau véritablement natif (Swift pour macOS, WinUI pour Windows) est justifié pour les outils gourmands en calcul, les logiciels créatifs ou les produits pour lesquels l'intégration au système d'exploitation est essentielle. Flutter est également un choix crédible pour le bureau multiplateforme, particulièrement si vous l'utilisez déjà pour le mobile.

---

Si vous travaillez sur cette décision pour un produit et souhaitez un point de vue ancré dans ce que nous avons réellement développé et déployé, nous sommes disponibles pour en discuter. Nous ne privilégions pas une plateforme particulière — nous privilégions celle qui a le plus de sens pour ce que vous cherchez à accomplir. Contactez-nous et parlez-nous de votre produit.