Maintenance applicative

Questions fréquentes

C'est quoi la maintenance applicative ?

La maintenance applicative regroupe toutes les interventions sur une application déjà en service : corriger ses bugs, faire évoluer ses fonctionnalités, l'adapter à un nouvel environnement et prévenir les pannes. Elle dure bien plus longtemps que le développement initial et occupe une grande partie du temps des développeurs. Au BTS SIO, elle correspond à la compétence « Assurer la maintenance corrective ou évolutive d'une solution applicative » du bloc 2 SLAM (les types de maintenance).

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

La maintenance corrective répare un défaut : l'application ne fait pas ce que prévoit sa spécification, comme un total faux ou une page qui plante. La maintenance évolutive ajoute ou modifie une fonctionnalité parce que le besoin a changé. Pour trancher, demande-toi si le comportement actuel respecte ce qui avait été demandé : si oui, c'est une évolution. La différence décide de l'urgence, de qui paie dans un contrat de TMA et du numéro de version : correctif (1.4.3) ou mineure (1.5.0).

Quels sont les quatre types de maintenance logicielle ?

La maintenance corrective (corriger un défaut constaté), évolutive (répondre à un nouveau besoin), adaptative (suivre un changement de l'environnement, comme une nouvelle version de PHP) et préventive (réduire un risque avant qu'il ne cause une panne). La norme ISO/IEC/IEEE 14764:2022 les croise selon deux axes (corriger ou améliorer, réagir ou anticiper) et découpe l'évolutive en deux : additive (ajouter une fonctionnalité) et perfective (améliorer l'existant) (le tableau de la norme).

C'est quoi un test de non-régression ?

Un test de non-régression vérifie qu'une modification n'a pas cassé ce qui fonctionnait déjà. En pratique, on garde tous les tests automatisés qui passaient et on les relance après chaque changement : si l'un échoue, il y a régression. En maintenance corrective, le test écrit pour reproduire un bug reste dans la suite et empêche ce bug de revenir (corriger un bug sans régression).

C'est quoi la dette technique ?

La dette technique est l'ensemble des raccourcis pris dans le code (conception bâclée, duplication, tests absents, dépendances jamais mises à jour) qui font gagner du temps sur le moment mais ralentissent chaque modification suivante. L'image vient de Ward Cunningham, en 1992 : une dette a des intérêts, le temps perdu à chaque intervention tant qu'on ne la rembourse pas. Elle se gère en la rendant visible dans des tickets, en remboursant d'abord celle des parties du code souvent modifiées, et par refactoring progressif (qualité et dette technique).

Qu'est-ce que le refactoring ?

Le refactoring est une modification de la structure interne d'un code qui ne change pas son comportement visible : renommer, extraire une fonction, remplacer un nombre magique par une constante, aplatir des conditions imbriquées. Il se fait par petites étapes, chacune vérifiée par les tests, et dans des commits séparés des corrections et des évolutions. Sur un code sans tests, on commence par écrire des tests de caractérisation qui figent son comportement actuel (refactoring et code smells).

Comment lire une stack trace ?

La première ligne donne le type d'erreur et son message, par exemple TypeError: Cannot read properties of undefined (reading 'length'). Les lignes suivantes listent les fonctions en cours, de la plus récente à la plus ancienne, avec le fichier et le numéro de ligne. Cherche la première ligne qui pointe vers ton propre code, et ignore celles de Node.js, de PHP ou des bibliothèques. Attention : la stack trace montre où l'erreur éclate, pas toujours où elle naît (lire une stack trace).

Comment déboguer avec VS Code ?

Pose un point d'arrêt en cliquant dans la marge à gauche d'une ligne, puis lance ton programme sous débogueur : pour Node.js, dans un « JavaScript Debug Terminal » ; pour PHP, avec l'extension PHP Debug et Xdebug configuré sur le port 9003. Quand l'exécution s'arrête, lis les variables, ajoute des espions et avance pas à pas avec F10 et F11. Les points d'arrêt conditionnels et les logpoints évitent de s'arrêter mille fois dans une boucle (déboguer avec VS Code).

Qu'est-ce que la rétro-conception ?

La rétro-conception (reverse engineering) consiste à reconstituer les modèles d'une application à partir de son code et de sa base de données : schéma relationnel et MCD à partir des tables et des clés étrangères, diagramme de classes à partir des classes, diagramme de séquence à partir du parcours d'une requête. Elle sert quand la documentation manque ou ne correspond plus au code, ce qui est fréquent quand on reprend une application (reprendre un code existant).

Comment la maintenance est-elle évaluée à l'E6 SLAM ?

L'expression des besoins remise par la commission demande presque toujours une correction ou une évolution sur l'une de tes réalisations, à faire en une heure, puis à prouver pendant la recette. La commission regarde cinq choses : la version et son changelog, la qualité, l'analyse et la correction du dysfonctionnement, la documentation mise à jour et les tests, dont la non-régression. Des commits clairs, un test rouge puis vert et une suite complète verte sont tes meilleures preuves (cas types E6).