Qui maintient votre logiciel après la livraison ?

Le jour de la mise en production est le seul jour de la vie d’un logiciel où il est parfaitement à jour. Dès le lendemain, ses dépendances vieillissent, ses utilisateurs trouvent ses limites et son environnement bouge. La question n’est donc pas de savoir si votre logiciel aura besoin de maintenance, mais qui s’en chargera, dans quel cadre, et à quel prix. Voici de quoi répondre avant que la question ne se pose en urgence.

Pourquoi un logiciel livré n’est-il jamais terminé ?

Parce qu’un logiciel en production vit dans un environnement qui change en permanence, même quand son code ne bouge pas. Les navigateurs se mettent à jour toutes les quelques semaines, les systèmes d’exploitation chaque année, et les briques logicielles sur lesquelles repose votre application publient des correctifs en continu. Un logiciel figé dans cet environnement mouvant ne reste pas stable : il dérive.

L’ampleur du phénomène est documentée. L’étude de référence menée par Stripe auprès de plus de 1 000 développeurs et 1 000 dirigeants a mesuré que le développeur moyen consacre plus de 17 heures par semaine à la maintenance de code existant, débogage et remaniement compris (Stripe, Le coefficient développeur). La maintenance n’est pas l’exception du métier, elle en est la moitié. Un contrat de développement qui n’organise pas cette moitié laisse le sujet au hasard.

Il y a enfin la sécurité, le volet le plus ignoré et le plus dangereux. L’agence nationale de la sécurité des systèmes d’information place les mises à jour régulières parmi les mesures d’hygiène fondamentales de tout système d’information (guide d’hygiène informatique, ANSSI). Une dépendance non mise à jour, c’est une faille connue de tous, documentée publiquement, et toujours ouverte chez vous.

Que couvre exactement la maintenance d’un logiciel ?

Trois volets distincts, qui ne se budgètent pas pareil. La maintenance corrective traite les anomalies : un bug apparaît, quelqu’un le qualifie, le corrige et vérifie que la correction ne casse rien ailleurs. La maintenance évolutive fait grandir le logiciel : nouvelles fonctionnalités, adaptations aux changements du métier ou de la réglementation. Le maintien en conditions opérationnelles et de sécurité, enfin, est le volet invisible : mises à jour des dépendances, correctifs des frameworks, montées de version des briques critiques, surveillance des sauvegardes.

Le volet invisible se raconte mal en devis et se constate bien en exemple : sur un outil métier typique, une année de maintien en conditions représente une vingtaine de mises à jour de dépendances, deux ou trois montées de version de briques importantes, et une poignée d’alertes de sécurité à qualifier, dont une ou deux méritent un correctif le jour même. Aucune de ces interventions n’est visible des utilisateurs, et c’est exactement le but : le logiciel bien maintenu est celui dont on ne parle jamais.

La distinction compte parce que les contrats low cost ne couvrent généralement que le premier volet. Or c’est le troisième qui protège votre investissement dans la durée : un logiciel dont les bugs sont corrigés mais dont les fondations ne sont jamais mises à jour devient, en deux ou trois ans, impossible à faire évoluer sans chantier lourd. C’est exactement le mécanisme de la dette technique : elle grossit en silence, et se paie avec intérêts.

Qui peut maintenir votre logiciel ?

Quatre options existent, et le bon choix dépend surtout de qui possède la connaissance du code :

La tierce maintenance applicative (TMA) est un contrat par lequel un prestataire tiers prend en charge la maintenance corrective et évolutive d’une application, qu’il l’ait développée ou non, avec des engagements de délai et une connaissance du code entretenue dans la durée. C’est la formule pensée pour le cas le plus courant en PME : un logiciel critique, pas d’équipe technique interne, et un besoin qui ne justifie pas un salarié à temps plein. Le détail de notre offre est sur la page tierce maintenance applicative.

Combien coûte la maintenance d’un logiciel sur mesure ?

Pour un logiciel stable, sans roadmap d’évolutions, l’ordre de grandeur que nous constatons et pratiquons est de 8 à 12 % du coût de développement initial par an. Un outil métier développé pour 30 000 € HT se maintient donc autour de 2 400 à 3 600 € par an : mises à jour de sécurité, petites corrections, surveillance. Ce montant n’est pas une option de confort, c’est le coût d’assurance de l’investissement initial.

Dès qu’une roadmap d’évolutions s’ajoute, l’échelle change : comptez 1 000 à 5 000 € par mois selon le rythme, du simple maintien actif à l’évolution continue du produit. Chez Krafter, les interventions se facturent entre 700 et 1 100 € HT par jour selon la complexité, et le crédit temps (des blocs de 10 ou 20 heures utilisables sur 6 à 12 mois) offre un tarif préférentiel avec une priorité de traitement. Une correction isolée prend 1 à 2 heures, une évolution fonctionnelle 1 à 5 jours, une montée de version majeure 1 à 4 semaines.

