Que préparer avant d'estimer une application mobile

Une tâche claire vaut mieux qu'un dossier technique prématuré

Vous pouvez demander une estimation alors que votre idée évolue encore. Inutile de choisir une base de données ou de dessiner chaque écran avant le premier échange. L'équipe a surtout besoin de comprendre qui utilisera l'application, ce que cette personne doit accomplir et quels outils votre entreprise possède déjà.

La difficulté vient souvent des mots que chacun interprète différemment. « Réserver » peut vouloir dire envoyer une demande à un salarié, bloquer un créneau disponible ou acheter la dernière place. Une estimation fondée sur la mauvaise interprétation peut sembler précise sans être utile. Un bon résumé du projet permet d'éviter cet accord seulement apparent.

Commencez par une personne et son résultat

Écrivez une phrase qui pourrait décrire une journée ordinaire. « Nos élèves doivent ouvrir leur prochaine leçon et transmettre un exercice au professeur » donne plus de repères qu'« un écosystème éducatif innovant ». On comprend pour qui le produit existe et quel résultat doit rester possible dans une première version réduite.

Expliquez ensuite le fonctionnement actuel. Les liens arrivent peut-être dans une conversation collective, les devoirs par courriel et les accès sont vérifiés manuellement. Ces détails montrent où l'application doit intervenir. Sans eux, on risque de moderniser une interface tout en conservant la difficulté principale.

La première version doit mener un parcours utile jusqu'au bout. Recommandations, communauté et rapports avancés peuvent attendre s'ils ne sont pas nécessaires à ce résultat. Ce n'est pas renoncer à l'ambition du projet. C'est distinguer la première vérification de son développement futur.

Remplacez une demande vague par un parcours observable

Prenons un service fictif de réservation de cours. La demande vague serait : « Nous voulons une application comme une grande place de marché du fitness, avec paiement, réservation et notifications ». On ignore si vous exploitez un établissement ou reliez des entreprises indépendantes, si les places sont limitées et qui traite les annulations.

Une formulation plus utile serait : « Les membres de notre premier studio choisissent un cours, réservent une place libre et paient si leur abonnement ne la couvre pas. Le personnel modifie le planning et consulte les participants. Nous n'ajoutons ni autres établissements ni espace social au lancement ».

Ce n'est pas encore un cahier des charges technique, mais plusieurs ambiguïtés importantes ont disparu. Ajoutez une exception : deux personnes choisissent la dernière place, ou le paiement est confirmé après expiration de la réservation. L'équipe peut désormais examiner une question précise au lieu d'imaginer toute une plateforme.

Un résumé d'une page à compléter

Utilisez les champs suivants comme document de travail. Des réponses courtes et honnêtes valent mieux qu'une présentation commerciale. Indiquez « non décidé » si nécessaire et nommez la personne capable de trancher.

