Référentiels Qualité & Gestion de Projet

Référentiels Qualité & Gestion de Projet Panorama et exemples d application Par Cyrille Devaux I Rachid El Ouarghani I Thibault Estran

Pour tous renseignements complémentaires : cdevaux@aubay.com ou pesteves@aubay.com 2011 AUBAY. Tous droits réservés Les informations contenues dans ce document représentent le point de vue actuel d Aubay sur les sujets exposés, à la date de publication. Dans la mesure où les éditeurs cités doivent s adapter aux conditions changeantes du marché, Aubay ne peut pas garantir l exactitude des informations présentées après la date de publication. Les noms de produits ou de sociétés dans ce document peuvent être les marques déposées de leurs propriétaires respectifs. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 2

A PROPOS DES AUTEURS Cyrille DEVAUX, Directeur chez Aubay Management Titulaire d un master en Intelligence artificielle, reconnaissance des formes et robotique, et d un Executive MBA (HEC), Cyrille Devaux est le plus globe-trotter des experts en technologies et systèmes d information Aubay. Après une adolescence passée à Abidjan, Cyrille effectue son service civil à l Ecole Nationale des Sciences de l Informatique à Tunis (Tunisie). Puis il débute sa carrière en 1992 à la Délégation Générale pour l Armement. En 1995, il part en mission chez TELMEX au Mexique. C est chez Marben, devenu Atos, qu il rencontre Christian Aubert (plus tard, fondateur du Groupe Aubay) et François Hisquin. En 1998, en collaboration avec ces derniers, il crée OCTO Technology, cabinet spécialisé dans l architecture de systèmes d information. En 1999 ouvre l agence espagnole d OCTO jusqu au rachat du cabinet par le Groupe Aubay, qu il rejoint en 2002. Depuis 2007, Cyrille Devaux occupe le poste de Directeur au sein de la structure de conseil : Aubay Management. Rachid EL OUARGHANI, Consultant Aubay Management Après un diplôme d ingénieur IPSA obtenu en 2001, Rachid décroche un poste de consultant chez Thales. En 2003, il décide de partir aux USA afin d enrichir son parcours en effectuant un MBA en finance et stratégie. Ce MBA lui a permis d intégrer en 2005 la société américaine TIBCO où il a exercé en tant que Directeur de projets. Attiré par la refonte des processus 6 sigma et conduite de changement, il obtient le poste de Directeur projets au sein de la société américaine Meridium basée à Dubaï. Début 2010, Rachid El Ouarghani rejoint l équipe Aubay Management. Thibault ESTRAN, Consultant Aubay Management Jeune collaborateur d Aubay Management, Thibault Estran est titulaire d une double compétence en ingénierie et en marketing. Il effectue ses débuts dans l industrie automobile où il découvre les préceptes de l amélioration continue et du Lean Management. Il développe par la suite ses compétences en gestion de projet dans l aéronautique. Très intéressé par le secteur des systèmes d information, il intègre Aubay Management en tant que consultant afin de prendre en charge des missions d organisation et de management de projets. Ont également participé à la constitution de ce libre blanc : Luc BERNARD, Antoine LAURENT, Nicolas ZUMINO, Jean-Baptiste POTOKAR, Franck BERMAN et Emeline GUEZELLO. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 3

Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 4

SOMMAIRE 1 INTRODUCTION... 9 2 LE PROJET ET SES ACTEURS... 10 2.1 Le Projet... 10 2.2 Principales activités inhérentes à la gestion de Projet... 11 2.2.1 Gestion des risques... 11 2.2.2 Gestion budgétaire... 13 2.2.3 Planification... 14 2.2.4 Reporting... 15 2.2.5 Contrôle qualité... 16 2.2.6 Gestion des engagements du projet... 16 2.3 Principaux acteurs de la gestion de projet.... 16 2.3.1 Directeur de Projet... 18 2.3.2 Chef de Projet... 19 2.3.3 Project Manager Officer... 19 2.4 Gouvernance de projet... 20 3 PRINCIPAUX RÉFÉRENTIELS QUALITE... 23 3.1 ISO 9001... 24 3.1.1 Qu est-ce que ISO 9001, exactement?... 24 3.1.2 Qu est-ce que n est pas ISO 9001?... 24 3.1.3 Que s attend-t-on à trouver dans une entreprise certifiée ISO 9001?... 24 3.1.4 Sur quels principes repose la gestion de la qualité ISO 9001?... 25 3.1.5 Comment s effectuent les contrôles?... 26 3.2 CMMI (Capability Maturity Model Integration)... 26 3.2.1 Qu est-ce que CMMI exactement?... 26 3.2.2 Qu est-ce que n est pas CMMI?... 27 3.2.3 Comment maintenir son niveau de maturité?... 27 3.2.4 Que s attend-t-on à trouver dans une entreprise dont un service est évalué selon CMMI?... 28 3.2.5 Quelles compétences pour mettre en œuvre des activités?... 28 3.2.6 Comment s effectuent les contrôles?... 28 3.3 ITIL (Information Technology Infrastructure Library)... 29 3.3.1 Qu'est ce qu'itil?... 29 3.3.2 À quoi sert-il?... 29 3.3.3 D'où vient ITIL?... 30 3.3.4 Utilisation d'itil... 30 3.3.5 Quels sont les bénéfices de la démarche ITIL?... 30 3.3.6 Les processus ITIL V2... 31 3.3.7 ITIL en 3 points... 31 3.4 Référentiels et certification... 31 3.5 Conclusion... 32 4 MÉTHODOLOGIES D OPTIMISATION DES PROCESSUS... 33 4.1 Méthodologies de niveau Stratégique... 33 4.1.1 Balanced Score Card... 34 4.1.2 Six Sigma... 37 4.1.3 Kaizen... 39 4.1.4 Lean Management... 40 4.1.5 Comparaison rapide... 47 4.2 Méthodologies de niveau Tactique... 48 4.2.1 Introduction au cycle de vie du projet... 48 4.2.2 Modèles traditionnels de développement logiciel... 51 4.2.3 Modèles agiles de développement logiciel... 53 4.2.4 Conclusion sur les modèles... 61 4.3 Méthodologies et certification... 62 4.4 Un changement? Un accompagnement!... 62 Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 5

5 EXEMPLE D APPLICATIONS... 67 5.1 Mise en place de référentiel Qualité... 67 5.1.1 Qui est Aubay du point de vue des référentiels?... 67 5.1.2 Comment choisit-on un référentiel chez Aubay SA?... 67 5.1.3 Comment utilise-t-on un référentiel chez Aubay SA?... 68 5.1.4 Comment s effectue la mise en œuvre?... 69 5.2 Certification CMMI... 70 5.2.1 Naissance d une volonté... 70 5.2.2 De CTRL à CMMI... 70 5.2.3 Les premiers pas vers CMMI... 70 5.2.4 Le vécu Aubay... 71 5.3 Un projet développé en mode SCRUM... 71 5.3.1 Contexte du projet... 71 5.3.2 Le choix de SCRUM... 72 5.3.3 Points clés... 72 5.3.4 Les facteurs qui ont permis le succès de la méthode... 73 5.3.5 Difficultés et ajustements... 73 6 CONCLUSION... 75 7 DÉTAIL SUR LES PROCESSUS ITIL V2... 76 7.1 Les processus du Soutien des Services... 76 7.1.1 Le Centre de Services (Service Desk)... 76 7.1.2 La Gestion des Incidents (Incident Management)... 76 7.1.3 La Gestion des Problèmes (Problem Management)... 77 7.1.4 La Gestion des Changements (Change Management)... 78 7.1.5 La Gestion des Mises en Production (Release Management)... 79 7.1.6 La Gestion des Configurations (Configuration Management)... 79 7.2 Les processus de Fourniture des Services... 80 7.2.1 La Gestion des Niveaux de Service (Service Level Management ou SLM)... 80 7.2.2 La Gestion Financière des services des TI (IT Services Financial Management)... 81 7.2.3 La Gestion de la Disponibilité (Availability Management)... 82 7.2.4 La Gestion de la Continuité des Services des TI (IT Service Continuity Management)... 84 7.2.5 La Gestion de la Capacité (Capacity Management)... 84 8 REFERENCES BIBLIOGRAPHIQUES... 86 9 ACRONYMES... 87 Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 6

TABLE DES FIGURES Figure 1 : Les 3 axes de contrainte d un projet... 10 Figure 2 : Les activités centrales de la gestion de projet... 10 Figure 3 : Courbe de Farmer sur la gravité, probabilité et traitement des risques... 11 Figure 4 : Exemple de Matrice des risques... 12 Figure 5 : Courbe en S des coûts... 13 Figure 6 : Les principales activités liées à la planification... 14 Figure 7 : Préconisations de planification... 15 Figure 8 : Une organisation projet type... 17 Figure 9 : Décomposition d un portefeuille de projets... 18 Figure 10 : Exemple de mise en place d une gouvernance... 20 Figure 11 : Cartographie des processus DSI et correspondance avec les référentiels SI existants... 23 Figure 12 : Schéma illustratif de ISO... 25 Figure 13 : Schéma illustratif de CMMI... 26 Figure 14 : Schéma illustratif de ITIL... 29 Figure 15 : Du rêve à la mise en œuvre avec les méthodologies au service de la DSI... 33 Figure 16 : Exemples d axes d optimisation selon les 4 perspectives stratégiques... 34 Figure 17 : Exemple illustré d une balanced scorecard... 35 Figure 18 : Le cheminement de la réflexion aboutissant à l action... 36 Figure 19 : Processus d amélioration continue... 37 Figure 20 : Organisation des certifications Six Sigma... 39 Figure 21 : Le modèle Toyota... 40 Figure 22 : Lean Management TPS... 42 Figure 23 : Illustration du processus d amélioration porté par OPEX... 42 Figure 24 : Les 4 phases de OPEX... 43 Figure 25 : OPEX, un changement de culture... 44 Figure 26 : OPEX, une organisation impliquant à tous les niveaux hiérarchiques... 45 Figure 27 : Gouvernance OPEX, une véritable dynamique d amélioration continue pérenne... 45 Figure 28 : Compétences Blue et Black Belt... 46 Figure 29 : Illustration du cycle de vie d un projet informatique (source CNRS)... 48 Figure 30 : Détail du cycle de vie (source CNRS)... 49 Figure 31 : Modèle en cascade avec un maquettage et un prototypage... 51 Figure 32 : Cycle de vie du processus unifié... 52 Figure 33 : Illustration du processus unifié... 53 Figure 34 : Illustration du modèle RAD... 55 Figure 35 : Représentation de la méthode SCRUM - déroulement d un Sprint... 56 Figure 36 : Comment construire le backlog... 57 Figure 37 : Illustration des 13 pratiques XP... 60 Figure 38 : Cycle de développement XP... 60 Figure 39 : illustration d une itération XP... 61 Figure 40 : Accompagnement au changement : 3 axes d actions... 62 Figure 41 : Cycle d acceptation du changement... 63 Figure 42 : Passage de la réticence à l action... 63 Figure 43 : Exemple de plan de communication... 64 Figure 44 : Une méthode d accompagnement en 4 grandes étapes... 65 Figure 45 : Quelques causes d échec au changement... 66 Figure 46 : Cycle de vie d un incident... 76 Figure 47 : Processus de gestion des incidents... 77 Figure 48 : Processus de gestion des problèmes... 78 Figure 49 : Processus de gestion des changements... 78 Figure 50 : Processus de gestion des configurations... 80 Figure 51 : Relation entre les clients et la gestion des niveaux de service... 81 Figure 52 : Processus de gestion de la disponibilité... 83 Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 7

Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 8

1 INTRODUCTION Plus que jamais, les responsables et gestionnaires des applicatifs métiers sont confrontés à l émergence de normes et standards «reconnus» internationalement. La pression est forte pour adopter et faire certifier son organisation par un label qui est sensé non seulement répondre à tous les problèmes, mais aussi et surtout prouver aux tiers que l organisation a adopté les «bonnes pratiques». CMMI, ITIL, ISO 9000, PMI, PRINCE2, COBIT, Six Sigma, etc. sont parmi les standards les plus répandus. Les avantages vendus avec ces normes, standards et référentiels sont multiformes et vont des performances opérationnelles les plus concrètes aux avantages stratégiques permettant des gains de compétitivité. Nous ne cherchons pas à nier les mérites intrinsèques de ces méthodes, mais il est évident que les coûts d implémentation sont très importants et que les résultats obtenus difficiles à mesurer. Le problème ne réside pas dans le référentiel en lui-même, mais dans son application et son adéquation avec le contexte particulier de l organisation qui l adopte. Toutes les méthodes ne sont pas adaptées à une organisation donnée. Cet ouvrage s adresse aux Directeurs des Services Informatiques et à toute personne qui souhaite améliorer la gestion des projets grâce à la mise en application d un référentiel méthodologique cohérent et adapté à l organisation des services informatiques. La question principale à laquelle nous avons voulu répondre est : «Comment mettre en place et utiliser un référentiel méthodologique Qualité dans une organisation de services dédiée aux systèmes d information et aux projets informatiques?». La première partie du livre blanc définit donc ce qu est un projet, le rôle de ses principaux acteurs ainsi que les grandes fonctions de la gestion de projets. La deuxième partie présente un panorama structuré mais non exhaustif des principaux référentiels et normes reconnus internationalement. Il ne s agit pas d une simple énumération et description des différents standards du marché, mais d une explication de leur succès et des bénéfices attendus de leur adoption par les DSI. La troisième partie concerne le choix d une méthode de gestion de projet. Enfin la cinquième partie présente l exemple de la société Aubay du point de vue du choix, de la mise en œuvre et de l utilisation d un référentiel Qualité et de différentes méthodes de gestion de projet. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 9

2 LE PROJET ET SES ACTEURS 2.1 Le Projet Un projet est un «ensemble d'activités qui sont prises en charge, dans un délai donné et dans les limites de ressources imparties, par des personnes qui y sont affectées dans le but d'atteindre des objectifs définis» (Source : AFNOR/Z 67-100-1). Ainsi, d après l AFNOR : " La gestion de projet est l ensemble des méthodes, outils d évaluation, de planification et d organisation permettant d atteindre ses objectifs en respectant les contraintes de performance, de délais, et de coûts». La conduite de projet aura donc pour fonction de maîtriser la qualité, les coûts et les délais de développement dans un souci d'efficacité et de rentabilité (efficience). On peut ainsi définir la conduite de projet comme étant l'ensemble des activités destinées à assurer le déroulement d'un projet dans les meilleures conditions de coût, de délai et de qualité des résultats ; ces 3 conditions étant antinomiques par nature. Figure 1 : Les 3 axes de contrainte d un projet La gestion de projet est une démarche visant à organiser et gérer, de bout en bout, le bon déroulement d un projet. Cette démarche repose sur certaines actions : mettre en place l organisation et la planification de l ensemble des activités visant atteindre les objectifs du projet exprimés en termes de qualité, coûts et délais (voir schéma ci-dessus), effectuer leur suivi, anticiper les risques potentiels, décider et communiquer. Vous trouverez ci-dessous une description des principales fonctions de la gestion de projet et de ces principaux acteurs. Figure 2 : Les activités centrales de la gestion de projet Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 10

2.2 Principales activités inhérentes à la gestion de Projet 2.2.1 Gestion des risques D'après le National Institute of Standard Technology (NIST), le risque est «la possibilité que quelque chose de défavorable puisse survenir (1995)» puis le NIST a changé de définition en 2001 : «impact net négatif de l'exploitation d'une vulnérabilité considérant sa probabilité et son impact de réalisation». Nous nous référerons aux définitions issues de la norme ISO/CEI 73 : «combinaison de la probabilité d'un événement et de ses conséquences», et de l ISO/CEI51 : «combinaison de la probabilité d un dommage et de sa gravité». Ainsi, la notion de risque repose sur deux concepts principaux : le facteur de risque, qui représente un élément présent dans le projet, susceptible de provoquer une perturbation, et la criticité qui, associée à un facteur de risque, désigne la combinaison entre la gravité de l impact et la probabilité du risque. Le risque est inhérent à tous les projets. Dans le jargon de la gestion de projet, le «risque» désigne un événement incertain qui, s il advient, aura un effet négatif sur les objectifs du projet ainsi qu un impact sur les coûts, l échéancier ou la qualité du projet. Il convient donc de les identifier et d en estimer l impact. L occurrence et les conséquences d un risque sont liées au cycle de vie du projet. En début de projet la probabilité d occurrence d un risque est élevée mais son impact généralement faible, alors qu en fin de projet la probabilité d occurrence est faible mais son impact critique pour le projet. Figure 3 : Courbe de Farmer sur la gravité, probabilité et traitement des risques La première étape dans la création d un plan de réponse consiste à rédiger un recueil de risques avec tous les intervenants du projet. Les intervenants peuvent définir les risques en se fiant à leur expérience. Ce document recueillera la description des risques identifiés, ainsi que le niveau de criticité associé, la nature de leur impact (cout, délai, qualité), et une estimation du risque ainsi que le service ou la personne responsable du suivi du risque. Il est impossible de se préparer à tous les risques mais les risques hautement probables et ayant des répercussions considérables doivent requérir une intervention immédiate. La réduction ou l accroissement des risques projet dépend de l efficacité de votre planification. Comme tous les risques ne sont pas facilement identifiables au début du projet, il importe de prévoir régulièrement un examen des risques lors de réunions dédiées avec l équipe projet. Les risques ainsi identifiés doivent faire l objet d'un rapport soulignant la réaction privilégiée. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 11

Figure 4 : Exemple de Matrice des risques Ainsi, afin de se prémunir contre les différents facteurs de risques pouvant perturber le déroulement d un projet, il est préconisé de déployer une procédure d analyse et de gestion des risques. Celle-ci peut suivre la démarche suivante : 1) Inventorier les risques Type de risques potentiels : financiers, organisationnels, techniques, sociaux, environnementaux. Méthodes d identification : larges consultations, enquêtes, exploration des archives, analyse de la mémoire des projets antérieurs, consultation d'experts. 2) Evaluer et valoriser les risques. Evaluer la criticité de chacun des risques en termes d'impacts, de dommages, de conséquences et en termes de probabilité d occurrence, afin d établir un indice de criticité pour chaque risque. Puis traduire le risque en coût. 3) Définir les parades. L on peut identifier 4 réactions que l on peut adopter face à un risque : L évitement : Si une activité présente un risque, il est préférable de l'éviter. L'acceptation : le risque est accepté et des provisions sont allouées pour l amortir. La réduction du risque : maîtrise des risques par des mesures de protection et de prévention : c'est la démarche classique de gestion des risques. Le transfert : contraction d une assurance ou recours à la sous-traitance (qualifiée, mieux a même de réduire le risque). 4) Identifier les points critiques Les points critiques sont associés aux risques de criticité maximale. Il s agit ici d identifier les instants du déroulement du projet où il faudra redoubler de vigilance. 5) Construire et réviser la table des risques Suivi de l évolution des risques au cours du projet. Exemple d une table des risques : Risque Criticité Action Responsable Durée Echéance Ressources Coût (en heures) 6) Capitaliser l expérience En renseignant par exemple une base de données des risques propre à une typologie de projet. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 12

2.2.2 Gestion budgétaire Un budget a deux utilités fondamentales. D une part, il permet de garantir au chef de projet les moyens financiers de son action et, d autre part, il lui fournit un cadre d engagement évitant ainsi le risque de débordements incontrôlés. Le budget se construit en lien avec la planification du projet. Idéalement, un budget devrait être la déclinaison annuelle de la partie «coûts d investissement» d un plan d investissement. Le suivi budgétaire est un exercice permanent pour le chef de projet. Avant chaque engagement de dépense, en fonction de sa nature, il en vérifie la disponibilité dans son budget. Le budget est défini suivant un processus d estimation, qui est intrinsèquement lié à l activité de planification. Toute activité de planification étant prospective, elle repose sur un processus d estimation ; estimation de la durée (calendrier) et des coûts (efforts), couplée à une analyse des risques. Ce processus couvre une activité qui comporte des difficultés intrinsèques. Cette estimation ne peut être correcte que lorsque le logiciel est appréhendé dans son intégralité, elle requiert d être affinée progressivement. Le processus d estimation est déployé sur 3 phases : lors de la réponse à l appel d offres pour chiffrer la proposition et établir le budget, lors de la planification du projet pour établir le plan du projet et le plan qualité, et bâtir ainsi le référentiel contractuel, au cours du suivi du projet pour mettre à jour le référentiel et affiner les prévisions. Le processus d estimation suit 3 étapes : l estimation de la taille du produit, suivant le nombre de lignes de code, la méthode des points de fonction ou la méthode des features points, l estimation de l effort, en hommes / mois, suivant par exemple la méthode de COCOMO, l estimation de la durée, en mois ou semaines calendaires, suivant l élaboration de différents scénarios de planification. Ces différentes estimations définissent la partie variable, les coûts salariaux, à laquelle il convient d ajouter les frais fixes (locaux, équipement ) pour définir le budget prévisionnel. Visualiser l avancement de son projet et les dépenses effectuées. La courbe en S est un outil graphique de suivi de l'avancement d'un projet pouvant mettre en lumière sa situation économique. Cet indicateur permet notamment de montrer l'évolution des dépenses réelles cumulées ou "coût réel" au cours de l'avancement du projet et d'estimer à un instant T du projet des écarts prévisionnels en termes de coûts et de délais. La construction de cet indicateur s'appuie sur la réalisation de 3 courbes : une première courbe appelée Coût Budgété du Travail Prévu représentant le budget prévisionnel du projet (coûts + temps) ; une deuxième (Coût Réel du Travail Effectué) qui représente l'avancement effectif du projet à une date T. Et une troisième courbe "virtuelle" (Coût Budgété du Travail Effectué) qui symbolise l'avancement physique du projet. Pour réaliser ce type de graphique, il faut en amont du projet définir une première courbe prévisionnelle de réalisation (CBTP) au lancement du projet. Puis à un instant T, le chef de projet peut définir une seconde courbe, qui représente la courbe réelle de réalisation. Il peut enfin définir une troisième courbe qui donnera la valeur du travail réalisé en valeur budgétaire, soit les dépenses en temps et en coûts réellement effectués au cours de la période. L'écart entre les courbes CBTE (3) et CRTE (2) sur l'axe des abscisses illustre le retard d'avancement entre le travail effectué et le travail prévu. L'écart entre ces deux courbes, sur l'axe des ordonnées représente la différence en coûts entre le coût budgété et le coût réel. Cette méthode permet donc de visualiser les écarts, et l éventuelle dérive budgétaire d un projet, à charge au chef de projet d en analyser les raisons et d y apporter les correctifs nécessaires. Dans des contextes budgétaires de plus en plus tendus la direction de projet est souvent plus challengée sur la tenue de son budget que sur certains aspects délais ou qualité. Figure 5 : Courbe en S des coûts Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 13

2.2.3 Planification Le planning est un outil fondamental du chef de projet. Il trace le cadre de travail du projet, fournit les objectifs (coûts, délais), et présente une perspective globale du travail en commun. C est un élément fédérateur de motivation qui doit être réaliste. En cas de dérive, il est important de mettre en place des actions correctives, pour qu il conserve son rôle de stimulation. Le planning est un outil de base pour le suivi de projet, il est indispensable à tout bon pilotage. Son suivi permet la maîtrise des délais, des coûts et de la qualité du projet. Ce suivi est une activité itérative qui commence avec l initialisation du planning et se termine avec la fin du projet. Objectifs de la planification Offrir une vision sur le long terme du déroulement du projet : anticiper, prévoir. Identifier et ordonnancer les actions du projet : organiser et piloter. Allouer les ressources aux tâches : gérer les ressources et le travail. Suivre l avancement et le respect des objectifs : contrôler et corriger. Reporter aux instances décisionnelles : communiquer et informer. Figure 6 : Les principales activités liées à la planification Ainsi, le planning présente des informations fondamentales pour la prise de décision. La première planification détaillée doit fournir une vision globale sur le long terme du projet, et détailler les phases planifiées sur au moins 6 mois. Cette planification représente le scénario de départ du projet, et établit la baseline, le référentiel en termes de délais et de coûts. En premier lieu, la construction d un planning s initie par le choix d un Work Breakdown Structure (WBS), déterminant l arborescence (l organisation du réseau de tâches récapitulatives et de sous-tâches) du planning. Il semble préférable de suivre un WBS respectant au mieux la logique de développement et donc les processus. Cependant, pour diverses raisons (contrôle de gestion ) on pourra préférer différents types de «découpage». A titre d information voici les différents types de découpage existants : L Organization Breakdown Structure (OBS), qui respecte l organisation industrielle de l entreprise (découpage de la structure arborescente par directions, services ) Le Product Breakdown Structure (PBS), découpage qui respecte l architecture du produit développé (découpage par ensembles, sous-ensembles ). Le Resources Breakdown Structure, qui représente l ensemble des ressources de l entreprise. C est le prolongement de l OBS, qui permet de planifier les tâches en allouant des ressources nominatives (c est aussi possible avec un PBS ou un WBS). Le Work Breakdown Structure, décomposition hiérarchique, axée sur les tâches et activités que l équipe de projet doit exécuter pour atteindre les objectifs du projet et produire les livrables voulus. C est le terme générique employé pour désigner la structure arborescente de décomposition du projet, permettant sa planification. Le but étant d aboutir à une planification assez fine pour obtenir des prévisions fiables. Il est préférable de choisir une structure logique se rapprochant le plus possible de la méthodologie de développement (processus) de l entreprise, pour construire un planning cohérent et logique. Ainsi, dans le cas des systèmes d information, il semble judicieux d opérer un découpage suivant le cycle de développement, qui offre une cohérence de regroupement (Définition, Développement, Exploitation, Maintenance/Evolution), et permet d introduire une certaine logique chronologique. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 14

