RAPPORT D’ALTERNANCE

QUEL EST LE ROLE D’UNE TIERCE MAINTENANCE D’EXPLOITATION DANS

UN CONTEXTE D’INFOGERANCE ?

THIBAULT CHARMENSAT
CSIA 18-19 A
1
 REMERCIEMENTS

Je tiens tout d’abord à remercier Sopra Steria Infrastructure Management et plus particulièrement
Faten Abu Sway, Lilian Morinon et Aurélie Gapp pour avoir donné à mon souhait de reprise d’études
une teneur concrète. Sans ces personnes, je serais encore étranger au vocabulaire IT.

Je remercie l’équipe du Grand Lyon (avec une mention spéciale pour l’équipe Réseau : Gilles, Denis et
Jean-Yves) sans oublier les collègues de la TME pour leur pédagogie à mon égard, leur enthousiasme
et leur volonté presque louche d’avoir fait régner une ambiance agréable tout au long de cette année :
Jocelyn, Frédérique et Fayssal notamment. Merci de m’avoir montré qu’il était possible de passer 8
heures devant un écran et de pouvoir rallumer son PC le soir.

Je remercie également l’établissement Sciences-U via Lucie de Sousa pour avoir accéleré mon
admission malgré mon entreprise tardive, Guillaume Noël pour m’avoir montré ce qu’était qu’un
véritable informaticien, pour de vrai, ainsi que le corps enseignant. Je pense notamment à Michel
Prézelin, Jonathan Blanchard et Fabrice Mancon qui m’ont permis de comprendre petit à petit le
contenu des conversations de mes collègues.

Finalement je remercie mes proches, Marion, Simon et Louis, qui m’ont soutenu dans ce pari osé et
qui ont su rester de marbre au regard de ma mutation vers une espèce d’étudiant informe et mal rasé
qu’ils ne connaissaient pas jusqu’alors. Merci à vous trois pour votre patience. Sans votre écoute
régulière et vos bons conseils, j’aurais sans nul doute repris l’entreprise viticole familiale depuis.

2
1 LES PARTIES PRENANTES DE LA PRESTATION ............................................................................................................ 8
1.1 SOPRA STERIA GROUP ......................................................................................................................................... 8
1.1.1 Présentation.................................................................................................................................................. 8
1.1.2 Les marchés ou Business Unit (BU) .............................................................................................................. 8
1.1.3 Infrastructure Management (I2S) ................................................................................................................. 9
1.1.4 Stratégies et problématiques liées à la concurrence .................................................................................... 9
1.2 LE GRAND LYON ................................................................................................................................................. 11
1.2.1 Présentation et compétences ..................................................................................................................... 11
1.2.2 Environnement ........................................................................................................................................... 11
1.2.3 La DINSI ...................................................................................................................................................... 13
1.3 L’INFOGERANCE DES INFRASTRUCTURES DU SI DU GRAND LYON ............................................................... 14
1.3.1 Périmètre technique et fonctionnel ............................................................................................................ 14
1.3.2 Les processus .............................................................................................................................................. 15
1.3.3 Les objectifs de la prestation ...................................................................................................................... 16
1.3.4 Responsabilité de l’infogérant .................................................................................................................... 16
1.3.5 Cycle de vie de la prestation ....................................................................................................................... 17
2 LA TIERCE MAINTENANCE D’EXPLOITATION ............................................................................................................. 18
2.1 LES POLES OPERATIONNELS............................................................................................................................. 18
2.1.1 Pôle N1 ........................................................................................................................................................ 18
2.1.2 Pôles N2 ...................................................................................................................................................... 22
2.1.3 Pôle N3 ........................................................................................................................................................ 25
2.1.4 Pilotes de production (PP) .......................................................................................................................... 26
2.1.5 Autres équipes ............................................................................................................................................ 26
2.2 La gouvernance de la prestation .......................................................................................................................... 27
2.2.1 La relation Sopra Steria – Grand Lyon ........................................................................................................ 27
2.2.2 Les activités de gouvernance (pilotage) ..................................................................................................... 28
2.2.3 Les instances de pilotage ............................................................................................................................ 33
2.2.4 Les indicateurs et pénalités ........................................................................................................................ 35
2.2.5 Les différents Plans ..................................................................................................................................... 40
3 REGARD CRITIQUE SUR LA PRESTATION ................................................................................................................... 42
3.1 Le projet SI............................................................................................................................................................ 42
3.1.1 Le contexte ................................................................................................................................................. 42
3.1.2 Les raisons de non-résolution de ce projet ................................................................................................. 42
3.2 Apports personnel et professionnel ..................................................................................................................... 43
3.3 Les limites de la prestation ................................................................................................................................... 44
3.3.1 La recherche de la performance ................................................................................................................. 44
3.3.2 La spécialisation du travail .......................................................................................................................... 45
3.3.3 La transversalité .......................................................................................................................................... 45
3.3.4 La coordination des activités ...................................................................................................................... 46
3.4 Analyse globale de la prestation .......................................................................................................................... 46

3
 INTRODUCTION

A la veille de ma reconversion professionnelle dans le secteur informatique j’ai fait le choix de solliciter
Sopra Steria Group et particulièrement la section Infrastructure Management (I2S) afin
d’accompagner ma formation au sein du groupe Sciences-U.

C’est sur l’infogérance du Grand Lyon La Métropole que j’ai eu l’opportunitié d’appréhender et
d’évoluer au sein d’un Sytème d’Information (SI) à échelle régionale et à rayonnement Européen. J’y
ai découvert les différents processus mis en place par la Direction de l’Innovation Numérique et des
Systèmes d’Information (DINSI) en collaborant avec les membres de la Tierce Maintenance
d’Exploitation (TME) pour le compte de la Tierce Maintenance d’Application (TMA).

En point final de mon année d’alternance, j’ai choisi d’étendre la rédaction de ce rapport au rôle d’un
infogérant plutôt que de me restreindre aux missions qui m’étaient confiées. Cette étude détaillée me
servira d’une part pour ma culture personnelle et d’autre part pour mon prochain poste.

Mes sources ont été l’étude de documents internes à l’entreprise Sopra Steria et au Grand Lyon, des
comptes-rendus d’instances et d’activité. J’ai également mené pour le bien de ce rapport des
interviews auprès des différents membres de l’équipe.

Certaines informations de ce rapport, présentées de façon sous-entendue, explicite ou masquée sont

strictement confidentielles. La diffusion de ce document est limitée aux membres du jury et aux
responsables des sociétés Grand Lyon et Sopra Steria Group.

Présenté comme une étude de cas sur l’infogérance dans un contexte de marché public, ce rapport
d’alternance détaille les missions de la TME et apporte une analyse critique sur les activités
opérationnelles et de gouvernance de cette prestation du point de vue d’un Adminstrateur Réseau &
Système.

A travers ce travail d’analyse, j’ai cherché à interroger le rôle et les enjeux d’une Tierce Maintenance
d’Exploitation dans un environnement d’infogérance d’infrastructures.

Dans une première partie, je présente les parties prenantes de la prestation : Sopra Steria, mon
employeur et infogérant, et le Grand Lyon, entreprise cliente. Je conclue la première partie par une
approche descriptive de la prestation Opérations SI au sein de la DINSI : présentation de
l’environnement technique, des processus mis en place et des objectifs attendus par le Grand Lyon.

La deuxième partie, cœur de ce rapport, se décompose en deux sous-parties. La première que l’ont
pourrait qualifier d’opérationnelle et la seconde qui porte sur l’aspect gouvernance au sein de la TME.
Je précise également le rapport relationnel entre le client et l’infogérant en détaillant les modalités
d’engagements de service et de pénalités. J’ai fait le choix d’accorder un intérêt à cette dernière sous-
partie car mon prochain poste d’alternant au Master portera sur cet aspect là.

La troisième et dernière partie expose mon analyse globale de la TME, l’existence d’un projet ainsi que
les raisons de sa non résolution, mes impressions personnelles et générales sur la prestation.

Je conclue ensuite ce rapport par une ouverture sur d’autres formes d’infogérance

4
 PREAMBULE
DEFINITION D’UNE INFOGERANCE
Les responsables de projets adoptent une démarche d’amélioration continue tant au niveau des
méthodes de travail, du management ou des processus , que des services rendus aux utilisateurs. Que
ce soit dans un contexte de mutualisation, de restructuration ou d’une simple volonté de mieux faire,
la mise en place d’une infogérance est nécessaire car elle permet à une entreprise cliente de sous-
traiter tout ou partie de son activité.

Ces responsables visent à optimiser leurs ressources dans la gestion des services informatiques,
classifiée comme référence de bonnes pratiques.

La structure dans laquelle j’ai effectué ma reconversion professionnelle s’inscrit pleinement dans cette
démarche. Le Grand Lyon utilise l’infogérance dans plusieurs contextes : tout au long du cycle de vie
des applications métiers, dans la gestion de ses serveurs ou de son parc informatique.

Il existe plusieurs formes d’infogérance suivant le niveau d’implication de l’entreprise prestataire chez
l’entreprise cliente :

L’infogérance globale : l’entreprise confie l’intégralité de la gestion de son Système d’Information

(SI) à une entreprise tierce. Tout les services sont sous-traités : le développement, la mise en œuvre,
l’exploitation, que cela concerne l’infrastructure technique comme les solutions logicielles.

L’infogérance partielle ne concerne qu’une partie du SI :

On y trouve ainsi des contrats d’infogérance applicative, qui englobent le développement, la

maintenance, l’exploitation et l’évolutivité du patrimoine logicielle de l’entreprise.

L’infogérance peut également concerner uniquement l’exploitation. Il s’agit donc de l’hébergement

et de l’exploitation des systèmes et applications de la société cliente qui sont confiés au prestataire.

L’exploitation réseau aura pour but notamment de gérer les interconnexions et les applications reliant
les différents sites de l’entreprise ainsi que d’assurer la sécurité et la qualité de service de l’architecture
en place et les flux échangés.

Les types d’infogérances partielles les plus utilisées sont les suivants :

L’hébergement de services : cela englobe les moyens mis en œuvre pour offrir une expérience fluide
et performante d’un logiciel à un client en s’affranchissant des contraintes de mise en place d’un
hébergement d’une solution, de mise en service et de maintenance.

Les gestion des applications : l’entreprise prestataire va être engagée à fournir des ressources
réalisant le déploiement, l’intégration et la mise en service des applications, ainsi que que le
déploiement des correctifs.

La gestion d’infrastructures : il s’agit ici d’effectuer la maintenance du parc informatique, des

serveurs et équipements composant le réseau ainsi que de la supervision de ces matériels.

C’est sur la gestion d’infrastructures que portera ce rapport.

5
 GLOSSAIRE DES ACRONYMES
AI Assistant Informatique

AWS Amazon Web Services

BAL Boite Aux Lettres (boite mail)

BDD / DBA Ligne technique Base de Données / Database

BU Business Unit

CGR Conseil Général du Rhône

COPIL Comité de Pilotage

COSTRA Comité Stratégique

CGH Comité de Gouvernance Hebdomadaire

CS Convention de Service

CTO Comité Technique Opérationnel

DAAG Direction Adjoint Architecte et Gouvernance

DARBO Direction Adjointe Relation Bénéficiaires et Opérations

DASIM Direction Adjointe Systèmes d’Information Métiers

DAUSN Direction Adjointe Usages et Services Numériques

DEES Développement Econonique, Emploi & Savoirs

DINSI Direction de l’Innovation Numérique et des Systèmes d’Information

DM Dossier Mainteneur

DMIT Demandes de Moyen Informatique et Telecom

DSIT Direction des Systèmes d’Information et Télécommunications

EAP Ligne technique Exploitation d’Environnements Applicatifs

ESN Entreprise de Services du Numérique

FM Fait Marquant

FS File System

GCP Google Cloud Platform

GDC-B Gestion des Demandes de services Complexes cataloguées (catégorie B)

GDC-C Gestion des Demandes de services Complexes devisées (catégorie C)

GDS-A Gestion des Demandes de services « Standards » (catégorie A)

GDO Gestion des Demandes Opérationnelles

6
GMEP Gestion des Mises en Production

