Examen professionnel pour l`accès au grade d`attaché principal d

Ministère de l’intérieur
-------Examen professionnel d’ingénieur principal
des systèmes d’information et de communication
du ministère de l’intérieur
Session 2013
Meilleure copie
Sujet n°1 - Réseaux
Note obtenue : 16,5/20
--------
PARIS, le 21 mars 2013
Note à destination
du chef de service X
OBJET : Migration réseau et système : analyse et proposition d’organisation projet.
Dans le cadre des deux chantiers ministériels de migration du réseau IP et
des infrastructures applicatives, cette note a pour ambition de dresser une analyse
technique, juridique et fonctionnelle des deux chantiers à engager et de proposer
une organisation pour y faire face.
Le ministère a engagé un profond chantier de modernisation du réseau IP et
des services informatiques en choisissant de s’appuyer sur un réseau MPLS/IP et
sur un concept d’infrastructure as a Service (Iaa S). Ces deux technologies apportent
des gains en terme de coût, de disponibilité, d’évolutivité, et d’accessibilité,
moyennant un niveau de délégation de service à un prestataire. S’il est difficile de
contester les gains apportés, il faut cependant tout mettre en œuvre afin d’évaluer
l’impact de ce déploiement sur les utilisateurs.
Ainsi dans un premier temps, je m’attacherai à identifier et décrire les risques
et facteurs de réussite du projet.
Puis, je proposerai une organisation à mettre en place pour mener le
déploiement compte-tenu des compétences et des ressources disponibles.
Je décrirai ensuite les indicateurs permettant de piloter au mieux le chantier.
Et enfin, je proposerai un planning projet prenant en compte les contraintes de
délai du ministère, mais aussi les sujets sensibles tels que la conduite du
changement.
2
1 - Déploiement IP/MPLS : risques et facteurs de réussite
La transition d’une infrastructure intégralement internalisée ou presque, vers
une infrastructure externalisée nécessite de répondre à un certain nombre de risques
pour s’assurer d’atteindre les objectifs fixés en terme de coût ou de qualité de
service.
1.1.
La sécurité
Tant pour le chantier IP/MPLS que pour l’IaaS, la sécurité est le premier
risque qu’il convient d’évoquer. En effet, le partage des infrastructures introduit des
risques supplémentaires par l’ajout de menaces des autres utilisateurs du Cloud.
Le Cloud Security Alliance propose une liste exhaustive des points d’attention
sur les aspects sécurité de l’IaaS. Il conviendra donc d’approfondir ces points dans le
cadre du projet.
On peut cependant déjà proposer de traiter la partie sécurité de manière
prioritaire et d’insister sur la nécessité de gérer cet aspect tout au long du projet.
On insistera notamment sur les notions d’authentification, de disponibilité du
service.
Dans tous les cas une documentation rigoureuse sera le préalable afin de
contrôler et de s’assurer que la sécurité est respectée sur le projet.
1.2. La qualité de service
Le deuxième risque qui vient à l’esprit est celui du non respect de la qualité de
service dans le cadre d’une externalisation partielle.
Il conviendra donc de définir et contractualiser de manière très rigoureuse la
qualité de service attendue du prestataire. Cela pourra se faire via notamment une
convention de service dotée d’indicateurs précis et mesurables.
1.3. Le risque technique
Etant donné l’importance du périmètre technique du projet, il est inévitable que
des problèmes techniques de compatibilité se présentent.
Le grand nombre d’infrastructures actuellement déployées nécessite une
cartographie exhaustive et précise de l’existant.
Cette cartographie permettra d’évaluer ce qui est migrable et ce qui est non
migrable ou doit être modernisé.
Cela permettra aussi de planifier le déploiement en commençant par les
infrastructures les moins critiques ou les plus faciles à migrer.
1.4. Le risque budgétaire
Une fois les réseaux IP/MPL et l’IaaS déployés, il conviendra de s’assurer que
les modalités de facturation sont soutenables et conformes aux prévisions.
3
Pour éviter de mauvaises surprises, il conviendra de s’assurer au préalable de
l’adéquation entre l’usage réel et l’usage prévu des infrastructures.
En cas d’un usage excessif des infrastructures, une refacturation interne
pourra modérer cet usage.
1.5. Le risque juridique
L’hébergement de données dans un Cloud public pose des problèmes
juridiques. En effet, par exemple le Patriot Act permet aux Etats-Unis d’avoir accès à
toute donnée hébergée sur leur sol.
Le moyen d’écarter ce risque est d’intégrer si nécessaire une clause au
marché de formation de l’IaaS ou de vérifier si le marché actuel est conforme sur ce
point.
1.6. Le risque de non réversibilité
Afin de s’assurer de la possibilité de réversibilité des services offerts par les
deux prestataires on vérifiera dans le marché ministériel la conformité sur ce point.
Dans le cas contraire, une demande sera faite pour inclure une clause au marché via
un avenant.
2 – Organisation à mettre en place et impacts R.H.
Etant donnés le large périmètre, la complexité et les délais annoncés du
projet, il convient de mettre en œuvre une organisation solide de conduite de projet.
2.1. Les ressources projets
L’équipe projet sera composée :
-
d’un représentant de la direction ;
d’un directeur projet ;
d’un chef de projet maître d’ouvrage ;
d’une équipe projet ;
d’un représentant de chaque direction cliente ;
d’un chef de projet prestataire ;
d’un représentant des services juridiques et financiers.
2.2. Les compétences nécessaires
Chaque membre de l’équipe apportera ses compétences dans les domaines
techniques, fonctionnels, organisationnels ou juridiques.
Il conviendra d’associer l’ensemble des agents et plus particulièrement les 20
membres de mon équipe de spécialistes réseaux et système qui gèrent aujourd’hui le
périmètre concerné par le projet.
4
2.3. L’impact sur les R.H. réseaux et système
La première question qui sera posée par le projet est le devenir de l’équipe
réseaux et système. Si l’externalisation partielle nécessite toujours des compétences
fortes de pilotage et d’analyse, l’équipe devra certainement être réduite.
Les agents intéressés par un rôle plus fonctionnel et moins technique se
verront proposer des fonctions de pilotage des prestataires. Les plus experts
pourront quant à eux se concentrer sur de l’ingénierie sur les nouveaux services ou
fonctionnalités évaluées. Enfin des postes de sécurité opérationnelle devront être
ouverts.
Il restera néanmoins à reclasser certains agents et surtout à les accompagner
durant ce reclassement interne ou externe.
2.4. Les instances de pilotage
Différents comités permettront de piloter le projet.
Un comité de pilotage intégrant le responsable hiérarchique permettra de
lancer le projet et de rendre les arbitrages à intervalles réguliers. Il aura lieu tous les
un à deux mois en fonction de l’avancée du projet.
Un comité de pilotage exceptionnel pourra être proposé en cas d’alerte sur le
projet.
Le comité de projet aura lieu toutes les semaines en phase active du projet et
réunira les chefs de projet, les prestataires et les représentants des utilisateurs. Il
permettra de s’assurer de l’avancée du projet et du respect des coûts, qualités et
délais.
Enfin des groupes de travail techniques organisés à la demande ou de
manière régulière permettront de traiter les aspects techniques du projet.
3 – Pilotage et indicateur du projet
Afin de piloter au mieux le projet de déploiement réseaux et système, un
pilotage des risques sera mis en place et permettra d’alerter la hiérarchie en cas de
dérive.
De plus, afin de rendre visible l’avancée du déploiement quelques indicateurs
seront définis.
3.1. Le pilotage des risques
Dès que les risques seront identifiés précisément, on évaluera leur probabilité
d’occurrence et leur impact afin de définir leur criticité.
Une fois hiérarchisé on définira des solutions palliatives à mettre en œuvre en
cas de matérialisation du risque.
5
Ces éléments seront matérialisés de manière graphique afin de pouvoir
communiquer largement sur ce sujet.
3.2. Les indicateurs du projet
Nous définirons quelques indicateurs simples et représentatifs de l’avancée du
projet.
Ces indicateurs devront être peu nombreux, acceptés par tous et légitimes. Ils
devront être faciles à calculer et tenables pour être incontestables.
Enfin, ils devront être chiffrés ou qualitatifs, mais surtout devront pouvoir être
représentés de manière graphique. Il faudra aussi pouvoir constater leur évolution au
fil du temps.
Leur mise à jour sera mensuelle et leur point de départ sera fixé avant le
projet de manière à pouvoir constater les gains apportés par le projet si cela est
pertinent.
Je propose, par exemple, les indicateurs suivants :
•
•
•
•
•
pourcentage de migration réseau des sites sur l’IP/MPLS ;
pourcentage de service applicatif migré sur l’IaaS ;
disponibilité du service réseau ;
disponibilité des services applicatifs ;
taux de satisfaction des utilisateurs.
Des indicateurs supplémentaires pourront être ajoutés, mais il faudra éviter
leur multiplication pour ne pas nuire à la visibilité sur l’avancée du projet.
4 – Planning du projet et tâches prévues
Les vingt mois annoncés par le ministère sont très ambitieux compte tenu du
périmètre du projet.
Cependant, en mobilisant toutes les ressources et en anticipant au maximum
les risques techniques et fonctionnels il est possible de mener le projet dans les vingt
mois impartis.
Il sera très important d’alerter au plus tôt à la moindre dérive des délais du
projet.
De même la conduite du changement tout au long du projet permettra d’éviter
tout problème avec les directions utilisatrices et de bien s’assurer avant migration de
la bonne compréhension des résultats attendus du projet.
Planning projet : voir Annexe 1 – Intercalaire n°2.
6
Le projet de migration des services réseaux et systèmes sur des
infrastructures partiellement externalisées est un projet ambitieux et novateur. Il
répond à un certain nombre de problématiques actuelles des directions utilisatrices
en apportant plus de souplesse, une meilleure accessibilité et une meilleure
disponibilité du service.
En outre, dans le cadre d’un exercice budgétaire contraint, il permettra de
dégager des marges de manœuvre financières qui pourront être attribuées à la mise
en œuvre de services novateurs.
Malgré les difficultés qu’il va engendrer en terme technique, fonctionnel, R.H.,
ce projet sera l’occasion de démontrer le savoir-faire des équipes d’experts réseaux
et système et de repenser l’activité du service pour le recentrer sur le service aux
utilisateurs.
7
PHASES PROJET
Annexe 1
T0 Définition de l’existant
Définition des services à
migrer et ordonnancement
Définition des
services attendus
Go No Go
Prototype
Etude du
déploiement
Etude du prototype
Conduite du changement
Pré-requis migration IaaS
Déploiement prototype
Recette
VSR
Bilan prototype
Conduite du changement
Déploiement industrialisé
Etude industrialisation
6 mois
VSR
3 mois
2 mois
2 mois
2 mois
2 mois
1 mois
2 mois
Conduite du changement
Bilan projet