Vous êtes sur la page 1sur 12

Une CMDB lUniversit de Strasbourg

Virgile Gerecke
Direction Informatique
14 rue Ren Descartes
67 000 Strasbourg

Julien Dupr
Direction Informatique
14 rue Ren Descartes
67 000 Strasbourg

Rsum
La CMDB, ou base de donnes de gestion des configurations, est au cur du processus de gestion des confi-
gurations. Cest un des premiers et des rares outils mis en avant par ITIL. Plus quun inventaire, la CMDB
est cense faire le lien entre diffrents lments issus de multiples inventaires et rfrentiels et apporter une
version historise de ces lments et de leurs relations. Pour autant, cest un outil qui, sil semble promet-
teur au sortir dune formation ITIL, est surtout trs thorique et difficile implmenter. En 2009 un premier
groupe de travail de la Direction Informatique de lUniversit de Strasbourg avait dailleurs planch sur le
sujet de la CMDB sans aboutir une implmentation possible, fut-t-elle parcellaire. Enfin, la plus-value par
rapport un outil dinventaire classique nest pas vidente au premier abord mais se rvle incontournable
lusage.
Sappuyant sur les dmarches qualit entreprises depuis 2009, la Direction Informatique de lUniversit de
Strasbourg a lanc depuis 2013 un projet de mise en oeuvre dune CMDB portant sur un vaste primtre.
Un catalogue dune centaine de services offerts est finalement li plus de 300 applications, 200 serveurs
physiques, 1800 quipements rseaux, 200 lieux, 300 "clients" et contacts, 400 organisations et structures.
Les donnes voques reprsentent plus de 13 000 objets qui auront t injects dans la CMDB. La rali-
sation de la CMDB sappuie sur iTop, un produit dont les qualits et les limites seront exposes lors de la
prsentation. Nous nous attacherons particulirement dmontrer la souplesse de loutil et sa capacit
sinterfacer avec de nombreux lments dun systme dinformation de faon efficace.

Mots clefs
ITIL, CMDB, ITOP, Gestion des configurations, inventaire, donnes de rfrence, ETL

1 Introduction

1.1 Contexte

LUniversit de Strasbourg a t cre en 2009 suite la fusion de 4 tablissements strasbourgeois prexis-


tants. Du cot des services informatiques, 9 entits se sont runies pour donner le jour une direction des
usages et une direction informatique (DI). Cette dernire structure, forte initialement de 122 personnels,
a d affronter le dfi que reprsente la gestion dun systme dinformation complexe et vaste en terme de
nombre dapplications, ou dlments dinfrastructure. Un catalogue dune centaine de services offerts est

JRES 2015 - Montpellier 1/12


finalement li plus de 300 applications, 200 serveurs physiques, 1800 quipements rseaux, 200 lieux,
300 "clients" et contacts, 400 organisations et structures. Les donnes voques reprsentent plus de 13 000
objets. Bon nombre dentre-elles taient pralablement rfrences dans des inventaires comme GLPI pour
les lments dinfrastructures ou dans un wiki documentaire pour les services.
Le recensement et la cartographie mme partielle de ces lments nont pas t une mince affaire. Il a
dabord fallu homogniser les pratiques et trouver un langage commun au travers de la mise en place
dune dmarche qualit centre sur ITIL ds 2009. Cette dmarche a fait lobjet dune prsentation lors
des JRES en 2013. Elle a dot la DI, via le lancement de 11 projets, doutils structurants comme des
processus de gestion des incidents ou un catalogue des services. Ces outils ont "rsist" 3 organisations et
4 directions diffrentes. Malgr des limites, ils ont apport des gains qui ont assur leur prennit. Dans le
cas de processus de faible valeur ajoute, ils ont sombr dans un oubli bienheureux en attendant peut-tre
des jours meilleurs. Dans le mme temps, un recensement des applications tait en cours sous langle de
larchitecture du systme dinformation. Enfin, de son ct, le support charg de grer plus de 25 000 tickets
par an avait besoin de soutiller en terme de procdures et de documentations pour pouvoir rpondre la
demande. Un wiki a servi de dversoir dans lequel toutes ces informations taient jetes avec plus ou moins
de bonheur. Si le recensement et le travail de documentation taient effectus, il est devenu extrmement
difficile de maintenir ces donnes. De plus les liens et corrlations faire entre diffrents lments se
faisaient alors difficilement. Comment lier ces informations ? Comment en assurer la mise jour ainsi que
la cohrence ?

