À retenir
- Comptez 15 à 20 % du coût de développement initial par an, hors nouvelles fonctionnalités.
- Deux mises à jour majeures d’OS par an imposent du travail, même sans changement fonctionnel.
- Les certificats et comptes développeur expirent : leur oubli rend l’application indisponible.
- Une application sans maintenance devient généralement non publiable en 18 à 24 mois.
- Reprendre une application abandonnée coûte 40 à 70 % d’une réécriture.
C’est la ligne budgétaire que personne ne prévoit et qui rattrape tout le monde. L’application est lancée, l’équipe passe à autre chose, et quinze mois plus tard elle ne compile plus, ne passe plus la validation des magasins, et personne ne sait par où reprendre.
Une application mobile n’est pas un livrable : c’est un service qui vit dans un environnement qui change deux fois par an sans vous demander votre avis.
Ce qui change sans que vous fassiez rien
Les systèmes d’exploitation. Apple et Google publient chacun une version majeure par an, plus des versions intermédiaires. Chacune apporte son lot d’adaptations : nouvelles règles de permissions, changements d’interface système, comportements de fond modifiés, API dépréciées.
Les règles de publication. Version minimale du kit de développement imposée, nouvelles déclarations de confidentialité, exigences d’accessibilité. Une application conforme en 2024 ne l’est plus mécaniquement en 2026.
Les dépendances. Vos bibliothèques tierces publient des correctifs de sécurité et des versions majeures. Rester en arrière est confortable pendant un an, puis chaque montée de version devient un chantier parce qu’elles s’enchaînent.
Les certificats et les comptes. Certificats de signature, clés de notifications push, comptes développeur, abonnements aux services tiers. Ils expirent. Un certificat oublié, et l’application ne peut plus être mise à jour — parfois plus être installée.
L’incident le plus fréquent, et le plus évitable : l’expiration d’un compte développeur ou d’un certificat. Aucune ligne de code n’est en cause, l’application est retirée ou bloquée, et la remise en service peut prendre plusieurs jours. Mettez ces échéances dans un agenda partagé, pas dans la boîte mail d’une seule personne.
Ce que couvre réellement un budget de maintenance
| Poste | Part indicative | Contenu |
|---|---|---|
| Compatibilité OS | 25 – 35 % | Adaptation aux versions majeures d’iOS et Android |
| Dépendances et sécurité | 20 – 25 % | Montées de version, correctifs de sécurité |
| Correction d’anomalies | 20 – 30 % | Plantages, régressions, cas non prévus |
| Surveillance | 10 – 15 % | Suivi des plantages, des performances, des erreurs serveur |
| Infrastructure | 10 – 20 % | Hébergement, sauvegardes, certificats, comptes |
Notez ce qui n’y figure pas : les nouvelles fonctionnalités. Elles se budgètent à part. Un contrat de maintenance qui prétend inclure les évolutions cache soit une réserve de jours très limitée, soit un malentendu qui se révélera au premier trimestre.
Le calcul qui convainc les directions financières
Prenons une application développée pour 90 000 €.
Avec maintenance : environ 15 000 € par an. Au bout de trois ans, vous avez dépensé 45 000 € et vous disposez d’une application à jour, publiable, dont l’équipe connaît le code.
Sans maintenance : 0 € pendant trois ans, puis une reprise. Remise en état de la chaîne de compilation, trois ans de montées de version enchaînées, adaptation aux règles actuelles des magasins, correction de ce qui s’est cassé au passage. Coût constaté : 50 à 65 % d’une réécriture, soit 45 000 à 60 000 € — pour retrouver exactement la même application, trois ans plus tard, sans aucune amélioration.
L’économie apparente était donc négative, et l’application aura été dégradée pendant toute la période.
Ce qu’il faut mettre en place dès le lancement
Ces quatre éléments coûtent quelques jours et divisent le coût de maintenance ensuite.
La surveillance des plantages. Un outil qui remonte automatiquement les erreurs, avec la version, l’appareil et le contexte. Sans lui, vous découvrez les problèmes par les avis sur les magasins, c’est-à-dire trop tard.
Un pipeline de livraison automatisé. Compiler et publier doit être une commande, pas un rituel de trois heures maîtrisé par une seule personne. C’est le sujet de notre article sur le CI/CD mobile.
Un agenda des échéances. Certificats, comptes, abonnements, avec un rappel deux mois avant, partagé entre au moins deux personnes.
Une documentation de démarrage. Comment installer l’environnement, compiler, publier. Une page suffit, et elle vaut plusieurs jours quand quelqu’un de nouveau reprend le projet.
Les trois formules qui existent sur le marché
Au fil de l’eau. Vous appelez quand quelque chose casse, vous payez à la journée. Adapté aux applications internes peu critiques ; imprévisible sur un produit exposé.
Forfait mensuel. Un budget fixe couvrant la maintenance corrective et évolutive légère, avec un engagement de délai de prise en charge. C’est la formule la plus répandue, et la plus lisible en gestion.
Réserve de jours. Un volume de jours acheté d’avance, consommé selon les besoins. Souple, mais demande un suivi pour éviter que tout soit consommé en évolutions et rien en maintenance réelle.
La question n’est jamais « faut-il maintenir l’application ». C’est « payons-nous la maintenance en continu, ou une reprise plus chère dans deux ans ». Il n’y a pas de troisième option où l’application reste utilisable sans que personne n’y touche.
Le signal d’alerte
Si vous ne savez pas répondre à ces trois questions, votre application est déjà en dette :
- Quand la dernière version a-t-elle été publiée ?
- Quand vos certificats expirent-ils ?
- Combien de plantages par jour vos utilisateurs subissent-ils ?
Si vous souhaitez un avis extérieur, nous réalisons un audit de reprise en quelques jours : état du code, dette technique, échéances à risque et coût de remise à niveau chiffré. C’est utile même quand la conclusion est que tout va bien.



