BlogTechnique · 5 octobre 2026

Application mobile : native, multiplateforme ou web ?

Trois façons de construire une application mobile, trois compromis. Comment choisir selon vos usages, votre budget et la façon de la faire évoluer.

Tous les articles Nous écrire

Application mobile : native, multiplateforme ou web ?

« Il nous faut une application. » La phrase revient souvent, et elle cache plusieurs projets très différents. Une application destinée au grand public, publiée sur les magasins d'Apple et de Google, n'a pas les mêmes contraintes qu'un outil de terrain utilisé par vingt techniciens. Avant de choisir une technologie, il faut savoir ce que l'application doit faire sur le téléphone que le web ne sait pas faire. Trois grandes approches existent : native, multiplateforme et web. Voici comment les distinguer.

Trois approches, trois compromis

Trois maquettes de ponts différents : suspendu, en arc et passerelle légère. — Trois façons de franchir le même fossé, trois compromis.

L'application native

Une application native est écrite spécifiquement pour chaque système : Swift pour iOS, Kotlin pour Android. Elle accède à toutes les fonctions du téléphone dès leur sortie et offre le meilleur niveau d'intégration. En contrepartie, elle demande en principe deux bases de code à maintenir, donc deux fois plus d'efforts pour chaque évolution.

Elle se justifie pour des usages exigeants : traitement vidéo, réalité augmentée, intégration poussée avec le matériel, ou expérience très fine qui fait la différence face à la concurrence.

L'application multiplateforme

Une seule base de code produit les applications iOS et Android. React Native, soutenu par Meta, et Flutter, soutenu par Google, sont les deux familles les plus répandues. L'outillage Expo, construit autour de React Native, simplifie aussi la compilation et la publication.

Pour la grande majorité des applications métier et de nombreuses applications grand public, cette approche offre un bon équilibre : l'accès aux fonctions courantes du téléphone (appareil photo, géolocalisation, notifications, stockage hors ligne), une expérience proche du natif, et un seul code à faire évoluer. Quand une fonction très spécifique manque, il reste possible d'écrire un module natif ciblé.

L'application web progressive

Une application web progressive, ou PWA, est un site web conçu pour se comporter comme une application : installable sur l'écran d'accueil, capable de fonctionner en partie hors ligne, et, depuis iOS 16.4, capable de recevoir des notifications sur iPhone une fois ajoutée à l'écran d'accueil. Elle ne passe pas par les magasins d'applications, ce qui simplifie les mises à jour.

Ses limites sont réelles : accès plus restreint au matériel, comportement qui varie selon les navigateurs, et visibilité moindre pour le grand public, qui cherche d'abord dans les magasins.

Les questions qui décident

Plutôt que de comparer les technologies dans l'absolu, posez ces questions dans l'ordre.

Qui utilise l'application ? Un public large qui la cherchera sur les magasins, ou une équipe identifiée à qui l'on peut envoyer un lien ?

Que doit-elle faire sur le téléphone ? Photo, scan, géolocalisation en arrière-plan, Bluetooth, paiement : listez les fonctions matérielles indispensables.

Doit-elle fonctionner sans réseau ? Sur un chantier, dans un entrepôt ou en zone rurale, le mode hors ligne change toute l'architecture : synchronisation, conflits, stockage local.

Existe-t-il déjà une application web ? Si oui, une PWA ou une application multiplateforme qui partage une partie de la logique peut économiser beaucoup de travail.

Qui la fera évoluer ? Une seule base de code est plus simple à reprendre, à documenter et à confier à une équipe.

Ce qu'on oublie souvent

La publication sur les magasins

Publier sur l'App Store et sur Google Play demande des comptes développeur, des fiches, des captures, une politique de confidentialité, et le respect de règles d'examen qui évoluent. Apple publie ses règles d'examen, qui peuvent conduire au refus d'une version. Il faut l'anticiper dans le calendrier.

Le serveur derrière l'application

Une application mobile n'est presque jamais seule. Elle s'appuie sur un serveur qui gère les comptes, les données et les droits. C'est souvent là que se trouve l'essentiel du travail, et c'est là que se jouent la sécurité et la fiabilité. Le choix de la technologie mobile ne doit pas faire oublier ce socle.

Les versions qui coexistent

Sur le web, tout le monde utilise la dernière version. Sur mobile, certains utilisateurs ne mettent pas à jour. Le serveur doit donc rester compatible avec plusieurs versions de l'application pendant un temps, ou pouvoir demander une mise à jour.

Notre approche

Nous partons de l'usage, pas de la technologie. Pour une application de terrain destinée à une équipe, une PWA ou une application multiplateforme suffit souvent. Pour un produit grand public, la présence sur les magasins compte davantage. Dans tous les cas, nous traitons ensemble l'application et son serveur, pour que l'ensemble reste cohérent. Plus de détails sur la page applications mobiles.

Questions fréquentes

Une application multiplateforme est-elle moins performante ?

Pour la plupart des usages, la différence n'est pas perceptible. Elle peut le devenir pour des traitements très lourds ou des animations complexes, où le natif garde un avantage.

Une PWA peut-elle remplacer une application des magasins ?

Pour un public identifié, souvent oui. Pour un public large qui cherche dans les magasins, ou pour des fonctions matérielles poussées, une application installée reste préférable.

Peut-on commencer en web et passer au mobile ensuite ?

Oui. Une application web bien construite, avec un serveur propre, facilite la création ultérieure d'une application mobile qui réutilise la même logique.

Vous hésitez entre ces approches ? Expliquez-nous l'usage, nous vous aiderons à choisir.