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’une seule ligne de code ne soit écrite : celle de la construire.
Une application doit être trouvée dans un magasin, installée, autorisée et ensuite conservée sur un écran d’accueil que son propriétaire nettoie périodiquement. C’est beaucoup de friction à surmonter. Cela vaut le coup lorsque l’application offre quelque chose qu’un site web ne peut pas fournir :
- Fonctionnalité hors ligne — pour les employés sur le terrain, les livreurs, ou partout où le signal est peu fiable
- Notifications push — celles qui sont réellement utiles, et non des diffusions marketing
- Accès au matériel du dispositif — pipelines de caméra, périphériques Bluetooth, localisation en arrière-plan
- Utilisation à haute fréquence — quelque chose ouvert la plupart des jours, où économiser trois secondes se cumule
Si aucun de ces éléments ne s’applique, un site web mobile rapide et bien construit atteindra plus de personnes pour moins d’argent. Nous le disons régulièrement à nos clients, et c’est généralement le conseil le plus utile lors d’un premier appel.
Coût réel d’une application au Royaume-Uni
Les « calculateurs de coût d’application » publiés sont des outils marketing. Voici les fourchettes que nous utilisons, pour une agence au Royaume-Uni réalisant le travail correctement :
| Portée | Fourchette typique |
|---|---|
| Plateforme unique, ensemble de fonctionnalités ciblées | £6,000 – £12,000 |
| Cross-platform, iOS et Android | £8,800 – £18,000 |
| Avec paiements, données en temps réel ou synchronisation hors ligne | £14,000 – £28,000 |
| Maintenance continue, par an | 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 chacun une version majeure par an. Google augmente annuellement ses exigences en matière d’API cible et retire les applications qui ne sont pas à jour. Une application sans budget de maintenance a une durée de vie opérationnelle d’environ deux ans.
Tout ce qui est proposé en dessous de £3,200 est soit un modèle générique préconçu, soit un prix fixe qui sera renégocié une fois que les parties complexes émergeront.
Application native ou cross-platform
C’est la décision qui influence le plus le coût, il est donc important d’être clair sur le compromis plutôt que de la traiter comme une question de goût.
Multiplateforme (Flutter, React Native) signifie un seul codebase produisant les deux applications. Vous économisez environ 30 à 40 % sur la construction et bien plus sur la durée, car il n’y a qu’un seul ensemble de fonctionnalités à synchroniser au lieu de deux. Pour la grande majorité des applications métiers — réservation, commande, tableaux de bord, outils internes — l’utilisateur ne fait pas la différence.
Natif (Swift, Kotlin) signifie deux codebases et deux ensembles d’expertise plateforme. C’est la bonne solution lorsque l’application repose fortement sur l’appareil : traitement prolongé de la caméra, suivi de localisation en arrière-plan, ARKit, ou animations assez complexes pour que la couche de rendu intermédiaire devienne visible.
La seconde question porte sur la maintenance. Si votre équipe maîtrise déjà React, React Native leur permet de partager leurs 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 le choix technique le plus sûr. Dans tous les cas, le marché de l’embauche dans lequel vous recruterez compte plus que les benchmarks.
Où les budgets disparaissent silencieusement
Cinq éléments expliquent la majorité des dépassements que nous observons sur les projets qui nous parviennent d’ailleurs.
1. Le comportement hors ligne traité comme un cas marginal
« Il faut que ça marche hors ligne » sonne comme une fonctionnalité. C’est une architecture. Intégrer rétroactivement le stockage local et la résolution des conflits dans une application conçue autour d’appels API en temps réel revient presque à tout refaire. Décidez cela 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 correct. Ajoutées à la fin, elles deviennent « envoyer le même message à tout le monde », ce qui habitue les utilisateurs à les désactiver — perdant ainsi le levier de rétention pour lequel l’application a été conçue.
3. La soumission au store non planifiée
Les premières soumissions à Apple sont fréquemment rejetées. Pas pour des raisons dramatiques : chaînes de confidentialité, conditions d’abonnement peu claires, absence de suppression de compte, présentation sur iPad pour une application universelle. Un calendrier sans marge pour une ou deux rondes de révision est un calendrier qui glissera publiquement.
4. Le backend considéré comme une après-pensée
La plupart des applications sont une interface pour un service. Si ce service n’existe pas, vous commandez en réalité deux projets. Lorsque le backend existe déjà, son API est souvent conçue pour un site web et nécessite des ajustements pour le mobile — des endpoints plus interactifs, une pagination et des charges utiles adaptées à une connexion mobile.
5. Les tests réalisés sur un seul appareil phare
C’est surtout un problème sur Android, et un gros. Une application performante sur un appareil récent peut être inutilisable sur un smartphone milieu de gamme, que porte une part substantielle des utilisateurs britanniques. Ajoutez 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 courant.
Un calendrier réaliste
Pour une application métiers multiplateforme :
- Définition et design — 3 à 4 semaines. Liste des fonctionnalités, flux et design d’interface revus sur des appareils réels.
- Construction principale — 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 les tests internes Play.
- Soumission au store — 1 à 3 semaines, incluant les allers-retours probables avec les réviseurs.
- Post-lancement — 30 jours de corrections, puis maintenance.
Environ quatre à cinq mois. Comprimer ce calendrier signifie généralement supprimer la phase bêta, qui est exactement la partie qui révèle les problèmes que vos utilisateurs signaleraient autrement publiquement dans les avis du store.
Que demander à une agence avant de signer
- Qui possède le code, et obtenons-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 — cela est-il facturé ?
- Quel est le coût annuel de maintenance, par écrit ?
- Quels appareils spécifiques allez-vous tester ?
- Que devient l’application si nous cessons de collaborer ?
Les réponses à ces six questions en disent plus que tout portfolio. Si l’une d’elles suscite de l’hésitation, c’est votre réponse.
Étapes suivantes
Si vous hésitez sur une application, la première conversation utile ne porte pas sur les fonctionnalités — mais sur la forme adaptée au problème. Nous sommes ravis d’en discuter et de vous dire si la réponse est un site web.
Questions fréquentes
Une application mono-plateforme ciblée coûte généralement entre £6,000 et £12,000. Une application cross-platform couvrant à la fois iOS et Android se situe généralement entre £8,800 et £18,000, selon le volume de travail backend nécessaire. Les applications avec paiements, données en temps réel ou synchronisation hors ligne se situent dans la fourchette haute. Tout devis inférieur à £3,200 correspond généralement à un modèle préétabli 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