Coût maintenance application par an : comptez en jours, pas en %

Le coût de maintenance d'une application par an se situe entre 5 % et 25 % de son prix de construction selon les guides publiés en 2026, soit de 1 500 € à 7 500 € pour une application livrée à 30 000 €. La maintenance applicative est l'ensemble des interventions qui gardent une application en ligne, sécurisée et acceptée par les stores après sa mise en production. Un écart de 1 à 5 entre deux sources, ce n'est pas une fourchette, c'est un désaccord.

Je vois régulièrement des devis où la ligne maintenance est absente, ou réduite à un pourcentage jeté en bas de page. Mon avis : le pourcentage est un bon réflexe pour poser un ordre de grandeur, et un mauvais outil pour signer un budget.

Pour trancher, il faut d'abord comprendre pourquoi les chiffres divergent autant, puis ce que la maintenance couvre réellement, puis comment la convertir en jours, et enfin ce que coûte l'économie sur ce poste.

Quelle fourchette de maintenance prévoir par an, selon les sources ?

Les cinq guides français les mieux classés sur cette requête annoncent entre 5 % et 25 % du coût de développement initial par an, avec deux écoles : une autour de 5 à 8 %, l'autre autour de 15 à 25 %. Pour une application construite 60 000 €, cela donne de 3 000 € à 30 000 € par an. Aucun décideur ne peut budgéter sur une plage pareille.

Pourquoi les pourcentages divergent-ils autant ?

Parce que chaque auteur parle d'un périmètre différent. Selon playmoweb.com (octobre 2026), la règle est de prévoir 5 à 8 % par an pour une application mobile maintenue avec un contrat à crédit de temps. À l'opposé, bob-le-developpeur.com (mis à jour le 14 octobre 2026) retient 15 à 20 %, soit 9 000 à 12 000 € par an pour une application à 60 000 €. shortcut-agency.com (août 2026) et eid-lab.com (juillet 2026) annoncent 15 à 25 %.

Le premier chiffre couvre surtout la correction et les mises à jour obligatoires. Les seconds y ajoutent des évolutions fonctionnelles, ce qui explique l'essentiel de l'écart.

Un même taux appliqué à un code mal livré ou bien livré ne donne pas la même facture. C'est la limite du raisonnement en pourcentage : il traite le prix de construction comme un indicateur de charge, alors que la charge dépend de ce qui bouge autour de l'application.

Que paie-t-on vraiment dans une maintenance annuelle ?

La maintenance d'une application recouvre quatre natures de travail : corriger les bugs, adapter l'application aux changements extérieurs, la protéger, et la faire évoluer. Seule la dernière est un choix. Les trois autres sont imposées par des tiers : Apple, Google, les navigateurs et les éditeurs des briques logicielles que l'application emprunte (les dépendances).

Quelles échéances imposent des heures de travail ?

