SIAMU

Cartographie en mode collaboratif d’un SI

basée sur des besoins opérationnels

Jean-Philippe FLORET
DOSI Aix Marseille Université
58 BVD Charles Livon Jardin du Pharo
13007 Marseille

Brice GUIMET
DOSI Aix Marseille Université
58 BVD Charles Livon Jardin du Pharo
13007 Marseille

Résumé
Dans le cadre d’un SI en place et opérationnel, où chaque métier se préoccupe de ses propres
problématiques fonctionnelles, recourant parfois même à des solutions locales, comment avoir une vision
claire des interactions, des liens et de l’urbanisation du SI ?
La première réponse se traduit en général par une cartographie du SI (souvent uniquement applicative)
qui ne restera à jour que peu de temps malgré les outils les plus performants du marché, à moins d’avoir
des ressources humaines dédiées et très motivées.
Dans ce contexte, après avoir testé plusieurs outils et essuyé des difficultés liées à l’absence de mise à
jour des données, nous avons imaginé une solution alternative. Celle-ci ne se focalise plus uniquement
sur la représentation détaillée du SI mais sur l’ensemble des besoins des différentes équipes
informatiques (système, développement, gestion des applications) comme de tous nos utilisateurs.
Cet outil innovant s’appuie sur une démarche participative de renseignement, de saisie et de mise à jour
par les acteurs les plus proches des applications et des serveurs – participation motivée non pas par la
contrainte, mais par la véritable plus-value qu’apporte l’outil dans leur activité quotidienne.
En cas d’intervention ou d’incident sur un serveur ou une application, l’outil permet notamment d’avoir
une visibilité sur l’impact global de ces événements sur le SI. Il permet également d’auditer les
habilitations applicatives pour prévenir tout changement lié à un usager. Il améliore aussi la
transparence vis-à-vis des utilisateurs (arrêts de services, catalogue de services…). Enfin, il génère les 3
cartographies applicative, serveur et réseau.

Mots-clefs
Système d’information, urbanisation, cartographie, collaboratif, application, opérationnel, serveur,
réseau, habilitation

1 Introduction
Les universités d’Aix Marseille ont fusionné au premier janvier 2012. Le nombre d’applications de
gestion et de salles serveurs a explosé par rapport à ce que nous avions l’habitude de gérer et très

JRES 2017– Nantes 1/12

rapidement il est devenu difficile d’avoir une vue d’ensemble sur nos outils. De plus, nous avons
également découvert un SI caché, composé d’applications provenant d’origines diverses, et gérées sur des
petits serveurs dans des environnements parfois improbables. Ce « deep SI » n’étant pas d’une grande
ouverture, les découvertes de nouvelles applications se sont faites au fur et à mesure du temps et nous
avons dû les intégrer à notre paysage informatique.
Ce document retrace l'histoire de la mise en place d'un système visant à décrire, comprendre, partager et
piloter le SI d'Aix-Marseille Université. Les solutions présentées ne sont sans doute pas applicables dans
toutes les organisations, ce n'était d'ailleurs pas l'objectif d'origine. L’objectif était avant tout de sortir de
la brume notre SI et de se doter d'un outil et surtout d'une démarche facilement appropriables par
l’ensemble des acteurs du SI de l’établissement et notamment la Direction Opérationnelle des Systèmes
d’Information (DOSI) composée de 170 personnes environ.

2 Une démarche bottom-up, top-down, middle-out, outside-in

