Ressources · 93
Logiciels : inventorier les versions et préparer la fin de support
Transformer une liste d’outils en décisions de maintenance, remplacement ou retrait.
· 3 min
Ce que ce guide permet
- Partir des services utilisés
- Vérifier auprès du fournisseur
- Relier aux dépendances métier
- Préparer une décision
- Fermer sur une preuve
Contrôle express
- Faut-il remplacer tout logiciel ancien ?
- Que faire si la date est inconnue ?
- Une exception règle-t-elle le risque ?
Méthode pas à pas
- 01
Partir des services utilisés
Recensez logiciels, services hébergés, versions, environnements et usages essentiels. Rapprochez inventaires techniques et achats. Le CSF 2.0 relie inventaire et cycle de vie ; un abonnement facturé ne prouve pas qu’une version déployée reste maintenue.
Livrable : Inventaire des instances et usages.
- 02
Vérifier auprès du fournisseur
Conservez lien officiel, édition, version, type de maintenance et date de consultation. Distinguez correctifs de sécurité, support standard et contrat étendu. Marquez une information inconnue comme inconnue ; n’inventez pas d’échéance.
Livrable : Conditions de support sourcées.
- 03
Relier aux dépendances métier
Identifiez propriétaires, intégrations, données et tâches qui cesseraient de fonctionner. Un composant interne non exposé peut rester critique. Priorisez exposition et impact plutôt que le seul âge du produit.
Livrable : Carte des dépendances métier.
- 04
Préparer une décision
Comparez mise à niveau, remplacement, retrait et maintien temporaire contrôlé. Testez compatibilité, restauration et sortie des données. Donnez aux exceptions une justification, un responsable et une échéance de revue.
Livrable : Plan et exceptions attribuées.
- 05
Fermer sur une preuve
Vérifiez version en service, parcours métier et retrait des anciennes instances. Réconciliez registre, supervision et contrats. Une commande de nouvelle licence ne suffit pas à prouver la migration.
Livrable : Preuve de version et de retrait.
Scénarios fictifs de recette
Ces cas proposés ne sont pas des observations de clients. Adaptez les données, permissions et critères à votre environnement autorisé.
| Situation à provoquer | Résultat à vérifier | Preuve à conserver |
|---|---|---|
| Un inventaire indique seulement le nom du produit. | Retrouver version, édition, mode de déploiement et propriétaire avant de décider du statut de support. | Référence installée et source officielle correspondant à cette édition. |
| Une date de support connue change chez l’éditeur. | Mettre à jour la référence datée, les dépendances et le plan ; distinguer date annoncée et état effectivement observé. | URL de politique, date de consultation et décision révisée. |
| La mise à niveau fonctionne mais le retour échoue. | Tester restauration, compatibilité des données et dépendances avant de déclarer la migration maîtrisée. | Chronologie d’essai, sauvegarde utilisée et résultat de reprise. |
Fiche de travail à réutiliser
À compléter avec vos observations autorisées. Ces champs constituent une trame de travail, pas des résultats observés.
| Champ | Information à consigner |
|---|---|
| Produit | Édition, version, environnement et propriétaire |
| Support | Source officielle, conditions et consultation |
| Impact | Services et données dépendants |
| Action | Décision, preuve, échéance et exception |
Exemple d’application
Situation illustrative
Exemple fictif : une application dépend d’un module dont le support annoncé concerne une autre édition.
Décision et preuve attendue
L’équipe vérifie son contrat, teste une version compatible et retire l’ancienne instance après validation métier.
Distinguer les mécanismes
| Mécanisme | Utilité | Point de vigilance |
|---|---|---|
| Version installée | Décrire l’état opérationnel | À relever sur les systèmes réels |
| Contrat de support | Définir les engagements | Peut couvrir certaines éditions seulement |
| Plan de migration | Organiser le changement | À valider par une tâche exécutée |
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Versions identifiées | Instances rattachées à une version | Résoudre les inconnues |
| Support vérifié | Éditions avec preuve fournisseur | Revoir les données périmées |
| Retraits prouvés | Anciennes instances fermées | Réconcilier inventaire et usage |
Erreurs fréquentes
- À relever sur les systèmes réels
- Peut couvrir certaines éditions seulement
- À valider par une tâche exécutée
Questions fréquentes
Faut-il remplacer tout logiciel ancien ?
Non. Vérifiez maintien, exposition, utilité et dépendances. L’âge seul ne définit pas la priorité.
Que faire si la date est inconnue ?
Nommer la lacune, contacter le fournisseur et fixer une revue. Ne déduisez pas la date depuis un autre produit.
Une exception règle-t-elle le risque ?
Elle rend la décision explicite et doit comporter mesures, propriétaire et durée, puis être réexaminée.
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
Pour aller plus loin
Analyses associées