Méthode préconisée pour établir la planification initiale : Si des référentiels existent dans l entreprise, il est nécessaire de se les approprier, sinon, il convient de les concevoir. 1) Identification des grandes phases, des principaux livrables et des jalons majeurs relatifs au projet de développement. Ressources : processus standard de développement et standards de gestion de projet de l entreprise. Le cas échéant, animation de groupes de travail spécifiques 2) Découpage des phases du projet en tâches et sous-tâches, allocation d une durée, d une charge et d un type de compétences à chaque tâche. Ressources : processus standards des différents services. Le cas échéant, animation de groupes de travail spécifiques (ex : construction de rétro-plannings détaillés ). 3) Définition de la logique d enchaînement des tâches pour construire le diagramme PERT. 4) Allocation des tâches suivant l OBS, puis le RBS. 5) Analyse des résultats de la planification : délai final, chemin critique et marges. 6) Optimisation du planning, modification de l enchaînement des tâches et gestion de la charge / capacité. 7) Edition de la planification initiale sous forme claire et lisible, par un diagramme de GANTT. Il est important d identifier clairement les livrables et les jalons (tâches de durée et de travail nuls), car ils représentent à eux seuls des indicateurs de pilotage primordiaux. Il est capital d intégrer les liens entre les tâches (et entre les tâches et leurs livrables), ainsi que les inputs nécessaires (livrables externes), afin d obtenir une planification pertinente. Figure 7 : Préconisations de planification Une fois la planification établie, on construit le plan de travail. Illustration d un plan de travail : Tâche Description Responsable Indicateur de fin (livrable) Enchaînement (entrée) Durée Echéance Ressources Estimation Du coût (en heures) A partir de ce plan de travail global, on transmet à chaque service un ordre de travail, reprenant l ensemble des tâches qui le concerne. Cet ordre de travail engage le service sur des objectifs précis, et contractualise sa participation au projet. 2.2.4 Reporting Le reporting représente la synthèse nécessaire à la maîtrise des objectifs et aux prises de décision. Il est principalement un outil destiné à fournir de l information décisionnelle. C est est un document de synthèse destiné aussi bien à la direction qu aux équipes projet, il est communiqué selon une périodicité définie, ce qui facilite la compréhension de l évolution des indicateurs du projet. Le reporting doit permettre de comprendre rapidement la situation d un projet à l aide de synthèses, notes chiffrées, tableaux de bords ou KPI. Un KPI (Key Performance Indicateur) est un paramètre qui se veut le plus représentatif de l activité du projet et qui permet d'évaluer la performance globale de ce dernier en fonction des objectifs attendus. Ces indicateurs doivent être à jour en permanence pour pouvoir répondre aux besoins du top management. Le KPI peut porter sur tout type d information : l état des dépenses du projet, les risques, la qualité etc. Il est primordial de ne sélectionner que des indicateurs susceptibles de délivrer une information de mesure de la performance cohérente avec l objectif poursuivi. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 15

