Cadre de Gestion des Actifs

En gestion d'actifs, un framework est le modèle qui transforme des registres dispersés d'équipements et de licences en un programme piloté. Il fixe quatre éléments : une taxonomie de catégories d'actifs, un cycle de vie que chaque actif traverse, des rôles qui attribuent la propriété, la garde et la supervision, et des règles de décision pour approuver, modifier et retirer les actifs. Il sert à ce que les réponses aux questions pratiques découlent d'une politique plutôt que de l'improvisation. Un service peut-il acheter ses propres ordinateurs portables ? Qui valide un achat de logiciel ?

Le terme dépasse tout registre ou toute base de données. Un tableur de numéros de série n'est pas un framework, pas plus qu'un outil de découverte, aussi complet soit son scan. Le framework est l'ensemble des définitions et des responsabilités qui décide de ce que ces enregistrements doivent contenir, qui les tient à jour et quelles décisions ils alimentent. Au sein de la gestion des actifs informatiques, c'est la structure que les outils automatisent. Ils ne la remplacent pas.

Un framework commence par répartir la population d'actifs en catégories. La catégorie détermine tout le reste : les attributs enregistrés, les contrôles applicables, le propriétaire naturel et la manière dont l'actif est valorisé. Une taxonomie d'entreprise typique distingue les cinq catégories ci-dessous.

Deux règles font tenir la taxonomie. Les catégories doivent être mutuellement exclusives, afin que chaque actif ait une place unique dans la structure. Elles doivent aussi être collectivement exhaustives, pour que rien de ce que l'organisation dépense ne reste hors du cadre. Chaque catégorie a besoin d'une règle de nommage et d'étiquetage, décrite dans l'identification des actifs. Quand un nouveau type d'actif ne rentre pas, c'est le framework lui-même qui est amendé. Les listes improvisées en dehors sont l'endroit où naît le shadow IT.

Aucune organisation n'a besoin d'inventer un framework à partir de rien. Plusieurs corpus de pratiques sont largement adaptés. La série ISO 55000 décrit un système de management des actifs en termes génériques : des décisions d'actifs alignées, le cycle planifier-réaliser-vérifier-agir et une ligne de visibilité allant de la politique jusqu'à chaque actif. L'ITIL traite la gestion des actifs comme une pratique de gestion des services et relie le cycle de vie de l'actif à la fourniture du service, aux enregistrements de configuration et à la base de gestion des configurations. La vision sécurité ajoute l'exigence d'inventaire. La NIST SP 800-53 attend un inventaire complet et à jour des composants du système, revu à intervalles définis. L'ISO/IEC 27001 exige un inventaire des actifs avec une responsabilité attribuée.

Les organisations matures n'adoptent presque jamais une référence en entier. Le schéma courant combine une couche de gouvernance de style ISO 55000, un lien avec le cycle de vie de style ITIL et une exigence d'inventaire pilotée par la sécurité, adaptés à la taille et au profil de risque de l'organisation.

Le cycle de vie est l'épine dorsale du framework. Chaque actif se trouve toujours dans une seule étape, et chaque étape a des critères d'entrée, des critères de sortie et un rôle responsable. Le modèle classique compte cinq étapes :

1. 1

   Planifier

   Les besoins sont identifiés, les budgets validés et les standards d'achat fixés. Enregistrements clés : standards approuvés, lignes budgétaires.

2. 2

   Acquérir

   L'actif est acheté, loué ou reçu, puis enregistré et étiqueté. Enregistrements clés : facture d'achat, entrée d'inventaire, étiquette d'actif.

3. 3

   Déployer et exploiter

   L'actif est configuré, remis, entretenu et revalidé périodiquement. Enregistrements clés : historique d'affectation, registres de maintenance.

4. 4

   Modifier

   Déménagement, mise à niveau, réaffectation ou reclassement à mesure que l'usage évolue. Enregistrements clés : historique des changements, attributs mis à jour.

5. 5

   Retirer

   L'actif est mis hors service, ses données sont effacées, et le matériel est réutilisé, revendu ou détruit. Enregistrements clés : procès-verbal de réforme, preuve d'effacement.

L'erreur la plus répandue consiste à acheter un outil et à considérer la tâche comme terminée. Un agent de découverte qui liste chaque point d'accès n'est pas un framework, pas plus qu'une base de gestion des configurations. Le framework est l'accord sur les catégories, la propriété, les étapes et les droits de décision que ces systèmes consignent et font respecter. L'outil est l'endroit où vivent les données. Sans framework, la sortie de l'outil se transforme en liste sans propriétaire. Sans outil, le framework se noie dans une maintenance manuelle.

Le test pratique consiste à vérifier que l'organisation peut répondre à partir de ses enregistrements, et non de mémoire. Quels actifs détenons-nous ? Qui répond de chacun ? À quelle étape du cycle de vie se trouve chacun ? Quand la réponse a-t-elle été vérifiée pour la dernière fois ? Un framework solide rend ces questions routinières. Un framework faible transforme chacune en enquête.

Dans Anexet Inventory, la fiche de chaque poste de travail comporte un onglet Devices qui énumère chaque composant avec son type et son fabricant. Sur la fiche d'un serveur, le même onglet ajoute les colonnes numéro d'inventaire et numéro de série, afin que le registre puisse être rapproché des factures d'achat et du stock physique.

1 / 2

• 
• 

Un framework confie le travail à des rôles nommés, et non à celui qui remarque un problème en premier. L'ensemble des rôles est restreint et stable, et chacun porte une décision :

Commencez par les catégories et leurs propriétaires, pas par le logiciel. Désignez un responsable par catégorie, convenez des cinq étapes du cycle de vie, puis seulement choisissez un outil qui consigne ce que le framework décide déjà. Reliez tôt le framework à la gestion des actifs logiciels, car c'est dans les licences que le coût et le risque d'une liste sans propriétaire apparaissent en premier.