Les stores fixent le calendrier. D'après un fil de r/AppFollow relayé en 2026, r/AppFollow, Apple n'accepte depuis le 28 avril 2026 que des applications compilées avec Xcode 26 et le kit de développement iOS 26. Google Play refuse, depuis le 31 août 2026, les nouvelles applications et mises à jour qui ne ciblent pas Android 16 (niveau d'API 36).

Playmoweb rappelle qu'Apple a sorti iOS 27 le 14 septembre 2026 et Google Android 17 le 16 juin 2026 sur ses Pixel. Une application que personne ne touche pendant douze mois sort de ces règles, et personne ne vous prévient avant la note à une étoile.

Une application mobile coûte-t-elle plus cher à maintenir qu'une application web ?

Oui, parce que le calendrier est subi et que les mises à jour passent par une validation externe. Apple vise une revue de 90 % des soumissions en 48 heures d'après le même fil r/AppFollow, un délai à intégrer dans tout engagement de rétablissement.

Côté chiffres extrêmes, MobiLoud (vidéo de 2026) cite des marques qui mobilisent 2 à 3 personnes pour garder une application native vivante, et jusqu'à six pour certaines, soit environ 500 000 $ de salaires par an. Je n'en tire pas une règle : c'est le haut de la fourchette d'un grand e-commerce, pas la situation d'une PME. Mais cela montre que le pourcentage du devis initial ne plafonne rien.

Sur le web, le calendrier est moins serré, mais la sécurité reste le poste incompressible. D'après eid-lab.com, qui cite le rapport IBM Cost of a Data Breach 2024, une faille coûte en moyenne 4,88 millions de dollars. Une mise à jour de sécurité non appliquée n'est jamais une économie.

Pourquoi chiffrer en jours de développeur senior plutôt qu'en pourcentage ?

Chiffrer en jours consiste à réserver un volume annuel de journées de développeur, au TJM (tarif journalier moyen) convenu, plutôt qu'à appliquer un taux au devis. Le volume de jours est mesurable, vérifiable et ajustable. Le pourcentage ne l'est pas.

Transparence : je dirige Extra Dev, qui met à disposition des développeurs seniors augmentés par l'IA à 180 €/jour, donc j'ai un biais évident sur ce point. Reste que le calcul est le même chez n'importe quel prestataire : prenez son TJM et multipliez.

Combien de jours par mois faut-il prévoir ?

Voici mon estimation, pas une norme de marché. Pour une application stable qui ne reçoit pas de nouvelles fonctionnalités :

• 1,5 jour par mois (18 jours par an, 3 240 € à 180 €/jour) : surveillance, mises à jour de sécurité, une correction mineure.
• 3 jours par mois (36 jours par an, 6 480 €) : en plus, une adaptation par version majeure d'iOS ou Android et quelques ajustements demandés par les utilisateurs.
• 6 jours par mois (72 jours par an, 12 960 €) : application avec intégrations tierces nombreuses, paiement ou données sensibles, évolutions régulières.

Ces trois paliers recoupent la plage de bob-le-developpeur.com : 9 000 à 12 000 € par an, c'est 50 à 67 jours à 180 €. La différence, c'est que vous voyez ce que vous achetez.

Un développeur senior dédié, avec 8 ans d'expérience minimum, règle en une heure ce qu'un profil qui découvre le code met une journée à comprendre. C'est pour cela que je compte en jours de senior : le même ticket coûte moins cher au bon niveau, même si le TJM semble plus élevé.

Si vous hésitez entre recruter et déléguer ce volume, le calcul complet est dans Recruter un dev senior en CDI ou le prendre en régie à 180€/jour, et le calculateur du coût d'un développeur donne le chiffre sur votre cas.

Qu'est-ce qui fait grimper la maintenance d'une application ?

La maintenance explose quand le code est difficile à comprendre, pas quand l'application est grosse. La dette technique (le coût caché d'un code mal écrit, qui ralentit chaque évolution future) est le premier facteur de dérive, et elle se fabrique au moment de la construction, pas après.

La construction d'origine change-t-elle vraiment la facture annuelle ?

Oui, et c'est le point que les pourcentages ignorent. 8090 AI, éditeur d'outils de développement, avance dans une vidéo de 2026 que les équipes d'ingénierie passent environ 17,3 heures par semaine à maintenir l'existant contre 13,5 heures à créer des fonctionnalités, et que la maintenance absorberait de 50 à 80 % du temps. Il vend une solution, donc je prends ces ratios comme un ordre de grandeur, pas comme un constat neutre. Le sens, lui, est cohérent avec ce que je vois.

Ma conviction : une application construite proprement dès le départ coûte moins cher à garder en vie. Cela veut dire des journaux d'erreurs exploitables, des sauvegardes testées, un back-office, des tests réalisés dans un vrai navigateur et pas seulement du code généré, et une documentation de projet que le développeur suivant peut lire en une heure. Un code produit en quelques prompts sans cadre produit l'inverse, comme je l'explique dans Vibe coding : la dette technique qui va plomber votre budget.

