Contrat de maintenance et d’évolution

Un applicatif stable consomme peu de correctifs et beaucoup de montées de version. Les briques sur lesquelles il repose sortent du support de leurs éditeurs à des dates fixées sans rapport avec votre activité. Le contrat sert alors à absorber ces échéances au rythme où elles tombent. Sans lui, tout ce retard s’accumule en silence, jusqu’au jour où il faut le rattraper d’un coup.

Oui, après un audit de reprise, chiffré à part. Nous lisons le code, l’architecture, les briques utilisées et l’état de la documentation avant de nous engager. Sans cette étape, un engagement de correction porterait sur un ensemble dont nous ignorons les zones fragiles. L’audit dit ce qui est reprenable en l’état, ce qui demande une remise à niveau préalable, et ce qui relève plutôt de reprendre un projet développé ailleurs.

Nous demandons à maîtriser l’hébergement, ou au minimum à disposer des accès serveur complets. Un engagement de disponibilité suppose de voir les journaux, de redémarrer un service et d’appliquer un correctif système sans passer par un tiers. Quand l’hébergement reste chez vous ou chez votre infogérant, le contrat existe toujours, mais son contenu change : il porte alors sur l’applicatif seul, la disponibilité de la machine restant du côté de celui qui la tient.

Elle sort du forfait et part au devis. L’enveloppe couvre les demandes courantes, celles qui se traitent en quelques jours. Un nouveau module, une refonte de parcours ou une interface avec un outil supplémentaire se chiffrent comme un projet, avec leur propre cadrage. Nous le disons au moment de la demande, avant que le travail commence. Le compte rendu périodique affiche ce qui reste dans l’enveloppe pour éviter la surprise.

Le délai fait partie de ce qui distingue les formules entre elles. Il se chiffre dans votre contrat, une fois votre applicatif connu. Ce qui est constant, c’est la manière de le construire : les incidents se classent par gravité, et un blocage de la production ne suit pas le même circuit qu’un affichage imparfait sur un écran de consultation. Nous convenons de cette grille avec vous, puis nous y attachons un engagement de prise en charge. Cette même grille dit si un blocage détecté un soir ou un week-end déclenche une intervention immédiate ou attend la reprise du lundi : la réponse tient au niveau de gravité choisi à la signature, pas à l’heure à laquelle l’incident tombe.

Non, le contrat sert justement à voir venir ce moment. Tant que les demandes se livrent dans des délais normaux, la maintenance suffit. Quand une évolution simple oblige à toucher cinq endroits du code, ou que le socle technique n’a plus de version supportée vers laquelle migrer, le coût du suivi dit lui-même qu’il faut regarder ailleurs. Ce signal apparaît dans le compte rendu avant de devenir une urgence.

Un éditeur met à jour son produit selon sa feuille de route, arbitrée sur l’ensemble de sa base de clients. Les mises à jour arrivent quand il les décide, apportent des fonctions que vous n’avez pas demandées, et ce que vous attendez peut ne jamais sortir. Un outil du marché reste le bon choix tant que ses priorités croisent les vôtres. Le contrat sur un applicatif que vous possédez se justifie le jour où les vôtres doivent passer devant.

Chaque demande entre dans une liste commune dès qu’elle est formulée, avec le service qui la porte et l’usage qu’elle sert. Nous les classons ensemble à intervalle régulier, pas au fil de l’eau, pour que la plus utile à votre activité passe devant, indépendamment de son ordre d’arrivée. Le compte rendu périodique reprend cette liste, dit ce qui a été livré et ce qui reste à trancher pour la période suivante, pour qu’aucune demande ne se perde dans un fil de mails comme au temps du projet initial.