Contrat de maintenance : ce que vous devez exiger

Le projet a été livré. La plateforme métier est en production. La réunion de clôture a eu lieu. C'est le moment précis où le directeur achats doit ouvrir un nouveau dossier, car ce qui a été budgété et mis en œuvre ne couvre que la livraison. Ce qui vient après (correctifs, adaptations, évolutions) dépend d'un contrat de maintenance qu'il faut négocier avant que le premier incident ne vous rappelle son absence.

Aucun logiciel n'est jamais fini. Une plateforme web qui gère les achats, les flux avec les fournisseurs, ou le suivi de prestations de services continuera à évoluer sous trois types de pression : les bugs qui se révèlent en usage réel, les demandes d'adaptation métier, et les mises à jour de sécurité. Sans contrat de support, chaque ticket devient une négociation commerciale. Avec un contrat mal rédigé, la facture arrive quand même, simplement déguisée sous l'étiquette « évolutif ».

Cet article détaille les six lignes contractuelles qu'un acheteur doit exiger dans un contrat de maintenance applicative, et la mécanique exacte des engagements de service (SLA, pénalités, frontières de facturation) qu'il faut lire avant de signer.

Ce que couvre la garantie après mise en production, et jusqu'à quelle date

La garantie est l'unique période où tout correctif est inclus dans le forfait projet. Elle démarre à la recette définitive (ou au go-live si la recette est confondue avec la mise en production) et court typiquement entre trois et douze mois. Passé cette date, tout correctif relève du contrat de maintenance, donc d'un abonnement annuel payant.

Trois calendriers comptent :

1. Le délai de garantie légale : en droit français, c'est deux ans à compter de la livraison pour les vices cachés. Certains contrats tentent de réduire cette durée par clause ; un juriste d'entreprise doit valider la conformité.
2. Le délai de garantie contractuel : celui inscrit au contrat projet, généralement six ou douze mois, pendant lequel l'éditeur ou l'intégrateur s'engage à corriger tout bug sans facturation additionnelle.
3. Le délai de signalement : certains fournisseurs imposent que tout bug soit signalé pendant la garantie pour être corrigé gratuitement, même si la correction est livrée après. Un bug découvert le mois suivant devient payant. Cette clause doit être identifiée et négociée dès la signature du projet.

Un directeur des achats doit donc inscrire dans l'agenda le terme de la garantie, car passée cette date, sans contrat de support actif, un simple bug bloquant peut nécessiter un bon de commande ad hoc, avec un délai commercial qui ajoute des semaines au délai de correction.

La frontière correctif / évolutif : où fuient les budgets d'après-projet

Le budget informatique d'après-projet disparaît presque toujours au même endroit : la frontière entre ce qui relève du correctif (inclus dans le contrat de support) et ce qui relève de l'évolutif (facturé en régie ou en forfait additionnel). Cette ligne est juridiquement définie dans le contrat de maintenance, mais commercialement interprétée à chaque ticket.

Définition standard du correctif : toute déviation entre le comportement actuel de la plateforme et ce qui a été spécifié et validé lors de la recette. Si la fonctionnalité de validation de facture fournisseur exige trois niveaux d'approbation et que la plateforme en permet deux, c'est un correctif. Si elle fonctionne comme spécifié, mais que vous souhaitez ajouter un quatrième niveau, c'est un évolutif.

Définition standard de l'évolutif : toute modification fonctionnelle qui va au-delà du périmètre initial, même si elle vous semble mineure. Cela inclut les nouvelles fonctionnalités, les adaptations de processus métier, les intégrations avec de nouveaux systèmes tiers, et toute demande de refonte d'interface.

Le piège commercial est simple : chaque fournisseur qualifie ses propres tickets. Si vous demandez une correction et qu'il répond « c'est un évolutif », il vous faudra prouver que la spécification initiale couvrait ce point. Les trois leviers pour encadrer cette frontière :