La complexité du calcul et la difficulté de collecter les données ne sont pas les critères de valeur pour qualifier la pertinence d un indicateur. Un bon indicateur doit être simple à construire sans nécessiter des données inaccessibles ou des calculs difficiles à comprendre. La forme du KPI (diagramme à barre, camembert ou autre) n a pas grande importance il se doit d être avant tout visuel et facilement compréhensible. Le KPI apporte une information, qu il convient d analyser pour mettre en œuvre les actions adéquates. 2.2.5 Contrôle qualité Le processus qualité, spécifié par la norme ISO 9000-3, décrit l ensemble des activités et des produits qui certifient que le logiciel développé satisfasse aux exigences de qualité requises. Il remplit deux fonctions principales : l'assurance qualité : Démarche préventive visant à éviter les problèmes de non conformité à la spécification et d'inadéquation aux besoins, ensemble des actions préétablies et systématiques nécessaire pour donner la confiance appropriée en ce qu'un produit satisfera aux exigences données relative à la qualité (définition AFNOR NFX 50-120). L assurance qualité se formalise dans le plan qualité, qui répond aux clauses qualités exigées par le client. le contrôle qualité : Ensemble des actions dont le but est de vérifier la conformité d'un produit et d'un processus de développement, au plan qualité préétabli (par l'assurance qualité). Le contrôle qualité s effectue principalement par le biais des actions suivantes : les audits (contrôles permettant de vérifier le respect des procédures qualité), les revues (vérifications de la conformité des résultats d'une phase), les inspections (mesures de critères qualité), les lectures croisées (vérifications de documents avant leur passage en revue). 2.2.6 Gestion des engagements du projet Les engagements majeurs d un projet sont en grande partie gérés par le processus qualité. Un contrôle périodique permet le suivi de l'avancement du projet et le contrôle de l'atteinte des objectifs. Ce contrôle s'effectue par des réunions périodiques aux différents niveaux requis (opérationnel, décisionnel), et est retranscrit aux différents partenaires lors des comités projet et des comités de pilotage. Au cours de ces réunions, les principaux livrables de Gestion de projet sont mis à jour : journal de bord, planning, fichier d'analyse des risques et plans d'action. Les problèmes se rencontrent au fil du temps, et sont exposés lors des activités de suivi et de contrôle périodique. Les plans d action, chargés d y remédier sont construits parfois lors des réunions de suivi elles-mêmes (ceux-ci se bâtissent, s étoffent et sont suivis), parfois, pour les sujets plus techniques, lors de réunions dédiées. Illustration d un plan d action standard : Problème Action Description Responsable Durée Echéance Ressources Estimation Du coût (en heures) 2.3 Principaux acteurs de la gestion de projet. Un projet est par définition un travail collectif, engageant plusieurs entités et de nombreux acteurs autour d objectifs partagés, qui se matérialisent dans une réalisation concrète. La fonction première de la gestion de projet est d organiser et de contrôler le processus technique encadrant le développement du nouveau produit. L organisation des activités a pour but de gérer la complexité relationnelle inhérente au projet, de diriger et de coordonner le travail des différentes entités et de la multitude d acteurs avec un souci constant d efficience. Un des pré-requis essentiel à une bonne conduite de projet est donc l identification des entités engagées. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 16

Figure 8 : Une organisation projet type Brève description des principales entités impliquées dans la conduite d un projet : Le Sponsor Le Sponsor est le représentant du projet auprès des plus hautes autorités exécutives de l organisation. Il finance le projet, et à ce titre il est le plus exposé aux différents risques, (allongement des délais, augmentation des coûts planifiés, et dégradation de la qualité ou des fonctionnalités). Il est donc un des acteurs majeurs des comités de pilotage. Le rôle du sponsor est généralement pris en charge par un membre confirmé de l exécutif de l organisation ou par un groupe de management. La maîtrise d ouvrage - MOA Le terme maîtrise d ouvrage fait référence au commanditaire d un produit ou d un service pour lequel un projet spécifique va être développé. La maîtrise d ouvrage est donc l entité porteuse du besoin. Elle définit les objectifs, le calendrier et le budget associés au projet. Elle représente l utilisateur final. A ce titre, l une de ses fonctions fondamentales est d exprimer son besoin, de définir le produit, et de spécifier ses exigences. En tant que commanditaire, elle assure un suivi régulier du projet pour sécuriser son avancement. Elle dirige l étape de qualification pour vérifier la conformité du produit développé avec ses exigences, participe activement à la conduite du changement et à la mise en œuvre du produit pour l implémenter dans son organisation. Une fois le produit réceptionné, vérifié et validé, elle peut librement l exploiter, et assure son bon fonctionnement par la mise en place d une maintenance adéquate. La maîtrise d œuvre - MOE La maîtrise d œuvre est l entité retenue par la MOA pour réaliser l'ouvrage, dans les conditions de délais, de qualité et de coût fixées par cette dernière conformément à un contrat. Elle dirige donc le développement du produit défini par la MOA, assure sa conception et sa réalisation. Elle s implique aussi fortement dans la conduite du changement et dans la mise en œuvre du produit chez son client. Ainsi maîtrise d ouvrage et maîtrise d œuvre ont des fonctions complémentaires et déterminantes pour le développement d un projet. La réussite de celui-ci dépend donc directement de la relation entre ces 2 acteurs, de leur coordination et de la communication entre ces 2 instances majeures. Les fournisseurs Un fournisseur est une organisation externe qui fournit des produits ou des services requis par un projet. Ayant des intérêts communs stratégiques, les fournisseurs et leurs clients développent des relations partenariales fortes, concrétisées le plus souvent par un processus de certification interne. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 17

L équipe Projet L équipe projet intègre l ensemble des acteurs internes fonctionnels impliqués dans la conduite et la réalisation d un projet. Afin de mener à bien un projet complexe, l équipe projet regroupe des membres aux profils et aux compétences complémentaires. Ceux-ci peuvent être : un ou des chefs de projet, des analystes développeurs, des architectes (techniques et fonctionnels), des administrateurs de données. Afin d assurer l efficience et la coordination du travail d équipe que représente un projet, différentes méthodes de management ont été élaborées, dont l une des plus célèbres est la méthode SCRUM. Ainsi, les activités de gestion de projet peuvent mobilisées de nombreux acteurs tels que : Responsable d un portefeuille de programmes ou de projets Directeur d un programme Directeur de projet Chef de projet PMO Responsable fonctionnel Directeur opérationnel Directeur de la qualité Client Il convient de préciser que le rôle de ces acteurs reste très dépendant du niveau de maturité de l entreprise dans la mise en œuvre des processus de management de projets, cependant leur existence est globalement garantie d une organisation à l autre. En fonction de l importance du projet, différents intervenants sont amenés à exercer une activité de management, il est donc important de connaître la typologie des projets, la décomposition d un portefeuille de projets. Figure 9 : Décomposition d un portefeuille de projets Selon l importance du projet, son positionnement dans le portefeuille de projets, différentes fonctions relatives au domaine de la conduite de projets, sont requises pour assurer le pilotage. Quelques unes de ces dernières sont décrites ci-dessous. 2.3.1 Directeur de Projet Le directeur de projet supervise la conception et la réalisation de projets importants, stratégiques, et souvent de dimension internationale. Le directeur de projet est donc responsable de l'aboutissement d'un projet sur le plan : du budget/coût des délais (planning, jalons) du respect de la réponse aux besoins (spécifications) de la qualité (tests, recettes...) Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 18

Il coordonne les travaux de la MOA, de la MOE ainsi que ceux de tout autre acteur impacté par le projet (juridique, marketing, informatique, technique, formation des personnels, organisation, logistique, communication...) Il doit s assurer que les travaux sont conduits dans les règles de l'art (standards qualité, méthode, techniques, réglementaires) et dans le respect du cadre fixé au projet (budgets, délais, réponse aux besoins). Il est garant que l'ensemble des impacts sur les différentes fonctions de l'entreprise ou de l'organisation soit bien identifié et pris en compte. Les difficultés éventuelles doivent donc être bien identifiées et anticipées suffisamment tôt. Il est responsable de la bonne évaluation et maîtrise des risques et des mesures d évitements nécessaires. Il s assure que des solutions sont proposées avec des argumentations suffisantes (avantages, inconvénients, scénarios, impacts,...).le directeur de projet prend les décisions en fonction des enjeux (gestion des priorités) tout en les hiérarchisant. En termes d outils, le Directeur de projet utilisera principalement des Comités de Pilotage et par conséquent, ses qualités principales devront être d avoir une bonne capacité d'analyse et de synthèse. En résumé, le Directeur de projet pilote le projet dans le cadre fixé par la maîtrise d'ouvrage et en accord avec les chefs de projet de la maîtrise d'œuvre. Il veille au respect des spécifications, des délais, du budget et des standards de qualité. Il doit anticiper les impacts en s'assurant que les répercussions des changements sur les différentes fonctions de l'entreprise ou de l'organisation sont bien prises en compte. Il a en charge la conduite du changement notamment dans le cas de réorganisations, de fusions,... Il arbitre en prenant les décisions nécessaires dans le respect des impératifs, objectifs et contraintes des différents acteurs de l'entreprise ou de l'organisation, tout en veillant à rapporter ces décisions aux enjeux et aux objectifs fixés par la maîtrise d'ouvrage. Le Directeur de Projet conduit donc un projet complexe, souvent avec plusieurs entreprises, des contrats importants et des équipes nombreuses. Le plus souvent, le projet implique plusieurs pays et plusieurs cultures. 2.3.2 Chef de Projet Le chef projet est la personne chargée de mener un projet et de contrôler son bon déroulement. De manière générale, il dirige ou anime une équipe pendant la durée du projet dont il a la charge. Il est responsable d'un projet de taille limitée, souvent interne à un seul département et avec une équipe réduite, il peut être chargé de contrôler le bon déroulement du développement d'un logiciel (ex projet informatique). Il peut avoir à mettre en place une nouvelle organisation au sein d'une entreprise (ex projet organisation) ou développer un nouveau produit (ex projet R&D). Il peut aussi avoir à construire un outil de production (ex projet industriel). Pour mener à bien son projet, il le structure pour arriver à une date clé. Il doit contrôler son bon déroulement. Il a également la charge de fédérer, diriger et animer une équipe dédiée au projet. Il s assure de la bonne communication des informations du projet avec les dirigeants, soutien indispensable au bon déroulement du projet. Il travaille avec le sponsor pour faire clarifier et formaliser les objectifs. Il peut également avoir à organiser des ateliers utilisateurs ou d'expression de besoin en début de projet pour impliquer les utilisateurs. Ses outils sont aussi bien les Comité de Projet (comité de pilotage, comité de suivi etc.) que les outils de gestion de planning (Gantt, PERT) ou l analyse fonctionnelle. Ses qualités maîtrise instrumentale du pilotage de projet (les outils) maîtrise des champs techniques impliqués dans le projet (le métier technique) compétences sociales (le travail en groupe) compétences de traduction entre les langages des métiers (le rôle de facilitateur) bonnes capacités relationnelles connaissances techniques dans les domaines concernés En résumé, le chef de projet est central sur tous ces aspects. Il représente statistiquement 75% des facteurs de succès du projet. Il est souvent très proche d'un rôle de gestionnaire de projet ou de planificateur, c'est le bras droit du Directeur de projet. 2.3.3 Project Manager Officer Le PMO est l entité ou le groupe dans une entreprise qui définit et maintient le référentiel des processus liés à la gestion de projet. Le PMO a pour objectif de standardiser et d industrialiser les projets. Le PMO a en charge la documentation, le tutorat et l'évaluation de la gestion des projets, ainsi que le suivi de la mise en œuvre. Le PMO a la charge de fournir une liste et une situation à jour des projets. Il doit avoir une compréhension des interdépendances entre les projets ou programmes et par là permettre une reprogrammation rendue nécessaire par les changements rapides des priorités et du marché. Il est amené à appliquer ou à mettre en œuvre des processus permettant aux managers d atteindre les résultats dans les délais, les coûts et les spécifications requises. Le PMO est également responsable de fournir de l information à jour et en temps voulu Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 19

qui permettra une optimisation en termes de préparation, d allocation et de management des ressources. Il informera de l évolution des risques majeurs et des correctifs mis en œuvre. Il est chargé d'aligner ses projets sur un plan stratégique ; c'est-à-dire de disposer d une visibilité sur les projets permettant à une Direction Générale de décider et d arbitrer en connaissance de cause, d optimiser les ressources, de sécuriser le déroulement des projets majeurs (Fonction portefeuille de projets). Il doit faciliter l'intégration des chefs de projets débutants, et disposer d un référentiel partagé qui facilite le dialogue (stratégique, opérationnel et économique) et la maîtrise des projets (Fonction Normes et Méthodes). Le PMO travaille à améliorer la qualité du management de projet, à accélérer les projets à travers une meilleure compréhension des acteurs externes et des attendus et des rôles de chacun (Fonction Formation). Il aide à mieux maîtriser les projets, améliorer les compétences et les comportements des chefs de projets (Fonctions conseil et coaching). Il doit également prendre en charge les différents tâches répétitives (mise à jour du planning projet, des feuilles de temps et des actions, archivage et historique de projet...) afin que le chef de projet se concentre sur le management et les points (Fonction support). Ses outils Le PMO doit avoir une bonne connaissance d outils tels que Planisware, Augeo, Artemis, Compuware, CA, SAS, Oracle HP, IBM-Cognos. Il doit être capable de fournir des tableaux de bords et indicateurs synthétiques permettant une compréhension de l état réel du ou des projets dont il a la charge. Le PMO est également responsable de la bonne utilisation et animation des outils de planification. Ses qualités confiance, leadership et motivation rigoureux, organisé, curieux et pugnace goût des chiffres capacité à récupérer puis transmettre l information En résumé, le PMO s assure que les projets lancés soient pertinents (stratégiquement, économiquement, techniquement), il doit être capable de prioriser les projets entre eux. Il sécurise et maîtrise les projets à enjeux majeurs (objectifs tenus : stratégiques, opérationnels, économiques) et dispose d un état d avancement des projets conformes à la réalité. Il s assure que l impact des projets sur le fonctionnement quotidien de l entreprise soit sous contrôle (projets internes) et fait fonctionner de concert les niveaux stratégiques, opérationnels et économiques. 2.4 Gouvernance de projet Il est important et ce quelque soit la taille du projet de se poser le plus tôt possible les bonnes questions quant à la gouvernance projet comme ; quelle est l organisation de l entreprise? Faudra-t-il créer des instances? Pourrons-nous utiliser les instances existantes? Comment faire prendre et par qui les décisions ou arbitrages? etc.. La gouvernance d'un projet recouvre l'ensemble des instances à mettre en place pour assurer un bon pilotage d'un projet. En fonction de la taille du projet, on aura une complexité de gouvernance croissante. Figure 10 : Exemple de mise en place d une gouvernance Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 20

Rôles et responsabilités de chaque Instance de gouvernance Comité de Pilotage Programme Il pilote le budget global alloué au programme, définit les priorités et réalise les arbitrages inter-chantiers, il effectue le suivi des KPI du Programme. Il pilote la mise en œuvre du programme : validation du macro-planning consolidé et garantie du respect des jalons clés du programme, revoit l avancement global et les événements clés, pilote les risques transverses au programme ; Il valide la communication du Programme vers les utilisateurs. Comité de suivi du Programme Restreint Il assure la coordination fonctionnelle et métier entre les chantiers. Il effectue / prépare les arbitrages entre les chantiers. Il effectue le suivi du Programme : suivi des risques, suivi budgétaire (budget, plan strat), suivi des actions, valide les règles de fonctionnement du Programme et suit les pratiques de pilotage des projets. Il prépare les Copil Programme, et il pilote le plan de charge et le sourcing du programme. Comité de suivi du Programme Sinistres - Elargi Il supervise la bonne gestion opérationnelle des projets du Programme et assure la coordination entre les Chantiers et les Coordinations, de manière à ce qu il n y ait pas de «zone d ombre» : Suivi de l avancement des Coordinations et des Chantiers : faits marquants, risques / alertes / problèmes Communication des orientations stratégiques ou des décisions prises dans le cadre d autres instances Partage des règles de fonctionnement sur le Programme Suivi du budget consolidé du Programme Partage du planning, des étapes métier Suivi des actions Pilotage du staffing du programme (remontée des besoins, problèmes de staffing Programme) Il garantit la mobilisation de l ensemble des contributeurs et maintient un niveau d information homogène sur le programme. Comité de Pilotage Chantier Il garantit la mise en œuvre des orientations stratégiques sur le chantier et la réalisation des gains associés au chantier. Il pilote la mise en œuvre du chantier en s appuyant sur les indicateurs de pilotage : revues d avancement global du chantier, garantie du respect des jalons clés, pilotage des risques, etc. Il définit les priorités, valide les arbitrages nécessaires au sein des projets et prend les décisions clés sur le chantier : Décisions métier Arbitrages inter-projets, jalons clés, budget, etc. Il prépare le reporting et la communication vers le COPIL Programme et il réalise un suivi régulier des gains / KPI associés. Comité de Suivi Chantier Il suit l avancement de l ensemble des projets du chantier : jalons et livrables, consommés et reste à faire, activités réalisées et à réaliser. Il présente les indicateurs de suivi du chantier et partage les analyses correspondantes et il gère les adhérences entre les projets du chantier. Il pilote le sourcing des projets du chantier et consolide les analyses de risques des projets et les plans d actions associés. Il prépare le reporting et sujets à faire valider ou arbitrer par le COPIL Chantier. Comité de Pilotage Projet Il met en œuvre les orientations définies par le COPIL Chantier, il assure les revues d avancement du projet sur les jalons clés. Il suit et analyse les indicateurs de pilotage du projet et valide les arbitrages à réaliser au sein du projet. Il prépare la communication et les sujets à faire valider ou arbitrer par le COPIL Chantier : Arbitrage sur les changements de périmètre du projet : extension, arrêt, re-planification, proposition de différents scénarios en fonction des ambitions et des moyens Actions de maîtrise des risques Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 21

Comité de Suivi Projet Il suit le bon déroulement du planning et fait le point sur les activités du projet (réalisées et à réaliser), il présente les indicateurs de suivi du projet et partage les analyses correspondantes. Il coordonne l intervention des différents contributeurs sur le projet, et analyse la faisabilité du plan de charge par rapport aux objectifs et contraintes du projet (notamment jalons clés). Il fait le point sur les livraisons du projet et identifie et anticipe les risques sur le projet, examine et résout les difficultés rencontrées. Il prépare les reporting et sujets à faire valider ou arbitrer en comité de Pilotage Projet. Comme évoqué précédemment l organisation de la gouvernance dépendra beaucoup de la taille du projet, de son coût ou de son impact pour l entreprise. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 22

3 PRINCIPAUX REFERENTIELS QUALITE Qu est-ce qu un référentiel? Un référentiel est une collection de bonnes pratiques sur un sujet donné. Lorsque qu il fait l objet d une large diffusion et qu il est reconnu par le marché on parle alors de standard. Les référentiels doivent être perçus comme une boîte à outils de laquelle l expertise extrait les bonnes pratiques dont elle a besoin pour résoudre un problème donné ou pour répondre à un besoin. (ex : ITIL pour la gestion de la production). La norme se différencie des référentiels dans la mesure où il s agit d un document édité par une instance de normalisation indépendante, par exemple l ISO, faisant l état de l art d un sujet donné (ex : ISO 27001 pour la sécurité de l information). La norme peut avoir un niveau de contrainte supplémentaire par rapport au référentiel. Les référentiels sont au cœur des processus de la DSI, car ils permettent aux DSI d améliorer le degré de maîtrise de leur SI. La nomenclature, quant à elle permet de décomposer une problématique (Ex : les coûts de la DSI) en éléments plus fins et homogènes permettant de se comparer à d autres entreprises. Enfin la méthodologie est une démarche structurante pour réaliser une tâche donnée, exemple : le développement en cycle en V. Les référentiels sont nombreux et dans le domaine de l informatique, on peut citer : ISO 27000, CMMI, ITIL, TOGAF, ISO 9001, COBIT, etc. Nous en détaillons 3 d entre eux. Selon le CIGREF, les 3 référentiels les plus cités par les entreprises sont ITIL pour la production, ISO 27001 pour la sécurité et la nomenclature RH des emplois métiers du CIGREF. Les référentiels de gouvernance (COBIT), de développement (CMMI), de gestion de projet, de qualité (ISO9001) et de suivi des coûts (benchmarking) les suivent. Les trois référentiels les moins utilisés, d après leur enquête, sont TOGAF pour l architecture d entreprise, Prince 2 pour la gestion de projet et escm pour la gestion de la relation clients fournisseurs. Figure 11 : Cartographie des processus DSI et correspondance avec les référentiels SI existants Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 23

3.1 ISO 9001 3.1.1 Qu est-ce que ISO 9001, exactement? En guise de préambule, précisons qu un référentiel est une collection de bonnes pratiques sur un sujet donné. Une norme se différentie des référentiels dans la mesure où il s agit d un document édité par une instance de normalisation indépendante, en l occurrence, ISO (International Organization of Standardization), qui dispense le plus souvent, suite à un audit, une accréditation gage de qualité et de compétence. ISO 9001 est une norme internationale qui définie les exigences de la gestion de la qualité d une entreprise ou d une de ces entités (filiale, département, service). Elle est une norme internationale de gestion générale de la qualité. En ce sens, elle est comparable au Plan Comptable de la comptabilité générale. Elle prend en compte la gestion non financière de l entreprise, de la même façon qu IFRS/IAS prend en compte la gestion financière de l entreprise. La bonne corrélation de ces deux gestions est au cœur de la production de richesse et, notamment, de l innovation. Les exigences répertoriées par ISO 9001 sont analogues à des pratiques génériques applicables à tous les métiers. De fait, toutes sortes d entreprises peuvent faire certifier conforme à ISO 9001, leurs solutions de gestion de la qualité : un restaurant d entreprise, un centre hospitalier, une SSII. Un certificat dure 3 ans. Il est renouvelable chaque année. Ainsi de la même façon que la gestion financière peut être certifié conforme à IFRS/IAS par des commissaires aux comptes. Chaque année, des commissaires aux comptes qualités réalisent un audit de la gestion de la qualité. 3.1.2 Qu est-ce que n est pas ISO 9001? ISO 9001 n est pas un référentiel de bonnes pratiques spécifiques à un métier. De la même façon qu il serait absurde de demander à IFR/IAS une expertise sur les métiers de l entreprise, de la même façon ISO 9001 ne fournit pas de réponse d experts métiers pour la mise en œuvre des meilleures pratiques métiers. Les bonnes pratiques doivent préexister et sur ce socle vient se greffer la gestion de leur qualité. Cette gestion de la qualité accroit la visibilité sur les bonnes et les mauvaises pratiques. Elle est un outil d aide à la décision qui permet d identifier les activités les plus porteuses de satisfaction client. Elle fiabilise la mise en œuvre régulière et stable des activités prévues et de leurs résultats attendus. Elle garantie que l entreprise réfléchit collectivement et méthodiquement en vue de s améliorer en permanence. 3.1.3 Que s attend-t-on à trouver dans une entreprise certifiée ISO 9001? Une entreprise certifiée ISO 9001 est une entreprise de confiance, dynamique, qui bouge en permanence, qui accroit ses performances avec une gestion de la qualité garantie. Cette entreprise possède : Un dispositif de surveillance du bon niveau de satisfaction client dont la prise en compte méthodique des réclamations éventuelles. Dans une entreprise certifiée, toute non-conformité, dont une réclamation client, est prise en compte, ses causes sont analysées. Un plan d actions correctives et préventives est mené à terme de façon à éradiquer les causes du mécontentement ; Du personnel compétent. Chacun a un poste bien décrit et sait «qui fait quoi» dans l entreprise. Une gestion prévisionnelle des emplois et des compétences est mise en œuvre. Le personnel est formé régulièrement pour maintenir ses compétences et les faire évoluer en fonction des besoins. Plan de formation, bilan de formation, catalogue de formation sont des outils ordinaires de la gestion des compétences; Des environnements de travail qui respectent les dispositions légales et un document unique de prise en compte des risques du travail qui est maintenu à jour ; Une production de la qualité qui fait l objet d une gestion établie connue de chaque membre du personnel ; Des activités professionnelles bien décrites et maitrisées sur la base desquelles des décisions factuelles sont prises et des améliorations permanentes sont réalisées ; Une Direction Générale qui s implique dans une progression constante de l efficacité de la gestion de la qualité en suivant l atteinte des objectifs qualité considérés comme des éléments clés de la performance régulière de l entreprise ; Des règles de gestion transparentes de la qualité : - Une documentation professionnelle maitrisée et tenue «state of the art». Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 24

- Des activités clés dont les traces sont archivées, sécurisées et analysées pour s améliorer sur une base pragmatique et apporter des preuves de leur réalisation. - S il en existe des non-conformités dans les activités et leurs résultats, celles-ci sont méthodiquement traitées pour empêcher leur utilisation. Ceci est systématique qu il y ait des engagements contractuels ou pas. - Les non-conformités existantes sont traitées de façon à éradiquer toutes celles qui sont analogues même si elles ne sont pas encore signalées, puis à traiter les causes de celles qui pourraient potentiellement survenir. - La gestion de la qualité est régulièrement et formellement auditée en interne en sus des audits de suivi des auditeurs Veritas. 3.1.4 Sur quels principes repose la gestion de la qualité ISO 9001? Huit principes président à une gestion de la qualité conforme à la norme internationale de gestion de la qualité ISO 9001. Chaque entreprise certifiée met en œuvre chacun de ces principes. L orientation client : les objectifs non-financiers sont priorisés afin d améliorer le fonctionnement des activités dans le but de contribuer significativement aux objectifs d affaire définis par la Direction Générale. Le leadership : la Direction Générale établit les objectifs et les orientations d affaire qui sont communiqués aux régisseurs des activités métiers. Ces derniers s impliquent en déterminant les objectifs non-financiers et leur dispositif de suivi. L implication du personnel : la Direction de la Qualité, avec le relais des régisseurs des activités métier, assure la promotion de la politique de gestion de la qualité auprès du personnel. L approche processus : chaque régisseur métier assure la bonne tenue de l inventaire de ses activités qui sont classées par finalité et pour lesquelles les ressources et les parties prenantes sont décrites. Management par l approche système : les offres de service de valeur sont le plus souvent le fruit de la contribution constructive de plusieurs patrimoines métiers. Identifier, comprendre et gérer ses contributions participent à la performance. Une matrice d interaction entre patrimoines identifie les échanges prévus pour des interactions constructives. L amélioration continue : chaque régisseur métier contribue de façon autonome ou concertée à l amélioration de la valeur, de la notoriété et à la performance. L aspect continu consiste en l aptitude à proposer des objectifs intermédiaires raisonnables et étalés dans le temps pour atteindre un objectif complet de façon fiable et progressive. L approche factuelle pour la prise de décision : les décisions efficaces se fondent sur l analyse des données et d informations issues, par exemple, de tableaux de bord de suivi d activité. Relations mutuellement bénéfiques : l entreprise favorise la construction de relations durables de partenariats avec ses clients et avec ses fournisseurs. En interne, les patrimoines métiers sont interdépendant et sont encouragés à partager des ressources, à établir des activités communes d amélioration, bref, à travailler ensemble. Enfin, l attractivité de l entreprise, vis-à-vis des investisseurs et des écoles, est pilotée afin d entretenir des relations mutuellement bénéfiques. Figure 12 : Schéma illustratif de ISO Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 25

3.1.5 Comment s effectuent les contrôles? Les contrôles s effectuent plusieurs fois par an par des revues et des audits : Une revue de direction annuelle est obligatoire selon un ordre du jour établi par la norme internationale ISO 9001. Elle prouve que la D. Générale et le personnel régisseur de la qualité s impliquent et réfléchissent à la surveillance de la satisfaction client, à la gestion des compétences, à la maitrise des risques, au fonctionnement des activités, à leur progrès permanent et au traitement systématique et durable des écarts Un audit interne annuel méthodique qui examine le respect du cahier des charges de la norme internationale ISO 9001 Un audit de suivi annuel par un bureau de certification accrédité, les commissaires aux comptes de la qualité. Au final sur la durée d un certificat, le respect des exigences de la norme internationale est vérifié 9 fois dont 3 fois par un bureau accrédité qui peut, chaque année, suspendre le certificat ou le renouveler. 3.2 CMMI (Capability Maturity Model Integration) Créé aux Etats Unis dans les années 80, sous le signe CMM par les SEI (Software Engineering Institute), il a depuis évolué pour arriver aujourd hui à être décliné en différents secteurs : développement, service, 3.2.1 Qu est-ce que CMMI exactement? Ce modèle permet d évaluer des pratiques mises en place en fonction de critères très précis et très pragmatiques. Une entreprise qui souhaiterait fonder son système de gestion de projet sur l unique base du guide CMMI, irait à l échec. On ne fabrique pas un bateau à partir de tests de flottabilité. Cette compréhension de ce qu est CMMI et de ce que n est pas CMMI est fondamentale pour une société qui entreprend une telle démarche de certification. L expérience d Aubay dans ce domaine, en est une illustration. CMMI analyse l ensemble de l activité d un projet par zones de fonctions. Ces zones s appellent Process Area (PA). Ces zones sont au nombre de 22. Pour chacune de ces PA, CMMI détermine des pratiques spécifiques, regroupées par Specific Goals (SG), et 15 pratiques génériques communes à toutes les PA (GP), regroupées par Generic Goals (GG) Quelques exemples de PA/SG/SP : Project Planning Project Monitoring and Control Risk Management Process and Product Quality Assurance Ces PA sont affectés à des niveaux, de 2 à 5, par ordre croissant de conformité au modèle complet (Le niveau 1 correspond à un niveau reposant uniquement sur les connaissances des personnes, sans surveillance, sans documentations, sans stratégie. Il n est pas sujet à certification). Ainsi, pour obtenir une certification de niveau 2 (managed), seuls 7 PA sont analysées. Il y en a 11 de plus pour le niveau 3 (defined), encore 2 de plus pour le niveau 4 (quantitatively managed) et enfin 2 de plus pour le niveau 5 (optimizing). Figure 13 : Schéma illustratif de CMMI Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 26

CMMI est donc : Un «thermomètre» de la maturité, gradué et étalonné, pour évaluer officiellement la maturité d un département de développement logiciel d une entreprise ; Un moyen de comparaison objectif de la maturité des départements de développement logiciel de différentes entreprises ; Un outil pour piloter des améliorations de la maturité des activités de développement logiciel et réaliser des mesures intermédiaires ; Un référentiel sectoriel de qualité analytique pour les pratiques des projets de développement logiciel et de maintenance applicative. 3.2.2 Qu est-ce que n est pas CMMI? CMMI n est pas un référentiel dans lequel piocher des bonnes pratiques à déployer. Les bonnes pratiques sont à inventer et à déployer par chaque entreprise. Ensuite, c est la compatibilité de ces pratiques avec CMMI qui sera mesurée. Autrement dit, il ne s agit pas de déployer les pratiques du modèle de maturité CMMI pour obtenir le niveau de maturité escompté. Ainsi, chaque département certifié doit définir et ancrer très solidement ses propres pratiques de développement logiciel afin d établir la maturité visée. Il en découle, dans cette optique, une certaine rigidité qui, pour une société de service, doit s accompagner d un cadre d intégration méthodique et efficient des pratiques de développement logiciel de ses clients. En effet, l une des exigences fréquentes des clients, à l égard de la société de service, se formulerait paradoxalement ainsi : «savoir mettre en œuvre les pratiques de développement logiciel de chaque client avec la maturité requise». CMMI n est pas un modèle unique. Il y a en fait trois constellations CMMI : CMMI-DEV, le modèle historique d estimation de la maturité des activités de développement logiciel d un département, CMMI-ACQ, le modèle pour l estimation des activités d acquisition (un service achat ou une direction métier pourrait, chez un grand compte, décider d atteindre un niveau de maturité 2 ou 3), CMMI-SVC, le modèle pour l estimation de la maturité des activités de service delivery (un département d exploitation informatique pourrait décider d atteindre un niveau de maturité 2 ou 3 ; nous avons compris que cette constellation entrait en concurrence avec ITL/ISO 20000). CMMI fournit la cible à atteindre et une façon de mesurer objectivement une collection de processus, mais il ne dit pas comment définir une solution pour atteindre la cible le plus efficacement possible. En conséquence, le conseil d experts accompagnateurs et évaluateurs est quasiment obligatoire afin de garantir en permanence la compatibilité de la solution en construction avec la cible CMMI visée. CMMI est donc un modèle d évaluation des pratiques de gestion de projet. Il est important de bien intégrer que ce n est pas un guide, ni un mode d emploi, ni une proposition de fonctionnement. 3.2.3 Comment maintenir son niveau de maturité? Une évaluation CMMI, dîtes scampi A, est acquise pour une durée de 3 ans et publiable sur le site de l institution CMMI, le Software Engineering Institute 1. Le plus souvent, un gros effort initial est fait pour obtenir une évaluation conforme au niveau de maturité escompté. Trois ans plus tard, qu en est-il de l effort à faire pour renouveler l évaluation pour un niveau de maturité au moins équivalent? Qu en est-il de l intérêt du management pendant ces 3 ans? Une des solutions les plus fréquemment rencontrées est d allier la qualité générale ISO 9001 à la qualité analytique sectorielle CMMI La qualité générale ISO 9001 avec son audit annuel amène, à porter régulièrement et méthodiquement l attention, chaque année, au moment de la revue de direction annuelle, sur les pratiques de gestion maitrisée de la qualité ; Au niveau 2 de maturité, la gestion des activités est portée par chaque projet. Chaque projet est obligé de mettre en œuvre son propre dispositif de gestion à chaque fois. La capitalisation entre les projets est faible. Autrement dit, le coût de maintenance de ce niveau est assez élevé. A ce niveau, il y a une multitude de projets, tous biens gérés et administrés par le département de développement logiciel évalué. Or ISO 9001 amène à porter le regard sur l efficacité de la gestion. En conséquence, ISO 9001 encourage à la gestion efficace des processus dont ceux de développement logiciel inclus dans le modèle CMMI-DEV. Au niveau 3 de maturité, une infrastructure d amélioration est établie au niveau du département de développement logiciel. La capitalisation inter projet est réelle et les coûts sont répartis. A ce niveau, les activités d ingénieries, de gestion des processus de développement font l objet d une estimation au même titre que celles de gestion et de support d un projet. Ici le département logiciel évalué possède un véritable savoir-faire collectif qu il redistribue, de façon adaptée à leur contexte, 1 voir http://sas.sei.cmu.edu/pars/pars.aspx Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 27

auprès de chaque projet mis en œuvre. Chaque projet, à son tour, enrichit le savoir-faire collectif du département. Lorsque le niveau 3 est bien établi, son coût de maintenance est beaucoup plus faible que celui du niveau 2 à la condition que le management continue à s impliquer régulièrement. Dans ce cas, ISO 9001 permet de maintenir continument l intérêt du management pour la gestion efficace des processus. 3.2.4 Que s attend-t-on à trouver dans une entreprise dont un service est évalué selon CMMI? Une entreprise qui justifie d un département de maturité CMMI d au moins 2 fournit : La garantie d avoir en permanence du personnel compétent sur les activités de développement logiciel. Par conséquent, l entreprise peut fournir les ressources compétentes escomptées lorsqu elle réalise un projet ; Un savoir-faire pour la gestion maitrisée du déroulement régulier de chaque projet conduit par le département évalué ; La preuve que les activités de développement logiciel constituent une activité régulière, bien établie et bien gérée dans le service évalué de l entreprise ; Un essaimage des bonnes pratiques de développement du département à travers l entreprise, dans la mesure où la rotation du personnel, dans le département certifié, est bien organisée. 3.2.5 Quelles compétences pour mettre en œuvre des activités? La maturité d un département est liée aux pratiques qu il met en œuvre donc aux compétences du personnel du département. Sans compétences disponibles et pertinentes, pas de pratiques donc pas de maintien de la maturité. Ainsi, le personnel doit être en permanence formé, impliqué, informé. Ceci surtout lorsque le turnover est important ou en cas de recours à la sous-traitance. A quelles pratiques former le personnel? Aux pratiques de développement logiciel du département et non pas aux pratiques CMMI. Quel est l intérêt de connaître le modèle CMMI? Suivre le cours d introduction officiel à CMMI garantira que le personnel a compris l importance d apprendre et de mettre en œuvre les pratiques de développement logiciel du département. Donner confiance à un client sur le sérieux du prestataire. Cependant, en aucun cas, cela ne remplacera l apprentissage des pratiques de développement locales du département dans lequel le prestataire réalise sa mission. 3.2.6 Comment s effectuent les contrôles? Les contrôles CMMI sont : Une évaluation approfondie qui a lieu tous les trois ans ; Aucun contrôle formel n est exigé durant la période de validité de 3 ans de l évaluation. Bien évidemment, le bon sens et les coûts de maintenance veulent qu un contrôle informel régulier soit effectué et que les écarts soient traités. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 28

3.3 ITIL (Information Technology Infrastructure Library) 3.3.1 Qu'est ce qu'itil? ITIL est l'acronyme de "Information Technology Infrastructure Library", ce qui peut se traduire en français par "Bibliothèque de l'infrastructure des Technologies de l'information". En réalité, ITIL n'est pas une méthode mais un ensemble de bonnes pratiques. Il s'agit d'une collection de livres qui recense, synthétise et détaille les meilleures pratiques du monde entier dans la fourniture de services informatiques. Figure 14 : Schéma illustratif de ITIL 3.3.2 À quoi sert-il? L'adoption des bonnes pratiques d'itil par une entreprise permet d'assurer à ses clients, internes comme externes, un service répondant à des normes de qualité préétablies au niveau international. ITIL permet, grâce à une approche par processus clairement définie et contrôlée, d'améliorer la qualité des systèmes d'information et de l'assistance aux utilisateurs en créant notamment la fonction, au sens département de l'entreprise, de Centre de Services (ou Service Desk). ITIL a pour cible privilégiée le fait que les services délivrés par les technologies de l'information soutiennent le métier de l'entreprise et les activités associées, de manière efficace et rentable. Les directions informatiques trouveront avec ITIL une mise en œuvre qui leur permettra d'atteindre leurs objectifs de qualité et de maîtrise des coûts. Sur ce périmètre, ITIL représente l'approche la plus complète et la plus structurée du marché. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 29

3.3.3 D'où vient ITIL? ITIL est née en Angleterre à la fin des années 80, à la suite de la politique de "Market Testing" (mise en concurrence systématique des prestations internes, notamment informatiques, avec l'offre du marché) imposée par le gouvernement Thatcher aux administrations et entreprises publiques britanniques. Ce référentiel de meilleures pratiques a été élaboré par des groupes de travail réunissant des responsables opérationnels, des experts indépendants, des consultants spécialisés et des formateurs, sous l'égide de la CCTA (Central Computer & Telecommunications Agency). La CCTA est une agence gouvernementale anglaise chargée d'améliorer l'efficacité et la qualité des services informatiques centraux des ministères. Depuis, elle est devenue l'ogc (Office Government of Commerce). ITIL a connu un essor rapide en Angleterre. Puis elle a été adoptée par plusieurs départements ministériels et par de grandes entreprises publiques et privées aux Pays-Bas. Elle a poursuivi son développement dans de nombreux pays à travers le monde, devenant ainsi un standard de facto, sous l'impulsion de l'itsmf (IT Service Management Forum une association des utilisateurs d'itil). Le développement d'itil est assuré aujourd'hui conjointement par l'ogc, l'itsmf, l'iseb et l'exin. L'ISEB (Information Systems Examination Board) et l 'EXIN (EXamination INstitute) sont deux organismes publics, respectivement anglais et hollandais ayant pour principales responsabilités la définition des programmes de certification pour les individus (professionnels intéressés par l'itil) ainsi que l'accréditation des organismes de formation habilités à délivrer des certifications ITIL. 3.3.4 Utilisation d'itil La philosophie d'itil est d'adopter une démarche suffisamment souple pour s'adapter à toutes les organisations, petites ou grandes. Elle part du principe que la gestion des services est constituée d'un certain nombre de processus étroitement liés entre eux et fortement intégrés. Pour que les principaux objectifs en matière de gestion des services puissent être atteints, ces processus doivent utiliser les ressources humaines et les produits de manière efficace, rentable et économique de sorte que les services liés aux technologies de l'information soient innovants, de haute qualité et adaptés aux processus de l'entreprise. Les organisations ne doivent pas être trop ambitieuses lors de la mise en œuvre de la gestion des services. La plupart d'entre elles possèdent déjà des éléments d'organisation déployés et opérationnels. L'activité de mise en œuvre de la gestion des services concerne donc plutôt l'amélioration des processus existants. Pour ce faire, il est nécessaire de bien connaître son point de départ en évaluant la maturité de ces processus. De plus, pour engager une telle démarche, il est nécessaire de s'assurer à la fois de l'implication du management et que les conditions d'un changement culturel soient satisfaites. Les processus de gestion des services peuvent être mis en œuvre les uns à la suite des autres ou simultanément et chaque processus peut être décomposé en une série d'activités. L'utilisation de ces meilleures pratiques est soutenue par un ensemble de formations et de certifications utilisées dans le monde pour reconnaître les compétences professionnelles des individus. 3.3.5 Quels sont les bénéfices de la démarche ITIL? Les bénéfices de l'adoption de la démarche ITIL pour une entreprise constituent une meilleure traçabilité de l'ensemble des actions du département informatique. Ce suivi amélioré permet d'optimiser en permanence les processus des services pour atteindre un niveau de qualité maximum de satisfaction des clients. Les plus values constatées, lors de sa mise en œuvre, sont généralement les suivantes : la satisfaction des utilisateurs (personnel de l'entreprise ou clients), la clarification des rôles, l'amélioration de la communication entre les différents services de l'entreprise, la mise sous contrôle des processus à l'aide d'indicateurs pertinents et mesurables permettant d'identifier des leviers d'économies, une meilleure compétitivité, une sécurité accrue (disponibilité, fiabilité, intégrité), la capitalisation des données de l'entreprise, l'optimisation de l'utilisation des ressources. ITIL permet aux entreprises de capitaliser sur une expérience pratique de bientôt 20 ans sur la gestion des services informatiques et de gagner du temps en évitant de réinventer des éléments (processus, règles de gestion, descriptions de postes, etc.) déjà testés et éprouvés par de nombreuses autres entreprises dans le monde. ITIL apporte donc un cadre de référence commun avec l'apport d'un vocabulaire ciblé et d'une structuration des activités pour l'optimisation des services informatiques. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 30

ITIL permet de faciliter le dialogue entre les différents acteurs : entre DSI et DG, entre DSI et utilisateurs ou clients, entre DSI et équipes informatiques, entre DSI et prestataires externes. 3.3.6 Les processus ITIL V2 Deux grandes catégories de processus forment la base de ITIL V2. Processus de type «Soutien des services» (Service Support) Processus de type «Fourniture des Services» (Service Delivery) Ces processus sont abondamment détaillés en annexe. 3.3.7 ITIL en 3 points Pour répondre à l'adéquation entre le métier de l'entreprise et les services fournis par les technologies de l'information, on peut retenir trois idées importantes qui sous-tendent la philosophie ITIL : L'orientation client L'utilisateur ou le client est positionné au centre des préoccupations de la direction informatique et toutes les activités de l'informatique doivent s'inscrire dans une relation client-fournisseur. 2 Les services s'appréhendent à travers un cycle de vie La gestion des services, pour être efficace, doit être prise en considération en amont des projets informatiques, dès les phases d'étude et de conception. L'approche par les processus La qualité de service repose sur un modèle d'activités se déclinant dans la mise en place de processus informatiques appropriés en étroite corrélation avec les processus métiers. 3.4 Référentiels et certification Passer une certification sur un référentiel Qualité, c est se donner un temps, une respiration (parfois assez longue) pendant laquelle l entreprise s interroge sur ses pratiques internes et annonce au monde 3 vérités : 1- «Oui je sais ce que je dois faire!» : ses processus métiers sont identifiés 2- «Oui je sais comment le faire!» : ses processus sont définis en termes d étapes et d acteurs 3- «Et oui je peux le refaire!» : ses processus sont tracés et reproductibles L entreprise s est évaluée, elle se connaît parfaitement (ses processus) et le fait savoir. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 31

Mais si le chemin vers la connaissance est parfois semé d embûche et la démarche de certification lourde, elle assoie la légitimité de l entreprise dans son secteur d activité. Dans le domaine de l informatique, c est devenu de plus en plus un pré-requis pour les SSII qui ambitionnent de gérer des forfaits de plus en plus importants. Une certification officielle sur au moins un de ces référentiels est une nécessité mais hélas, elle n est pas suffisante. Les SSII et DSI peuvent aussi avoir besoin d optimiser leurs processus. Le chapitre suivant décrira donc de manière large quelques unes des méthodologies d optimisation des processus. 3.5 Conclusion Deux phénomènes parallèles expliquent le besoin de mettre en œuvre un référentiel de gestion des projets liés au SI. L alignement stratégique, d une part, est un besoin fondamental à prendre en compte pour la gestion des SI. Il s agit tout simplement de reconnaitre que pour la plupart des organisations, les SI ne font pas partie du «cœur de métier». Ils ont donc une fonction support. Ainsi, la Direction des SI participe à la réalisation et au succès des objectifs métiers. L alignement stratégique n est autre que l assurance que la stratégie et la gestion des SI est en conformité étroite avec les objectifs métiers. Cette assurance ne peut être obtenue que par l établissement de processus de communication, de contrôles et de décisions conjointes systématiques entre le métier et les équipes des SI. Les référentiels de méthode et de bonnes pratiques peuvent aider et guider dans la mise en place de ces processus et principes de gouvernance. Ils permettent de systématiser les processus de décision et standardiser les contrôles afin de maîtriser la gouvernance et contrôler la qualité des applicatifs livrés. Les référentiels répondent aussi à un autre besoin qui découle d une réalité simple : La gestion des SI est régie par une obligation de moyens et non pas de résultat. Ce constat est le corollaire logique du fait que les SI sont une fonction support. Au contraire du produit final, les applicatifs supports ne sont pas directement sanctionnés par le marché, sauf lorsqu ils sont entièrement externalisés. Les résultats doivent être jugés selon un critère de qualité. Or la qualité perçue des SI dépend en grande partie de la satisfaction des utilisateurs, c est une donnée essentiellement subjective et mesurée à posteriori, ce qui constitue deux inconvénients majeurs. La solution qui consiste à passer d une obligation de résultat vers une obligation de moyens permet à la fois d établir des critères objectifs (respect des normes, bonnes pratiques établies) et d utiliser les mesures afin d évaluer la qualité des résultats futurs. Les référentiels méthodologiques répondent à ce problème et permettent de mettre en place des mesures objectives de respect des obligations de moyens. Ces mesures ont l avantage d être plus facilement mesurables, et de donner une assurance de qualité des services futurs, puisque ce n est pas la qualité du projet livré qui est jugée, mais la maturité de l organisation à travers l implémentation de processus standards de contrôle et de mesure. Les référentiels méthodologiques impliquent un glissement de la nature de l obligation. On demandera aux responsables de projet de prouver que les processus ont été respectés, au lieu de leur demander que leurs projets aboutissent sans incidents. Nous avons donc voulu poser le problème du point de vue de l organisation, de la DSI qui souhaite tirer avantage de l implémentation de ces standards. Il ressort de notre expérience que ce n est pas tant le choix d une méthodologie particulière qui pose problème, mais surtout la manière dont ces normes et standards sont appliqués et mis en place concrètement pour chaque activité. Le choix des normes et standards méthodologiques doit être fait selon une analyse stratégique de l existant et des objectifs à long terme. Les objectifs de la DSI sont déterminés en amont sur la base du principe d alignement des Systèmes d Information aux objectifs «métiers» de l organisation. Mais s ils sont décidés en amont, c est lors de la mise en œuvre de la stratégie qu ils sont réalisés. Ces objectifs doivent donc être poursuivis constamment lors du choix d un référentiel pour la DSI et tout autant au niveau de l application de ce référentiel dans la gestion des projets au quotidien. Depuis les choix les plus «stratégiques» jusqu aux recommandations de mise en œuvre des méthodes de projet, les bénéfices attendus doivent être clairement retranscrits et rester le souci permanent de tous les acteurs du changement. Le principal problème est organisationnel et non technique. Il s agit de transformer les pratiques, les processus et les rôles afin de modeler une organisation ayant une même logique d un bout à l autre de la chaîne de valeur. Par exemple, une fois une méthode choisie comme standard, la mise en œuvre peut être différée dans le temps et sur un périmètre plus ou moins étendu, et poussée à des degrés divers de perfectionnement. Ces phases de mise en œuvre dépendent tout particulièrement des efforts fournis en conduite du changement. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 32

4 METHODOLOGIES D OPTIMISATION DES PROCESSUS Après le précédent rapide parcours des principaux référentiels qualités, le chapitre suivant a pour ambition de présenter quelques méthodologies d optimisation des processus que l on trouve au sein d une DSI. Ces méthodologies peuvent se répartir selon différents niveaux : Les méthodologies de niveau Stratégique traitent des axes budgétaires, de la satisfaction des clients (utilisateurs), des processus et du capital humain. Exemple de méthodologie de ce niveau : Balanced Scorecard, benchmark, Lean Management, etc. Les outils de ce type de méthodologies sont proches des analyse SWOT, forces de Porter, chaîne de valeurs, matrice du BCG, Les méthodologies de niveau Tactiques ont plus orientées vers l optimisation des processus opérationnels. L ouvrage comportera un chapitre spécifiquement dédié aux méthodes de gestion de projet de développement. A ce niveau, il existe pléthore de méthodes comme RUP, Scrum, XP Dans cette catégorie, on note la tentative de normalisation de la gestion de projet par l organisation PMI (Project Management Institute). 4.1 Méthodologies de niveau «stratégique» Les méthodologies de niveau Stratégique sont importantes à connaitre car, en plus d être applicable directement par la DSI pour ses propres besoins d amélioration de ses processus internes, elles peuvent aussi provenir de la Direction Générale qui demande à la DSI d appliquer ses recommandations. Figure 15 : Du rêve à la mise en œuvre avec les méthodologies au service de la DSI Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 33

4.1.1 Balanced Score Card Le Balanced Scorecard (BSC) propose un nouveau mode de management et de pilotage de l'entreprise en s'appuyant sur la mise en place d'un cadre rigoureux d'élaboration et de déploiement de la stratégie garanti par l'équilibre permanent de 4 perspectives. Perspective financière : que faut-il apporter aux actionnaires? Quelle est notre performance au sens des actionnaires? Perspective client : que faut-il apporter aux clients? Quelle est notre performance au sens des clients? Processus interne : quels sont les processus essentiels à la satisfaction des actionnaires et des clients? Quels sont nos avantages internes? Apprentissage organisationnel : comment piloter le changement et l'organisation? Allons-nous progresser et comment? Le résultat visé est de niveau «stratégique». Par exemple : Satisfaction des actionnaires Clients enchantés Processus efficaces et efficients Motivation des ressources humaines Figure 16 : Exemples d axes d optimisation selon les 4 perspectives stratégiques Le dispositif BSC permet donc de définir une stratégie ou une vision en phase avec des objectifs terrains réalistes. Il s appuie sur une analyse terrain, autour des processus, des hommes et de l organisation qui confirme que la stratégie est «faisable» et qui met en évidence d un côté les risques, de l autre les conditions de succès. L'évaluation de la performance est effectuée à l'aide de cartes de scores (scorecard) et la rémunération des managers est directement liée à la performance ainsi exprimée. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 34

Figure 17 : Exemple illustré d une balanced scorecard Quelques précautions à prendre dans l application de la méthode : 1) raisonner par métiers et activités homogènes : trouver les indicateurs judicieux de mesure de la création de valeur par branche et ses spécificités (pas de démarche qui part de la direction générale d un groupe à plusieurs activités) 2) boucler avec la stratégie en fin de parcours. Si l on démarre par ce volet, on prend trois risques : philosopher, attendre que la stratégie soit définie et se couper du terrain. 3) s appuyer sur une analyse correcte et dimensionnée des Processus et de leurs conditions de réussite. En effet, la naissance de la performance est issue : d une organisation efficace des processus ; d hommes formés, motivés, compétents ; de l innovation, de la veille, de la recherche ; d outils informatiques managés et maîtrisés ; d une maîtrise de la technologie du métier, etc. Le mot important dans balanced scorecard est "balanced". La traduction française "tableau de bord équilibré" est préférable à "tableau de bord prospectif". Elle convient mieux à l'idée des auteurs. Robert Kaplan et David Norton ont opté pour le terme de "balanced" scorecard afin de mettre l'accent sur la notion d'équilibre. Equilibre entre les objectifs à court et à moyen/long terme Equilibre entre les indicateurs financiers et non-financiers Equilibre entre les indicateurs mesure de la performance passée et les indicateurs "prospectifs" Equilibre entre la perception externe et la performance réalisée interne L objectif n étant pas ici de détailler la méthode pour laquelle il existe de nombreux ouvrages de référence, le balanced scorecard est, en résumé, un outil ayant pour objectif de traduire la mission et la stratégie d une organisation en indicateurs et initiatives concrets, mesurables qui se déclinent ensuite en autant d actions et d initiatives à entreprendre pour réaliser la stratégie. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 35

