Développement d'applications React Native

Chaque projet React Native que nous prenons repose sur le même stack, pour la même raison : il permet à une petite équipe senior de livrer des applications de production sans réinventer l'infrastructure à chaque client. Nous avons choisi chaque brique pour une raison concrète de coût ou de délai, pas parce qu'elle est à la mode.

• Expo — un workflow managé avec des config plugins pour les modules natifs, donc nous avons rarement besoin d'un eject vers du code natif brut. Les mises à jour OTA permettent à de petits correctifs d'atteindre les utilisateurs sans attendre une nouvelle revue de store, ce qui compte la semaine suivant le lancement, quand les vrais utilisateurs trouvent les bugs que vos appareils de test n'ont pas trouvés.
• Builds cloud EAS — les builds tournent dans le cloud, pas sur un ordinateur portable. Cela veut dire des builds reproductibles qui ne dépendent pas de la version d'Xcode d'une machine précise ni de certificats locaux, et nous pouvons lancer un build iOS sans posséder de Mac ni en payer un juste pour compiler.
• Supabase — Postgres, auth, storage et edge functions derrière une seule API. Il se comporte comme un backend managé sans le verrouillage, car en dessous c'est une vraie base Postgres que vous pouvez exporter n'importe quand, vers n'importe où, si vous décidez un jour de partir.
• TypeScript en mode strict — chaque projet part avec le typage strict activé dès le premier jour. Moins de plantages en production, moins de bugs silencieux, moins de surprises quand le type d'un champ backend change six semaines dans le projet et que rien ne vous prévient avant qu'un utilisateur ne le rencontre en production.

Ce n'est pas la seule façon de construire une application mobile, mais pour la plupart des applications de startups et de petites entreprises, c'est le chemin réaliste le plus rapide entre une idée et une vraie publication en store — et c'est exactement le stack que nous faisons tourner en production pour nos propres produits, donc nous ressentons chaque aspérité avant un client. Si un élément de ce stack cesse d'être le bon choix pour un projet donné, nous le disons au lieu de forcer l'adéquation.

Construire iOS et Android en natif signifie maintenir deux bases de code dans deux langages différents — généralement Swift pour iOS et Kotlin pour Android — avec deux ingénieurs, ou un seul qui change de contexte toute la journée. React Native ramène cela à une seule base de code et une seule équipe, en partageant la grande majorité de la logique métier, de la gestion d'état et de l'interface entre les plateformes.

Les différences entre plateformes comptent toujours, et nous ne les ignorons pas. Les gestes de navigation, les invites de permission, le comportement des notifications push, et quelques écrans précis sont ajustés par plateforme là où cela affecte réellement l'expérience. Une feuille de partage doit sembler native sur les deux, même si le bouton qui l'ouvre est le même composant en dessous.

Mais le cœur de l'application — les écrans, l'état, les appels API, les règles métier qui ont demandé le plus de temps d'ingénierie à bien traiter — est construit une fois et publié deux fois. Pour la plupart des projets, cela signifie un délai nettement plus court et une facture plus petite que de construire la même application deux fois à partir de zéro, sans demander aux utilisateurs d'accepter une moins bonne expérience sur l'une ou l'autre plateforme.

C'est aussi pourquoi les estimations d'applications React Native passent souvent largement sous les devis tout-natif pour un même périmètre fonctionnel : vous payez un seul effort de construction qui se publie sur deux stores, pas deux chantiers d'ingénierie séparés qui se ressemblent seulement.

Playro, notre réseau social pour gamers, est en ligne sur le Play Store, construit sur ce même stack React Native, Expo et Supabase — celui que nous utilisons pour les projets clients, pas une version de démo simplifiée. Il gère des données de matchmaking en temps réel et une base d'utilisateurs active, exactement le genre de charge qu'une promesse de stack doit tenir.

Stusher, notre application mobile de recommandations, est également en ligne et tourne sur React Native avec Expo Router et Zustand pour la gestion d'état, prouvant que le stack tient au-delà d'un seul produit, sans réécriture entre les applications.

FadeChats, notre produit de chat centré sur la confidentialité, est une application web, pas React Native — construite avec Next.js et WebRTC pour une messagerie pair-à-pair sans stockage de messages. Nous le mentionnons ici parce que c'est la preuve que nous livrons de vrais produits en ligne, aussi bien mobile que web, pas seulement du travail client, et nous sommes transparents sur quel stack a construit quel produit plutôt que de brouiller la ligne pour un meilleur argumentaire. Voir la feuille de route complète des produits →