Budget de maintenance d’un logiciel métier : comment le calculer ?

Pour construire le budget annuel de maintenance d’un logiciel métier, ne partez pas d’un pourcentage du coût initial. Partez de ce que le système doit continuer à faire, des risques qu’il ne peut pas accepter et de la capacité nécessaire pour le maintenir exploitable.

La formule utile est la suivante :

Budget de maintenance = socle récurrent + risques prioritaires + exploitation variable + évolutions nécessaires + réserve contrôlée.

Cette approche évite deux erreurs opposées : sous-financer silencieusement le système jusqu’à l’incident, ou conserver une enveloppe historique dont personne ne sait expliquer l’usage.

Définir ce qui relève réellement de la maintenance

Une application peut ne recevoir aucune nouvelle fonctionnalité et demander pourtant du travail. Ses bibliothèques vieillissent, ses certificats expirent, ses interfaces externes changent, ses données grossissent et ses utilisateurs rencontrent de nouveaux cas limites. Le fonctionnement apparent ne signifie pas que le coût futur est nul.

Pour budgéter correctement, séparez au moins cinq natures de travail :

• Maintien en condition opérationnelle : surveillance, sauvegardes, restaurations, incidents, capacité, renouvellement des certificats et continuité de service.
• Maintien en condition de sécurité : correctifs, mises à jour, analyse des vulnérabilités, gestion des accès et traitement des composants en fin de support.
• Support et qualité des données : assistance, erreurs de saisie, imports, doublons, reprises et contrôle des échanges avec les autres outils.
• Compatibilité : évolution des API partenaires, navigateurs, systèmes, formats, règles d’authentification et dépendances techniques.
• Évolutions nécessaires : adaptations imposées par l’activité, la réglementation ou un changement de processus. Une idée nouvelle sans nécessité démontrée reste un investissement produit, pas une dépense de maintien.

Cette séparation est importante pour la décision. Une correction qui protège l’intégrité des données n’entre pas en concurrence avec un nouvel écran sur les mêmes critères. Elle réduit un risque de perte ou d’indisponibilité ; l’écran cherche à créer un bénéfice supplémentaire.

Construire l’inventaire des obligations

Avant de demander une estimation, décrivez le système exploité. La recommandation peut sembler élémentaire, mais elle change la qualité du budget : l’ANSSI demande de tenir à jour l’inventaire des systèmes et applications, de suivre les mises à jour et les dates de fin de support, et d’identifier les ressources nécessaires à la migration des logiciels en fin de vie. Son guide d’hygiène informatique inclut explicitement les ressources humaines, matérielles et budgétaires.

Pour chaque logiciel métier, consignez :

• les fonctions indispensables et leurs propriétaires métier ;
• les utilisateurs, profils d’accès et périodes de forte activité ;
• les bases de données, fichiers, API et traitements planifiés ;
• les fournisseurs, composants et versions supportées ;
• les engagements de disponibilité, de délai de reprise et de conservation ;
• les incidents des douze derniers mois et leurs causes ;
• les changements externes déjà annoncés ;
• les travaux différés et la raison de leur report.

Une ligne d’inventaire doit avoir un propriétaire et une date de prochaine revue. Sans cela, elle devient une photographie qui vieillit au même rythme que le logiciel.

Répartir le budget en cinq enveloppes

1. Le socle récurrent

Il finance les gestes prévisibles : surveillance, sauvegardes, test de restauration, mises à jour ordinaires, support, petites corrections et revues d’accès. Le NIST présente la gestion des correctifs comme une forme de maintenance préventive et comme un coût normal de l’activité, pas comme une opération exceptionnelle à négocier après chaque alerte. Son guide de planification des correctifs insiste sur l’identification, la priorisation, l’installation et la vérification.

2. La sécurité et l’obsolescence prioritaires