I2S Infrastructure Security & Services

ID Intervention Déléguée

IT Information Technology

ITIL Information Technology Infrastructure Library

MCO Maintien en Condition Opérationnelle

MP Mode Projet

MS Ligne technique Microsoft

PCQ Point de Coordination Quotidien

PA Plan d’Autonomie

PAQ Plan d’Assurance Qualité

POP Point of Presence

PR Plan de Réversibilité

PP Pilote de Production

REVO Revue d’un plan (PR, PA, etc.)

RH Ressources Humaines

RMA Return Merchandise Authorization

RPG Reporting

RS Réseau & Sécurité

SDM Service Delivery Manager

SI Système d’Information

SVP Contact Informatique de la Métropole (CIME)

TMA Tierce Maintenance d’Application

TME Tierce Maintenance d’Exploitation

TL Team Leader

TO-SDM / TO-EOP Turn Over - Service Delivery Manager / Turn Over - Equipe Opérationnelle

ULVS Unix Linux Virtualisation Stockage

UO Unité d’Œuvre

7
1 LES PARTIES PRENANTES DE LA PRESTATION
1.1 SOPRA STERIA GROUP
1.1.1 Présentation
Sopra Steria Group est né de la fusion-absorption en 2014 de deux des plus anciennes Entreprises de
Services du Numérique (ESN) françaises : Sopra Group et Groupe Steria, fondées respectivement en
1968 et 1969. La SOciété de PRogrammation et d’Analyses (SOPRA) et la SociéTé d’Etude et de
Réalisation en Informatique et Automatisme (STERIA) ont toutes deux été marquées par un fort esprit
entrepreneurial puisqu’elles n’ont cessées depuis 50 ans de se développer sur des projets d’envergure
et d’acquérir de nombreuses sociétés d’informatique.

A titre d’exemple, les projets phares et historiques des deux sociétés sont : l’informatisation de l’AFP
en 1973, le concours au développement du Minitel en 81, l’ automatisation du RER A en Ile de France
en 1987, la proposition du premier logiciel bancaire, la conception du SI de l’aéroport de Jakarta en
1993 etc.

Sopra Steria figure parmi les principales entreprises françaises de services en informatique. Le groupe
est présent dans 25 pays avec près de 45.000 collaborateurs.

En 2018, son Chiffre d’Affaires (CA) était de 4.1 Milliards avec une croissance de 4.9% par rapport à
l’année précédente et a presque doublé en 5 ans.

La répartition géographique du CA se découpe comme suit : France (41.%), Royaume Uni (19.1%) et
reste de l’Europe (39.4%).

Figure 1 : Evolution du CA de Sopra Steria Group (en milliers d’€)

1.1.2 Les marchés ou Business Unit (BU)

Le Groupe s’affirme comme étant l’un des leaders Européen de la transformation numérique de ses
clients. Son activité s’articule essentiellement autour de 3 pôles :

Les prestations de conseil

Sopra Steria Consulting, cabinet de conseil Européen, fournit des prestations de conseils stratégiques
dans la mise en œuvre de projets de restructuration organisationnelle et d’évolution vers les nouvelles
technologies. Il accompagne ses clients dans l’identification, la conduite et la conception de leurs
grands projets de transformation digitale.

8
L’Intégration de solutions et de systèmes
Le cœur de compétences s’organise autour de la conception et le déploiement de solutions en
technologie internet (sites marchands, intranets, extranets, etc.), l’intégration de solutions ERP et la
mise en place de solutions applicatives (gestion de la relation client, RH, etc.).

Fort d’une politique industrielle historique, le groupe axe sa stratégie sur la construction, le maintien
et la modernisation des systèmes d’information en réponse aux transformations des entreprises.

Il propose également des solutions d’externalisation dans le support technique auprès des utilisateurs
et de maintenance corrective des applications.

Prestations d’infogérance et exploitation des processus métiers

Les infogérances de Sopra Steria regroupent la supervision, l’adminisitration et l’exploitation des
infrastructures informatiques et bénéficient d’une expertise dans les domaines tels que le big data, le
cloud, les réseaux collaboratifs, la mobilité ou encore la cybersécurité.

1.1.3 Infrastructure Management (I2S)

Cette structure a été rachetée à l’origine par Steria en 1997 et conserve son indépendance depuis son
acquisition par Sopra.

C’est maintenant la seule structure du groupe sur la région Rhône-Alpes qui accompagne la
transformation des infrastructures et des modes de consommation des services d’Information
Technology (IT) par notamment l’intégration de technologies et l’opération de services autour du
Cloud, du Datacenter et de l’environnement de travail de l’utilisateur.

C’est via cette filiale que j’ai été amené à travailler sur l’infogérance du Grand Lyon.

1.1.4 Stratégies et problématiques liées à la concurrence

Le secteur des ESN représente 56.3 milliards d’euros et près de 474.000 emplois pour 28.000
entreprises en 2018 en France d’après le Syntec Numérique.

C’est un secteur très concurrentiel qui affiche une forte croissance moyenne de +4.1% par rapport à
l’année précédente et qui s’explique principalement par une cadence soutenue des projets de
transformation numérique (notamment dans les domaines du conseil technologique et de l’édition de
logiciels).

9
Ce marché est dominé par de grandes entreprises telles que Capgemini, IBM, GFI, Econocom, etc.

Figure 2 : Classement 2018 des ESN selon leur CA France

La plupart de ces entreprises est présente dans la région Rhône-Alpes et se dispute les différents
marchés, appels d’offre ainsi que les profils de candidats qui se font parfois rares selon les métiers. Les
recruteurs doivent donc s’adapter pour faciliter les embauches. Ils multiplient les moyens de sourcing
et mobilisent largement les différents canaux de recrutement qui permettent une approche moins
classique mais plus directe des candidats (LinkedIn, Viadeo, APEC, etc.).

Les différentes entreprises de services du numérique se distinguent donc selon les marchés qu’elles
occupent et leur maitrise des technologies.

Sopra Steria axe sa stratégie sur les technologies du cloud ainsi que les missions « Devops » mais dans
la région elle possède aussi de nombreuses missions de maintien d’infrastructures et de conseils.

Le Groupe a aussi l’ambition de développer un centre de compétences afin de former en interne ses
collaborateurs sur les technologies innovantes.

C’est ce que j’ai pu observer notamment au sein de la TME cette année pour certains membres de
l’équipe (formations Docker, DevOps, AWS, GCP).

10
1.2 LE GRAND LYON
1.2.1 Présentation et compétences
Le Grand Lyon La Métropole (ou Métropole de Lyon) est né le 1er janvier 2015 de la fusion de la
Communauté Urbaine de Lyon et du Conseil Général du Rhône (CGR).

Il est soumis au respect des lois et directives qui régissent les collectivités locales et la fonction
publique territoriale.

La Métropole assume toutes les compétences exercées auparavant par la Communauté Urbaine de
lyon et le département du Rhône ainsi que des compétences supplémentaires provenant des 59
communes.

Voici quelques unes de ces compétences :

Compétences issues du Compétences issues de la Autres compétences prévues

Département Communauté Urbaine par la loi
Insertion Aménagement urbain Création et gestion
d’équipements culturels
Logement et développement Habitat et logement Construction et entretien des
urbain réseaux très haut débit
Collèges Développement durable et Concession de distribution
énergie d’électricité de gaz
Culture et sport Transports et mobilité Participation à la gouvernance
des gares
Aménagement du territoire Développement économique Co-pilotage des pôles de
compétitivité
Voirie Relations internationales Création et entretien des
services pour les véhicules
électriques

1.2.2 Environnement
Plus de 8000 collaborateurs sont structurés en délégations et directions, tous placés sous la
responsabilité de la Direction Générale représentée par le président de la Métropole. Le budget de la
Métropole s’élevait à sa création en 2015 à 3 milliards d’euros.

Les utilisateurs du système d’information sont répartis sur l’ensemble des sites du territoire de la
Métropole.

11
Figure 3 : Organigramme simplifié de la Métropole de Lyon

Lors de la transormation de la Communauté Urbaine du Grand Lyon (absorbant une partie du Conseil
Général du Rhône), la Direction des Systèmes d’Information et Télécommunications (DSIT) est
devenue la Direction de l’Innovation Numérique et des Systèmes d’Information (DINSI).

Les impacts majeurs de cette transformation ont été :

 Une augmentation de la population

▪ La DINSI regroupe désormais 200 personnes
▪ Un nombre d’utilisateurs porté à plus de 10.000 personnes
▪ Une répartition géographique sur plus de 300 sites

 Une extension du périmètre applicatif

▪ Prise en charge d’applications métier propres aux nouvelles activités issues du CGR : SI
social, collèges, culture, etc.
▪ Intégration de nouvelles spécificités et données : RH, gestion de projets, voirie, etc.

 Extension du parc informatique

▪ La DINSI compte aujourd’hui 15.000 postes de travail
▪ Et plus de 400 serveurs virtuels sur une centaine de serveurs physiques

 Evolution du socle technique

▪ Remplacement de l’environnement Novell par Microsoft (sur les serveurs de fichiers,
messagerie et système d’impression)

12
 1.2.3 La DINSI
La DINSI fait partie de la délégation Développement Econonique, Emploi & Savoirs (DEES) [Figure 3]
et assume plusieurs missions :

 La gestion globale des systèmes d’information

 La gestion des usages numériques
 La gestion des données appartenant au Système d’Information Géographique (SIG)
 La gestion des infrastructures téléphoniques fixes et mobiles et des systèmes de câblage
 La relation opérationnelle avec les directions du Grand Lyon

Ces missions sont réparties au sein de 4 Directions Adjointes :

Architecte et Gouvernance (DAAG), service transverse en charge de l’architecture, l’urbanisme, la

qualité et les processus, la sécurité et la gestion du portefeuille de projets

Usages et Services Numériques (DAUSN) en charge des activités numériques et des données du
Système d’Information Géographique (SIG)

Systèmes d’Information Métiers (DASIM) en charge de l’intégration SI, du Patrimoine SI et des

Projets SI

Relation Bénéficiaires et Opérations (DARBO) regroupe la Relation Opérationnelle avec les

Directions du Grand Lyon ainsi que les Services de Proximités et les Opérations SI

Figure 4 : Organigramme de la DINSI

Le découpage structurel de la DINSI permet une meilleure efficacité dans les relations entre les
personnes internes et les prestataires par la réalisation d’un plan de charge annuel, la mise en œuvre
d’une communication régulière et l’incitation au travail en équipe.

J’ai apporté mon concours à la gestion globale des Systèmes d’Information au sein de la DARBO et
plus précisément du service Opérations SI. [Figure 4]

13
Ce service est constitué de 3 unités :

 Systèmes partagés : Unix, Linux, VMWare, Stockage, Microsoft, Sauvegarde,

ordonnancement et bases de données
 Réseaux et Télécoms : Réseaux LAN et WAN, systèmes de sécurité et téléphonie
 Systèmes personnels : postes de travail, impression et autres périphériques

Chacune de ces unités est dirigée par un responsable d’unité et de plusieurs pilotes de productions.

1.3 L’INFOGERANCE DES INFRASTRUCTURES DU SI DU GRAND LYON

1.3.1 Périmètre technique et fonctionnel
Le Grand Lyon (via la Comunauté Urbaine de Lyon) externalise depuis une quinzaine d’années les
activités opérationnelles d’exploitation des applications et des infrastructures ainsi que les activités
liées aux évolutions de son Système d’Information (mises en production, évolution d’applications
existantes, etc.).

Le parc informatique regroupe plus de 200 applications métier supportées par une infrastructure
composée de plus de 400 serveurs virtuels aux environnement informatiques distribués sur plus de
300 sites reliés entre eux.

On recense 3 salles serveurs principales qui accueillent les équipements réseau et télécom, les fibres
optiques (FO), les connectiques opérateurs, le stockage informatique et le système téléphonique
central du Grand Lyon.

D’autres points utilisés pour l’interconnexion avec les sites historiques sont appelés Point Of Presence
(POP).

Ces sites reliés ensemble représentent le cœur de réseau du Grand Lyon. Ce réseau informatique
fédéral porte le nom de réseau Mercure (hérité du projet : Mise En Réseau de la Communauté
Urbaine).

