Combien coûte la maintenance d’un logiciel sur mesure après sa livraison?

Une heure de maintenance peut sembler facile à reporter. Les opérations pressent, le logiciel fonctionne encore et la dépense ne produit aucune nouvelle fonctionnalité visible.

C’est exactement la décision à laquelle un de nos clients a déjà été confronté. DevActif avait détecté une vulnérabilité critique dans une dépendance de son logiciel. Nous avions recommandé d’appliquer immédiatement le correctif, une intervention estimée à environ une heure au tarif normal. Le client a préféré attendre.

Le correctif aurait demandé une heure. Il a été reporté. Six mois plus tard, la vulnérabilité a été exploitée et la récupération a demandé près de 40 heures.

L’analyse technique a confirmé que cette vulnérabilité constituait le vecteur d’entrée. Ce cas ne signifie pas que chaque mise à jour reportée mène à une intrusion. Il montre plutôt pourquoi la maintenance d’un logiciel sur mesure doit être planifiée avant qu’une urgence décide du calendrier à votre place.

Un logiciel ne cesse pas d’évoluer après sa livraison

La livraison marque le début de l’utilisation réelle, pas la fin de la vie technique du logiciel. Même si l’entreprise ne demande aucune modification, le monde autour de l’application continue de changer.

De nouvelles vulnérabilités sont découvertes. PHP, .NET, Node.js et les autres environnements publient de nouvelles versions. Les frameworks et librairies vieillissent, puis cessent d’être soutenus. Les systèmes d’exploitation atteignent leur fin de vie. Les API de fournisseurs changent leurs règles ou leurs formats.

Les navigateurs, téléphones et tablettes évoluent aussi. Des certificats expirent. Des clés et autres secrets techniques doivent être renouvelés. Les sauvegardes peuvent échouer silencieusement si personne ne vérifie qu’elles sont encore restaurables. Les attentes en sécurité et les exigences de conformité progressent.

Autrement dit, un logiciel vieillit même lorsque son propre code ne change pas. L’entretien logiciel en entreprise consiste à absorber ces changements graduellement, pendant qu’ils sont encore simples à comprendre et à tester.

Attendre plusieurs années concentre plutôt le risque. Une suite de petites mises à niveau prévisibles devient alors un projet majeur où plusieurs versions, dépendances et comportements doivent changer en même temps. Plus l’écart est grand, plus les tests et les possibilités d’incompatibilité augmentent.

Les trois types de maintenance

Un budget utile distingue trois catégories de travaux. Elles répondent à des besoins différents et ne devraient pas être confondues dans un seul bloc imprécis.

1. La maintenance préventive

La maintenance préventive vise à réduire la probabilité d’un problème. Elle comprend les mises à jour de sécurité, la surveillance des vulnérabilités, la mise à niveau des dépendances et les tests qui confirment que l’application fonctionne toujours après ces changements.

Elle couvre également la vérification des sauvegardes, des certificats, des secrets, de la supervision et des procédures de déploiement. Comme pour l’entretien d’un équipement, sa valeur vient précisément des pannes et incidents qui ne se produisent pas.

2. La maintenance corrective

La maintenance corrective intervient lorsqu’un problème est déjà visible : bogue, erreur, panne, ralentissement ou incident. Elle cherche à rétablir le comportement attendu, à comprendre la cause et à éviter une récidive lorsque c’est possible.

Un logiciel stable peut nécessiter peu de correctifs pendant une année. Il faut tout de même conserver une capacité d’intervention, puisque le coût d’un problème dépend souvent de la rapidité avec laquelle l’équipe peut le diagnostiquer.

3. La maintenance évolutive

La maintenance évolutive ajoute une fonctionnalité, améliore un parcours ou adapte l’application à un nouveau processus. Un rapport supplémentaire, une intégration avec un nouveau fournisseur et une étape ajoutée au flux d’approbation entrent dans cette catégorie.

Ces travaux créent de la valeur, mais ils ne remplacent pas l’entretien technique. Ajouter des fonctions à une base vieillissante sans mettre ses fondations à niveau ne fait que repousser le problème.

