Pourquoi votre startup n'a pas besoin d'une application mobile (pour l'instant)

J'ai perdu le compte du nombre d'appels de découverte qui commencent de la même façon : « On a besoin d'une app. » C'est l'équivalent moderne du « on a besoin d'un site web » du début des années 2000 — quelque chose que chaque entreprise suppose nécessaire, sans jamais se demander si c'est vraiment le bon investissement maintenant.

Soyons francs : je développe des applications mobiles pour gagner ma vie. Mon équipe en livre régulièrement. Et c'est précisément à cause de cette expérience que je peux vous dire qu'environ 60 % des startups qui viennent nous voir pour une application mobile devraient d'abord construire autre chose.

Ce n'est pas une critique. C'est un schéma que j'ai observé sur des dizaines de projets, et les fondateurs qui écoutent atteignent le product-market fit plus vite en dépensant beaucoup moins.

L'App Store est un cimetière

Voici un chiffre qui devrait faire réfléchir tout fondateur : l'application mobile moyenne perd 77 % de ses utilisateurs actifs quotidiens dans les trois premiers jours après l'installation. En 30 jours, ce taux dépasse les 90 %. La plupart des applications construites ne trouvent jamais leur public.

L'App Store et Google Play hébergent environ 5 millions d'applications combinées. À moins que vous ne construisiez quelque chose qui nécessite fondamentalement le matériel de l'appareil — la caméra, le GPS, le Bluetooth, le stockage hors ligne, les notifications push liées à des flux critiques — vous ajoutez à une pile où la découverte est brutale et la rétention pire encore.

Instagram avait besoin du natif. Votre tableau de bord SaaS, probablement pas.

Quoi construire à la place

Une application web responsive

Une application web responsive bien construite fait presque tout ce qu'une application mobile fait, avec trois avantages majeurs :

Zéro friction d'accès. Pas de téléchargement, pas d'approbation App Store, pas de dialogues « Mise à jour disponible ». Les utilisateurs tapent une URL ou cliquent un lien et c'est parti.
Un seul code source. Vous construisez pour toutes les tailles d'écran simultanément. Desktop, tablette, mobile — même pipeline de déploiement, même équipe.
Mises à jour instantanées. Livrez un correctif à 14h et chaque utilisateur l'a à 14h01. Pas d'attente du review App Store. Pas de fragmentation de versions.

J'ai travaillé avec une startup de logistique à Accra l'année dernière qui était convaincue qu'elle avait besoin d'applications iOS et Android séparées pour son tableau de suivi de flotte. Nous avons construit une application web responsive en Next.js à la place. Temps de développement total : 8 semaines. Les applications natives équivalentes auraient pris 14 à 16 semaines avec une équipe plus large.

Six mois plus tard, leurs chauffeurs l'utilisent quotidiennement sur leurs téléphones. Leurs responsables opérationnels utilisent la même application sur desktop. Une seule équipe la maintient.

Une Progressive Web App

Si vous avez besoin de fonctionnalités proches du natif — accès hors ligne, notifications push, installation sur l'écran d'accueil — une PWA vous amène à 80 % du chemin sans les gardiens de l'App Store.

Les PWA fonctionnent sur la technologie web moderne mais peuvent être « installées » sur les téléphones et apparaître aux côtés des applications natives. Les utilisateurs obtiennent la vitesse et la commodité du natif sans le téléchargement de 50-200 Mo que la plupart des apps demandent.

Pour les marchés en Afrique et en Asie du Sud-Est où les coûts de données sont réels et le stockage des appareils est limité, cette distinction compte énormément. Une PWA qui charge en 200 Ko contre une application native qui demande 80 Mo de stockage — la PWA gagne systématiquement en adoption.

Quand le natif est vraiment nécessaire

Il y a des raisons légitimes de passer au natif. Voici ma check-list honnête :

Construisez en natif quand :

Votre proposition de valeur principale dépend de la caméra, de la RA ou de capteurs complexes
Vous avez besoin d'une intégration profonde avec le système d'exploitation (HealthKit, widgets, Siri)
Le mode hors ligne est non négociable (pas juste un support offline sympa, mais l'app doit fonctionner entièrement sans internet)
Les exigences de performance sont extrêmes (jeux, traitement vidéo en temps réel, rendu 3D)
Les notifications push sont votre mécanisme principal d'engagement et le timing est critique

Ne construisez pas en natif juste parce que :

« Tout le monde a une app » — vos concurrents ayant des apps ne signifie pas que les leurs fonctionnent
« On doit avoir l'air légitime » — une web app soignée a l'air tout aussi professionnelle
« Nos utilisateurs préfèrent les apps » — testez cette hypothèse avant de miser 50-150K € dessus

L'approche par phases qui fonctionne vraiment

Les fondateurs les plus malins avec qui j'ai travaillé suivent un schéma :

Phase 1 (Mois 1-3) : Construire une application web responsive. La livrer. Obtenir des utilisateurs. Apprendre ce qu'ils font vraiment versus ce qu'on supposait.

Phase 2 (Mois 3-6) : Si l'usage mobile dépasse 60 % et que vous perdez des utilisateurs à cause de limitations natives spécifiques, évaluer les améliorations PWA.

Phase 3 (Mois 6-12) : Si vous avez un fort product-market fit et des preuves claires que des fonctionnalités natives amélioreraient les métriques clés, construire l'app — mais maintenant vous savez exactement quelles plateformes prioriser et quelles fonctionnalités comptent vraiment.

Ce n'est pas une question d'économie. C'est une question de stratégie avec votre runway. Chaque euro dépensé à construire une application native avant d'avoir validé votre modèle produit est un euro qui aurait pu servir à trouver vos 1 000 premiers vrais utilisateurs.

Le mot de la fin

La meilleure application est celle que vos utilisateurs utilisent vraiment. Et pour la plupart des produits en phase initiale, le chemin le plus fluide pour mettre quelque chose de réel devant les gens, c'est le web. Commencez par là. Prouvez votre concept. Puis investissez dans le natif quand les données vous le disent — pas quand le buzz le fait.

Votre startup a besoin d'utilisateurs et de validation, pas d'une icône d'app.