Gestion des cycles de vie

Tout élément du CMDB suit un cycle de vie depuis son acquisition jusqu'à sa mise au rebut. KaliaOps gère ce cycle pour trois types d'entités :

Assets (équipements)

Serveurs, postes de travail, équipements réseau, mobiles... Leur cycle de vie est généralement :

1. Acquisition : Achat ou leasing, création dans le CMDB
2. Déploiement : Installation et mise en production
3. Exploitation : Utilisation normale, maintenances ponctuelles
4. Obsolescence : Performances insuffisantes, fin de support
5. Retrait : Mise au rebut, recyclage DEEE ou revente

Applications

Logiciels, services, applications métier. Leur cycle suit les versions :

1. Développement ou Acquisition
2. Déploiement en production
3. Évolutions et mises à jour
4. Fin de vie : Migration vers une nouvelle solution

Contrats

Contrats de maintenance, licences, support. Leur cycle est rythmé par les dates :

1. Négociation et signature
2. Période de validité
3. Renouvellement ou Résiliation

KaliaOps définit 4 statuts pour le cycle de vie des assets :

Transitions possibles

Les transitions entre statuts suivent une logique métier :

• Actif → Maintenance : Panne, mise à jour planifiée
• Maintenance → Actif : Réparation terminée
• Actif/Maintenance → Retiré : Obsolescence, remplacement
• Retiré → Actif : Remise en service (rare)
• Retiré → Supprimé : Destruction définitive

Contrôles automatiques

Lors d'un changement de statut, KaliaOps vérifie :

• Dépendances actives : Avertissement si des applications ou incidents sont liés
• Analyse d'impact : Proposition d'exécuter l'analyse avant retrait

Lors du remplacement d'un équipement, documentez la relation entre l'ancien et le nouveau :

Créer le lien de remplacement

1. Ouvrez la fiche de l'ancien asset
2. Cliquez sur « Modifier »
3. Dans le champ « Remplacé par », sélectionnez le nouvel asset
4. Changez le statut en « Retiré »
5. Enregistrez

Informations conservées

Le lien de remplacement permet de :

• Visualiser la chaîne : Ancien → Nouveau → Plus récent
• Transférer les connaissances : L'historique de l'ancien reste accessible
• Auditer les changements : Justifier le remplacement (fin de garantie, obsolescence)

Entités concernées

Le champ « Remplacé par » existe sur :

• Assets : Remplacement matériel
• Applications : Migration vers nouvelle version ou solution
• Contrats : Renouvellement avec nouveau contrat

Visualiser la chaîne de remplacement

Depuis la fiche d'un asset, la section « Cycle de vie » affiche :

• Remplacé par : Lien vers le successeur (si défini)
• Remplace : Lien vers le prédécesseur (si applicable)

Vous pouvez ainsi naviguer dans toute la chaîne de remplacement.

Exemple

Un serveur a été remplacé deux fois :

SRV-PROD-01 (2018, supprimé)
  ↓ remplacé par
SRV-PROD-02 (2021, retiré)
  ↓ remplacé par
SRV-PROD-03 (2024, actif)

Depuis SRV-PROD-03, vous pouvez remonter toute l'histoire du serveur de production.

Conservation de l'historique

Même si l'ancien asset est passé en statut « Supprimé », ses informations restent dans la base :

• Caractéristiques techniques
• Dates d'acquisition et de retrait
• Incidents associés
• Lien de remplacement

Seule une suppression définitive (action explicite d'un administrateur) efface ces données.

Avant de retirer un élément du parc, réalisez une analyse d'impact pour identifier toutes les dépendances.

Pourquoi analyser l'impact ?

• Éviter les interruptions : Identifier les services qui dépendent de l'élément
• Planifier la migration : Anticiper les modifications à effectuer
• Communiquer : Informer les utilisateurs impactés

Réaliser l'analyse

1. Ouvrez la fiche de l'élément à retirer
2. Cliquez sur « Analyse d'impact »
3. Consultez les dépendances affichées

Résultats de l'analyse

L'analyse liste :

• Applications hébergées sur l'asset
• Autres assets dépendants (cluster, réplication)
• Incidents en cours liés à cet élément
• Changements planifiés concernant cet élément

Actions recommandées

Selon les résultats :

• Aucune dépendance : Retrait possible immédiatement
• Dépendances non critiques : Planifier la migration
• Dépendances critiques : Définir un plan de continuité avant retrait

1. Documentez les dates clés

Renseignez systématiquement :

• Date d'achat : Pour calculer l'amortissement
• Date de mise en service : Début du cycle de vie actif
• Date d'expiration garantie : Alertes automatiques

2. Utilisez les alertes de garantie

KaliaOps génère des alertes avant expiration de garantie :

• Alerte à 60 jours
• Alerte à 30 jours
• Alerte à expiration

Anticipez les renouvellements ou les remplacements.

3. Préférez « Retiré » à la suppression

Le statut « Retiré » conserve toutes les données. Ne supprimez définitivement que si :

• L'équipement n'a plus aucune valeur documentaire
• Les obligations légales de conservation sont respectées
• Vous êtes certain de ne jamais avoir besoin de l'historique

4. Créez un changement pour les retraits importants

Le retrait d'un serveur de production ou d'une application critique doit suivre le processus de gestion des changements :

• Analyse d'impact documentée
• Plan de migration
• Validation CAB si nécessaire
• Communication aux utilisateurs

5. Liez l'ancien au nouveau

Utilisez toujours le champ « Remplacé par » pour maintenir la traçabilité. Cette information est précieuse pour :

• Les audits de conformité
• L'analyse des coûts de possession (TCO)
• La planification des futurs remplacements