# Maintenance applicative et support : ce qu’ils couvrent réellement Le support et la maintenance figurent dans les contrats sur une seule ligne, puis chaque partie y met un sens différent. Voici ce que couvre réellement chacun, et ce qu’il faut régler avant d’en avoir besoin. - Page: https://www.cognivise.co.uk/fr/blog/maintenance-applicative-support - Original (anglais): https://www.cognivise.co.uk/blog/what-application-support-covers - Sujet: Faire vivre un logiciel - Publié: 2026-09-18 - Mis à jour: 2026-10-30 - Auteur: Cognivise ## 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é](https://www.cognivise.co.uk/blog/legacy-system-modernisation). - **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](https://www.cognivise.co.uk/fr/services/support-et-maintenance) 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. ## À lire aussi - [Support et maintenance applicatifs](https://www.cognivise.co.uk/fr/services/support-et-maintenance) - [Développement de logiciels sur mesure](https://www.cognivise.co.uk/fr/services/developpement-logiciel-sur-mesure) - [Planification et conseil technique](https://www.cognivise.co.uk/fr/services/conseil-technique) - [Modernisation des systèmes existants](https://www.cognivise.co.uk/blog/legacy-system-modernisation) - [Équipes dédiées](https://www.cognivise.co.uk/fr/services/equipe-de-developpement-dediee)