Matrice : Maintenance applicative

Comment le produit installé est maintenu : anomalies, correctifs, versions, dette technique, compatibilité, composants tiers, connaissance, fin de vie.

≈ 12 min de lectureLecture

En bref

8 dimensions, niveaux 0 à 5, 112 critères.
Outil : état des lieux en choisissant « Maintenance applicative ».
Niveaux et critères : synthèse originale, références citées en bas de page.

Sur cette page

Vue d'ensemble
Corrections et versions
Dette et compatibilité
Connaissance et vie du produit
1. Connaissance et documentation technique
2. Fin de vie et retrait
Sources et vérification

Périmètre

La vie du produit installé : traitement des anomalies, correctifs et versions maintenues, numérotation et notes de version, dette technique, compatibilité et montées de version, composants et bibliothèques tiers, connaissance et documentation technique, fin de vie. La planification des évolutions relève du thème « Gestion de projet », l'acheminement vers la production du thème « Déploiements ».

8 dimensions, six niveaux (0 à 5) et 112 critères observables. Pour situer votre produit : ouvrir l'état des lieux de ce thème. Les règles de calcul sont ici.

Vue d'ensemble#

Chaque cellule est la signature du niveau pour la dimension.

Dimension	0 · Artisanal	1 · Local outillé	2 · Partagé	3 · Industrialisé	4 · Intégré et gouverné	5 · Autonome
Gestion des anomalies	Les anomalies sont corrigées au gré des demandes, sans trace.	Anomalies enregistrées.	Tri et gravité.	Circuit complet.	Anomalies analysées.	Anomalies prévenues.
Correctifs et versions supportées	Un seul état du produit : le correctif est appliqué sur ce qui existe.	Versions identifiées.	Versions maintenues.	Correctifs maîtrisés.	Correctifs suivis.	Correctifs automatisés.
Numérotation et notes de version	Versions nommées par date ou par habitude, sans règle.	Numérotation simple.	Numérotation significative.	Notes utiles.	Notes produites à partir du travail.	Communication de version automatisée.
Dette technique	La dette s'accumule sans que personne la voie.	Dette perçue.	Dette listée.	Dette arbitrée.	Dette mesurée.	Dette maîtrisée.
Compatibilité et montées de version	Chaque montée de version est une aventure.	Montées documentées.	Montées vérifiées.	Chemins de migration.	Compatibilité gérée.	Montées sans friction.
Composants et bibliothèques tiers	Les composants tiers sont ceux qu'un développeur a installés un jour.	Composants listés.	Composants suivis.	Mises à jour planifiées.	Chaîne maîtrisée.	Dépendances surveillées.
Connaissance et documentation technique	Le fonctionnement du produit est connu d'une personne.	Notes personnelles.	Documentation technique.	Documentation tenue.	Documentation générée et vérifiée.	Connaissance accessible.
Fin de vie et retrait	Une fonction disparaît parce qu'elle a cassé et que personne ne la répare.	Retraits décidés.	Retraits annoncés.	Politique de support.	Retrait accompagné.	Cycle de vie piloté.

Lien avec le modèle global

Dimensions du modèle global les plus concernées : Tests et corrections, Industrialisation et déploiement, Documentation et traçabilité et Pilotage projet et roadmap.

Corrections et versions#

Gestion des anomalies#

Comment une anomalie est-elle reçue, qualifiée, corrigée et suivie ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Les anomalies sont corrigées au gré des demandes, sans trace.	Point de départ : aucun critère.
1 · Local outillé	Anomalies enregistrées.	Chaque anomalie est enregistrée dans un outil, avec une description. Une personne est affectée à chaque anomalie.
2 · Partagé	Tri et gravité.	Chaque anomalie est qualifiée : gravité, produit et version concernés, comment la reproduire. Le délai de correction attendu dépend de la gravité. La personne qui a signalé l'anomalie est informée de sa correction.
3 · Industrialisé	Circuit complet.	Chaque anomalie corrigée est vérifiée par une autre personne que l'auteur de la correction. Un test automatique qui reproduit l'anomalie est ajouté avec la correction. Les anomalies sont reliées aux versions dans lesquelles elles sont corrigées.
4 · Intégré et gouverné	Anomalies analysées.	Le stock d'anomalies ouvertes et leur ancienneté sont suivis. Les causes (spécification, code, données, environnement) sont analysées pour agir sur les plus fréquentes. Les anomalies sont traitées dans les délais annoncés pour chaque gravité, et les écarts sont suivis.
5 · Autonome	Anomalies prévenues.	Une anomalie corrigée déclenche la recherche automatique de sa jumelle ailleurs dans le code. Les anomalies détectées en production sont rattachées automatiquement au changement qui les a causées. Le nombre d'anomalies par version diminue, et cela est suivi.