Figure 18 : Le cheminement de la réflexion aboutissant à l action Selon cette introduction, son application doit donc permettre de mesurer la performance d une DSI en tant qu organisation. Tentons l exercice. Voici ce que pourraient être les objectifs et mesures associés à une DSI : Perspectives Objectifs Mesures ou indicateurs Finances Contrôle des coûts Budget global de la DSI, ROI des projets Répartition CAPEX / OPEX Coût de maintenance du parc applicatif TJM par profil type Clients (directions opérationnelles) Satisfaction du service reçu Adéquation des applications aux processus métiers Satisfaction utilisateurs Nombre de dysfonctionnements remontés Respect des délais de livraison des applications Ergonomie conviviale Taux d utilisation du support papier Processus Activité d achat Gestion d équipement Rapidité des développements Performance des recettes Nombre réduit de fournisseurs Délais (court) de livraison des développements Taux d indisponibilité des applications Capital humain Implication du personnel (motivation) Capacité d évolution (adaptation aux nouvelles technologies) Capacité d initiative et d autonomie Taux de rotation Taux d absentéisme Taux de formation Dépense en recherche et développement La méthode ne se termine jamais, en effet, elle boucle sur un processus d amélioration continue comme illustrée ci-après. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 36

Figure 19 : Processus d amélioration continue 4.1.2 Six Sigma Méthode structurée de management visant à une amélioration de la qualité et de l'efficacité des processus. La méthode Six Sigma a d abord été appliquée à des procédés industriels avant d être élargie à tous types de processus, notamment administratifs, logistiques, commerciaux et d'économie d'énergie. La méthode Six Sigma se base sur une démarche fondée à la fois sur la voix du client (enquêtes, etc.) et sur des données mesurables (par indicateurs) et fiables. Cette méthode est utilisée dans des démarches de réduction de la variabilité dans les processus de production (ou autre) et au niveau des produits et vise ainsi à améliorer la qualité globale du produit et des services. Six Sigma repose sur les notions de client, processus et mesure ; il s'appuie en particulier sur : les attentes mesurables du client ; des mesures fiables mesurant la performance du processus métier de l'entreprise par rapport à ces attentes ; des outils statistiques pour analyser les causes sources influant sur la performance ; des solutions attaquant ces causes sources ; des outils pour contrôler que les solutions ont bien l'impact escompté sur la performance. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 37

Chaque étape possède des outils différents qui sont regroupés dans une démarche cohérente. Typiquement, la gamme d'outils utilisés dans chacune des phases est (cette liste n'est pas exhaustive) : Définir : voix du client, cartographie des processus, Mesurer : analyse de systèmes de mesure, capacités, diagrammes d'ishikawa Analyser : cartographie détaillée des processus (par exemple, analyse de la valeur ajoutée), tests d'hypothèses (ANOVA, χ², tests de variances, ), plans d'expérience Améliorer : plans d'expériences, AMDEC, poka yoke Contrôler : plans d'expérience, MSP Bénéfices directs Contrôle des tailles d équipe Réduction des coûts directs Réduction des délais Bénéfices indirects, intangibles Gain de productivité Effet de conservation des clients Morale équipe en augmentation Augmentation des investissements Par contre, les barrières à l application de la méthode peuvent être nombreuses : Freins potentiels Objectifs peu clairs de l initiative Valeur de la méthode non reconnue Perception que la méthode est consommatrice de temps Confiance fiable durant les premières étapes Manque de sponsoring de la direction Attente de résultat immédiat Manque de coaching adéquate Conséquences possibles Incompréhension des acteurs impliqués Faible motivation des acteurs impliqués Faible motivation des acteurs impliqués Faible motivation des acteurs impliqués Déroulement chaotique du process Effet de déception sur le court terme Effet de déception sur le court terme Afin d éviter ces échecs dans le déroulement de la méthode, une certification des acteurs coachs est indispensables. Les différents niveaux de certification sont : Le Green Belt («ceinture verte»), dont on attend qu'il consacre partiellement son temps (souvent autour de 25%) à la conduite de projets d'amélioration. Le Black Belt («ceinture noire»), chef d'équipe qui se consacre à plein temps à l'amélioration (conduite de projets, formation des Green Belts voire d'autres Black Belts) et doit maîtriser la méthode dans son ensemble. Il est plus spécialisé soit en DMAIC, soit en DFSS. Le Master Black Belt, mentor et formateur de Blacks Belts, garant du respect de la démarche, encadre les Blacks Belts hiérarchiquement. Le Deployment Leader ou Champion (en France, «directeur du déploiement» ou plus souvent «directeur du système d'excellence»), chargé d'élaborer la stratégie, le contenu de la formation, les budgets, etc. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 38

Figure 20 : Organisation des certifications Six Sigma Notons que le lean-six-sigma associe les méthodes qualitatives du lean management et du six sigma pour améliorer de manière substantielle la performance logistique de l'entreprise. Les défauts du processus de production sont analysés et modifiés en conséquence. L'idée qui a donné son nom à la méthode est de répondre aux possibilités de non conformité de part et d'autres de la moyenne de 3 écarts-types (les fameux 6 sigma). Ces causes de non conformité doivent être maîtrisées grâce à l'utilisation de tableau de bord tel que les KPI logistiques. Elle nécessite un investissement de tous les acteurs de l'entreprise, de la direction aux utilisateurs. Certaines notions fondamentales de la gestion d'un projet sont naturellement requises (communication, formation, implication des utilisateurs, etc.). Les KPI logistiques sont des outils qui répondent au besoin d'analyser le fonctionnement, les flux et les processus d'une entreprise (performances de la supply chain). Le choix de ces indicateurs est primordial et dépend du secteur étudié ainsi que des objectifs principaux de l'entreprise (le respect des délais, la réduction des coûts logistiques, etc.). 4.1.3 Kaizen La méthode Kaizen d'améliorations incrémentales et continues est un concept de gestion initialement japonais pour un changement (amélioration) progressif et continu (incrémental). Kaizen est réellement une philosophie de mode de vie. Il suppose que chaque domaine de notre vie mérite à être constamment amélioré. La philosophie Kaizen est sous-jacente à beaucoup de concepts de gestion japonais comme : Contrôle Qualité Totale, Cercles de Contrôle Qualité, activités en petit groupe, relations de travail. Les éléments principaux de Kaizen sont : qualité, effort, participation de tous les employés, volonté de changer, et communication. Les entreprises japonaises distinguent entre : Innovation, une forme radicale de changement, et Kaizen, une forme progressive de changement. Kaizen signifie littéralement : changez (kai) pour devenir bon (zen). Les cinq éléments de base du Kaizen Travail d'équipe. Discipline personnelle. Moral amélioré. Cercles de qualité. Suggestions pour l'amélioration. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 39

Figure 21 : Le modèle Toyota Historique 4.1.4 Lean Management L école de gestion Lean («maigre») puise ses sources au Japon dans le Toyota Production System (TPS). Le Lean s est initialement développé dans l industrie, plus particulièrement autour des activités de gestion de production. Générique et adaptable à tous les secteurs économiques, ses préceptes se propagent désormais jusqu aux activités de services. Le Lean Management repose sur les pré-requis de la production Juste A Temps (JAT). Le JAT consiste à «fournir au client le nombre de produits qu il demande au moment où il le souhaite, à l endroit désiré et dans le standard de qualité et de coût fixé» (selon Techniques de l ingénieur, AG 5190). Le JAT peut aussi être défini comme «une philosophie basée sur l élimination de tous les gaspillages et sur la mise en œuvre d une stratégie de progrès permanent en terme de productivité» (selon l APICS). La mise en place d un système Lean repose sur trois fondements : une saine gestion des stocks, une bonne maîtrise des coûts, une politique de progrès permanent. Le TPS est né après la seconde guerre mondiale, qui fut particulièrement éprouvante pour le Japon. L industrie japonaise moribonde devait absolument réaliser des prouesses pour survivre, malgré la relative sécurité (fermeture) de son marché intérieur. Eiji Toyoda, alors directeur de l entreprise chargea Taiichi Ohno d égaler la productivité de Ford. Le système de Ford reposait sur une production de masse, un flux continu des lignes de production, et une conception scientifique du travail ouvrier (MTM, standardisation ). Or, le marché japonais se caractérise par des petits volumes et une demande fragmentée. Une simple transposition du modèle américain était vouée à l échec. Au cours des visites dans les usines américaines, Ohno se rendit compte de l imperfection du système américain (chaque ligne produit au maximum, sans coordination) qui entraînait surproduction, encours colossaux, défauts de qualité, flux chaotiques Pour Toyota, le système américain se caractérisait principalement par le gaspillage, et du fait de sa situation précaire, la chasse au gaspillage était une priorité absolue. Les fondements du TPS étaient posés : initier une chasse drastique au gaspillage, développer un flux continu, flexible et instaurer une politique d amélioration continue. Lean Management: version Toyota Production System TPS Les objectifs de la version TPS du Lean Management consistent à éliminer les gaspillages de temps et de ressources, d intégrer la qualité dans les systèmes, identifier des alternatives peu coûteuses mais fiables à des nouvelles technologies onéreuses, perfectionner les processus opérationnels et bâtir une culture d amélioration continue. Cette démarche de gestion consiste à privilégier des solutions Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 40

simples et économiques. La conception de l activité du point de vue client permet de définir la valeur du produit ou service, son flux, sa mise en œuvre, sa mise en place (Kanban) et sa recherche de l excellence. Ainsi, l activité se définit comme une succession de processus générateurs de valeur, sans interruption, à flux tirés, en réapprovisionnant au plus juste, à brefs intervalles. A l échelle macroscopique, l entreprise fait preuve d empathie en se plaçant systématiquement du point de vue client ; à l échelle microscopique, chaque processus est considéré par rapport à son processus client (le suivant). Le Lean Management, d après Jeffrey Liker, peut être développé suivant 14 axes de travail : Philosophie à long terme. 1 Fondez vos décisions sur une philosophie de long terme même au détriment des objectifs financiers à court terme. Le bon processus produira les bons résultats. 2 Organisez les processus en flux pièce à pièce pour mettre à jour les problèmes. 3 Utilisez des systèmes tirés pour éviter la surproduction. 4 Lissez la charge de travail. 5 Inculquez une culture de résolution immédiate des problèmes, d obtention de la qualité du premier coup. 6 La standardisation des tâches est la base de l amélioration continue et de la responsabilisation des employés. 7 Utilisez des contrôles visuels pour qu aucun problème ne reste caché. 8 Utilisez uniquement des technologies fiables, longuement éprouvées, qui servent vos collaborateurs et vos processus. Valorisez l entreprise en développant vos employés et vos partenaires. 9 Formez des responsables qui maîtrisent parfaitement le travail, sont imprégnés de la philosophie et l enseignent aux autres (+ promotion interne). 10 Formez des individus et des équipes exceptionnels, qui appliquent la philosophie de votre entreprise. 11 Respectez votre réseau de partenaires et de fournisseurs en les encourageant et en les aidant à progresser. La résolution continue des problèmes pilote l apprentissage de l entreprise. 12 Allez sur le terrain pour bien comprendre la situation (Genshi Genbutsu) 13 Décidez en prenant le temps nécessaire, par consensus, en examinant en détail toutes les options. Appliquez rapidement les décisions. 14 Devenez une entreprise apprenante grâce à la réflexion systématique (Hensaï) et à l amélioration continue. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 41

Figure 22 : Lean Management TPS Lean Management: version Excellence Opérationnelle OPEX L Excellence Opérationnelle OPEX, au delà d être un ensemble de méthodes, repose sur le facteur humain. Il suggère que le personnel travaille dans un état d esprit orienté vers la diminution du gaspillage et des pertes dans les processus et la réduction des étapes non génératrices de valeur. La motivation et les comportements des hommes sont nécessaires pour une application efficace. Le Lean Management s efforce d aboutir spécifiquement dans un cycle de vie de bout en bout dans chacun des processus pour parvenir à une totale satisfaction client. L élimination du coût des rebuts de qualité dès le premier coup est moyen et effort continu pour s évaluer et constamment se contrôler. Dans un processus d amélioration du service client par exemple, l expérience clients optimisée fidélise la clientèle. Il revient moins cher de conserver et d étoffer une clientèle rentable que d investir dans de nouvelles activités. Les clients fidélisés assurent eux-mêmes la promotion de la société dans leur entourage. Figure 23 : Illustration du processus d amélioration porté par OPEX Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 42

«Dans 85% des cas, la raison pour laquelle nous ne parvenons pas à répondre aux attentes du client, est que nos sytèmes et nos processus sont défectueux, et non que nos employés ne sont pas à la hauteur Le rôle de la Direction est de changer le processus plutôt que d insister sur une amélioration de l individu.» Le Lean en tant que philosophie, Edwards Derning L objectif dans l absolue étant de rechercher constamment des moyens d améliorer les opérations tout en satisfaisant la clientèle rentablement, l approche OPEX doit suivre les quatre phases essentielles à sa réussite. Durant la première étape, il s agit de comprendre les besoins clients et cadrer le projet. Ensuite, mesurer la situation actuelle par rapport aux besoins clients. Analyser les causes premières et générer des solutions permet d établir une relation entre les causes et effets de rebuts de qualité dans un processus donné. En dernière partie vient l élaboration d un plan d amélioration et mise sous contrôle des progrès. Figure 24 : Les 4 phases de OPEX Phase 1 : Définir le Projet L identification et définition des problèmes et des attendus des clients permet de mieux comprendre l enjeu durant la première phase de la méthodologie OPEX. Cette phase permet d identifier les besoins des clients et de fixer les objectifs, notamment par une cartographie de processus de haut niveau pointant le processus à améliorer. Une analyse coûts et bénéfices de haut niveau synthétise le périmètre du projet afin que le sponsor consente à la poursuite du projet ou non. Dans le cas où le projet est validé et promu, le sponsor constitue une équipe, définit les premiers jalons, met toutes les parties prenantes en adhésion pour fixer des objectifs spécifiques et mesurables. L objectif de la définition du projet et de s assurer que les ressources soient allouées aux projets prioritaires. Ensuite, identifier le problème et l objectif du projet en des termes mesurables pour mieux comprendre la complexité du projet, ses bénéfices et sa logistique. Par conséquent, les besoins clients seront bien définis, les équipes mieux préparées ainsi que le mandat du projet qui sera précis avec une définition claire de la problématique et des objectifs, des paramètres du projet, du planning par jalons et des bénéfices. Phase 2 : Mesurer la situation actuelle La mesure de la situation actuelle revient à cartographier le processus actuel et à en mesurer les défauts. Cette mesure porte sur la collecte de données concernant les problèmes identifiés durant la précédente phase. La cartographie du processus «As Is» permet à l équipe de mieux le comprendre en l état actuel et d aller au-delà de la perception initiale. Cette analyse de l existant permet aussi d identifier les Quick Wins. Le mandat de projet constitue un document d orientation pour l équipe projet et définit son cadre de travail. Le mandat clarifie ce que l on attend de l équipe et permet à l équipe de respecter les priorités de l organisation. Le document d orientation autorise le transfert du projet du Sponsor à l équipe d amélioration et identifie les problèmes, explique la complexité du projet et fixe des objectifs en des termes mesurables. Ainsi, la logistique de la constitution de l équipe de projet est identifiée et le mandat de projet devient un document vivant, qui évolue à mesure que le projet se précise. Les livrables du mandat de projet sont l harmonisation et équilibrage en présentant la valeur et de la nécessité du projet. L énoncé des bénéfices à tirer du projet et de son calendrier d exécution (pourquoi l entreprendre maintenant?), tout en fournissant l explication des raisons qui justifient le projet. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 43

Phase 3 : Analyser et générer des solutions La phase d analyse des données et découverte des causes des défauts consiste à examiner de plus près les données, afin de déterminer les causes profondes des problèmes avant de proposer des solutions de fond. La conception des solutions qui traitent des causes profondes induit l amélioration et la satisfaction des objectifs du projet. Apporter des solutions en élaborant une cartographie du processus cible, nommé «To Be» en anglais avec tous les outils de contrôle pour le suivi de la performance du nouveau processus. Une fois, le processus cible défini, il est crucial d inviter toutes les parties prenantes à procéder à une étude critique de la proposition et, si possible, à déployer un programme «pilote» à travers des ateliers de travail et de communication. La conception du modèle financier, comme input de l analyse coûts et bénéfices, démontre de manière plus détaillée les avantages financiers à la mise en œuvre de la solution proposée. Il est important d examiner les clients et de les segmenter en groupes logiques. L équipe est ainsi à même d axer les travaux sur les clients les plus importants pour le projet en définissant des segments logiques de clients (Lieu géographique, taille, valeur, type d activité, segment de marché, etc.). À partir des données collectées auprès des clients, il est possible de définir précisément ce que le client attend du produit ou du service. Les besoins des clients se traduisent en besoins critiques au niveau du processus, spécifiques et mesurables. Phase 4 : Améliorer et mettre sous contrôle Test de tout ou partie d une solution proposée, à petite échelle, en vue de mieux comprendre les effets de cette solution et de découvrir comment optimiser sa mise en œuvre à grande échelle et de maitriser sa pérennité des améliorations apportées durant la précédente phase. Un plan d actions correctives doit être dressé, expliquant comment réagir si les performances du processus changent ou s écartent des normes établies. Une fois le plan de contrôle identifié, le plan de mise en œuvre de la solution doit être finalisé. Le projet passe en mise en œuvre, les solutions sont testées et validées. Avant le transfert de responsabilité du nouveau processus au propriétaire, l équipe projet surveille attentivement la performance du processus et valide le modèle financier à travers l observation des gains. La cartographie de processus confère une structure simple et visible de raisonnement pour un processus complexe. Ses objectifs sont, entre autres, comprendre les interdépendances en cours du processus (passages de relais, goulots d étranglement et boucles de correction), instaurer une communication (propice au travail d équipe) entre les départements via une sensibilisation aux problèmes potentiels du processus cibles. La méthode OPEX est structurée en 4 phases de travail composées elles-mêmes de 12 étapes spécifiques supportées par 50 outils Blue et ~ 40 outils complémentaires Black. L application de cette méthode représente aussi un changement de culture par rapport à l approche classique comme illustré cidessous : Figure 25 : OPEX, un changement de culture Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 44

De nouvelles performances appellent évidemment à de nouvelles compétences! Un programme de formation et de certification OPEX permet de développer ses compétences en matière d amélioration des processus. Figure 26 : OPEX, une organisation impliquant à tous les niveaux hiérarchiques Des nouvelles performances appellent aussi à une gouvernance favorisant des prises de décisions équilibrées. Figure 27 : Gouvernance OPEX, une véritable dynamique d amélioration continue pérenne Rôle du Champion Central OPEX Le Champion Central OPEX met en place le programme OPEX et assure l animation globale d'opex au quotidien. Il conçoit l'infrastructure OPEX incluant les systèmes supports comme la formation, les approbations de projet, les ressources humaines, les systèmes de reporting, et s assure de la cohérence et de l évolution de la méthode. Au moins une fois par trimestre, le champion central rapporte à/informe le Comité Exécutif sur l'avancement du déploiement d'opex et apporte l appui des équipes centrales BB et MBB aux unités si besoin. La mise en œuvre d un plan de communication pour l entreprise se fait avec les champions locaux. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 45

Rôle du Champion local Le Champion local déploie la dynamique dans chaque Unité de l entreprise et il est responsable du déploiement d'opex dans son Unité. Le travail de coordination est établi avec le Champion Central pour mettre en œuvre l'infrastructure OPEX et le champion local définit avec les responsables de l'unité ses buts et ses objectifs, et s'assure qu'ils sont alignés sur la stratégie du COMEX. Celui-ci décline ces buts et ces objectifs par l'identification d'aires d'opportunités prioritaires et facilite l'identification, la définition de l'étendue et la priorisation des projets pour les sponsors. L'identification et le choix de candidats Blue Belt et Black Belt pour le comité de direction s exécutent avec les plans de formation avec le Champion Central. De ce fait, le Champion local développe un plan de communication pour l'unité et supprime les barrières rencontrées par les Black Belt et leurs équipes pendant leurs projets. En conclusion, il assure l'implication du bon niveau de ressources et suit et communique l'avancement des projets OPEX au champion central. Rôle du Sponsor Le sponsor en général assure l identification, le lancement et le suivi de ses projets OPEX prioritaires au moins N-2 d un membre du COMEX. Le sponsor prend en charge l identification et la validation des projets prioritaires à conduire dans son unité, en cohérence avec la stratégie de l entreprise et en coordination avec le champion local. Le sponsor communique au champion local et, si besoin au COMEX, l état d avancement de ses projets. En bref, il libère les ressources nécessaires (équipe, temps, budget) et prend charge du bon déroulement du projet et des points de décisions aux différentes étapes du projet. Rôle d un OPEX Master Black Belt Le Master Black Belt est un expert OPEX et un agent du changement encadrant et conseillant des Blue Belts et des Black Belts. Egalement, il assure le déploiement de la méthodologie et le coaching des Black Belt et possède de solides compétences statistiques et savoir utiliser tous les outils. Pour la validation des projets et clôture de projets, il assiste et supporte les champions et les responsables de processus dans le choix, le cadrage et la gestion des projets OPEX. Le Master Black Belt maintient et met à jour si nécessaire la méthodologie OPEX et assure le partage d expérience et la diffusion des meilleures pratiques. En conclusion, il mène des projets très complexes et/ou à très forts enjeux, pour la plupart multifonctionnels et/ou à travers plusieurs unités. Rôle d un OPEX Blue Belt L OPEX Blue Belt est un acteur du changement dans son environnement opérationnel et travaille sur des projets d'une plus petite étendue, et typiquement dans son domaine/secteur de travail. Le Blue Belt, communique l état du projet et livre les résultats du projet. Egalement, il contribue au maintien de la performance du processus après amélioration, tout en intégrant les outils et la méthodologie OPEX à ses fonctions actuelles. Le Blue Belt, insuffle au quotidien les principes OPEX dans ses équipes par son comportement. La réussite d un projet OPEX nécessite des «acteurs du changement» Les principales compétences d un Blue / Black Belt consistent à la mise en œuvre de la méthodologie OPEX adaptée au contexte, la diffusion des meilleures pratiques et la maitrise des projets très complexes à très fort enjeux. Figure 28 : Compétences Blue et Black Belt Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 46

En résumé sur l amélioration de processus utilisant OPEX Lean Management Les organisations sont régies par des processus, gérées par des personnes, payées par des clients et financées par des actionnaires. Il est primordial de comprendre les besoins de nos clients et de s assurer que nos processus satisfont ou outrepassent leurs besoins. Pour exceller dans leur secteur, les organisations doivent savoir comment mesurer, améliorer et contrôler l ensemble de leurs processus. Pour garantir une gestion efficace et efficiente des processus, il faut une force de travail suffisamment engagée et disciplinée pour améliorer l efficacité et l efficience des processus. 4.1.5 Comparaison rapide Six Sigma Lean Kaizen Théorie Réduire les variations Réduire le gaspillage Améliorer la qualité Démarche Définir Identifier ce qui crée la valeur Ordonner (i.e. commander) Mesurer Identifier la chaîne de valeurs Ordonné (i.e. trié) Analyser Améliorer le flux Propreté Améliorer Pull (JiT client) Nettoyage normalisé Maîtriser Viser la perfection Discipline Cible Problème Flux Cible simple et tactique Hypothèses Problème existe. Quantification. L output du système augmente si on réduit les variations dans tous les processus. Réduire le gaspillage améliore la performance de l entreprise. Plusieurs petites améliorations rapides sont préférables à l analyse du système. Emphase sur la vitesse et le volume. Utilise les systèmes en place. Processus interdépendants. Impact premier Output uniforme des processus Amélioration du débit Débit rapide Effets secondaires Moins de rebuts Débit amélioré Moins de variations Débit plus uniforme Moins de rebuts Moins de stocks Moins de stocks Moins de stocks Nouvelle comptabilité Les fluctuations comme mesure du rendement de la gestion. Qualité améliorée. Nouvelle comptabilité Le débit comme mesure de rendement de la gestion Débit comme mesure rendement de la gestion Qualité améliorée de Qualité améliorée Critiques Interactions non considérées. Processus améliorés de façon indépendante. Contrôle statistique et analyse de système non exploités Peu de participation de l employé Analyse des données peu exploitée Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 47

Conclusion Ainsi, le Lean Management est une vision globale de l entreprise, qui se caractérise par une philosophie à long terme et qui se vit avec tous les employés. C est aussi un travail permanent sur les processus, orienté vers l élimination systématique du gaspillage et plus largement des 3M : muda (gaspillage), mura (irrégularité), muri (surcharge), une gestion respectueuse des employés qui sont considérés comme la principale ressource de valeur de l entreprise, et enfin une culture de résolution continue des problèmes qui guide l apprentissage et développe les compétences de l entreprises. La pensée classique occidentale concevait jusqu alors le développement et l amélioration de la production par l unique biais de lourds investissements sur les processus générateurs de valeur. Le Lean Management exacerbe l effort continu sur la réduction drastique des processus non générateurs de valeur par le biais d actes simples et économiques (Lean). Enfin, au niveau de la gestion des flux, il insiste sur l importance d instaurer des flux tirés, avec pour ultime objectif d obtenir un flux pièce à pièce (ou livrable d entrée à livrable de sortie, dans le cadre de la gestion de projet), synonyme de réactivité, de rendement, et révélateur de problèmes (chasse au gaspillage). En effet, la diminution progressive et systématique du niveau des stocks et des encours conduit à faire affleurer les problèmes jusqu alors immergés sous la marge de sécurité des stocks. On peut et l on doit alors améliorer les points néfastes et donc la productivité. Initialement cantonné à l'organisation de la production, l'école lean se révèle être une méthode pertinente pour combattre tous les types d inefficacité, son utilisation s étend notamment aux processus documentaires et électroniques, aux services administratifs (lean office), au développement de produit (lean development). Par une analyse minutieuse de la chaîne des valeurs, il permet de déceler les activités non productives ou sans aucune valeur ajoutée réelle, et d optimiser par la suite le processus global de création de valeur. La résolution continue des problèmes rencontrés aboutit à un «système pensant», développant ses compétences. 4.2 Méthodologies de niveau Tactique Il s agit à ce niveau d optimiser les processus plus opérationnels d une DSI. Cela signifie pour l essentiel de mieux maitriser son processus de gestion de projet (par exemple, lors du développement d une nouvelle application ou du déploiement d un progiciel). La gestion de projet repose fondamentalement sur un découpage décrivant l enchaînement des phases, étapes et tâches à effectuer pour aboutir aux livrables finaux spécifiés. Ce découpage, exhaustif pour la prise en compte de toutes les composantes et contraintes, permet une prise en charge affinée du projet sur chacune de ses portions élémentaires. Un cycle de vie propose une modélisation du cycle de développement logiciel, focalisée sur certains facteurs particuliers. Il fournit un cadre théorique global à la gestion de projet, et induit un certain type d organisation et de méthodologie. 4.2.1 Introduction au cycle de vie du projet Le cycle de vie du logiciel définit l'enchaînement chronologique des différentes phases d élaboration et d utilisation d'un logiciel, depuis l émergence du besoin (l idée) jusqu au retrait de service du produit. Figure 29 : Illustration du cycle de vie d un projet informatique (source CNRS) Le projet est composé de 4 phases : réalisation, développement, exploitation /utilisation et maintenance / évolution. Les évolutions majeures sont traitées comme des projets indépendants (V1, V2, ). Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 48

Figure 30 : Détail du cycle de vie (source CNRS) Présentation des différentes phases du cycle de vie (Source : Génie logiciel, Anne-Marie Hugues 19/12/02 2-3) a. Définition des Objectifs Le management étudie la stratégie et décide de la nécessité de fabriquer ou acheter un nouveau produit. C'est pendant cette phase qu'est défini un schéma directeur dans le cas de la création ou de la rénovation d'un système d'information complet d'une entreprise prenant en compte la stratégie de l'entreprise (voir méthode Merise). b. Définition des Besoins Un cahier des charges est établi par le client après consultation des divers intervenants du projet (utilisateurs, encadrement...), un appel d'offres est éventuellement lancé. Le cahier des charges décrit, en langage naturel, les fonctionnalités attendues du produit ainsi que les contraintes non fonctionnelles (temps de réponse, contraintes mémoire...). Dans le cas de la refonte d'un système complet on peut avoir un cahier des charges par sous domaine. Le produit intermédiaire obtenu à l'issue de cette phase est le cahier des charges. On peut décrire le produit à partir de différents scénarii d'utilisation (Use Case). c. Définition du Produit Les spécifications précises du produit sont décrites ainsi que les contraintes de réalisation. A l'issue de cette phase, les fournitures intermédiaires sont le dossier de spécifications fonctionnelles et une première version du manuel utilisateur. On peut également désigner cette phase par le terme analyse des besoins. A l'issue de cette phase, le client et le fournisseur sont d'accord sur le produit à réaliser et les contraintes auxquelles il doit obéir ainsi que sur la façon de l'utiliser et en particulier sur l'interface utilisateur qu'il s'agisse d'une interface homme-machine ou d'une API. Les produits intermédiaires à l'issue de cette phase sont : le dossier d'analyse comprenant les spécifications fonctionnelles et non fonctionnelles du produit, une ébauche du manuel utilisateur, une première version du glossaire contenant les termes propres au projet. d. Planification et gestion de projet Il est évident que le client comme le développeur doivent être d'accord sur les coûts et la durée du projet. La phase de planification permet de découper le projet en tâches, de décrire leur enchaînement dans le temps, d'affecter à chacune une durée et un effort, calculé en homme*mois. Il est également important de définir les normes qualité qui seront appliquées comme la méthode de conception choisie ou les règles qui régiront les tests. On notera également les dépendances extérieures (comme par exemple l'arrivée d'une nouvelle machine ou d'un nouveau logiciel) afin de mesurer les risques encourus. Les produits intermédiaires à l'issue de cette phase sont : le plan qualité, le plan projet destiné aux développeurs, une estimation des coûts réels (utile pour le management), Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 49

