6 min lecture • Guide 507 of 877
Comment Gérer les Projets de Maintenance de Systèmes Legacy
Les systèmes legacy nécessitent une maintenance continue pendant que les équipes planifient simultanément des efforts de modernisation. GitScrum aide les organisations à équilibrer ces demandes concurrentes en fournissant des boards séparés pour la maintenance et la modernisation, des frameworks de priorisation clairs et un suivi garantissant que les mises à jour critiques ne se perdent pas au milieu du développement de fonctionnalités.
Catégories de Systèmes Legacy
| Type | Caractéristiques | Stratégie |
|---|---|---|
| Critique stable | Essentiel au business, change rarement | Maintenir soigneusement |
| Critique instable | Essentiel au business, problèmes fréquents | Prioriser modernisation |
| Non-critique stable | Fonctionne bien, pas stratégique | Maintenir au minimum |
| Non-critique instable | Cause des douleurs, pas essentiel | Considérer retrait |
Framework de Maintenance Legacy
APPROCHE GESTION SYSTÈME LEGACY
1. ÉVALUATION
┌─────────────────────────────────────────────────┐
│ Pour chaque système legacy: │
│ ├── Criticité business (1-5) │
│ ├── Santé technique (1-5) │
│ ├── Coût maintenance (€/mois) │
│ ├── Disponibilité experts │
│ ├── Niveau risque sécurité │
│ └── Dépendances intégration │
│ │
│ Output: Inventaire systèmes legacy │
└─────────────────────────────────────────────────┘
2. CLASSIFICATION
┌─────────────────────────────────────────────────┐
│ │
│ Haute Criticité │
│ │ │
│ ┌──────────┼──────────┐ │
│ │ INVESTIR │MODERNISER│ │
│ │ (stable) │ (urgent) │ │
│ │ │ │ │
│ ├──────────┼──────────┤ │
│ │ MAINTENIR│ RETIRER │ │
│ │ (minimal)│ (planif.)│ │
│ └──────────┴──────────┘ │
│ Bonne Santé │ Mauvaise Santé │
│ │
└─────────────────────────────────────────────────┘
3. ALLOCATION RESSOURCES
┌─────────────────────────────────────────────────┐
│ Allocation capacité équipe: │
│ ├── Nouveau développement: 60-70% │
│ ├── Maintenance legacy: 20-30% │
│ └── Projets modernisation: 10-20% │
│ │
│ Ajuster selon stabilité système │
└─────────────────────────────────────────────────┘
Gestion des Tâches Legacy
TRAVAIL LEGACY DANS GITSCRUM
STRUCTURE PROJET:
┌─────────────────────────────────────────────────┐
│ Projet: Maintenance Systèmes Legacy │
│ │
│ Labels: │
│ ├── [legacy-critique] - Problèmes production │
│ ├── [legacy-sécurité] - Patches sécurité │
│ ├── [legacy-dette-tech] - Travail amélioration │
│ └── [legacy-documentation] - Capture savoir │
│ │
│ Colonnes Board: │
│ ├── Entrant - Nouvelles demandes/problèmes │
│ ├── Trié - Priorisé, planifié │
│ ├── En Cours - Travail actif │
│ ├── Revue - Revue code/tests │
│ └── Terminé - Complété │
└─────────────────────────────────────────────────┘
TEMPLATE TÂCHE:
┌─────────────────────────────────────────────────┐
│ Titre: [Nom Système] - Description Problème │
│ │
│ Système: Traitement Commandes (COBOL) │
│ Criticité: Haute │
│ Type: Correction Bug / Amélioration / Sécurité │
│ │
│ Contexte: │
│ Quel est le comportement actuel ? │
│ Que devrait-il se passer à la place ? │
│ Impact business si non traité ? │
│ │
│ Notes Techniques: │
│ Modules/fichiers pertinents │
│ Experts connus: @jean, @marie │
│ Dépendances avec autres systèmes │
│ │
│ Test: │
│ Comment vérifier la correction │
│ Préoccupations régression │
└─────────────────────────────────────────────────┘
Préservation des Connaissances
GESTION CONNAISSANCES LEGACY
EXIGENCES DOCUMENTATION:
┌─────────────────────────────────────────────────┐
│ Pour chaque système legacy: │
│ │
│ Documentation Essentielle: │
│ ☐ Vue d'ensemble et objectif système │
│ ☐ Diagramme architecture │
│ ☐ Flux données et intégrations │
│ ☐ Procédures déploiement │
│ ☐ Problèmes courants et résolutions │
│ ☐ Liste contacts (internes et fournisseurs) │
│ │
│ Pour Chaque Changement: │
│ ☐ Ce qui a changé et pourquoi │
│ ☐ Comment tester le changement │
│ ☐ Procédure rollback │
│ ☐ MAJ runbook si nécessaire │
└─────────────────────────────────────────────────┘
PRATIQUES TRANSFERT CONNAISSANCES:
┌─────────────────────────────────────────────────┐
│ • Pair programming sur changements legacy │
│ • Walkthroughs enregistrés systèmes critiques │
│ • Rotation astreinte pour exposition legacy │
│ • Revues documentation après chaque changement │
│ • Sessions cross-training trimestrielles │
└─────────────────────────────────────────────────┘
Framework Décision Modernisation
DÉCISION MODERNISER VS MAINTENIR
Calculer annuellement:
COÛT MAINTENANCE:
┌─────────────────────────────────────────────────┐
│ Temps développeur corrections: 120 000 € │
│ Coût infrastructure: 48 000 € │
│ Frais licence: 24 000 € │
│ Coût opportunité (features): 80 000 € │
│ ──────────────────────────────────── │
│ Maintenance annuelle: 272 000 € │
└─────────────────────────────────────────────────┘
COÛT MODERNISATION:
┌─────────────────────────────────────────────────┐
│ Effort développement: 400 000 € │
│ Tests & migration: 100 000 € │
│ Formation: 25 000 € │
│ Contingence risque (20%): 105 000 € │
│ ──────────────────────────────────── │
│ Total modernisation: 630 000 € │
└─────────────────────────────────────────────────┘
DÉCISION:
┌─────────────────────────────────────────────────┐
│ Période retour: 630K / (272K - 50K) = 2,8 ans │
│ │
│ Considérer modernisation si: │
│ • Retour < 3 ans │
│ • Risque sécurité élevé │
│ • Besoins business bloqués │
│ • Disponibilité experts critique │
└─────────────────────────────────────────────────┘
Bonnes Pratiques
- Inventorier tous systèmes legacy avec propriété claire
- Allouer capacité dédiée pour maintenance
- Tout documenter surtout savoir tribal
- Cross-training agressif pour éviter SPOF
- Suivre coûts maintenance pour business cases
- Planifier modernisation stratégiquement pas en réaction
- Célébrer travail legacy comme contribution valorisée
- Automatiser tests où possible
Anti-Patterns
✗ Ignorer legacy jusqu'à la panne
✗ Expert unique par système
✗ Pas de documentation ou docs obsolètes
✗ Mélanger legacy et nouveau de façon imprévisible
✗ Pas de budget pour modernisation
✗ Traiter legacy comme punition