Cette enveloppe traite les vulnérabilités selon le risque réel, les composants qui sortent du support et les migrations imposées. Le catalogue KEV de la CISA recense les vulnérabilités dont l’exploitation est avérée et recommande de l’utiliser comme entrée de la priorisation. Il ne remplace pas l’analyse du contexte, mais évite de classer toutes les alertes par un simple score théorique.

3. L’exploitation variable

Hébergement, stockage, trafic, observabilité, courriels transactionnels et services tiers évoluent avec l’usage. Ces coûts doivent être rattachés au produit ou à l’activité qui les provoque. Le référentiel FinOps décrit l’allocation comme une stratégie de responsabilité : comptes, projets, étiquettes et règles de partage servent à attribuer les coûts directs et communs. La capacité d’allocation FinOps permet de distinguer une hausse d’activité normale d’une dérive non expliquée.

4. Les évolutions nécessaires

Une modification devient nécessaire lorsqu’un processus métier, un fournisseur, un format de données ou une règle applicable change. Chaque évolution doit être reliée à une échéance, un risque évité ou un résultat attendu. Les demandes purement optionnelles peuvent rester dans un portefeuille produit séparé.

5. La réserve contrôlée

La réserve couvre ce qui est plausible mais non planifiable précisément : incident significatif, correctif urgent, défaillance d’une dépendance ou reprise de données. Elle n’est pas une caisse noire. Définissez les personnes autorisées à l’engager, les motifs admis et la règle de reconstitution après usage.

Calculer le budget étape par étape

1. Borner le service. Listez ce que l’application doit assurer pendant l’année : fonctions critiques, heures de service, volumes, intégrations, données et engagements de reprise.
2. Transformer l’inventaire en travaux. Pour chaque obligation, décrivez l’action, la fréquence, le responsable et la preuve attendue. « Sauvegarder » devient par exemple « contrôler chaque jour le résultat et réaliser un test de restauration trimestriel ».
3. Estimer la capacité. Évaluez les jours internes, les forfaits fournisseurs et les coûts d’infrastructure. Conservez les unités séparées : une journée de développement, un abonnement et un téraoctet stocké ne se pilotent pas de la même façon.
4. Prioriser par conséquence. Notez l’impact d’une indisponibilité, d’une corruption, d’une fuite, d’une erreur de calcul ou d’un retard. Ajoutez la probabilité et la capacité de détection. Un défaut peu probable mais invisible peut mériter plus d’attention qu’un incident fréquent et immédiatement réversible.
5. Constituer les cinq enveloppes. Affectez chaque ligne au socle, à la sécurité/obsolescence, à l’exploitation variable, aux évolutions nécessaires ou à la réserve. Une ligne sans enveloppe ni propriétaire n’est pas budgétée.
6. Arbitrer à capacité finie. Protégez d’abord les obligations non reportables. Classez ensuite les évolutions par valeur, urgence et réversibilité. Documentez explicitement ce qui est repoussé et le risque accepté.
7. Convertir en euros. Appliquez aux jours les coûts complets internes ou les tarifs contractuels réellement applicables, puis ajoutez les dépenses externes. Ne mélangez pas une estimation de charge avec un prix commercial supposé.
8. Réviser chaque trimestre. Comparez consommé, prévu, incidents, dette et changements annoncés. Le budget annuel donne une direction ; la revue trimestrielle protège la décision.

Si vous devez encore estimer le coût total de possession avant cette répartition, notre dossier sur le coût réel d’un logiciel métier fournit une méthode sur trois ans. Pour qualifier les travaux différés, complétez-la par une lecture du coût de la dette technique.

Exemple fictif : chiffrer sans faux tarif de marché

L’exemple suivant est fictif. Il illustre la méthode ; il ne représente ni un tarif de marché ni une expérience client de Forge Labs.

Une PME exploite une application de gestion utilisée par 120 personnes, reliée à six services externes. L’équipe prépare le budget avec des unités de capacité avant de les convertir en euros :