un devis destiné au client précisant le prix à payer, les délais et les fournitures, une liste des dépendances extérieures. En cas de réalisation du produit par un sous-traitant le dossier de spécifications fonctionnelles ainsi que le plan projet et le plan qualité terminent cette phase et sont contractuels. e. Conception globale Pendant cette phase l'architecture du logiciel est définie ainsi que les interfaces entre les différents modules. On veillera tout particulièrement à rendre les différents constituants du produit aussi indépendants que possible de manière à faciliter à la fois le développement parallèle et la maintenance future. A l'issue de cette phase les produits intermédiaires sont : le dossier de conception, le plan d'intégration, les plans de tests, le planning mis à jour. f. Codage et tests unitaires Chaque module est ensuite codé et testé indépendamment des autres. A l'issue de cette phase les produits intermédiaires sont : les modules codés et testés, la documentation de chaque module, les résultats des tests unitaires, le planning mis à jour. g. Intégration Chaque module testé est intégré avec les autres suivant le plan d'intégration et l'ensemble est testé conformément au plan de tests. A l'issue de cette phase, les produits intermédiaires sont: le logiciel testé, les tests de régression, le manuel d'installation, la version finale du manuel utilisateur. h. Qualification Lorsque le logiciel est terminé et les phases d'intégration matériel/logiciel achevées, le produit est qualifié, c'est à dire testé en vraie grandeur dans des conditions normales d'utilisation. Cette phase termine le développement. A l'issue de cette phase le logiciel est prêt à la mise en exploitation. i. Maintenance Lorsque le produit a été accepté, il passe en phase de maintenance jusqu'à son retrait. C'est pendant cette phase que tous les efforts de documentation faits pendant le développement seront particulièrement appréciés de même que la transparence de l'architecture et du code. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 50

4.2.2 Modèles traditionnels de développement logiciel Le cycle de développement du logiciel (définition AFNOR Z61-102) représente l'ensemble des activités mises en œuvre dans un ordre donné pour effectuer le développement d'un logiciel. Il existe différents modèles de développement du logiciel, chacun mettant l accent sur différents enjeux projet, et bien sûr présentant un certains d avantages ou d inconvénients diverses. Modèle en cascade : modèle basé sur les livrables (fournitures de fin de phase livrées au client). Toutes les phases sont exécutées sans exception dans l'ordre indiqué. Chaque phase se termine par un jalon, tâche de vérification et validation des résultats (afin d'éliminer les anomalies et les incohérences). Le passage à la phase suivante est conditionné par la revue de jalon. Le retour est uniquement autorisé pour la phase précédente : on ne peut changer que les décisions prises à la phase précédente. Cette méthode permet de distinguer clairement les phases du projet et impose un certain rythme de développement, séquencé par les revues de jalons. Par contre, les inconvénients sont que le modèle est peu adaptatif aux évolutions des besoins et la vérification des fonctionnalités développées arrive tardivement (en fin de cycle). Le retour en arrière est complexe car demanderait des modifications des spécifications. Ce modèle est donc plus adapté aux petits et moyens développements, dont les besoins et spécifications sont clairement exprimés. L un des problèmes majeurs résidant dans son manque de flexibilité quant au changement de spécification, il est cependant possible d inclure une boucle de prototypage pour sécuriser l adéquation du produit avec les besoins. Modèle avec prototypage : permet la validation des spécifications par expérimentation (pour expliciter l analyse des besoins et les spécifications fonctionnelles). Le prototype expérimental est utilisé pour valider des options de conception ou pour obtenir le produit final par itérations successives. Figure 31 : Modèle en cascade avec un maquettage et un prototypage Modèle en V : modèle normalisé par l'afciq (Association Française pour le Contrôle Industriel et la Qualité), l'afnor et l'iso. Il représente une variante du modèle en cascade en se focalisant sur les étapes de spécification et de vérification / validation. La conception va du plus large (système) au plus spécifique (sous-ensembles, composants), et à chaque étape de spécification est associée une étape de vérification / validation / test. Modèle en W : extension du modèle en V, il introduit une phase de définition des interfaces externes permettant à l utilisateur de juger, dès le stade de la conception, les interfaces utilisateur du futur produit. Modèle par extensions successives : variante du modèle en cascade dans lequel le système est découpé en plusieurs sous-ensembles logiques ; les fonctionnalités sont étendues progressivement à partir d'une 1ère réalisation (noyau regroupant les fonctionnalités minimum).ce modèle permet de limiter les coûts et risques (par exemple en arrêtant le projet à la première itération si nécessaire). Il permet de maitriser les délais et les coûts en sécurisant le développement par des livrables intermédiaires. Enfin, la motivation représentée par des objectifs définis à court terme améliore la vitesse de travail de l équipe. Par contre, les difficultés résident dans la gestion des extensions qui peut être complexe (le développement de nouvelles extensions ne doit pas remettre en cause l architecture globale du produit). Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 51

Modèle en spirale : tient compte de la possibilité de réévaluer les risques en cours de développement, il emprunte au prototypage incrémental mais lui adjoint une dimension relevant de la prise de décision managériale et non purement technique. Il s inspire de l idée d extensions successives : approche itérative du processus de développement du logiciel représentée par les boucles successives de la spirale, chaque boucle se déroule en quatre phases : détermination des objectifs du cycle, des alternatives pour les atteindre et des contraintes ; à partir des résultats des cycles précédents, ou de l analyse préliminaire des besoins ; analyse des risques, évaluation des alternatives à partir de maquettage et/ou prototypage ; développement et vérification de la solution retenue, un modèle «classique» (cascade ou en V) peut être utilisé ici ; revue des résultats et vérification du cycle suivant. Ce modèle est adaptée aux projets développés en interne, en effet il est assez difficile de quantifier le travail et donc de contractualiser sa réalisation à un sous traitant. Modèle unifié. Le Processus Unifié (PU ou UP en anglais pour Unified Process) est une méthode de gestion du cycle de vie d un logiciel, développée par I. Jacobson, J. Rumbaugh et G. Booch (1997).C est une méthode de développement générique, itérative et incrémentale, pour les logiciels orientés objets. Le processus unifié s emploie conjointement à la méthode de modélisation systémique UML (orientée objet). Il complète cette méthode de développement et fournit un cadre théorique générique prenant en compte le cycle de vie du logiciel. L une des implémentations les plus utilisées du processus UP est la méthodologie RUP (Rational Unified Process). PU s appuie sur 6 bonnes pratiques : un développement itératif, la gestion des exigences, la gestion des demandes de changement, l utilisation des architectures à base de composants, la modélisation graphique des exigences, et la vérification continue de la qualité du logiciel. PU fonctionne suivant une série de cycles, aboutissants chacun à un livrable : la livraison d une version du produit aux clients. Un cycle s articule en 4 phases : création (inception), élaboration, construction et transition, chacune d entre elles se subdivisant à son tour en itérations. Figure 32 : Cycle de vie du processus unifié La phase de création correspond à la phase de définition du projet (avant-projet), elle inclut les étapes de l étude d opportunité et de l étude de faisabilité. La phase d élaboration correspond aux étapes d organisation du projet et de conception. La phase de construction correspond aux étapes de développement et de réalisation. Enfin, la phase de transition correspond à la mise en œuvre du logiciel. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 52

PU propose l utilisation intensive des schémas et modèles graphiques : Modèle des cas d utilisation : décrit les cas d utilisation et leurs relations avec les utilisateurs. Le terme utilisateur renvoie aux utilisateurs humains et également aux autres systèmes. L utilisateur représente donc une personne ou une chose dialoguant avec le système en cours de développement. Les cas d utilisation transcrivent les besoins fonctionnels et leur ensemble constitue le modèle des cas d utilisation qui décrit les fonctionnalités complètes du système. Le développement est piloté par les Diagrammes de Cas d'utilisation. Modèle d analyse : détaille les cas d utilisation et procède à une première répartition du comportement du système entre divers objets. Modèle de conception : décompose la structure statique du système en sous-systèmes, classes et interfaces ; et définit les cas d utilisation réalisés sous forme de collaborations entre les sous systèmes, les classes et les interfaces. Modèle d implémentation : intègre les composants (code source) et la correspondance entre les classes et les composants. Modèle de déploiement : définit les nœuds physiques des ordinateurs et l affectation de ces composants sur ces nœuds. Modèle de test : décrit les cas de test vérifiant les cas d utilisation. Figure 33 : Illustration du processus unifié A partir du modèle des cas d utilisation et des diagrammes associés, les développeurs créent une série de modèles UML d analyse, de conception, et de déploiement. Tous ces modèles sont ensuite révisés pour contrôler leur conformité par rapport au modèle des cas d utilisation. Enfin, les testeurs testent l implémentation pour s assurer que les composants du modèle d implémentation mettent correctement en œuvre les cas d utilisation. 4.2.3 Modèles agiles de développement logiciel Une méthode agile est une méthode de développement informatique permettant de concevoir des logiciels en impliquant au maximum le demandeur (client), ce qui permet une grande réactivité à ses demandes. Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles visent la satisfaction réelle du besoin et non d'un contrat établi préalablement. La notion de méthode agile est née à travers un manifeste signé par 17 personnalités (parmi lesquelles Ward Cunningham, l'inventeur du Wiki), créateurs de méthodes ou dirigeants de sociétés. Les grands principes des méthodes agiles se retrouvent dans le «manifeste agile» et se traduisent par quatre oppositions aux concepts traditionnels : Individus et interactions contre processus et outils, Logiciel qui fonctionne contre documentation exhaustive, Collaboration du client contre négociation de contrat, Réponse au changement contre suivi d'un plan prédéfini. Un des buts fondateurs des méthodes agiles est d éviter «l effet tunnel» d allongement des délais et de glissement des jalons, en multipliant les interactions avec le client par le biais d itérations et de livraisons courtes. L agile est une démarche qui vise à produire les bonnes fonctionnalités dans une optique de qualité. L idée n est pas de développer plus vite et moins cher, mais de faire la bonne fonction au bon moment! Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 53

La méthode RAD structure le cycle de vie du projet en 5 phases : Le manifeste Agile En 2001, les ténors du monde agile se sont réunis pour extraire de leurs pratiques et méthodes respectives la substantifique moelle. Il en a résulté un certain nombre de choses très intéressantes, mais on retient principalement quatre points, que l on appelle «le manifeste agile» (http://agilemanifesto.org/). On remet le facteur humain au centre. C est bien lui qui construit l application, et non le processus ou des outils. Ces derniers ne sont là que pour aider, et surtout pas pour «commander». Dans des organisations du type de celle de France Telecom, où il y a beaucoup de gens, il est difficile de fonder la réussite du projet sur la confiance dans la qualité du travail que fournira chaque intervenant. C est pourtant une des idées fortes de l agilité : on confie un rôle à quelqu un, on le responsabilise et on lui fait confiance. Cela comporte une petite part de risque, mais on constate à l usage, dans l énorme majorité des cas, que cette prise de risque a été payante. La contractualisation tente de substituer la volonté de bien faire par des obligations contraignantes. On a l impression que parce qu on a signé un contrat, on est à l abri des problèmes. Il n y a rien de plus faux! Est-ce qu un contrat a évité un décalage du planning? Pratiquement toujours, la réponse est non. Par contre, il a nuit à la relation entre les partenaires. Imaginons maintenant que chaque acteur du projet accepte cet objectif : faire une application utile au métier. Chacun va alors collaborer pour obtenir le meilleur résultat possible. Bien sûr, des problèmes pour survenir au fur et à mesure, mais on cherchera des solutions ensemble (en collaborant). De toute façon, ces problèmes auront à être réglés, et le contrat ne fera rien, ou alors il faudra un avenant. Que d énergie, d argent et de temps perdu lorsqu on ne collabore pas, mais qu on exige sans prendre en compte les contraintes, et on pourrait presque dire, la réalité des choses. Plutôt que de figer au maximum les choses pour espérer garantir un résultat, on va accepter dès le départ que des changements sont possibles. Et on aura raison! Si le fonctionnel change, il est dans l intérêt du métier que ce changement soit pris en compte au plus tôt. Si les contraintes techniques change, ou que le code se révèle plus difficile que prévu à écrire, il faut aussi le prendre en compte, puisque c est la réalité! Enfin, même si il est indispensable de documenter un projet, le plus important est en premier d avoir un logiciel qui fonctionne. Là encore, ce qui paraît être du bon sens n est pas forcément appliqué sur le terrain : on juge le projet à la complétude de sa documentation, aux comptes-rendus des différents passages de jalon, au respect des dates annoncées, mais on accepte très RAD souvent : «qu une RAPID application APPLICATION parte en production DEVELOPMENT alors qu on» sait qu elle contient encore des bogues. N est-ce pas étonnant? A-ton encore à l esprit de délivrer une application utile au métier? L'organisation du projet s'appuie sur un principe fondamental : la séparation des rôles et des responsabilités entre maîtrise d'ouvrage (MOA) et maîtrise d'œuvre (MOE). Cette dichotomie renforcée par la présence d une instance d animation RAD (Groupe d Animation et de Rapport) implique une véritable réingénierie des méthodes de conduite de projet et impose aux deux maîtrises une redistribution des rôles opérationnels et un apprentissage. L Initialisation définit l organisation, le périmètre et le plan de communication. Le Cadrage définit un espace d objectifs, de solutions et de moyens. Le Design modélise la solution et valide sa cohérence systémique. La Construction réalise en prototypage actif (validation permanente). La Finalisation est un contrôle final de qualité en site pilote. Principes de la méthode La phase de spécification/conception est remplacée par une phase de prototypage menée conjointement avec le client. Ce modèle déploie une démarche participative des intervenants du projet : les utilisateurs et les concepteurs collaborent au cours d ateliers afin d aboutir à un consensus sur les besoins à couvrir. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 54

Figure 34 : Illustration du modèle RAD Cette méthode est adaptée aux projets développés en interne, en effet il est assez dur de quantifier le travail et donc de contractualiser. Le manque de conception inhérent à la démarche a rendu nécessaire une amélioration du modèle, dont est issue la méthode DSDM. Cette méthode est adaptée aux petites applications de gestion, n'ayant pas de cycle de vie d'une trop longue durée. SCRUM SCRUM est une méthode agile de gestion de projets ; elle est itérative, incrémentale et adaptative. C est un processus de développement de logiciels qui s'intéresse plus à l'organisation du projet qu'aux aspects techniques. Cette méthode générique ne couvre pas le cycle de développement d un logiciel, il est donc nécessaire de lui adjoindre une méthode complémentaire telle que l Extreme Programming. Les processus de développement traditionnels séquentiels correspondent de moins en moins aux nouveaux besoins applicatifs. Or, il semble, dans la pratique, que nous ne sommes pas bons pour estimer : seulement 31% des projets informatiques tiennent les délais et le budget, et qu en moyenne un projet coûte 189% de ce qui était initialement prévu. L approche adaptative mise en avant par SCRUM au contraire introduit l acceptation d un certain changement en partant d une planification initiale et accepte les réévaluations au fur et à mesure des itérations pour s adapter aux évolutions du besoin. SCRUM, dans son approche adaptative, se distingue des approches prédictives dans le sens où ses dernières : Tentent de limiter l incertitude au plus tôt du projet en s appuyant sur un planning exhaustif et précis Nécessitent la définition complète du produit avant de lancer les développements Demandent de stabiliser les exigences de l application finale au début du projet Le terme Scrum est emprunté au rugby à XV et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée, qui cherche à atteindre un but, comme c'est le cas en rugby pour avancer avec le ballon pendant une mêlée. Un principe fort de Scrum est la participation active du client pour définir les priorités dans les fonctionnalités du logiciel et pour choisir celles qui seront réalisées dans chaque sprint. Il peut à tout moment compléter ou modifier la liste des fonctionnalités à réaliser, mais jamais celles qui sont en cours de réalisation pendant un sprint. Principes de la méthode Cette méthode repose sur des développements itératifs de fonctionnalités, chaque itération étant appelée «Sprint». Chaque sprint a pour finalité de produire une version du produit incluant certaines fonctionnalités. Un groupement de Sprints, aboutissant à la livraison d une version du produit incluant des fonctionnalités définies, est appelée release. La réalisation d un Sprint (figure ci dessous) est rythmée par quatre moments clés : 1) L élaboration de la liste des besoins métier ; 2) La préparation du sprint à venir ; 3) L exécution du sprint ; 4) La revue et rétrospective du Sprint écoulée. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 55