Effet sur l'utilisateur

Un défaut signalé a un numéro, un responsable et un délai ; on sait où il en est.

Correctifs et versions supportées#

Quelles versions sont maintenues, et comment un correctif y est-il apporté ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Un seul état du produit : le correctif est appliqué sur ce qui existe.	Point de départ : aucun critère.
1 · Local outillé	Versions identifiées.	Chaque installation connaît sa version. Les versions livrées sont conservées.
2 · Partagé	Versions maintenues.	La liste des versions supportées est définie. Un correctif peut être appliqué sur une version supportée sans y apporter des évolutions. Une correction faite sur une version est reportée sur les autres versions concernées.
3 · Industrialisé	Correctifs maîtrisés.	Les correctifs sont livrés sous forme de versions numérotées et testées. Un correctif urgent suit un circuit raccourci, mais garde les tests essentiels. Le report d'un correctif sur toutes les versions supportées est vérifié.
4 · Intégré et gouverné	Correctifs suivis.	Les versions installées chez chaque client sont connues, avec les correctifs qui leur manquent. Le temps entre la correction et son application chez le client est mesuré. Un correctif peut être installé à chaud ou avec une interruption minimale.
5 · Autonome	Correctifs automatisés.	Les correctifs sont proposés et appliqués automatiquement aux installations qui les acceptent. Un correctif défaillant est retiré automatiquement. L'état de correction de l'ensemble des installations est visible sur un tableau de bord.

Effet sur l'utilisateur

Un client sur une version supportée reçoit son correctif sans devoir changer de version.

Numérotation et notes de version#

Les versions sont-elles numérotées de façon significative et accompagnées d'explications claires ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Versions nommées par date ou par habitude, sans règle.	Point de départ : aucun critère.
1 · Local outillé	Numérotation simple.	Chaque version a un numéro unique. Un livrable ne change plus une fois publié sous un numéro.
2 · Partagé	Numérotation significative.	La numérotation distingue les changements incompatibles, les ajouts compatibles et les corrections (par exemple version majeure, mineure, correctif). Chaque version a des notes de version. Les notes listent les changements visibles, les corrections et les points d'attention.
3 · Industrialisé	Notes utiles.	Les notes de version sont rédigées pour les utilisateurs et pour les administrateurs séparément. Les changements incompatibles sont signalés en tête, avec la marche à suivre. Les notes sont conservées pour toutes les versions publiées.
4 · Intégré et gouverné	Notes produites à partir du travail.	Les notes de version sont générées en grande partie à partir des demandes et des corrections livrées. Le numéro de version est calculé par des règles, et non choisi à la main. Un historique des changements est consultable par fonction et par date.
5 · Autonome	Communication de version automatisée.	Les clients concernés sont prévenus automatiquement d'une nouvelle version selon son effet pour eux. La nature d'une version (incompatible, compatible) est vérifiée automatiquement par comparaison avec la précédente. Les questions des clients sur une version enrichissent les notes suivantes.

Effet sur l'utilisateur

Le numéro d'une version dit s'il y a un risque à l'installer, et les notes disent ce qui change.

Dette et compatibilité#

Dette technique#

Sait-on où sont les raccourcis pris, ce qu'ils coûtent, et quand les rembourser ?

