Coût De Maintenance Logicielle : Ce Que Personne Ne Prévoit

Le coût de maintenance logicielle est le chiffre qui transforme un projet réussi en conversation difficile dix-huit mois plus tard. La construction avait été budgétée, validée et livrée. Ce qui se passe après la mise en production a été qualifié de « support » et doté d’un montant que quelqu’un a estimé au jugé, et ce montant était presque toujours trop faible.

La raison est structurelle plutôt que négligente. Une construction a un périmètre que l’on peut chiffrer. La maintenance n’a pas de périmètre, parce qu’elle est définie par des choses qui ne se sont pas encore produites : une bibliothèque qui révèle une faille, un fournisseur qui modifie une API, un utilisateur qui tombe sur un cas que personne n’avait prévu.

La règle empirique que tout le monde cite, 15 à 20 pour cent du coût de construction par an, est assez juste pour être dangereuse. Elle tombe juste assez souvent pour rassurer et se trompe dans une direction prévisible : elle sous-estime la première année, celle où les défauts remontent, et elle s’effondre complètement pour les systèmes soumis à des obligations réglementaires ou reliés à de nombreux services tiers, où le travail est déclenché par des événements extérieurs et non par votre propre base de code.

Ce que le coût de maintenance logicielle recouvre réellement

Cinq catégories distinctes, et c’est en les mélangeant que l’on obtient le mauvais chiffre.

Le correctif. Réparer les défauts. Cette charge arrive tôt, parce que la plupart des anomalies apparaissent durant les premiers mois d’usage réel, et c’est la catégorie que la règle du pourcentage traite le mieux.

L’adaptatif. Suivre ce qui échappe à votre contrôle. Une dépendance publie un correctif de sécurité. Un prestataire de paiement abandonne une version d’API. Un navigateur change de comportement. Rien de tout cela n’ajoute une fonctionnalité et tout cela est obligatoire.

Le préventif. Mettre à niveau avant d’y être contraint. Y renoncer ne supprime pas la dépense, cela la reporte et la fait grossir, et c’est ainsi qu’une montée de version de routine devient un chantier de trois mois.

L’exploitation. Hébergement, supervision, sauvegardes, certificats, et le temps humain nécessaire pour les surveiller. Souvent comptabilisée à part, ce qui ne pose aucun problème tant que quelqu’un la comptabilise.

Les petites évolutions. Le flux continu d’ajustements qu’un système en production génère dès que de vrais utilisateurs s’en servent. Insignifiantes prises une à une, et pourtant la catégorie la plus lourde la plupart des années.

Seule la première correspond à ce que les gens appellent habituellement la maintenance. Les quatre autres expliquent pourquoi le budget s’épuise.

Pourquoi la règle du pourcentage induit en erreur

Elle s’ancre sur la mauvaise grandeur. L’effort de maintenance suit le nombre de pièces mobiles et le rythme auquel le monde extérieur les modifie, pas le prix que la construction a coûté.

Deux systèmes construits pour la même somme peuvent différer d’un facteur trois. Une application autonome avec deux dépendances et sans exposition réglementaire coûte peu à maintenir en état de marche. Un système qui intègre six services tiers, traite des données personnelles et relève de règles sectorielles, non, car chacune de ces intégrations est une source de travail que vous ne programmez pas.

Le pourcentage suppose en outre un régime stable qui n’existe pas la première année. L’usage réel révèle les défauts, et les six premiers mois après le lancement se situent en général nettement au-dessus de la moyenne annuelle avant que les choses ne se calment.

Une meilleure estimation part des pièces mobiles. Comptez les intégrations, les obligations de conformité et le nombre d’utilisateurs susceptibles de contacter le support, puis chiffrez le temps que tout cela consomme réellement. Notre guide du coût du développement logiciel sur mesure traite le versant construction de la même arithmétique.

Les postes que les équipes oublient

Les mises à jour de dépendances. Elles ne sont pas facultatives, car les bibliothèques non corrigées sont la porte d’entrée des compromissions, et la charge est réellement imprévisible puisqu’elle dépend de ce que font les mainteneurs en amont.

Les changements d’API tierces. Un fournisseur abandonne une version et vous impose une échéance. Vous n’avez pas choisi le calendrier et vous ne pouvez pas le refuser.

Le renouvellement des certificats et des noms de domaine. Sans importance, jusqu’au jour où l’un d’eux expire un week-end et où le site tombe.

La supervision et la réponse qu’elle exige. Les alertes ne servent à rien sans quelqu’un pour réagir, et cette disponibilité est une dépense réelle, que quelque chose casse ou non.

