Quelle technologie pour votre application mobile ?
Swift, Kotlin, Flutter, React Native : le choix a un impact direct sur votre budget, vos délais et votre capacité à faire évoluer l'application. Voici comment il se décide, sans jargon.
La question à poser n'est pas « quelle est la meilleure ? »
Il n'y a pas de meilleure technologie mobile. Il y a celle qui convient à votre application, à votre budget et à ce que vous pourrez maintenir dans trois ans.
Méfiez-vous d'un prestataire qui propose une technologie avant d'avoir compris ce que fait votre application : il propose ce qu'il maîtrise, ce qui est humain mais ne devrait pas décider de votre projet. Le raisonnement va dans l'autre sens — le produit d'abord, la technologie ensuite.
Natif ou cross-platform : le seul arbitrage qui compte vraiment
Tout le reste découle de cette décision.
| Natif (Swift, Kotlin) | Cross-platform (Flutter, React Native) | |
|---|---|---|
| Coût sur iOS + Android | Deux développements | Une base de code commune |
| Performance | Maximale | Suffisante pour la majorité des apps |
| Accès au matériel du téléphone | Immédiat | Via des plugins, parfois en retard |
| Maintenance | Deux fois | Une fois |
| Recrutement futur | Deux profils différents | Un seul profil |
| À choisir pour | Jeux, réalité augmentée, vidéo, capteurs | Apps métier, marketplaces, e-commerce, MVP |
La règle simple : si votre application passe son temps à afficher, saisir et envoyer des données, le cross-platform fait le travail et vous économise une plateforme entière. Si elle exploite intensivement le matériel du téléphone, le natif s'impose.
Les technologies que nous faisons utiliser
Swift — iOS natif
Le langage d'Apple. Accès immédiat à toutes les nouveautés d'iOS, performances maximales. À privilégier pour les jeux, la réalité augmentée et tout ce qui sollicite fortement l'appareil.
Kotlin — Android natif
L'équivalent côté Android. Même logique : indispensable dès que l'application exploite finement le matériel ou doit fonctionner sur un parc d'appareils très hétérogène.
Flutter
Développé par Google. Une seule base de code pour iOS et Android, avec un rendu très fluide et une bonne maîtrise du visuel. Le choix par défaut de beaucoup de projets métier aujourd'hui.
React Native
Une seule base de code également. Intéressant si vos équipes connaissent déjà React côté web : les compétences se recyclent en partie, ce qui compte pour la maintenance.
Application web progressive
Utilisable depuis le navigateur mobile et installable sur l'écran d'accueil, sans passer par les stores ni leurs commissions. Une bonne option quand le budget est serré et que l'app n'a pas besoin du hors ligne.
Unity
Pour les jeux mobiles, et pour la 3D en général. Un monde à part, avec ses propres profils et ses propres contraintes de monétisation.
Ce qui compte plus que le choix du langage
Trois décisions ont plus d'impact sur la durée de vie de votre application que le langage retenu, et on en parle beaucoup moins.
- L'API et le serveur. Une application mobile n'est que la partie visible. Si l'API derrière est mal conçue, changer de technologie mobile n'y changera rien.
- Le mode hors ligne. Décidé au début ou ajouté après, ce n'est pas le même projet. Sur une application terrain, c'est la question centrale.
- Qui maintiendra. Une technologie excellente pour laquelle vous ne trouverez personne à recruter dans votre région est un mauvais choix, même si elle est techniquement supérieure.
Questions fréquentes
Le cross-platform est-il moins bon que le natif ?
Pour la grande majorité des applications professionnelles, la différence n'est pas perceptible par l'utilisateur. Elle le devient sur les usages intensifs : jeux, traitement vidéo, réalité augmentée, capteurs en continu. Si votre application affiche et saisit des données, le débat est théorique.
Combien économise-t-on avec le cross-platform ?
L'économie est réelle mais pas de moitié : la partie visible se mutualise, alors que le serveur, l'API, le design et les tests restent à faire une fois de toute façon. Comptez plutôt 25 à 35 % sur un projet couvrant les deux plateformes.
Peut-on changer de technologie plus tard ?
Cela revient à redévelopper la partie mobile. L'API et les données, elles, se conservent — raison de plus pour les concevoir proprement au départ, indépendamment du choix mobile.
Faut-il sortir sur iOS ou sur Android d'abord ?
Regardez où sont vos utilisateurs. Pour une application interne, la réponse est dans le parc de téléphones de vos équipes. En France, sur du grand public, les deux plateformes comptent, ce qui plaide pour le cross-platform si le budget est contraint.
Qui décide au final ?
Vous, avec notre recommandation écrite et argumentée. Nous vous disons ce que nous ferions et pourquoi, avec les conséquences sur le budget et la maintenance. Le choix reste le vôtre.
Un doute sur la technologie à retenir ?
Décrivez ce que doit faire votre application. Nous vous dirons ce que nous recommanderions, et pourquoi.