1.2 Historique du projet

Ds 2009, le concept de CMDB avait fait quelques mules et semblait tre un Graal atteindre. La CMDB
(Configuration Management DataBase) doit rfrencer toutes les informations utiles lexploitation des
services informatiques. Les lments composant la CMDB sont appels CI ou "Configuration Items". Il
peut sagir de services, dapplications, de serveurs ou dquipements rseaux, de postes de travail, de do-
cumentations de contrats ou de procdures. La CMDB est donc cense rfrencer ces lments et les lier
entre eux. Elle doit galement historiser les informations et cest (outre son primtre trs large) ce qui la
distingue dun inventaire classique. Ds 2009, un premier groupe pilote avait planch sur la mise en place
de cet outil merveilleux, sans aboutir. Le manque doutils disponibles, lampleur de la tche avait finalement
dcourag les plus enthousiastes.
En 2012, un peu de veille technologique et la comparaison de divers outils libres (oneCMDB, iTop) ont
finalement conduit la mise en place dune maquette diTop un outil qui avait t prsent aux RMLLs
Strasbourg. iTop est un logiciel libre, dvelopp principalement par la socit Combodo qui se prsente
comme un outil ITSM et CMDB. Au-del de la CMDB, la promesse diTop est donc daider la gestion des
services informatiques. Des processus intgrs loutil comme la gestion des changements ou la gestion
des incidents (systme de tickets) doivent donc apporter un plus, comme si la seule CMDB ne suffisait pas
aux ambitions des dveloppeurs. On peut aussi considrer quil sagit au final dutiliser les lments de la
CMDB afin de faciliter le travail quotidien. iTop est dvelopp en PHP et est accessible via une interface
web. Il possde deux qualits principales :
des mcanismes dimport et de synchronisation qui feront lobjet de la premire partie de cet article ;
un modle de donne extensible qui sera prsent dans une seconde partie.
Malgr ces qualits, la maquette iTop a rapidement pris la poussire courant 2013. Personne ne semblait
finalement sy intresser. En 2014, ltude a t ractive car de nouveaux besoins ont merg qui pouvaient
tre satisfaits par la maquette. Ces moments sont instructifs et nous tudierons dans cet article loutil plus
en dtail afin den prsenter les qualits et les limites, les difficults se lapproprier. Cela fera lobjet dune
troisime partie qui sera galement loccasion de prsenter les apports inattendus de la dmarche.

JRES 2015 - Montpellier 2/12


Au final, si on peut sinterroger sur ce qui a pu motiver une telle dmarche, il faut considrer la complexit
et le primtre des lments grs. La dsagrable sensation de construire sur des fondations dont la nature
serait inconnue ainsi que la volont de dcloisonner les informations ont conduit au lancement de ces
exprimentations. Se lancer dans la CMDB, cest essayer de rpondre linjonction crite sur le fronton du
temple de Delphes : "connais-toi toi-mme".

2 Synchronisations et imports
Une fois les premiers tests manuels effectus, vient rapidement la tentation dinsrer des donnes relles
dans la CMDB naissante. Le produit permet des imports CSV et propose des tables de synchronisation.
On pioche, on agrge, on lie les lments entre eux plus ou moins proprement. On obtient rapidement
une plateforme de dmonstration permettant dvaluer le potentiel de la dmarche. Mais tout se complique
lorsquil sagit de mettre en place les lments ncessaires une mise en oeuvre effective et au maintien de
la pertinence des donnes. Voici donc les tapes suivies lUniversit de Strasbourg.

2.1 Identification des sources

