Combien coûte la maintenance d'un logiciel ou d'une application ?

Pourquoi aucun pourcentage de maintenance n'est fiable ?

La règle souvent répétée d'un pourcentage annuel du prix de développement ne repose sur aucune mesure publique. La Fabrique du Net, qui publie des baromètres de prix à partir de budgets d'agences, l'écrit sans détour sur sa page consacrée aux applications mobiles : « Nous ne donnons pas de pourcentage de maintenance ». Son baromètre des sites internet ajoute que la maintenance confiée à un prestataire « se chiffre au devis ».

Un pourcentage fixe aurait d'ailleurs peu de sens. Prenons deux logiciels construits pour le même montant. Le premier sert trois personnes au bureau et n'échange avec aucun autre outil. Le second équipe soixante techniciens sur téléphone, fonctionne hors ligne, envoie des rapports aux clients et se synchronise avec la comptabilité. À coût de construction égal, le second demandera chaque année bien plus de surveillance, de mises à jour et de support.

Que faut-il budgéter pour maintenir un logiciel ?

Un budget de maintenance se lit poste par poste. Le tableau indique, pour chacun, ce qui le rend léger ou lourd.

Pour une application mobile, La Fabrique du Net conseille de prévoir chaque année les correctifs, la compatibilité avec les nouvelles versions d'iOS et d'Android et les petites évolutions, et rappelle que le compte Apple Developer se renouvelle chaque année. Les natures de maintenance sont définies dans le guide TMA et maintenance applicative.

Pourquoi les mises à jour de sécurité ne peuvent pas attendre ?

Parce que chaque composant d'un logiciel a une date de fin de support, après laquelle les failles découvertes ne sont plus corrigées. Node.js, environnement d'exécution utilisé par de nombreuses applications web, en donne un exemple documenté. Le site officiel du projet indique qu'une version arrivée en fin de vie ne reçoit plus aucune mise à jour, correctifs de sécurité compris, et range parmi les risques le fait que de nombreux audits interdisent les environnements non maintenus.

• Selon la page des versions de Node.js, une version LTS (support à long terme) garantit en général la correction des bogues critiques pendant 30 mois au total.
• La même page recommande de n'utiliser en production que des versions en support actif ou en maintenance.
• Node.js 20, publiée en avril 2023, figure désormais parmi les versions en fin de vie.

Concrètement, une application web mise en service en 2023 et restée sur cette version tourne en 2026 sur un socle qui ne reçoit plus de correctifs. Passer à une version récente demande des tests, que le logiciel évolue ou non : c'est la part incompressible d'un budget de maintenance. Le même raisonnement vaut pour les bibliothèques, la base de données et le système du serveur.

Forfait annuel ou intervention à la demande ?

Le forfait annuel achète de la disponibilité et de la régularité ; l'intervention à la demande achète du temps, seulement quand un besoin apparaît. Le choix dépend de ce que coûte une journée d'arrêt du logiciel.

Quand le logiciel est stratégique, recruter un développeur est une autre option, avec ses propres coûts et le risque de dépendre d'une seule personne : le comparatif maintenance externalisée ou développeur interne pose le calcul. Les formules et les tarifs d'abonnement de YMHB Web (hébergement, maintenance de site et d'application) figurent sur la page abonnements.

Que doit prévoir un contrat de maintenance ?

Un contrat de maintenance protège surtout par ses définitions, écrites avant le premier incident.

1. Le périmètre : applications, environnements, types de maintenance couverts, et ce qui en est exclu.
2. Les niveaux de gravité, illustrés d'exemples : bloquant, majeur, mineur.
3. Les délais de prise en charge et de rétablissement pour chaque niveau, avec les horaires couverts. C'est l'objet du SLA, l'engagement de niveau de service.
4. La frontière avec les évolutions : comment une demande est qualifiée, chiffrée puis validée.
5. L'hébergement et les sauvegardes : qui les opère, à quelle fréquence, et comment une restauration est testée.
6. La réversibilité : code source, accès, documentation et données restent au nom du client, et la passation à un autre prestataire est organisée. La notion est définie à l'entrée réversibilité du glossaire.
7. Le compte rendu périodique : incidents, mises à jour passées, composants qui approchent de leur fin de support.
8. La durée, la révision du prix et la résiliation.

Comment réduire le coût de maintenance sans fragiliser le logiciel ?

On réduit durablement le coût de maintenance en rendant chaque intervention plus courte et plus sûre, pas en espaçant les mises à jour.

• Mettre à jour souvent, par petits pas. Monter d'une version régulièrement coûte moins cher qu'un rattrapage de plusieurs années d'un seul coup.
• Tester automatiquement les parcours critiques : une mise à jour vérifiée par des tests se déploie sans mobiliser les utilisateurs.
• Limiter les dépendances : chaque bibliothèque ou service tiers ajouté est une source de mises à jour et de pannes futures.
• Surveiller avant que les utilisateurs n'appellent : alertes sur les erreurs, l'espace disque, les envois qui échouent.
• Regrouper les évolutions en lots arbitrés, plutôt que de traiter chaque demande dès qu'elle arrive.
• Documenter l'architecture et le déploiement, pour qu'un nouvel intervenant ne commence pas par des jours d'exploration.

Si le logiciel accumule déjà les composants en fin de support, un état des lieux s'impose avant de signer un forfait : la page combien coûte un audit de code en décrit le contenu.

Comment YMHB Web établit un contrat de maintenance

Pour un site ou une application courante, YMHB Web publie des formules de maintenance à prix mensuel fixe, sans engagement. Pour un logiciel métier, le contenu dépend du logiciel, de ses utilisateurs et de ses liaisons avec d'autres outils. Pour une application construite par YMHB Web, le périmètre est connu dès la mise en service ; le contrat écrit ce qui est couvert, les délais d'intervention par niveau de gravité, et la façon dont une évolution est chiffrée à part puis validée.

Pour un logiciel développé par un autre prestataire, tout commence par un état des lieux : code, versions des composants, accès, documentation, sauvegardes. Il arrive que cet état des lieux conclue qu'une remise à niveau est nécessaire avant toute maintenance régulière. Dans tous les cas, le code, les comptes d'hébergement et les accès restent au nom du client, ce qui lui permet de changer de prestataire sans repartir de zéro.