App Store et Google Play : les 9 motifs de refus qu’on voit le plus
5 min de lecture
À retenir
- Le cross-platform est le choix par défaut raisonnable : il couvre bien 80 % des projets mobiles.
- Le natif redevient pertinent dès que le matériel, la latence ou l’intégration système sont au cœur du produit.
- React Native est le meilleur choix si votre équipe web existe déjà ; Flutter si l’interface doit être très travaillée et identique partout.
- Le vrai coût du choix technique n’est pas le développement initial mais le recrutement et la maintenance sur trois ans.
- Aucune de ces technologies ne rattrapera un produit mal cadré.
C’est la question qui déclenche le plus de débats en atelier de cadrage, et presque toujours pour de mauvaises raisons. On y répond par conviction technique alors que c’est une décision économique et organisationnelle.
Voici comment nous tranchons réellement, avec les critères que nous utilisons et les cas où nous recommandons chaque approche.
Ce que chaque approche coûte vraiment
| Critère | Natif (Swift + Kotlin) | React Native | Flutter |
|---|---|---|---|
| Coût initial iOS + Android | 1,6 – 1,8 × | 1 × | 1 – 1,1 × |
| Bases de code à maintenir | 2 | 1 | 1 |
| Accès immédiat aux nouveautés OS | Immédiat | Quelques semaines à quelques mois | Quelques semaines à quelques mois |
| Réutilisation avec une équipe web | Nulle | Forte (TypeScript, React) | Faible (Dart) |
| Vivier de recrutement en France | Moyen, cher | Large | Moyen, en croissance |
| Rendu identique sur les deux plateformes | Non par nature | Proche | Oui par construction |
La ligne la plus importante n’est pas le coût initial : c’est le nombre de bases de code à maintenir. Sur trois ans, maintenir deux applications natives coûte structurellement plus cher que d’en maintenir une, à périmètre égal.
Notre arbre de décision
Nous posons quatre questions, dans cet ordre.
1. Le produit dépend-il fortement du matériel ?
Bluetooth Low Energy, traitement d’image ou de vidéo en temps réel, réalité augmentée, capteurs à haute fréquence, watchOS, CarPlay, widgets système avancés. Si oui, le natif reprend l’avantage : vous passerez sinon votre temps à écrire des ponts natifs, ce qui revient à faire du natif tout en payant l’abstraction.
2. Avez-vous déjà une équipe web React ?
Si vous avez des développeurs TypeScript/React en interne, React Native leur ouvre le mobile en quelques semaines, et vous partagez la logique métier, les types et une partie des tests. C’est souvent l’argument décisif pour les PME et les scale-ups : le sujet n’est pas la technologie, c’est le fait de ne pas créer une seconde équipe.
3. L’interface doit-elle être très travaillée et rigoureusement identique partout ?
Une application de marque, très animée, où le pixel compte et où l’écart entre iOS et Android est inacceptable : Flutter est fait pour ça. Il dessine tout lui-même, donc le rendu est le même partout, et son moteur d’animation est excellent.
4. Y a-t-il une contrainte de conformité ou de sécurité forte ?
Santé, paiement réglementé, défense : le natif simplifie les audits, réduit la surface de dépendances tierces et accélère l’adoption des nouvelles API de sécurité. Ce n’est pas obligatoire, mais c’est un argument réel face à un auditeur.
En pratique, sur nos projets 2025-2026 : environ 65 % en cross-platform (dont deux tiers React Native), 25 % en natif, 10 % en hybride assumé — une base cross-platform avec un ou deux modules natifs. Le natif « pur » reste minoritaire, mais il n’a jamais disparu.
Les fausses bonnes raisons
« Le natif est plus rapide. » Vrai sur un banc de test, invisible dans une application métier. La lenteur perçue vient presque toujours d’appels réseau mal gérés, d’images non optimisées et de listes mal virtualisées — trois problèmes que le natif ne résout pas tout seul.
« Le cross-platform, c’est du bricolage. » Ce n’était pas faux en 2016. En 2026, l’architecture moderne de React Native et le moteur de rendu de Flutter ont réglé l’essentiel des griefs historiques.
« On prendra Flutter, c’est Google. » Le sponsor n’est pas une garantie. Le vrai critère est : trouverez-vous quelqu’un pour reprendre ce code dans trois ans, à un tarif que vous acceptez de payer ?
Le meilleur choix technique est celui que votre équipe — actuelle et future — saura faire vivre. Tout le reste est de la préférence personnelle déguisée en argument d’ingénierie.
Une stratégie qui marche presque toujours
Pour un produit nouveau dont le marché n’est pas encore validé :
- Démarrez en cross-platform. Vous allez de toute façon jeter la moitié de ce que vous écrivez : autant le jeter une seule fois.
- Isolez la logique métier dans une couche indépendante de l’interface. C’est ce qui vous permettra de changer d’avis sans tout réécrire.
- Réécrivez en natif seulement ce qui le mérite, quand un besoin précis apparaît — et pas avant.
Cette approche est celle qui minimise le coût total sur trois ans dans la grande majorité des cas que nous voyons. Elle a aussi l’avantage d’être réversible, ce qui est rare en informatique.
Et le budget dans tout ça ?
Le choix technique déplace le budget de 20 à 40 %, ce qui est significatif mais moins déterminant que le périmètre fonctionnel. Nous détaillons la décomposition complète dans notre article sur le coût d’une application mobile en 2026.
Si vous hésitez sur votre cas précis, décrivez-nous le produit : nous vous répondons avec une recommandation argumentée, y compris quand elle consiste à vous dire que la question ne se pose pas.
