Un bug bloque la facturation, un écran renvoie une erreur, un calcul de remise est faux depuis lundi : la maintenance corrective entre en jeu. Bien menée, elle rétablit le service vite et empêche le même défaut de revenir. Mal menée, elle se résume à des échanges de courriels, des correctifs posés à la hâte et des bugs qui réapparaissent. Voici la méthode en 6 étapes que nous appliquons, du signalement à la clôture.

Maintenance corrective : de quoi parle-t-on exactement ?

La maintenance corrective regroupe les interventions qui corrigent un défaut constaté dans une application en service : un comportement différent de ce qui était prévu, une erreur, un plantage, une donnée faussée. La norme ISO/IEC/IEEE 14764 (édition 2022), consacrée à la maintenance logicielle, la distingue des autres catégories de maintenance : l'adaptative (suivre un changement d'environnement, comme une nouvelle version de système), la préventive (corriger avant que le défaut ne se manifeste) et l'évolutive (ajouter ou améliorer une fonction).

Cette distinction n'a rien de théorique. Une demande présentée comme un bug alors qu'il s'agit d'une évolution fausse les délais, les priorités et souvent la facture. Le premier réflexe d'une bonne maintenance corrective est donc de vérifier qu'on parle bien d'un défaut.

Étape 1 : signaler le bug avec les bonnes informations

La moitié du temps de correction se joue au moment du signalement. Un message du type « l'appli ne marche plus » oblige le développeur à enquêter avant même de chercher la cause. Un signalement utile tient en quelques lignes :

  • Ce qui s'est passé et ce qui aurait dû se passer.
  • Les étapes pour reproduire : écran, action, données saisies.
  • Quand et qui : date et heure, utilisateur concerné, poste ou téléphone utilisé.
  • Une capture d'écran ou le message d'erreur exact.
  • L'impact métier : combien de personnes bloquées, quel processus arrêté.

Le plus efficace consiste à intégrer un formulaire de signalement directement dans l'application. Il capture automatiquement l'utilisateur, la page et la version, et crée le ticket sans ressaisie.

Étape 2 : qualifier et prioriser la demande

Chaque ticket reçu doit être qualifié avant d'être traité. Trois questions suffisent : est-ce un défaut, une demande d'évolution ou une question d'utilisation ? Quelle est la gravité ? Existe-t-il un contournement ?

La gravité se définit en termes métier, pas techniques. Une grille simple à trois niveaux fonctionne bien en PME :

  • Bloquant : un processus clé est arrêté sans contournement (facturation, prise de commande, paie).
  • Majeur : une fonction importante est dégradée, mais un contournement existe.
  • Mineur : un défaut gênant sans effet sur l'activité (libellé, affichage, tri).

Cette grille doit être écrite et partagée avec vos utilisateurs, sinon tout devient « urgent ». Si vous travaillez avec un prestataire, elle doit correspondre aux niveaux de gravité prévus au contrat.

Étape 3 : reproduire avant de corriger

Un bug qu'on ne sait pas reproduire est un bug qu'on ne sait pas vérifier. Le développeur reproduit d'abord le défaut, idéalement sur un environnement de test avec des données proches de la production, jamais en modifiant directement l'application en service.

Les journaux applicatifs (logs) sont ici précieux : ils indiquent l'erreur exacte, l'heure et le contexte. Une application sans journalisation exploitable rend chaque diagnostic plus long, et donc plus coûteux. Si le défaut reste introuvable, on demande des précisions à l'utilisateur plutôt que de corriger à l'aveugle.

Étape 4 : rétablir le service, puis traiter la cause

Face à un bug bloquant, deux objectifs s'enchaînent et ne doivent pas être confondus :

  1. Rétablir le service au plus vite : contournement, retour à la version précédente, désactivation temporaire d'une fonction, correction manuelle des données touchées.
  2. Corriger la cause racine ensuite, à tête reposée : comprendre pourquoi le défaut est apparu et le supprimer durablement.