Il a la structure principale d’un réseau Ethernet métropolitain.

Pour des raisons de confidentialité, je n’ai pas l’autorisation de détailler d’avantage cette partie.

Les différents sites distribués se distinguent en plusieurs catégories, classées par ordre d’importance :

 Les sites connectés directement au réseau de la Métropole (fibre appartenant au Grand Lyon
ou loué à un prestataire comme Covage mais propriétaire du Grand Lyon), ce sont
généralement les sites dits « décisionnels » de la Ville,
 Les sites opérés (Amplivia, Numericable etc.), ce sont des sites de moyenne importance
comme les collèges ou les subdivisions (Maisons de la Métropole, musées, etc.)
 D’autres sites plus petits en taille et d’importance moindre sont eux autonomes (connectés à
Internet via une « box » opérateur), on trouve dans cette catégorie les dépôts de voirie ou les
DSU (Développement Social Urbain).

14
Le périmètre fonctionnel est composé de 3 lignes de services applicables sur un périmètre technique.
Les trois lignes de services sont les suivantes:

 Le service récurrent comprenant le MCO, la GDO et les GDS standards (catégorie A)

 Le service à la demande comprenant les GDS ou complexes cataloguées (B et C), la gestion
des problèmes GDP, assimilées GDC-C, les gestions de mises en production GDMEP,
assimilées GDC-C et les études et projet techniques (MP)
 Le service « gouvernance de la prestation »

1.3.2 Les processus

La DINSI est ancrée dans une organisation orientée bénéficiaires et culture de services. Ce qui signifie
que la démarche de pilotage par les processus fait partie de sa stratégie d’amélioration de sa valeur et
de sa performance. Parmi les processus mis en place, certains sont issus de l’Information Technology
Infrastructure Library (ITIL) v3 notamment ceux concernant l’exploitation des services.

On dénombre 4 processus pour cette prestation qui seront détaillés en 2.1. Les pôles
opérationnels, classifiés par le Grand Lyon en services récurrents ou « à la demande » :

Le Maintien en Condition Opérationnelle (MCO) consiste à garantir la disponibilité, la fiabilité et la

pérennité des infrastructures au regard de la satisfaction des utilisateurs. Il implique notamment les
activités comme la communication en temps réel, la supervision des équipements, la gestion des
configuration, des connaissances, de la performance, de la sécurité, etc.

La Gestion des Demandes Opérationnelles (GDO) couvre le périmètre suivant : incidents

utilisateurs, création de Faits Marquants (FM) relatifs aux incidents liés aux plateformes et services
d’infrastructure, aux bases de données et aux environnements applicatifs, les interventions déléguées
(ID) aux équipes applicatives, les dossiers mainteurs (DM) qui permettent l’escalade technique vers
des mainteneurs tiers comme des opérateurs réseaux (Amplivia, Numericable, Completel), etc.

La Gestion des Demandes de services (GDS) a pour objectif de détecter et limiter les impacts
utilisateurs. Son adaptation sur le modèle ITIL est à ce jour en cours.

Elle regroupe 6 catégories : les demandes de services en « temps réel », les Demandes de services
Standards catégorie A (GDS-A) ayant un impact maîtrisé et de moins d’une heure de charge, les
Demandes de services Complexes catégorie B (GDC-B) cataloguées et à charge identifiée et les
demandes complexes catégorie C (GDC-C) non cataloguées et à charge non identifiées, les Demandes
de Moyen Informatique et Telecom (DMIT) et les demandes SVP.

La gestion des Mises en Production (GMEP) n’existe officiellement pas. En effet, la mise en
production d’infrastructures et d’applications est gérée par le biais d’une ou plusieurs demandes de
services individuelles et non liées.

Ces processus résument l’activité des lignes techniques de la Tierce Maintenance d’Exploitation.

15
 1.3.3 Les objectifs de la prestation
Dans le cadre de cette démarche d’amélioration continue, la DINSI a délimité le cadre de travail de
l’infogérant. La prestation est dirigée par le respect de 5 objectifs associés à un niveau de priorité allant
de 1 à 3 :

Objectif 1 : Maitrise du coût direct et indirect des prestations produites

Cela concerne notamment la tenu des engagements pris en matière de MCO, de réalisation d’activités
confiées et nécessite de constituer un socle de compétences reconnues aux niveaux techniques,
fonctionnels et du pilotage. Le respect de ces processus opérationnels et de pilotage de la DINSI
possède également une priorité de niveau 1.

Objectif 2 : Assurer la qualité du service confié

Les priorités détaillées ci-dessus s’appliquaent aussi à ce thème.

Celles de niveau 2 impliquent d’anticiper les problèmes. La priorité de niveau 3 est d’industrialiser les
opérations et de capitaliser les bonnes pratiques.

Objectif 3 : Développer et maintenir une relation de confiance et contribuer au développement des

valeurs de la DINSI

Cela nécessite de maitriser la stabilité des ressources clés de la prestation et d’assurer la visibilité des
opérations pour le Grand Lyon.

Une des priorités de niveau 2 est de ne pas créer de relation de dépendance notamment par le
maintien à jour du plan de réversibilité pour la période de renouvellement. [Figure 5]

Objectif 4 : La prise en compte des évolutions de l’environnement du Grand Lyon implique de

maintenir à niveau les compétences de l’équipe TME et de prévoir une adaptabilité en fonction
d’éventuelles évolutions organisationnelle et technologique.

Objectif 5 : La contribution à l’amélioration opérationnelle de la DINSI nécessite de maintir les

référentiels à jour comme les procédures d’installation, les bases d’activité ou de gestion de parc
informatique (PC, imprimantes).

1.3.4 Responsabilité de l’infogérant

Cette responsabilité s’applique sur le périmètre cité ci-avant. En l’occurrence la gestion
opérationnelle, la prise en charge de l’activité, le maintien à jour des documentations techniques et
opérationnelles, la capitalisation des bonnes pratiques, le reporting d’activité, la production des unités
d’œuvre (UO) de facturation et des indicateurs de suivi et le pilotage de la prestation.

16
 1.3.5 Cycle de vie de la prestation

Figure 5 : Cycle de vie de la prestation

La prestation se distingue en 3 phases :

La phase probatoire comprend une période de prise de connaissance et une période de transition.
Elle permet au prestataire d’assurer sa prise de fonction et de s’approprier l’environnement
organisationnel et technique de la prestation. Elle met en œuvre les solutions techniques et pré-requis
logistiques qui soutiennent la prestation. Elle sert au transfert des compétences afin d’atteindre une
autonomie suffisante et nécessaire au bon déroulement de la prestation. Cette phase a une durée de
2 mois.

Cette phase ne sera pas détaillée dans ce rapport.

La phase de régime établi couvre l’intégralité des services durant la totalité de la prestation et répond
aux objectifs fixés par le Grand Lyon (diminution des coûts de production, augmentation de la
réactivité de prise en charge d’évènements, diminution de la durée des traitements, etc.)

La phase de reversibilité se réserve un délai de 2 mois permettant au prestataire actuel de transférer

les prestations réalisées vers un tiers. Contrairement à ce que sous-entend la figure 5, cette phase se
déroule en parallèle du régime établi. Elle a pour rôle de restituer l’ensemble des moyens développés
par le prestataire au cours de la totalité de la prestation (documents, consignes, scripts, programmes),
de transférer les compétences mais aussi la responsabilité opérationnelle des actions en cours. Le plan
de réversibilité détaille ces actions.

17
2 LA TIERCE MAINTENANCE D’EXPLOITATION
2.1 LES POLES OPERATIONNELS

Figure 6 : Le fonctionnement de la prestation

2.1.1 Pôle N1
Le niveau 1 correspond au pôle transverse. Il a été créé à l’initiative de l’ancien Service Delivery
Manager (SDM) que je n’ai pas connu. L’objectif de cette mise en place était d’alléger la charge des
équipes N2 concernant noamment les tâches répétitives peu complexes. Ce qui en fait un pôle aux
compétences transversales puisque les membres sont amenés à traiter des tickets ayant trait aux
environnement Microsoft, Linux ou Unix et demandent également des connaissances en Réseau et
Sécurité.

Le rôle principal de ce pôle est la réception, la qualification et le routage aux équipes concernées de
dossiers et d’incidents reçus dans l’outil de ticketing Asset Manager ainsi que par mail ou téléphone.
Le N1 supervise également via l’outil Nagstamon les équipements réseaux et les serveurs de La
Métropole.

Les membres de ce pôle sont en charge d’actions simples, procédurées ne demandant pas une forte
expertise technique. Après plusieurs tests ou vérifications effectuées et si le problème persiste, le N1
escalade le sujet au Niveau 2 de la ligne technique concernée.

L’objectif des ressources intégrant le pôle Transverses est d’appréhender le Système d’Information
du Grand Lyon et de découvrir l’environnement technique sur lequel il s’appuie.

18
En acquérant une autonomie suffisante, il est ensuite possible de monter en compétences sur les
missions du Niveau 2 concernant les lignes techniques Réseau&Sécurité (RS), Microsoft (MS), ou Unix
Linux Virtualisation et Stockage (ULVS).

Gestion des demandes « Temps réel »

Les demandes « Temps réels » sont des demandes caractérisées par certains critères. Elles peuvent
être ensuite orientées vers le bon pôle par l’équipe transverse :

 Demandes nécessitant une compétence minimale

Ces demandes rythment le quotidien des membres du pôle transverse :

▪ Arrêt/relance d’un service sur un serveur Linux ou Microsoft,

▪ Mise en production déguisée (copie, suppression de fichiers sur un serveur de
production),
▪ Demande d’information simple dont la charge ne dépasse pas 15 minutes et ayant un
impact maitrisé (vérification de postes sur le serveur DHCP, de ports libres sur un switch,
etc.).

 Incidents sur l’infrastructure entrainant une dégradation ou une interruption de service

Le traitement de ces incidents est procéduré est repose sur une bonne communication de
l’information par un système d’escalade organisationnelle.

▪ Une escalade, si nécessaire, auprès du Team Leader est effectuée si la problématique est
complexe ou dure un certain temps
▪ La création systématique d’un ticket (FM) si la charge dépasse 5 minutes est effectuée afin
de tracer et permettre un suivi de l’incident

 Prise d’appel du téléphone de permanence et gestion du bipper.

Dans un environnement de production, la réactivité est primordiale sur la plage définie
contractuellement par le Grand Lyon. [Figure 7]

 Préparation et participation au Point de Coordination Quotidien (PCQ)

Celui qui est présent au PCQ doit avoir les informations nécessaires à son bon déroulement puisqu’il
est en contact direct avec les équipes N2 et les Pilotes de Production (PP) de chaque ligne de service,
cela implique d’être au courant des sujets en cours afin de pouvoir partager les informations, réaliser
un suivi des incidents et apporter des précisions si nécessaire.

 Routage des dossiers d’incident via l’outil de « ticketing »

Contrôle de l’outil obligatoire sur la plage de production : 8h-12h ; 13h-17h30. [Figure 7]

Maintien en condition opérationnelle (MCO)

Le Maintien en Condition Opérationnelle de l’infrastructure englobe les différentes missions
permettant d’anticiper les incidents ainsi que les tâches permettant de garder l’infrastructure dans un
état fonctionnel. Cela implique une attitude active sur l’outil de supervision Nagstamon par le
traitement d’alertes classées en WARNING, CRITICAL ou DOWN et une réactivité importante. Il

19
nécessite également l’utilisation d’une boîte mail (BAL) commune aux équipes de la TME et TMA
consultée occasionnellement par les différentes lignes de service. Il a un rôle de recherche et
d’information auprès des personnes concernées.

Les mission afférentes au pôle transverse sont les suivantes :

 Exécution du plan de production

L’éxecution du plan de production consiste à effectuer des vérifications et des mises à jour afin de
tenir l’infrastructure dans le meilleur état possible. Des tâches sont effectuées de manière
quotidienne, hebdomadaire, mensuelle et trimestrielle.

 Supervision :
