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.
1 - Déploiement IP/MPLS : risques et facteurs de réussite 2 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.
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. 3 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.
2.3. L impact sur les R.H. réseaux et système 4 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.
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. 5 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.
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. 6
7 PHASES PROJET T0 Définition de l existant Définition des services attendus Etude du déploiement Définition des services à migrer et ordonnancement Go No Go Prototype Annexe 1 Etude du prototype Conduite du changement Pré-requis migration IaaS Déploiement prototype Recette VSR Bilan prototype Conduite du changement Etude industrialisation Déploiement industrialisé 6 mois VSR 3 mois 2 mois 2 mois 2 mois 2 mois 1 mois 2 mois Conduite du changement Bilan projet