Un contrat de maintenance qui ne dit pas ce qu'il couvre ne couvre rien

Presque tous les contrats de maintenance que je lis vendent la même chose : un volume d’heures mensuel, reportable ou non, à un tarif préférentiel. Le document fait deux pages, il se signe vite, et il contient précisément zéro information sur ce qui se passera le jour où quelque chose casse. C’est un défaut de conception, pas un oubli : un contrat d’heures ne peut pas répondre à la question « est-ce couvert », parce qu’il ne parle pas de couverture. Il parle de décompte.

La conséquence apparaît au premier incident sérieux. Le client considère que la panne relève de la maintenance ; le prestataire considère qu’elle vient d’une évolution demandée six mois plus tôt et qu’elle sort du forfait. Les deux ont des arguments, aucun n’a de texte, et la relation se dégrade sur un désaccord qui aurait pu être tranché à la signature en une demi-page.

Les quatre clauses

Clause	Ce qu’elle doit dire	Ce qui arrive sans elle
Périmètre	Les familles couvertes, énumérées ; tout le reste sur devis	Chaque incident devient une négociation
Délai de prise en charge	Un délai par niveau de gravité, vérifiable	Le client appelle, personne ne sait sous combien de temps on répond
Seuil de devis séparé	Ce qui bascule en projet, et à partir de quand	Les évolutions grignotent le forfait, les correctifs passent après
Sortie	Restitution, documentation, période de transition	Une dépendance, donc un service qui n’a plus besoin d’être bon

Le périmètre : quatre familles, énumérées

La formulation qui fonctionne est une liste fermée, pas une intention générale du type « maintien en condition opérationnelle ».

Les correctifs : ce qui existait, fonctionnait, et ne fonctionne plus. C’est la seule famille où la responsabilité est évidente, et elle est couverte sans limite de temps passé.

Les mises à jour de sécurité et de dépendances : montées de version, correctifs publiés en amont, renouvellement des composants obsolètes. Cette famille est prévisible en volume et invisible pour le client, ce qui explique qu’elle soit la première sacrifiée quand elle n’est pas contractualisée.

La surveillance et la réponse aux incidents : ce qui est surveillé, ce qui déclenche une alerte, et ce qu’on fait quand elle sonne. Sans cette ligne, la maintenance est réactive et le client est le système de détection.

La veille de compatibilité : une plateforme change son API, un moyen de paiement retire une version, un navigateur modifie un comportement. Rien n’a été demandé, rien n’a été modifié côté site, et pourtant quelque chose casse. Cette famille est celle qu’on oublie le plus souvent et celle qui produit les incidents les plus déroutants pour le client.

Tout ce qui ajoute une capacité relève d’un devis distinct. La frontière n’est pas toujours nette, et c’est pourquoi elle doit être illustrée par des exemples dans le contrat plutôt que définie en abstrait.

Un contrat qui vend des heures fait porter au client la charge de prouver qu’un incident est couvert. Un contrat qui vend un périmètre fait porter au prestataire la charge de le tenir. Ce n’est pas la même relation.

Le délai : prise en charge, pas résolution

C’est la clause la plus souvent mal écrite, et l’erreur va toujours dans le même sens : on s’engage sur un délai de résolution.

C’est intenable et malhonnête. Avant d’avoir vu une panne, personne ne peut dire si elle se corrige en dix minutes ou si elle vient d’un service tiers sur lequel on n’a aucune prise. S’engager quand même conduit soit à ne pas tenir, soit à gonfler les délais pour se protéger — ce qui rend l’engagement inutile.

Le délai de prise en charge est vérifiable et suffit : en combien de temps quelqu’un regarde, qualifie, et informe. Il doit être gradué par gravité, parce que payer une astreinte permanente pour un bouton mal aligné n’a aucun sens :

• Bloquant — le tunnel de commande est inaccessible, le site est en panne : prise en charge sous une heure, y compris hors ouvrés si l’astreinte est souscrite.
• Majeur — une fonctionnalité importante est dégradée, la commande reste possible : sous 4 heures ouvrées.
• Mineur — défaut cosmétique ou fonctionnalité secondaire : sous 2 jours ouvrés.

Cette gradation a un effet secondaire utile : elle oblige à définir ce qui est bloquant, donc à s’accorder sur ce qui compte réellement dans le parcours.

Le budget de maintien, rendu visible

Une clause que je recommande d’ajouter, et qu’on ne voit presque jamais : réserver explicitement une part du forfait aux mises à jour de sécurité et de dépendances, non consommable par autre chose.

Sans cette réserve, le mécanisme est toujours le même. Le client a une demande urgente, le prestataire la traite dans le forfait, les montées de version attendent le mois suivant, puis celui d’après. Dix-huit mois plus tard, la boutique tourne sur des dépendances obsolètes, la mise à jour est devenue un chantier au lieu d’une routine, et personne n’a jamais pris la décision d’en arriver là.

C’est la même logique que celle qui gouverne un budget technique : ce qui n’a pas de ligne propre est consommé en silence par ce qui a une échéance¹.

La sortie, qui protège les deux parties

La dernière clause est celle qu’on hésite à demander parce qu’elle a l’air de préparer une rupture. Elle protège pourtant le prestataire autant que le client.

Trois éléments concrets. La restitution : accès, dépôts de code, comptes de service, sous un délai chiffré. La documentation d’architecture, tenue à jour pendant le contrat et non produite dans l’urgence au moment du départ. Une période de transition pendant laquelle le prestataire sortant répond aux questions du suivant, facturée si elle dépasse un volume convenu.

Un contrat sans clause de sortie crée une dépendance, et une dépendance dégrade le service — non par malveillance, mais parce qu’un fournisseur qu’on ne peut pas quitter n’a plus besoin d’être excellent. Pour un atelier qui vit de sa réputation, l’absence de cette clause est un mauvais calcul : elle attire les clients qui ne peuvent pas partir plutôt que ceux qui choisissent de rester.

Ce que ça change en pratique

Un contrat écrit de cette manière fait trois pages au lieu de deux, et il se négocie plus longtemps. Il produit en échange une chose rare dans cette relation : au premier incident, la conversation porte sur la panne, pas sur le contrat.

C’est aussi le document qui permet de mesurer le service. Un délai de prise en charge annoncé est un délai qu’on peut suivre, comparer, et sur lequel on peut être jugé. Un forfait d’heures n’offre aucun de ces trois usages.

---

Footnotes

1. Sur la séparation des enveloppes — maintien, dette, capacité, pari — et sur ce que coûte de ne pas nommer le maintien, voir Arbitrer son budget techno en décembre. ↩