Maintenance applicative et support : ce qu’ils couvrent réellement

Ce sont deux choses différentes

La maintenance garde le logiciel en bonne santé : correctifs de sécurité, mises à jour des dépendances, correction des défauts, maintien en fonctionnement à mesure que les plateformes sur lesquelles il repose évoluent. Elle a lieu, que quelqu’un signale un problème ou non.

Le support, c’est ce qui se passe quand quelqu’un en signale un : tri, diagnostic, correctif ou solution de contournement, et information de la personne qui l’a signalé sur l’avancement. Il est réactif par définition.

Un contrat qui mentionne « support et maintenance » sans distinguer les deux, c’est là que les désaccords commencent. Pour une partie, cela veut dire « vous répondrez au téléphone », pour l’autre « nous appliquerons les mises à jour de sécurité ».

Ce qui est normalement inclus

Mises à jour de sécurité et des dépendances

Les bibliothèques et les plateformes publient des correctifs en permanence. Un logiciel qui n’est pas mis à jour ne reste pas figé – il devient moins sûr pendant qu’on n’y touche pas, et c’est ainsi que les systèmes glissent vers le logiciel hérité.

Supervision et alertes

Savoir que quelque chose ne va pas avant qu’un client vous le dise. Si personne ne surveille, ce sont vos utilisateurs qui assurent la supervision.

Correction des défauts

Ce qui devait fonctionner et ne fonctionne pas. À écrire noir sur blanc, car c’est la limite la plus souvent contestée.

Petites améliorations

Des changements trop modestes pour constituer des projets. Généralement plafonnées sous forme d’un volume d’heures par mois, ce qui est une façon raisonnable de les gérer.

Nouvelles fonctionnalités

Normalement non incluses. Si votre accord ne le précise pas, partez du principe que chaque partie pense que l’autre se trompe à ce sujet.

Le point que la plupart des accords ratent

L’accès et la propriété. Un logiciel ne peut être maintenu par quelqu’un d’autre que si le code source, l’infrastructure et les comptes vous appartiennent et sont documentés.

Si le code se trouve dans les dépôts du prestataire, que les serveurs sont sur le compte du prestataire et que la seule personne qui sait comment fonctionne le déploiement est celle qui l’a construit, alors vous n’avez pas un contrat de support. Vous avez une dépendance.

Mieux vaut régler cela avant le lancement, quand vous avez encore un levier de négociation, plutôt que lors d’une passation que vous n’aviez pas prévue. Le test est simple : si ce prestataire disparaissait demain, un ingénieur compétent pourrait-il reprendre le logiciel à partir de ce que vous détenez ? S’il faut un coup de téléphone pour connaître la réponse, c’est non.

Comment c’est généralement facturé

Aucune de ces formules n’est meilleure que les autres. La question est de savoir combien coûte à votre entreprise une heure d’interruption, et si ce chiffre justifie de payer pour une disponibilité dont vous ne vous servirez peut-être pas.

Un forfait mensuel d’heures

Un nombre d’heures fixe, utilisé pour tout ce qui doit être fait. Simple, prévisible, et la formule la plus courante pour les petits systèmes.

Un contrat avec délais d’intervention

Vous payez la disponibilité, avec des délais d’intervention convenus selon la gravité. Adapté quand une interruption coûte réellement de l’argent.

À la demande

Vous appelez quand quelque chose casse. La solution la moins chère, jusqu’à la semaine où vous avez besoin de quelqu’un et qu’il est pris sur un autre projet.

Comment savoir si le support fonctionne ?

Cherchez des éléments vérifiables, pas des paroles rassurantes :

Prise en charge et résolution par rapport aux objectifs convenus

Un court rapport mensuel indiquant chaque incident, quand il a été signalé et quand il a été traité.

Problèmes récurrents

Le même défaut signalé encore et encore signifie que la cause n’a pas été corrigée.

Incidents rouverts

Un nombre élevé laisse penser que les correctifs sont déclarés terminés trop tôt.

Mises à jour appliquées

Un historique daté des mises à jour de sécurité et des dépendances.

Si vous n’y avez pas accès, demandez-les. Un prestataire qui fait bien son travail sera généralement content de le montrer.

À quoi ressemble un incident bien géré ?

• Il est pris en compte rapidement, et on vous dit qui s’en occupe.
• Vous recevez des nouvelles à un intervalle convenu, même quand la nouvelle est que rien n’a changé.
• Le service est d’abord rétabli, par un correctif ou un contournement, puis la correction durable suit.
• Ensuite, vous recevez un court compte rendu écrit de ce qui s’est passé, pourquoi, et de ce qui empêchera que cela se reproduise.

Et la couverture en dehors des heures ouvrées ?

Décidez si votre logiciel en a besoin. Un outil utilisé uniquement pendant les heures de bureau peut s’en passer. Une boutique ou un système de réservation qui prend des commandes la nuit, peut-être pas. Demandez quels sont les horaires du prestataire, si une aide urgente est disponible en dehors, comment la joindre et si elle est facturée en plus. Ne le découvrez pas le soir même.

À convenir avant le lancement

Ce qui constitue une urgence, et en combien de temps quelqu’un y répond. Ce qui relève d’un défaut plutôt que d’une évolution. Qui détient les comptes et les identifiants. Où se trouve la documentation, et si sa mise à jour fait partie de la prestation.

Ce sont toutes des conversations faciles avant le lancement, et difficiles un vendredi à neuf heures du soir.