ou juste opérationnelle ?
Dans notre contexte, nous sommes partis d'un SI en place et opérationnel où les métiers se préoccupent
chacun de leurs problématiques fonctionnelles et recourent souvent à des solutions locales pour pallier les
manques des applications officielles. Ces solutions peuvent reposer sur des tableurs ou autres outils de
bureautique ou bien prendre la forme de développements très locaux (hors DSI). Dans tous les cas, la
mise en place d'une architecture orientée services (SOA), dans laquelle le SI s’aligne sur le métier et non
l’inverse est une démarche rassurante et sécurisante.
Dans ce contexte, sommes-nous prêt à déconstruire un système qui fonctionne, malgré quelques hoquets,
pour une meilleure maîtrise de notre système d’information ? Sommes-nous prêts à faire table rase de
notre capital SI pour nous lancer dans le colossal travail de déconstruction/reconstruction ? Ne pourrait-
on pas commencer par mettre en place une solution décrivant le SI sous ses aspects applicatifs avec ses
interactions pour gagner en visibilité et en transparence ?
Cette idée est loin d’être originale puisque c’est souvent la base des projets d’urbanisation des SI.
Néanmoins dans notre contexte (Aix Marseille Université) où il n’y a pas d’équipes d’urbanistes ni de
ressources vraiment dédiées à la mise en place de cartographies, il fallait trouver une solution qui s’appuie
sur des ressources existantes et opérationnelles.
Nous nous sommes donc posé les questions suivantes :
― Quelles sont les démarches envisageables ?
― Qui sont les acteurs ?
― Quels sont nos besoins, ceux auxquels il convient de répondre pour apporter une plus-value à notre
organisation ?
― Comment rendre notre action la plus participative possible ?
De ces questions est né le constat qu’il est difficile de trouver la première ficelle à tirer si le problème
n'est pas posé en terme de besoin...ce besoin étant inhérent à l'établissement, aux personnes le composant
et à sa maturité en matière de SI.
De plus, si l'on considère que le SI est l'affaire de tous et que tout un chacun y a sa part de responsabilité,
comment avancer si cette démarche n'est pas vue comme une réponse à un besoin reconnu et surtout
opérationnel ?

3 Au commencement
Bien souvent la démarche d'urbanisation est motivée par un besoin de cartographie applicative visant à
faire un état des lieux exhaustif de l'ensemble des outils. Il semble que cette seule perspective suffise à
reporter la démarche aux calendes grecques. En effet, il peut être vain d'espérer mettre en place, maintenir
cette cartographie et en garantir la pertinence dans un contexte de grand établissement géographiquement
éclaté et composé historiquement d'entités presque autonomes.

JRES 2017– Nantes 2/12

Au mieux, le résultat du travail de collecte des données permettra de mettre en place une cartographie qui
sera obsolète dès la première mise à jour d'un logiciel ou dès l'apparition d'un nouvel outil, mais aura au
moins le mérite d'exister en tant que cartographie instantanée.
Malheureusement, ce type de cartographie n’intéresse pas grand monde en dehors de l'architecte/urbaniste
ou du DSI. Peu de gens y voient un intérêt dans leurs activités quotidiennes au sein de l'établissement. Ce
constat découle de l’échec de la mise en œuvre d’une cartographie « graphique » développée en 2013,
simplement disponible et modifiable en ligne, reconnue par tous nos collègues comme « très jolie » mais
qui au-delà de cet aspect esthétique, n’a pas remporté l’adhésion souhaitée.
C'est ainsi qu'a démarré la réflexion sur la possibilité d’utiliser la cartographie comme un outil
opérationnel pour tous les responsables d’applications et, au-delà, pour tous les acteurs du SI.

4 La cartographie applicative comme solution de fédération

