Natif ou cross-platform : la décision qui engage tout le reste
C'est la première question de tout projet mobile, et celle qui coûte le plus cher à trancher trop vite. Le cross-platform (React Native, Flutter) permet une base de code unique pour iOS et Android : le développement est plus rapide, la maintenance divisée par deux, et le rendu est indiscernable du natif pour la grande majorité des applications. Le natif (Swift pour iOS, Kotlin pour Android) reprend l'avantage dès qu'on touche à du matériel pointu, à du traitement graphique intensif ou à des fonctionnalités système récentes.
Je ne pousse pas une technologie par habitude. Le choix se fait sur votre cas : les fonctionnalités réellement prévues, le budget de maintenance à trois ans, et le profil de l'équipe qui reprendra le code. En pratique, la majorité des applications de PME et de startups sortent mieux en cross-platform — mais pas toutes, et je vous dis lesquelles.
Ce que comprend une application livrée
Une application publiée, ce n'est pas seulement des écrans qui fonctionnent. Le périmètre couvre systématiquement :
- la conception des parcours et de l'interface, avant la première ligne de code ;
- l'authentification et la gestion des comptes utilisateurs ;
- le back-end et l'API, ou l'intégration à votre système existant ;
- les notifications push, avec une logique d'envoi qui ne fait pas désinstaller l'application ;
- le mode hors-ligne quand l'usage le justifie ;
- les tests sur appareils réels, iOS et Android ;
- la publication sur l'App Store et Google Play, y compris le passage en revue Apple ;
- la fiche store optimisée (ASO) : titre, description, captures, mots-clés.
Le déroulé, semaine par semaine
Un projet mobile se déroule en quatre temps. D'abord le cadrage : on liste les fonctionnalités, on tranche ce qui part en version 1 et ce qui attend, et vous recevez un planning ferme. Ensuite la conception : parcours, écrans, cas limites — c'est là qu'on évite les allers-retours coûteux. Puis le développement, livré par incréments : vous testez l'application sur votre téléphone pendant qu'elle se construit, pas à la fin. Enfin la recette et la publication.
Vous avez un point d'avancée chaque semaine et un accès permanent à l'état du projet. Personne n'attend trois semaines pour découvrir que l'application ne fait pas ce qui était prévu.
Budget et délai : les ordres de grandeur
Une application mobile se livre en 6 à 12 semaines selon son périmètre. La fourchette s'explique presque entièrement par trois facteurs : le nombre de parcours utilisateurs distincts, la présence ou non d'un back-office d'administration, et le degré d'intégration à des systèmes existants (paiement, ERP, CRM, outils métier).
Chaque devis est établi après un appel de cadrage gratuit, et le prix est ferme : pas de facturation de dépassement sur un périmètre déjà arbitré. Si le budget disponible ne couvre pas le périmètre souhaité, on réduit le périmètre — jamais l'estimation.
Ce que je ne prends pas
- Les projets sans interlocuteur décisionnaire. Si chaque fonctionnalité demande trois validations, les délais annoncés ne tiennent pas — et je préfère le dire avant de m'engager.
- La reprise d'un code non documenté sans phase d'audit. Sur du legacy, aucun engagement de délai avant un audit préalable.
- Le design seul, sans développement. Je conçois ce que je construis.
- Les délais en dessous du périmètre. Une application ne sort pas en trois semaines. Si c'est la contrainte, on coupe dans le périmètre, pas dans l'estimation.
Questions fréquentes
Combien coûte le développement d'une application mobile ?
Le prix dépend du périmètre : nombre de parcours utilisateurs, présence d'un back-office, intégrations à des systèmes existants. Plutôt qu'une fourchette qui ne veut rien dire, vous recevez un prix ferme après un appel de cadrage gratuit, une fois le périmètre arbitré.
Faut-il développer pour iOS et Android en même temps ?
En cross-platform, oui : une base de code unique produit les deux applications, il n'y a donc pas d'économie à n'en faire qu'une. En natif, chaque plateforme est un développement distinct — là, commencer par celle où sont vos utilisateurs a du sens.
Qui possède le code de l'application ?
Vous. Le code source complet vous est livré et reste transférable à un autre prestataire ou à une équipe interne. Aucune dépendance à une plateforme ou à un outil propriétaire dont vous ne détiendriez pas les clés.
Vous vous occupez de la publication sur les stores ?
Oui, c'est inclus : préparation des comptes développeur, fiches store, captures, passage en revue Apple et Google. La revue Apple peut demander plusieurs allers-retours ; ils sont pris en charge, pas facturés en supplément.
Que se passe-t-il après la mise en ligne ?
La publication n'est pas la fin du projet. Je propose du suivi, la correction des anomalies remontées par les premiers utilisateurs, et les évolutions suivantes. Les systèmes iOS et Android évoluant chaque année, une application vivante demande de la maintenance.