Des applications React Native sur les deux stores, par une seule équipe senior
iOS et Android depuis une seule base de code TypeScript, avec les types, la logique métier et souvent des modules entiers partagés avec le produit web construit à côté. React Native fait partie de notre stack standard parce qu'il permet à une petite équipe senior de livrer et de maintenir le mobile sans doubler la facture d'ingénierie. Et quand le natif est réellement le meilleur choix, nous le disons par écrit, plus bas sur cette page.
Nos raisons de le choisir
Des critères d'ingénierie, pas de mode : le même test que doit passer chaque outil de notre stack.
Une base de code, les deux stores
Les fonctionnalités arrivent sur iOS et Android dans la même version, construites et maintenues par une seule équipe senior, au lieu de deux équipes de plateforme qui finissent par diverger.
Une logique partagée avec le web
Le même TypeScript, les mêmes types, la même validation et les mêmes clients d'API que le produit web React construit à côté. Les règles de tarification et la logique métier ne s'écrivent qu'une fois.
Un vivier de talents très large
Les développeurs React comptent parmi les ingénieurs les plus faciles à recruter. L'application que nous livrons est donc une application dont votre future équipe pourra hériter : de la technologie ennuyeuse, choisie pour cela.
Du natif là où cela compte
React Native affiche de vrais composants natifs, descend en Swift ou en Kotlin pour les écrans qui l'exigent, et pousse des correctifs over-the-air sans attendre la validation des stores.
Les cas où nous le déconseillons
Un outil que l'on recommande pour tout est un outil auquel on a cessé de réfléchir. Trois situations où la réponse est autre chose.
Jeux, réalité augmentée et capteurs intensifs
La 3D temps réel, la réalité augmentée et tout ce qui sollicite fortement le GPU ou la chaîne de capteurs relèvent de Swift et de Kotlin. L'abstraction qui rend React Native productif devient ici un obstacle : nous vous dirons de partir en natif complet, et nous vous aiderons à le cadrer.
Une application interne mono-plateforme
Si le public est votre propre équipe et que le travail se fait à un bureau, une application web responsive coûte moins cher à construire, à déployer et à mettre à jour : aucune validation en store, aucune installation. C'est le cas de la plupart des outils internes.
Une base de code native en bonne santé
Si vous exploitez déjà des applications Swift ou Kotlin bien faites, les réécrire en React Native est rarement rentable. Gardez ce qui marche : la modernisation doit être incrémentale, pas idéologique.
Les applications que nous développons en React Native
Les formes sous lesquelles le travail mobile arrive le plus souvent, chacune rattachée à un service ou à un secteur que nous connaissons bien.
Applications clients et places de marché →
Le versant mobile des portails, des places de marché et des produits SaaS, avec les clients d'API et les types partagés avec le produit web.
Applications terrain et opérations →
Chauffeurs, techniciens et équipes d'entrepôt qui saisissent la donnée là où le travail se fait : hors ligne d'abord, synchronisé avec la plateforme opérationnelle.
Outils internes en mobilité →
Validations, tableaux de bord et alertes pour les responsables qui ne sont pas à un bureau : le visage mobile des systèmes ouverts chaque matin.
Logistique et transport →
Applications chauffeur pour le dispatch, la preuve de livraison et les mises à jour de statut, qui alimentent directement la cotation et la facturation.
Retail et e-commerce →
Applications de commande, de fidélité et d'exploitation de magasin, branchées sur l'automatisation des stocks et du cycle order-to-cash.
Des copilotes IA dans la poche →
Des fonctions d'assistant intégrées aux processus mobiles, ancrées dans vos données, avec les mêmes garde-fous que la version web.
Une liste représentative, pas une frontière : si un processus gagne à vivre sur un téléphone, il est dans le périmètre.
Sa place dans notre méthode
La stack est un résultat du diagnostic, pas une donnée d'entrée. React Native reste un choix par défaut, et un choix par défaut n'est pas un dogme : nous l'écrivons dans notre façon de construire. Et quand le mobile n'est pas du tout la bonne forme, le diagnostic le dit par écrit, avant qu'une ligne de code ne soit écrite.
Questions fréquentes
Une application React Native aura-t-elle l'air native ?
Oui, pour les interfaces produit : fils, formulaires, tableaux de bord, paiement. React Native affiche de vrais composants natifs, pas une web view. Quand un écran a réellement besoin de code de plateforme, nous écrivons un module natif pour cet écran seul.
Une seule équipe couvre-t-elle vraiment iOS et Android ?
Oui : une base de code, une équipe senior, les deux stores. Les fonctionnalités sortent sur les deux plateformes dans la même version, et la signature, la validation en store et la CI/CD font partie du projet.
En combien de temps une première version peut-elle sortir ?
Une v1 ciblée sort généralement en 2 à 3 mois, facturée au jalon comme tout ce que nous construisons. Une version tournera sur votre propre téléphone bien avant, en général dès les premières semaines.
Pourquoi React Native plutôt que Flutter ?
Flutter est un bon outil, et ce n'est pas une position religieuse. Nous nous standardisons sur React Native parce qu'il partage TypeScript, l'outillage et souvent des modules entiers avec la stack web React que nous construisons, et parce que le vivier de recrutement pour votre future équipe y est bien plus large.
Vous envisagez une application mobile, ou on vous a dit qu'il en fallait une ?
Le diagnostic est gratuit, et si une application web responsive ou du code natif est la meilleure réponse, c'est ce que vous entendrez.