Négocier un contrat de maintenance applicative

La maintenance est la partie du budget qu’on négocie le moins et qui dure le plus longtemps. Un contrat de développement court six à douze mois ; un contrat de maintenance peut durer dix ans.

Voici ce que je regarde quand on me demande de relire celui d’un confrère — et ce que nous mettons dans les nôtres.

Séparer le correctif de l’évolutif

C’est le point de loin le plus important, et le plus souvent négligé.

Le correctif, c’est réparer ce qui ne fonctionne pas comme prévu. L’évolutif, c’est ajouter ou modifier une fonctionnalité. Ce ne sont pas les mêmes engagements, ni la même urgence, ni la même façon de facturer.

Quand les deux partagent une enveloppe unique, il se produit toujours la même chose : les corrections passent en priorité — normal, elles bloquent des utilisateurs — et le budget est consommé avant d’avoir livré la moindre évolution. Au bout d’un an, le client a le sentiment d’avoir beaucoup payé sans que rien n’ait avancé.

Ce que je conseille : deux lignes budgétaires distinctes, et une règle écrite pour trancher les cas litigieux. Parce qu’il y en aura : « ça ne marche pas comme je pensais » n’est pas toujours une anomalie.

Les engagements de service

Trois niveaux de gravité suffisent, définis par leur effet métier et non par une appréciation technique.

Bloquant — l’application est inutilisable, ou une fonction critique est indisponible. Majeur — une fonction importante est dégradée, un contournement existe. Mineur — gêne sans impact sur l’activité.

Pour chacun : un délai de prise en compte — au bout de combien de temps quelqu’un s’en occupe — et un délai de rétablissement, avec les heures ouvrées de référence.

Le piège : un engagement de prise en compte sans engagement de rétablissement. « Nous accusons réception sous deux heures » n’apporte rien si la correction arrive trois semaines plus tard.

Et une clause à négocier : que se passe-t-il en cas de dépassement ? Sans conséquence prévue, un engagement n’en est pas un.

Un volume d’évolutions garanti

Une maintenance purement corrective condamne l’application à se figer. Or une application qui n’évolue plus perd sa valeur en deux ou trois ans.

Je recommande de contractualiser un volume : un nombre de jours d’évolution par trimestre, utilisable sur des demandes que vous priorisez. Cela garantit une capacité, et cela oblige les deux parties à un point régulier pour décider ce qu’on en fait.

À vérifier : ce volume est-il reportable d’un trimestre à l’autre ? Un volume perdu s’il n’est pas consommé pousse à dépenser pour dépenser.

Photo : domaine public (CC0).

Les trois formulations qui coûtent cher

« Support best effort. » Cela signifie : aucun engagement. C’est parfois acceptable sur une application secondaire, à condition de le savoir et de ne pas payer le prix d’un vrai engagement.

« Maintenance corrective incluse. » Incluse dans quoi, et jusqu’où ? Sans définition de ce qui constitue une anomalie, chaque demande devient une négociation.

« Hors périmètre : les évolutions de l’environnement technique. » Cette clause exclut les montées de version, les correctifs de sécurité des composants tiers, les changements d’API des services connectés. Ce sont précisément les travaux qui garantissent la pérennité de l’application — et ils reviendront en facturation exceptionnelle, généralement au pire moment.

Le pilotage

Un contrat de maintenance sans rendez-vous régulier s’endort. Chacun fait au mieux, personne ne regarde les tendances, et l’on se réveille lors d’un incident.

Je recommande un point trimestriel court, avec quatre chiffres : le nombre d’anomalies ouvertes et fermées, le respect des délais d’engagement, la consommation du budget d’évolution, et l’état des dépendances techniques.

Une heure par trimestre. C’est ce qui transforme un contrat subi en outil de pilotage — et cela permet de voir venir les sujets avant qu’ils ne deviennent des urgences.

Photo : domaine public (CC0).

Ce que doit couvrir le forfait, écrit noir sur blanc

Un forfait de maintenance dont le contenu n’est pas énuméré finit toujours en désaccord, parce que chacun a une idée différente de ce qui est « inclus ».

Quatre postes doivent y figurer explicitement.

Les mises à jour de sécurité des dépendances et du socle. C’est le poste le plus régulier et le plus invisible. S’il n’est pas au contrat, il n’est pas fait.

La surveillance et l’astreinte, avec les plages horaires exactes. « Heures ouvrées » se définit : lesquelles, quel fuseau, quels jours fériés.

La correction des anomalies, avec la définition de ce qu’est une anomalie — un écart au comportement documenté — par opposition à une évolution.

Les sauvegardes et leur test de restauration, avec une fréquence de test annoncée. Une sauvegarde jamais restaurée n’est pas une sauvegarde, et c’est le premier point que je vérifie sur un contrat existant.

Ce qui doit rester en dehors, et pourquoi c’est protecteur

Les évolutions fonctionnelles n’ont pas leur place dans le forfait, même quand cela semble pratique.

La raison n’est pas commerciale, elle est opérationnelle : si le même budget couvre les deux, l’urgent chasse l’important. Chaque demande d’évolution consomme des jours prévus pour la maintenance, et le travail de fond — les mises à jour, la surveillance, les tests de restauration — n’est jamais fait, parce que personne ne le réclame.

Deux lignes distinctes, deux discussions distinctes. C’est ce qui garantit que l’application reste saine pendant qu’elle évolue.

La réversibilité, encore

Elle vaut pour la maintenance autant que pour le développement, et elle est encore plus importante ici : un contrat de maintenance crée une dépendance qui se renforce avec le temps.

Ce qui doit être écrit : la documentation reste à jour et vous appartient, les accès sont partagés, et une période d’accompagnement d’un repreneur est prévue en fin de contrat.

La question à poser au moment de signer, pas trois ans plus tard : si nous décidons de changer de prestataire, combien de temps faut-il et que devons-nous fournir au suivant ? Un prestataire confiant y répond sans détour.