Un Point de Situation du Matin (PSM) permet de vérifier les éléments cruciaux de l’infrastructure et
de communiquer aux différentes équipes les problèmes ou anomalies de la veille. La mise en place
d’un Point de Situation du Soir (PSS) proposée par le Team Leader (TL) a également été mis en place
pendant l’année, permettant notamment de relever des alertes étant apparues un laps de temps court
dans la journée.

Le traitement des alertes remontées par les outils de supervision ainsi que celles remontées par mail
sur la BAL partagée fait partie de la supervision.

 Gestion de configuration et des inventaires

Cette gestion permet de maintenir à jour les descriptifs des équipements et ainsi d’être au fait des
évolutions de l’infrastructure.

 Gestion de la connaissance
Via la mise à jour des documentations et des consignes ainsi que le suivi de l’exécution du plan de
production, l’autonomie des membres du pôle en termes de compétences est maintenue.

 Création systématique d’un ticket

A chaque dysfonctionnement constaté lors des tâches citées ci-avant, les informations relatives au
traitement sont inscrites dans les dossiers numérotés, permettant une base de connaissance
nécessaire à l’optimisation des traitements.

Gestion des incidents

La gestion des incidents concerne le traitement des dossiers remontés par l’outil de ticketing
entrainant un diagnostic, une résolution (qui sera validée avec le demandeur), une gestion de
configuration (inventaire, consigne) voire une escalade si nécessiare au niveau supérieur via le Team
Leader.

Toutes ces étapes doivent être consignées dans les dossiers permettant le suivi et le chiffrage du
temps passé par chaque personne active sur un ticket.

20
Ces incidents concernent surtout la partie Réseau et Sécurité comme par exemple l’analyse d’une
perte de réseau, de coupures régulières, de problèmes d’accès à une application, d’emails reçus (ou
non reçus) par les utilisateurs, de whitelistage d’URL, etc.

Gestion des demandes standards

Ces demandes regroupent le traitement des dossiers appelés « standard » car ils sont d’une part
récurrents et d’autre part nécessitent une action de moins d’une heure. Il faut pour cela effectuer une
analyse afin de caractériser la conformité de la demande :

 Analyse d’impact (risques encourus, interruptions de service, nombre d’utilisateurs impactés,

etc.)
 Validation de la demande (par le Niveau 2 ou un Pilote de Production selon la criticité)
généralement effectuée en PCQ
 Environnement impacté
 Réalisation de la demande
 Gestion de configuration (inventaires, éléments Asset, réversibilité, etc.)
 Escalade si nécessaire auprès du Team Leader ou de la ligne technique concernée

Toutes les étapes doivent être consignées dans les dossiers.

Ces demandes concernent en grande majorité la gestion du parc informatique de la Métropole par le
suivi des postes des agents ou utilisateurs (ajout/suppression dans le serveur DHCP, attribution
d’adresses IP), l’arrêt ou la relance de services, la restauration de fichiers ou répertoires, etc.

Figure 7 : Plage horaire de la TME

Les membres de chaque pôle alternent d’une semaine sur l’autre les rôles du matin ou du soir afin de
couvrir l’intégralité de la plage d’astreinte.

En règle générale, l’équipe du matin a un rôle axé sur la gestion des incidents (GDO) et MCO tandis
que l’équipe du soir s’occupe de la gestion des demandes de services.

21
 2.1.2 Pôles N2
Le niveau 2 correspond au socle technique sur lequel repose la plupart des résolutions des demandes
concernant l’infrastructure. Il existe une équipe N2 par ligne technique. Leur périmètre d’action est
très large au vu des nombreux domaines à maitriser pour le maintien en condition opérationnelle de
l’infrastructure.

Ce périmètre technique ou technologique est couvert par chaque pôle de compétences, chacun dirigé
par un Team Leader qui fait office de coordinateur technique. Ils sont au nombre de deux. L’un occupe
à mi-temps la partie EAP et BDD l’autre moitié du temps. Le deuxième gère les pôles MS et URX.

Ces lignes techniques sont au nombre de 5 :

 La ligne Réseaux & Sécurité (RS) qui couvre les aspects Réseau et Sécurité
 La ligne Unix Linux Virtualisation Stockage (ULVS) couvre les plateformes Unix, Linux,
Virtualisation et Stockage ainsi que les services d’infrastructure applicatifs associés
 La ligne Microsoft (MS) comprend les plateformes Microsoft et les services infrastructure et
applicatifs associés.
 La ligne Base de Données (BDD) couvre les environnements des services d’infrastructure de
bases de données Oracle, Sybase, MySQL et PostgreSQL.
 La ligne technique Exploitation (EAP) regroupe les environnements des services applicatifs
tels que l’ordonnanceur de traitements différés, les sauvegardes, les échanges de données.

En cas de problématique dépassant les compétences ou le périmètre des équipes, le N2 peut escalader
le sujet au Niveau 3 ou aux Pilotes de Production (PP).

Ligne technique URX (ULVS + RS)

Unix Linux Virtualisation Stockage (ULVS)
Cette ligne technique comptabilise une personne. La journée débute par du support incident.

Avant l’envoi des Points de Situation du Matin, elle doit produire un état des serveurs de production
Linux et Unix via l’outil Nagios en prévision du Point de Coordination Quotidien (PCQ). Pour cela, elle
crée un Fait Marquant (FM) ou déclenche une gestion de crise sur incident selon la gravité.

Dans ce dernier cas, l’incident est prioritaire sur les instances et elle doit apporter une résolution le
plus rapidement possible. En cas d’impossibilité de résolution (fort impact, risque non maîtrisé,
complexité dépassant le champ des compétences), elle peut faire une escalade au Niveau 3 et PP ou
à l’équipe applicative.

Le PCQ marque la priorisation des activités de la journée (reports éventuels de tickets, escalades,
relances équipes applicatives, etc.)

Le reste de la journée dépend des demandes ou incidents en cours. Cela peut concerner par exemple:

 Gestion des droits utilisateurs, création de compte et droits sur serveurs,

 Gestion de ressources (augmentation SAN sur serveur physique),
 Relance de services et débogage applicatif,
 Gestion DNS et DHCP (mises à jour des entrées DNS),
 Ajout/Modification de la supervision Nagios,
 Création d’environnements applicatifs (VM) : réservation d’adressage IP/adresses MAC, mise
en place de Virtual Machine à une date souhaitée par les responsables d’application,
 Déploiement applicatif (Apache, Tomcat, Ngynx, etc.)

22
Les actions de cette ligne technique peuvent également concerner le débogage de problèmes des
autres lignes techniques. Par exemple, le stockage VM pour le pôle MS (ajout d’espace pour éviter une
interruption de service ou une perte de données) ou Linux/Unix pour la ligne Exploitation, BDD (alertes
après un traitement et résolution immédiate possible ou simplement augmentation de file system).

Des points mensuels ont lieu avec les pôles N2 et N3 et Pilotes de Production permettant d’acquérir
de la visibilté sur les projets à venir, leurs impacts, les ressources nécessaires et les compétences
souhaitées. Ils permettent également d’affecter les ressources sur un projet ou même de
communiquer les nouvelles normes du Grand Lyon liées au SI (par exemple, nouvelle version de
RedHat pour les machines déployées impliquant des nouvelles règles sécurité SI). Ils ouvrent
également la possibilité de mener de nouvelles actions sur des projets en cours après les remontées
des responsables applicatifs.

Ils participent à l’évolution du SI : industrialisation (mise en place d’outils pour réaliser des tâches
simples et quotidiennes plus rapidement).

Réseau & Sécurité (RS)

Cette équipe compte une personne et demie. Elles s’occupent de la gestion du réseau Grand Lyon au
sens Mercure et hors Mercure en lien avec les Pilotes de Production. 1.3.1 Périmètre technique

L’environnement technique comprend des routeurs CISCO pour la distribution, des routeurs
principaux EXTREME pur le backbone et des switches provenant des deux constructeurs.

Les missions principales de cette ligne technique reposent sur le MCO, la gestion des inventaires des
équipements réseau, les installations, les migrations.

La GDO concerne les incidents réseau liés aux équipements et nécessite des investigations poussées
concernant des lenteurs, coupures ou dysfonctionnements.

Les Demandes Complexes regroupent l’exécutif (migration, ajout, modification des liaisons).

La ligne RS s’occupe également des interventions sur les sites afin de modifier ou remplacer tout ou
partie de l’architecture réseau :

Avant intervention

 Contrôle des équipements sous Nagios,

 Analyse d’impacts utilisateurs (diagnostics)
 Priorisation des interventions (définies en PCQ), mises en place d’un plan d’action (sites
décisionnels, VIP, etc.)
 Préparation de matériel en salle préparation

Durant l’intervention

 Modification de configuration,
 Communication auprès des utilisateurs

Post-intervention

 Reporting : mises à jour des schémas et inventaires,

 Réalisation de tests (iperf, ssh)
 Ouverture d’un ticket de Remise en Maintenance (RMA) chez un mainteneur tier.

23
Ligne technique Microsoft (MS)
Le pôle Microsoft est composé de 2 personnes.

L’environnement technique comprend des serveurs Novell et Microsoft 2000, 2003, 2008 R2 et 2012
R2.

En plus des processus que sont le MCO et la GDO, ils ont également un nombre d’heures
hebdomadaires réservées au traitement des Demandes Complexes cataloguées et devisées ainsi que
la gestion de projets d’industrialisation (automatisation par le scripting, notamment).

Au quotidien, leur périmètre concerne la gestion des serveurs applicatifs Microsoft (physiques et
virtuels).

Les Demandes Complexes sont poussées puis devisées par le Team Leader après consultation du
catalogue ou par le PP Microsoft.

Ils consultent également les équipes Exploitation et Réseau & Sécurité dans le cadre de leurs activités.

Les projets récents sur lesquels ils ont été amenés à travaillés sont des projets d’infrastructures
(virtualisation des serveurs), de migration WSUS (centralisation), de migration DHCP, de réplication
des contrôleurs de domaine, et globalement d’automatisation (scripting), etc.

Ils ont également un rôle important de reporting afin de capitaliser leurs expériences par le biais de
procédures leur permettant de s’affranchir des Demandes Standards et de se focaliser sur les
Complexes. Ce sont les membres du pôle N1 qui traitent la plupart des demandes standards leur
permettant ainsi une montée en compétences sur la ligne MS.

Ligne technique Exploitation d’environnements Applicatifs (EAP)

Le pôle Exploitation est composé de 2 personnes et demie et travaille en étroite collaboration avec
l’équipe DBA (DataBase). Ils gèrent au quotidien les incidents de production sur les applications métier
du Grand Lyon.

L’environnement applicatif concerne 200 applications pour 6000 traitements, dont HR Access,
Filigrane (Finance), PLU (Plan Local Urbain), SIG (Service Information Géographique), IODAS, etc.

L’environnement technique comprend les technologies suivantes : VTOM 6.2, ETL Sunopsis V3, CFT,
Solaris 9 et 10, AIX, Linux Red Hat, Windows 2008, 2012, Net Backup 8, Robot Symantec, SPIP,
Outlook, Asset Center, Stambia.

Leurs missions quotidiennes s’articulent autour du :

 Contrôle des traitements de jour et de nuit à l’aide d’un ordonnanceur (VTOM).

 Suivi, de l’analyse et correction des incidents N1/N2
 Gestion, planification et suivi des Demandes de services Standard et Complexe (Projet)
 Gestion des sauvegardes, du stockage et des restaurations : maintenance et incidents
 Gestion et normalisation de la documentation (plan de production)
 Suivi de l'activité et reporting auprès du Grand Lyon
 Initialisation et réalisation d'éléments du plan de progrès de l'exploitation sur le périmètre de
l'infogérance

24
Ligne technique Bases de Données (BDD ou DBA)
La ligne technique DBA ou BDD est composée de 2 membres et demi.

L’environnement technique comprend 140 bases Oracle (paie, GRH, IODAS : prestations RMI,
sociales, héritées du CGR) et MySql pour les principales (petites bases et nombreuses).

Les bases de données utilisées sont Oracle 9i, 10g, 11g et 12g ; postgreSQL 9.3, 9.6, 10 ; Sybase ;
MySQL 5041, 5521 et 5627, ESRI, APIC ; SQL Server 2012,2016

