Application mobile : natif, multiplateforme ou web ?

C’est la première question de tout projet mobile, et elle est souvent tranchée avant d’être posée — par habitude ou par préférence de l’équipe en place.

Voici comment je la pose, avec les critères qui décident réellement.

Commencer par une question plus simple

Avant de choisir une technologie : avez-vous besoin d’une application ?

Beaucoup de projets mobiles n’en ont pas besoin. Si l’usage est occasionnel, sans fonctionnement hors ligne, sans notification, sans accès à l’appareil photo ou à la position, alors un site web bien conçu fait le travail — et il évite les magasins d’applications, les validations, les mises à jour et deux plateformes à maintenir.

La question à poser : combien de fois par semaine un utilisateur ouvrira-t-il ça ? En dessous d’une ou deux fois, il ne l’installera pas, ou il l’installera puis l’oubliera. Un lien fonctionne mieux.

Quatre besoins justifient réellement une application : le fonctionnement hors ligne, les notifications, l’accès au matériel — photo, position, capteurs, lecture de codes —, et un usage quotidien où le temps de démarrage compte.

Le multiplateforme

C’est ce que nous recommandons dans la majorité des cas d’application métier.

Une seule base de code produit les deux applications. En pratique, 80 à 90 % du code est partagé ; le reste correspond aux différences d’interface et aux intégrations système propres à chaque plateforme.

Ce qu’on gagne : un développement et une maintenance uniques, des corrections livrées simultanément sur les deux plateformes, et une équipe qui n’a pas besoin d’être doublée.

Ce qu’on perd : l’accès immédiat aux nouveautés du système — il faut attendre que le cadre les prenne en charge, ce qui prend quelques mois. Et l’application est un peu plus lourde.

Ce qu’on ne perd pas, contrairement à une idée répandue : la qualité perçue. Sur une application métier, un utilisateur ne fait pas la différence. Les cas où elle se voit sont les animations complexes et le graphisme intensif.

Le natif

Deux applications, deux langages, deux équipes ou une équipe qui maîtrise les deux.

Ce que ça apporte : l’accès immédiat à tout ce que le système propose, les meilleures performances possibles, et l’intégration la plus fine — extensions, widgets, montres connectées.

Ce que ça coûte : à peu près le double, en développement comme en maintenance. Chaque fonctionnalité s’écrit deux fois, chaque bug se corrige deux fois, chaque montée de version se teste deux fois.

Ce coût se justifie quand la performance ou l’intégration système sont le produit : une application de traitement d’image, un jeu, un outil de navigation. Sur une application métier de saisie et de consultation, il se justifie rarement.

Ma grille

Besoin	Web	Multiplateforme	Natif
Usage occasionnel	Oui	Surdimensionné	Surdimensionné
Fonctionnement hors ligne	Limité	Oui	Oui
Notifications	Partiel	Oui	Oui
Photo, position, capteurs	Limité	Oui	Oui
Graphismes intensifs	Non	Limité	Oui
Budget contraint	Oui	Oui	Non
Deux plateformes à maintenir	Non	Une seule base	Deux

Photo : Toni Hukkanen — licence CC0.

Le coût qu’on oublie systématiquement

Ce n’est pas le développement initial. C’est l’entretien permanent.

iOS et Android publient chacun une version majeure par an. À chaque fois : tester, corriger ce qui a changé, parfois adapter une autorisation ou un comportement. Les magasins font par ailleurs évoluer leurs exigences, et une application qui ne suit pas finit par être retirée.

Comptez quelques jours par an et par plateforme, même sans aucune évolution fonctionnelle. C’est un budget de fonctionnement, pas un imprévu — et c’est ce que le multiplateforme divise par deux.

Photo : domaine public (CC0).

Ce que le multiplateforme ne dispense pas de connaître

Une idée fausse circule : le multiplateforme permettrait de se passer de compétences iOS et Android. C’est faux, et c’est la principale cause de déception sur ces projets.

Une base de code unique ne supprime pas les différences entre les deux systèmes. Elle les regroupe à un seul endroit. Il faut toujours savoir comment iOS gère le retour arrière, comment Android gère le bouton système, ce que chaque plateforme fait des autorisations, et ce qui se passe quand le système décide de fermer l’application restée en arrière-plan.

Un développeur multiplateforme qui n’a jamais publié une application native se heurte à ces sujets au pire moment : en fin de projet, quand tout semblait fonctionner. Les 10 à 20 % de code spécifique à chaque plateforme sont précisément la partie qui demande le plus d’expérience.

Les conventions d’interface, qu’on ne peut pas ignorer

Les deux systèmes ont des habitudes différentes, et les utilisateurs y sont sensibles sans savoir les nommer.

La navigation ne se fait pas de la même manière : Android dispose d’un geste et d’un bouton de retour système qu’une application doit gérer correctement, iOS s’appuie sur un geste depuis le bord de l’écran. Les fenêtres de choix, les listes, la position des actions principales, la typographie système : tout diffère.

Une application qui applique les conventions d’une plateforme sur l’autre paraît étrangère. Ce n’est pas un défaut esthétique — c’est un défaut d’usage : les gestes qui marchent partout ailleurs ne marchent pas ici.

Les cadres multiplateformes sérieux proposent deux jeux de composants, un par plateforme. Les utiliser demande un peu plus de travail de conception, et cela se voit immédiatement à l’usage.

Les trois questions que je pose avant de trancher

Avant tout choix technique, je pose trois questions au métier — et les réponses décident presque toujours à elles seules.

Où sont les utilisateurs quand ils s’en servent ? Au bureau devant un ordinateur, ou en mobilité avec du réseau incertain ? La deuxième réponse écarte le web et impose de traiter le fonctionnement hors ligne.

Quelle est la répartition entre iOS et Android ? Sur une application interne à parc maîtrisé, une seule plateforme suffit parfois — et cela change tout le calcul. Sur une application grand public en France, il faut les deux, dans des proportions qui varient beaucoup selon la cible.

Combien de temps cette application doit-elle vivre ? Un outil pour une campagne de six mois et un outil métier prévu pour huit ans ne justifient pas le même investissement. Le second doit privilégier ce qui se maintient facilement ; le premier, ce qui se construit vite.

Ce que je conseille de faire d’abord

Si le besoin n’est pas certain : commencer par un site web responsive, mesurer l’usage réel pendant quelques mois, et construire l’application quand on sait qui l’utilisera et pour quoi.

Le développement mobile est l’un des endroits où l’on construit le plus souvent avant de savoir. Et une application publiée que personne n’installe coûte autant qu’une application utilisée.