Quand la maintenance doit-elle conduire à revoir l'architecture d'un produit ?
D’après Gestion de projets avec DYNAMAP SI
Réanalyser l’existant quand la maintenance révèle une fragilité structurelle (DYNAMAP SI 1)
Lorsqu’un produit entre en spirale d’incidents, lorsque la dette devient systémique, ou lorsque des obsolescences rendent chaque changement dangereux, il faut parfois sortir du flux et reconstituer une vision factuelle.
DYNAMAP SI cadre cette analyse : recueil de données existantes, analyse technologies/process, sessions de feedback, mise à jour continue, rapport d’analyse et recommandations, puis planification des initiatives.
Application maintenance : c’est le mécanisme qui permet d’identifier si l’on est face à un « problème de tickets » ou à un « problème d’architecture / d’exploitation / de gouvernance ».
Sorties minimales attendues (et critères de qualité)
1. Tableau de bord de maintenance (DYNAMAP SI 7)Qualité attendue : indicateurs définis (formule, source, fréquence), seuils, responsables, et rituels de revue. La présence de validation/itération et de mise à jour continue est déterminante pour éviter un tableau de bord figé.
2. Pack de cartographies versionné (DYNAMAP SI 3)Qualité attendue : validé, publié, mis à jour régulièrement, et mobilisable pour analyser impacts et risques.
3. Backlog de maintenance gouvernée + règles d’arbitrage (DYNAMAP SI 4 + 6)Qualité attendue : priorisation conjointe, allocation de capacité explicite, et alignement sur objectifs et roadmap.
4. Journal d’étonnements et décisions (DYNAMAP SI 2 + 5)Qualité attendue : chaque étonnement se conclut par une décision et une action, les ajustements sont suivis et leurs effets mesurés.
5. Plan d’amélioration structurelle lorsque nécessaire (DYNAMAP SI 1)Qualité attendue : rapport d’analyse argumenté et initiatives de remédiation planifiées, plutôt qu’une accumulation de correctifs isolés.
