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, une base de code commune réduit la duplication de maintenance entre iOS et Android, et l'expérience peut être très proche du natif pour la majorité des usages standards. 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 stratégie d'envoi pensée pour rester utile et non intrusive ;
- 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 : vous testez les incréments au fil du développement, pas seulement à la recette finale.
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, sur un périmètre écrit, et le budget est fixé dessus : tout changement de périmètre est chiffré et validé avant d'être lancé. Si le budget disponible ne couvre pas le périmètre souhaité, on ajuste la V1 avant de démarrer.
Quand une autre solution sera plus adaptée
- 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.
- Un délai compatible avec le périmètre. Sur le périmètre décrit plus haut, comptez 6 à 12 semaines. Si le budget ou la date sont contraints, on ajuste la V1 avant de démarrer plutôt que l'estimation.