La premire tape dintgration des donnes est lidentification des sources. Nous avons donc procd un
"inventaire des inventaires" notre disposition. Nous avons donc retenu :
les inventaires dinfrastructure (GLPI) ;
les listes des services et des applications (notre wiki) ;
les contacts, organisations (dans le rfrentiel des personnes et des structures) ;
les btiments (base mtier rfrentiel immobilier) ;
les fonctions (base mtier RH et application de gestion des correspondants) ;
les contacts et utilisateurs (annuaire LDAP) ;
le primtre dintervention de la direction (fichier tableur) ;
linventaire des onduleurs et des climatisations (fichier tableur) ;
les listes des salles gres avec les informations rcoltes par la DI au fur et mesure des annes
(fichier tableur).
Avec laide des experts des diffrents domaines couverts par la CMDB, nous avons ralis un tableau
rcapitulatif de lensemble de ces donnes comprenant la description de la source, les champs intgrer et
les rgles dusage (par exemple les rgles concernant les statuts des objets).
Cette tape a permis dobtenir une vision globale sur les donnes utiliser. Mais elle a aussi t loccasion
de procder lanalyse de notre capacit matriser nos donnes dans le temps. En effet, bien avant la
CMDB, des liens existaient entre les donnes de certaines bases. Malheureusement, ces liens pouvaient
souffrir dobsolescence dune part cause du type de lien et dautre part cause des donnes elles-mmes.
Lexemple le plus flagrant tait le lien entre les lieux et les quipements. Dun ct, les lieux avaient t
imports une fois dans loutil dinventaire dinfrastructure sans synchronisation ultrieure. En consquence,
la cration ou la modification de salles entranait la perte de cohrence. De lautre ct, le rfrentiel des
lieux montrait des dcalages entre les donnes saisies et lvolution de la finalit des salles. Typiquement,
des salles contenant des matriels comme des postes pdagogiques et qui taient donc des salles de TP
informatique pouvaient tre rfrences dans linventaire des lieux comme des salles de runion ou des
locaux techniques. Le travail sur la CMDB a permis de mettre en lumire ces deux aspects et de les corriger.
Ce travail fastidieux effectu, les donnes ont pu tre intgres dans iTop tout en nous rappelant limportance
des contrles de cohrence des donnes dans le cycle de vie des objets.

JRES 2015 - Montpellier 3/12


2.2 ETL - Extract Transform Load

Le principe de synchronisation diTop repose sur ce paradigme simple


on extrait depuis les bases sources travers les interfaces dexposition des donnes ;
on transforme ensuite ces donnes afin quelles soient compatibles ;
on charge les donnes dans la CMDB.

2.2.1 Elles sont fraches mes donnes !

Nous avons donc utilis un produit interne appel synchronisator. Cet outil gnrique permet de rcuprer
des donnes dans une source spcifie laide de services web ou de requtes SQL. Nous exploitons donc
les possibilits daccs aux donnes de nos inventaires et dfaut, nous avons construit une bibliothque de
requtes SQL.

2.2.2 Elles sont belles mes donnes !

Les donnes sont ensuite transformes pour correspondre dune part aux rgles dusage dfinies lors de
lidentification des sources mais aussi pour consolider les liens entre les lments dinventaire. En effet,
iTop utilise un systme dhritage pour les lments de configuration. Cela permet de partager des pro-
prits communes entre les classes dobjet. Nous avons ainsi dfini un identifiant extrieur permettant de
rconcilier les donnes lors des synchronisations. Il faut donc sassurer de lunicit des identifiants externes
des objets pour viter les problmes dambigut sur les liens. Car si iTop permet deux lments davoir
un mme identifiant externe, il provoque une erreur dimport en cas dincertitude. Parmi les transforma-
tions de donnes, synchronisator applique des rgles de construction didentifiant unique en prfixant les
identifiants externes.
Dans certains cas le modle diTop nous impose lutilisation de classes dobjet. Ainsi, nos sondes dinven-
taire ne remontent pas de donnes concernant les hyperviseurs. Comme cette information sera peut-tre
utilise dans le futur, nous navons pas souhait altrer le modle de donnes et nous devons donc crer des
objets virtuels hyperviseurs afin de lier entre eux serveurs et machines virtuelles. Synchronisator permet de
crer les lments virtuels qui ne remontent pas automatiquement dans linventaire. Dans notre cas, il
sagit par exemple des hyperviseurs. iTop dfinit les machines virtuelles comme on le voit sur la figure 1 :