Cette logique reprend la distinction posée par ITIL entre la gestion des incidents (remettre en route) et la gestion des problèmes (éliminer la cause). Un correctif posé dans l'urgence sans analyse traite le symptôme ; le bug revient souvent sous une autre forme quelques semaines plus tard.

Pensez aussi aux données : un calcul faux pendant trois jours a pu produire des factures ou des commandes erronées. La correction du code ne règle pas ce passé, il faut identifier et rectifier les enregistrements concernés.

Étape 5 : tester et livrer le correctif proprement

Un correctif reste une modification du code, avec les mêmes risques qu'une évolution. Avant la mise en production :

  • vérifiez que le scénario signalé fonctionne désormais ;
  • relancez les tests de non-régression pour vous assurer que rien d'autre n'a cassé ;
  • ajoutez un test automatisé qui reproduit ce bug précis, pour qu'il ne puisse plus revenir sans être détecté ;
  • faites valider la correction par l'utilisateur qui a signalé le défaut.

La livraison suit le circuit habituel (version identifiée, sauvegarde préalable, possibilité de retour arrière), même pour un correctif d'une ligne. C'est souvent le correctif livré dans la précipitation, un vendredi soir, qui cause l'incident suivant.

Étape 6 : clôturer et tirer les leçons

Un ticket se clôture quand l'utilisateur confirme que tout fonctionne, pas quand le développeur a poussé son code. La clôture documente en quelques lignes la cause, la correction et les éventuelles données rectifiées.

Une fois par mois ou par trimestre, prenez dix minutes pour relire les tickets correctifs. Les tendances apparaissent vite : un module qui concentre les défauts, un connecteur fragile, une saisie mal contrôlée. Ces signaux nourrissent la maintenance préventive et les décisions de refonte partielle, bien plus utilement qu'une impression générale.

Les erreurs qui allongent les délais de correction

  • Signaler par téléphone ou dans un couloir : sans trace écrite, le bug se perd ou se déforme.
  • Tout classer en urgence : quand tout est prioritaire, plus rien ne l'est.
  • Corriger directement en production : rapide sur le moment, risqué ensuite.
  • Oublier les données : le code est juste, mais les enregistrements faussés restent en base.
  • Ne jamais analyser l'historique : les mêmes causes produisent les mêmes bugs.

Si votre application métier accumule les défauts récurrents ou si personne ne maîtrise plus son code, une démarche de reprise et modernisation peut remettre la maintenance sur des bases saines.

Questions fréquentes

Quelle est la différence entre maintenance corrective et maintenance évolutive ?

La maintenance corrective supprime un défaut : l'application ne fait pas ce qui était prévu. La maintenance évolutive ajoute ou modifie une fonction pour répondre à un nouveau besoin. La distinction compte pour les priorités, les délais et la facturation.

Comment bien signaler un bug à son prestataire ?

Décrivez ce qui s'est passé et ce qui était attendu, les étapes pour reproduire, la date, l'utilisateur concerné, une capture d'écran et l'impact sur l'activité. Passez toujours par un outil de tickets ou un formulaire, jamais uniquement par téléphone.

Faut-il corriger un bug bloquant directement en production ?

Non. On rétablit d'abord le service par un contournement ou un retour à la version précédente, puis on corrige sur un environnement de test avant de livrer. Corriger en direct sur la production crée souvent un second incident.

Pourquoi un bug corrigé réapparaît-il ?

Le plus souvent parce que seul le symptôme a été traité, sans analyse de la cause, ou parce qu'aucun test automatisé ne protège le scénario corrigé. Ajouter un test par bug corrigé limite fortement ces retours.

Combien de niveaux de gravité prévoir pour les bugs ?

Trois niveaux suffisent en PME : bloquant, majeur et mineur, définis en termes d'impact métier et de contournement possible. Au-delà, la qualification devient source de débats plutôt que d'efficacité.

Parlons de votre maintenance

Vos utilisateurs signalent des bugs sans savoir quand ils seront corrigés, ou les mêmes défauts reviennent sans cesse ? Pulsar Forge organise la maintenance corrective de vos applications métier, du formulaire de signalement au suivi des causes. Parlons de votre projet.