Commencez par déterminer si vous avez besoin d’une application
La décision la plus coûteuse concernant une application est prise avant même qu’un seul ligne de code n’existe : celle de la construire.
Une application doit être trouvée dans un magasin, installée, autorisée, puis conservée sur un écran d’accueil que son propriétaire nettoie régulièrement. C’est beaucoup de friction à surmonter. Cela vaut le coup uniquement si l’application propose quelque chose qu’un site web ne peut pas offrir :
- Fonctionnement hors ligne — personnel de terrain, livreurs, zones avec un signal peu fiable
- Notifications push — des notifications réellement utiles, pas des messages marketing
- Matériel de l’appareil — flux de la caméra, périphériques Bluetooth, géolocalisation en arrière-plan
- Utilisation fréquente — quelque chose ouvert presque tous les jours, où gagner trois secondes fait la différence
Si aucun de ces critères ne s’applique, un site mobile rapide et bien conçu touchera plus de personnes pour moins cher. Nous le disons régulièrement à nos clients, et c’est généralement la chose la plus utile à dire lors d’un premier appel.
Ce qu’une application coûte réellement au Royaume-Uni
Les « calculateurs de coût d’application » publiés sont des outils marketing. Voici les fourchettes que nous utilisons pour nos devis, pour une agence britannique réalisant le travail correctement :
| Périmètre | Fourchette typique |
|---|---|
| Plateforme unique, jeu de fonctionnalités ciblé | £15 000 – £30 000 |
| Multiplateforme, iOS et Android | £22 000 – £45 000 |
| Avec paiements, données en temps réel ou synchronisation hors ligne | £35 000 – £70 000 |
| Maintenance annuelle | 15–20 % du coût de développement |
Cette dernière ligne est celle que la plupart des budgets omettent, et elle n’est pas optionnelle. iOS et Android publient chaque année une nouvelle version majeure. Google relève annuellement ses exigences en matière d’API cible et retire les applications qui ne suivent pas. Une application sans budget de maintenance a une durée de vie opérationnelle d’environ deux ans.
Tout devis inférieur à environ £8 000 est soit un modèle générique, soit un prix fixe qui sera renégocié une fois les difficultés apparentes.
Natif ou multiplateforme
C’est la décision qui influence le plus le coût, il est donc important d’en être clair sur les compromis plutôt que de la traiter comme une question de préférence.
Multiplateforme (Flutter, React Native) signifie une seule base de code produisant les deux applications. Vous économisez environ 30 à 40 % sur le développement et bien plus sur le long terme, car il n’y a qu’un seul ensemble de fonctionnalités à synchroniser au lieu de deux. Pour la grande majorité des applications professionnelles — réservation, commande, tableaux de bord, outils internes — l’utilisateur ne s’en rend même pas compte.
Native (Swift, Kotlin) implique deux bases de code et deux expertises spécifiques à chaque plateforme. C’est la bonne solution lorsque l’application repose fortement sur l’appareil : traitement continu de la caméra, suivi de localisation en arrière-plan, ARKit, ou animations si complexes qu’une couche de rendu intermédiaire devient visible.
La question secondaire est celle de la maintenance. Si votre équipe écrit déjà en React, React Native leur permet de partager des compétences et une partie du code avec votre application web, ce qui compense souvent l’avantage technique de Flutter. Si vous n’avez aucune capacité mobile en interne, Flutter est alors le choix technique le plus sûr. Dans tous les cas, le marché de l’emploi dans lequel vous recruterez compte davantage que les benchmarks.
Où les budgets disparaissent discrètement
Cinq éléments expliquent la plupart des dépassements de budget que nous observons sur les projets qui nous sont confiés.
1. Le comportement hors ligne traité comme une fonctionnalité secondaire
« Il faut que ça fonctionne hors ligne » semble être une simple fonctionnalité. C’est une architecture. Ajouter un stockage local et une résolution de conflits à une application conçue autour d’appels API en temps réel revient presque à une refonte complète. Décidez-en dès la première semaine.
2. Les notifications push ajoutées en fin de projet
Les notifications nécessitent une infrastructure serveur, des flux de permissions, une segmentation et des liens profonds ouvrant l’écran approprié. Ajoutées en fin de projet, elles se transforment en « envoyez le même message à tout le monde », ce qui incite les utilisateurs à les désactiver — perdant ainsi le levier de rétention pour lequel l’application a été conçue.
3. La révision en magasin non prévue
Les premières soumissions sur l’App Store sont souvent rejetées. Pas pour des raisons dramatiques : chaînes de caractères de confidentialité, conditions d’abonnement floues, absence de suppression de compte, présentation sur iPad pour une application universelle. Un planning sans marge pour une ou deux révisions est un planning qui déraillera publiquement.
4. Le backend considéré comme une réflexion après coup
La plupart des applications sont une interface pour un service. Si ce service n’existe pas, vous commandez deux projets. Lorsque le backend existe déjà, son API est souvent conçue pour un site web et nécessite une refonte pour le mobile — des points de terminaison plus verbeux, une pagination adaptée et des charges utiles optimisées pour une connexion mobile.
5. Tests sur un seul appareil phare
C’est surtout un problème sur Android, et un problème majeur. Une application performante sur un appareil phare récent peut être inutilisable sur un smartphone milieu de gamme, que beaucoup d’utilisateurs britanniques possèdent. Ajoutez à cela les gestionnaires de batterie des fabricants qui tuent les processus en arrière-plan, et « les notifications ne fonctionnent plus » devient votre ticket de support le plus fréquent.
Un calendrier réaliste
Pour une application professionnelle multiplateforme :
Cadrage et conception — 3 à 4 semaines. Liste des fonctionnalités, flux et conception de l’interface validés sur appareils réels.
Développement principal — 8 à 12 semaines en cycles de deux semaines, chacun se terminant par une version installable.
Bêta — 2 semaines avec des utilisateurs réels sur TestFlight et le test interne de Google Play.
Soumission en magasin — 1 à 3 semaines, incluant les allers-retours probables de révision.
Post-lancement — 30 jours de corrections, puis maintenance.
Environ quatre à cinq mois au total. Vouloir le compresser revient généralement à supprimer la phase bêta, qui est précisément celle qui permet de détecter les problèmes que vos utilisateurs rapporteraient autrement publiquement dans les avis en magasin.
Questions à poser à tout prestataire avant de signer
- Qui est propriétaire du code, et recevons-nous le dépôt ?
- Les comptes développeur sont-ils enregistrés à notre nom ou au vôtre ?
- Que se passe-t-il si Apple rejette la soumission — est-ce facturé ?
- Quel est le coût annuel de maintenance, par écrit ?
- Quels appareils spécifiques allez-vous tester ?
- Que devient l’application si nous arrêtons de travailler ensemble ?
Les réponses à ces six questions en disent plus long que tout portfolio. Si l’une d’elles suscite une hésitation, c’est votre réponse.
Prochaines étapes
Si vous hésitez entre une application et une autre solution, la première conversation utile ne portera pas sur les fonctionnalités — elle portera sur la pertinence de l’application pour résoudre votre problème. Nous sommes heureux d’avoir cette discussion et de vous dire si la réponse est un site web.
Questions fréquentes
Une application ciblée pour une seule plateforme coûte généralement entre £15 000 et £30 000. Une application multiplateforme couvrant à la fois iOS et Android se situe généralement entre £22 000 et £45 000, selon l’ampleur du travail backend nécessaire. Les applications incluant des paiements, des données en temps réel ou une synchronisation hors ligne se situent dans la fourchette haute. Tout devis inférieur à £8 000 correspond généralement à un modèle avec votre logo.
De douze à vingt semaines entre la validation du périmètre et la première mise en ligne pour la plupart des applications professionnelles, plus une à trois semaines pour la révision par le store. La variable la plus importante n'est pas la vitesse de développement, mais la rapidité avec laquelle les décisions et le contenu sont fournis par le client.
Une solution multiplateforme avec Flutter ou React Native convient à la plupart des applications professionnelles et permet d'économiser environ 30 à 40 % par rapport à un développement double. Le natif est justifié lorsque vous dépendez de fonctionnalités matérielles avancées comme le traitement avancé de l'appareil photo, la localisation en arrière-plan ou des animations complexes en continu.
Souvent, non. Si vos utilisateurs ne visitent votre service qu'une fois par mois, un site web mobile rapide répondra mieux à leurs besoins et coûtera bien moins cher — personne n'installe une application qu'il utilise occasionnellement. Une application se justifie lorsqu'elle nécessite un accès hors ligne, des notifications push, du matériel spécifique ou une utilisation réellement fréquente.
- développement d'applications
- mobile
- budgeting
- iOS
- Android