Machine
virtuelle

Hyperviseur

Serveur

Figure 1 - Elment virtuel hyperviseur

JRES 2015 - Montpellier 4/12


2.2.3 Et ce sera tout ?

Lintgration des donnes se droule en deux temps. Tout dabord il faut remplir les tables de synchroni-
sation diTop avec les donnes prpares. Dans notre cas, cest une nouvelle fois synchronisator qui sen
charge mais dautres scripts maisons peuvent faire laffaire. Ensuite, les possibilits dintgration et la flexi-
bilit diTop entrent en oeuvre. En effet, lors de la dfinition dune synchronisation, une table est cre avec
tous les champs dune classe iTop. Pour chacun de ces champs, on peut dfinir comme on le voit sur la
figure 2 :
si le champ participe la rconciliation des donnes, avec la possibilit de rconcilier sur plusieurs
champs ;
si le champ doit tre mis jour ;
la politique concernant la mise jour des donnes (crasement ou alimentation si vide) ;
si le champ peut-tre mis jour manuellement ;
la cl de recherche pour les objets lis (par exemple le nom de lorganisation dont dpend un lment
de configuration, ce quon qualifie de jointure en SQL).

Figure 2 - Configuration dune synchronisation

Une fois les donnes prsentes dans ces tables de synchronisation, iTop se charge de ventiler les infor-
mations dans son propre schma de base de donnes. Ce mode de fonctionnement permet de conserver
lhistorique des modifications et de sabstraire des subtilits du modle de donnes, rendu complexe par
le systme dhritage entre objets. Il permet aussi dassurer la prennit des synchronisations. Il faut noter
quune attention particulire doit tre porte aux cls externes permettant la rconciliation des donnes.
Nous avons d mettre en place, malheureusement aprs lapparition de conflits, une nomenclature permet-
tant dexclure tout recouvrement sur ces cls externes.
Lensemble des lments ncessaires la remonte automatique des informations depuis nos diffrents
inventaires a ncessit environ un mois-homme.

JRES 2015 - Montpellier 5/12


2.3 Rcupration manuelle de donnes

La dmarche de mise en place dune CMDB a aussi t loccasion de rfrencer toutes les donnes, lments
de configuration ou liens entre lments, stockes hors base de donnes norme. Il sagissait essentiellement
de fichiers tableurs mis en place en labsence doutil adquat ou abordable pour la gestion de ces donnes.
Les informations pouvaient tre fragmentes (il existait plusieurs fichiers de gestion de salles) et les donnes
constitutives ntaient que faiblement lies au S.I. Nous avons essay dautomatiser le plus de rapproche-
ments possibles pour les donnes simples, en essayant dinterprter les informations saisies comme le nom
des contacts, tout en grant les ventuelles fautes de frappes ou les diffrences de format. Pour le reste, un
fastidieux travail manuel a t men afin de rconcilier les lments textuels avec les donnes du S.I. et
ainsi exploiter la somme de connaissances accumules dans ces fichiers.
Les scripts de rapprochement des donnes ont t raliss en deux jours-homme. Le rapprochement manuel
a reprsent prs dune semaine-homme juste pour la rcupration du fichier tableur lies aux donnes
descalade. Toutes ces donnes ont ensuite t intgres au format CSV dans iTop, grce un module ddi
ce type dopration.

2.4 Cycle de vie des objets

2.4.1 iTop comme source de donnes