Niveau	Signature	Critères à réunir
0 · Artisanal	La dette s'accumule sans que personne la voie.	Point de départ : aucun critère.
1 · Local outillé	Dette perçue.	Les zones du code que l'équipe évite de toucher sont connues. Les raccourcis délibérés sont signalés au moment où ils sont pris.
2 · Partagé	Dette listée.	La dette technique est inscrite dans le backlog, avec une description de son effet. Chaque élément de dette a une estimation de son coût de remboursement. Un raccourci pris sous contrainte est consigné avec sa date de remboursement prévue.
3 · Industrialisé	Dette arbitrée.	Une part du temps de chaque période est réservée au remboursement de la dette. La dette est remboursée en priorité là où le code est le plus souvent modifié. Les nouveaux raccourcis sont examinés en revue avant d'être acceptés.
4 · Intégré et gouverné	Dette mesurée.	Des mesures (complexité, duplication, couverture de tests, ancienneté des composants) sont suivies dans le temps. Le coût de la dette est estimé en temps perdu et en incidents. La dette fait partie des critères de décision pour une nouvelle fonction.
5 · Autonome	Dette maîtrisée.	Un seuil de dette est fixé, et son dépassement arrête les nouvelles fonctions. Les contrôles automatiques empêchent d'introduire certains types de dette. La dette diminue d'une période à l'autre, et c'est suivi.

Effet sur l'utilisateur

Le produit reste facile à faire évoluer, et la vitesse n'est pas gagnée à crédit sans qu'on le sache.

Compatibilité et montées de version#

Passer d'une version à une autre est-il prévisible, testé et réversible ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Chaque montée de version est une aventure.	Point de départ : aucun critère.
1 · Local outillé	Montées documentées.	Une procédure de montée de version est écrite. Les sauvegardes avant montée sont prévues.
2 · Partagé	Montées vérifiées.	La montée d'une version à la suivante est testée sur une copie de données réelles. Les données et personnalisations existantes sont conservées par la montée. Un contrôle après montée vérifie les éléments essentiels.
3 · Industrialisé	Chemins de migration.	Les chemins de montée entre versions supportées sont définis et testés. Les changements de structure de données sont appliqués par des scripts rejouables. Un retour à la version précédente est prévu et testé.
4 · Intégré et gouverné	Compatibilité gérée.	Les changements incompatibles passent par une période où l'ancien et le nouveau coexistent (ajout, migration, retrait). La compatibilité avec les rapports et les extensions des clients est vérifiée avant chaque version. Le temps d'interruption d'une montée est mesuré et réduit.
5 · Autonome	Montées sans friction.	Les montées s'effectuent automatiquement, sans interruption notable, avec retour automatique en cas d'échec. La compatibilité est vérifiée automatiquement pour chaque configuration cliente connue. Les clients choisissent la date de leur montée dans une plage définie.

Effet sur l'utilisateur

Une montée de version ne fait rien perdre : ni donnée, ni personnalisation, ni rapport.

Composants et bibliothèques tiers#

Les composants utilisés sont-ils connus, à jour et sans vulnérabilité connue ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Les composants tiers sont ceux qu'un développeur a installés un jour.	Point de départ : aucun critère.
1 · Local outillé	Composants listés.	La liste des composants tiers utilisés est connue. La version de chaque composant est notée.
2 · Partagé	Composants suivis.	La liste des composants est tenue dans un fichier géré avec le code. Les composants abandonnés ou en fin de support sont repérés. La licence de chaque composant est connue et compatible avec l'usage.
3 · Industrialisé	Mises à jour planifiées.	Les composants sont mis à jour à intervalle défini, avec les tests de non-régression. Les vulnérabilités connues des composants sont recherchées par un outil. Une vulnérabilité grave suit un circuit de correction rapide.
4 · Intégré et gouverné	Chaîne maîtrisée.	Les composants sont téléchargés depuis des sources approuvées. La liste complète des composants de chaque version livrée est conservée. Un composant critique a une solution de remplacement identifiée.
5 · Autonome	Dépendances surveillées.	Les mises à jour de sécurité sont proposées et testées automatiquement. Les clients sont informés automatiquement lorsqu'une vulnérabilité touche leur version. L'âge moyen des composants est suivi comme un indicateur.

Effet sur l'utilisateur

Une faille publiée dans un composant est repérée et corrigée avant qu'elle ne devienne un incident.

Connaissance et vie du produit#

