Faisabilité d’une application mobile : votre idée est-elle réalisable ?

1. Demandez un verdict, avec ses conditions

« Oui, on peut le faire » ne suffit pas pour engager un budget. Demandez ce qui permet cette réponse et ce qui reste inconnu. Un verdict utile porte sur une version précise, avec un budget et des dépendances identifiées.

Une difficulté peut changer le calendrier ou le périmètre sans condamner l’idée. Mais si une fonction indispensable dépend d’un accès refusé, le projet peut rester bloqué dans sa forme actuelle.

• Faisable : les éléments nécessaires sont accessibles et le fonctionnement est défini.
• À tester : un point essentiel reste incertain ; il faut une preuve avant de s’engager.
• À simplifier : une première version plus courte répond au besoin dans les moyens disponibles.

2. Vérifiez les données et les outils connectés

Votre app doit reprendre les disponibilités d’un logiciel existant ? Demandez si ce logiciel propose une API, une passerelle entre deux logiciels. Vérifiez aussi que votre abonnement autorise son usage et que les informations nécessaires sont réellement accessibles.

Lire les créneaux ne suffit pas si l’app doit aussi réserver, annuler et éviter les doublons. Un test doit couvrir ces opérations. L’accord du fournisseur, les limites d’utilisation et les coûts éventuels font partie de la décision.

Pour vos propres données, précisez leur origine, qui les met à jour et qui peut les consulter. Un fichier incomplet ou des droits d’accès mal définis deviennent des problèmes dans l’app. Utilisez des données fictives pour les premières démonstrations.

3. Testez les fonctions importantes sur téléphone

« iOS et Android » décrit deux destinations. Cela ne prouve pas que chaque fonction se comportera de la même façon sur tous les appareils. Une connexion Bluetooth, la caméra ou une action en arrière-plan méritent une vérification ciblée si votre service en dépend.

Fixez les appareils et versions de système pris en charge. Testez l’action essentielle sur les deux plateformes, avec les autorisations acceptées puis refusées. Une démonstration sur ordinateur valide une partie du parcours ; elle ne remplace pas ce contrôle.

4. Précisez ce qui fonctionne sans réseau

Consulter un billet déjà téléchargé et réserver la dernière place sans connexion sont deux besoins différents. Le premier utilise une information enregistrée. Le second doit gérer ce qui a pu changer sur les autres téléphones.

Listez ce qui reste visible, ce qui peut être modifié et ce qui attend le retour du réseau. Précisez aussi comment résoudre deux modifications contradictoires. Le fonctionnement hors ligne doit être prévu dans le projet ; installer une app sur un téléphone ne le rend pas automatique.

5. Cadrez les paiements et les notifications

Vendre un accès à des vidéos dans l’app et encaisser un atelier en présentiel relèvent de règles différentes. Apple et Google distinguent les achats numériques des biens et services physiques. Le moyen de paiement doit être choisi selon ce qui est vendu, les pays concernés et les exceptions applicables. Le choix d’un prestataire de paiement ne suffit pas à trancher.

Une notification dépend aussi des réglages de l’utilisateur. Sur iOS, les alertes nécessitent une autorisation ; Android 13 et les versions suivantes prévoient une permission pour les notifications ordinaires. Prévoyez donc un endroit dans l’app où retrouver une confirmation ou une annulation, même sans alerte.

Apple : règles sur les paiements

Google Play : règles sur les paiements

Apple : autorisation des notifications

Android : permission de notification

6. Isolez le test qui peut changer la décision

La bonne preuve technique répond au point le plus risqué. Si le projet dépend d’un agenda externe, commencez par une réservation de test, son annulation et une tentative sur un créneau déjà pris. Ajouter dix écrans ne répondra pas mieux à cette question.

Définissez avant le test ce qui constitue un succès, qui le réalise et ce qui sera décidé en cas d’échec. Son périmètre, son coût et ses limites doivent être convenus. Une maquette montre l’enchaînement des écrans ; elle ne prouve pas qu’un paiement ou une connexion à un outil fonctionne.

Décrire les besoins dans votre cahier des charges

7. Séparez faisabilité et intérêt commercial

Une app peut fonctionner sans trouver ses utilisateurs. La faisabilité technique répond à « pouvons-nous la construire ? ». L’intérêt commercial répond à « qui en a besoin, pourquoi l’utiliserait-il et qui paierait ? ».

Présentez le parcours essentiel à des personnes concernées. Observez ce qu’elles comprennent et ce qu’elles utilisent aujourd’hui. Un compliment sur le design ne vaut pas une intention d’achat vérifiée. Intégrez aussi les dépenses après lancement : hébergement, services utilisés, maintenance et acquisition des premiers utilisateurs.

Comprendre le budget d’une application mobile

8. Arrivez au cadrage avec vos vraies contraintes

Préparez le parcours principal, les outils à connecter, votre budget et la date souhaitée. Ajoutez les points inconnus plutôt que de les masquer. Le premier échange chez Keenov sert à définir les fonctions utiles et à vérifier l’adéquation du projet avec notre accompagnement.

La création démarre à 8 000 € HT. Le calendrier annoncé est de 30 à 60 jours selon le périmètre et les validations. L’accompagnement à la publication est chiffré au devis avec Launch ou Premium ; les décisions et délais d’examen des stores restent distincts. Ces repères ne remplacent pas l’étude de votre projet.

Réserver un appel de cadrage

Préparer la publication sur les stores