Déroulons le cas classique. Une PME fait développer un outil de gestion pour 25 000 € HT, sans contrat de maintenance : « on verra si ça casse ». Dix-huit mois plus tard, rien n’a cassé, mais une mise à jour de l’ERP connecté change un format d’échange, et le flux s’arrête. Le prestataire d’origine répond en dix jours, l’intervention en urgence se négocie mal, et l’audit révèle dix-huit mois de mises à jour de sécurité jamais appliquées : trois jours de rattrapage avant même de traiter le problème. Le contrat de maintenance à 250 € par mois qu’elle avait refusé aurait couvert l’ensemble, correction comprise, sans interruption d’activité.

Comment bien choisir un contrat de maintenance ?

Cinq questions suffisent à séparer un contrat sérieux d’une ligne de facturation vide :

1. Vérifiez ce qui déclenche une intervention. Bugs seulement, ou aussi les mises à jour préventives ? Un contrat sans volet sécurité protège le prestataire, pas vous.
2. Exigez un délai de réaction chiffré pour les incidents critiques. « Dans les meilleurs délais » n’est pas un engagement. Chez nous : sous 48 heures dans la mesure du possible pour un bug critique en production, et cet engagement figure par écrit.
3. Demandez qui interviendra réellement. Une équipe qui connaît votre code, ou le premier profil disponible ? La valeur d’une maintenance tient dans la connaissance entretenue de votre application.
4. Contrôlez la propriété et les accès. Code, dépôt, hébergement, noms de domaine : tout doit être à votre nom, avec la liberté documentée de partir. Un contrat de maintenance ne doit jamais être une prise d’otage.
5. Regardez comment le prestataire maintient ses propres produits. C’est le test le plus fiable : quelqu’un qui n’opère rien en production vous vend une théorie.

Sur ce dernier point, notre réponse tient en une phrase : nos 5 produits maison, utilisés chaque jour par 25 000 personnes, vivent sous le même régime de maintenance que les logiciels de nos clients, mêmes outils, mêmes pratiques, même méthode.

Un dernier critère sépare les contrats qui vieillissent bien de ceux qui déçoivent : la transparence du compteur. Un crédit temps sérieux se consulte : ce qui a été consommé, sur quoi, avec quel reste. Une maintenance facturée au forfait flou finit toujours par une conversation désagréable où chacun a une version différente des heures passées. Exigez de voir le relevé d’interventions comme vous verriez un relevé bancaire : c’est votre budget, il doit être lisible.

Comment se passe la reprise d’un logiciel en maintenance ?

Par un audit d’entrée, jamais par une promesse : reprendre la maintenance d’un logiciel qu’on n’a pas développé impose de le comprendre avant de s’engager sur des délais. La reprise sérieuse suit quatre temps, sur deux à trois semaines au total.

L’inventaire d’abord : accès au dépôt de code, à l’hébergement, aux noms de domaine et aux services tiers, avec au passage la vérification de qui possède quoi. C’est l’étape qui révèle les surprises : un nom de domaine au nom de l’ancien prestataire, une base de données sur un compte personnel, des accès jamais révoqués. L’audit technique ensuite, quelques jours : stack, architecture, dette, état des dépendances, qualité des sauvegardes. Il produit une carte, pas un jugement : ce qui est sain, ce qui est fragile, ce qui est urgent. Le plan d’action troisième temps : les urgences de sécurité à traiter immédiatement (dépendances en retard, accès à assainir), puis le régime de croisière proposé, intervention ou crédit temps. La période d’observation enfin : les trois premiers mois d’une reprise servent autant à apprendre le logiciel qu’à le maintenir, et les délais d’intervention s’affinent à mesure que la connaissance s’installe.

Un signe distingue immédiatement un repreneur sérieux d’un vendeur de contrats : le sérieux commence par demander les accès en lecture avant de chiffrer quoi que ce soit. Personne ne peut s’engager honnêtement sur un code qu’il n’a pas ouvert.

Et si votre logiciel n’a plus personne pour le maintenir ?

C’est plus fréquent qu’on ne le croit, et ça se traite : un logiciel orphelin (prestataire disparu, freelance parti, agence fermée) se reprend par un audit technique de quelques jours, qui aboutit à une décision honnête entre reprise et reconstruction. Si le code est sain, une TMA classique prend le relais après l’audit. S’il est trop dégradé, le reconstruire coûte parfois moins cher que s’acharner à le maintenir : nous avons détaillé cet arbitrage, critères à l’appui, dans que faire d’un logiciel sans développeur.

Le meilleur moment pour organiser la maintenance reste cependant le jour du devis initial, pas le jour de la panne. Un projet chiffré sans son coût de vie n’est chiffré qu’à moitié : nous avons posé les chiffres complets dans combien coûte vraiment un SaaS pour une PME, et le principe vaut pour tout logiciel métier.

Si votre application tourne aujourd’hui sans filet, le premier pas ne coûte rien : 30 minutes en visio avec un fondateur, l’accès au dépôt de code si vous l’avez, et vous repartez avec un état des lieux honnête de ce qui doit être surveillé, mis à jour ou repris. Parlons-en avant que le sujet ne se rappelle à vous.