Création d'application mobile — votre idée dans toutes les poches.

Décision argumentée selon 3 critères. (1) Performance et features système : jeu 3D, AR/VR, intégration profonde hardware (capteurs avancés) → natif obligatoire. (2) Équipe existante : si votre équipe web connaît déjà React/TypeScript, React Native fait gagner 30-40 % de vélocité. (3) Time-to-market et budget : cross-platform divise souvent le coût de développement par 1,5 à 2 pour des apps « produit » standard. React Native + Expo SDK 52 ont rattrapé le natif sur 95 % des cas d'usage PME/startup — on recommande cette voie par défaut, avec bascule natif sélective si un écran spécifique l'impose.

iOS (App Store Connect) : note App Privacy détaillée obligatoire (type de données collectées, partagées, usage, liens avec l'utilisateur), App Tracking Transparency pour tout tracking cross-app, conformité Required Reason API (API sensibles nécessitent une raison déclarée), screenshots aux nouvelles résolutions iPhone 17/Pro. Android (Google Play Console) : Target SDK 35 (Android 15) obligatoire depuis août 2025 pour les nouvelles apps, déclaration Data Safety obligatoire, SDK tiers listés dans le SDK Index Google, conformité edge-to-edge (gestion safe areas). On s'occupe de la conformité totale — zéro rejet évitable.

Expo SDK 52 (sorti fin 2025) est la version stable qui fait d'Expo + React Native la référence 2026 pour le développement mobile cross-platform. Avantages concrets : New Architecture activée par défaut (Fabric + TurboModules = perf native), EAS Build pour builds cloud sans Mac nécessaire, EAS Update pour pousser des mises à jour JS en quelques minutes sans re-soumission store, support Android 15 et iOS 26, API modulaire (vous n'embarquez que ce dont vous avez besoin), plugins tiers stables (notifications, auth biométrique, achats in-app, BLE). On utilise systématiquement Expo sauf contrainte technique forte qui l'interdirait (très rare).

Le calendrier se construit au cadrage et se contractualise au devis, jalon par jalon. Trois facteurs le déterminent avant tout. Le volume et la nature des écrans d'abord : un MVP simple (5-8 écrans, authentification, liste, détail, notifications basiques) n'a rien à voir avec une app produit complète (15-25 écrans, backend API, paiements Stripe, mode hors ligne), ni avec une app à synchronisation temps réel, géolocalisation, vidéo ou IA embarquée. Le backend ensuite : une API existante à brancher, ou un serveur complet à construire. La publication enfin, dont une part ne dépend pas de nous — la revue Apple et Google. Ce qui ne change pas : on livre par sprints, avec des versions installables sur votre téléphone via TestFlight et Internal Testing — vous testez en continu, pas à la fin.

Processus complet pris en charge. App Store : création/configuration compte Apple Developer, certificats et provisioning profiles, screenshots aux 6 résolutions requises, App Privacy détaillée, gestion TestFlight pour les betas, soumission avec notes de revue détaillées, suivi jusqu'à l'approbation (typiquement 24-72 h en 2026). Google Play : configuration Play Console, signature app Play App Signing, Data Safety, Internal Testing + Closed Testing avant release, gestion des étapes de rollout progressif (10 %, 50 %, 100 %).

Six leviers qu'on applique systématiquement. (1) Mots-clés dans le TITRE (App Store) et le nom (Play Store) — recherche préalable via App Radar ou AppTweak. (2) Screenshots narratifs avec annotations texte (pas juste des captures d'écran nues) aux bonnes résolutions. (3) App Preview vidéo 15-30 sec qui montre les 3 valeurs clés. (4) Description structurée avec les mots-clés secondaires en naturel. (5) Note et avis pilotés via un prompt in-app bien timé (après succès utilisateur, pas après un crash). (6) Localisation EN + FR minimum, plus les langues des marchés ciblés. ASO bien fait = 2-3 × plus de téléchargements organiques.

Deux stratégies combinées. (1) EAS Update (Expo) pour pousser du code JS/TS en quelques minutes, sans re-soumission store — idéal pour corriger des bugs UI ou ajuster des textes. Limite : ne marche que pour du code JS, pas pour les changements qui touchent au code natif. (2) Phased rollout via App Store Connect et Google Play Console pour déployer progressivement une nouvelle version (10 %, 25 %, 50 %, 100 %) — si crashs détectés, on stoppe le rollout avant d'impacter tout le monde. Résultat : time-to-fix critique divisé par 5 vs publication classique.

Souvent oui, avec nuances. Une PWA (Progressive Web App) c'est votre site qui s'installe comme une app — avantages : pas de soumission store, une seule base de code web, indexable SEO. Limites : fonctionnalités natives restreintes (notifications push limitées sur iOS, pas d'accès Bluetooth/NFC avancé, pas d'achats in-app App Store). Notre reco 2026 : PWA pour les usages occasionnels ou B2B interne, app native/cross-platform pour tout ce qui nécessite rétention quotidienne, notifications riches, ou monétisation via IAP. On peut développer les deux en partageant un backend unique pour minimiser le coût : la partie web relève alors de notre offre de création de site web, l'app mobile de celle-ci.

VOUS, sans ambiguïté. Compte Apple Developer + Google Play Console à VOTRE nom (entreprise ou personnel selon préférence), code source sur VOTRE GitHub, backend hébergé sur VOS comptes Vercel/AWS. On ajoute nos devs en accès collaborateur pour le temps du projet, accès retirés automatiquement à la fin du contrat. Si vous changez de prestataire ou reprenez en interne, tout est transférable sans friction — on a prévu la documentation technique et le handover pour ça dès le cadrage.

