Vous voulez un chiffre. Nous comprenons. Le problème, c'est qu'une application mobile est un ensemble de décisions, et chacune ajoute ou retire du travail. Deux applications qui se ressemblent à l'écran peuvent demander un effort très différent, à cause de ce qui se trouve derrière l'écran.
Cet article explique où vont les heures, ce qui les fait grimper ou baisser, et comment obtenir une vraie fourchette pour votre idée en quelques minutes. Nous n'écrirons pas de prix ici. Les tarifs changent, et notre estimateur travaille toujours à partir de la grille tarifaire courante. Ce qui suit, c'est le raisonnement derrière les chiffres qu'il vous donne.
Le coût, ce sont des heures, par rôle
Chaque estimation que nous produisons se décompose de la même façon : des heures, par rôle, au tarif courant. Sur un projet mobile typique, les rôles sont les suivants :
- Produit et découverte. Quelqu'un transforme votre idée en une liste d'écrans, de parcours et de règles. C'est là que la portée se définit, et que la plupart des surprises sont évitées.
- Design. Les maquettes filaires d'abord, puis l'apparence finale. Chaque écran ajouté est un écran à concevoir, et chaque état de cet écran (vide, chargement, erreur) représente plus de travail.
- Développement mobile. Le code qui s'exécute sur le téléphone, pour iOS, Android ou les deux.
- Backend et API. La plupart des applications ont besoin d'un serveur derrière elles : comptes, données stockées, notifications, paiements, côté administration. Les utilisateurs ne le voient jamais, mais c'est souvent une grande part de la construction.
- Assurance qualité. Des tests sur de vrais appareils avant chaque version.
- Gestion de projet. La planification, la revue, et garder tout le monde aligné sur la même portée.
L'estimateur montre l'effort de chaque rôle séparément, pour que vous voyiez quelle partie de votre idée fait monter le coût, et décidiez si elle mérite sa place.
Ce qui fait bouger les heures
La liste ci-dessous est ce que nous regardons en premier quand nous cadrons une application mobile.
Table : Les décisions qui changent l'effort sur une application mobile | Décision | Pourquoi elle change le travail | | --- | --- | | Nombre d'écrans et de parcours | Chaque écran est conçu, construit et testé. Chaque parcours entre les écrans est de la logique à écrire et à vérifier. | | Une plateforme ou deux | iOS et Android sont des systèmes différents. Construire pour les deux coûte plus qu'un seul, même quand le code est partagé. | | Connexion et rôles d'utilisateurs | Comptes, réinitialisation de mot de passe, permissions et rôles d'administration vivent tous sur le backend et demandent des tests soignés. | | Paiements | Encaisser de l'argent implique un fournisseur de paiement, des reçus, des remboursements et des cas limites. | | Intégrations | Chaque système externe que vous connectez (CRM, comptabilité, cartes, messagerie) a ses propres règles et ses propres pannes à gérer. | | Usage hors ligne et synchronisation | Une application qui fonctionne sans connexion doit stocker les données localement et les réconcilier plus tard. C'est de la vraie ingénierie. | | Conformité | Les règles sur les données personnelles, les données de santé ou les dossiers financiers ajoutent des contraintes de conception, de la journalisation et de la revue. | | Outils d'administration | Votre équipe a besoin d'un moyen de voir les utilisateurs, le contenu et les problèmes. C'est souvent une seconde application web, plus petite. | | Finition | Les animations, les composants sur mesure et le soin au pixel près valent la peine pour certaines applications et sont du gaspillage pour d'autres. |
Aucun de ces choix n'est mauvais en soi. L'important, c'est de les faire exprès. Une première version qui laisse de côté la synchronisation hors ligne et sort sur une seule plateforme peut rejoindre vos utilisateurs plus tôt, et la deuxième version peut ajouter le reste une fois que vous savez ce qu'ils utilisent vraiment.
[ !TIP] Avant de lancer l'estimateur, écrivez une liste simple des écrans que vous imaginez et des services externes avec lesquels l'application doit communiquer. Plus l'entrée est claire, plus la fourchette obtenue est serrée.
Le coût après le lancement
La construction n'est pas tout le coût. Une application en boutique continue de coûter quelque chose chaque mois : l'hébergement du backend, les services tiers dont elle dépend, et le travail pour la garder à jour à mesure que les téléphones et les systèmes d'exploitation changent. L'estimateur affiche les coûts mensuels à côté du coût de construction, pour que vous voyiez les deux avant de décider.
Trois façons de payer
La façon dont vous achetez le travail façonne aussi le total.
- Un prix fixe pour une portée définie. Idéal quand les écrans et les règles sont arrêtés. Vous connaissez le chiffre avant que nous commencions.
- Une équipe au mois. Idéal quand le produit est encore en découverte et que vous voulez ajuster la direction à mesure que vous apprenez.
- Un bloc d'heures mensuel avec un délai de réponse promis. Idéal pour une application déjà en ligne qui a besoin d'un entretien régulier.
Beaucoup de projets commencent avec la première formule et passent à la troisième après le lancement.
Obtenez votre fourchette en quelques minutes
Nous sommes établis à Kelowna, en Colombie-Britannique, et nous construisons des applications web et mobiles pour des clients de l'Okanagan, de partout au Canada, des États-Unis et du monde entier. L'estimateur vous donne une fourchette de prix à partir de la grille tarifaire courante : coût de construction, coûts mensuels, effort par rôle, durée et chaque hypothèse derrière. Lancez-le avec votre idée, changez quelques réponses, et regardez quelles décisions font bouger le chiffre. C'est la réponse la plus honnête à la question posée dans ce titre.
