Native, hybride ou PWA : comprendre les trois chemins vers votre application

Trois voies, trois budgets, trois relations aux plateformes

Il existe trois manières de mettre une application dans la main de quelqu’un. Elles sont souvent présentées comme un choix technique, réservé aux développeurs. C’est faux : c’est un choix stratégique, qui engage votre budget, votre autonomie et votre dépendance aux stores.

Voici les trois voies, expliquées comme nous les expliquons en rendez-vous : sans acronymes lâchés en l’air et sans faux suspense.

Le natif : construire deux fois, au plus près de la machine

Une application native est écrite dans le langage de la plateforme, Swift pour iOS et Kotlin pour Android. Elle parle directement au téléphone, sans intermédiaire.

Ce que cela vous donne

• La fluidité maximale : animations, défilement et transitions sont ceux du système, sans aucune couture perceptible.
• L’accès immédiat à tout ce que fait l’appareil : capteurs, Bluetooth, réalité augmentée, widgets, montres connectées.
• Le premier accès aux nouveautés : quand Apple sort une fonction, le natif l’utilise le jour même.

Ce que cela vous coûte

Deux bases de code, donc deux fois le travail, deux cycles de correction, deux maintenances. En pratique, le natif pur représente souvent près du double d’une approche mutualisée, développement et suivi confondus.

À privilégier quand l’application est le produit lui-même, que la performance graphique est centrale, ou que vous exploitez du matériel spécifique.

L’hybride multiplateforme : un code, deux stores

Ici, nous écrivons une fois et nous publions des deux côtés. Deux technologies dominent : React Native, issue de l’écosystème JavaScript, et Flutter, portée par Google.

Il faut lever une confusion fréquente : l’hybride moderne ne produit plus un site web déguisé. Les interfaces sont composées d’éléments réellement affichés par le système ou dessinés à haute performance. Un utilisateur ne fait généralement pas la différence.

Ce que cela vous donne

• Une seule base de code, donc un coût de développement et de maintenance nettement réduit.
• Une cohérence garantie entre les deux plateformes : une correction faite une fois est corrigée partout.
• Un écosystème mature pour la caméra, les cartes, le paiement et les notifications.

Ce que cela vous coûte

• Les fonctions les plus pointues nécessitent parfois un pont écrit en natif, donc du natif quand même sur une petite portion.
• Vous héritez d’une dépendance : quand la technologie évolue en profondeur, la migration est un chantier.
• Les performances graphiques extrêmes restent en dessous du natif pur.

À privilégier quand l’application est un outil métier, un service ou l’extension d’une activité existante. C’est-à-dire dans la grande majorité des projets d’indépendants, de TPE et de PME.

La PWA : l’application qui vit dans le navigateur

Une application web progressive est un site construit avec les capacités d’une application : installation sur l’écran d’accueil, fonctionnement hors ligne, notifications, mise en cache intelligente.

Ce que cela vous donne

• Aucun store : pas de compte développeur, pas de validation, pas de commission, pas de retrait arbitraire.
• Une seule base de code pour le web et le mobile.
• Une mise à jour instantanée : l’utilisateur recharge et dispose de la nouvelle version, sans attente ni parc fragmenté.
• Un coût de départ très inférieur.

Ce que cela vous coûte

• L’accès au matériel reste plus limité qu’en natif, en particulier sur iOS.
• L’installation depuis le navigateur est moins évidente pour beaucoup d’utilisateurs : il faut l’expliquer et l’accompagner.
• L’absence des stores prive d’un canal de découverte, réel pour certains publics.

À noter : une PWA peut être empaquetée pour être déposée sur Google Play. Vous obtenez alors un compromis assumé entre les deux mondes.

À privilégier quand votre application est essentiellement du contenu, des formulaires, de la consultation ou du suivi, et que vos utilisateurs y arrivent depuis votre site ou un lien direct.

Les trois erreurs que nous voyons le plus souvent

Choisir le natif par prestige. Le mieux, c’est ce qui sert le projet. Payer deux fois pour une application de prise de rendez-vous n’est pas de l’exigence, c’est du gaspillage.

Choisir la PWA pour le prix, sans vérifier l’usage. Si votre application a besoin du Bluetooth, de la caméra en continu ou de notifications critiques sur iOS, la PWA vous mettra dans le mur, après six mois de développement.

Ne pas décider du tout. Laisser le prestataire choisir ce qu’il maîtrise revient à optimiser son confort à lui, pas votre projet. Un bon interlocuteur vous explique les trois options, y compris celle qui l’arrange le moins.

Notre méthode

Nous ne partons jamais de la technologie. Nous partons de trois éléments : ce que l’application doit faire, qui l’utilisera, et ce que vous pourrez soutenir dans le temps. La technologie se déduit, elle ne se choisit pas d’avance.

Si vous n’avez pas encore cadré le besoin, commencez par les sept questions à se poser avant de se lancer. Si le cadrage est fait, la suite logique est la construction du budget. Notre page création d’application smartphone détaille la prestation, et un échange simple suffit souvent à trancher.