Un rejet store n'est pas un échec, c'est une étape normale (30-40 % des premières soumissions). Processus qu'on applique. (1) Analyse détaillée du motif (Apple donne la « guideline » violée, Google donne le type de violation). (2) Correction ciblée : la majorité des rejets concernent App Privacy mal remplie, permissions non justifiées, description trompeuse ou crash sur un écran spécifique — rien de structurellement bloquant. (3) Re-soumission avec note de revue expliquant les changements (important pour iOS) : la correction porte presque toujours sur un point précis, et l'app repart en revue dans la foulée. Dans les cas rares (rejet "spirit of the guidelines" subjectif), on rédige un appel ou on adapte l'approche. Les 2 premiers aller-retour de revue sont prévus dans le périmètre standard.

Dès que vos utilisateurs travaillent sur le terrain, la réponse est oui — et cela se décide au cadrage, jamais une fois le développement lancé. Un technicien en sous-sol, un commercial dans un parking souterrain, un livreur en zone blanche : si l'app affiche une roue qui tourne, elle est abandonnée en une semaine. Le mode hors ligne consiste à stocker sur l'appareil les données utiles, à autoriser la saisie sans réseau, puis à synchroniser dès que la connexion revient. La vraie difficulté n'est pas technique, elle est métier : que faire quand deux personnes ont modifié la même fiche chacune de leur côté, hors ligne ? On tranche cette règle de conflit avec vous — priorité au dernier enregistrement, priorité au terrain, ou validation manuelle — parce qu'aucune bibliothèque ne décidera à votre place. Un mode hors ligne bien conçu se reconnaît à un détail : l'utilisateur ne sait même pas qu'il est hors ligne, et rien ne se perd. Quand l'app mobile n'est que la façade terrain d'un outil métier plus large, la logique de synchronisation se conçoit avec le back-office : c'est le périmètre de nos solutions sur mesure.

Tout dépend de ce que vous vendez, et l'arbitrage change votre modèle économique — donc il se pose au cadrage. Pour un bien physique ou un service consommé hors application (une commande, une réservation, une prestation), vous encaissez avec le prestataire de paiement de votre choix — Stripe par exemple — sans commission de magasin d'applications. Pour un contenu ou une fonctionnalité numériques consommés dans l'app (abonnement, contenu premium, crédits), Apple et Google imposent en principe leur système d'achat intégré et prélèvent une commission de l'ordre de 30 %, ramenée à 15 % pour les développeurs sous un seuil annuel de chiffre d'affaires et, chez Apple, sur la deuxième année d'abonnement. Le règlement européen sur les marchés numériques (DMA) a ouvert des brèches depuis 2024 : dans l'Union européenne, une app peut orienter l'utilisateur vers un paiement externe, sous conditions et avec des frais réduits. Ce cadre continue d'évoluer, y compris devant les tribunaux — on vérifie l'état des règles au moment de votre lancement, pas d'après un article de blog de l'an dernier.

Trois cadres se superposent, et c'est ce qui rend le sujet piégeux. Les règles des plateformes d'abord : Apple exige une déclaration de confidentialité détaillée et le consentement explicite au suivi entre applications, Google impose une section « Sécurité des données » complète et vérifiable — une déclaration inexacte suffit à faire rejeter une mise à jour. Le RGPD ensuite : une app collecte souvent bien plus qu'un site — identifiant publicitaire, localisation, contacts, capteurs — et chacun de ces accès doit être justifié, minimisé et expliqué. La CNIL a publié en 2024 une recommandation dédiée aux applications mobiles, suivie d'une phase de contrôles engagée en 2025 : le consentement doit être recueilli avant toute lecture ou écriture sur le terminal, et refuser doit être aussi simple qu'accepter. Les bibliothèques tierces enfin, dont vous restez responsable : chaque outil de mesure ou de publicité embarqué envoie des données quelque part. Nous auditons ces trois couches avant la soumission — un rejet pour déclaration incohérente coûte des semaines.

Une application n'est pas un site : elle vit dans deux systèmes d'exploitation qui changent chaque année et dans deux magasins qui durcissent leurs exigences en continu. Trois échéances reviennent. Les nouvelles versions d'iOS et d'Android, qui modifient parfois des comportements d'interface ou de permissions et imposent une passe de tests sur les nouveaux appareils. L'obligation de cibler une version récente de l'API Android pour continuer à publier : Google relève ce seuil chaque année, et une app qui ne suit pas finit par ne plus pouvoir être mise à jour du tout. Les certificats et comptes développeur enfin, à renouveler sous peine de voir l'app disparaître du magasin. Les 6 mois de suivi post-lancement inclus couvrent ces ajustements sur le périmètre livré ; au-delà, un contrat de maintenance légère suffit dans la plupart des cas. L'essentiel est de ne pas laisser passer deux ans : c'est la remise à niveau tardive qui coûte cher, jamais le suivi régulier.

Cinq facteurs dominent le chiffrage : le nombre d'écrans et de parcours (un MVP à 6 écrans n'a rien à voir avec une app à 25 vues et 3 rôles utilisateurs), le choix cross-platform ou natif (React Native mutualise iPhone et Android, le natif double une partie du travail), le backend (une API existante à brancher ou un serveur complet à créer), les fonctionnalités spécifiques (paiement in-app, mode hors ligne, géolocalisation, temps réel) et le niveau de finition — tests utilisateurs, animations, accessibilité. Le devis est gratuit et envoyé sous 24 h après votre brief via notre page contact : forfait ferme, 40 % au démarrage, 60 % à la livraison, avenant écrit pour tout hors-périmètre. Pour comparer sereinement plusieurs prestataires, notre guide pour choisir son agence web liste les bonnes questions à poser — app mobile comprise.