Des applications React Native sur les deux stores, par une seule équipe senior
iOS et Android depuis une seule base de code TypeScript - types, logique métier et souvent modules entiers partagés avec le produit web que nous construisons à 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 - ci-dessous, par écrit.
Pourquoi nous y allons
Des raisons 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 divergent.
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 que nous construisons à côté. Les règles de tarification et la logique métier ne s'écrivent qu'une fois.
Un vivier de talents profond
Les développeurs React sont parmi les ingénieurs les plus faciles à recruter, partout. L'application que nous livrons est une application dont votre future équipe peut hériter - de la technologie ennuyeuse, délibérément.
Du natif là où cela compte
React Native rend 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.
Quand nous le déconseillons
Un outil que l'on recommande pour tout est un outil auquel on a cessé de réfléchir. Trois cas 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 est moins chère à construire, à déployer et à mettre à jour - pas de validation en store, pas d'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.
Ce que nous construisons avec
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 - clients d'API et 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 managers qui ne sont pas à un bureau - le visage mobile des systèmes que votre équipe ouvre chaque matin.
Logistique et transport →
Applications chauffeur pour la répartition, la preuve de livraison et les mises à jour de statut qui alimentent directement les flux de devis et de 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 flux de travail 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 flux de travail gagne à vivre sur un téléphone, il est dans le périmètre.
Comment cela s'inscrit dans le processus
La stack est un résultat du diagnostic, pas une donnée d'entrée. React Native est un choix par défaut que nous tenons - des choix par défaut, pas des dogmes, comme nous le disons 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 ?
Pour les interfaces produit - fils, formulaires, tableaux de bord, paiement - oui : React Native rend 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. Vous aurez une version installée 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 - 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 profond.
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.