L’objectif du Grand Lyon à terme est de migrer vers les bases libres PostgreSQL.

Les premières missions de la journée de l’équipe sont de faire un contrôle d’incidents en analysant les
alertes dans l’outil Nagios : regarder les éventuels problèmes remontés dus aux traitements de nuit.

Ils sont contractuellement chargés de collecter les informations des différents PSM afin d’éditer une
synthèse de l’état du SI vers 8h30 qui servira de base pour le PCQ (indisponibilités, interruptions de
service, compte rendu de l’ordonnanceur).

Globalement, la majeure partie des missions de l’équipe BDD est d’étudier les différentes alertes
remontées par l’outil de supervision Nagios afin d’ajuster au mieux les seuils de criticité pour obtenir
des informations pertinentes.

En cas d’alertes révélées, ils peuvent procéder à une purge des données ou faire une demande
d’augmentation de FS auprès de l’équipe URX.

D’autres missions d’exploitation ou projets peuvent concerner les points suivants :

 Création/Suppression de FS pour des bases

 Création d’une base accompagnée d’un formulaire (type de serveur, version)
 Migration de données (paramétrages)
 Déploiement d’une nouvelle appli, migration, nouvel environnement de test
 Projets complexes : virtualisation de bases de données oracle
 Migration par rapport aux enchainements : amélioration des traitements d’exploitation
(industrialisation)
 Passage de scripts sur serveur de BDD (mises à jour, correctifs, montées ou changements de
version)

2.1.3 Pôle N3
Le Niveau 3 est essentiellement client. Il se compose des différents pilotes de production (côté Grand
Lyon) des différents domaines technologiques. Leur rôle est de piloter la prestation, en contrôlant les
indicateurs de performance, la facturation des différentes actions ainsi que la gestion des projets en
cours et à venir. Ils interviennent aussi durant toute décision ayant un impact significatif sur
l’infrastructure ou des ressources matérielles ou lors de conflits. Ils servent aussi d’interface entre les
décideurs et les utilisateurs du Grand Lyon.

Les autres membres du pôle travaillent sur des projets (MP) procédant notamment à l’amélioration
des services (industrialisation des process).

25
 2.1.4 Pilotes de production (PP)
Les pilotes de productions sont le point de contact unique par pôle pour la TME, ils gèrent le pilotage
opérationnel ainsi que le support N3 des incidents et des changements.

Ils sont aussi le point de contact unique pour les services bénéficiaires de la DINSI, pour la gestion des
changements ou les mises en production d’applications ou de services. Cela veut dire que la TME
n’aura des échanges concernant des spécificités techniques (concernant les demandes) qu’avec les
équipes applicatives et les utilisateurs du Grand Lyon. Les Pilotes de Production gèrent les
problématiques en interne.

Ils sont aussi en charge du suivi contractuel de la prestation, pour cela ils s’occupent de valider :

 Le Service Level Agreement (SLA) : c’est-à-dire les engagements de Sopra Steria à fournir un
engagement de service ainsi que les objectifs précis et le niveau de service attendu par le
Grand Lyon.
 Les éléments à facturer.
 La recette des éléments, services et applications produites par la TME
 Enfin ils sont garants du bon respect des processus et de la cohérence de la production.

2.1.5 Autres équipes

Certaines équipes sont des acteurs régulièrement en interaction avec les membres de la TME mais
n’en font pas partie. [Figure 6]

SVP
Communément appelée CIME, c’est le point de centralisation des demandes. Cette équipe effectue
un premier routage des dossiers et demandes des utilisateurs vers les bonnes équipes. Ils sont en
relation directe avec les utilisateurs du SI du Grand Lyon.

Assistants Informatiques (AI)

Les Assistants Informatiques des utilisateurs formulent des DMIT. Ce sont des demandes spécifiques,
non standards, qui demanderont une expertise et des compétences particulières. Ces DMIT doivent
être validées par les pilotes de production avant d’être réparties aux Team Leader puis aux équipes.

26
2.2 La gouvernance de la prestation
2.2.1 La relation Sopra Steria – Grand Lyon

Figure 8 : Les relations entre le GL et l'infogérant

Le Team Leader (TL)

Il est le manager référent des différentes équipes. Il suit et accompagne les équipes au quotidien dans
leur gestion des dossiers et projets. Il s’assure que la qualité de service est atteinte au quotidien et
distribue les tâches aux équipes. Il sert d’interface avec les pilotes de productions ainsi qu’avec le SDM.

Le TL (ou SDM adjoint) anime et participe aux instances suivantes : réunions d’équipe hebdomadaires,
Points de Coordination Quotidien (PCQ), Comités Techniques Opérationnels (CTO) et Comités de
Pilotage (COPIL).

Au quotidien, il regarde la planification afin de prioriser les actions des différents pôles sous sa
responsabilité. Il s’occupe également des suivis des demandes de reports des incidents auprès des PP
et est en relation avec les responsables applicatifs.

Ses compétences opérationnelles lui permettent de deviser les demandes complexes qualifiées par
les PP figurant ou ne figurant pas dans le catalogue mis à disposition par le Grand Lyon. Par exemple :
installation ESX, création de VM, remise à niveau des firmware, mise en production d’une application,
etc.

Toute Demande Complexe devient de catégorie C lorsqu’elle a un impact sur le planning. Par
exemple : mise à jour de cumulatifs, incidents / problèmes impossibles à corriger, etc.

Les instances comme le CTO permettent d’ajuster et recatégoriser les demandes par capitalisation
d’expérience (optimisation).

27
Le Service Delivery Manager (SDM)
Il supervise, et organise l’ensemble de la prestation afin de s’assurer qu’elle respecte les engagements
contractuels. Il participe aux comités décisionnels et se situe au plus haut sur le plateau de la TME. Il
s’appuie sur les différents Team Leader pour s’informer de l’avancement des dossiers et projets.

La gouvernance s’inscrit dans une logique d’amélioration continue qui est matérialisée par le Plan de
Progrès. Il est constitué de 3 processus : l’optimisation permanente, l’industrialisation et l’innovation.
[Figure 8]

Les missions du SDM sont notamment :

 Le pilotage de l’autonomie des collaborateurs et de la cohésion avec les équipes du

Grand Lyon
 Le pilotage stratégique, tactique et opérationnel
 Le pilotage du plan de progrès

Le Pilote de la prestation
Il supervise la prestation et vérifie si les engagements de service respectent les termes contractuels
établi entre le Grand Lyon et l’infogérant. Il participe aux instances décisionnels (Comités de Pilotage,
Comités Stratégiques) et contrôle mensuellement avec les Pilotes de Production ainsi que le SDM et
le TL la véracité des indicateurs de performance (engagements de service en lien avec l’activité de
pilotage ou des activités opérationnelles et les non conformités).

Il concourt au développement de la valeur globale de la DINSI auprès des différents prestataires du

Grand Lyon. Il maîtrise les coûts des différentes activités de la prestation (éléments de facturation)
par le biais d’Unités d’Œuvre (UO) et participe aux évolutions majeures du SI du Grand Lyon. C’est le
référent direct du SDM.

Les rôles de Niveau 2 et Niveau 3 [Figure 8] sont hors champ et ne seront pas abordés dans ce rapport.

2.2.2 Les activités de gouvernance (pilotage)

Afin de mener à bien ses activités de gouvernance, le SDM doit a un rôle de pilote de la prestation côté
Sopra Steria. Il doit pour ce la :

 Piloter et garantir la maîtrise durable des compétences : Plan d’Autonomie (PA)

 Maîtriser la qualité des services produits : Plan d’Assurance Qualité (PAQ)
 Formaliser les engagements de service : Convention de Service (CS)
 Piloter « administrativement » les services produits : RePortinG (RPG)
 Permettre la réappropriation de la prestation par le Grand Lyon : Plan de Réversibilité (PR)
 Assurer la maîtrise et le développement de la valeur de la prestation : Plan de Progrès

28
2.2.2.1 Le pilotage de l’autonomie (et de la cohésion avec les équipes du Grand Lyon)
Cette étape consiste à qualifier, valider et contrôler le niveau d’autonomie de la TME durant la durée
de la prestation c’est-à-dire que les collaborateurs doivent pouvoir réaliser l’essentiel de leurs missions
au quotidien sans sollicitation externe et en respectant un niveau de qualité de service contractuel.

Ce pilotage se découpe en plusieurs étapes : partage des objetifs et priorités, état des lieux de
l’existant (organisation, processus, outils, etc.), définition d’un Plan d’acquisition d’Autonomie
(comprenant les échéances, les moyens, les différentes instances de pilotage, etc.), la définition d’un
plan de cohésion favorisant une bonne interaction entre les équipes du Grand Lyon et l’infogérant, la
consitution d’un référentiel de compétences nécessaires à l’assurance de chaque activité permettant
de garantir un niveau de service et une continuité de service souhaités par le client.

Le référentiel de compétences est visible en Annexe.

Cette qualification d’autonomie s’effectue en trois étapes : observation (2 à 3 semaines), réalisation

en mode contrôlé (2 à 4 semaines), réalisation en mode autonome (2 mois après la prise de fonction).

L’autonomie à son poste passe également par une bonne compréhension des enjeux et des impacts
(priorité, criticité). La mise en place d’indicateurs de suivi du niveau d’autonomie permet au SDM de
suivre la montée en compétences de chaque membre de l’équipe.

2.2.2.2 Le pilotage stratégique, tactique et opérationnel de la prestation

La gestion de l’organisation mise en œuvre par le SDM se définit à trois niveaux :

 Le niveau stratégique qui définit le cadre de la prestation

 Le niveau tactique assure le respect de ce cadre
 Le niveau opérationnel conduit les activités de la prestation

Les principales activités sont les suivantes :

Pilotage du plan de charge

La gestion du plan de charge met en relation la prévision des activités et la capacité de production
dont le SDM dispose. En d’autres termes, il va maintenir une continuité d’activité sur des plages de
service spécifiées (8h-17h30 hors exceptions) et fournit un plan de charge prévisionnel pour
matérialiser le besoin ainsi qu’un plan de capacité.

Mensuellement, il doit produire une synthèse de l’activité pour chaque ligne d’activité afin de pouvoir
au besoin expliquer les variations au regard des périodes précédentes.

Pilotage des compétences

Cette matrice des compétences est le fruit d’un engagement visant à atteindre les niveaux attendus.
Le Delivery Manager fournit pour cela une procédure de gestion des compétences afin d’assurer la
montée en compétences lors notamment de l’évolution de l’environnement (technologique) ou des
procédures et contrôle ce niveau dans la durée.

29
Pilotage des conditions de réversibilité
La TME doit maintenir à jour un état des biens (matériels et immatériels) comme par exemple
l’inventaire des serveurs des différents environnements (production, formation, recette et
dévelopement) et concourir à la formalisation des modalités de réalisation des activités
opérationnelles présentées sous la forme d’une base de connaissance accessible librement par les
membres de l’équipe et du Grand Lyon (SPIP).

Pilotage des décisions et actions

Un suivi des actions partagé avec le Grand Lyon est assuré également par le SDM découlant des
décisions prises lors des différentes instances de pilotage. [2.2.3 Les instances de pilotage]

La gestion de la performance opérationnelle

Cette gestion mesure si les objectifs fixés par le Grand Lyon ont été atteints. Ils sont au nombre de
trois :

Les métriques fournissent une mesure des niveaux de performance opérationnelle atteints.

Le SDM a un role ici d’analyse de ces métriques notamment lui permettant d’expliciter les écarts dans
la qualité du service et d’anticiper les tendances

Les non-conformités : enregistrent quant à elles les activités ne respectant pas les exigences
imposées par le Grand Lyon.

Ces non-conformités sont discutées conjointement afin d’en déterminer la responsabilité et

d’appliquer ou non les pénalités associées.

Les questionnaires de satisfaction, n’ayant pas eu l’opportunité de constater la mise en place de tels
questionnaires et leurs impacts, je ne développerai pas cette partie.

La gestion des risques

Elle a pour objectif d’anticiper les envetuelles ruptures d’engagement de service. Elle couvre
l’identification, la cotation et la publication de ces risques ainsi que le suivi du plan de prévention des
risques.

