Configuration Item (CI) — Définition IT

Un Configuration Item (CI), ou élément de configuration, est tout composant du système d'information suivi dans une CMDB parce qu'un changement, une perte ou une mauvaise configuration de ce composant impacterait un service IT. C'est l'unité atomique de la gestion des configurations dans ITIL — la brique sur laquelle reposent toutes les pratiques d'ITSM, d'ITAM et de SecOps.

Un CI peut être une application, un serveur, un poste de travail, une licence, un contrat, une base de données, un cluster Kubernetes, un service métier, un runbook. La définition précise du CI — sa granularité, ses attributs, ses relations — est l'une des décisions les plus structurantes (et les plus négligées) d'un programme CMDB.

Les types de CI

ITIL 4 distingue quatre grandes familles de CI :

• •CI matériels: : serveurs, baies de stockage, équipements réseau, postes utilisateurs, imprimantes.
• •CI logiciels: : applications, systèmes d'exploitation, middleware, conteneurs, firmware.
• •CI de service: : services métier, abonnements SaaS, services externalisés.
• •CI documentaires: : runbooks, contrats, SLA, schémas d'architecture.

Cette typologie est extensible : certaines organisations ajoutent des CI personnes (responsables, équipes), des CI processus métier, ou des CI réglementaires.

Attributs et relations

Chaque CI porte deux types d'informations :

• •Attributs: : caractéristiques propres (nom, version, propriétaire, criticité, classification de données, date de mise en service, contrat associé).
• •Relations: : liens avec d'autres CI (« tourne sur », « dépend de », « connecté à », « soutient le service »). C'est le réseau de relations qui transforme une simple liste en graphe exploitable.

Une application métier critique peut compter plusieurs dizaines de relations : VM, bases de données, API consommées, équipes propriétaires, contrats vendeurs, processus métiers soutenus.

Granularité : la décision la plus difficile

Le choix de la granularité des CI est l'arbitrage le plus important d'un programme CMDB :

• •Trop grossier: (1 CI = 1 ERP entier) : l'analyse d'impact perd toute précision.
• •Trop fin: (1 CI = 1 conteneur Kubernetes éphémère) : impossible à maintenir manuellement.
• •Bon compromis: : un niveau de granularité par classe de CI, documenté dans une politique de modélisation.

Règle pratique : la granularité doit permettre de répondre à la question business « si ce CI tombe, qu'est-ce qui s'arrête ? » — ni plus, ni moins.

CI vs Asset

• •Un asset (ITAM) est suivi pour sa dimension financière et contractuelle (coût, propriétaire, contrat, amortissement).
• •Un CI est suivi pour sa dimension opérationnelle (relations, configuration, impact service).
• •Un même élément physique peut être à la fois un asset et un CI (un serveur), mais ne l'est pas toujours (un contrat est asset mais rarement CI pertinent ; un cluster Kubernetes éphémère peut être CI mais pas asset).

Les plateformes modernes unifient les deux vues dans un même graphe pour éviter la double saisie.

Cycle de vie d'un CI

Un CI suit typiquement les états ITIL :

• •Planifié: : décision d'acquisition prise.
• •En commande: : achat en cours.
• •En stock: : reçu mais non déployé.
• •En production: : actif et utilisé.
• •En obsolescence: : signalé mais encore en service.
• •Retiré: : décommissionné.
• •Détruit: : disparu du SI.

La transition entre états est tracée dans la CMDB et alimente l'analyse d'obsolescence (technical-obsolescence).

Source de vérité et qualité

Le défi central d'un CI n'est pas sa création mais sa fraîcheur. Un CI saisi à la main dérive de la réalité en quelques semaines. Les bonnes pratiques :

• •Source automatique: : chaque classe de CI doit avoir une source de découverte automatique (cloud API, SSO, agent endpoint, scan réseau).
• •Owner clair: : chaque CI a un propriétaire métier ou technique nommé.
• •Date de dernière vérification: : un CI sans mise à jour depuis 90 jours est probablement obsolète.
• •Score de confiance: : métadonnée qui indique la fiabilité de la donnée.

Kabeen rebâtit automatiquement le graphe des CI applicatifs à partir d'agents, SSO, expense data et feedback utilisateur — éliminant la saisie manuelle qui est la cause numéro 1 d'échec des CMDB.