Ce qui devrait être vérifié chaque année

Le contenu exact d’un plan varie selon l’architecture, mais une revue annuelle devrait normalement couvrir au moins les points suivants :

• les vulnérabilités connues dans le code, les frameworks et les dépendances;
• les versions soutenues des langages, systèmes d’exploitation et bases de données;
• les mises à jour de sécurité disponibles et leur niveau de priorité;
• le fonctionnement des sauvegardes et un véritable essai de restauration;
• la date d’expiration des certificats, clés, jetons et secrets techniques;
• les comptes administratifs, permissions et accès qui ne sont plus requis;
• le bon fonctionnement des déploiements et la capacité de revenir à une version stable;
• les journaux, alertes et mécanismes de surveillance;
• la compatibilité avec les navigateurs, appareils et API externes utilisés;
• les tests essentiels qui protègent les parcours critiques.

Cette liste ne doit pas attendre le mois de décembre. Les éléments urgents, particulièrement une vulnérabilité critique, doivent être traités selon leur risque. La revue annuelle sert plutôt à garantir qu’aucune catégorie n’est oubliée et à préparer le prochain cycle budgétaire.

Combien d’heures prévoir annuellement?

Pour un petit logiciel interne relativement simple et stable, DevActif recommande généralement de prévoir au minimum de 20 à 30 heures de maintenance technique par année.

Cet ordre de grandeur vient de notre expérience. Ce n’est ni une garantie ni une règle universelle. Il représente quelques interventions planifiées, une revue technique, l’application de mises à jour raisonnables et un peu de capacité pour les correctifs imprévus.

Les 20 à 30 heures ne comprennent généralement pas les nouvelles fonctionnalités. Elles visent d’abord la santé technique de l’application. Une demande qui change le processus, ajoute un écran ou crée une nouvelle intégration relève plutôt de la maintenance évolutive et doit être estimée séparément.

Il est aussi utile de distinguer le budget de maintenance informatique du budget d’hébergement, de licences et de soutien aux utilisateurs. Ces postes peuvent être liés, mais ils ne financent pas le même travail. Un forfait d’hébergement ne signifie pas nécessairement que quelqu’un met régulièrement le code et ses dépendances à jour.

Pour situer l’entretien dans le coût total du produit, consultez aussi notre guide sur le prix d’un logiciel sur mesure au Québec.

Les facteurs qui augmentent le budget de maintenance

Le minimum de 20 à 30 heures peut être insuffisant lorsque l’exposition ou les conséquences d’une panne sont plus importantes. Le budget devrait notamment augmenter pour :

• une application accessible publiquement sur Internet;
• un système qui contient des données sensibles;
• un logiciel utilisé quotidiennement par plusieurs employés;
• une application reliée à plusieurs API, équipements ou systèmes externes;
• un produit encore en développement actif;
• un système critique pour la production, les ventes ou le service;
• une application construite avec des technologies vieillissantes;
• un environnement soumis à des exigences particulières de sécurité ou de conformité.

Deux applications de taille semblable peuvent donc avoir des budgets très différents. Un outil interne consulté une fois par mois ne présente pas le même risque qu’un portail public qui traite des opérations toute la journée.

La bonne estimation part de questions concrètes : combien de personnes dépendent du logiciel? Combien coûte une heure d’arrêt? Quelles données sont présentes? Combien de fournisseurs externes peuvent changer? À quelle vitesse l’entreprise doit-elle pouvoir intervenir?

Pourquoi reporter une mise à jour peut coûter cher

Dans le cas présenté au début, l’intervention préventive d’environ une heure est devenue près de 40 heures de travail. La récupération a compris l’analyse de l’intrusion, la reconstruction d’un environnement propre, la restauration et la validation des données, puis l’application des correctifs.

Il a aussi fallu remplacer les secrets et les accès, réinitialiser les mots de passe, gérer l’incident de confidentialité, remettre le système en production et surveiller le nouvel environnement. Ces catégories expliquent l’ampleur du travail sans révéler de détails qui pourraient identifier le client ou son système.