1. Une définition contractuelle stricte : au lieu de la clause générique ci-dessus, inscrivez que « tout comportement non conforme aux spécifications validées lors de la recette projet constitue un correctif », et annexez au contrat de support la dernière version des spécifications signées. Sans cette référence, tout est négociable.
2. Un comité de classification : certains contrats prévoient qu'en cas de désaccord sur la nature d'un ticket (correctif ou évolutif), un comité paritaire (un représentant client, un représentant fournisseur, et éventuellement un expert métier indépendant) se réunit sous 72 heures pour trancher. Cela évite le blocage unilatéral.
3. Un log d'arbitrage : exigez que toute décision de requalification (correctif reclassé en évolutif) soit notifiée par écrit avec justification. Cela crée une piste d'audit utile lors des revues budgétaires et permet de repérer les fournisseurs qui utilisent la requalification comme levier commercial.

En pratique, cette frontière est le lieu exact où les budgets de maintenance explosent. Un DSI qui pense avoir contractualisé 20 000 euros annuels de support se retrouve à 45 000 euros parce que la moitié des tickets ont été requalifiés en évolutif facturé au temps passé.

Lire une grille de sévérité : délai de prise en compte contre délai de rétablissement

Un contrat de support mentionne toujours un SLA (Service Level Agreement), mais il faut distinguer deux engagements différents, souvent confondus volontairement :

• Délai de prise en compte : le temps maximum entre la déclaration du ticket et la première réponse du support (accusé de réception, qualification, assignation).
• Délai de rétablissement : le temps maximum entre la déclaration et la livraison d'une correction fonctionnelle ou d'un contournement validé par le client.

La majorité des contrats ne s'engagent que sur le premier. Voici une grille standard pour un abonnement de support à 18 000 euros annuels :

Trois pièges à identifier avant signature :