Figure 35 : Représentation de la méthode SCRUM - déroulement d un Sprint L élaboration de la liste des besoins métier L ensemble des fonctionnalités à réaliser est appelé le backlog du produit (product backlog). Le backlog de produits est le cœur de Scrum.C est la liste priorisée de besoins et exigences que veut le client, exprimés dans son vocabulaire et sa terminologie métier. Le product backlog représente "l'ensemble des fonctionnalités du produit que l'on veut développer". Il priorise les différentes fonctionnalités, le but étant d'implémenter en premier ce qui a le plus de valeur (meilleur ratio entre ce que rapporte une fonctionnalité et ce qu'elle coûte). Le product backlog présente plusieurs niveaux de granularité. ce qui doit être réalisé à court terme doit être de granularité fine pour ce qui est long terme, une description grosse maille suffit (rien ne sert de tirer des plans sur la comète!) Le product backlog est sous l entière responsabilité du Directeur de produit (product owner). Le Directeur de produit est l'interlocuteur des métiers dans la démarche. Dans ce cadre, le Directeur de produit doit : - être le représentant du client ou des utilisateurs. - récolter les attentes, besoins, exigences du client ou des utilisateurs et les priorités associées. - formaliser le backlog de produit avec le niveau de précision adapté à la priorité. - être en mesure de les expliquer au Scrum Master et à l équipe de développement ou d inviter le client et/ou un utilisateur pour le faire. - définir le planning des releases dans lesquels les Sprints s inscriront. - définir les tests de bon fonctionnement attendus lors de la démonstration. - Le Directeur de produit définit, à partir des données issues des métiers le contenu de chaque version et la date souhaitée. Le contour de la version est revu avec le Scrum Master (coach et facilitateur de l équipe de développement) pour valider la date de livraison et identifier le nombre de Sprints nécessaires. Les contours de version sont acceptés par les métiers, le COPIL, Le contour de chaque Itération donne lieu à la création d un Backlog de sprint (backlog d'itération / Sprint backlog) revu avec l équipe de développement. La préparation du sprint à venir Avant de démarrer un sprint toute l équipe de développement se réunit. D autres personnes peuvent assister en temps que spectateur à cette réunion (Clients, ). Elles ne peuvent y intervenir sans invitation préalable d un membre de l équipe (par exemple pour fournir des éclaircissements). Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 56

Figure 36 : Comment construire le backlog C est l équipe en concertation avec le Directeur de produit et le Scrum Master qui définit l organisation et planification du sprint à venir, comportant : la définition du but du sprint, la revue du budget, chiffrage et estimation du coût, la détermination du backlog, des jalons, de l équipe, la définition de l architecture générale, de la conception générale (1 er sprint), le choix des items du backlog du produit à réaliser, l identification et analyse des risques, la décomposition des items du backlog du produit en items du backlog du sprint (puis pour finir celle de ces items en tâches élémentaires), l estimation de la charge / durée pour chaque tâche élémentaire. L exécution du sprint Scrum ne couvre pas les moyens et les techniques à mettre en œuvre pour la réalisation du produit. Néanmoins, la méthodologie prévoit des réunions quotidiennes, aussi appelée mêlées (scrum en anglais), qui permettent à tous les membres de l équipe de développement de faire le point sur l évolution des tâches du backlog du sprint et sur les difficultés rencontrées. Au cours de cette brève réunion, de maximum 15 minutes, l équipe fait le point sur : Les réalisations engrangées depuis la dernière mêlée. Les réalisations envisagées jusqu à la prochaine mêlée. Les problèmes et difficultés rencontrés. Les difficultés qui ne peuvent être surmontées par l équipe de manière autonome sont prises en charges par le Scrum Master dont la mission principale est d éviter que ces difficultés ne perturbent le déroulement du sprint. Le résultat de cette réunion est une mise à jour du backlog du sprint, que ce soit en termes de tâches à réaliser ou en termes d évaluation du «reste à faire». Un outil particulièrement intéressant pour la mesure du progrès et du reste à faire est le graphique d avancement. Ce graphique reprend, de manière quotidienne, le volume de travail à réaliser pour atteindre l objectif. L évolution de la courbe permet de mesurer rapidement si ce dernier pourra ou non être atteint et prendre ainsi les mesures nécessaires. La revue et rétrospective de l itération écoulée Une fois le sprint terminé, et donc des produits réalisés lors de celui-ci, une, voir deux réunions distincte, de revue du sprint et de rétrospective, ont lieu. La revue du sprint a pour but de vérifier la conformité du réalisé (intégration et jeux de tests), ainsi que de s occuper de la mise à jour la documentation. La rétrospective, quant à elle, a pour objectif de capitaliser sur le retour d expérience dans le but d améliorer, de manière continue, la performance de l équipe et la qualité du produit. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 57

Synthèse & Sémantique/Terminologie SCRUM, un processus simple, quelques définitions d acteurs et d outils de la méthode. 3 acteurs : Directeur de produit (Directeur de produit) : personne responsable de produire et maintenir à jour le backlog de produit. C'est lui qui en détermine les priorités et qui a le pouvoir décisionnel dans le projet. Scrum Master : membre de l'équipe dont l'objectif principal est de la protéger des perturbations extérieures. Il est complètement transparent pour la communication entre l'équipe et les clients et n'a aucun pouvoir hiérarchique sur l'équipe. C'est en revanche un facilitateur pour les problèmes non techniques de l'équipe ; il encadre le développement du produit suivant la méthodologie SCRUM. L équipe : elle fonctionne suivant un principe d autogestion. 3 artéfacts : Backlog de produit (Product Backlog) : liste des fonctionnalités qui devront être réalisées par le logiciel, liste priorisée de besoins et exigences que veut le client, exprimé dans son vocabulaire et sa terminologie métier Backlog de sprint (Sprint Backlog) : liste des tâches à accomplir pendant un sprint. Elles correspondent à la réalisation des items de backlog du produit affectés au sprint. Graphique d'avancement (Burndown Chart) : graphique qui montre la tendance du reste à faire total de jour en jour (pour les sprints) ou de sprint en sprint (pour les releases). 4 rendez-vous : Planification de sprint. Sprint est le terme désignant une itération dans Scrum. Cette itération dure 30 jours calendaires en théorie, mais en pratique on utilise plutôt entre 2 et 4 semaines. Pendant une itération, l'équipe doit développer une liste d'items du backlog de produit qui a été définie au début de ce sprint. Mêlée quotidienne (Daily Scrum) : réunion quotidienne de 15 minutes qui a pour but de faire le point sur ce qui a été fait depuis la dernière mêlée, ce qui est prévu de faire jusqu'à la prochaine et quelles sont les embûches rencontrées durant le travail. Revue de sprint : jalon Qualité, vérification de la conformité du réalisé (intégration et jeux de tests). Rétrospective : retour d expérience pour capitalisation et amélioration continue. Le travail d une tâche peut être estimé en points relatifs (suivant la suite de Fibonacci : 1, 2, 3, 5, 8, 13), qui déterminent sa complexité. La vélocité de l équipe représente le nombre de points relatifs qu elle peut réaliser en un sprint. L analyse rétrospective revient sur le travail effectué durant le sprint pour déterminer la vélocité de l équipe, revoir les estimations de planification, afin de peaufiner l organisation du sprint suivant. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 58

Inconvénients Requiert une forte implication du client pour - Prioriser les fonctionnalités ; - Mettre en œuvre de tests périodiques à chaque release ; - Participer aux réunions de définition et de priorisation du backlog : être force de proposition, faciliter le processus de priorisation, respecter les arbitrages du Directeur de produit ; - Etre disponible pendant les itérations ; - Etre présent (sur invitation) au réunion de Démonstration ou fin d'itération pour : Valider les réalisations avec le Directeur de produit. Identifier des évolutions ou des nouvelles fonctionnalités et les prioriser. Nécessite une forte cohésion et implication de l équipe, ainsi qu un certain isolement (pour limiter les perturbations). Principaux inconvénients des modèles itératifs (voir modèle par extensions successives) 2 Avantages Engendre un processus d amélioration continue. Fédère et responsabilise l équipe. Principaux avantages des modèles itératifs (voir modèle par extensions successives) 3 Méthode Extreme Programming (XP) Cette méthode a été inventée par Kent Beck, Ward Cunningham et Ron Jeffries en 1999. C est une méthode agile de gestion de projets informatiques qui est applicable pour des équipes réduites, répondant à des besoins changeants. XP est à la fois un processus de développement, un état d esprit et des valeurs, et un ensemble de bonnes pratiques. XP est une méthode itérative qui préconise des bonnes pratiques, et qui repose sur une forte collaboration de l équipe et une forte implication du client. Elle s appuie sur 5 valeurs fondamentales : la communication, la simplicité, le feedback, le courage et le respect. Les 5 valeurs de XP sont déclinées en 13 pratiques : 2 Difficulté de planification (quantification du travail) et donc de contractualisation (baseline de départ floue). Gestion complexe des extensions, le développement progressif de nouvelles extensions ne doit pas remettre en cause l architecture globale du logiciel. 3 Permet de limiter les coûts et les risques (arrêt dès la première itération). Permet la maîtrise des délais et des coûts de développement (sécurisés par les livrables intermédiaires). Améliore la vélocité grâce à la motivation des objectifs à courts termes. Permet de s adapter rapidement aux modifications des besoins des utilisateurs. Fournit de nombreuses versions prototypes pour sécuriser les fonctionnalités. Permet d affiner le besoin et les solutions. Permet la capitalisation de l expérience au fil des extensions. Facilite la validation (puisqu elle est semi-continue). Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 59

Figure 37 : Illustration des 13 pratiques XP La présence du Client sur site, celui-ci est le référent pour les besoins et la priorisation. Il écrit les scenarios (user stories), les priorise et établit les tests de recette. La planification continue et évolutive (planning game), celle-ci évalue différents scénarios pour implémenter les fonctionnalités lors d une itération (de 1 à 3 semaines). L intégration continue, le produit complet est mise à jour en continue au fil des itérations, le client réalise fréquemment des tests d intégration (il écrit les tests de recette). La fréquence des livraisons, conjointement à l intégration et aux tests continus elle réduit considérablement le coût de livraison et les risques. Le rythme de développement soutenable (pas de surcharge). Le développement piloté par les tests, tests de recette (ou tests fonctionnels) à chaque itération et tests unitaires pour chaque fonctionnalité (ils sont écrits avant le code à tester). On privilégie au maximum l automatisation des tests. Une conception simple, focalisée pour chaque itération sur les scénarios sélectionnés. L utilisation de métaphores ou d analogies pour décrire le système et son fonctionnement, et faciliter ainsi sa compréhension. Le refactoring, amélioration continue de la qualité du code. L appropriation collective du code, pour une collaboration efficace de l équipe. Les conventions de nommage, normes facilitant le travail en équipe. La Programmation en binôme, permet de capitaliser les connaissances, et de sécuriser le développement. Le travail d équipe, l équipe travail de manière collaborative, en favorisant l autogestion. Figure 38 : Cycle de développement XP La phase de planification release établit la planification initiale, qui évolue en continu avec les itérations. Le planning définit les dates et contenus (scenarios) de chaque itération et de chaque release. La première itération, d une durée moyenne d un mois aboutit à un prototype fonctionnel. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 60

Figure 39 : illustration d une itération XP En premier lieu, une phase exploratoire analyse les scénarios qui seront fournis pendant cette itération, en fonction de la priorisation du client et de la vélocité de l équipe lors de la précédente itération. Puis, l'équipe décompose les scénarios en tâches à réaliser et conçoit les tests fonctionnels associés. Chaque développeur s'alloue des tâches et les réalise en binôme ; Une fois tous les tests fonctionnels validés, le produit est livré. Inconvénients Requiert une forte implication du client pour la priorisation des fonctionnalités et la mise en œuvre de tests périodiques à chaque release. Ne couvre pas les phases en amont et en aval du développement : capture des besoins, support, maintenance Elude la phase d analyse, si bien qu on peut dépenser son énergie à faire et défaire. Assez flou dans sa mise en œuvre: quels intervenants, quels livrables? Avantages Nécessite une forte cohésion et implication de l équipe, ainsi qu un certain isolement (pour limiter les perturbations). Engendre un processus d amélioration continue. Fédère et responsabilise l équipe. Simple à mettre en œuvre. Fait une large place aux aspects techniques : prototypes, règles de développement, tests 4.2.4 Conclusion sur les modèles Les caractéristiques et l efficacité de ces modèles de conduite de projet dépendent grandement des modalités de leur application. Cependant, ils présentent certaines particularités, illustrées dans le tableau ci-dessous. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 61

Ils accentuent chacun leur tour, certaines composantes principales de la conduite de projet : le séquençage précis (en accord avec le cycle de vie), la tenue et la maîtrise rigoureuse des objectifs (revues de jalons), et une orientation qualité pour les processus séquentiels. la flexibilité et l adaptabilité afin d affiner l analyse des besoins, et la réalisation de boucles de conception / développement afin de valider en continue le produit pour les modèles itératifs. l implication du client, la cohésion et la responsabilisation de l équipe, afin de capitaliser l expérience et d enclencher un processus d amélioration continue (organisation apprenante) pour les méthodes agiles. La connaissance de ces différents modèles rappelle à notre connaissance des perspectives fondamentales de la gestion de projet, qui doivent nous guider dans notre activité de pilotage. Aucun de ces modèles n est bien sûr parfait, cependant chacun est plus au moins adapté à un contexte spécifique, et doit être employé après réflexion et analyse sur un projet logiciel. Le choix pertinent d un modèle repose fondamentalement sur les acquis, la culture de l entreprise et de l équipe projet. Il semble, en effet, particulièrement difficile d appliquer une méthode agile au sein d une entreprise rompue au processus séquentiel. Enfin, bien que le plus souvent focalisée sur une méthodologie particulière notre démarche de conduite de projet peut emprunter à chacun de ces modèles des items pertinents pour développer une méthodologie ad hoc. 4.3 Méthodologies et certification La certification à titre personnelle sur l une de ces méthodologies est bénéfique, a minima pour faire monter en connaissance une population de jeunes chefs de projet. L acteur est ainsi reconnu par ses pairs comme ayant acquis une connaissance qui se transformera en compétence avec la pratique. Il acquière et peut ainsi justifier d un savoir-faire dans un premier temps, puis, l expérience d encadrement s affirmant, il démontrera un certain faire-savoir. Sur PMP, la certification est clairement affichée et favorisée. Elle se présente sous différentes formes : Certified Associate in Project Management (CAPM) et Project Management Professional (PMP) sont des certifications délivrées par le Project Management Institute PMI ou par des centres agréés. La première, CAPM, justifie d'une connaissance acquise des concepts et principe de la gestion de projet. Certified Associate in Project Management (CAPM) sur le site PMI La seconde, PMP, est une véritable certification professionnelle justifiant d'une expérience et d'une expertise. Celle-ci devra être complétée et validée régulièrement. 4.4 Un changement? Un accompagnement! Admettons : le projet informatique est en cours. Les méthodologies de conduite de projet informatique garantissent l aboutissement du développement, de la recette et de la mise en production de l application. Au préalable, les méthodes de modélisation de processus ont permis d optimiser l organisation de l entreprise et l adéquation du système logiciel aux besoins de l utilisateur. Les méthodes de pilotage de projet garantissent le bon aboutissement du projet dans les délais et les budgets en levant les risques. Cependant, si la solution est parfaite dans sa réponse au besoin et dans ses qualités techniques, rien ne dit qu elle soit utilisé par ses utilisateurs. En parallèle, une autre réflexion doit s engager qui doit garantir la prise en main de l outil informatique par les utilisateurs. Dès lors la démarche s oriente non plus sur la technologie ou sur l organisation, mais sur la connaissance, les savoir-faire et les comportements. Figure 40 : Accompagnement au changement : 3 axes d actions Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 62

De nombreuses applications très abouties et portant un fort espoir de progrès ne sont que peu utilisées, voire jamais utilisées. Tous les efforts consentis se trouvent réduits à néant car les utilisateurs n acceptent pas leur nouvel outil. La raison en est souvent une résistance au changement. Tout changement dans notre cadre de vie, nos habitudes, qu il provienne de façons de travailler ou d outils à utiliser provoque des réticences. Réciproquement, souvent un bel objet suscite l intérêt et l attirance. L objectif des actions de conduite du changement est donc de lever les freins au changement puis de susciter l intérêt, de passer de l incompréhension à l adhérence, puis à l implication. Figure 41 : Cycle d acceptation du changement Le précédent montre trois points essentiels sur ce passage de la réticence vers l implication : Il procède par étapes, et certaines d entre elles sont inévitables, notamment le déclic de la réticence à l adhésion Il n est pas instantané ; il demande un certain temps Il demande de l énergie, il n est donc pas donné, il faut même le provoquer. Figure 42 : Passage de la réticence à l action Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 63

Les méthodes de conduite du changement ont donc pour objectifs de passer ses étapes, dans un délai optimisé mais qui ne peut être nul et d apporter les éléments et l énergie nécessaires pour franchir les caps. Le risque inhérent au changement fait que dans la plupart des grands projets, un chantier spécifique «conduite du changement» est mis en place. Ces actions peuvent être classées en 4 catégories : L information L accompagnement La formation La coordination et le pilotage Il est important de comprendre que ces actions ont lieu dans la durée et dès le démarrage des premières phases projet. Les actions d information de formation, d accompagnement s enchaînent jusqu à la prise en main de la solution ce qui entretient un rythme continu et implique les personnes concernées. Figure 43 : Exemple de plan de communication Les actions d information sont réalisées tout le long du projet depuis le démarrage du projet et au-delà de la mise en œuvre. L information concerne toutes les étapes de la réalisation du projet depuis le lancement jusqu à la mise en œuvre. Son cadencement permet d anticiper et de préparer les personnes aux évènements. Les supports d information sont plutôt de type indirect et collectif, mais l information peut être délivrée à tout moment. L accompagnement a pour objectif d amener les utilisateurs à s impliquer dans la construction et la mise en œuvre concrète du changement. Elle doit permettre à chacun d'exprimer ses doutes et réticences par rapport au changement annoncé. Les résistances sont d autant moins fortes si elles sont immédiatement écoutées, reconnues et comprises par le management de proximité. L accompagnement fait l objet d une communication de type direct et individuel. L accompagnement type se fait au travers d atelier sous un mode participatif ou chacun est amené à s exprimer et proposer des solutions. Ces actions d information et d accompagnement sont définies, listées, planifiées et suivi dans le plan de communication qui est un des deux livrables clés de la méthode de conduite du changement. Bien sûr, toute nouvelle organisation ou outil informatique ou changement doit donner lieu à des actions de formation qui détaillent les objectifs et le fonctionnement mis en œuvre. Un point important de ces informations est qu au-delà du fonctionnement proprement dit qui doit être clair et didactique, il faut préciser à quoi sert la solution et contextualiser le fonctionnement : Quels sont les bénéfices attendus?, en quoi la solution est un progrès?. Il est nécessaire de projeter l utilisateur dans un projet et dans un rôle afin qui ressentent en quoi il est utile. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 64

Enfin, les actions liées à la conduite du changement doivent être pilotées. A tout moment, il doit être possible de dresser un bilan des actions réalisées et de leur efficacité, des risques encourus afin d anticiper les problèmes et prendre les actions nécessaires. Les méthodologies standard structurent ces actions en 4 phases : Figure 44 : Une méthode d accompagnement en 4 grandes étapes Diagnostiquer et analyser pour adapter la méthode et la portée des actions, identifier les points durs, définir une stratégie Planifier et budgétiser, définir la gouvernance de pilotage Mettre en œuvre les actions spécifiques de la conduite du changement vues précédemment Réaliser le bilan de la démarche, mesurer la satisfaction, savoir où l on en est Il est important que le démarrage de cette démarche intervienne très tôt dans le processus projet afin d anticiper les risques et les problèmes, d adapter les actions en conséquence, d informer les utilisateurs officiellement «avant» la mise en œuvre définitive du changement. Les principaux livrables à réaliser sont : Le plan de communication Le plan de formation Les supports de communication : présentation support des ateliers, lettre et mail d information, flyers Les supports de formation : présentation support, manuel utilisateur Ils mettent en œuvre les techniques de communication et de mise en participation. Si l on a décidé de mettre en œuvre une démarche de conduite du changement, on limite forcément les conséquences de nombreux risques liés à la prise de l outil de l adaptation à une nouvelle organisation. Cependant, une démarche de conduite du changement n est elle-même pas à l abri du risque et de l échec. Il est crucial de pouvoir anticiper les risques et de faire le point très régulièrement (lors des points hebdomadaires par exemple) sur les différentes causes d échec possible. Un outil intéressant pour cela est sur la matrice des causes d échecs suivante, à partir de laquelle on peut se référer pour conduire son analyse de risque. A-t-on bien explicité puis communiqué sur la vision du projet, le contexte de mise en œuvre, les progrès attendus, les objectifs à atteindre et donc donner une vision claire à chacun des changements en cours? Les compétences pour s adapter à la nouvelle organisation ou pour utiliser le nouvel outil sont-elles bien au rendez-vous et la formation jouera-t-elle son rôle? Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 65

