Développeur mobile freelance : préparer un devis jusqu’à la recette
Une application peut fonctionner sur le téléphone du développeur et rester incomplète pour son utilisateur. Les connexions, les interruptions, les comptes et les appareils visés font partie du besoin. Pour une mission mobile, y compris avec Flutter, la proposition doit donc décrire le parcours de validation jusqu’à la remise du produit.
Définir l’usage avant les écrans
Demandez qui utilise l’application, dans quel contexte et pour accomplir quelle action. Un outil interne utilisé sur un parc maîtrisé ne se chiffre pas comme un service ouvert à un public très divers. Les contraintes de connexion et de disponibilité du support peuvent modifier les choix de réalisation.
Décrivez ensuite quelques parcours complets : ouverture du compte, action principale, interruption et reprise. Les écrans intermédiaires, les erreurs et les états vides doivent être discutés. Ils sont faciles à oublier dans une liste de maquettes et peuvent représenter un travail réel.
Recenser les dépendances
L’application peut dépendre d’une API, d’un fournisseur d’authentification, d’un système de paiement ou d’un outil de notification. Vérifiez qui gère ces services et qui peut résoudre un incident. Si l’API n’est pas disponible au démarrage, convenez d’un moyen de tester sans présenter l’intégration finale comme acquise.
Précisez également les accès aux comptes de publication et les responsabilités associées. N’utilisez pas un compte personnel pour héberger durablement un actif client sans accord clair. Le transfert des accès doit être pensé avant la fin de la mission.
Construire une matrice de recette
Listez les appareils et environnements retenus, les parcours critiques et les conditions à tester : connexion lente, session expirée, refus d’une permission ou reprise après interruption. Cette matrice doit rester adaptée au projet ; vouloir tout couvrir sans limite rend le devis inexploitable.
Faites désigner un interlocuteur capable d’accepter le résultat. Précisez le délai de retour et la manière de regrouper les anomalies. Une nouvelle fonctionnalité demandée pendant la recette doit être traitée comme une évolution, avec une estimation distincte.
Chiffrer au-delà du code
Incluez la prise de connaissance, l’intégration, les tests, les corrections et la préparation de la livraison. À titre fictif, dix jours de développement et quatre jours d’intégration et de recette représentent quatorze jours mobilisés. Ce total doit être confronté aux dépendances et non vendu comme une durée universelle.
Une soumission sur une boutique ne garantit pas son acceptation à une date choisie. Vérifiez les exigences officielles en vigueur au moment du projet et distinguez votre prestation des décisions qui appartiennent à un tiers. Définissez ce qui est prévu en cas de demande de correction.
Trouver les bons interlocuteurs
Votre portfolio doit montrer un parcours complet et votre façon de traiter les cas difficiles, pas seulement une animation. Adressez votre proposition à des équipes ayant un besoin que vous savez couvrir, avec une disponibilité réaliste. Pour préparer le prix, utilisez la méthode de TJM puis détaillez le périmètre et la recette dans le devis.