Connaissance et documentation technique#

La connaissance du produit dépend-elle de quelques personnes, ou est-elle partagée et écrite ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Le fonctionnement du produit est connu d'une personne.	Point de départ : aucun critère.
1 · Local outillé	Notes personnelles.	Des notes techniques existent sur les parties critiques. Les personnes qui connaissent chaque partie sont identifiées.
2 · Partagé	Documentation technique.	L'architecture générale et les dépendances sont décrites dans un document partagé. Chaque composant important a au moins deux personnes capables d'intervenir. Les procédures d'exploitation et de correction sont écrites.
3 · Industrialisé	Documentation tenue.	La documentation technique est stockée avec le code et mise à jour avec lui. Les décisions d'architecture sont consignées avec leur motif. Une personne qui arrive sur le produit peut le construire et l'exécuter en suivant la documentation.
4 · Intégré et gouverné	Documentation générée et vérifiée.	Une partie de la documentation (objets, dépendances, schémas) est générée à partir du code et des métadonnées. Une documentation périmée est détectée à la revue de chaque changement. La répartition des connaissances est suivie pour repérer les composants maîtrisés par trop peu de personnes.
5 · Autonome	Connaissance accessible.	La documentation est interrogeable par un assistant qui s'appuie sur elle. Les questions posées à l'équipe améliorent automatiquement la documentation. La connaissance est transmise par un parcours d'intégration éprouvé.

Effet sur l'utilisateur

Le départ d'une personne ne bloque ni une correction ni une évolution.

Fin de vie et retrait#

Comment retire-t-on une fonction, une version ou un produit sans surprise pour les utilisateurs ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Une fonction disparaît parce qu'elle a cassé et que personne ne la répare.	Point de départ : aucun critère.
1 · Local outillé	Retraits décidés.	Les décisions de retrait sont prises explicitement. Les utilisateurs de la fonction retirée sont recherchés.
2 · Partagé	Retraits annoncés.	Un retrait est annoncé avec un préavis et une date. Une alternative ou une marche à suivre est proposée. La fonction retirée est signalée comme obsolète pendant le préavis.
3 · Industrialisé	Politique de support.	Une politique écrite définit la durée de support de chaque version. La date de fin de support de chaque version est communiquée dès sa publication. L'usage des fonctions en cours de retrait est mesuré pour adapter le préavis.
4 · Intégré et gouverné	Retrait accompagné.	Les clients utilisant une version en fin de support sont contactés avec un plan de migration. Les données des fonctions retirées sont conservées ou exportées selon une règle définie. Le code et les données obsolètes sont réellement supprimés après la période prévue.
5 · Autonome	Cycle de vie piloté.	Les fonctions peu utilisées sont repérées automatiquement et proposées au retrait. Les migrations vers les alternatives sont outillées pour les cas courants. Le coût de maintien de chaque fonction est connu et alimente les décisions de retrait.

Effet sur l'utilisateur

Un retrait est annoncé, expliqué et accompagné ; personne ne découvre qu'une fonction a disparu.

Origine des critères

Les dimensions s'inspirent des références citées ci-dessous ; les niveaux et les critères sont une synthèse originale, pas une reprise d'un référentiel. Ils sont proposés pour être discutés et adaptés, pas pour faire foi.

Sources et vérification#

Martin Fowler — Technical Debt — dette technique : « intérêts » (effort supplémentaire sur chaque évolution) et « principal » (le remboursement) ; rembourser d'abord le code souvent modifié
Semantic Versioning 2.0.0 (version française) — numéro MAJEUR.MINEUR.CORRECTIF ; une version publiée ne doit plus être modifiée
Martin Fowler — Parallel Change — élargir (ancien et nouveau coexistent), migrer, puis retirer ; valable aussi pour l'évolution d'un schéma de base de données
DORA — Software delivery performance metrics — temps de rétablissement après un déploiement défaillant, taux d'échec des changements
ISO/IEC 25010:2023 — Product quality model (SQuaRE) — la maintenabilité parmi les caractéristiques de qualité d'un produit logiciel ; seul le nombre de caractéristiques (neuf) a été vérifié, la norme est payante