C'est la première question que se pose presque tout porteur de projet mobile en Tunisie : faut-il partir sur React Native avec Expo, ou investir directement dans du développement natif ?
Nous avons dû trancher en construisant Dokkan, une marketplace multi-vendeurs tunisienne avec deux expériences distinctes, celle de l'acheteur et celle du vendeur. Voici ce que nous avons choisi, pourquoi, ce qui nous a surpris, et dans quels cas nous ferions un autre choix. Cet article s'adresse aux fondateurs, chefs de produit et responsables techniques qui doivent décider d'une stack mobile, pas aux amateurs de guerres de frameworks.
La réponse courte : pour la plupart des startups et des PME qui lancent une marketplace, une app e-commerce ou une app de services, React Native avec Expo est le point de départ le plus rapide, le plus économique et le plus sûr. Le natif ne se justifie que face à un besoin précis et démontré.
Pourquoi ce choix pèse plus lourd qu'il n'en a l'air
Votre stack mobile ne détermine pas seulement le code que vous écrivez. Elle influence directement :
Le délai de mise sur le marché : à quelle vitesse une première version arrive entre les mains de vrais utilisateurs.
La taille et le coût de l'équipe : une base de code ou deux, et la facilité de recrutement.
La vitesse de correction : le temps qu'il faut pour réparer un bug une fois l'app publiée.
La maintenance : ce que coûtera l'app dans trois ans.
Quand chaque dinar de trésorerie compte, une stack qui vous ralentit n'est pas seulement un mauvais choix technique, c'est une erreur stratégique.
Les options, sans jargon
Le natif consiste à développer deux applications séparées : Kotlin (ou Java) pour Android, Swift pour iOS. Vous obtenez un contrôle maximal et un accès complet aux fonctions du téléphone, mais tout est à construire et à maintenir en double.
React Native permet d'écrire l'application une seule fois en JavaScript ou TypeScript, puis de la faire tourner sur Android et iOS avec de véritables composants d'interface natifs.
Expo est une boîte à outils construite autour de React Native. Elle prend en charge la configuration, les builds dans le cloud, de nombreuses fonctions du téléphone et les mises à jour à distance, pour que l'équipe se concentre sur le produit plutôt que sur l'outillage.
Pourquoi nous avons choisi React Native et Expo pour Dokkan
Une marketplace n'est pas une seule application. C'est une expérience acheteur (parcourir, rechercher, panier, paiement, suivi des commandes) et une expérience vendeur (catalogue, commandes, expédition, versements), le tout reposant sur un backend qui doit rester cohérent. Quatre raisons ont motivé notre choix.
1. Une équipe, une base de code
Notre stack est en TypeScript de bout en bout : React Native et Expo côté mobile, NestJS et MongoDB côté serveur. Partager le même langage, les mêmes types et les mêmes conventions permet aux développeurs de passer du mobile au backend sans friction, et à une petite équipe de maîtriser tout le produit. Pour le volet serveur, voyez notre présentation du développement backend avec NestJS.
2. La vitesse de mise en marché
Pour une marketplace qui démarre, apprendre auprès de vrais utilisateurs vaut mieux que peaufiner dans le vide. Avec Expo, nous pouvons construire, tester sur de vrais appareils et publier rapidement, ce qui est décisif quand il faut vérifier que acheteurs et vendeurs adoptent réellement le produit.
3. Les mises à jour à distance (OTA)
C'est l'avantage le plus sous-estimé. Grâce au système de mise à jour d'Expo, beaucoup de corrections et de changements d'interface (tout ce qui relève de la couche JavaScript) peuvent atteindre les utilisateurs sans attendre une validation complète des stores. Quand un bug de paiement apparaît un vendredi soir, la différence est énorme. Les changements qui touchent au code natif exigent toujours une publication sur les stores : il faut prévoir les deux voies, mais pouvoir corriger vite change la façon dont on exploite un produit.
4. Un profil de coûts réaliste
Deux applications natives, c'est deux bases de code, deux séries de bugs et souvent deux profils de spécialistes à recruter. Pour la plupart des startups et PME tunisiennes, ce budget sera mieux employé sur le produit, le backend et l'exploitation au quotidien.
Ce que change le fait de construire en Tunisie
Une application se juge sur les téléphones et les réseaux que vos utilisateurs ont réellement, pas sur un smartphone haut de gamme connecté au Wi-Fi du bureau.
Android d'abord. Android domine le marché local et beaucoup d'utilisateurs ont des appareils d'entrée ou de milieu de gamme. Testez sur ces téléphones, pas seulement sur le vôtre.
Des connexions inégales. La data mobile peut être lente ou instable. Concevez pour cela : images compressées, cache généreux, écrans utilisables pendant le chargement, et échec propre quand le réseau coupe.
Plusieurs langues, deux sens de lecture. L'arabe, le français et l'anglais sont tous des usages réels, et l'arabe impose des interfaces de droite à gauche. Intégrez l'internationalisation et le RTL dès le premier sprint, pas en rustine de dernière minute.
Paiement à la livraison et logistique locale. Le tunnel de commande, le suivi et les écrans d'expédition vendeur doivent refléter la façon dont les Tunisiens achètent et reçoivent leurs colis. Nous l'expliquons dans pourquoi le paiement à la livraison reste roi en Tunisie.
Le numéro de téléphone fait office d'identité. La connexion par téléphone correspond aux habitudes des utilisateurs, comme nous le détaillons dans pourquoi l'authentification par numéro de téléphone fonctionne en Tunisie.
Ce qui nous a surpris (et ce que nous dirions à notre moi d'il y a un an)
La performance est d'abord un problème de conception, ensuite un problème de framework. Les listes lentes, les images trop lourdes et les appels API bavards pèsent bien plus que le choix entre React Native et natif. Listes virtualisées, optimisation des images, mémoïsation et réduction des rendus inutiles ont réglé l'essentiel de nos soucis. Un backend rapide compte tout autant, d'où notre article sur comment trouver le vrai goulot d'étranglement d'une application lente.
Testez tôt sur de vrais appareils d'entrée de gamme. Les émulateurs mentent. Un écran fluide sur un téléphone récent peut saccader sur un ancien modèle Android.
Gardez l'app légère et le backend intelligent. Les règles métier (prix, stock, statuts de commande, versements) appartiennent au serveur. L'application reste simple, les mises à jour sont plus sûres, et corriger un comportement n'exige pas toujours une nouvelle version sur les stores.
Planifiez quand même vos publications sur les stores. Les mises à jour OTA sont puissantes, mais tout ce qui touche au code natif, aux permissions ou aux versions de SDK passe par un vrai build et une validation. Considérez l'OTA comme une voie rapide, pas comme un substitut à la rigueur de livraison.
Acheteurs et vendeurs n'ont pas les mêmes priorités. L'acheteur veut de la vitesse et de la confiance. Le vendeur veut de la clarté et de l'efficacité : traiter une commande vite, comprendre chaque étape d'expédition. Réussir les deux compte plus que n'importe quel choix de framework.
React Native + Expo ou natif : comparatif rapide
Critère
React Native + Expo
Natif (Kotlin + Swift)
Délai de mise sur le marché
Plus court, une seule base de code
Plus long, deux bases de code
Coût
Plus bas à construire et à maintenir
Plus élevé, souvent deux équipes
Souplesse de livraison
Mises à jour OTA pour les changements JS
Validation des stores à chaque changement
Performance
Très bonne pour la plupart des apps
Idéale pour le graphisme lourd ou le matériel
Accès aux fonctions du téléphone
Large, extensible par modules natifs
Complet et immédiat
Recrutement
Vaste vivier JavaScript/TypeScript
Spécialistes distincts par plateforme
Idéal pour
Marketplaces, e-commerce, services, contenu, outils internes
Jeux, réalité augmentée, audio/vidéo intensif, intégration profonde à l'OS
Quand choisir le natif
React Native et Expo ne sont pas la réponse à tout. Pensez au natif quand :
Votre produit est gourmand en graphismes : jeux, 3D, réalité augmentée, animations avancées.
Vous avez besoin d'une intégration matérielle ou système très poussée : protocoles Bluetooth sur mesure, traitements en arrière-plan à grande échelle, fonctions propres à l'OS.
Le traitement audio ou vidéo en temps réel est le cœur du produit.
Vous disposez d'une équipe mobile dédiée et du budget, et d'une exigence de performance mesurée que le multiplateforme ne peut pas satisfaire.
Si rien de tout cela ne vous décrit, le natif est probablement une optimisation prématurée.
Checklist de décision pour les fondateurs
Répondez honnêtement avant de choisir :
Mon application est-elle surtout faite d'écrans, de listes, de formulaires, de paiements et de notifications ? Si oui, penchez pour React Native et Expo.
Ai-je besoin d'Android et d'iOS rapidement avec un budget de startup ? Si oui, penchez pour React Native et Expo.
Dois-je pouvoir corriger vite après le lancement ? Si oui, penchez pour React Native et Expo.
Ma valeur principale dépend-elle de graphismes lourds ou d'un matériel particulier ? Si oui, étudiez le natif.
Puis-je financer deux équipes, une par plateforme ? Si non, penchez pour React Native et Expo.
Mon backend est-il prêt ? Une excellente app sur un backend fragile échoue quand même. Investissez dans les deux.
Questions fréquentes
React Native est-il assez solide pour une marketplace en production ?
Oui. Une marketplace, c'est surtout des listes, de la recherche, des formulaires, des paiements et des notifications, ce que React Native gère très bien. Les problèmes de performance viennent le plus souvent de listes, d'images ou d'appels API mal optimisés, pas du framework.
Expo est-il réservé aux prototypes ?
Non. Expo sert à construire et publier des applications en production. Il couvre les builds, les mises à jour et de nombreuses fonctions du téléphone, et vous pouvez toujours ajouter du code natif quand un projet l'exige.
Combien coûte le développement d'une application mobile en Tunisie ?
Cela dépend du périmètre : nombre de profils utilisateurs, intégrations de paiement et de logistique, langues, complexité du backend. Une base de code multiplateforme coûte généralement nettement moins cher que deux applications natives. Le moyen le plus fiable d'obtenir un chiffre réaliste est un court échange de cadrage.
Peut-on commencer avec React Native puis passer au natif ensuite ?
Oui, et beaucoup d'équipes le font. Comme la logique métier vit sur le backend et que le produit est validé tôt, vous pouvez reconstruire certains écrans ou modules en natif plus tard si un besoin réel apparaît.
Faut-il lancer d'abord sur Android en Tunisie ?
Dans la plupart des cas, oui. Android concentre la majorité des utilisateurs locaux, c'est donc la première cible logique. Avec React Native, ajouter iOS ensuite coûte beaucoup moins que de démarrer une seconde base de code.
Pour conclure
La meilleure stack est celle qui met un produit fiable entre les mains d'utilisateurs réels rapidement, et qui reste en bonne santé ensuite. Pour Dokkan, React Native et Expo nous ont offert exactement cela : une équipe, une base de code, une itération rapide et la possibilité de corriger sans longs délais.
Si vous préparez une marketplace, une application e-commerce ou une application métier, découvrez notre étude de cas Dokkan Mobile, lisez comment l'application Android Dokkan Marketplace peut améliorer le e-commerce tunisien, et parcourez nos services de développement d'applications mobiles et notre expertise Android.
Un projet d'application mobile en Tunisie ? Parlez-nous de votre projet et nous vous aiderons à choisir la bonne stack avant que vous ne dépensiez un dinar à mauvais escient.
