React Native, Flutter ou PWA : quelle différence pour mon projet ?
+
Trois technos pour trois usages différents.
**React Native** (ce que j'utilise par défaut) : une seule base de code JavaScript/TypeScript pour iOS + Android, accès complet aux fonctions natives du téléphone (caméra, GPS, notifications push, biométrie). Idéal pour 80 % des projets TPE/PME. Économie de 40-60 % vs développement natif pur.
**Flutter** (Google, langage Dart) : meilleures performances pour UI sur-mesure avec beaucoup d'animations, mais plus loin de l'écosystème web. Je vous oriente vers un spécialiste Flutter si votre besoin justifie cette stack.
**PWA** (Progressive Web App) : votre site web installable sur le home screen du téléphone. Pas d'app store, pas de notifications iOS (Apple bloque encore en grande partie). Bon pour un MVP ultra-rapide ou pour une app qui ne sert qu'occasionnellement.
Ma règle : on choisit la techno après le diagnostic du besoin, pas avant.
Combien de temps pour livrer une application mobile ?
+
Entre 4 semaines (MVP simple) et 16 semaines (app complexe avec backend custom).
**MVP 3-5 écrans, 1 fonction métier, sans backend custom** : 4-6 semaines.
**App fonctionnelle 8-12 écrans, auth + backend Firebase + notifications push** : 8-12 semaines.
**App complexe multi-rôles, intégrations tierces, soumission stores** : 12-20 semaines.
À chaque sprint de 2 semaines, vous avez une version testable sur votre téléphone via TestFlight (iOS) ou Play Console interne (Android). Pas d'attente jusqu'à la fin pour voir ce qui se construit.
Faut-il publier sur l'App Store, le Play Store, ou les deux ?
+
Les deux dans la majorité des cas, sauf besoin spécifique.
App Store (iOS) : audience plus restreinte (28 % du marché smartphone en France), mais utilisateurs avec un panier moyen plus élevé. Soumission Apple = 3-7 jours de revue avec règles strictes.
Play Store (Android) : 71 % du marché en France, soumission Google plus rapide (souvent 24-48 h). Moins de friction sur les règles éditoriales.
Exception : app métier interne déployée uniquement chez Apple ou uniquement chez Google, sans passage par les stores publics (distribution via MDM ou TestFlight / Play Console interne). Possible et parfois plus rapide.
Comment je garde le contrôle après la livraison ?
+
Le code source est à vous, sur votre GitHub, avec documentation complète.
Ce que vous récupérez à la passation :
- Repo GitHub avec accès admin
- Documentation technique (architecture, stack, dépendances, commandes de build)
- Accès aux comptes développeurs Apple + Google (à votre nom, pas au mien)
- Manuel de mise à jour basique (changer un texte, une couleur, ajouter un écran simple)
- Suivi 3 mois inclus pour les bugs critiques et premiers ajustements
Si vous voulez gérer la maintenance en interne après les 3 mois : votre dev peut reprendre. Si vous voulez que je continue : forfait maintenance mensuel sur devis (mises à jour stores, corrections, petites évolutions).
Faut-il un backend dédié pour une app mobile ?
+
Ça dépend de ce que l'app fait. Trois cas typiques.
**Pas besoin de backend** : app qui consomme uniquement des données publiques (API tierces, contenu statique). Rare en pratique.
**Firebase (Google) suffit** : besoin d'authentification, base de données temps réel, notifications push, storage de fichiers. Couvre 70 % des projets TPE/PME. Économie de 4-8 semaines de dev backend.
**Backend custom nécessaire** : logique métier complexe, intégrations multiples, contrôle total sur les données (RGPD strict, secteurs régulés). On part sur Next.js API routes ou un serveur Node dédié, hébergé sur Vercel ou un VPS européen.
Le choix se fait après le diagnostic, pas avant.
Vous travaillez à distance ou en présentiel ?
+
Les deux selon le projet, avec une préférence remote pour la phase build.
**Diagnostic et observation terrain** : présentiel idéal pour les apps métier internes (chauffeurs, techniciens). Je passe 1-2 jours sur place pour voir le flux réel, parler aux utilisateurs, comprendre les contraintes physiques (gants, soleil, écran cassé, batterie morte). Cette étape ne se fait pas en visio.
**Phase design + build** : 100 % remote. Sprints de 2 semaines avec démo en visio à chaque fin de sprint. Vous testez l'app entre les sprints sur votre téléphone.
**Lancement + formation** : présentiel selon le besoin (formation utilisateurs en groupe). Sinon, formation en visio + manuel PDF.
Déplacements possibles : Paris, Île-de-France, Lyon, Bordeaux pour la France · Kinshasa et Afrique francophone selon la mission.