Choisir un framework de développement d'application mobile : le guide

On m'a posé la question trois fois la même semaine. Un fondateur de startup, une responsable produit dans une boîte de logistique, et un ami qui voulait lancer son app de suivi d'entraînement. Tous les trois : « Bon, je choisis quoi pour développer mon application mobile ? » Et à chaque fois, ma première réponse les a un peu déçus. Parce que la vraie réponse, c'est : ça dépend de ce que vous avez déjà.

Pas de votre budget. Pas de la mode. De ce que vous savez déjà faire et de ce que vous serez encore capables de maintenir dans dix-huit mois. Le choix d'un framework de développement mobile, c'est moins un concours de popularité qu'un pari sur votre propre capacité à tenir dans la durée.

Choisir un framework de développement mobile : le cadre avant le catalogue

Un framework, c'est un socle qui vous évite de réécrire le même caca à chaque écran. Une bibliothèque de composants, un moteur de rendu, une façon de structurer vos écrans et votre navigation. Vous en choisissez un, et vous héritez de ses forces comme de ses limites.

Le piège classique, c'est de comparer les frameworks comme on compare des voitures sur une fiche technique. Nombre de plugins, nombre d'étoiles sur un dépôt public, courbe de popularité. Ça raconte quelque chose, mais ça ne dit rien de votre situation réelle.

Trois questions à se poser avant de regarder le premier tutoriel

1. Qui va maintenir ce code dans deux ans ? Si la réponse est « moi tout seul, et j'ai déjà un job », vous n'avez pas le même problème qu'une équipe de dix.
2. Votre app a-t-elle réellement besoin d'accéder à des capteurs, du Bluetooth, du stockage local lourd, ou du traitement d'image temps réel ?
3. Quel est votre horizon ? Une app jetable pour tester un marché, ou un produit que vous allez faire vivre une décennie ?

Dans mon expérience, les projets qui se plantent ne se plantent presque jamais sur le framework. Ils se plantent sur la question 1. J'ai vu un projet React Native abandonné six mois après lancement, non pas parce que React Native était mauvais, mais parce que le seul développeur qui le maîtrisait est parti et que personne d'autre dans la structure ne pouvait reprendre le code.

Comment développer une application mobile, concrètement ?

Avant de parler de frameworks, il faut comprendre les trois grandes voies qui s'offrent à vous. Elles ne s'excluent pas, mais elles ne mènent pas au même endroit.

La voie native

Vous écrivez un code séparé pour iOS (Swift ou Objective-C) et pour Android (Kotlin ou Java). C'est la voie historique, celle des apps qui dépendent lourdement du matériel ou qui exigent une fluidité maximale. Le revers : deux bases de code, deux équipes ou deux compétences, et un coût de développement qui grimpe mécaniquement.

La voie multiplateforme

Un seul code source, compilé ou interprété pour les deux plateformes. C'est là que Flutter et React Native règnent. Vous écrivez une fois, vous déployez sur iOS et Android, avec en général 70 à 90 % de code partagé selon la complexité de l'app. C'est ce qui explique leur succès : pas la performance, le coût.

La voie hybride web

Vous packagingez une app web dans une coquille native. C'est la famille d'Ionic, de Capacitor. Vous écrivez du HTML, du CSS, du JavaScript, et vous obtenez une app installable. Le rendu et la fluidité restent en deçà des deux autres voies, mais si votre équipe est déjà web, la marche est très courte.

Quel est le meilleur outil pour développer une application mobile ?

Il n'y en a pas un. Il y a celui qui correspond à votre situation, et c'est une réponse qui n'amuse personne mais qui est vraie. Ceci dit, si vous me poussez à choisir pour un projet neuf, sans contrainte particulière, je pars sur Flutter. Et je vais expliquer pourquoi, sans cacher les inconvénients.

Flutter

Développé par Google, écrit en Dart. La grande force, c'est le rendu : Flutter ne délègue pas le dessin des composants à la plateforme, il les dessine lui-même. Résultat, votre interface est identique sur les deux systèmes, et vous contrôlez visuellement chaque détail. La documentation est solide, les outils de test intégrés sont sérieux, et l'écosystème de packages est mature.

Les points de friction ? Dart, précisément. C'est un langage agréable, mais ce n'est pas JavaScript, et si vous recrutez, vous allez devoir chercher spécifiquement des profils Dart. Sur un marché où React domine largement côté web, la pool de candidats est plus étroite. Sur un projet personnel, je m'en fiche ; sur une équipe qui grandit, c'est un vrai sujet.

React Native

