Les types de maintenance logicielle

La maintenance logicielle désigne toutes les modifications apportées à une application après sa mise en service, pour corriger ses défauts, l'adapter à son environnement ou faire évoluer ses fonctionnalités. On distingue en général quatre types : la maintenance corrective, évolutive, adaptative et préventive. Ce chapitre les définit avec des exemples, donne le vocabulaire qui va avec (bug, anomalie, incident, problème) et décrit le cycle d'une demande de maintenance, du ticket à la livraison.

Ce qu'on appelle maintenance applicative

Une application ne s'arrête pas le jour de sa livraison. Ses utilisateurs découvrent des bugs que les tests n'avaient pas vus. Ils demandent de nouvelles fonctions. Le système d'exploitation, le langage, les bibliothèques et les navigateurs évoluent sous elle. Les règles de l'entreprise changent. Tout ce travail sur une application en production, c'est la maintenance applicative.

Elle dure bien plus longtemps que le développement initial. Sorbier Frais a été écrite en quelques mois ; elle sera utilisée et modifiée pendant des années, souvent par des personnes qui ne l'ont pas écrite. C'est pour cette raison que la lisibilité du code, les tests et la documentation comptent autant : ils servent surtout à ceux qui viendront après.

Le mot « maintenance » vient de l'industrie, où l'on maintient des machines. La différence est de taille : un logiciel ne s'use pas. Un programme qui calculait juste hier calcule juste aujourd'hui, à environnement égal. S'il se met à mal fonctionner, c'est qu'il contenait déjà un défaut qu'une nouvelle situation a révélé, ou que son environnement a changé.

Les quatre types de maintenance

La maintenance corrective répare un défaut. Tout commence par un écart entre ce que fait l'application et ce qu'elle devrait faire : un calcul faux, une page blanche, un bouton sans effet. Elle se décline selon l'urgence. Un correctif urgent (hotfix) part tout de suite en production quand l'application est bloquée pour beaucoup d'utilisateurs : connexion impossible, paiement refusé. Un correctif planifié attend la prochaine version quand le bug est rare ou contournable. Entre les deux, on livre parfois une solution de contournement (on dit aussi maintenance palliative) : on indique aux utilisateurs comment éviter le bug en attendant la vraie correction.

La maintenance évolutive ajoute une fonctionnalité ou modifie une fonctionnalité existante parce que le besoin a changé. La norme internationale ISO/IEC/IEEE 14764 (édition 2022) la découpe en deux : maintenance additive quand on ajoute une fonctionnalité, perfective quand on améliore ce qui existe (ergonomie, performances, maintenabilité). La frontière avec la corrective se trace avec une question simple : est-ce que le comportement actuel respecte ce qui avait été demandé ? Si oui, la demande est une évolution, même si l'utilisateur la présente comme un bug.

La maintenance adaptative garde l'application en état de marche quand son environnement change : nouvelle version de PHP ou de Node.js, mise à jour majeure d'un framework, nouveau navigateur, migration vers un autre serveur ou vers le cloud, API d'un partenaire qui change de format. L'utilisateur ne voit pas de nouvelle fonction ; il voit une application qui continue de fonctionner. Certains auteurs rangent aussi dans cette catégorie les adaptations à une nouvelle réglementation, comme un nouveau taux ou une nouvelle mention obligatoire sur une facture.

La maintenance préventive agit avant la panne. Elle regroupe la mise à jour d'une dépendance avant la fin de sa maintenance, la correction d'un défaut repéré en revue de code avant qu'un utilisateur ne le rencontre, l'ajout de tests sur une partie fragile, le refactoring d'un module que personne n'ose plus toucher, la surveillance de l'espace disque ou des temps de réponse. C'est la plus facile à repousser, et c'est souvent elle qui évite les nuits blanches.

Les classements que tu croiseras

Selon les sources, tu trouveras trois, quatre ou cinq types. Ne t'en inquiète pas : ce sont les mêmes idées découpées autrement.

La norme ISO/IEC/IEEE 14764:2022, consacrée à la maintenance du logiciel, distingue cinq types selon deux questions : la modification corrige-t-elle un défaut ou améliore-t-elle le logiciel ? Est-elle réactive (on répond à un problème constaté) ou proactive (on anticipe) ? Côté correction : la corrective (réactive) et la préventive (proactive). Côté amélioration : l'adaptative (réactive), l'additive, qui ajoute une fonctionnalité, et la perfective, qui améliore l'existant (toutes deux proactives). La norme définit aussi la maintenance d'urgence : une modification non planifiée qui garde provisoirement le système en service en attendant la correction.

En France, on parle plus volontiers de maintenance évolutive que d'additive ou de perfective, et beaucoup d'entreprises ne gardent que deux catégories dans leurs contrats : la corrective (le prestataire répare à ses frais ce qui ne marche pas) et l'évolutive (le client paie ce qu'il demande en plus). L'adaptative et la préventive sont alors facturées comme des évolutions.