autour du SI
Lors de discussions avec les ingénieurs système, ils évoquent fréquemment ce problème lié à l’arrêt d’un
serveur : s’ils connaissent vaguement les services ou applications directement affectés, ils maîtrisent mal
les effets de bord et dépendances touchant des services ou des applications hébergés sur d’autres serveurs.
Par ailleurs, sur une infrastructure de plusieurs centaines de serveurs, il est difficile de savoir qui
contacter, d’autant plus avec des ressources humaines mouvantes. La personne en charge d’un serveur à
un instant T ne sera peut-être plus la même dans quelques mois.
Parallèlement, les responsables des applications ont une problématique du même ordre liée aux opérations
de maintenance. Dans le meilleur des cas, ils ont une liste d’utilisateurs à jour mais ne savent pas si
d’autres applications sont dépendantes de celle qui doit être maintenue et ne peuvent donc pas prévenir
les éventuels intéressés. Au final, ce sont les utilisateurs impactés qui ne comprennent pas pourquoi leur
outil ne fonctionne plus. Avec toute la frustration que génèrent les mystères de l’informatique et ses
caprices, ils s’en prennent aux assistances informatiques de proximité, lesquelles, par rebond, se plaignent
d’un défaut d’information qui les discrédite auprès des usagers.
Il est donc indispensable que nous ayons le contrôle de notre SI pour anticiper les dysfonctionnements et
les effets de bord car il en va de la satisfaction de nos utilisateurs et de la bonne marche du système.
Finalement, la réponse pourrait résider dans l’état des lieux évoqué plus haut. Que désirent les ingénieurs
système et les ingénieurs responsables des applications ? Que désirent les responsables fonctionnels ?
Que désirent les développeurs, chefs de projets ? Que désirent les assistances ? Et même, que désirent les
utilisateurs ?
C’est limpide : ils souhaitent être avertis lorsqu'une interruption risque d’affecter leur domaine d'activité.
Or, pour que les responsables des applications soient avertis il faut que l’on sache :
― de quelles applications ils sont responsables ;
― sur quels serveurs sont installées ces applications, leurs bases de données ;
― s’il y a des liens entre les applications.
On a donc besoin des informations pertinentes remontées par les bonnes personnes.
Et qui mieux qu’un responsable d’application / de serveur / de base de donnée peut mettre à jour le
descriptif d’une application / d’un serveur / d’une base de données et de tout ce qui tourne autour ?
L'intérêt pour eux étant d’améliorer la qualité de service et de voir l'indicateur « satisfaction des
utilisateurs » remonter.
Il y a donc une chaîne d’acteurs à mettre en place pour la saisie des données. La qualité des données
saisies étant implicitement liée à la plus-value générée pour ces acteurs.

JRES 2017– Nantes 3/12

5 Proposition de mise en place de la chaîne de saisie de
l'information
Selon le modèle classique de description d'un SI, la première couche représente les infrastructures, soit les
serveurs et équipements réseaux. La seconde couche est la partie applicative. Sur chacune de ces couches
nous avons mis en évidence les responsables liés à la saisie des données qui les décrivent.

5.1 Les infrastructures

Dans notre contexte les serveurs existent dans des environnements virtualisés et la notion de réseau
physique n'a plus d'existence réelle. Il devient difficile de relier un commutateur ou un routeur physique
avec un serveur virtuel ou, à l’inverse, de relier un serveur virtuel avec un serveur physique puisque le
serveur virtuel peut être déplacé de façon automatique sur n'importe quel serveur physique du data center.
Nous prenons donc en compte uniquement les serveurs virtuels puisque ce sont eux qui hébergent nos
applications et bases de données (entre autres). En général, un serveur virtuel est associé comme un
serveur physique à une adresse IP et à un ou plusieurs alias de domaine.
Cette première couche est prise en charge par une automatisation de la saisie des serveurs dans l’outil
SIAMU, facilitée par la gestion centralisée des serveurs virtuels. Néanmoins certaines informations sont
saisies afin d’améliorer la description et le typage du serveur. Le type des responsables est décrit dans le
tableau ci-après :

Intitulé des responsables liés Champs d’actions Services concernés

aux infrastructures

Responsable des serveurs Exploitation des serveurs Services informatiques

5.2 Les applications

Chaque application est saisie manuellement sous la forme d’une fiche descriptive indiquant les
interactions possibles avec d’autres applications.
A cette deuxième couche sont associés les différents responsables liés aux applications. A ce stade nous
avons sélectionné plusieurs types de responsables :

Intitulé des responsables liés Champs d’actions Services concernés