Notre CMDB agrge, intgre et lie les lments de configuration provenant de sources diverses. Nous
avons vu au paragraphe 2.3 quiTop servait galement de source de donnes. En effet, les informations sont
directement saisies et gres dans loutil dans le cas dobjets pour lesquels il nexiste pas de rfrentiel (ou
pas de rfrentiel satisfaisant). Cest le cas de notre catalogue des services par exemple.
Toutefois, iTop permet aussi denrichir les donnes dobjets provenant de nos inventaires avec par exemple
lajout de commentaires techniques propres nos usages et qui nauraient pas dintrt pour les utilisateurs
initiaux. Ainsi on voit sur la figure 3 que le champ description que nous avons ajout nest pas verrouill :

Figure 3 - Champs verrouills vs saisie manuelle

JRES 2015 - Montpellier 6/12


Enfin, et il sagit dun des principaux intrts de la dmarche, des liens auparavant non rfrencs sont
mis en place et donnent corps aux informations dj prsentes. Cest le cas par exemple des liens entre les
instances de base de donnes et les applications qui les utilisent. Aucun rfrentiel ne nous donnait cette
information qui semble pourtant utile dans le cadre de lexploitation quotidienne des applications.

2.4.2 Suppression

Une fois quun objet est cr, il est li dautres et peut mme tre enrichi. Sil provient dune source
externe, il a fait lobjet dune synchronisation et des restrictions peuvent sappliquer sur les manipulations
dont il peut faire lobjet. Ainsi, certains champs aliments automatiquement peuvent tre verrouills. Cest
pourquoi iTop ne permet pas de suppression partir de synchronisation. Cela vite les suppressions non
dsires (lors dune synchronisation qui choue par exemple) et force adopter une stratgie spcifique.
Tous les objets que nous manipulons ont donc t pourvus dun statut qui permet de grer le cycle de vie.
Ainsi, un serveur peut tre en stock, puis avoir un usage dfini et enfin tre retir. Il reste quand mme
prsent dans la CMDB. Avant toute suppression, une analyse de la situation est mene afin de sassurer que
tous les liens vers ce serveur ont bien t mis jour dans la ralit et dans loutil. Une fois ces vrifications
ncessaires effectues, il peut tre supprim en toute scurit des synchronisations et des objets grs. Cela
permet la fois de limiter les risques de perte dinformation ct CMDB mais aussi et surtout dexploiter
ces donnes afin dliminer tout effet de bord indsirable au retrait de lobjet.
Il est tonnant de constater que si iTop propose des statuts prts lemploi pour plusieurs lments de
configuration (comme les serveurs), tous les objets ne peuvent tre inactivs nativement (instances de base
de donnes ou utilisateurs LDAP par exemple). Nous avons compens ces manques par lajout des champs
correspondants.

3 Modle de donnes

3.1 Pourquoi tendre le modle de donnes ?

Le modle de donnes est llment central de la gestion des configurations. iTop propose un modle par
dfaut riche et proche de nombreux usages. Nous avons vu quil tait ncessaire de faire voluer ce modle
car la CMDB est aussi source de donnes (cf. 2.4.1) et bien souvent des informations qui sont importantes
dans notre contexte dutilisation ne sont pas prsentes dans loutil par dfaut.
Par exemple, pour notre catalogue de services, nous avons d ajouter des champs qui ntaient pas prsents
dans iTop comme la criticit du service, le fait quil soit ou non utilis par certaines populations (tudiants,
enseignants/chercheurs, personnels administratifs et techniques, etc.) ou le fait que certains services soient
internes la DSI.
Par ailleurs, toujours concernant la modlisation des services, nous aurions pu reproduire la structure exis-
tante ralise partir de notre wiki (figure 4).
Mais cette reprsentation ne refltait ni la diversit de nos clients, ni les diffrents environnements mis en
uvre. Nous avons donc opt pour une modlisation plus ambitieuse et plus proche de la ralit (figure 5)
qui permet dexploiter au mieux les fonctionnalits dtude dimpact et de dpendance de loutil (voir 4.5) :

3.2 Comment tendre le modle de donnes ?

Le modle diTop est fait pour tre tendu. Tous les objets sont dcrits sous forme de classes qui bnficient
dun systme dhritage. Il est donc ais de crer de nouvelles classes, de modifier des classes existantes ou
dtendre des classes.