Enveloppe	Hypothèses de travail	Capacité annuelle
Socle récurrent	Surveillance, support, sauvegardes, restaurations, mises à jour ordinaires	36 jours
Sécurité et obsolescence	Deux dépendances à migrer, correctifs prioritaires, revue des accès	22 jours
Exploitation variable	Hébergement, stockage, observabilité et services tiers	Contrats et consommation mesurée
Évolutions nécessaires	Nouvelle version d’une API partenaire et adaptation d’un contrôle métier	40 jours
Réserve contrôlée	Incident ou changement externe imprévu, avec validation du responsable	12 jours

Le budget de capacité représente donc 110 jours, auxquels s’ajoutent les dépenses variables. L’entreprise applique ensuite ses coûts complets internes et ses tarifs contractuels. Si l’enveloppe disponible ne couvre que 90 jours, elle ne réduit pas chaque ligne au même pourcentage. Elle protège le socle et les travaux de sécurité, revoit les évolutions nécessaires, puis documente les 20 jours reportés avec leurs conséquences.

Cette méthode produit une conversation plus utile que « combien dépense-t-on en maintenance ? ». La question devient : « quelles obligations finançons-nous, quels risques acceptons-nous et quelle capacité de changement conservons-nous ? »

Ce qu’il ne faut pas reporter

Le report est une décision possible, mais certains signaux doivent passer avant les améliorations de confort :

• une vulnérabilité connue comme exploitée et applicable au système ;
• un composant ou un système qui ne reçoit plus de correctifs ;
• une sauvegarde sans test de restauration concluant ;
• un défaut qui menace l’intégrité, la confidentialité ou la traçabilité des données ;
• une intégration critique dont la date de rupture est annoncée ;
• un incident récurrent sans diagnostic ni dispositif de reprise ;
• un accès privilégié sans propriétaire ou sans revue.

À l’inverse, une préférence d’interface, un rapport rarement consulté ou une automatisation à faible fréquence peuvent attendre si le coût du report est explicite. L’objectif n’est pas d’éliminer tout risque : il est d’empêcher qu’un arbitrage implicite devienne une surprise coûteuse.

Réviser le budget avec des indicateurs utiles

Un tableau de bord de maintenance doit déclencher une décision, pas accumuler des chiffres. Suivez peu d’indicateurs, mais reliez chacun à une action :

• délai de traitement des correctifs prioritaires : faut-il augmenter la capacité ou réduire le périmètre ?
• nombre de composants hors support ou proches de leur fin de support : faut-il financer une migration ?
• incidents par cause et temps de reprise : le socle préventif est-il suffisant ?
• résultat du dernier test de restauration : la continuité est-elle démontrée ?
• âge des travaux différés à risque : un report temporaire devient-il permanent ?
• écart des coûts variables : provient-il de l’usage, d’une anomalie ou d’une mauvaise allocation ?
• part de capacité absorbée par les urgences : la réserve est-elle réaliste ou le système manque-t-il de prévention ?

Pour les automatisations qui composent le logiciel métier, le budget gagne aussi à suivre le résultat produit, les erreurs silencieuses et la charge de reprise. Notre méthode pour mesurer la fiabilité d’une automatisation complète ce pilotage.

À la fin de chaque trimestre, prenez trois décisions explicites : ce qui entre dans le socle, ce qui sort parce qu’il n’apporte plus de valeur et ce qui doit devenir un projet séparé. Un budget de maintenance bien construit ne fige pas le logiciel. Il rend visible le prix de sa continuité et protège sa capacité à évoluer.

Sources et références

• ANSSI — Guide d’hygiène informatique, notamment l’inventaire, le suivi des mises à jour et l’anticipation des fins de support.
• MonServiceSécurisé / ANSSI — Référentiel de mesures, mesures relatives aux correctifs et aux versions maintenues.
• NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning, publié en avril 2022.
• CISA — Known Exploited Vulnerabilities Catalog, catalogue vivant à utiliser dans la priorisation des vulnérabilités.
• FinOps Foundation — Allocation capability, principes d’attribution et de partage des coûts technologiques.