aux applications

Responsable technique Exploitation des applications Services informatiques

Responsable développement Développement des applications Services informatiques

Responsable fonctionnel Utilisateur métier Tous les services potentiellement

5.3 Sources de motivations pour inciter à la saisie

Nous avons donc d'un côté les responsables des applications (technique, développement, fonctionnel) et
de l'autre côté les responsables des serveurs. La motivation des uns et des autres pour effectuer une saisie
exhaustive des données tient à la plus-value qu'ils en tireront. En d’autres termes, si cela ne me sert à rien,
je n’irai pas porter ma pierre à l’édifice alors même que pendant ce temps mes autres tâches continuent de
s’accumuler. Mais si cette action provoque à court ou moyen terme une amélioration de la qualité de mon
service et par conséquent une diminution de la charge de travail liée à l’assistance ou à la maintenance,
j’y adhère. Nous allons voir comment la gestion des événements a permis de créer cette adhésion.

JRES 2017– Nantes 4/12

6 Le chaînon manquant : la gestion des événements
Un événement représente pour nous, de façon exhaustive, un incident, un arrêt, une évolution ou une
maintenance, à la fois pour les serveurs, les applications et le réseau. Cette liste sera néanmoins sans
doute amenée à évoluer en fonction des besoins.
La gestion des événements consiste à mettre en place un système d’alerte susceptible d’apporter
l'information la plus pertinente aux acteurs concernés et d’offrir plus de transparence à l’ensemble des
utilisateurs. C’est cette fonctionnalité qui a véritablement permis de remporter l’adhésion de tous.

6.1 Principe
Un formulaire est à la disposition des responsables des applications et des responsables de l'infrastructure.
Pour tout événement, ceux-ci sélectionnent l’application ou le serveur concerné et complètent un
formulaire comportant un descriptif, un niveau de gravité et une durée d'interruption de service. Dès lors
si les liens applications/applications et applications/serveurs existent et que les personnes sont
correctement associées il devient très simple de collecter de façon automatique les responsables à
prévenir de façon ciblée.

6.2 Avantages
Les avantages de ce type de système de déclaration des événements sont les suivants :
― une plate-forme unique d'information pour tous les acteurs de la DOSI ;
― une traçabilité de tous les événements survenus sur le SI ;
― la possibilité de construire des indicateurs de performance ;
― la transparence sur les événements qui surviennent dans le SI auprès des utilisateurs (cf. Figure 1) ;
― l’envoi d’une information ciblée aux responsables concernés par l'événement évitant la saturation
d'avertissements inutiles ;
― l’augmentation de l'effet d'appartenance au même service et moins de flou liés aux
dysfonctionnements.

Figure 1 : exemple d’affichage d’un événement sur une application dans l’ENT

JRES 2017– Nantes 5/12

6.3 Cartographie des applications
La saisie des fiches pour les applications est cadrée dans une organisation classique d’urbanisation sous
forme de zones et de quartier dans lesquels les applications représentent des îlots (Figure 2).
Pour chaque application, le responsable de la saisie indique quels sont les autres applications ou services
dont elle consomme les données ou dont elle dépend. Par exemple, une application comme « Ecandidat »
consomme des données de l’application « Apogée » et dépend du service d’authentification « Cas » .
Ainsi, la cartographie web (Figure 2) permet de voir pour chaque application quelles sont les autres
applications qui l’utilisent en source de données (consommatrices) et celles qui lui en sont une
(productrices) ainsi que les dépendances de services.
Pour chaque application, le statut est indiqué (production, test, etc.) Un champ de sélection permet de
choisir un statut et de mettre en surbrillance toutes les applications correspondant à ce statut. Chacun peut
également avoir un descriptif de l’application en se positionnant sur l’application cible.

Figure 2 : Zoom sur une partie de cartographie applicative avec liens

6.4 Cartographie des serveurs