Le transfert de connaissances. Les gens partent. Ce que coûte l’apprentissage du système par la personne suivante est un coût de maintenance, et il est proportionnel à tout ce qui n’a pas été écrit.

La croissance des données. Le stockage coûte plus cher, des requêtes autrefois rapides ralentissent, et le travail qui en découle arrive selon un calendrier fixé par votre propre succès. Notre guide sur la performance des bases de données montre à quoi cela ressemble en pratique.

Ce que cela coûte au Royaume-Uni

Fourchettes annuelles approximatives pour la maintenance d’un système sur mesure, en supposant un prestataire externe plutôt qu’une équipe interne.

Ces montants excluent l’hébergement et les licences, facturés séparément et extrêmement variables. Ils supposent aussi que le système est dans un état raisonnable. Maintenir quelque chose que personne n’a documenté, sans tests et avec une seule personne qui le comprend, coûte davantage et porte un risque qu’aucun contrat de maintenance ne supprime.

Comment structurer la relation

Un forfait avec un volume d’heures défini fonctionne quand la charge est globalement prévisible. Il achète de la disponibilité, ce qui représente l’essentiel de ce que vous payez, et les heures non consommées ne sont pas perdues puisque l’alternative consiste à n’avoir personne.

La régie convient aux systèmes qui bougent peu, mais le délai de réponse devient celui que permettent les autres engagements du prestataire, et c’est le compromis que vous acceptez.

Un contrat de support à prix fixe transfère le risque au prestataire, qui l’intègre à son tarif. Raisonnable pour les systèmes critiques, quand la prévisibilité vaut plus cher que la marge.

Quel que soit votre choix, convenez de ce qui relève de la maintenance et de ce qui relève d’une nouvelle fonctionnalité avant d’en avoir besoin. Cette frontière est à l’origine de presque tous les litiges dans les relations de support, et la définir au départ ne coûte rien.

Mecanik maintient des systèmes que nous n’avons pas construits comme ceux que nous avons livrés, dans le cadre de notre activité de développement logiciel . Le premier mois d’une reprise sert presque toujours à documenter, parce que c’est cela qui détermine le coût de chaque mois suivant.

À lire aussi : Contrat au forfait ou en régie ? , Rédiger un cahier des charges logiciel qui obtient des devis utiles , Séquestre de code source : qui en a vraiment besoin et Développement de MVP : périmètre, coût et calendrier .

Questions fréquentes

Combien coûte la maintenance logicielle par an ? La règle empirique courante annonce 15 à 20 pour cent du coût de construction par an, mais elle sous-estime la première année, celle où les défauts remontent, et elle ne tient plus du tout pour les systèmes comportant de nombreuses intégrations ou des obligations réglementaires. Les fourchettes britanniques approximatives vont de £6 000 à £15 000 pour un petit outil interne, jusqu’à £60 000 ou plus pour une plateforme réglementée ou à fort trafic, hébergement exclu.

Que comprend réellement la maintenance logicielle ? Cinq catégories : le correctif qui répare les défauts, l’adaptatif qui suit les dépendances et les changements d’API tierces, le préventif qui met à niveau avant d’y être contraint, l’exploitation avec l’hébergement et la supervision, et le flux continu de petites évolutions qu’un système en production génère. Seule la première correspond à ce que la plupart des gens appellent maintenance.

Pourquoi la règle du pourcentage du coût de construction est-elle peu fiable ? Elle s’ancre sur la mauvaise grandeur. L’effort de maintenance suit le nombre de pièces mobiles et la vitesse à laquelle le monde extérieur les modifie, pas le prix de la construction. Deux systèmes construits pour la même somme peuvent différer d’un facteur trois selon le nombre d’intégrations, l’exposition réglementaire et le volume de support.

Quels coûts de maintenance les équipes oublient-elles de budgéter ? Les mises à jour de dépendances, les API tierces abandonnées avec des échéances que vous n’avez pas choisies, le renouvellement des certificats et des domaines, la disponibilité humaine derrière les alertes de supervision, le transfert de connaissances quand les gens partent, et l’effet de la croissance des données sur le coût de stockage et la vitesse des requêtes.

Vaut-il mieux un forfait ou payer à la demande ? Un forfait avec un volume d’heures défini convient à une charge prévisible et achète de la disponibilité, ce qui représente l’essentiel de ce que vous payez. La régie convient aux systèmes qui bougent peu, mais le délai de réponse dépend des autres engagements du prestataire. Quel que soit votre choix, définissez ce qui relève de la maintenance et ce qui relève d’une nouvelle fonctionnalité avant d’en avoir besoin.