Bon, je vais être direct : depuis 2014, j'ai dû avoir cette conversation 50 fois. Un client arrive, il veut « son appli ». Et la première question qui tombe c'est toujours la même : iOS, Android, ou un truc cross-platform ? Franchement, dans 80% des cas la réponse est évidente en 10 minutes de discussion. Le problème c'est que personne pose les bonnes questions au début.
Du coup je vais te raconter comment je tranche, avec des chiffres réels et des cas vécus. Pas de blabla.
D'abord : t'as vraiment besoin d'une appli ?
En janvier 2024, un gérant d'un magasin de vélo à Wavre me contacte. Il veut une appli pour son catalogue. Budget annoncé : 8000€. J'ai passé 1h avec lui, j'ai compris qu'il voulait juste que ses clients voient les nouveautés et prennent rendez-vous. On a fait un site web responsive avec un module de réservation. 2200€, livré en 3 semaines. Ses clients ouvrent un lien, point.
Une appli native sur les stores, ça veut dire compte développeur Apple à 99€/an, compte Google à 25€ une fois, processus de validation, mises à jour à pousser, support iOS qui change tous les 18 mois. Si t'as 3 utilisateurs internes ou un site informationnel : fait pas de natif. C'est ridicule.
La vraie question c'est : t'as besoin du GPS en arrière-plan ? Du Bluetooth ? Du capteur photo avec traitement local ? Des notifications push fines ? De marcher hors-ligne pendant 2h sur un chantier ? Si oui, ok on parle. Sinon une PWA fait le job pour 4 fois moins cher.
Natif iOS vs natif Android : le vrai match
Quand vraiment faut du natif, voilà ma grille à moi.
iOS (Swift, SwiftUI). Tu codes pour 4-5 modèles d'iPhone récents et 2 iPad. Les tests prennent 2 jours, pas 3 semaines. L'écosystème est propre, les API sont stables, Apple casse moins de trucs entre les versions majeures. Mais : compte Apple Developer obligatoire, validation App Store qui peut prendre 5 jours pour un truc trivial, et si Apple décide que ton appli viole une règle obscure, t'es bon pour réécrire un module. Ca m'est arrivé en mars 2023, j'ai perdu 6 jours sur une histoire de permission caméra mal formulée dans le manifeste.
Android (Kotlin, Jetpack Compose). La fragmentation est réelle mais moins violente qu'avant. Aujourd'hui tu cibles Android 9+, ca couvre 92% du parc. Le Play Store est plus permissif, les délais de publication sont raisonnables. Par contre les tests : entre un Samsung S24, un Xiaomi de gamme moyenne et une tablette Lenovo qu'utilise une infirmière à domicile, tu vas trouver des bugs spécifiques. Faut prévoir 4-5 jours de tests sur appareils réels, pas que sur émulateur.
Mon verdict tranché. Si ton public est belge B2C grand public premium (genre client final qui paye une appli de coaching) : iOS d'abord. Si c'est du B2B avec terrain (logisticien, infirmière, technicien) : Android d'abord, parce que les boites achètent du Samsung à 350€ et pas du iPhone à 1200€.
Budget natif réel pour une appli métier moyenne (10-15 écrans, login, sync, push, photo) : 18000 à 28000€ par plateforme. Délai 3 à 4 mois si je bosse seul. Et tu doubles si tu fais les deux plateformes en même temps. Voilà, c'est ca le vrai chiffre, pas le devis Fiverr à 3000€ qui finit en cauchemar.
Cross-platform : Flutter, React Native, Capacitor
Ici ca devient interessant parce que c'est là que je gagne du temps pour mes clients.
Flutter. Mon préféré pour les TPE/ASBL belges. Une seule base de code Dart, tu sors iOS et Android avec un design quasi identique. Performance bluffante, l'UI est fluide, et le tooling de Google est solide. J'ai livré une appli pour une ASBL bruxelloise en juin 2023, gestion de bénévoles, 22 écrans : 11 semaines pour les 2 plateformes, 19500€ total. Equivalent natif aurait coûté le double. Le seul vrai souci de Flutter c'est quand tu dois plugger une lib hardware exotique (vieux lecteur de code-barres Bluetooth d'un client, par exemple). Là tu repasses en code natif via plugin, et c'est plus chiant.
React Native. Si ton équipe vient du web et connait React, c'est cohérent. La librairie de composants est énorme. Par contre la gestion de l'état natif et les mises à jour (passer de 0.72 à 0.74 par exemple) c'est régulièrement des week-ends perdus. Honnêtement je le propose moins, sauf si le client a déjà des devs React internes.
Capacitor (Ionic). Tu prends ton site web, tu l'enrobes, ca tourne sur le téléphone. Pour des outils internes simples ou un MVP qu'on veut tester en 4 semaines, c'est génial. Pour une appli grand public qui doit être fluide à 60fps, fuis. Coût de dev divisé par 3 mais expérience qui sent le web.
Mon arbre de décision en 4 questions
- L'appli a besoin d'accès matériel poussé (NFC custom, capteurs, calcul image local lourd) ? → natif des deux côtés.
- Budget sous 25k et 2 plateformes voulues ? → Flutter sans hésiter.
- Outil interne pour 5 à 30 employés ? → PWA ou Capacitor, pas plus.
- Tu sais pas si ton produit va marcher ? → MVP en Capacitor ou Flutter, on jette si ca prend pas, on refait propre si ca cartonne.
Le piège que tout le monde oublie : la maintenance
Une appli c'est pas un projet, c'est un engagement. Apple sort iOS 18, Google sort Android 15, et tes API tierces (Stripe, Firebase, login social) bougent en permanence. Compte 15 à 25% du coût initial chaque année juste pour rester compatible et pas casser. Si t'as pas ce budget, refais un site web.
Et s'il te plait, fais pas l'erreur classique : prendre une agence parisienne qui sous-traite à Madagascar pour 12000€ « tout compris ». A 2014 j'ai récupéré 2 projets foirés comme ca. Le code était illisible, la doc inexistante, et les clients ont payé 2 fois.
Bref, si tu hésites entre les options, écris-moi. Je passe une heure gratuite à clarifier le besoin, parfois je dis « fait pas d'appli », et c'est ok aussi.