Contrat de maintenance applicative : ce qu'il doit couvrir

Pour beaucoup de dirigeants, une application bien maintenue est une application qui tourne : le site est accessible, l'hébergement est payé, tout s'affiche correctement. Cette représentation est compréhensible, et elle est à l'origine de la plupart des malentendus entre un client et son prestataire.

Ces malentendus viennent rarement de la mauvaise foi. Ils viennent d'un contrat qui ne dit pas ce que chacun a en tête. Un contrat de maintenance applicative sérieux répond à cinq questions : ce qui est surveillé, ce qui est sécurisé, dans quels délais on intervient, qui est responsable de quoi, et comment on se quitte.

MCO et MCS : les deux piliers de la maintenance

Une maintenance applicative repose sur deux piliers distincts.

• Le MCO (maintien en conditions opérationnelles) correspond à ce que tout le monde imagine : s'assurer que l'application continue de fonctionner, intervenir en cas d'incident, corriger les bugs, maintenir la continuité de service, s'assurer des sauvegardes. C'est la partie visible.
• Le MCS (maintien en conditions de sécurité) est souvent invisible et tout aussi critique. Il couvre la mise à jour régulière des composants applicatifs et des dépendances logicielles, et le suivi des CVE, les failles de sécurité connues et référencées. Une seule dépendance non mise à jour peut exposer toute une application à une vulnérabilité documentée publiquement, et cela arrive chaque jour dans le développement web.

Les clients ne voient presque jamais cette partie, et certains prestataires ne l'assurent pas vraiment, faute de l'avoir formalisée. Si votre contrat ne mentionne ni mise à jour des dépendances ni suivi des failles connues, posez la question.

Ce suivi s'automatise. Par exemple, sur les projets que je maintiens, un pipeline GitLab tourne chaque semaine : il analyse les dépendances à la recherche de vulnérabilités connues, audite les composants applicatifs et scanne les environnements conteneurisés quand le projet l'exige. Le client dispose ainsi d'une visibilité régulière sur l'état de sécurité de son application, sans attendre qu'un incident révèle un problème présent depuis des semaines.

Les GTR : définir ce que « rapidement » veut dire

Un engagement à « intervenir rapidement » reste vague tant que le délai n'est pas écrit : le « rapidement » du prestataire et celui du client diffèrent souvent.

Les garanties de temps de rétablissement (GTR) fixent ces délais selon la gravité de l'incident. Voici les trois niveaux que j'applique dans mes contrats :

Ce cadre aligne les attentes dès la signature. Le client sait ce qu'il peut attendre selon la gravité du problème, le prestataire sait ce qu'il doit livrer. Et la conversation inconfortable du « j'attendais une intervention dans l'heure » n'a plus lieu d'être.

Les responsabilités : le sujet que personne ne veut aborder

C'est le point le plus souvent mal compris. Une maintenance applicative couvre l'application ; le matériel, le réseau et l'infrastructure relèvent d'une autre responsabilité, qui doit être écrite. Si le serveur géré par le client tombe, sa remise en service sort du périmètre.

La situation est fréquente. Après un incident serveur, un client m'a demandé de réinstaller l'application sur une nouvelle machine, en considérant que cela entrait dans le forfait. Ce genre de désaccord se règle en une ligne de contrat, à condition de l'avoir écrite avant.

Il en va de même pour les noms de domaine et les certificats SSL. Si un nom de domaine expire faute de renouvellement par le client, le rétablissement d'une architecture fonctionnelle fait l'objet d'une facturation complémentaire. Cette clause relève du bon sens, mais personne ne pense à la formuler tant que le problème ne s'est pas posé.

Ces éléments peuvent aussi être confiés au prestataire quand le besoin existe. L'essentiel est que le contrat dise qui s'en occupe.

La réversibilité : prévoir la fin dès le début

Que se passe-t-il à la fin du contrat ? La clause de réversibilité y répond, et c'est l'une des plus importantes. Elle engage le prestataire à restituer les données, les configurations, les accès et les procédures documentées dans un délai défini, 20 jours ouvrés dans mes contrats. Le client, ou son nouveau prestataire, doit pouvoir reprendre le service sans interruption.

C'est souvent la clause qui rassure le plus : elle montre que la fin de la relation est pensée dès le début, et que rien n'est fait pour rendre les choses opaques.

Avant de signer : cinq questions à poser à votre prestataire

Si vous êtes sur le point de signer un contrat de maintenance, ou si vous relisez celui que vous avez déjà, vérifiez qu'il répond à ces questions.

1. Sécurité : comment les dépendances et les failles connues (CVE) sont-elles suivies, à quelle fréquence, et comment en suis-je informé ?
2. Délais : quels sont les délais d'intervention et de rétablissement pour un incident bloquant, majeur ou mineur ?
3. Sauvegardes : qui les réalise, qui vérifie qu'elles fonctionnent ?
4. Périmètre : serveur, réseau, nom de domaine, certificat SSL : qui en est responsable, et qu'est-ce qui est facturé en plus ?
5. Sortie : en fin de contrat, qu'est-ce qui m'est restitué, et dans quel délai ?

Une réponse floue à l'une de ces questions annonce un malentendu le jour où le problème se posera.

Ce que ça change en pratique

Formaliser ces cinq points assainit la relation client, sans la rendre froide ou juridique. Le client sait ce qu'il paie, ce qu'il peut attendre et ce qui sort du périmètre. Le prestataire sait ce qu'il doit livrer, dans quels délais, et où s'arrête sa responsabilité.

La plupart du temps, parcourir ces points ensemble avant de signer suffit à éviter une grande partie des tensions futures.

La maintenance applicative est un cadre de collaboration. Comme tout cadre, il vaut mieux le poser avant d'en avoir besoin.

Vous voulez faire relire le contrat de maintenance de votre prestataire, ou en poser un pour votre application ?

C'est typiquement le genre de sujet que je traite dans le cadre du pilotage SI à temps partagé.