Dans l'industrie, on distingue aussi la maintenance palliative (un dépannage provisoire) de la maintenance curative (une réparation définitive). Le vocabulaire passe parfois au logiciel : un contournement est palliatif, un correctif est curatif. La norme ISO/IEC/IEEE 14764 parle, elle, de maintenance d'urgence pour la modification provisoire.

Bug, anomalie, incident, problème : le vocabulaire

Les mots se mélangent dans les tickets. Ils ne veulent pas dire la même chose, et une commission d'examen apprécie que tu les emploies juste.

Une anomalie n'est donc pas forcément un bug : après analyse, elle peut se révéler un malentendu (l'application fait ce qui était prévu), une demande d'évolution déguisée ou un incident d'exploitation (le serveur de base de données est arrêté). Le chapitre Reproduire un bug montre comment trancher. Côté support, la gestion des incidents, des problèmes et des changements est décrite dans le cours ITIL et support.

Qui fait la maintenance, et comment elle s'organise

Dans une petite structure, la personne qui a développé l'application la maintient aussi. Dans une plus grande, la maintenance s'organise en niveaux.

• Le support de niveau 1 reçoit les demandes des utilisateurs, crée les tickets, répond aux questions d'usage et applique les contournements connus.
• Le niveau 2 analyse les cas plus techniques : configuration, droits, données.
• Le niveau 3, c'est l'équipe de développement : elle corrige le code, développe les évolutions et livre les nouvelles versions. La maintenance applicative se joue surtout là.

Beaucoup d'organisations confient leurs applications à un prestataire, en tierce maintenance applicative (TMA). Le contrat fixe ce qui est couvert (corrective, évolutive, adaptative), les délais d'intervention et de résolution selon la gravité, les indicateurs suivis et les conditions de livraison. Le cours ITIL et support détaille ces engagements de service, avec la garantie de temps d'intervention (GTI) et la garantie de temps de rétablissement (GTR).

Que tu travailles seul ou dans une grande équipe, tu suis le même outil : un gestionnaire de tickets (GLPI, Jira, les issues de GitHub ou de GitLab, Redmine). Chaque demande y a un numéro, un type, une priorité, un état et un historique. Ce numéro te suivra jusque dans tes commits et ton changelog.

Le cycle d'une demande de maintenance

Corrective ou évolutive, une demande suit toujours les mêmes étapes. Ce qui change, c'est le poids de chacune.

1. Réception. La demande arrive par le support, un formulaire ou un message. Elle reçoit un numéro.
2. Qualification. Tu vérifies que tu as compris, tu classes la demande (corrective, évolutive, adaptative, préventive), tu estimes sa gravité et sa priorité. Une demande floue repart vers son auteur avec des questions.
3. Analyse. Pour un bug, tu le reproduis et tu cherches sa cause. Pour une évolution, tu mènes une analyse d'impact : quelles tables, quels fichiers, quels écrans, quels tests, quelle documentation seront touchés ?
4. Réalisation. Sur une branche dédiée (fix/231-total-note, feat/250-refus-ligne), tu écris d'abord le test qui décrit le comportement attendu, puis le code.
5. Tests. Le nouveau test passe, et toute la suite existante aussi : c'est la non-régression. Si quelque chose casse, retour à l'étape 4.
6. Livraison. Le changement est relu (pull request), fusionné, livré dans une version numérotée, inscrit au changelog. La documentation suit.
7. Clôture. Tu fermes le ticket avec la cause, la correction et la version qui la contient, et tu préviens le demandeur.

Pourquoi la distinction entre corrective et évolutive compte

Classer une demande n'est pas une formalité. Le type décide de plusieurs choses concrètes.

Une demande mal classée coûte cher dans les deux sens. Traiter une évolution comme un bug, c'est la livrer sans spécification ni validation, en urgence, aux frais de l'équipe. Traiter un vrai bug comme une évolution, c'est laisser les utilisateurs avec un calcul faux en attendant un devis.

La maintenance dans le référentiel du BTS SIO

Le référentiel du BTS SIO range la compétence « Assurer la maintenance corrective ou évolutive d'une solution applicative » dans le bloc 2 de l'option SLAM, avec « Concevoir et développer une solution applicative » et « Gérer les données ». Elle se décompose en cinq sous-compétences, que ce cours traite une par une :

À l'épreuve E6 SLAM, la commission te remet une expression des besoins sur l'une de tes deux réalisations : une correction ou une évolution à apporter en une heure. C'est exactement cette compétence. Le dernier chapitre de ce cours en fait la synthèse, et le cours Épreuve E6 SLAM détaille les indicateurs officiels de chaque sous-compétence.

Exercices

Exercice 1 sur 3 Classer des demandes Réussi À revoir

Voici dix demandes reçues par l'équipe de Sorbier. Pour chacune, donne le type de maintenance (corrective, évolutive, adaptative ou préventive).