JRES 2015 - Montpellier 7/12


Service
Plate forme pdagogique

Application Application
Acolad Moodle

Figure 4 - Modlisation des services et applications dans le wiki

Service
Plate forme pdagogique

Application Application Application Application


Acolad Unistra Moodle Unistra Moodle ENA Moodle Unistra
Production Production Production Formation

Architecture de Architecture de Architecture de Architecture de


Architecture
production de production production production
production
spcifique spcifique spcifique spcifique
spcifique
/|\ /|\ /|\ /|\
/|\

Figure 5 - Modlisation des services et applications dans iTop

Lensemble de ces classes est dcrit sous forme de fichiers XML de configuration comprenant :
des donnes de configuration de stockage ;
la liste des champs et de leurs donnes jointes (la plupart des lments est lie une organisation dont
on stocke lidentifiant org_id mais dont on affiche simplement le nom grce une jointure implicite
offerte par iTop) ;
la configuration de laffichage des donnes de la classe ;
la configuration des formulaires de recherche dobjets.
iTop propose de nombreuses classes dans son modle par dfaut. Afin de prserver les possibilits de mise
jour, toutes les modifications du modle passent par un systme de modules. Nous pouvons donc crer des
modules spcifiques chaque but vis, comprenant une conjonction de classes modifies et/ou nouvelles.
La mise en place dune CMDB a cr de nombreuses attentes, portant sur diverses problmatiques. Nous
avons donc cr des modules pour :
les fluides (onduleurs, alimentations, climatisations qui sont des notions absentes diTop) ;
les salles (extension des lieux pour permettre dapporter de nombreuses prcisions) ;
de nombreux liens avec des contacts (nos correspondants au sein des structures clients, des respon-
sables administratifs ou de filire, etc.) ;
larchitecture de nos applications comme dcrite au paragraphe 3.1 ;
les flux de donnes entre les diffrents lments du S.I.
etc.

JRES 2015 - Montpellier 8/12


Ce ne sont que nos premiers modules car nous continuons dadapter le modle lvolution de nos usages.
Au-del de laspect technique, nous avons aussi mis en place un processus dvolution du modle voqu
au paragraphe 4.2.

4 Appropriation de loutil et apports

4.1 Difficults de dmarrage

La dmarche autour de la CMDB a rellement dmarr dbut 2013 avec une premire maquette diTop.
Pourtant, un rel projet na pu voir le jour que mi-2014. On peut sinterroger sur ce dcalage. Si la CMDB
tait le Graal comment se fait-t-il que son implmentation ait mis autant de temps prendre racine ? On
pourrait avec facilit voquer une charge de travail consquente qui ne laissait que peu de place aux expri-
mentations mais on peut galement aller plus loin dans lanalyse. Dans un premier temps, une CMDB mme
adosse un ronflant volet de gestion de services (ITSM - IT Service Management) semble simplement tre
un outil de plus, encore un outil, qui napporte pas de relle plus-value :
des outils dinventaires au niveau du parc ou des lments dinfrastructure sont dj en place ;
les applications et les services ont probablement dj t cartographis par des architectes du systme
dinformation ou des qualiticiens ;
la prsence trs probable dun outil de gestion de ticket interne qui donne satisfaction dans les grandes
lignes semblent rendre caduc le volet ITSM diTop.
Considrant le cot de mise en place dune maquette avec des donnes relles, la mise en place de la CMDB
ressemble un luxe que lon ne peut pas se permettre.
Le facteur qui a permis la dmarche davancer lUniversit de Strasbourg a t la volont du responsable
du support informatique de structurer et de lier de nombreuses donnes concernant le primtre dinter-
vention de la DI. Ce primtre dune complexit extrme qui tait pralablement dcrit dans un tableur
impossible maintenir a servi de catalyseur pour le projet de mise en place de la CMDB dans la mesure
o il fallait lier les services, les clients, les btiments et les quipements. Dune manire ou dune autre,
la prsence dun besoin non satisfait sert de mouche du coche pour ce genre de dmarche. Par ailleurs, le
fait de se focaliser sur ce besoin particulier peut permettre dviter de se disperser, ce qui est important
dans le cas de la CMDB. Le projet men Strasbourg est parfois tomb dans le pige de la multiplicit des
cibles vises. Cette dispersion provoque un effet secondaire viter dans le sens o cela peut allonger les
dlais de ralisation. La prsence de mcanismes de synchronisation de donnes voqus dans le chapitre 2
a galement facilit la ralisation dune maquette convaincante, cest--dire prsentant des donnes relles.