Utilisateur et problème : [Qui aider, comment cette personne procède aujourd'hui et ce qui la gêne.]

Parcours principal : [Point de départ, choix ou envoi, confirmation du résultat.]

Travail de l'entreprise : [Qui prépare les contenus, confirme les opérations, traite les exceptions et répond aux clients.]

Première version : [Fonctions indispensables au parcours. Dans une phrase séparée, fonctions reportées.]

Systèmes existants : [Services à relier, responsables, documentation et accès de test.]

Design et contenus : [Idée, références, croquis ou maquettes finalisées ; responsables des textes, images et langues.]

Conditions de lancement : [Pays, langues, iOS ou Android, date nécessaire et raison de cette contrainte.]

Décisions ouvertes : [Questions susceptibles de modifier le plan et personnes chargées de les clarifier.]

N'incluez ni mots de passe ni véritables données clients. Un exemple fictif explique généralement le besoin tout aussi bien. Si un accès protégé devient nécessaire, il pourra être organisé séparément.

Décrivez ce qui se passe en dehors du téléphone

L'interface mobile n'est qu'une partie du service. Lorsqu'un client demande un remboursement, quelqu'un doit recevoir la demande, décider et mettre le dossier à jour. Lorsqu'un professeur publie une leçon, quelqu'un doit pouvoir la charger, la remplacer et la retirer.

Vous n'avez pas besoin de concevoir toute l'administration avant l'estimation. Décrivez les actions du personnel et les conséquences d'une erreur. Une personne à l'accueil peut avoir le droit de modifier une présence sans pouvoir changer les coordonnées de paiement. Le guide de l'interface d'administration aide à distinguer ces responsabilités.

Précisez aussi ce qui peut rester manuel au début. Une exportation quotidienne peut suffire pour un petit essai. Une demande urgente ne peut pas attendre dans une boîte que personne ne consulte. Le traitement manuel est un choix de périmètre, pas une façon de faire disparaître le travail.

Rendez les dépendances externes visibles

Deux applications comportant autant d'écrans peuvent présenter des risques différents en raison de leurs systèmes sous-jacents. « Relier notre CRM » ne suffit pas si personne ne connaît son responsable ou les informations accessibles.

Ne copiez pas les clés de production pour donner une impression de dossier complet. Une documentation publique ou le contact habilité suffit d'abord. Si le fournisseur n'est pas choisi, dites-le. Comparer des services est un travail à part entière, qui doit apparaître parmi les décisions ouvertes.

Expliquez ce que vous retenez des références

Deux ou trois références peuvent suffire si chacune comporte une observation précise. « Dans ce planning, je trouve rapidement une soirée libre » aide à décider. « Faites comme cette application » ne dit pas quelle partie d'un produit développé pendant des années vous voulez reprendre.

Montrez également ce qui vous déplaît. Une erreur de paiement n'indique peut-être pas la prochaine action, ou un élève ne retrouve pas une leçon commencée. Ces situations rendent vos priorités plus claires qu'une longue liste d'adjectifs. La référence sert à expliquer un choix, pas à demander la copie d'une création.

Soyez aussi précis sur vos propres éléments. Un fichier Figma peut contenir des écrans aboutis, mais aucune annulation ni situation vide. Une application existante peut posséder des données utiles et un serveur mal documenté. « Design terminé » et « serveur prêt » demandent donc quelques explications.

Distinguez une échéance d'une préférence

Expliquez pourquoi la date compte. Un début de formation, un engagement contractuel avec un partenaire et une préférence personnelle n'imposent pas les mêmes contraintes. Ajoutez les tâches de votre entreprise : préparer les comptes, livrer les contenus, vérifier les règles, obtenir les autorisations et valider les maquettes.

Ces dépendances doivent apparaître dans l'estimation, au lieu d'être supposées disponibles à temps. Si la date est fixe, demandez quelles réductions préservent le parcours principal. Retirer quelques écrans décoratifs ne résout pas une intégration inexistante.

Les méthodes de calcul sont abordées dans le guide du coût de développement. Cette page vise à améliorer les informations de départ, pas à attribuer un montant standard à chaque idée. N'adaptez pas votre description à un chiffre isolé trouvé dans un autre projet.

Demandez les hypothèses, les exclusions et la suite

Une réponse utile indique ce que l'équipe a compris, les travaux inclus, les exclusions et les vérifications restantes. Elle distingue une première orientation d'un engagement de livraison fondé sur des exigences examinées. Cette distinction évite des attentes que personne n'a réellement acceptées.

Demandez quelle hypothèse est la plus fragile. Par exemple : « Nous supposons que votre logiciel de planning empêche les doubles réservations ». La prochaine étape peut être une vérification technique limitée. C'est plus informatif que de cacher l'incertitude derrière une conclusion apparemment définitive.

Le guide de sélection d'une agence aide à comparer les réponses. Partagez les clarifications importantes et la même version actualisée avec toutes les équipes. Sinon, vous évaluerez aussi leurs différences d'information, pas seulement leur capacité à réaliser le projet.

Vérifiez si le document peut déjà partir

Relisez-le comme une personne qui ne vous connaît pas. Pourra-t-elle identifier le premier utilisateur, son résultat, le travail de l'entreprise et la question principale encore ouverte ? Si oui, vous avez probablement de quoi entamer un échange utile. Une page supplémentaire de fonctions ne rendra pas forcément le besoin plus clair.

Chez Appfyl, le court questionnaire du projet permet d'envoyer ces éléments pour examen. Il s'agit d'une demande, pas d'un calcul immédiat ni d'une promesse de date. Le même résumé convient aussi à une discussion avec une autre équipe.

Lorsque le comportement doit être précisé, passez au modèle de cahier des charges technique. Le résumé présente le problème et les limites ; le cahier des charges décrit le fonctionnement et la recette. Cette séparation évite une préparation documentaire sans fin.

Questions fréquentes