1. « L'export CSV des notes plante dès qu'un libellé contient un point-virgule. »
2. « Pouvez-vous ajouter un filtre par service dans la liste des notes ? »
3. L'hébergeur annonce l'arrêt de PHP 8.2 sur ses serveurs mutualisés : Sorbier Véhicules doit passer en PHP 8.4.
4. En relisant le code, une développeuse remarque qu'une requête construit son SQL en concaténant une saisie de l'utilisateur, ce qui la rend vulnérable à une injection. Aucun incident n'a été signalé.
5. « Le planning des véhicules s'affiche mal sur le nouveau navigateur de nos tablettes. »
6. « Je voudrais recevoir un mail quand ma note est validée. »
7. Le disque du serveur de base de données est rempli à 85 % ; on met en place une alerte et une purge des journaux de plus d'un an.
8. « Une réservation de 14 h à 16 h est refusée alors que le véhicule est rendu à 14 h. »
9. L'entreprise change son plafond de remboursement des repas, de 20 € à 22 €.
10. Une fonction de 300 lignes que personne n'ose plus modifier est découpée en fonctions testées, sans changer son résultat.

Voir la réponseMasquer la réponse de l'exercice 1

1. Corrective. L'export doit fonctionner quel que soit le libellé : c'est un défaut (le champ n'est pas protégé par des guillemets).
2. Évolutive. Une nouvelle fonction.
3. Adaptative. L'environnement change, le comportement doit rester le même.
4. Préventive, et urgente : le défaut existe mais n'a pas encore causé d'incident. On peut aussi la classer corrective, puisque le code ne respecte pas une exigence de sécurité ; l'important est de la traiter vite.
5. Adaptative. Le navigateur a changé, pas le besoin. Si l'affichage était déjà faux sur les navigateurs prévus, ce serait une corrective.
6. Évolutive.
7. Préventive. Rien n'est encore en panne.
8. Corrective, si la règle est qu'un véhicule rendu à 14 h est disponible à 14 h. C'est le bug de chevauchement traité au chapitre 11.
9. Évolutive pour beaucoup d'entreprises, adaptative pour ceux qui y voient un changement réglementaire de l'environnement. Dans les deux cas, c'est une modification planifiée, pas un bug. Si le plafond était une constante bien nommée, elle se fait en une ligne.
10. Préventive. C'est un refactoring : le comportement ne change pas, le risque de la prochaine modification baisse. Dans la norme ISO, ce refactoring relève de la maintenance perfective (améliorer la maintenabilité) ; en France, on le range souvent dans la préventive.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 3 Le bon mot Réussi À revoir

Complète chaque phrase avec le terme juste : défaut, défaillance, incident, problème, régression, anomalie.

1. Depuis la version 1.3, l'export CSV, qui fonctionnait, sort vide : c'est une …
2. Un salarié signale « mon total est bizarre », sans plus de détails : c'est une … à analyser.
3. Plus personne ne peut se connecter à Sorbier Frais depuis 9 h : le support ouvre un …
4. Trois incidents de ce type en un mois : l'équipe ouvre un … pour en trouver la cause.
5. L'opérateur + concatène deux chaînes au lieu d'additionner deux nombres : c'est le … dans le code.
6. Le total affiché 012.5019.90 est la … visible par l'utilisateur.

Voir la réponseMasquer la réponse de l'exercice 2

1. Régression. 2. Anomalie. 3. Incident. 4. Problème. 5. Défaut (ou bug). 6. Défaillance.

La chaîne complète se lit dans l'ordre inverse : un défaut dans le code provoque une défaillance, que l'utilisateur signale comme une anomalie ; si le service est touché, c'est un incident, et la recherche de sa cause est un problème.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 3 Un plan de maintenance préventive Réussi À revoir

Sorbier Véhicules tourne depuis quatre ans : PHP 8.2, une dizaine de dépendances Composer jamais mises à jour, aucun test automatisé, un seul développeur qui part à la retraite dans six mois. Propose quatre actions de maintenance préventive, par ordre de priorité, en justifiant l'ordre.

Voir la réponseMasquer la réponse de l'exercice 3

Une proposition raisonnable :

1. Faire documenter l'application par le développeur qui part (installation, déploiement, architecture, pièges connus). C'est le risque le plus urgent : dans six mois, cette connaissance disparaît, et rien ne la remplace.
2. Auditer les dépendances avec composer audit et corriger les failles connues (chapitre 9). Une dépendance vulnérable exposée sur le Web est un risque immédiat.
3. Écrire des tests sur les calculs et les règles critiques (disponibilité d'un véhicule, chevauchement des réservations). Ils sécuriseront toutes les modifications suivantes, à commencer par la migration de PHP.
4. Passer en PHP 8.4, avant la fin du support de sécurité de PHP 8.2, une fois les tests en place.

D'autres ordres se défendent, à condition de les justifier par le risque et par les dépendances entre actions : migrer PHP sans tests, c'est migrer à l'aveugle.

Tu avais trouvé ?

Oui, j'avais bonPas encore