4.2 Appropriation de loutil

Une CMDB propose une agrgation de donnes existantes dans le systme dinformation, mais permet aussi
la saisie dlments manquants. Cette situation provoque 2 types de problmes diffrents :
dans le cas dlments existants, il sagit de les rcuprer dans des bases sources diverses. Cette ma-
nuvre peut engendrer des effets de bord : certaines donnes qui taient prsentes dans ces bases
sources peuvent tre compltes par des donnes saisies manuellement. Il peut savrer pertinent de
dcaler cette saisie manuelle pour quelle se fasse dsormais dans la CMDB, mais cela implique de
changer des pratiques. Dans ce cas prcis, il faut mettre en avant un gain, faute de quoi ce change-
ment naura pas lieu. Il faut alors trouver des rponses aux questions suivantes : que peut apporter
- directement - la CMDB ceux qui doivent alors changer leurs pratiques ? Quels gains pour tous
les collgues ? La rponse ces questions ne peut se trouver quen travaillant directement avec les

JRES 2015 - Montpellier 9/12


quipes concernes. Bien souvent, les informations taient prsentes dans dautres outils qui ont pu
tre partiellement tordus pour rpondre des problmatiques qui ne sont pas initialement les leurs.
Ainsi le catalogue des services tait-t-il modlis dans GLPI qui nest pas fait pour a. Recentrer
un outil sur ses fonctions de base facilite sa maintenance. Dans le cas dinformations qui taient
prsentes dans des fichiers isols, leur dversement dans la CMDB permet un meilleur partage et
une mise jour plus facile (automatise) des informations. Cest le cas par exemple du fichier esca-
lade gr par le support de la Direction Informatique qui regroupait des centaines de structures, des
dizaines de correspondants, plus dune centaine de btiments et de nombreux services ;
dans le cas dlments nouveaux, la problmatique de la conduite du changement est moindre, mais
encore une fois, la dfinition du mta-modle de donnes ne peut se faire quavec limplication dac-
teurs reprsentatifs.
De manire gnrale, la problmatique est bien celle de la valeur ajoute du produit pour tous. Il nest
pas forcment vident de la dmontrer. Dans notre cas, des ateliers ouverts de prsentation ou des sessions
ddies certaines problmatiques ont t mis en place. La difficult est ensuite dtre capable de rpondre
rapidement aux attentes souleves par ces ateliers. Dans notre cas le bt a pu blesser ce niveau.

4.3 Gouvernance du modle de donnes


Il faut sentendre sur lvolution du modle de donnes. Dans notre contexte, le principe de gestion suivant
a t dfini :
le mta-modle de donnes appartient tous. Tous peuvent proposer des volutions de ce modle.
La version de rfrence est reprsente par iTop sous la forme de fichiers XML qui sont stocks
sur un systme de gestion de versions (git). La cration dinstances de dveloppement diTop a t
automatise afin de faciliter les tests ;
une proposition dvolution du modle de donnes se fait via une demande de modification du
schma. Cette demande est examine par un collge de membres reprsentatifs et en cas dabsence
dobjection, elle est considre comme valide. Les architectes du Systme dInformation ont bien
sr vocation se pencher sur ces demandes ;
la modification est dploye en production.

4.4 Processus internes


