Sommaire6
Une application ne coûte pas seulement le jour où on la développe. Une fois en service, elle tourne sur des serveurs qu’on paie chaque mois, elle doit suivre les nouvelles règles d’Apple et de Google, et ses utilisateurs demandent des changements. Beaucoup de devis résument tout cela par un pourcentage annuel du prix de développement. Nous préférons le découper en lignes, parce que chacune a sa cause et son rythme.
En bref
Trois postes : l’exploitation (chaque mois), les mises à jour imposées (plusieurs fois par an), les évolutions (selon vos choix).
L’exploitation démarre bas et suit le nombre d’utilisateurs ; une offre sans sauvegarde ne convient pas à une application d’entreprise.
Apple et Google relèvent leurs exigences chaque année : une application qu’on ne met pas à jour finit par ne plus pouvoir publier de correctif.
De petites mises à jour fréquentes coûtent moins cher qu’un grand rattrapage tous les deux ans.
Le premier poste : faire tourner l’application
C’est la partie la plus prévisible. Elle comprend le serveur et la base de données, l’hébergement de l’interface web, l’envoi d’emails (codes de connexion, notifications) et les comptes développeur des stores.
Pour la base de données, prenons l’exemple de Supabase, le back-end sur lequel tourne Challenge Us, une application de défis de groupe que nous avons développée :
d’inactivité suffit à mettre en pause un projet de l’offre Free, qui n’inclut pas de sauvegarde automatique
par mois, le prix de départ de l’offre Pro, avec des sauvegardes quotidiennes gardées sept jours
de crédits de calcul inclus chaque mois dans l’offre Pro, de quoi couvrir une petite instance
Une application d’entreprise ne tourne pas sur une offre qui se met en pause et ne sauvegarde rien : comptez au moins le palier payant. Côté stores, Apple facture 99 $US par année d’adhésion d’après sa page d’inscription, et Google 25 $US une seule fois d’après l’aide de la Play Console. Le choix du back-end change ces lignes : nous comparons les options dans Supabase, Firebase ou serveur à soi.
Le deuxième poste : les mises à jour que vous ne choisissez pas
C’est le poste le plus souvent oublié. Apple, Google et les outils de développement avancent à leur rythme, et une application doit suivre pour rester publiable.
- 29 avril 2024
Apple exige que les applications envoyées sur App Store Connect soient construites avec Xcode 15.
- 28 avril 2026
Apple passe le minimum à Xcode 26 et aux SDK de la génération 26 (iOS 26, iPadOS 26).
- 31 août 2026
Google Play exige que les nouvelles applications et leurs mises à jour visent Android 16 (niveau d’API 36).
- 1er novembre 2026
Dernier délai de prolongation que Google permet de demander pour cette exigence.
Ces dates viennent de la page des exigences à venir d’Apple et de la page de Google sur le niveau d’API cible. Google y précise aussi le sort des applications qui ne suivent pas : une application existante qui vise Android 14 ou moins ne reste visible, pour les nouveaux utilisateurs, que sur les téléphones dont la version d’Android ne dépasse pas la sienne.
Les bibliothèques suivent le même mouvement. Expo, l’outil avec lequel nous construisons une seule application pour le web, l’iPhone et Android, publie trois nouvelles versions de son SDK chaque année. Suivre ces versions une à une est un travail régulier et prévisible ; en sauter plusieurs transforme la mise à jour suivante en chantier.
Attention
L’application qu’on ne touche plus
Une application qui marche n’a pas besoin d’évolutions, mais elle a besoin de ces mises à jour. Sans elles, le jour où il faut publier un correctif urgent, il faut d’abord rattraper un ou deux ans de retard sur les outils.
Le troisième poste : les évolutions
C’est le seul poste que vous pilotez entièrement. Les premiers utilisateurs demandent des changements, l’activité en fait naître d’autres. Ce budget se fixe selon le rythme que vous voulez, et il peut être nul certains trimestres.
Il gagne à être découpé en petites livraisons. Pour Challenge Us, chaque modification est vérifiée automatiquement et prévisualisée en ligne avant d’être publiée, avec un journal des nouveautés lisible dans l’application.
Sur le terrain
108 versions en cinq semaines pour Challenge Us
Entre la version 1.0 du 2 septembre 2026 et la 1.58.3 du 6 octobre 2026, Challenge Us a connu 108 versions. Ce rythme n’est possible que parce que chaque version est petite, vérifiée par des contrôles automatiques et publiable sans attendre la revue d’un store, sa version web étant servie directement.
Ce n’est pas un rythme à copier : c’est celui d’une application jeune. Mais le principe vaut pour toutes : beaucoup de petites livraisons vérifiées coûtent moins cher et cassent moins que quelques grosses.
Le poste qu’on oublie : la surveillance
Une application en service doit prévenir avant que ses utilisateurs ne le fassent. Chez Palmora Property, une agence immobilière que nous accompagnons, l’exploitation produit un rapport chaque matin (dont l’âge de la sauvegarde), un test de restauration chaque mois, et une alerte si une tâche ne s’est pas signalée depuis 30 heures ; le détail est dans l’étude de cas Palmora. Une sauvegarde qu’on n’a jamais restaurée ne protège de rien, comme le montre notre article sur ce qui casse dans les sauvegardes d’un serveur.
Comment fixer le budget de maintenance
- Lister l’exploitation ligne par ligne.
Base de données, hébergement, emails, comptes des stores, avec un ordre de grandeur pour votre nombre d’utilisateurs.
- Réserver les mises à jour imposées.
Un forfait régulier pour suivre Apple, Google et les bibliothèques, indépendant des évolutions.
- Fixer un rythme d’évolutions.
Mensuel, trimestriel ou à la demande, selon l’usage et vos priorités.
- Écrire qui fait quoi.
Qui surveille, en combien de temps une panne est prise en charge, qui détient les accès.
Ce découpage est la suite logique de ce qui fait varier le prix de développement d’une application. Une application web installable réduit une partie du poste « stores », puisque ses correctifs ne passent pas par une revue : c’est l’un des arguments de notre comparatif PWA ou application native.
Notre développement d’applications livre des mises à jour régulières, un journal des versions et la documentation pour faire tourner l’application, et le cadrage chiffre le coût d’exploitation pour votre usage.
Questions fréquentes
Combien coûte la maintenance d’une application par an ?
Il n’y a pas de pourcentage juste pour toutes les applications. Additionnez trois lignes : l’exploitation (base de données, hébergement, emails, comptes des stores), qui dépend du nombre d’utilisateurs ; un forfait de mises à jour imposées par Apple, Google et les bibliothèques ; et le budget d’évolutions que vous choisissez. Les deux premières sont incompressibles, la troisième dépend de vous.
Que se passe-t-il si on ne met jamais à jour son application ?
Elle peut continuer à fonctionner un temps, mais elle se dégrade sur deux fronts. Sur Google Play, une application qui ne vise pas un niveau d’API récent n’est plus proposée aux nouveaux utilisateurs des téléphones récents. Chez Apple, publier un correctif exige de reconstruire l’application avec des outils récents. Le jour où une correction urgente s’impose, il faut d’abord rattraper le retard.
La maintenance est-elle moins chère pour une application web installable ?
En partie. Ses correctifs arrivent aux utilisateurs dès leur mise en ligne, sans revue de store, et elle ne dépend pas des exigences annuelles d’Apple et de Google pour être publiée. Elle a en revanche les mêmes coûts d’exploitation (base de données, hébergement, emails) et les mêmes mises à jour de bibliothèques qu’une application native.
Peut-on reprendre la maintenance de son application en interne ?
Oui, si le code, la base de données, les comptes des stores et les accès à l’hébergement sont à votre nom, et si l’application est documentée. Vérifiez-le dès le contrat de développement. Il faudra aussi une personne qui connaît les outils utilisés, ou le temps de la former, pour suivre les mises à jour imposées.
Sources
- Apple Developer Program, page d’inscription (nouvel onglet)developer.apple.com
- Aide Play Console, frais d’inscription (nouvel onglet)support.google.com
- Apple Developer, exigences à venir (nouvel onglet)developer.apple.com
- Android Developers, exigences de niveau d’API cible (nouvel onglet)developer.android.com
- Documentation Expo, versions du SDK (nouvel onglet)docs.expo.dev
Android Developers, exigences de niveau d’API cible
Lire sur developer.android.com(nouvel onglet)Jim · fondateur de Brain Plus AI
À lire aussi en applications web et mobiles
Choisir et chiffrer7 min Le guide du sujet
Combien coûte une application : ce qui fait varier le prix
Une fourchette de prix ne dit rien de votre projet : ce qui fait varier le devis d'une application, ce sont quelques décisions précises, plus un coût d'exploitation mensuel à chiffrer à part. Voici lesquelles.
Choisir et chiffrer6 min
Back-end d'application : Supabase, Firebase ou serveur à soi
Derrière les écrans d'une application, il faut des comptes, une base de données, des fichiers et des règles. Supabase, Firebase et un serveur à soi y répondent de trois façons, et chacun engage des choses différentes.
Choisir et chiffrer6 min
PWA ou application native : que choisir en entreprise ?
Une application web installable (PWA) s'installe sur l'écran d'accueil sans passer par l'App Store ni Google Play, et suffit dans beaucoup de cas, pas dans tous. Voici comment trancher, et pourquoi nous démarrons par elle.