Le SDM a pour devoir d’identifier les risques entravant sa capacité à tenir les engagements
contractuels, d’évaluer l’exposition aux risques identifiés et de proposer des plans de prévention pour
certains risques qui le justifient.

Les livrables
En annexe de ses activités de pilotage, il doit fournir des documents correspondants aux référentiels
cités plus haut. Ces livrables sont :

Le plan de charge prévisionnnel : c’est le calendrier des charges à venir par ligne d’activité et
applications (en prenant en compte les activités dites récurrentes et les exceptionnelles)

Le plan de capacité qui permet de visualiser la disponibilité de charge par ligne d’activité.

30
L’analyse de l’activité réalisée, sous-entendu l’état des charges analysées du mois en cours par ligne
d’activité.

Le tableau de suivi des actions, c’est la description des actions affectées et leur état d’avancement.

Le tableau de suivi de performance concentre l’état des métriques de performance et descrit les plan
d’amélioration

Plan de prévention des risques : Il regroupe la liste de ces risques et leurs cotations

2.2.2.3 Le pilotage du plan de progrès

Figure 9 : Schématisation du Plan de Progrès

Autonomie
Le socle même du plan de progrès est la gestion de l’autonomie des membres de la TME.

Cette première étape validée, la gestion de l’opitimisation permanente vise à traiter les écarts entre
le service produit et les objectifs de service.

Optimisation
Les propositions d’optimisation sont présentées lors des CTO [2.2.3. Les instances de pilotage]. Lors
de cette présentation, ces propositions devront également inclure ce en quoi elles présentent un
intérêt pour le Grand Lyon ainsi que l’identification des impacts, des risques associés et gains
potentiels.

L’optimisation devra produire un gain de charge, qui sera au préalable validé par les Pilotes de
Production. Par exemple, la modification et l’adaptation un mode opératoire suite au déploiement
d’une nouvelle version d’un outil ou effectuer une modification dans une chaine de traitement afin de
réduire la charge de supervision.

31
Industrialisation
La gestion de l’industrialisation repose essentiellement sur l’amélioration de la productivité et de la
fiabilité du service. Cette étape vient compléter l’optimisation car elle amène des améliorations et des
réductions de couts importantes. Par exemple, le fait d’automatiser des activités afin de fiabiliser et
d’améliorer la productivité pour réduire le nombre d’actions sur une activité récurrente.

Ces propositions sont présentées lors des CGH [2.2.3. Les instances de pilotage].

Innovation
La gestion de l’innovation vise à mettre en oeuvres des évolutions permettant d’augmenter la valeur
globale du service. Par exemple, une évolution technologique d’un environnement ou la mise en place
d’une organisation pouvant réduire un délai de mise en œuvre d’une application.

Ces propositions sont abordées lors des COPIL ou COSTRA et devront présenter et identifier les
impacts techniques, organisationnels et financiers ainsi que leurs risques associés. [2.2.3. Les instances
de pilotage]

Transformation
La gestion de la transformation se place à part et vise à adapter a prestation aux évolutions du besoin
et de l’environnement. Elles font référence notamment à une évolution majeure ayant un impact
organisationnel fort et possède un impact budgétaire conséquent.

32
 2.2.3 Les instances de pilotage
Afin de fluidifier les rapports entre les différents interlocuteurs du Grand Lyon : responsables de
prestation, coordinateurs, etc., différentes instances à différents degrés d’autorité sont organisées et
planifiées lors de la prestation :

Figure 10 : Les instances de gouvernance

Lors de ces instances les personnes présentes devront être dotées d’un niveau de délégation suffisant
afin de fluidifier les prises de décision.

Le Comité Stratégique (COSTRA)

C’est l’instance ultime de décision, elle a lieu une fois pa an. Ce comité donne la visibilité sur les futures
évolutions majeures du Grand Lyon. Les activités couvertes sont la revue des objectifs stratégiques et
le sprincipaux faits marquants de l’année, la revue financière, le plan de progrès et la prévision de
l’activité à long terme.

Cette instance peut également être sollicitée en cas de dysfonctionnement majeur pendant la durée
du marché.

Le Comité de Pilotage (COPIL)

Il est mensuel. Son objectif principal est de s’assurer du respect de tous les objectifs de la prestation
en cours. Il s’assure que les moyens nécessaires au maintien sous contrôle sont en place. Sont
abordés lors de cette instance : la revue de la performance de l’activité, le plan de charge prévisionnel,
la validation des éléments de facturations (UO) et les pénalités, la validation des propositions
d’amélioration et les avancements des chantiers d’amélioration ainsi que la revue des risques.

33
Le Comité de Gouvernance Hebdomadaire (CGH)
Comme son nom l’indique, il a lieu une fois par semaine et assure l’avancement des activités de
gouvernance ainsi que la pertinence du pilotage. Il garantit la cohérence de l’ensemble et fluidifie les
décisions entre les différents niveaux de pilotage et vise à assurer le contrôle continu de la prestation
(qualité, sécurité, facturation, plan de progrès, etc.)

Il permet le traitement des sollicitations issues des opérations et décompose les actions à mener
issues des décisions prises lors de ce comité. Il permet également de revoir les chantiers du plan de
progrès (optimisation, industrialisation, innovation). Il contrôle également la qualité du service rendu
par la TME ainsi que les risques rencontrés. Enfin sont abordés les indicateurs de contrôle de
performance (non-conformités) et les éléments de facturation (UO).

Il sert également de base à la préparation du COPIL.

Le Comité Technique Opérationnel (CTO)

Il est lui aussi hebdomadaire et se tient autant de fois qu’il y a de lignes de services composant l’équipe
de la TME. Il s’assure du respect des objectifs opérationnels et traite notamment les
dysfonctionnements et alertes relevés durant la semaine. Il permet de consolider les élements de
prévision d’activité en vue d’alimenter le plan de charge prévisionnel. Il pilote enfin les actions
d’optimisation du plan de progrès et analyse les écarts sur objectifs pour mettre en avant les actions
d’amélioration de fond.

Sont revus lors de cette instances les faits marquants de la période écoulée, la prévision d’activité, la
performance opérationnelle et les propositions d’amélioration. Le suivi des plans dactions de
prévention est également présent à l’objet de l’ordre du jour et les cotations des risques et y sont
également abordés.

Le TL ou SDM doit produire des métriques de performance qui seront analysés par le Grand Lyon lors
de ces instances.

Le Plan de Coordination Quotidien (PCQ)

C’est l’instance auquel participe chaque pôle y compris le N1, il a lieu tous les matins à 9h et dure
généralement 30 minutes. Il permet le suivi des opérations réalisées la veille et de vérifier à l’aide des
pilotes de prodution la priorisations des opérations à mener dans la journée. Il permet également la
possibilité de déclencher des actions prioritaires nécessaires en cas de besoin.

Sont revus les activités significatives de la veille (retards, crises, difficultés), les éventuels reports à
valider par le Grand Lyon afin d’éviter les pénalités dans le cas d’une non responsabilité de Sopra
Steria, et les activités à venir.

34
Figure 11 : Les instances de gouvernance et les participants

Une instance de coordination des prestataires est également possible sous la tutelle du Grand Lyon
mais celle-ci est hors du cadre de l’activité de la TME et ne sera donc pas abordée.

2.2.4 Les indicateurs et pénalités

Le cadre juridique dans lequel évolue ce marché permet au Grand Lyon de mobiliser des ressources
nécessaires au bon fonctionnement du SI. La mise en place d’indicateurs oblige Sopra Steria à fournir
un engagement de résultats tant au niveau de la maitrise de ses prestations et des couts que de la
qualité de service.

Ces engagement de services permettent donc de juger de la qualité des services rendus perçue par les
bénéficiaires, du respect des délais de prise en charge de la prestation ainsi que de sa réalisation, de
sa qualité mais également du niveau d’autonomie et de la qualité de la gouvernance.

Les indicateurs mesurant la prestations se décomposent en 2 types :

 Les engagements de service liés à l’activité de gouvernance : indicateurs, critères de

recevabilité, pénalités, etc.
 Et ceux mesurants les activités opérationnelles : activités récurrentes, à la demande, etc.

35
Les engagements de service en lien avec l’activité de gouvernance
Ils gèrent les actions en rapport avec la gouvernance mais également ceux en lien avec les livrables à
fournir périodiquement lors des différentes phases du cylce de vie de la prestation. [Figure 5]

Nous nous concentrerons ici sur la phase de régime établi.

La gestion de l’autonomie
Le dispositif mis en place par le Grand Lyon comprend des indicateurs maitrisant l’impact du turn over
afin de contrôler l’application du plan d’autonomie.

Ces engagement de services liés au Turn Over (TO) sont au nombre de 6 mais nous n’aborderons que
les 3 principaux à titre d’exemple:

 Le Turn-Over du SDM (TO-SDM)

Afin de minimiser l’impact sur les ressources internes, le TO-SDM est limité à un seul remplacement
durant la durée du marché, ce qui a été le cas avant mon arrivée. Si ce seuil est dépassé, une pénalité
de 1500€ par remplacement supplémentaire est appliquée.

 Le turn over de l’équipe opérationnelle (TO-EOP)

Ce nombre de changements est fixé à 3 par an. Au-delà, une pénalité de 1500€ est appliquée.

 L’engagement de service permettant la Revue du Plan d’autonomie (REVO-PA)

Une fois par an minimum, une revue du PA est effectuée afin de mesurer la capacité de production et
la qualité des prestations fournies par Sopra Steria. Le Grand Lyon peut procéder à des audits d’un
certain nombre d’activités récurrentes ou à la demande. Ce nombre d’actes rejetés devra être inférieur
à 5%.

La gestion du plan de progrès

Un engagement de service oblige Sopra Steria a transmettre une réponse aux actions du plan de
progrès suivies dans les instances de pilotage suivantes : CTO, COPIL et CTH. 100% de ces actions
doivent être réalisées dans ces délais. Dans le cas contraire, une pénalité de 50€ par action en retard
est appliquée.

La gestion du Plan de Réversibilité (PR) et sa Revue (REVO-PR)

Cet engagement de service oblige à transmettre une réponse aux actions du PR dans les délais
impartis.

L’indicateur concernant la Revue du Plan de Réversibilité (REVO-PR) implique de respecter un délai

inférieur à 20 jours après le lancement de la revue du PR.

36
Les engagements de service en lien avec les activités opérationnelles
Ces niveaux d’engagement se décomposent en plusieurs modalités. Le Plan d’Assurance Qualité
(PAQ) définit la mesure de ces indicateurs.

 La disponibilité des applications métiers, des infrastructures et des plate formes

 Le délai de réactivité pour le traitement des demandes opérationnelles de Niveau 2 et 3
 Le respect des engagements liés aux Demandes de Services

Le taux de disponibilité du SI
Il implique que « les utilisateurs accèdent aux ressources qui leur sont autorisées afin d’en faire un
usage normal et d’en retirer des résultats conformes à ceux que le système à prévu de produire. » Ce
système est donc considéré comme disponible lorsque l’utilisateur dispose de l’ensemble des
fonctionalités prévues dans son perimètre (bases de données, travaux, infrastructures, réseaux, etc.)
afin d’en faire un usage complet.

Ce taux différencie trois niveaux de criticité :

1 : L’indisponibilité d’une application, d’une infrastructure ou d’un système a un impact fort sur les
missions et la gestion du Grand Lyon ou place le Grand Lyon dans une situation où il ne pourrait pas
respecter ses engagements vis-à-vis des utilisateurs du SI

2 : L’indisponibilité présente un impact important sur l’activité du Grand Lyon, le dysfonctionnement

des applications, des infrastructures, etc. génère des charges supplémentaires pour un nombre
important d’utilisateurs.

3 : Les autres services de production ou les environnements ayant un nombre plus réduit d’utilisateurs.

La complexité des services

Les modalités de supervision, la conduite des traitements, la surveillance des sauvegardes, la charge
d’exploitation, le support sur les incidents sont autant d’éléments qui régissent la complexité des
services proposés par le Grand Lyon. Ils sont évalués selon le nombre d’utilisateurs, le nombre de
traitements par lots, la taille des bases de données d’une application, la complexité d’une architecture
matérielle ou logicielle, etc.