iTop intgre en interne des processus prdfinis comme le processus de gestion de tickets et le processus de
gestion des demandes de changement. Cette fonctionnalit supplmentaire peut ventuellement prsenter
un intrt. Dans le cas de la Direction Informatique, le module de gestion de tickets na pas t activ
car un outil qui donne satisfaction est dj en place. En revanche, concernant le processus de gestion des
changements, iTop propose un module. Il est possible de lactiver en version "lourde" ou "lgre". Le
workflow alors mis en place dpend du choix de ladministrateur. Ce processus prsente un intrt potentiel
dans la mesure o la gestion des changements peut ds lors sappuyer sur des informations de la CMDB
(configuration). lUniversit de Strasbourg, un processus de gestion des changements est en place depuis
2012. On aurait pu penser que le module diTop aurait t une opportunit pour ce processus. Dans les faits,
cela na pas t le cas. iTop propose deux workflows diffrents, mais la rigidit de ces derniers ne facilite
pas leur utilisation relle, surtout quand des choix ont dj t faits. Dans notre cas, les modules proposs
nont donc pas t utiliss, leur valeur ajoute savrant ngative.
De plus, iTop prsente un dfaut particulier dans ce domaine : un plugin activ un instant donn ne peut
plus tre dsactiv par la suite. Il devient alors dlicat de faire des tests dans la mesure o ces derniers
ne sont pas totalement rversibles. Nous avons contourn ce problme en mettant en place larchitecture
suivante :

JRES 2015 - Montpellier 10/12


une instance de test peuple avec des donnes issues du systme dinformation
une myriade dinstances de dveloppement cres via des scripts qui copient linstance de test prin-
cipale
une instance de production

4.5 Bonus

Nous allons voquer dans ce chapitre deux bnfices induits par la dmarche et qui mritent dtre souligns.
Le premier a dj t voqu, il sagit du dcloisonnement de linformation et du lien entre des informations
qui taient isoles. Des fichiers bureautiques "confidentiels" ou des bases de donnes utilises exclusivement
par une quipe se retrouvent exposs et tous peuvent les consulter. Mme si les corrlations que lon souhaite
alors naturellement raliser ncessitent un travail sur la qualit et la cohrence des donnes, ce point est en
dfinitive bnfique.
Le deuxime point na pas encore t soulign et il mrite de ltre : iTop prsente une fonctionnalit
intressante danalyse dimpact. Pour un lment de configuration (CI) donn on peut valuer (en fonction
de son type) :
de quoi il dpend ;
ce quil impacte.
On peut ainsi essayer de dterminer limpact dune maintenance ou dune panne ce qui donnera la rponse
la question magique "que se passe-t-il si je casse ceci ?". iTop ne donne pas dattribut aux liens de d-
pendances, on ne peut donc pas modliser finement une architecture impliquant de la redondance. Cela
veut dire que lanalyse dimpact ne dterminera pas automatiquement leffet dune indisponibilit dun CI.
Lanalyse dun ingnieur matrisant larchitecture reste ncessaire, mais cest probablement mieux ainsi.
Lanalyse dimpact permet dattirer lattention sur un impact potentiel, que ce dernier soit matris par une
architecture redondante ou pas.

Figure 6 - Arbre de dpendance

JRES 2015 - Montpellier 11/12


Une telle dmarche ncessite de modliser et synchroniser lensemble des CI ncessaires au fonctionnement
dun service. Toutefois, elle permet de gagner en matrise du systme dinformation et de mieux cibler la
communication vers les utilisateurs en cas de panne.

5 Conclusion
On le voit dans cet article, la mise en place dune CMDB nest pas un Graal inaccessible. Toutefois, le projet
de mise en place dun tel outil nest pas trivial et il a des impacts multiples et ncessite une forte intgration
au systme dinformation. Justement, quand la route est longue, et dans la mesure o la CMDB prsente
de nombreuses facettes, il convient de se focaliser sur des objectifs ralistes et davancer par tapes, de
dcouper le SI en morceaux afin de prsenter des rsultats intermdiaires qui permettent de dmontrer les
apports de la dmarche.

JRES 2015 - Montpellier 12/12

Vous aimerez peut-être aussi