La Figure 3 montre les trois data-centers d’AMU décomposés en cluster, ESX (hyperviseur VMware) et
serveurs virtuels. Sur chaque serveur les applications sont indiquées avec une description et les
responsables associés. Ce module permet en outre de faire une recherche sur les noms.

JRES 2017– Nantes 6/12

 Figure 3 : Cartographie serveurs

JRES 2017– Nantes 7/12

6.5 Cartographie du réseau
La Figure 4 représente la cartographie du réseau métropolitain avec l’état des lignes et des matériels. Les
données sont issues automatiquement de l’IMC HP qui supervise le réseau. SIAMU, à ce stade de
développement, ne sert uniquement qu’à représenter l’état de réseau et permet de saisir des événements.

Figure 4: Cartographie réseau

7 La gestion des habilitations

Ce sujet est délicat car il montre que dans nos SI les aspects de sécurisation des habilitations peuvent être
mal maîtrisés. Qui peut fournir rapidement une information concernant les droits des agents sur telle ou
telle application ? Qui peut garantir que les habilitations ont bien été retirées aux utilisateurs qui ont
changés d’affectation sur les applications dont ils n’ont plus l’utilité ? Et qui peut garantir que tous les
droits ont été retirés lorsqu’une personne quitte l’établissement ?
Initialement SIAMU n’a pas été développé pour cela, mais finalement nous avions presque toutes les
briques nécessaires à la centralisation de ces informations et à la mise en place d’un système d’alerte lié
aux habilitations. Ces alertes permettent de prévenir les responsables (généralement fonctionnels) qu’une
personne n’est peut-être plus censée apparaître dans la liste des gestionnaires, administrateurs ou
utilisateurs d’une application.
Pour chaque application, SIAMU permet de paramétrer graphiquement un connecteur qui liste l’ensemble
des utilisateurs habilités, en interrogeant la base de données de l’application ou le groupe LDAP des
personnes autorisées par exemple.
La mise à jour des utilisateurs habilités de chaque application constitue une liste globale de tous les droits
applicatifs. A une fréquence choisie, l’outil repère tout changement d’affectation ou départ et lance une
alerte aux responsables des habilitations de chaque application configurée (Figure 5).

JRES 2017– Nantes 8/12

 Figure 5: Schéma du fonctionnement du module habilitations

8 SIAMU en chiffres
L’outil SIAMU est en phase de test depuis mai 2014 à Aix Marseille Université. Depuis ont été
recensées :
― 354 applications ;
― 486 serveurs en production ;
― 67 routeurs sur le réseau métropolitain .
Ces saisies ont été possibles grâce à l’intervention de :
― 61 responsables techniques (d’une ou plusieurs applications) ;
― 26 responsables développement (d’une ou plusieurs applications) ;
― 137 responsables fonctionnels (coté métier).
Depuis 2014 de nombreux événements ont été déclarés :
― 782 événements sur les applications ;
― 222 événement sur les serveurs ;
― 70 événements sur le réseau.
En trois ans, la moyenne du nombre de visiteurs distincts par jour (essentiellement DOSI) est passée de 9
à 20 sans compter les connexions aux flux RSS qui sont passées de 4 à 30.
Les utilisateurs (personnels et étudiants) ont maintenant une visibilité précise sur l’état des outils mis à
leur disposition dans l’ENT. Cette nouvelle fonctionnalité étant très jeune, nous n’avons pas encore de
retour de la part des utilisateurs.

JRES 2017– Nantes 9/12