Chacun se sent-il bien reconnu dans son rôle? Les différentes personnes impliquées seront-elles bien les acteurs du changement? Ne faut-il pas insister sur les ateliers participatifs? A-t-on bien anticipé le besoin en ressource? Le plan d action est-il réaliste, cohérent? A-t-on bien identifié les différentes contraintes externes (congés, réorganisation, impacts des autres projets,? Figure 45 : Quelques causes d échec au changement Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 66

5 EXEMPLE D APPLICATIONS 5.1 Mise en place de référentiel Qualité 5.1.1 Qui est Aubay du point de vue des référentiels? L activité, les clients, les offres de la société Aubay sont très bien décrites sur le site de l entreprise 4 ainsi que sur celui spécialement destiné aux jeunes diplômés 5. Nous invitons le lecteur à consulter ces sites qui sont des mines d informations pertinentes régulièrement tenues à jour. En bref, disons seulement que Aubay est un acteur de proximité à valeur ajoutée qui délivre des services de conseil en technologies, R&D et intégration de systèmes d information (Banque/Finance, Assurance, Industrie, Télécoms) et réseaux à très haute vitesse. La société dispose de 2072 collaborateurs répartis dans 11 bureaux, à travers 6 pays européens (France, Belgique, Luxembourg, Italie, Espagne et Portugal). Les activités et les compétences en développement logiciel et infrastructure IT sont au cœur des métiers de Aubay. En conséquence, le choix et l utilisation des référentiels se comprennent dans le contexte de promotion de nos activités front-office, de la notoriété et de la pérennité de Aubay. 5.1.2 Comment choisit-on un référentiel chez Aubay SA? Nous le comprenons, la pondération des critères qui préside au choix d un référentiel chez Aubay peut être significativement très différente de la pondération de ces critères pour nos clients DSI. Voici trois critères majeurs : Faciliter l adaptation permanente Signification pour Aubay : Aubay opère sur un marché d adaptation. La durée de vie d une offre est généralement de 3 ans, ce qui est aussi la durée ordinaire d un certificat. Il est donc illusoire de certifier des offres et donc beaucoup plus profitable d assurer la notoriété des activités et des compétences durables qui composent ces offres. Contribuer à la performance et à la régularité Signification pour Aubay : chez Aubay un référentiel doit accompagner la performance de l entreprise. Il doit donc contribuer à la promotion des offres qui constituent notre front-office, assurer le fonctionnement efficient du middle et du back-office et contribuer à l attractivité de l entreprise pour le personnel, les candidats et les investisseurs. Etablir un référentiel d entreprise prend entre 24 et 36 mois en moyenne. Or une personne reste en moyenne 4 ans chez Aubay. En conséquence, la pérennisation des compétences et des pratiques professionnelles dans l entreprise nécessite de trouver un équilibre raisonnable entre la facilité de mise en place d un programme de certifications individuelles et la pérennité d une certification d entreprise plus lourde à établir. In fine, un référentiel chez Aubay doit accompagner la croissance organique et externe en contribuant à optimiser les performances. Aider à établir un référencement durable Signification pour Aubay : pour Aubay les principaux référentiels sont choisis afin que le référencement et l attractivité de l entreprise soient bien établis pour les clients et les prospects, d une part, pour les investisseurs, le personnel et les candidats, d autre part. Ainsi, un référentiel aide au développement d offres pluriannuelles (centres de services et TMA). Aubay se place, d ors et déjà, parmi le top 10 des fournisseurs de ses plus importants clients. 4 www.aubay.com 5 http://jeunedip.aubay.com Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 67

5.1.3 Comment utilise-t-on un référentiel chez Aubay SA? Pour piloter l attractivité de l entreprise Le référentiel historique utilisé chez Aubay est constitué des normes comptables internationales IFRS/IAS. Ces normes internationales sont destinées à conforter l attractivité de l entreprise à l égard des investisseurs et des clients grands comptes en établissant la confiance en la gestion pérenne de l entreprise. En quelques chiffres : en 2004, le référentiel IFRS IAS est établi et pérenne. Aubay est alors un groupe en forte croissance, de 60 M, introduit en bourse, dont l effectif est d environ 700 personnes en Europe dont environ 200 personnes en France. Les prestations de conseils en technologie sont innovantes. La valeur ajoutée de celles-ci provient principalement de l expertise des ingénieurs qui les délivrent. Le mode de délivrance est essentiellement l assistance technique. L attractivité de l entreprise est aussi assurée vis-à-vis des collaborateurs par des relations solides avec les écoles d ingénieurs et la cooptation. en 2005 et 2008, Aubay obtient la labellisation OSEO-ANVAR entreprise innovante. Valable 3 ans, cette labellisation fera à nouveau l objet d un dépôt de dossier en 2011.Ceci contribue à établir l attractivité de l entreprise sous ses différentes perspectives et à la préparer à satisfaire à des offres à engagements diversifiés demandées par le marché. Le référentiel IFRS IAS et le label OSEO-ANVAR sont bien établis et pérennes. Pour piloter le front-office et la satisfaction client Afin de se préparer à poursuivre une forte croissance interne et externe donc à assurer des prestations à engagement profitables à la fois pour Aubay et ses clients, un référentiel de gestion maîtrisé des actifs métiers est mis au point et abouti, en 2006, à une certification qui établit que la gestion maitrisée de la qualité de Aubay France est conforme aux exigences de la norme internationale ISO 9001. En 2006, un premier palier est atteint, le groupe Aubay réalise environ 120 M, l effectif, qui dépasse 2000 personnes, a été multiplié par 6 en France. Ainsi, tout en préservant les acquis en termes d attractivité et d innovation, il est désormais essentiel d assurer la gestion maitrisée de la qualité de plus de 1000 prestations simultanées en Ile de France. Ces prestations se déroulant, en 2006, principalement en Assistance Technique. Le palier de 2006 fut atteint principalement par croissance externe et les référentiels IFRS IAS et ISO 9001 ont permis d optimiser à la fois l intégration financière et l intégration métier. En effet, IFRS IAS et ISO 9001 fournissent des cadres de réflexion pour piloter l attractivité et la satisfaction des clients pendant la phase transitoire d intégration. Le référentiel de qualité générale ISO 9001 est établi depuis 2006. Il renforce IFRS IAS et le label OSEO ANVAR. Pour piloter le middle et back-office d une grande entreprise En sus de la contribution à la croissance du CA par le biais des référencements et du pilotage de la satisfaction client via les activités front-office, la gestion maitrisée de la qualité générale s applique à l optimisation du middle office et du back-office qui contrôlent et administrent les activités. Les enjeux d un bon fonctionnement sont l optimisation des délais de paiement qui contribuent à une bonne trésorerie, la diminution des dysfonctionnements et de leurs impacts sur le front-office (réclamation, pénalité), la diminution du stress et de ses impacts sur l attractivité de l entreprise. La norme internationale ISO 9001 couvre l optimisation du fonctionnement du middle et du back office. Le référentiel de qualité générale ISO 9001 est établi depuis 2006 et renforce IFRS IAS. Pour piloter des activités front office régulières d une grande entreprise A coté des activités innovantes labellisées OSEO-ANVAR à très forte valeur ajoutée, il existe chez Aubay des activités régulières pluriannuelles à valeur ajoutée qui se renouvellent à un rythme plus lent que celui des activités purement innovantes. Les normes internationales et générales IFR IAS et ISO 9001 couvrent l ensemble des activités. Cependant, à coté de la comptabilité générale et de la qualité générale, ces activités récurrentes ont besoin de référentiels de qualité analytique sectorielle comme CMMI ou ITIL, pour ne citer qu eux. Les activités récurrentes sont soumises plus que les activités innovantes à : 1) des comparatifs méthodiques, 2) une mise en concurrence systématique, 3) l externalisation des sites clients et des regroupements, 4) une pression sur les prix à qualité constante Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 68

Quelles sont les conséquences? Il est nécessaire pour ces activités, dont le CA pluriannuel augmente, de s aligner sur des référentiels sectoriels qui permettent, d une part, à nos clients de comparer leurs fournisseurs et, d autre part, une gestion analytique de ces activités spécifiques (développement de logiciel, exploitation des infrastructures IT, sécurité informatique). Ainsi, ces référentiels sectoriels permettent de continuer à avoir voix au chapitre. Cependant, ils ne font pas toujours par eux-mêmes une différence compétitive. En conséquence, après avoir montré patte blanche grâce à la conformité aux exigences nécessaires de ces référentiels sectoriels, une analyse de la Direction Générale prouve que l avantage compétitif de Aubay se situe dans sa position d acteur de proximité. Aussi, après avoir fait le nécessaire, il convient de bien continuer à piloter cette relation de proximité qui donne entière satisfaction. 5.1.4 Comment s effectue la mise en œuvre? Depuis sa création en 1997, Aubay a toujours été sensible à la qualité de ses prestations, à la satisfaction de ses clients et à la compétence de ses collaborateurs en faisant preuve de responsabilité sociale et environnementale. Ces dernières années, la direction générale du Groupe Aubay a décidé de développer de manière significative son programme d actions vers l'optimisation de la satisfaction de ses clients, le respect de l environnement, la formation de ses collaborateurs, ainsi qu une approche collaborative où chaque collaborateur bénéficie en continu de la compétence collective du Groupe. Aubay place ainsi la qualité et l innovation au cœur de sa stratégie de développement. Le bureau Veritas, leader mondial de l évaluation et de la certification, atteste que la gestion de la qualité de Aubay SA est conforme à la norme ISO 9001-2008. Aubay SA traduit ses valeurs fondamentales au quotidien par des réflexes métiers organisés selon sa politique de gestion de la qualité C-T-R-L. La politique C-T-R-L est donc un catalogue de critères non-financiers, validés par la Direction Générale, sur lesquels doit s aligner le dispositif de gestion de la qualité patrimoniale qui vise à la maîtrise du bon déroulement des activités et à l obtention des résultats escomptés. La politique C-T-R-L s énonce, sous la forme d un acrostiche : Compréhension des besoins Impliquer les acteurs Collecter les améliorations Décrire les activités Tenue des engagements Planifier avant de réaliser Traiter les écarts Appliquer les directives Ressources performantes Fournir des ressources professionnelles Affecter clairement les responsabilités Former et informer les acteurs Livrables pertinents Piloter par rapport au plan Gérer les configurations Evaluer la conformité Sur la durée de trois ans d un certificat, le respect des exigences de la norme internationale ISO 9001 est formellement vérifié 9 fois dont 3 fois par bureau Veritas qui peut, chaque année, suspendre le certificat ou le renouveler. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 69

5.2 Certification CMMI 5.2.1 Naissance d une volonté Fort de sa certification répétée au fil des ans sur la norme ISO, grâce à son approche CTRL, Aubay a accueilli avec confiance la pression du marché visant à se faire certifiée conforme au modèle CMMI. En effet, les plus grands clients de notre société Aubay ont entamé en 2008 une marche vers le modèle CMMI, dans laquelle ils ont souhaité emmener leurs principaux fournisseurs pour 3 raisons : 1) S assurer que les équipes intégrées mêlant internes et externes seraient capable d accomplir cette mutation ; 2) S appuyer sur l expertise qualité de leurs fournisseurs pour booster leur propre démarche ; 3) Disposer d un critère de tri supplémentaire vis-à-vis de ces fournisseurs. Une SSII ne peut de son côté restée insensible à une démarche qui : 1) l associe à une évolution importante voulue par ses clients, 2) assure une plus-value commerciale, 3) propose un accroissement de l efficacité et de la pérennité du travail de ses équipes. 5.2.2 De CTRL à CMMI La certification ISO 9001-2008 est une certification globale de l entreprise, dont une des phrases biens connues de synthèse est : «on écrit ce qu on fait, on fait ce qu on écrit». Au-delà de cet aspect rédactionnel exigé par la norme, celle-ci au cours de son développement, insiste de plus en plus sur la logique, la pérennité, l efficacité, le suivi des processus d entreprise. Ces valeurs sont des valeurs que l on retrouve dans le modèle CMMI, au travers des pratiques génériques notamment. Cependant il existe des différences fondamentales entre ces deux approches. La première est la spécificité de CMMI sur des projets d ingénierie, versus l approche entreprise de ISO. De ce fait, CMMI va beaucoup plus loin que ISO sur des aspects d ingénierie, de métier informatique. Inversement, ISO aborde d autres aspects plus généraux à l entreprise, sur son fonctionnement interne. ISO s applique sur toute sorte d entreprise, industrielles, artisanales, tertiaires, et ce dans tous les secteurs de l économie. L approche est donc extrêmement générique. C est une des forces de la norme. CMMI peut s appliquer si et seulement si le métier de l entreprise ou d un département de l entreprise est le développement informatique, ou le service Ainsi, le terrain commun à CMMI et ISO 9001 est ténu, même s il est sous tendu par des valeurs universelles de bonne gestion, comme l alignement de l organisation aux besoins de l entreprise, la mise à disposition de moyens adéquats, l engagement de la direction auprès des opérationnels, etc. 5.2.3 Les premiers pas vers CMMI La démarche retenue par Aubay vers la certification CMMI est progressive. En effet, devant le niveau d exigence du modèle, et le détail des critères d éligibilité, il nous apparaît nécessaire de commencer par un état des lieux appliqué. Cet état des lieux, qui doit analyser, Process Area par Process Area, Specific Practice par Specific Practice, est nécessaire afin d appréhender sur des cas réels, les exigences du modèle, et de mesurer dans le détail la maturité de l entreprise. C est à cette occasion que l on peut identifier les écarts entre l existant et le modèle, et envisager un projet d amélioration adéquat. La notion de maturité Le terme maturité est un terme consacré dans CMMI. D'après la définition donnée dans le CMMI, la maturité d'une organisation est le degré auquel celle-ci a déployé explicitement et de façon cohérente des processus qui sont documentés, gérés, mesurés, contrôlés et continuellement améliorés. Un niveau de maturité (Maturity Level) correspond à l'atteinte d'un niveau de capabilité uniforme pour un groupe de processus. Un niveau de capabilité (Capability Level) mesure l'atteinte des objectifs d'un processus pour le niveau donné. En clair, un niveau de capabilité est un degré de maturité pour l ensemble des processus Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 70

L exigence de la norme La norme est entièrement définie dans un livre, le Guidelines for Process Integration and Product Improvement. Ce livre est disponible en français aussi, bien que parfois la traduction puisse être source de confusion. Ce livre de plus de 600 pages est extrêmement bien fait, et détail le contexte, les certifications, les PA, les SG, les SP, les GG, les GP. Pour chacune il donne une définition, des exemples de preuve, des idées, des illustrations. Cette complétude est en phase avec le niveau d exigence d une certification. Cette exigence peut -être source de désillusion si des personnes non expertes du modèle tentent d examiner les processus existants en regard du modèle. En effet, comme tous les modèles pragmatiques, CMMI n invente rien de révolutionnaire. Les pratiques listées sont des pratiques de bon sens, que tout ingénieur connaît, et prétend suivre peu ou prou. En première lecture, la norme apparaît donc comme un pense-bête permettant à un opérationnel de lister les actions à ne pas oublier. C est d ailleurs une utilisation possible du modèle, mais qui n est pas celle à retenir dans l optique d une certification. Certaines pratiques toutefois sont de nature à alerter le lecteur sur la complexité de l atteinte d un niveau. Dans les processus avancés, un service peu mature dans le métier de l ingénierie peut détecter des activités pas du tout adressées. Citons par exemple, dans la PA REQM (Requirement Management) la SP 1.4 (Maintain Bidirectional Traceability of Requirement), qui indique que le lien entre une demande client et un produit livré doit être tracé, et qu il doit être possible en permanence de le suivre dans un sens comme dans l autre. Une démarche nécessairement accompagnée La marche vers un niveau 2 est estimée à environ 18 mois. Cette durée inclut un état des lieux, une confrontation au modèle, la mise en place de nouveaux processus, et la préparation de l audit. Il est illusoire de préparer un audit sans se faire accompagner par un expert du modèle. En effet, l exigence de la norme, ainsi que la complexité du modèle, excluent tout amateurisme dans la démarche. 5.2.4 Le vécu Aubay Aubay est en phase de certification de niveau 2 sur l ensemble des projets de son Centre de Service Bancaire. Pour cela, Aubay se fait accompagné par différents cabinets d expert, reconnus sur le marché et par ses clients. Après une première phase d analyse des écarts, et un premier plan d amélioration, qui a permis de progresser significativement lors de deux readiness en 2010, la dernière ligne droite est abordée avec confiance, puisque les évolutions apportées sur la démarche projet l ont été en concertation entre les experts externes, la direction de la qualité, la direction technique, les opérationnels, et la direction générale. Ce consensus global est absolument nécessaire tant est grand l impact d une mise à niveau CMMI au cœur d une palette de projets concernant différents clients, différents chefs de projets, différentes technologies, différentes approches commerciales. En effet, dans l optique d un niveau de maturité 3, une SSII comme Aubay peut souffrir de l affrontement d une part de la volonté d uniformisation de ses pratiques au niveau de l ensemble de ses projets et d autre part de l influence puissante des choix d organisation des clients afin de favoriser la gestion et l intégration de ses prestations à engagement de résultats et de moyens. 5.3 Un projet développé en mode SCRUM Ce chapitre décrit une application de la méthode SCRUM au sein d un projet piloté par la société AUBAY. 5.3.1 Contexte du projet La méthodologie SCRUM a été utilisée dans le cadre du projet ARGO réalisé pour le compte de Sigedis, ASBL (association sans but lucratif) dans le secteur public des pensions belge. Sigedis est un organisme qui a pour mission de centraliser et d améliorer la qualité des données identitaires et carrière des salariés (employés et ouvriers) belges ou travaillant en Belgique. Ceci afin de permettre in fine le calcul de la pension légale de ceux-ci. Dans le cadre de sa mission, Sigedis est amené à échanger de nombreuses données avec d autres organismes et plus de deux milles partenaires du réseau de la sécurité sociale belge, mais également à traiter manuellement ces données. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 71

L'objectif du projet était : lors d'une première phase, de migrer le système existant d un mainframe vers une plateforme JavaEE et lors d'une seconde phase, d ajouter de nouvelles fonctionnalités au système tel que : - Des services web à destination des différents partenaires et organismes du réseau de la sécurité sociale - Un portail destiné au citoyen, afin que ce dernier puisse consulter ses données, son dossier de pension et faire un calcul de simulation du montant de la pension légale. Le système ARGO a été implémenté dans une architecture JavaEE, avec les outils suivants : le serveur applicatif JBoss, le système de base de données relationnelle Oracle, l'orchestrateur BPEL d'oracle, le système de gestion documentaire Alfresco et l outil d édition de rapports Business Objects, utilisé également comme interface vers un datawarehouse. Le projet a été réalisé dans le cadre d un marché public forfaitaire. Le projet a débuté en octobre 2006. La première phase a été mise en production en juin 2009 et la deuxième phase a été mise en production par lots entre juin 2010 et mars 2011. 5.3.2 Le choix de SCRUM Ce projet, mené conjointement avec SIEMENS, possédait des contraintes contractuelles fortes, telles qu'un budget déterminé d'avance et un délai fixe, correspondant à deux années civiles, assortis d'astreintes importantes, correspondants aux coûts de fonctionnement et de maintenance de l'ancien système mainframe pendant une durée d'une année, en cas de retard de livraison. Etant donné la taille du projet, le fait qu'une phase de pré-analyse existait déjà et les délais impartis, le choix s est porté naturellement sur une méthodologie de type Waterfall. Mais rapidement il s'est avéré que cette méthode ne convenait pas pour les raisons suivantes : 1) Nécessité et durée de l'analyse du projet. Ni le cahier de charges ni la documentation du système mainframe n'étaient suffisamment clairs pour démarrer la première phase de réalisation du projet (migration/réécriture du système mainframe existant). Ceci a amené à la réalisation d'une phase d'analyse très importante (de l'identification des processus métier à l'analyse fonctionnelle détaillée). Un cycle lourd de réunions, rédaction, validation de documents d'analyse, rédaction, nouvelle réunion, nouvelle validation, s'en est suivi. Cette phase d'analyse s'est éternisée, le client (secteur public) se dissipant et ne tenant pas compte des contraintes de temps critiques pour le maître d œuvre. 2) Vu la taille du projet, différentes équipes ont été formées par discipline (analyse, développement, test, base de données), sans prévoir de réelles couches de communication transversales. Ce qui a amené à des clivages et intérêts contraire au sein du même projet. Après six mois d'analyse, sans réel autre résultat que des dossiers d'analyse non validés, il a été décidé : de recentrer le périmètre du projet sur base du système existant. d'opter pour une méthode agile, Scrum en l'occurrence, afin de limiter le surcoût d une trop grande formalisation, ainsi que de favoriser la communication et la validation informelle et rapide, et ainsi montrer au maître d ouvrage que son projet évolue correctement. de prioriser et de décider du phasage des fonctionnalités du système avec le client. 5.3.3 Points clés Voici ici quelques autres points essentiels sur la mise en œuvre de Scrum dans le cadre du projet Argo : 1) Tous les matins, l'ensemble de l'équipe se réunit à heure fixe pour permettre à chacun de répondre aux 3 questions suivantes : Ce qui a été réalisé la veille. Ces prestations sont reportées sur un tableau Excel affiché au mur et qui permet de visualiser rapidement l'état d'avancement des différentes tâches. Ce qui est prévu pour le jour-même. Les difficultés rencontrées qui nécessite une intervention extérieure. En outre, des messages généraux peuvent être échangés lors de cette réunion : informations sur l'état de l'application. Un outil de build en continu produit, de manière quotidienne, différents indicateurs sur l'état du projet. Ces indicateurs sont : - le nombre d'incidents ouverts à traiter. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 72

- le nombre de tests unitaires qui ne sont pas déroulés correctement. - la part du code couvert par ces tests unitaires. - la qualité de la documentation technique (javadoc). communications du chef de projet 2) Au début de chaque Sprint, une réunion est organisée avec l'ensemble de l'équipe pour survoler le contenu du Sprint. Ensuite, c'est par "User Story" qu'est organisée une réunion avec uniquement les membres de l'équipe concernés par cette user story. Voir également le point «5.3.5. Difficultés et ajustements» à ce sujet. 3) A la fin de chaque Sprint, une réunion de révision du sprint est organisée pour revoir les points forts et les points faibles de l'organisation courante. A l'exception des premières fois où toute l'équipe a été réunie, ces réunions ne reprenaient que les personnes clés dans l'équipe. 4) Même si ceci n'est pas particulièrement lié à l'utilisation de SCRUM comme base pour la méthodologie de travail, la qualité de l'application est contrôlée en permanence par un outil de build en continu. L'utilisation d'un tel outil permet de réagir rapidement aux problèmes rencontrés. Dans notre cas, étant donné la taille de l'application et la durée d'un cycle complet de build, à chaque fois qu'un développeur publie du code, seule une compilation est réalisée qui dure de 15 à 30 minutes. A intervalle régulier (de 1 à 3 fois par jour en fonction des périodes du projet), un cycle complet de build (y compris l'exécution de tous les tests unitaires, des tests d'intégration automatisés et la construction des indicateurs du projet) est réalisé. Ce cycle dure environ 2 heures. 5.3.4 Les facteurs qui ont permis le succès de la méthode L'utilisation de SCRUM dans ce projet a été un succès, notamment grâce à : la disponibilité à plein temps d'un interlocuteur du client, ayant un niveau de connaissance élevé du métier de Sigedis et du milieu de la sécurité sociale belge, et disposant d un pouvoir de décision réel. La présence d un référentiel applicatif, à savoir le système à remplacer, comme base pour la validation du nouveau système. Des cycles de développement relativement courts permettant de limiter et d avoir une vision claire du périmètre des fonctionnalités à réaliser au cours de chaque itération, tant au niveau de leurs analyses qu au niveau de leurs mises en œuvres. Le feedback rapide des utilisateurs clés, permettant d intégrer rapidement les corrections et améliorations utiles dans des délais relativement courts. La visibilité permanente de l évolution du produit, permettant ainsi à chacun de juger de la bonne marche du projet. 5.3.5 Difficultés et ajustements Le contexte particulier d'un projet implique, la plupart du temps, de s'adapter à des contraintes et des situations particulières. 1) Une première difficulté rencontrée dans le cas présent a été le cadre forfaitaire pour la réalisation du projet. Ceci a eu pour implication, dans le chef du maître d œuvre, de contrôler de manière stricte le scope de l'application à réaliser, tout en faisant preuve de flexibilité pour permettre d'y inclure des demandes de changements par rapport au cahier des charges initial. Etant donné le nombre d'intervenant dans le chef du maître d'ouvrage, la gestion du scope des différentes versions de l'application a nécessité certains arbitrages "politiques" et a requis une certaine flexibilité dans l'élaboration et l'évolution des «sprint backlog». 2) Une deuxième difficulté a été le nombre de fonctions de l'application et la taille de l'équipe. Etant donné que l'équipe a compté jusqu'à 40 personnes, il aurait été ingérable de réunir l'entièreté de l'équipe pour la planification des différentes versions. Ainsi le choix des "user stories" faisant partie d'un sprint, de même que son estimation initiale en termes de charge de travail, n'était pas du ressort de l'équipe dans son ensemble mais seulement d'une partie de celle-ci. Afin de répartir et de suivre au mieux le travail sur chaque user story faisant partie d'un sprint, une proposition de répartition des ressources était également établie lors de la planification du sprint. Ainsi, pour chaque "User Story", une sous équipe était désignée au sein de l'équipe globale. Cette sous équipe était composée de : un analyste ayant une connaissance suffisante de la fonctionnalité à développer, un analyste-programmeur expérimenté ou architecte ayant pour responsabilité de coordonner les choix techniques dans le cadre de cette user story des programmeurs pour la réalisation technique. Un membre de l'équipe projet pouvait tout à fait être planifié sur plusieurs "User stories", en fonction de ses compétences, de ses affinités et de sa disponibilité. Chacune de ces sous équipes commençait, avant tout développement, par se réunir pour fixer les détails du développement : l'élaboration de la liste des tâches à réaliser. la révision des estimations faites lors de la planification du sprint. la répartition des tâches entre les différentes personnes. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 73

3) Une troisième difficulté était la trop grande spécialisation de la plupart des membres de l'équipe-projet. Trois grands types de profils s'y sont côtoyés, pas facilement interchangeables : analystes métier, techniciens (analystes-programmeurs, programmeurs et architectes) et testeurs. Ils interviennent à différents moments dans le cycle de développement d'une user story. Ainsi, pour permettre une occupation optimale de l'ensemble des personnes dans l'équipe, 2 sprints successifs se sont superposés d'une semaine. Par conséquent, lors de la dernière semaine d'un sprint, pendant que les testeurs étaient en plein tests de validation des user stories, les techniciens commençait déjà le travail de développement du sprint suivant, tout en assurant la correction des problèmes détectés lors des tests. Le gestionnaire de version des sources a été indispensable pour permettre le travail sur plusieurs versions en parallèle. 4) Enfin, une dernière difficulté rencontrée a été la durée nécessaire pour les tests de qualifications entre la livraison d'une version de l'application et sa mise en production. Cette durée (4 à 6 semaines) a parfois amené des problèmes, nécessitant des patches correctifs, à n'être détectés que très tard durant le sprint suivant. A nouveau, l'utilisation intelligente du gestionnaire de sources et la flexibilité dans la gestion du planning a permis de répondre aux situations urgentes. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 74

