Maintenance corrective : définition, gravité des anomalies et délais

La maintenance corrective regroupe les travaux qui corrigent les anomalies d’une application en service : ce qui ne fonctionne pas comme convenu est rétabli. Dans un contrat de tierce maintenance applicative (TMA), c’est la partie qui engage des délais. Ce guide en donne la définition, une façon de classer les anomalies par gravité, les délais à écrire au contrat et ce qu’il faut suivre.

Il s’adresse aux dirigeants, aux DSI et aux responsables de produit dont l’application est en production, qu’ils confient déjà sa maintenance applicative à un prestataire ou qu’ils s’apprêtent à le faire.

Maintenance corrective : définition

La maintenance corrective désigne les travaux qui ramènent une application en service au comportement prévu, après qu’une anomalie a été constatée. Elle ne change pas ce que fait l’application : elle lui fait de nouveau faire ce qu’elle devait faire.

Le cahier des clauses administratives générales des marchés publics de techniques de l’information et de la communication, le CCAG-TIC 2021, sert de repère bien au-delà des marchés publics. Son article 38 dit : « Par “correctif”, on entend les mesures consistant à corriger les anomalies. » Le Grand dictionnaire terminologique de l’Office québécois de la langue française la définit de son côté comme la « maintenance destinée à corriger les erreurs relevées dans un logiciel, après sa livraison ».

Les deux définitions posent la même limite : on parle de correctif pour une application livrée. Un défaut trouvé pendant le développement ou la recette se corrige dans le projet, avant la mise en service.

Le correctif est l’une des quatre familles de la maintenance, avec le préventif, l’adaptatif et l’évolutif. Notre article sur la maintenance évolutive trace les frontières entre les quatre.

Qu’est-ce qu’une anomalie, et qu’est-ce qui n’en est pas une ?

Une anomalie est un écart entre ce que fait l’application et ce qui a été convenu : une spécification, une recette signée, une documentation, ou un comportement établi que personne n’a demandé de changer. L’article 38 du CCAG-TIC ne définit pas le mot : c’est au contrat de le faire.

Les cas limites existent. Une anomalie peut naître d’un changement d’environnement, un navigateur ou une interface d’échange par exemple : le contrat dit alors qui la prend en charge et à quel titre. Le plus sûr est de qualifier chaque demande à l’entrée, par écrit, avant de la traiter.

Comment classer une anomalie par gravité ?

La gravité d’une anomalie se mesure à son effet sur l’activité, pas à la difficulté de la corriger. Quatre questions suffisent à la fixer : la fonction touchée est-elle essentielle ? Combien d’utilisateurs sont gênés ? Existe-t-il un contournement acceptable ? Des données ou la sécurité sont-elles en jeu ?

Les noms et le nombre de niveaux varient d’un contrat à l’autre. Ce qui compte, c’est que chaque niveau soit défini par des critères écrits, avec des exemples tirés de l’application elle-même. Sans cette grille, l’urgence se décide au cas par cas, au téléphone.

Qui classe ? Le client propose une gravité au signalement, le prestataire la confirme ou la discute à la qualification, et un désaccord remonte à un interlocuteur nommé de chaque côté. Une faille de sécurité suit sa propre règle : le CCAG-TIC prévoit, à son article 40, des délais d’application des mises à jour de sécurité fixés « en fonction du niveau de risque associé ». Pour un éditeur de logiciel, le Cyber Resilience Act ajoute des obligations de signalement.

Quels délais écrire dans le contrat ?

Un engagement de maintenance corrective tient en trois délais, fixés pour chaque niveau de gravité.

• Le délai de prise en charge. Du signalement au moment où le prestataire commence à traiter l’anomalie, et le fait savoir.
• Le délai de contournement. Le temps de remettre l’activité en marche par une solution provisoire quand la correction demande plus longtemps : une manipulation, un correctif temporaire, une fonction désactivée.
• Le délai de correction. Le temps de livrer la correction définitive, testée, en production.

Trois précisions changent la portée de ces délais :

• La plage d’intervention. Heures ouvrées ou continues, jours fériés compris ou non. Le CCAG-TIC prévoit ainsi que le décompte du délai de réponse à une demande d’intervention « ne court que pendant la période d’intervention définie dans les documents particuliers du marché » (article 39).
• Le point de départ. La réception du signalement, ou la qualification de l’anomalie : les deux ne tombent pas forcément au même moment.
• Ce qui suspend le délai. Une information attendue du client, un accès qui manque, une validation à faire de son côté.

Le CCAG-TIC renvoie aux documents de chaque marché la définition des niveaux de service, des moyens de les mesurer et des « sanctions applicables en cas de non-respect des niveaux prévus » (article 38). Dans un contrat privé, la logique est la même : un délai sans mesure ni conséquence reste une intention.

Comment se déroule une correction, du signalement à la clôture ?

Une anomalie bien traitée passe par sept étapes, dans un outil de suivi que le client et le prestataire voient tous les deux.

• Le signalement. Ce qui était attendu, ce qui s’est passé, quand, pour quel utilisateur, avec une capture ou le message d’erreur. Un signalement précis raccourcit le diagnostic.
• La qualification. Anomalie ou non, et quelle gravité.
• La reproduction et le diagnostic. L’anomalie est reproduite hors production et sa cause est trouvée.
• Le contournement, si l’anomalie bloque. L’activité repart avant la correction définitive.
• La correction et ses tests. La correction, puis des tests de non-régression : elle ne doit rien casser ailleurs.
• La validation et la mise en production. Le client vérifie sur un environnement de test, puis la correction part en production.
• La clôture. Le ticket est fermé avec la cause, la correction et la version livrée. Pour une anomalie bloquante, une courte analyse dit pourquoi elle est arrivée et ce qui évitera qu’elle revienne.

Comment se facture la maintenance corrective ?

Le correctif se prête à un forfait : son volume s’estime à partir de l’application, de son âge et de l’historique de ses anomalies. Il peut aussi se décompter au temps passé, sur une enveloppe réservée, ou combiner les deux, avec un plafond au-delà duquel le temps est facturé à part.

Une question se règle à part : la correction des défauts introduits par le prestataire lui-même. Le contrat dit si elle est à sa charge, pendant combien de temps après la livraison, et ce qui en est exclu. Les clauses à vérifier sont détaillées dans notre guide du contrat de maintenance applicative.

Que suivre pour savoir si la maintenance corrective fonctionne ?

Cinq indicateurs, relus chaque mois avec le prestataire, montrent si le correctif est tenu et s’il diminue.

• Les anomalies ouvertes, par gravité et par ancienneté. Ce qui attend, et depuis quand.
• Les délais tenus. Les anomalies prises en charge et corrigées dans les délais du contrat, niveau par niveau.
• Les anomalies rouvertes. Une correction qui ne tient pas est une correction à refaire.
• Les anomalies qui reviennent au même endroit. Elles désignent un module fragile.
• La part du correctif dans le temps passé. Si elle ne baisse pas avec les mois, l’application ne se stabilise pas.

Questions fréquentes

Maintenance corrective : écrivez les règles avant la première anomalie

La maintenance corrective se passe bien quand trois choses sont écrites avant la première anomalie : ce qui en est une, comment on la classe, et dans quels délais on la traite. Le reste se mesure chaque mois.

L’équipe iones assure la maintenance applicative d’applications en service, correctif compris, et peut commencer par un audit de l’existant. Pour confier la maintenance à un prestataire, notre guide pour externaliser sa maintenance applicative détaille les étapes. Vous pouvez aussi nous écrire pour un premier échange.