Prix de la maintenance d'un logiciel : quel budget annuel prévoir, poste par poste

Un logiciel métier coûte de l'argent chaque année après sa mise en production, même si personne ne lui demande rien de nouveau. Le chiffre qui circule partout, 15 à 20 % du coût de développement par an, n'est qu'une règle empirique sans méthode publiée. Le seul relevé détaillé que nous ayons trouvé, publié en 2026 sur 24 logiciels SaaS, situe la médiane entre 21 et 26 % par an, et 10 à 16 % pour un outil interne stable. Le bon réflexe n'est pas de choisir un pourcentage, mais de construire le budget poste par poste.

Cet article traite du coût et du budget annuel. Pour savoir ce que recouvre la maintenance et ce qu'un contrat doit préciser, lisez notre article sur la maintenance d'une application métier ; pour l'organisation d'une maintenance externalisée, celui sur la TMA.

Pourquoi « 15 à 20 % par an » ne suffit pas

La règle du pourcentage a un mérite : elle rappelle qu'un logiciel n'est pas payé une fois pour toutes. Elle a trois défauts.

• Elle part du mauvais chiffre. Deux logiciels développés pour le même prix n'ont pas le même coût d'entretien. Celui qui dépend de cinq API externes, traite des données de santé ou sert des clients la nuit coûte bien plus cher à maintenir qu'un outil interne utilisé par dix personnes aux heures de bureau.
• Elle mélange des postes qui n'ont rien à voir. L'hébergement est une dépense fixe ; les correctifs varient avec la qualité initiale ; les évolutions dépendent de vos demandes. Additionner les trois dans un pourcentage empêche de piloter.
• Elle n'a pas de source. Les pages qui la citent ne publient ni échantillon ni méthode.

Le relevé le plus détaillé que nous ayons trouvé est celui de l'agence allemande Wavect, publié le 10 juillet 2026 et révisé le 2 septembre 2026 : benchmark sur 24 produits SaaS de la zone DACH maintenus entre 2023 et mi-2026. L'auteur le qualifie lui-même d'indicatif, non représentatif statistiquement. Ses médianes annuelles, exprimées en pourcentage du coût de développement initial :

Le même relevé propose 18 à 30 % pour un produit SaaS qui évolue, et 10 à 16 % pour un outil interne stable et peu exposé. Retenez surtout l'ordre de grandeur et l'écart : du simple au triple selon le logiciel.

Les huit postes d'un budget de maintenance

Un budget utile se construit ligne par ligne. Voici les postes à prévoir, et ce qui fait gonfler chacun.

Deux remarques. D'abord, les évolutions ne sont pas de la maintenance au sens strict : elles ajoutent de la valeur au lieu de la préserver. Isolez-les dans le budget, sinon elles masquent la dérive des autres postes. Ensuite, l'hébergement figure souvent sur une autre facture que la maintenance, mais c'est la même enveloppe pour votre trésorerie. Nous détaillons les choix d'hébergement dans notre article sur l'hébergement en France.

Les montées de version, le poste qui grossit avec le temps

Un logiciel repose sur des briques qui ont chacune une durée de vie. Le langage PHP en donne un exemple public : selon la page officielle des versions supportées (consultée le 7 novembre 2026), chaque version reçoit deux ans de support actif puis deux ans de correctifs de sécurité seulement. La version 8.2, sortie en décembre 2022, ne reçoit plus aucun correctif de sécurité après le 31 décembre 2026.

Concrètement, une application qui n'a jamais été mise à jour doit franchir plusieurs versions d'un coup, avec les incompatibilités de chacune. Une montée de version faite chaque année coûte quelques jours ; trois années de retard peuvent coûter des semaines, voire une partie de réécriture. C'est la mécanique de la dette technique : elle ne figure sur aucune facture tant qu'on ne la rembourse pas.

Ce qui fait varier la facture

À coût de développement égal, six facteurs expliquent l'essentiel des écarts :

1. Le nombre d'intégrations. Chaque API externe (ERP, paiement, messagerie, administration) peut changer de version ou tomber en panne. C'est la première source de travail non prévu.
2. La criticité. Un outil dont l'arrêt bloque la facturation ou la production exige des délais d'intervention courts, parfois hors des heures de bureau. Les astreintes se paient.
3. La qualité initiale. Tests automatisés, documentation, code lisible : ce qui a été économisé au développement se repaie en maintenance.
4. La technologie. Une pile répandue se maintient plus facilement, et plus de prestataires savent la reprendre.
5. La réglementation. Facturation électronique, RGPD, données de santé : chaque règle nouvelle est un chantier d'adaptation. Notre article sur la facturation électronique en donne un exemple concret.
6. Le nombre d'utilisateurs. Il pèse moins sur le code que sur le support : plus d'utilisateurs, plus de questions.

Pour un éditeur qui vend son logiciel à d'autres entreprises, un facteur s'ajoute : le règlement européen sur la cyberrésilience impose des obligations de signalement à partir du 11 septembre 2026, et l'essentiel de ses obligations à partir du 11 décembre 2027, dont la gestion des vulnérabilités tout au long du cycle de vie du produit. Vérifiez avec un juriste si votre logiciel entre dans son champ.

Un exemple de calcul, étape par étape

Prenons une illustration, pas un devis : une application interne développée pour 60 000 euros, utilisée par une trentaine de personnes, reliée à un logiciel de comptabilité.