Trois niveaux existent : Complexe, Moyenne et Simple.

Les arrêts planifiés

Ces arrêts sont planifiés par le Grand Lyon concernant des interventions techniques ou spécifiques
(coupure annuelle). Ils sont procédurés et planifiés (validés) au préalable par le Grand Lyon.

37
La disponibilité est mesurée sur l’horaire de production hors arrêts planifiés. Elle est mesurée avec les
indicateurs suivants, selon le niveau de criticité de chaque technologie : taux mensuel de disponibilité,
durée maximale d’une interruption, nombre maximum d’interruptions par an et tolérance maximum
de données perdues :

Figure 12 : Disponibilité et tolérance de perte du SI

En cas de sinistre, un processus d’escalade organisationnelle est mis en place.

Réactivité sur demande opérationnelle de niveau 2

La réactivité du support téléphonique nécessite le respect de la plage d’astreinte (de 8h à 17h30). Pour
cela chaque ligne de service doit avoir sur le plateau au moins un membre présent à tout instant.

C’est la cellule SVP qui sollicite généralement la TME.

Figure 13 : Indicateurs concernant la prise en charge téléphonique

38
La réactivité sur les dossiers SVP, ID, FM, DM
La sévérité traduit l’impact du dysfonctionnementsur l’acitvité des ustilisateurs et la priorité de
traitement découle de la sévérité et de la criticité des applications concernées :

Figure 14 : Délais de traitement des dossiers

Les incidents de Niveau 1 et 2 doivent avoir un délai de résolution inférieur à 2h.

La réactivité sur demandes opérationnelles de Niveau 3

Celle-ci est déterminée au cas par cas par la DINSI en fonction du niveau de priorité identifié avant
l’escalade ainsi que des raisons de cette escalade.

Le taux de respect du délai de traitement est de 100%. En cas de non respect, le nombre de jours de
retard mesuré donnera lieu à des malus ou non-conformités.

39
Il existe 2 types d’indicateurs de non conformités : les non-conformités opérationnelles et les non-
conformités d’autonomie.

 Les non-conformités opérationnelles sont en général le non-respect d’une règle ou d’une

procédure (plan de production, modes opératoires, etc.), le seuil est de 2 erreurs par mois. Les
incidents non détectés ou non transmis dans les délais, les réouvertures d’incidents et les
mises à jour non effectuées des référentiels rentrent également dans ce calcul.

On trouve également l’asbence d’anticipation d’un risque impactant la fourniture du service,

comme la rupture de stock d’équipements réseau, une montée en charge planifiée mais non
prise en compte par la TME, la durée de vie d’un composant, etc.

 Les indicateurs de non-conformités d’autonomie concernent notamment l’escalade abusive

vers les PP ou la TMA.

La création du N1 est en partie liée à ces aspects.

Les principes de calcul de ces malus ne seront pas détaillés dans ce rapport.

2.2.5 Les différents Plans

Figure 15 : Les différents plans pour le respect des engagements de service

Le Plan d’Autonomie (PA)

Le Plan d’Autonomie est le garant de la maîtrise durable des compétences dans le temps par l’équipe
de la TME. Il met en avant les moyens mis en œuvre pour gérer les compétences ou connaissances des
ressources pendant la durée du marché. Ce document se matérialise par une matrice de compétences
consultable à tout moment par le Grand Lyon.

Il met également en avant les moyens mis en œuvre pour gérer la cohésion entre les différentes
équipes (Grand Lyon, prestataire sortant et prestataire entrant). [2.2.2.1 Pilotage de l’Autonomie]

40
Le Plan d’Assurance Qualité (PAQ)
Le Plan d’Assurance Qualité reflète la maîtrise de la qualité des services produits. Il s’articule avec la
Convention de Services, et met en exergue les modes opératoires mis en œuvre concrètement pour
réaliser les activités opérationnelles de la prestation.

La Convention de services (CS)

La convention de services regroupe les différents engagements de service. Elle doit couvrir les points
suivants :

 Description des services couverts par la prestation

 Plages de service et niveaux de service associés aux services produits
 Dispositions particulières applicables aux périodes exceptionnelles (crises, périodes
sensibles, etc.)
 La responsabilité et les limites d’engagement
 Catalogue des engagements de service produits
 Planning détaillé (activités, échéances, moyens)

Le Plan de Réversibilité (PR)

Le plan de réversibilité permet au Grand Lyon d’exercer la réversibilité de la prestation c’est-à-dire de
se la réapproprier en cas de changement de prestataire.

Il couvre les points suivants :

 Objectifs du Plan de Réversibilité

 Planning de réversibilité
 Dispositions relatives au transfert d’activité vers le nouvel infogérant
 Dispositions relatives au maintien des niveaux de services durant la Phase de Réversibilité
 Gouvernance du Projet de Réversibilité

Le Plan de Progrès
Il couvre les aspects suivants : Autonomie, Optimisation, Industrialisation, Innovation. [2.2.2.3.
Pilotage du Plan de Progrès]

41
3 REGARD CRITIQUE SUR LA PRESTATION
3.1 Le projet SI
3.1.1 Le contexte
Mon affectation à un projet SI n’était initialement pas prévue par le Delivery Manager. Au regard d’un
nombre suffisant de ressources au pôle transverse (deux titulaires et deux alternants), il nous arrivait
une semaine par mois de nous retrouver en sureffectif vis-à-vis du périmètre du N1. C’est donc lors
d’un entretien à 2 mois que j’ai proposé l’idée d’être placé sur un projet spécifique durant ce temps
disponible. Ma proposition a été bien reçue dans un premier temps puisque le SDM pouvait concentrer
ses efforts sur l’aspect industrialisation du plan de progrès. Après discussion conjointe, il a finalement
été proposé aux deux alternants du pôle de se pencher sur la mise en place d’une « météo » visant à
terme à remplacer les contrôles manuels du matin, socle des Points de Situation du Matin.

Après une analyse de l’existant, nous avons pu connecter la base de données du serveur primaire de
supervision avec une console de management shell et effectuer des requêtes en powershell pour
récupérer quelques informations. Malgré une première difficulté rencontrée suite à un problème de
compatibilité de librairie, cette phase de tests s’est avérée concluante.

Il nous suffisait dans un premier temps d’opérer à des filtres de recherche dans les syslogs afin de sortir
les informations concernant certains serveurs de productions, ceux concernés par les PSM des
différents pôles.

Ces informations auraient été ensuite receuillies et stockées dans une base et la création d’une
interface graphique conforme aux normes du Grand Lyon aurait permis de faire apparaitre via un
bouton, un état à un instant donné des serveurs de production.

3.1.2 Les raisons de non-résolution de ce projet

Malgré un projet transversal attrayant regroupant diverses compétences (linux, powershell, bases de
données, programmation), plusieurs aspects sont venus à l’encontre de son bon déroulement.

L’affectation des ressources

Nous devions réfléchir conjointement sur les différents aspects afin de préparer un plan de charge
prévisionnel. Nous avions émis l’idée aux Team Leader et SDM de nous réserver des plages communes
afin d’unir nos réflexions pour mener à bien ce projet. Nous avons obtenu 2 semaines communes sur
une plage de 10 semaines. En effet, au regard du caractère répétitif des tâches, il était délicat
d’affecter la même ressource deux semaines consécutives sur la même mission et le TL devait donc
jouer avec les affectations de chacun.

Dès lors que les bases communes de réflexion et résolution ont été vues ensemble, nous avions
l’opportunité de consacrer théoriquement deux fois plus de temps sur ce projet, chacun ayant une
semaine par mois sur ce projet.

La modification du plan de charge

Suite à un problème médical, l’un des titulaires de l’équipe transverse s’est absenté durant 3 mois ce
qui a mis en pause l’exécution du projet. Restaient à ce stade là, les deux mois estivaux pour s’y
consacrer.

42
La politique
L’importance de ce projet n’était contractuellement pas capitale puisqu’il aurait constitué simplement
une valeur ajoutée à la prestation fournie par Sopra Steria. La priorisation des tâches l’a rapidement
relayé au second plan et nous nous sommes retrouvés confronté à une hiérarchie moins
compréhensive.

A son retour d’ITT, le projet ne faisait plus partie de l’ordre du jour mais nous avons essayé de lui
redonner une place d’importance.

L’absence de communication
Parallèlement, la communication n’ayant pas été réalisée aux membres de l’équipe, nous continuions
d’être sollicités sur nos activités récurrentes durant nos phases de projet ce qui entravait son
avancement.

La planification
Finalement, les départs en congés de l’équipe pour la période estivale et le changement de mission
soudain d’un des titulaires courant juillet ont fini de mettre un terme à ce projet.

Une implication mesurée du SDM, une gestion des ressources compliquée et un environnement
cloisoné ont rendu impossible la bonne réalisation de ce projet d’industrialisation.

3.2 Apports personnel et professionnel

Pour une première approche avec le milieu informatique, j’ai intégré durant cette année le pôle
transverse. Véritable fer de lance de la TME, il permet dans un premier temps la centralisation des
informations relatives au SI du Grand Lyon puis la distribution des informations aux lignes techniques
concernées. Malgré une réputation quelque peu entachée par une complexité limitée des missions
afférentes, il est pourtant un passage obligatoire pour une appréhension concrète de
l’environnement.

Cette année passée au pôle transverse m’a permis de me familiariser avec un environnement de
production et de ses contraintes sous-jacentes. J’ai appris à utiliser les différents outils mis à diposition
ainsi que les nombreux processus mis en place pour le bon fonctionnement de la prestation.

Fort d’une attitude proactive et de recherches extra-professionnelles, j’ai rapidement pris mes
marques car le périmètre technique du pôle est devenu restreint.

Les cours dispensés à l’école Sciences-U ont également concouru à une montée en compétences
rapide.

Je me suis donc porté volontaire sur des missions annexes réalisées en temps normal par le Niveau 2,
notamment concernant la ligne technique Réseau & Sécurité et ULVS. J’ai commencé à planifier des
interventions pour le remplacement d’équipements réseau déffectueux en ayant au préalable
configuré les nouveaux équipements d’après les directives des Pilotes de Production. J’ai réalisé des
demandes standards sur les environnement Linux et Unix comme la création de compte utilisateur ou
la gestion de droits.

43
La combinaison de mon apprentissage à Sciences-U et mon volontariat sur ces différentes missions
sortant du cadre du Niveau 1 m’ont permis d’appronfondir ma connaissance technique dans les
domaines du Réseau et de la Sécurité ainsi que des environnements Linux et Microsoft. J’ai également
été amené à développer une réflexion critique sur les missions qui m’étaient confiées et une attitude
encline à la recherche de solutions techniques sur de nombreux aspects.

Ces démarches ont concouru à consolider une autonomie et une assurance dans le domaine de
l’Information Technology. L’année écoulée à été selon moi un passage nécessaire vers une bonne
compréhension d’un Système d’Information vaste mettant en jeu de nombreux acteurs et une
multitude d’équipements.

3.3 Les limites de la prestation

3.3.1 La recherche de la performance
L’efficacité d’une organisation se définit surtout par sa performance. Elle englobe un certain nombre
d’indicateurs permettant de suivre l’évolution et de se rendre compte des lacunes d’une organisation.

Dans un contexte d’une Relation Bénéficaires comme c’est le cas au Grand Lyon, la performance se
traduit par un engagement de résultats de la part de Sopra Steria, c’est-à-dire qu’elle réside dans une
qualité de services rendus aux utilisateurs. Cela passe par la qualité technique de la prestation fournie
et des délais de traitement.

Pour mesurer cette qualité de service, plusieurs indicateurs sont utilisés. [22.4. Indicateurs et Pénalités]

Tout d’abord un outil de suivi des dossiers et incidents permettant de tirer des statistiques tout au
long de la prestation et sur l’ensemble des tâches réalisées par la TME. On peut extraire ces
statistiques pour se rendre compte du temps passé par chaque personne ou équipe, ainsi que leurs
actions, sur tous les dossiers traités par la TME. Cela permet d’identifier les sujets chronophages, des
problématiques récurrentes ou encore certaines anomalies dans les processus.