Écrit en JavaScript, propulsé par Meta. Si vous venez du web, la transition est presque indolore. Vous réutilisez vos réflexes, vos bibliothèques, votre outillage. L'écosystème JavaScript est gigantesque, et c'est l'argument décisif pour beaucoup d'équipes.

Le hic : la performance dépend davantage de la qualité de votre code et des bibliothèques que vous empilez. Une app React Native mal écrite rame visiblement. Une app React Native bien écrite est indiscernable d'une app native sur 90 % des cas d'usage, mais sur des interactions très animées ou du traitement temps réel, vous sentez la différence.

Quel est le meilleur logiciel pour développer une application Android ?

Petite clarification utile : « logiciel » ici, c'est souvent confondu avec l'environnement de développement. Les deux se recoupent mais ne sont pas identiques, et ça vaut la peine de distinguer.

Android Studio reste le passage obligé

Quel que soit le framework que vous choisissez, pour produire un APK ou un bundle Android, vous passez par Android Studio. C'est l'environnement officiel de Google, il embarque le SDK, l'émulateur, le débogueur, les outils de profilage. Même si vous développez en Flutter ou React Native, vous l'installez.

Si l'app est strictement Android native, vous codez en Kotlin dans Android Studio, point. C'est l'option la plus performante sur Android, mais elle n'a de sens que si vous n'avez pas de besoin iOS.

Et pour iOS ?

Xcode, obligatoirement, sur macOS. Il n'existe pas d'alternative pour compiler une app iOS. C'est une contrainte matérielle à intégrer dès le début : si votre équipe est à 100 % sous Windows ou Linux, vous devrez prévoir une machine ou un service d'intégration continue avec des runners macOS.

Quel est le framework le plus utilisé ?

Sur le terrain que je côtoie, chez les équipes qui font du multiplateforme et qui ne sont pas de grosses structures, Flutter et React Native se partagent la quasi-totalité des projets. Sur les nouvelles apps multiplateforme lancées par des indépendants ou des petites équipes, Flutter a pris un net avantage ces dernières années, notamment parce que son outillage est plus simple à prendre en main pour quelqu'un qui démarre.

React Native reste massivement présent dans les entreprises qui ont déjà des équipes web et qui mutualisent leurs compétences. Ionic, lui, est très présent dans les projets internes, les apps métier, les outils qu'on ne vend pas au grand public.

Si je devais résumer par une intuition, sans prétendre à une statistique : Flutter pour un projet neuf de zéro, React Native si vous avez déjà des développeurs JavaScript, Ionic pour de l'app métier rapide à livrer. C'est ce que je vois, et c'est ce que je conseille.

La grille de décision que j'utilise vraiment

Quand on me demande conseil, je pose un tableau à quatre critères et je fais cocher.

Critère	Flutter	React Native	Ionic	Natif pur
Compétence déjà présente en web	Faible	Forte	Très forte	Aucune
Fluidité des animations complexes	Excellent	Bon	Moyen	Excellent
Accès au matériel natif	Bon	Bon	Dépend des plugins	Maximal
Coût de développement initial	Moyen	Moyen	Faible	Élevé
Facilité de recrutement	Moyenne	Forte	Forte	Spécialisée

Vous cochez la ligne qui vous concerne le plus, et la réponse sort presque d'elle-même. Ce tableau n'est pas une science exacte, mais il m'a évité plusieurs mauvais départs.

L'erreur que j'ai faite, et que vous pouvez éviter

Sur mon premier vrai projet multiplateforme, j'ai choisi le framework en fonction d'un benchmark de performance que j'avais lu. L'app était un peu plus rapide. Six mois plus tard, le développeur qui maîtrisait ce framework est parti, et j'ai dû passer trois semaines à former quelqu'un d'autre. Trois semaines perdues, pour un gain de performance que personne n'a jamais remarqué sur l'app final.

Le vrai coût, ce n'est pas le temps de développement initial. C'est le temps de maintenance, de montée de version, de remplacement de développeur, de migration de bibliothèques. Un framework auquel vous ne trouvez pas de compétence, c'est une dette technique qui dort.

Mon conseil, après cette leçon : choisissez le framework sur lequel vous pouvez recruter, pas celui qui a la meilleure fiche technique. La performance brute est rarement votre problème. La compétence disponible, presque toujours.

Et si vous êtes seul, la question change encore : prenez celui que vous comprenez le plus vite. Un peu moins bon mais que vous maîtrisez battra toujours un excellent framework que vous découvrez en même temps que le projet.

Le bon choix, au fond, c'est celui que vous serez encore capable de défendre dans dix-huit mois, devant un successeur ou un client, sans avoir à vous justifier.