1. La sévérité est unilatéralement décidée par le fournisseur. Exigez que la classification soit validée conjointement sous 30 minutes pour les S1, une heure pour les S2. Sinon, un bug qui bloque vos processus achats peut être requalifié en S3 par le support et traité trois semaines plus tard.
2. Le délai de rétablissement pour les S3 et S4 est vide. La formule « prochaine version mineure » signifie : nous le corrigerons quand nous le déciderons. Négociez un engagement calendaire (par exemple : 30 jours ouvrés maximum pour les S3).
3. Les horaires d'application du SLA sont limités aux heures ouvrables. Un ticket déclaré vendredi à 17h30 n'est pris en compte que lundi matin 9h. Si votre plateforme tourne en continu (cas d'une plateforme de gestion de commandes fournisseurs en flux tendu), le contrat de support doit inclure une astreinte 24/7 pour les S1 et S2.

Ce qu'un acheteur doit exiger : une grille de sévérité où le client valide la classification, et un engagement de rétablissement chiffré pour toutes les sévérités, y compris les S3.

Quand démarre le chronomètre, et quelles exclusions le suspendent

Un SLA n'est utile que si le chronomètre démarre au bon moment et ne peut pas être arbitrairement arrêté. Deux zones de négociation :

Point de départ du SLA

Le délai contractuel démarre-t-il au moment où vous envoyez l'email au support, ou au moment où le fournisseur valide que votre ticket est recevable ? Certains contrats inscrivent que « le SLA commence dès lors que le ticket est qualifié conforme aux exigences de signalement ». Cela signifie que si votre ticket ne contient pas les captures d'écran requises, le chronomètre ne démarre jamais, même si le bug est évident.

Ce qu'il faut négocier : le SLA démarre à la réception du ticket par le support, quelle que soit sa complétude initiale. Si le ticket est incomplet, le support peut demander des informations complémentaires, mais le chronomètre continue. Cela évite les tactiques dilatoires où chaque demande de complément remet le compteur à zéro.

Exclusions qui suspendent le SLA

Tous les contrats prévoient des exclusions légitimes (catastrophe naturelle, grève, panne d'hébergeur tiers). Le problème surgit avec les exclusions extensibles :

• « En attente d'informations client » : si le support vous demande des logs supplémentaires, le SLA est suspendu jusqu'à votre réponse. Certains fournisseurs utilisent cette clause pour poser une question toutes les 48 heures et maintenir le ticket en attente perpétuelle. Négociez un délai maximum de suspension (par exemple : le SLA peut être suspendu 72 heures maximum par demande d'information, puis reprend automatiquement).
• « Bug dans un composant tiers » : si l'incident provient d'un module externe (CRM, ERP, API bancaire), le SLA ne s'applique pas. Cette clause est légitime, mais elle doit être encadrée : le fournisseur reste responsable de l'escalade auprès du tiers, et le client doit être informé sous 24 heures si l'incident sort du périmètre contractuel.
• « Environnement non conforme » : si votre infrastructure (serveurs, bases de données, réseau) ne respecte pas les spécifications techniques du fournisseur, le SLA est caduc. Cela couvre des cas légitimes (vous avez installé un pare-feu non supporté), mais certains contrats élargissent cette clause pour inclure toute configuration non validée par écrit. Exigez une liste fermée des prérequis techniques, et que toute déviation soit notifiée avant suspension du SLA.

Un contrat bien rédigé doit inscrire que « toute suspension de SLA doit faire l'objet d'une notification écrite au client sous 12 heures, avec justification et date de reprise prévisionnelle du chronomètre ».

Ce qui se passe en cas de manquement : pénalité, avoir, escalade, ou rien

Un SLA sans mécanisme de pénalité est une promesse commerciale, pas un engagement contractuel. Pourtant, la majorité des contrats de support ne prévoient aucune conséquence en cas de dépassement. Trois modèles existent :

Modèle 1 : Pénalité financière automatique

Le contrat prévoit qu'en cas de dépassement du SLA, une pénalité est appliquée, calculée soit en pourcentage de l'abonnement mensuel, soit en montant fixe par heure de retard. Exemple :

• S1 dépassé de 2 heures : pénalité de 500 euros par heure de retard, plafonnée à 10% du montant annuel du contrat.
• S2 dépassé de 1 jour : pénalité de 200 euros par jour de retard, plafonnée à 5% du montant annuel.

Ce modèle impose au fournisseur une discipline opérationnelle stricte. Cependant, il est rarement accepté par les intégrateurs sur les contrats inférieurs à 50 000 euros annuels. Il faut le demander dès la négociation initiale, car aucun fournisseur ne l'acceptera en avenant.

Modèle 2 : Avoir commercial sur renouvellement

Plutôt qu'une pénalité immédiate, le contrat prévoit qu'en cas de manquements répétés (par exemple : trois dépassements de SLA S1 ou S2 sur un trimestre), le client bénéficie d'un avoir équivalent à un mois d'abonnement, déduit du renouvellement annuel. Ce modèle est plus acceptable pour les fournisseurs, mais il ne protège le client que s'il renouvelle le contrat.

Modèle 3 : Clause d'escalade et droit de résiliation

À défaut de pénalité financière, le contrat doit au minimum prévoir qu'en cas de manquement grave (par exemple : incident critique non résolu sous 72 heures, ou trois dépassements de SLA majeur en un trimestre), le client peut :

1. Déclencher une escalade auprès de la direction du fournisseur, avec réponse obligatoire sous 48 heures.
2. Suspendre le paiement de l'abonnement jusqu'à résolution (clause de rétention).
3. Résilier le contrat de support sans pénalité et transférer la maintenance à un tiers, avec obligation de livraison de la documentation technique et du code source sous 15 jours.

Ce troisième modèle est le strict minimum. Sans aucune de ces trois clauses, un contrat de support est purement déclaratif, et le fournisseur peut impunément ignorer les SLA.

L'abonnement d'évolutif : acheter un menu tarifé plutôt qu'une capacité abstraite

La maintenance corrective ne suffit jamais. Toute plateforme métier nécessite des ajustements fonctionnels (nouvelles règles métier, intégrations de systèmes, refonte de processus). Les fournisseurs proposent donc un « forfait évolutif », vendu soit en jours/homme prépayés, soit en capacité mensuelle (par exemple : « 10 heures d'évolutif par mois incluses dans l'abonnement »).

Le piège classique de cette offre est que la capacité est abstraite : vous achetez « 10 heures par mois », mais vous ne savez pas ce que ces heures produiront concrètement, ni ce qui se passe si vous ne les consommez pas. Trois mécanismes doivent être cadrés :

1. Report ou perte des heures non consommées

Si vous consommez 6 heures en janvier, que se passe-t-il avec les 4 heures restantes ? Certains contrats prévoient un report trimestriel (vous pouvez cumuler jusqu'à 30 heures sur trois mois, puis elles sont perdues). D'autres imposent un use-it-or-lose-it mensuel strict. Négociez un report annuel avec liquidation au renouvellement, pour éviter de créer de fausses urgences en fin de mois.

2. Valorisation du temps en cas de dépassement

Si vous consommez 14 heures en février, comment sont facturées les 4 heures supplémentaires ? Le contrat doit préciser le tarif horaire hors forfait (généralement 20 à 30% plus élevé que le tarif implicite du forfait). Sans cette clause, le fournisseur facture au tarif commercial plein, ce qui rend le forfait inutile.

3. Transparence du temps consommé

Exigez un relevé mensuel détaillé (ticket par ticket, avec temps passé par développeur et statut de livraison). Sans ce relevé, vous ne pouvez pas vérifier que les heures facturées correspondent au temps réellement consommé. Certains fournisseurs gonflent artificiellement les estimations pour épuiser le forfait et basculer en régie payante.

Une alternative plus protectrice pour l'acheteur est le forfait au ticket : au lieu d'acheter des heures, vous achetez un volume de tickets évolutifs (par exemple : 12 tickets par an, quelle que soit leur complexité, dans une enveloppe de charge définie). Cela transfère le risque de sizing sur le fournisseur.

Mesurer la capacité réellement livrée chaque mois

Un abonnement de maintenance est un flux, pas un événement. Pourtant, beaucoup d'entreprises paient un contrat de support pendant des années sans jamais mesurer ce qu'il produit concrètement. Trois indicateurs doivent être suivis mensuellement par le directeur des achats ou le responsable SI :

Taux de respect du SLA

Le fournisseur doit publier chaque mois un rapport indiquant, pour chaque sévérité, le nombre de tickets traités et le pourcentage respectant le SLA contractuel. Exemple :

• S1 : 2 tickets, 100% dans les délais
• S2 : 8 tickets, 75% dans les délais (2 dépassements)
• S3 : 15 tickets, 60% dans les délais

Si ce taux descend sous 80% deux mois de suite, c'est un signal de dégradation de la qualité de service. Le contrat doit prévoir qu'un taux inférieur à 75% sur un trimestre déclenche une revue de service avec plan d'action correctif.

Temps moyen de résolution par sévérité

Au-delà du respect binaire du SLA (dans les temps ou pas), mesurez le temps moyen réel de résolution. Si le SLA S2 est de 5 jours et que le temps moyen de résolution est de 4,8 jours, le fournisseur respecte formellement son engagement, mais travaille systématiquement au bord du délai. Cela indique une sous-capacité structurelle.

Taux de requalification correctif vers évolutif

Si 40% de vos demandes de correctif sont requalifiées en évolutif par le support, c'est soit un problème de définition contractuelle floue, soit une tactique commerciale du fournisseur. Demandez un reporting mensuel du nombre de tickets requalifiés, avec justification écrite. Au-delà de 20%, exigez une révision de la définition contractuelle du correctif.

Ces trois indicateurs doivent être publiés par le fournisseur sous forme de tableau de bord mensuel, idéalement accessible en ligne. Leur absence est un signal d'alerte : un prestataire qui ne mesure pas sa propre performance n'a aucune incitation à l'améliorer.

Les six lignes à exiger dans un contrat de support

Récapitulatif des clauses contractuelles qui protègent réellement votre budget de maintenance :

1. Définition stricte de la frontière correctif/évolutif : « Tout comportement non conforme aux spécifications validées lors de la recette projet constitue un correctif. En cas de désaccord, un comité paritaire tranche sous 72 heures. »
2. Grille de sévérité avec délais de rétablissement chiffrés pour toutes les catégories, y compris S3 et S4, et validation conjointe de la sévérité assignée à chaque ticket.
3. Point de départ du SLA à la réception du ticket, avec encadrement strict des motifs de suspension (durée maximale, notification écrite obligatoire).
4. Mécanisme de pénalité ou d'escalade en cas de manquement : pénalité financière automatique, avoir au renouvellement, ou droit de résiliation sans pénalité après manquements répétés.
5. Transparence du forfait évolutif : report annuel des heures non consommées, tarif de dépassement fixé contractuellement, relevé mensuel détaillé du temps passé par ticket.
6. Reporting mensuel obligatoire : taux de respect du SLA, temps moyen de résolution, taux de requalification correctif/évolutif, publié sous 5 jours ouvrés après clôture du mois.

Sans ces six lignes, un contrat de maintenance est un abonnement à l'incertitude. Avec elles, vous transformez une dépense opaque en un service mesurable, et vous donnez aux achats les leviers pour négocier sur la base de faits, pas de promesses.

Pour aller plus loin dans la structuration de vos contrats applicatifs, découvrez nos services de conseil digital et d'accompagnement sur les applications métier.

FAQ

Quelle est la durée standard d'un contrat de maintenance applicative ?

Un contrat de maintenance court généralement sur 12 mois, renouvelable par tacite reconduction. Certains fournisseurs proposent des engagements pluriannuels (24 ou 36 mois) avec tarif dégressif, ce qui peut être intéressant si la plateforme est stratégique et que le fournisseur a fait ses preuves pendant la garantie. Négociez toujours une clause de résiliation anticipée sans pénalité en cas de manquement grave (par exemple : trois mois consécutifs avec taux de respect SLA inférieur à 70%).

Un contrat de support peut-il couvrir plusieurs applications ?

Oui, certains contrats de support mutualisent la maintenance de plusieurs plateformes (par exemple : un ERP, un CRM, et un portail fournisseurs) sous un seul abonnement global. Cette approche permet de négocier un tarif plus avantageux et de simplifier la gestion contractuelle, mais elle exige une ventilation claire du temps passé par application dans les reportings mensuels, pour éviter qu'une plateforme consomme tout le forfait au détriment des autres.

Faut-il exiger le code source en garantie dès la signature du contrat de support ?

Oui, particulièrement si la plateforme est stratégique et que le fournisseur est une petite structure. La clause d'entiercement (ou « escrow ») prévoit que le code source est déposé auprès d'un tiers de confiance (notaire, organisme spécialisé) et vous est transmis automatiquement en cas de défaillance du fournisseur (liquidation, cessation d'activité, manquement contractuel grave). Cela permet de reprendre la maintenance avec un tiers sans perdre des mois à reconstruire l'application.

Comment négocier un SLA réaliste sans surpayer ?

Un SLA très exigeant (par exemple : rétablissement S1 sous 2 heures, 24/7) coûte structurellement plus cher, car il impose au fournisseur une astreinte permanente. Pour un budget maîtrisé, privilégiez un SLA en heures ouvrables (lundi-vendredi, 9h-18h) avec une option d'astreinte 24/7 activable à la demande moyennant un supplément mensuel. Cela vous donne la flexibilité de monter en exigence si la criticité de la plateforme augmente, sans payer ce niveau de service toute l'année.

Que faire si le fournisseur refuse d'inscrire des pénalités de retard dans le contrat ?

Si le fournisseur refuse toute clause de pénalité, négociez au minimum une clause d'escalade avec droit de résiliation sans pénalité en cas de manquement répété. Vous pouvez aussi conditionner le paiement de l'abonnement trimestriel à l'atteinte d'un taux de respect SLA minimum (par exemple : 80% des tickets S1 et S2 dans les délais). Cette clause incitative est moins punitive qu'une pénalité, mais elle crée une contrainte budgétaire réelle pour le fournisseur.