Les pannes coûtent-elles plus que la maintenance préventive ?

Souvent. Selon la vidéo de Lusig pour PlatformCon 2026, 71 % des désinstallations d'applications mobiles sont déclenchées par un problème de performance ou un plantage. Le tri d'un bug majeur consomme quatre heures ou plus d'un développeur senior, et chaque interruption lui fait perdre une vingtaine de minutes de concentration.

Je note que Lusig vend de l'observabilité mobile, mais le mécanisme est réel : un bug détecté par un utilisateur coûte plus que le même bug détecté par un journal.

Quand vaut-il mieux refondre que continuer à maintenir ?

Il vaut mieux refondre quand le coût annuel de maintenance dépasse environ un tiers du prix d'une refonte, parce que l'économie se récupère en trois à quatre ans. C'est un critère de décision, pas une loi, et il vient d'un cas chiffré publié par un acteur du secteur.

Comment savoir que la maintenance devient un piège ?

appmobilenormandie.fr donne l'exemple d'une application développée en 2019 pour 30 000 €, qui coûte désormais 10 000 € par an à maintenir à cause de technologies vieillissantes. Une refonte coûterait 35 000 €, amortie en trois à quatre ans. Le même site estime que le développement initial ne représente que 20 à 30 % du coût total sur la durée de vie.

Je retiens trois signaux concrets : chaque correction casse autre chose, plus personne ne sait ajouter une fonctionnalité sans une semaine d'analyse, et les mises à jour des stores prennent désormais plusieurs jours. Pour le chiffrage d'une refonte, voir Refonte d'une application métier : combien ça coûte vraiment en 2026 et, pour le coût initial, Combien coûte une application en 2026.

Un chiffre de cadrage vient de gartner.com : d'après eid-lab.com, qui cite une étude Gartner de 2024, les entreprises dépensent en moyenne 60 % de leur budget logiciel total en maintenance. Je ne l'ai pas vérifié à la source, donc je l'utilise comme tendance, pas comme preuve.

Comment vérifier un contrat de maintenance avant de signer ?

Un contrat de maintenance se juge sur trois engagements : le délai de prise en charge, le délai de rétablissement, et ce qui est inclus dans le forfait. Le fil r/AppFollow constate que seuls 2 prestataires sur 10 examinés publient un vrai accord de niveau de service (SLA, l'engagement écrit de délais).

Que faut-il exiger noir sur blanc ?

Un délai de réponse promet seulement qu'on accuse réception du ticket. Il ne dit rien du moment où l'application refonctionne : demandez un objectif de rétablissement, et vérifiez que la couverture dépasse les heures de bureau si votre activité tourne le soir.

Demandez aussi ce qui se passe quand les crédits de temps sont épuisés, qui possède le code et les accès, et si vous pouvez ralentir ou reprendre en interne. Une régie avec un développeur dédié, sans engagement, règle la plupart de ces points par construction. Le rituel de pilotage est détaillé dans Piloter un dev en régie à distance.

Mon verdict : réservez des jours, pas un pourcentage

Prévoyez entre 18 et 72 jours de développeur senior par an, soit de 3 240 € à 12 960 € à 180 €/jour, selon la vie de votre application. Le pourcentage du devis sert à vérifier que vous n'êtes pas hors de l'ordre de grandeur, jamais à signer.

Quel critère décide entre les trois paliers ?

Le critère est le nombre de choses qui bougent autour de votre application. Sans évolution et sans intégration critique, restez à 1,5 jour par mois. Avec des mises à jour d'OS à absorber et des utilisateurs actifs, prévoyez 3 jours. Si l'application porte des paiements, des données sensibles ou des évolutions mensuelles, comptez 6 jours.

Et si la facture dépasse un tiers du prix d'une refonte, arrêtez de maintenir et refaites. Pour mesurer votre propre cas, le calculateur du coût d'un développeur vous donne le chiffre en trois minutes. Pour le détail des budgets de construction, lisez Combien coûte le développement d'une application ?.