Une personne à la fois peut être active sur un dossier (affectation unique). Au regard du déroulement
alterné des missions des membres de la TME, une personne peut clore un incident en ayant réalisé
une participation minime sur la résolution de ce ticket et fausse donc les statistiques. [Figure 7]

Par la suite lors des différentes instances de gouvernance, ces points sont abordés et des
améliorations sont proposées et mises en place dans le but de gagner en efficacité par le biais des
chantiers du plan de progrès. [CTO]

Afin que ces améliorations soient prises en compte, les relations au sein des comités de pilotages les
équipes doivent être les plus professionnelles et saines possible, afin que les changements dans les
processus ne soient pas seulement perçus comme des contraintes et soient respectés. L’un des rôles
des Team Leader est donc de faire l’interface entre les équipes opérationnelles et les pilotes de
productions afin que ces changements soient compris, assimilés et effectifs dans les meilleures
conditions.

Ici se trouve une première difficulté : la relation entre les différents acteurs. Si des intérêts ou
problématiques personnels interfèrent dans ces relations, elles peuvent se dégrader et endiguer cette
recherche d’optimisation et de rationalisation.

44
J’ai dû faire face à plusieurs situations où les Pilotes de Production n’agissaient plus pour améliorer la
prestation et défendaient des intérêts personnels qui ne regardaient en aucun cas la TME, mais
seulement avec leur direction. Cela a entrainé de lourds ralentissements dans la mise en place de
certaines mesures pertinentes, et des sanctions parfois exagérées pour la TME.

Le Service Delivery Manager a ici un rôle de facilitateur et de négociateur puisqu’il doit apporter par
des éléments factuels la non responsabilité des équipes opérationnels. Sans l’utilisation de ces outils
de traçage, il serait difficile d’apporter des compléments d’informations face à des situations
conflictuelles.

3.3.2 La spécialisation du travail

En observant les différents schémas et l’organisation de la prestation, on se rend compte que les
périmètres sont très cadrés voire cloisonnés. Les tâches sont découpées et réparties selon le domaine
et la maitrise technologique. Par ailleurs les processus se doivent d’être précis, développés et
améliorés de façon continue afin de garantir une qualité de service et une bonne coordination de la
prestation. Cette coordination joue un rôle majeur dans le bon fonctionnement de l’organisation.

J’ai pu remarquer pour l’équipe transverse que cette répartition des tâches est dommageable pour les
intervenants. Le contenu de celles-ci n’est pas valorisant pour l’individu. Il ne nous est pas demandé
d’apporter une réflexion sur un problème mais plutôt d’agir en suivant des procédures. Outre le
caractère répétitif des incidents ou des demandes, la politique d’escalade technique implique au N1
de s’affranchir de toute difficulté en transférant le dossier au niveau suivant.

Le rôle du Delivery Manager et des Team Leader ici est important, car ils sont les seuls à pouvoir
prendre en compte ces remarques et permettre une action en conséquence. Une attitude proactive
pour gagner la confiance de la hiérarchie permet toutefois de se voir augmenter le cadre de ses
responsabilités. [3.2 Apports personnel et professionnel]

3.3.3 La transversalité
Dans cette même logique, le rôle du N1 est d’affecter les dossiers aux lignes techniques concernées.
Il est perçu comme un pôle de coordination survolant les aspects technique de chaque incident ou
demande mais impliquant d’être tout de même informé de tous les éléments en cours que ce soit au
niveau de la TME ou du Grand Lyon.

Ainsi la gestion de la BAL commune nécessite de partir du principe que les informations destinées aux
pôles ne sont pas prises en compte et donc de jouer le rôle de mandataire sans pour autant en avoir la
certitude. Cela peut générer des situations délicates dans le cas où nous transférons un email déjà pris
en compte par un Niveau 3 ou un Pilote de Production. Sans aborder l’aspect chronophage pourtant
évident, cette organisation tend à trouver ses limites au niveau de la responsabilité de chacun.

Par ailleurs, le rôle de transverse est perçu comme celui étant au plus proche des utilisateurs et
mainteneurs (dans le référentiel de la TME). Ainsi, nous pouvons observer régulièrement des
désescalades de la part des lignes N2 concernant des dossiers ayant fait l’objet d’une longue durée de
traitement et où il nous est simplement demander une tâche de confirmation (mail ou téléphone) afin
de le clore. La responsabilité de chacun trouve encore une fois sa limite dans cette gestion.

45
 3.3.4 La coordination des activités
La coordination permet de réduire les effets de la différenciation entre les différentes équipes créant
un sentiment d’appartenance et d’importance dans les processus.

On se rend très vite compte dans ce genre d’organisation que c’est un élément-clé permettant
d’améliorer la dynamique des équipes et la qualité globale du service.

Dans cette prestation, la coordination est mise en place grâce tout d’abord aux nombreux processus,
mais aussi aux nombreux comités (quotidiens, hebdomadaires et mensuels) durant lesquels des
informations utiles à la coordination entre les équipes sont partagées.

Malgré une absence de participation de certaines équipes dû à leur rôle hierarchique, les informations
ne circulent pas suffisamment alors qu’elles permettraient à chaque acteur de se sentir plus impliqué
dans la globalité de la prestation. Parallèlement, le rythme de l’alternance (absence d’une semaine
sur 3) vient compliquer la bonne réception des informations concernant certaines criticités
opérationnelles ou des changements dans l’organisation.

3.4 Analyse globale de la prestation

Durant cette année, j’ai pu acquérir une expérience technique et un avis sur la façon dont est organisée
la prestation.

Malgré quelques problèmes liés à des conflits/intérêts personnels de plusieurs Pilotes de Production
et managers, j’ai senti une amélioration dans le fonctionnement de la prestation. J’ai pu me rendre
compte que son fonctionnement dépend beaucoup des différents acteurs et la façon dont les
collaborateurs sont considérés. Plus ils le sont, plus l’organisation se fluidifie. Les initiatives se
multiplient et font croitre le sentiment d’implication. Les équipes sont volontaires et responsables.

La relation et l’organisation de la hiérarchie sont tout aussi importantes, car elles ont des
conséquences directes sur la dynamique de la prestation.

Une confiance mutuelle s’installe et il y a par exemple de moins en moins de non-conformités. J’ai vu
des projets, stagnants jusqu’alors, évoluer rapidement car les collaborateurs ne subissaient plus le
poids et les conséquences de certains indicateurs et conflits.

L’organisation générale de la prestation est devenue plus stable, on sent une amélioration dans
l’équité entre les différentes équipes et collaborateurs qui montent en compétences et en autonomie
et prennent part à de nouveaux projets d’optimisation et d’industrialisation.

Malgré une implication mesurée du SDM sur mon projet, j’ai pu constater l’importance de la
planification, de l’organisation, de la direction et de la coordination ainsi que du contrôle des
différentes missions et processus dans la gestion d’une infogérance. Même si certains aspects
contractuels ont ralenti le déroulement de la prestation, lorsque les acteurs ont la volonté d’améliorer
la qualité du service, on trouve généralement des solutions équitables pour les deux partis permettant
d’amérliorer l’ambiance de travail tout en gardant un niveau de qualité attendu.

46
 CONCLUSION

De mon point de vue d’Administrateur Réseau & Système avec un an d’expérience, je n’ai pas la
prétention d’apporter une réponse fermée aux rôles et enjeux d’une Tierce Maintenance
d’Exploitation dans une infogérance. Je peux toutefois exposer mon avis sur le cas d’étude que j’ai
connu, soit celui d’une infogérance d’infrastructures dans le contexte d’un marché public.

Le contexte d’un marché public est un contexte particulier. Il se distingue par ses offres et services
rendus aux utilisateurs. L’avancée d’un projet technique dans un secteur public met généralement
plus de temps à aboutir car les décisions sont prises plus en amont avec parfois des retombées
politiques. Cet aspect politique du marché délimite également le cadre des prestations : lenteurs dans
les prises de décision, retards technologiques avérés, actions très procédurées, etc.

Cette gouvernance à plusieurs niveaux est l’une des raisons de sa particularité.

Parallèlement, en réponse aux appels d’offres, les ESN proposent leurs solutions au coût le plus bas
afin de remporter le marché, généralement au détriment de la qualité. Dans le cadre de l’infogérance
du Grand Lyon, la période de réversibilité démarrera en Mars 2020 et entraînera avec elle la
publication d’un nouvel appel d’offres. Malgré un service rendu qualitatif de la part de Sopra Steria sur
ces dernières années et l’amélioration de la cohésion entre les équipes de la TME et de la TMA cela ne
lui donne pas de passe-droit pour se positionner favorablement sur la décision finale du Grand Lyon
concernant le choix du nouveau titulaire.

J’ai pu à mon échelle ressentir l’approche de l’éventuel arrêt de la prestation. Sopra Steria
Infrastructure Management a décidé de ne pas reconduire les alternants démarrant un nouveau cycle
d’études car la Direction n’avait pas de visibilité sur le long terme. Les choix qui en découlent sont
donc pragmatiques et ne sont que des réponses logiques à la politique du pouvoir adjudicateur.

On peut remettre en doute la précarité de ce modèle car selon moi, l’absence de visibilité des
infogérants décourage leurs investissements.

Dans cette démarche, le fait que le coût de la prestation soit souvent la principale motivation pour la
signature du contrat entraine inévitablement la croissance d’une dette technologique. On peut se
poser les questions suivantes : est-ce que le marché public ne risque pas ainsi de souffrir à échéance
de ces choix court-termistes ?

N’y a-t-il pas possibilité d’imaginer une ou plusieurs solutions alternatives ?

Le pilotage de la stratégie IT ne devrait-il pas être un peu moins orienté politique mais davantage
centré sur l’expertise et l’analyse des besoins du marché public et par extension, des utilisateurs du
SI ?

47
ANNEXES : MATRICE DES COMPETENCES

48
49
50
51
 TABLE DES ILLUSTRATIONS

Figure 1 : Evolution du CA de Sopra Steria Group (en milliers d’€) ........................................... 8

Figure 2 : Classement 2018 des ESN selon leur CA France ...................................................... 10
Figure 3 : Organigramme simplifié de la Métropole de Lyon .................................................. 12
Figure 4 : Organigramme de la DINSI ....................................................................................... 13
Figure 5 : Cycle de vie de la prestation .................................................................................... 17
Figure 6 : Le fonctionnement de la prestation ......................................................................... 18
Figure 7 : Plage horaire de la TME............................................................................................ 21
Figure 8 : Les relations entre le GL et l'infogérant ................................................................... 27
Figure 9 : Schématisation du Plan de Progrès .......................................................................... 31
Figure 10 : Les instances de gouvernance ................................................................................ 33
Figure 11 : Les instances de gouvernance et les participants .................................................. 35
Figure 12 : Disponibilité et tolérance de perte du SI ............................................................... 38
Figure 13 : Indicateurs concernant la prise en charge téléphonique ...................................... 38
Figure 14 : Délais de traitement des dossiers .......................................................................... 39
Figure 15 : Les différents plans pour le respect des engagements de service ........................ 40

52
 BIBLIOGRAPHIE

Etudes des documents internes au Grand Lyon

▪ CCTP : Cahier des ClausesTechniques Particulières de l’infogérance
▪ Livret d’accueil Infrastructure Management du Grand Lyon
▪ Volumétrie des activités
▪ Catalogue des services et des demandes
▪ Description de l’environnement technique
▪ Inventaire du périmètre technologique
▪ Outillage et processus
▪ Charte sécurité
▪ Procédures diverses

Interviews réalisées auprès des membres de la TME

▪ Ligne technique RS
▪ Ligne technique ULVS
▪ Ligne technique MS
▪ Ligne technique EAP
▪ Ligne technique BDD
▪ Team Leader
▪ Service Delivery Manager
▪ Pilote de production RS

Sites Web
▪ http://www.marche-public.fr
▪ https://www.soprasteria.com/fr
▪ https://www.grandlyon.com
▪ https://sopra-steria.career-inspiration.com
▪ https://www.journaldunet.com/management
▪ https://www.solutions-numeriques
▪ https://syntec-numerique.fr

53