9 Évolutions de SIAMU
De nombreuses évolutions ont été développées pour satisfaire les besoins qui grandissaient au rythme de
l’appropriation par le personnel de la DOSI.
L’outil a été conçu initialement comme une maquette sur la base d’un développement « sauvage » qui ne
répondait pas aux bonnes pratiques du domaine, notamment parce que ce projet – innovant mais sans
garantie de réussite – ne s’est pas inscrit dans un cadre « projet » de développement. Par conséquent,
plusieurs personnes ont ajouté des fonctionnalités, avec la volonté de démontrer dans des délais très
courts l’efficacité et la pertinence de ces évolutions, mais sans se préoccuper de documentation ou
d’harmonie de codage. Ces évolutions ont été accueillies malgré tout, le besoin étant d’avoir une forte
réactivité et de ne pas décourager les bonnes volontés.
Aujourd’hui l’adhésion est acquise, les besoins surgissent là où on ne les soupçonnait pas, comme par
exemple l’aide à la mise en place du plan de reprise d’activité (PRA). Il devient important de revoir le
mode de développement afin d’améliorer l’ergonomie, la robustesse et l’aptitude du produit à évoluer
dans un mode contributif (ajout de plugins).
Depuis l’été 2017, un projet de refonte est en cours avec la feuille de route suivante :
1. Analyse de l’outil existant pour en extraire toutes les fonctionnalités ;
2. Développement du cœur de l’outil comprenant les fiches applications, serveurs, événements et
back-office d’administration ;
3. Développement de l’API de base (JSON) ;
4. Développement des plugins, notamment :
― Cartographie des applications, des serveurs et du réseau ;
― Gestion des habilitations ;

― Plan de reprise d’activité (PRA).

L’outil SIAMU a déjà suscité l’intérêt d’autres établissements et leur a été fourni en l’état. Néanmoins il
serait beaucoup plus intéressant pour tous que nous arrivions à profiter chacun des éventuels travaux des
uns pour les autres dans une logique communautaire et participative sans contrainte. C’est également
l’une des raisons de la refonte de l’outil.

10 Conclusion
Cet outil développé initialement pour arriver à maintenir une cartographie des applications pour la
direction de la DOSI est devenu un élément fédérateur au sein de la DOSI de l’établissement en plus d’un
outil de gestion du SI (Annexe 1).
L’adhésion a d’abord été faite autour des pôles directement impliqués par les applications de gestion pour
un besoin de contrôle et d’information. Elle s’est rapidement propagée aux équipes d’assistance pour ces
mêmes raisons et également pour un sentiment égalitaire face à la diffusion de l’information autour du SI.
Nous œuvrons pour que cet outil continue à rendre un service reconnu et de qualité à l’intérieur d’AMU
et si cela intéresse d’autres établissements nous serions ravis d’échanger pour partager.

JRES 2017– Nantes 10/12

Annexe
[1] Représentation de l’organisation et du fonctionnement de SIAMU

Bibliographie
C. LONGEPE, Le projet d’urbanisation du SI, Dunod, Paris 2001

JRES 2017– Nantes 11/12

Remerciements
Beaucoup de personnes ont pu participer à ce projet et nous remercions nos collègues sans qui nous
n’aurions pas pu avancer avec notamment :
― Sébastien Nguyen-tu pour les développements des cartographies, et du module d’habilitation ;
― Mathieu Molineris : pour sa réflexion sur l’aspect serveur et ses scripts de synchro entre Vcenter et
Siamu ;
― Dominique Lalot et David Pucelle pour l’intégration des événements dans l’ENT ;
― Stéphane Ritsch et Jérôme Robianno pour l’intégration des événements dans le site web ;
― Michel Aimar et Julien Camoin pour toutes leurs petites propositions d’améliorations ;
― Fabienne Lacoude pour son aide et ses relectures pour nos présentations ;
― Mathieu Dandonneau pour la traduction du résumé ;
― aux équipes de campus pour leurs idées et remarques ;
― et d’une façon générale à tous nos collègues de la DOSI qui ont pris part d’une façon ou d’une
autre à la généralisation de l’outil SIAMU dans notre université ;
― Christophe Saillard et Catherine Grenet, présidents de la session JRES « Maîtrise et
Administration du SI », pour toutes leurs remarques pertinentes qui ont grandement améliorées la
qualité de cet article.

JRES 2017– Nantes 12/12