1. Appliquez la fourchette du profil. Outil interne stable : 10 à 16 % selon le relevé cité plus haut, soit 6 000 à 9 600 euros par an.
2. Vérifiez poste par poste. L'hébergement est-il inclus dans ce montant ? Une montée de version majeure est-elle prévue dans l'année ? Le connecteur comptable dépend-il d'une API qui change souvent ?
3. Ajoutez la première année à part. Elle coûte en général plus cher, le temps que l'usage réel révèle les cas oubliés.
4. Sortez les évolutions du calcul. Si vous savez déjà que trois nouveaux écrans seront demandés, chiffrez-les à part.

Le résultat n'est pas un chiffre unique, mais une fourchette argumentée que vous pouvez confronter aux devis.

Les façons de payer la maintenance

Le mode de facturation ne change pas le travail à faire, mais il change qui porte le risque d'un budget qui dérape.

Le paiement à la demande paraît économique tant que rien ne casse. Dès qu'un incident survient, vous négociez sous pression. Le détail des modèles de facturation d'une TMA est dans notre article dédié, et la logique générale du forfait face au temps passé dans forfait ou régie.

Ce que coûte de ne pas maintenir

Économiser la maintenance est tentant quand tout fonctionne. Les effets arrivent plus tard, et en bloc :

• une faille connue, publiée, reste ouverte sur un logiciel exposé sur Internet ;
• le langage ou le framework sort du support de sécurité, et l'hébergeur finit par ne plus proposer la version nécessaire ;
• un service relié change son API, et la synchronisation s'arrête un lundi matin ;
• plus personne ne connaît le code, et le premier prestataire consulté propose de tout réécrire.

À ce stade, la question n'est plus le coût annuel mais celui d'une remise à niveau ou d'une refonte. Notre article sur le prix d'une refonte de logiciel métier montre ce que cela représente.

Réduire le coût de maintenance dès la conception

Le budget de maintenance se décide en grande partie avant la première ligne de code :

• des tests automatisés sur les règles métier, pour qu'une montée de version ne casse rien sans que personne le voie ;
• peu de dépendances, et des dépendances répandues ;
• une pile technique standard, que d'autres prestataires savent reprendre ;
• une documentation tenue à jour : architecture, déploiement, comptes, procédures de restauration ;
• une supervision qui alerte avant que les utilisateurs appellent ;
• un périmètre de départ réduit : chaque écran développé est un écran à maintenir. Un écran inutile coûte deux fois.

C'est aussi pourquoi nous montrons un prototype avant d'engager un développement : un écran que personne n'utilisera, retiré à ce stade, ne coûte rien en maintenance pendant cinq ans.

Lire un devis de maintenance : la check-list

Avant de signer, vérifiez que le devis répond à chacune de ces questions :

1. L'hébergement est-il inclus ? Avec quelles sauvegardes, et quel test de restauration ?
2. Les montées de version du langage et du framework sont-elles comprises, ou facturées à part ?
3. Quels délais d'intervention selon la gravité, et sur quelles plages horaires ?
4. Quel volume d'évolutions est inclus, et à quel prix au-delà ?
5. Comment le support est-il joint, et qui répond ?
6. Que se passe-t-il à la fin du contrat : code, données, documentation ? Les droits sont définis au cas par cas dans le contrat ; lisez-les.
7. Comment le prix est-il révisé d'une année sur l'autre ?

Les erreurs fréquentes

• Budgéter le développement sans la suite. Un projet validé sur le seul prix de construction met l'entreprise en difficulté dès la deuxième année.
• Comparer des devis de périmètres différents. Un forfait bas qui exclut les montées de version n'est pas moins cher, il est incomplet.
• Mélanger évolutions et maintenance. Vous ne savez plus si le logiciel coûte cher à entretenir ou si vous demandez beaucoup.
• Couper la maintenance pour financer une évolution. Le logiciel vieillit pendant qu'on l'enrichit.
• Oublier le temps interne. Quelqu'un chez vous qualifie les demandes, teste les livraisons et répond aux utilisateurs. Ce temps a un coût.

Quand l'abonnement change le calcul

Une autre façon de poser la question consiste à ne plus distinguer développement et maintenance. Dans notre formule d'abonnement, vous ne payez pas le développement : un abonnement mensuel couvre l'hébergement, la maintenance et les évolutions. Le risque d'un entretien plus coûteux que prévu passe chez nous, et votre budget devient une ligne fixe.

Cette formule ne convient pas à tout le monde : sur une longue durée, un logiciel acheté et maintenu peut revenir moins cher. Nous comparons les deux logiques dans abonnement ou forfait, et les coûts de développement eux-mêmes dans le prix d'une application métier sur mesure.

Par où commencer

1. Listez vos dépendances : langage et version, framework, services externes, hébergement. Notez la date de fin de support de chacun.
2. Reprenez vos dépenses des douze derniers mois, rangées dans les huit postes ci-dessus.
3. Isolez les évolutions de la maintenance proprement dite.
4. Provisionnez la première année à part pour tout nouveau logiciel.

Si vous préparez un nouveau projet, le meilleur moment pour réduire la maintenance est avant le développement. Nous construisons un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés : vous voyez ce qui sera développé, donc ce qui sera maintenu, avant d'engager un budget. Le principe est expliqué dans voir son logiciel avant de le payer.