Gestion de l'obsolescence

Soyons francs, la gestion de l'obsolescence matérielle et logicielle est à peu près aussi excitant qu'une huitre morte sur une plage, l'air iodé en moins.
Mais comme beaucoup d'autres corvées, si vous ne le faites pas vous le regretterez. Et les regrets rendent vieux avant l'âge.

Bref, pas le choix.

Pour suivre l'état de vétusté/décrépitude de votre SI vous allez avoir besoin de corréler 2 entrants

  • la compilation des roadmaps des éditeurs/constructeurs en terme de support
  • l'inventaire de l'existant.

Deux entrants qui sont, n'en doutons pas, déjà impeccablement tenus pas vos collègues et déjà à disposition, il ne reste plus qu'à...
En fait, la constitution de ces deux entrants souvent dénommée "purge annuelle" est un parcours du combattant, ne serait-ce que parce que vous n'avez pas d'inventaire de l'existant ou alors pas avec la bonne granularité ou alors pas à jour, ensuite parce que chaque éditeur planque dans les bas-fonds de son site support (exclusivement accessible avec un compte préalablement validé par l'acheteur qui vient de partir en retraite) les dates de fin de support pour chacune de ses versions et, comme si cela ne suffisait pas, déguise ses dates sous de délicieux vocables "End of early standard Life - entreprise - Long Term only."

dates de support

Cette récupération des dates de support ne peut guère faite que manuellement, péniblement, mais doit être capitalisé : c'est là qu'entre en jeu le référentiel logiciel matériel décrit dans 99-archives/05-Projet livre architecture/content/Les outils et les 3 dates qu'il fallait préciser pour chaque entrée.

N'hésitez pas à faire preuve de bon sens :

  • vous pouvez afficher une date de fin de support plus proche que la réalité afin d'inciter vos projets à anticiper (de toute façon, ils commenceront dans le meilleur des cas à s'inquiéter la veille de la date fatidique) ou pour forcer les nouveaux projets à partir sur des solutions plus récentes ou pour être être davantage en cohérence avec la politique de l'entreprise (ex : exclure rapidement un éditeur aux dents trop longues)
  • Inversement s'il y a peu d'enjeu sur un produit (mais c'est de plus en plus rare ne serait-ce que pour les problématiques de patch sécurité) et parce que vous n'avez jamais fait appel à un quelconque support, vous pouvez rallonger une durée de vie.

inventaire

Côté inventaire de l'existant, il y a deux écoles :

  • une école "théorique" basée sur ce qui est documenté dans les dossiers d'architecture
  • une école "réaliste" qui s'appuie sur les retours des logiciels d'inventaire de votre SI, logiciels qui cataloguent tout ce qui est nstallé sur les serveurs.

Si vous êtes à peu près sain d'esprit, vous devriez vous dire qu'il faudrait être totalement stupide pour préférer la première école. Et vous avez raison. Sauf que vous avez raison en "théorie".
En effet, bien souvent la granularité de ces outils est un peu trop fine et vous risquez de vous noyer sous des monceaux de données qu'il faudra filtrer (parce que le moindre kb installé ne vous intéresse pas), regrouper (parce que le numéro de version à la 112ème décimale ne change rien à la date de support)
Bien souvent aussi, l'exploitant, dans sa grande sagesse, ne voudra pas vous donner accès à ces informations (qui il est vrai contiennent potentiellement des informations sensibles et la sécurité par obfuscation est la meilleure sécurité non ?) et vous êtes qui d'ailleurs pour demander ça, la police ?

C'est donc ainsi que l'école "théorique" a encore parfois le dessus mais elle n'est pas non plus sans poser problème.

Des logiciels de Software Asset Management pourraient vous aider dans cette tâche herculéenne. Aussi bien pour l'inventaire que pour les dates de support. Malheureusement, je n'ai jamais eu le bonheur de bénéficier de leur tout-puissance omnisciente.