6 CONCLUSION Le choix d une méthode de développement de projet est parfois délicat. Certaines ont cependant fait leurs preuves et rencontrent un réel succès, tant chez les praticiens que chez les théoriciens. Mais le sujet est en perpétuelle étude et évolution car la marge de progrès est encore élevée sur le taux de réussite des projets informatique. Il suffit pour cela de comparer les benchmarks pour bien réaliser que cette science est encore jeune et ne peut donc par rivaliser avec les 3000 ans de pratique de celle du BTP par exemple A ce jour, les méthodes les plus reconnues sont celles décrites dans le présent ouvrage et pour lesquelles la société Aubay possède de réelles compétences. Concernant les référentiels Qualités d entreprise, leur mise en œuvre se rapproche d un projet au long court plus qu une épreuve laborieuse comme certains retours d expérience pourraient le laisser croire Mais leur certification est un passage obligé pour toute SSII qui souhaite prendre la responsabilité de Centres de Services, TMA ou autres projets au forfait. Cependant, il ne s agirait pas d oublier que le succès de toute entreprise conduite par des hommes repose essentiellement sur les valeurs intrinsèquement humaines des individus participants au projet et ce constat est particulièrement vrai pour le Chef de projet, dont les qualités de charisme, d enthousiasme, d esprit de décision, de rigueur et de négociation seront primordiales. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 75

7 DETAIL SUR LES PROCESSUS ITIL V2 7.1 Les processus du Soutien des Services Le Soutien des Services (Service Support) permet d'effectuer les opérations quotidiennes nécessaires au maintien et à l'amélioration de la qualité des services rendus aux utilisateurs. 7.1.1 Le Centre de Services (Service Desk) Le point d'entrée unique (encore appelé Guichet Unique) de la production informatique est le Centre de Services ou Service Desk. Le Centre de Services est le point de contact unique entre les différents acteurs opérationnel : clients, utilisateurs, équipes de production et organisations tierces (sociétés de sous-traitance ou d'externalisation). Il s'agit d'une fonction et non d'un processus. Elle est stratégique dans l'entreprise car elle est probablement la fonction la plus importante dans l organisation de la production informatique. Le Centre de Services est la seule composante visible dans l'entreprise du niveau de service et du professionnalisme d une organisation (en termes de perception et de satisfaction clients). Différences de terminologies : Le Centre d Appels (ou Call Center) permet la gestion d'un volume très important d appels téléphoniques, Le Centre de Support (ou Help Desk) permet la gestion, la coordination et la résolution des dysfonctionnements utilisateurs aussi rapidement que possible, Le Centre de Services (ou Service Desk) s'étend à toutes les demandes de la production informatique et effectue une approche client globale en intégrant l'ensemble de ses demandes. En arrière-plan du Centre de Services, se trouvent les activités opérationnelles de la production informatique. 7.1.2 La Gestion des Incidents (Incident Management) Un incident est un événement qui ne fait pas partie du fonctionnement standard d'un service et qui cause, ou peut causer, une interruption ou une diminution de la qualité de ce service. Figure 46 : Cycle de vie d un incident L'objectif de la Gestion des Incidents est de : restaurer aussi vite que possible le fonctionnement normal des services, minimiser l impact négatif sur les activités métiers, s assurer ainsi que les meilleurs niveaux de qualité de service et de disponibilité sont maintenus. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 76

Figure 47 : Processus de gestion des incidents Les rôles du Centre de Services dans la Gestion des Incidents sont : tous les incidents doivent être remontés vers le Centre de Services et doivent être enregistrés par celui-ci (y compris les remontées automatiques), la majorité des incidents (jusqu à 85%) doivent être résolus par le Centre de Services, le Centre de Services constitue une fonction indépendante de suivi de l ensemble des incidents jusqu à leur résolution complète, le Centre de Services effectue la coordination des équipes de support intervenant dans la résolution des incidents. 7.1.3 La Gestion des Problèmes (Problem Management) Un incident est la conséquence d échecs ou d erreurs de traitement dans l infrastructure informatique. La cause d un incident peut être évidente et éradiquée directement par le Centre de Services sans investigation complémentaire. Quand la cause sous-jacente d un incident n est pas connue, il est nécessaire d'initialiser un problème dans le processus de Gestion des Problèmes. Un problème est ainsi le signe d une erreur inconnue dans l infrastructure. Plusieurs incidents peuvent sembler partager la même origine donnant lieu à la définition d un problème unique. Un problème est indépendant des incidents qui lui sont associés. L analyse du problème peut continuer même si les incidents ont été résolus et fermés. La résolution d un problème consiste en l'identification de l erreur sous-jacente et en la mise au point d une solution de contournement ou l'émission d une demande de changement. Le problème devient alors une erreur connue. Définitions : un problème est la cause inconnue d'un ou plusieurs incidents. une erreur connue est un problème diagnostiqué correctement et pour lequel soit une solution de contournement existe, soit une demande de changement a été émise. une demande de changement est une demande d ajout, de modification, d évolution ou de suppression de composants de l infrastructure informatique ou pour tout autre aspect de la production informatique. Les interactions entre les processus de Gestion des Incidents et de Gestion des Problèmes sont complexes mais il est nécessaire de les maîtriser afin de bien séparer ces deux processus dont les finalités sont très différentes. L'objectif de la Gestion des Problèmes est de : minimiser l impact négatif sur les activités de l entreprise, des incidents et problèmes causés par des erreurs dans l infrastructure informatique, prévenir la réapparition des incidents induits par ces erreurs. Pour cela, la Gestion des Problèmes recherche la cause première des incidents et initie des actions d'amélioration ou correction de la situation. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 77

Figure 48 : Processus de gestion des problèmes 7.1.4 La Gestion des Changements (Change Management) Un Changement est un processus permettant une transition d un état stable vers un nouvel état stable en optimisant l exposition aux risques, l impact et la sévérité des dysfonctionnements consécutifs à l implémentation de ce changement. L'objectif de la Gestion des Changements est de s assurer que des méthodes et procédures standards sont utilisées pour une prise en main efficace et rapide de tous les changements. Le but est de minimiser l impact des incidents consécutifs à l implémentation de ces changements et, par conséquent, d améliorer l exploitation quotidienne. Lorsqu'un changement est rendu nécessaire, il faut évaluer les risques de sa mise en œuvre et la continuité de l activité métier pendant et après cette mise en œuvre. L'approbation des changements se fait au cours d'un Comité Consultatif des Changements (Change Advisory Board ou CAB). Le CAB constitue l autorité de décision permettant d'approuver une Demande de Changement (ou Request for Change ou RFC), sauf en cas de changement mineur. Il est constitué des représentants de la plupart des autres fonctions de l entreprise. La Gestion des Configurations doit s assurer que toutes les informations de configuration sont fournies (impacts possibles détectés et présentés correctement). Figure 49 : Processus de gestion des changements Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 78

Les processus de Gestion des Changements, des Configurations et des Nouvelles Versions sont étroitement liés. La Gestion des Changements ne comprend pas : l'identification des composants de l infrastructure impactés par un changement (Gestion des Configurations), le déploiement et la mise à disposition aux utilisateurs des modifications et ajouts de composants (Gestion de Nouvelles Versions). 7.1.5 La Gestion des Mises en Production (Release Management) L'objectif de la Gestion des Mises en Production est de protéger l environnement de production et ses services, par : l utilisation de procédures formelles, des vérifications lors de l implémentation des changements. Les changements sont intégrés dans les Distributions et implémentés en production lors de Déploiements. La Gestion des Mises en Production permet : de planifier et superviser le déploiement d un logiciel et du matériel associé, d'élaborer et implémenter les outils de distribution et d installation des changements, de s assurer que les matériels et logiciels changés sont traçables, sûrs et que seules les versions correctes, autorisées et testées sont installées, de communiquer et de gérer les attentes des clients pendant la planification et le déroulement des déploiements, de valider le contenu exact d une distribution et le scénario de déploiement en liaison avec la Gestion des Changements, d installer les nouvelles versions logicielles et les matériels en production en respectant les procédures de la Gestion des Changements et des Configurations, de s assurer que les distributions d origine de tous les logiciels sont stockées et sécurisées dans la Bibliothèque des Versions Logicielles Définitives (Definitive Software Library ou DSL) et que la base de données des configurations (Configuration Management DataBase ou CMDB) est mise à jour (cf. Gestion des Configurations). 7.1.6 La Gestion des Configurations (Configuration Management) La Gestion des Configurations fournit un modèle logique de l infrastructure informatique en identifiant, contrôlant, maintenant et vérifiant les différents éléments au cours de leur durée de vie. Les objectifs pratiques de la Gestion des Configurations sont les suivants : rendre compte à l organisation de tous les biens et configurations de la Production Informatique, fournir une information pertinente sur les configurations pour le support des autres processus, fournir des bases solides pour la Gestion des Incidents, des Problèmes, des Changements et des Nouvelles Versions, comparer l information stockée à l infrastructure et corriger les différences. Le rôle de la Gestion des Configurations est l'identification, l'enregistrement et la restitution de l information sur tous les composants de l infrastructure informatique. Le périmètre intègre : les matériels, les logiciels et applications, les documentations associées. La gestion des composants inclut leurs versions, leurs sous-composants ainsi que les interrelations entre eux. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 79

Figure 50 : Processus de gestion des configurations 7.2 Les processus de Fourniture des Services La Fourniture des Services (Service Delivery) permet d'effectuer le suivi des contrats de services passés avec les utilisateurs, de gérer toutes les actions relatives aux problématiques globales (tous les contrats de service) et transversales (toutes les équipes techniques de la production informatique). 7.2.1 La Gestion des Niveaux de Service (Service Level Management ou SLM) La Gestion des Niveaux de Service est indispensable pour : permettre à toute organisation des systèmes d'information de déterminer le niveau de service à délivrer pour supporter les métiers de l entreprise, initialiser un suivi permettant d'identifier si les niveaux de services demandés ont été atteints ou non et, si non, pourquoi. Le but de la Gestion des Niveaux de Services est de maintenir et améliorer la qualité de service des systèmes d'information au travers d'un cycle permanent d accords. Ces accords sont agrémentés de suivis et de reporting sur l atteinte des objectifs et sur les actions menées pour éradiquer la mauvaise qualité (support des métiers ou justification des coûts). Une meilleure relation entre la DSI et services métiers peut être développée à partir de la gestion de ces accords. Le périmètre de la Gestion des Niveaux de Service contient : la préparation, la coordination, la rédaction, la signature, le suivi et le reporting de ces accords, la revue permanente de l atteinte des objectifs pour s assurer que la qualité de service requise et budgétairement justifiable est maintenue et améliorée progressivement. Les Accords de Niveaux de Services (Service Level Agreements ou SLA) définissent des objectifs spécifiques sur lesquels les performances de l organisation des systèmes d'information peuvent être jugées. Les SLA portent sur tous les services fournis par les systèmes d'information. Les contrats sous-jacents ou Contrats de Sous-Traitance (Underpinning contracts ou UC) et les Accords de Niveaux Opérationnels (Operational Level Agreements ou OLA) concernent tous les fournisseurs internes et externes. L'Accord de Niveau de Service est un accord signé entre le fournisseur de services (systèmes d'information) et le client. Il définit les objectifs et les responsabilités des deux parties. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 80

Figure 51 : Relation entre les clients et la gestion des niveaux de service 7.2.2 La Gestion Financière des services des TI (IT Services Financial Management) La gestion financière des services informatiques a pour but la mise en place de processus budgétaires et comptables, voire de processus de refacturation clients, afin de justifier les coûts de fonctionnement et de mise en œuvre de Services. La gestion financière dans une entreprise supporte l organisation en planifiant et en mettant en œuvre les objectifs métiers. Pour une Production Informatique, cela se concrétise avec trois processus principaux : la budgétisation, la comptabilité, la facturation. Le processus de budgétisation Il s'agit d'un processus de prévision et de contrôle des dépenses dans une organisation : un cycle périodique de négociation pour définir les budgets (généralement annuels), un suivi quotidien de ces budgets. Le but de la Budgétisation est de s assurer que les coûts réels correspondent aux coûts prévisionnels. Les budgets sont, en général, issus de négociations à grosses mailles: les services métiers allouent des budgets informatiques proportionnels à leur budgets de fonctionnement et ce, souvent en fonction des indications de coût de la Production Informatique. Par la suite, il est important, pour les services métiers, de déterminer à quelle hauteur les budgets informatiques seront consommés avant la fin de la période et de prendre les bonnes décisions pour gérer au mieux ces budgets. Le processus de comptabilité Il s'agit d'un ensemble de processus permettant à la Production Informatique de comptabiliser la manière dont sont dépensés les budgets (ventilation par clients, par services ou par activités). Certaines organisations (comme dans le cas de l'externalisation de la production) doivent mettre en place de véritables processus comptables pour leurs ressources informatiques. La comptabilité des SI peut être utilisée pour connaître la consommation exacte de CPU, d'espace-disque et de bande passante mais il n est pas recommandé d'utiliser ces critères comme base de refacturation pour les clients car le coût de ce service comptable reste prohibitif. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 81

Il est de l intérêt de toutes les parties de définir un coût minimum de gestion comptable et de mettre en place le système de refacturation le plus simple possible même si cela doit se faire aux dépens de la précision absolue. Une pratique courante consiste à utiliser la comptabilité des SI pour : aider les investissements et les décisions de renouvellements, identifier les comptabilisations improductives (dont le coût de mesure est supérieur au coût de refacturation) en les remplaçant par des coûts fixés pour une Capacité donnée, Cette Capacité peut être déterminée par les Accords de Niveaux de Service (SLA) et le suivi des coûts des Services ainsi globalisés. Le processus de facturation Il s'agit d'un ensemble de processus nécessaires pour refacturer aux clients le coût des services qu ils utilisent. La refacturation est souvent effectuée sur une base périodique (par exemple, 1/12 ème de la facturation chaque mois). Des facturations complémentaires peuvent être réalisées sur des services situés en dehors des Accords (par exemple : déménagements, déploiement majeur, mise à niveau système imprévue, etc. ). 7.2.3 La Gestion de la Disponibilité (Availability Management) L'objectif de la gestion de la disponibilité est d'optimiser la capacité de l infrastructure informatique, des services et de l organisation de support, pour délivrer la Disponibilité adéquate (niveau suffisant et coût optimisé) permettant aux activités métiers de satisfaire leurs objectifs. En comparant les besoins et la capacité réelle, la Gestion de la Disponibilité permet de : s assurer que les services des SI sont définis pour délivrer les niveaux de disponibilité requis par les métiers, fournir des rapports sur la disponibilité, la fiabilité et la maintenabilité, optimiser la disponibilité de l infrastructure en termes de coût, diminuer durablement la fréquence et la durée des incidents ayant un impact sur la disponibilité, s assurer que les petites interruptions de disponibilité soient identifiées et éradiquées, créer et maintenir un plan prévisionnel pour améliorer globalement la disponibilité afin d anticiper les besoins métiers futurs sur les aspects de disponibilité. Périmètre La gestion de la disponibilité devrait s appliquer à : tout nouveau service ou service en cours ayant des besoins définis en Disponibilité ou étant liés à des activités métiers critiques (SLA en place ou non), tous les fournisseurs (internes et externes) avant la mise en place de SLA formels. Cependant, ce processus n'est pas responsable du Plan de Continuité Métiers (Business Continuity Plan) et du rétablissement des activités métiers en cas de désastre majeur (cf. Gestion de la Continuité). Concepts de base La Disponibilité fournie par les services informatiques dépend de : la complexité des SI, la fiabilité des composants et de l environnement des SI, la capacité du support informatique à gérer l infrastructure, du niveau et de la qualité de la maintenance apportés par les fournisseurs, la qualité des procédures et processus opérationnels. Les niveaux de disponibilité sont généralement précisés dans les Accords de Niveaux de Service (SLA). Trois principes fondamentaux sous-tendent la gestion de la disponibilité des services informatiques : Principe n 1 : Principe n 2 : La disponibilité est au cœur de la satisfaction des utilisateurs et des métiers. Reconnaître que même si les choses se passent mal, il est encore possible d obtenir la satisfaction des utilisateurs. Pendant une interruption de service, le niveau de satisfaction des utilisateurs ne dépend pas seulement de la rapidité de redémarrage. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 82

Les organisations métiers et les utilisateurs ont des besoins diversifiés en terme de services informatiques (et pas uniquement la rapidité de redémarrage du service). C'est pourquoi c'est l ensemble de ces besoins qui doivent être traités. Principe n 3 : L amélioration de la disponibilité ne peut débuter que lorsque l on a compris comment les services des SI supportent les activités métiers. En effet, l analyse doit porter sur l'ensemble des transactions métiers et non pas sur chacun des composants techniques utilisés par ces transactions. Terminologie Disponibilité C'est la capacité pour un service ou un composant SI à remplir sa fonction à un instant donné ou sur une période de temps prédéterminée. Fiabilité La fiabilité d un service peut être définie comme étant son indépendance vis-à-vis des dysfonctionnements opérationnels. Elle est déterminée par : la fiabilité de chacun des composants utilisés pour délivrer le service, le niveau de redondance (ou resilience) de l infrastructure, c est-à-dire la capacité de l infrastructure à masquer le dysfonctionnement d un composant et à continuer à délivrer le service normalement. Maintenabilité C'est la capacité d un composant de l infrastructure à rester, ou à être restauré, dans un état opérationnel. La maintenabilité peut être divisé en 7 étapes séparées : l anticipation des pannes, la détection des pannes, le diagnostic des pannes, la résolution des pannes, le redémarrage après panne, la restauration des données et des services, les niveaux de maintenance préventive permettant d éviter l apparition des pannes. "Serviçabilité" (ou serviceability) Il s'agit d'un concept qui décrit les accords contractuels signés avec les fournisseurs tiers de la DSI et définissant la disponibilité, la fiabilité et la maintenabilité des composants et services des SI sous leur responsabilité. Figure 52 : Processus de gestion de la disponibilité Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 83

7.2.4 La Gestion de la Continuité des Services des TI (IT Service Continuity Management) La Gestion de la Continuité des Services Informatiques a pour objectif de permettre à la DSI d'être capable, lors d une interruption importante des activités (métiers et/ou informatiques), de continuer à fournir un niveau prédéterminé et accepté de services pour soutenir les activités métiers critiques. Le but est de permettre aux activités métiers de ne pas perdre d argent ou, en cas d interruption très importante, de permettre à l entreprise de survivre tout simplement. La Gestion de la Continuité des Services Informatiques concerne l entreprise dans sa globalité et dépasse le cadre de la DSI seule. Pour l'entreprise, le Plan d Urgence (ou Contingency Planning) ou encore la Gestion de la Continuité Métiers (ou BCM ou Business Continuity Management) prévoit tous les scénarios de reprise de chacune des activités. En mettant en œuvre, au niveau des métiers, le Plan de Continuité Métiers (Business Continuity Planning), et au niveau des services informatiques, le Plan de Gestion de la Continuité des Services (IT Service Continuity Management Planning). Concepts de base Les activités métiers sont de plus en plus dépendantes des services fournis par la DSI. La disponibilité des services (Gestion de la Disponibilité) met en place et gère des technologies permettant de diminuer les risques (redondance du matériel, politique de sauvegarde/restauration, etc ). La Gestion de la Continuité des Services s appuie sur la Gestion de la Disponibilité des services (ainsi que d autres processus) et nécessite l implication non seulement de la Direction de l entreprise mais aussi de tous les niveaux hiérarchiques. Des tests réguliers doivent être effectués afin de vérifier la coordination de l ensemble des techniques prévues concernant une interruption importante. Bénéfices : la gestion des risques La Gestion de la Continuité doit être considérée comme une assurance couvrant des risques prédéterminés. Cela permet à une entreprise d identifier, d analyser et de prendre ses responsabilités face à une éventuelle concrétisation de l un de ces risques. La DSI peut gérer de manière proactive son infrastructure afin de réduire l impact du dysfonctionnement de l'un de ses éléments (depuis un composant à l'ensemble d'un site). La DSI peut aussi, au travers de la Gestion de la Continuité, contribuer à la création de valeurs : Diminution potentielle des primes d assurance, Obligations de régulation, Relations poussées avec les organisations métiers, Marketing positif sur les capacités de reprise en cas de sinistre majeur. 7.2.5 La Gestion de la Capacité (Capacity Management) La Gestion de la Capacité a la responsabilité d assurer que la Capacité de l infrastructure des SI est en adéquation avec les demandes croissantes des organisations métiers (coûts et performances). Le processus comprend : le suivi des performances et des débits des services et des composants de l infrastructure, les activités d optimisation (tuning) de l utilisation des ressources existantes, la compréhension des demandes actuelles en ressources informatiques et la production de prévisions pour les demandes à venir, l influence sur les demandes de ressources, en collaboration avec le processus de Gestion Financière des Services, la production d un Plan de Capacité permettant d'assurer la qualité des Services fournis. Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 84

La Gestion de la Capacité est une question d'équilibre La Capacité achetée par une DSI se justifie en termes de besoins métiers ET doit être utilisée de manière optimale. La puissance informatique correspond à la demande métier (actuelle et à venir). Demande métier qui peut influencer la demande sur une ressource informatique particulière. La Gestion de la Capacité fournit aux organisations informatiques les données nécessaires pour leur permettre de décider : la nature des composants à remplacer (CPU, espace disque, bande passante, ), le moment idéal de leur remplacement (trop tôt induit un surcoût du à la sur capacité, trop tard induit des défauts de performance et génère l'insatisfaction des utilisateurs), le coût de leur remplacement (données prévisionnelles financières destinées à l établissement des budgets informatiques). Le gestionnaire de capacité devra s assurer en permanence : qu il existe toujours de la capacité informatique disponible et justifiable financièrement, que cette capacité soit toujours ajustée aux besoins métiers présents et à venir, que la puissance et la performance de l infrastructure informatique actuelle et future sont fournies de manière rentable. Pour cela, le gestionnaire de capacité analysera : les besoins métiers (la fourniture de services demandée), le fonctionnement de la DSI (la fourniture de services actuelle), l infrastructure informatique (les moyens de fournir les services). Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 85

8 REFERENCES BIBLIOGRAPHIQUES [1] CIGREF Ouvrage «Les référentiels de la DSI» - octobre 2009 [2] Jeffrey Liker Le modèle Toyota : 14 principes qui feront la réussite de votre entreprise [3] Institut de l audit interne Audit des projets informatiques [4] C. Chevallier Cours sur la conduite de projet [5] Anne Marie Hugues Cours sur le Génie Logiciel [6] Master ISIL - ESTI Cours Méthodologies de Développement [7] Gauthier Picard Introduction à l extreme Programming [8] F. Miller extreme Programming, vers plus d agilité [9] Decostre Alain et Ducochez Clément Le processus unifié (UP) [10] Cours du CNAM (F. Di Gallo) Méthodologie UML Sites internet : http://agile.thierrycros.net. http://dszalkowski.free.fr http://www.dsi.cnrs.fr/conduite-projet. http://www.techno-science.net http://www.jerome.capirossi.org/prj_mgt/cycle_10.htm http://www.rad.fr/ http://sabricole.ftp-developpez.com/up.pdf http://www.guideinformatique.com/fiche-itil_v3-831.htm http://itilfrance.com/ Wikipedia : http://fr.wikipedia.org/wiki/information_technology_infrastructure_library#bibliographie http://fr.wikipedia.org/wiki/extreme_programming http://fr.wikipedia.org/wiki/scrum_%28m%c3%a9thode%29 http://fr.wikipedia.org/wiki/rational_unified_process Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 86

9 ACRONYMES BB BSC CAPEX CMMI COBIT COCOMO COPIL DSI ISO ITIL JAT KPI MBB MOA MOE OBS OPEX PBS PMI PMO POS QoS RAD RBS RUP SI SOX SSII SWOT TJM TPS WBS XP Black Belt Balanced Score Card capital expenditure ou dépenses d investissement Capability Maturity Model Integration Control Objectives for Information and related Technology Constructive Cost Model Comité de Pilotage Direction des Systèmes d Information (ou service informatique) International Organization of Standardization Information Technology Infrastructure Library Juste A Temps (JIT = Just in time) Key Performance Indicator Master Black Belt Maitrise d Ouvrage Maitrise d Œuvre Organization Breakdown Structure operational expenditure ou dépenses de fonctionnement Product Breakdown Structure Project Management Institut Project Management Office Plan d Occupation des Sols Quality of Service Rapid Application Development Resources Breakdown Structure Rational Unified Process Système d Information Sarbanes-Oxley Société de services en ingénierie informatique Strengths (force), Weaknesses (faiblesses), Opportunities (opportunités), Threats (menaces). Taux Journalier Moyen Toyota Production System Work Breakdown Structure Extreme Programming 2011 AUBAY. Tous droits réservés Livre Blanc Aubay - Référentiels Qualité et Gestion de Projet - 87