Nous avons également publié une analyse plus technique de cette intervention, notamment de la reconstruction du serveur, de la restauration des données et du rôle de l’Infrastructure as Code. Voyez comment l’Infrastructure as Code a facilité la reconstruction du serveur.

Les heures facturées par une firme ne constituent qu’une partie du coût réel d’un incident. Une entreprise peut aussi subir une interruption de ses opérations, du temps perdu par ses employés, une baisse de productivité et des communications supplémentaires avec ses utilisateurs.

Selon la situation, elle peut devoir examiner les risques touchant des renseignements confidentiels, documenter ses décisions et remplir certaines obligations administratives ou réglementaires. Ces obligations varient selon les données touchées, le risque pour les personnes et les lois applicables. Une entreprise devrait obtenir les conseils appropriés à sa situation.

Il reste enfin des coûts moins faciles à chiffrer : l’atteinte à la confiance et l’incertitude sur l’intégrité du système. Tant que l’analyse n’est pas terminée, l’équipe ne sait pas toujours ce qui peut être remis en service ni quelles données peuvent être considérées comme fiables.

Comment structurer un plan de maintenance

Un bon plan n’a pas besoin d’être lourd. Il doit surtout rendre les responsabilités, les priorités et le budget explicites.

Tenir un inventaire minimal

Documentez le logiciel, son hébergement, ses principales dépendances, ses intégrations, ses propriétaires et les personnes qui possèdent les accès. Sans cette carte, chaque intervention commence par une recherche coûteuse.

Définir une fréquence

Prévoyez des vérifications régulières plutôt qu’une seule grande opération annuelle. Le rythme dépend du risque : une application publique exige généralement une surveillance plus fréquente qu’un petit outil isolé. Réservez aussi une revue plus complète pour les sauvegardes, les versions et la capacité de déploiement.

Classer les interventions par risque

Une vulnérabilité critique exposée ne devrait pas attendre la prochaine fenêtre ordinaire. Une mise à niveau sans effet immédiat peut être planifiée. Définissez à l’avance qui peut autoriser une intervention urgente et dans quel délai.

Réserver un budget distinct

Séparez l’entretien courant des améliorations. Vous pourrez ainsi protéger les mises à jour nécessaires sans les mettre en concurrence avec chaque nouvelle idée. Le suivi des heures par catégorie rendra aussi la prochaine estimation plus juste.

Tester les sauvegardes et les déploiements

Une sauvegarde qui existe sans avoir été restaurée reste une hypothèse. Une procédure de déploiement que personne n’a utilisée depuis deux ans aussi. Des essais périodiques réduisent le temps perdu au moment où l’entreprise en a le plus besoin.

Si votre logiciel repose sur une technologie ancienne ou n’a pas été entretenu depuis longtemps, une évaluation de reprise et de modernisation peut d’abord établir l’état réel du système. Pour un mandat plus large, notre service de développement de logiciels sur mesure couvre aussi l’évolution et la maintenance d’applications existantes.

Prévoir plutôt que rattraper

Le coût de maintenance d’un logiciel ne se résume pas à un pourcentage automatique du prix initial. Il dépend de son exposition, de sa complexité, de ses intégrations et de son importance pour les opérations.

Pour un petit système interne stable, un minimum annuel de 20 à 30 heures offre un point de départ raisonnable selon notre expérience. Le chiffre doit ensuite être ajusté au risque réel, et les nouvelles fonctionnalités doivent demeurer dans un budget distinct.

DevActif peut évaluer l’état de vos dépendances, les versions de vos frameworks, vos sauvegardes, votre procédure de déploiement et votre budget annuel de maintenance. Nous pouvons aussi clarifier les risques d’un logiciel qui n’a pas été mis à jour depuis longtemps.

Parlez-nous de votre application. Nous vous proposerons une évaluation pragmatique, sans dramatisation, afin de prioriser les interventions qui comptent réellement.