Une estimation d’appli mobile n’est pas un chiffre sorti de nulle part. C’est une somme d’efforts. Chaque rôle consacre du temps à votre projet, et la grille tarifaire actuelle transforme ce temps en coût.
Une fois que vous voyez quelles parties de votre idée ajoutent de l’effort, vous pouvez façonner la portée avant de toucher au budget. Cet article passe en revue les rôles, les choix qui font varier leurs heures, et la façon de lire une estimation pour que rien ne vous surprenne plus tard.
Les rôles derrière une appli mobile
La plupart des projets mobiles font appel à un ensemble de compétences semblable. Tous les projets n’ont pas besoin de chacune avec le même poids.
- Produit et conception : les écrans, les parcours, et la façon dont une personne passe de l’ouverture de l’appli à ce qu’elle venait chercher.
- Développement mobile : l’appli qui s’exécute sur le téléphone, sur iPhone, sur Android ou sur les deux.
- Serveur et API : le serveur, les données, les comptes d’utilisateurs et les connexions aux autres systèmes que vous utilisez déjà.
- Tests : vérifier que l’appli se comporte bien sur de vrais appareils, avec de mauvaises connexions et des saisies inhabituelles.
- Gestion de projet : garder la portée, les décisions et les livraisons sur la bonne voie, pour que les autres rôles consacrent leur temps à construire.
Une appli simple avec peu d’écrans repose surtout sur le développement. Une appli reliée à plusieurs systèmes externes repose surtout sur le travail côté serveur. Une appli grand public où la première impression compte repose surtout sur la conception.
Ce qui fait varier les heures
Voici les choix qui changent le plus souvent l’effort pour un ou plusieurs rôles.
- Les plateformes. Construire pour iPhone et Android ajoute du travail par rapport à une seule plateforme. L’ampleur dépend de l’approche, et l’estimation précise celle qu’elle suppose.
- Les écrans et les parcours. Chaque écran demande de la conception, de la construction et des tests. Chaque embranchement dans un parcours, comme une inscription à plusieurs chemins, multiplie cet effort.
- Les comptes et les permissions. Un seul type d’utilisateur est plus simple que des clients, des employés et des administrateurs qui voient chacun des choses différentes.
- Les intégrations. Les paiements, les cartes, la messagerie, ou votre système actuel de réservation ou de comptabilité demandent tous du travail côté serveur et des tests des deux côtés.
- Les fonctions hors ligne et en direct. Une appli qui fonctionne sans connexion, ou qui se met à jour en temps réel, demande une ingénierie plus soignée qu’une appli qui charge une page et attend.
- La conformité et le traitement des données. Les données de santé, financières ou personnelles entraînent des règles sur le stockage, l’accès et les registres. Cela se voit dans l’effort côté serveur et en tests.
- Les langues. Chaque langue ajoute de la traduction, des vérifications de mise en page et des tests. Nous construisons en cinq langues, alors nous le prévoyons dès le départ plutôt que de l’ajouter après coup.
- Les outils d’administration. Si votre équipe doit gérer du contenu, des utilisateurs ou des commandes, c’est un deuxième produit, habituellement sur le Web.
Ce qui les réduit
Le moyen le plus sûr de réduire l’effort est de construire moins dans la première version, volontairement.
- Commencez par la seule tâche que l’appli doit bien accomplir, et laissez le reste pour une version ultérieure.
- Utilisez des composants et des modèles standards là où des versions sur mesure ne changeraient pas la façon dont les gens utilisent l’appli.
- Prenez vos décisions tôt. Changer de direction en cours de route coûte plus cher que de trancher pendant la conception.
- Réutilisez ce que vous avez déjà. Un système existant doté d’une API fonctionnelle peut économiser du temps côté serveur.
[ !TIP] Lancez l’estimation deux fois : une fois avec tout ce que vous voulez, et une fois avec seulement ce dont la première version a besoin. L’écart entre les deux vous montre où vont vos heures.
Lisez les hypothèses, pas seulement le total
Notre estimateur donne une fourchette de prix en quelques minutes, à partir de la grille tarifaire actuelle. Il montre le coût de construction, les coûts mensuels d’exploitation de l’appli, l’effort par rôle, le nombre de semaines et toutes les hypothèses qui les sous-tendent.
Les hypothèses sont la partie à lire de près. Si l’estimation suppose une seule plateforme et que vous en avez besoin de deux, ou suppose l’absence de paiements alors que vous comptez vendre dans l’appli, la fourchette changera. Corrigez l’hypothèse et relancez l’estimation.
Nous ne mettons ni prix ni heures dans les articles. Les tarifs changent, et l’estimateur montre toujours les tarifs actuels.
Les coûts mensuels après le lancement
Une appli continue de coûter quelque chose après sa mise en ligne. Les serveurs, les comptes des boutiques d’applications, les services externes et les mises à jour pour les nouvelles versions des logiciels de téléphone entraînent tous des coûts récurrents. L’estimateur les présente séparément, pour que vous puissiez planifier l’année et pas seulement la construction.
Choisissez votre façon de travailler
Une fois la portée claire, il y a trois façons de travailler avec nous.
- Un prix fixe pour une portée définie, quand vous savez ce que vous voulez faire construire.
- Une équipe au mois, quand le produit continuera de grandir et que les priorités changeront.
- Un bloc d’heures mensuel avec un délai de réponse promis, pour le soutien et les améliorations régulières après le lancement.
Bien des projets combinent plus d’une formule : un prix fixe pour la première version, puis un bloc d’heures pour que l’appli continue de bien fonctionner.
Prochaine étape
Si vous avez une appli en tête, le moyen le plus rapide de voir où se situent ses heures est de lancer l’estimateur. Cela prend quelques minutes, et vous aurez une fourchette, l’effort par rôle et les hypothèses dont discuter avec nous.
