dossier : Management de projets Audit de projets informatiques Daniel Mahé, Manager ASK Conseil Daniel Mahé est un expert du pilotage de projet. Il a participé aux travaux européens en prélude à la rédaction de Riskman sur la prévention des risques projet dans les années 1990. En 2002-2003, Daniel Mahé a animé un groupe de travail * sur le thème " audit des projets informatiques ". Nous résumons ci-dessous certains des aspects essentiels de la publication qui a couronné les travaux du groupe. Lors d’un récent petit-déjeuner organisé par l’AFAI et 01 Informatique sur ce sujet, il était rapidement apparu une fracture entre deux conceptions de l’audit. Les auditeurs faisaient en général prévaloir la nécessité de maintenir une distance entre les deux fonctions, l’audit et la conduite de projet elle-même. Ceci peut être mal interprété par l’équipe de projet qui privilégierait au contraire une attitude participative, voire une intégration de la dimension audit dans leurs pratiques, un peu comme une gestion des risques. Nous avons tenté de trancher ce dilemme en proposant plusieurs options et sans éliminer celle qui intégrerait des auditeurs dans l’équipe de projet. Les projets informatiques Les projets Qu’est-ce qu’un projet ? La norme ISO 10006 version 1997 présente un projet comme « un processus unique qui consiste en un ensemble d’activités coordonnées et maîtrisées comportant des dates de début et de fin, entrepris dans le but d’atteindre un objectif conforme à des exigences spécifiques, incluant les contraintes de délais, de coût et de ressources ». Elle précise en outre : • qu’il est possible qu’un projet individuel fasse partie d’une structure de projet plus large, • que dans certains projets, les objectifs sont affinés et les caractéristiques du produit déterminées progressivement, à mesure que le projet progresse, • La revue n° 76 - Juillet 2004 • qu’un projet peut aboutir à une ou plusieurs unités de produits, 4 • qu’une organisation est déployée temporairement sur la durée du projet, • que les interactions entre activités au sein du projet peuvent être complexes. Un projet n’est ni une activité répétitive, ni une mission permanente. Cependant cette approche s’applique également à toute évolution des produits issus des projets dès lors qu’elle est conduite en mode projet en identifiant comme le précise la définition ci-dessus objectifs, contraintes de délais, de coûts et de ressources. Constat sur les projets informatiques Les projets de systèmes d’information possèdent des caractéristiques spécifiques, qui les distinguent intrinsèquement des autres types de projets : • forte obsolescence des composants : les versions des logiciels intégrés et des composants produits peuvent se succéder rapidement au cours même du projet, • logiciels non fiables : nous sommes en ce domaine très loin du zéro défaut et les techniques de prévention et de contrôle des défauts sont très inégalement maîtrisées, • complexité récursive et combinatoire des algorithmes employés et des structures de données manipulées, • interposition de l’informaticien entre le métier et l’utilisateur, ce qui peut entraîner un problème de légitimité voire de pouvoir, • fluctuations des interfaces et des fonctionnalités dues aux changements d’organisation et à l’évolution des systèmes qui environnent le produit. Un projet informatique est souvent vécu par ses acteurs principaux comme un cas inédit en raison des innovations Managements de projets dossier dans les technologies, de la nouveauté (partielle) du sujet abordé et des changements du mode d’organisation ou du contexte. Aussi, les références ou procédures standard ne sont pas toujours employées ; développer un logiciel s'apparente alors plus à une activité de recherche qu'à une fonction répétitive. Le cahier des charges n'est presque jamais complet et figé au lancement du projet : il s'élabore et s'adapte à mesure de l'avancement du projet parce que les systèmes informatiques sont aujourd’hui trop complexes pour pouvoir être totalement prédéfinis et parce que les réalités et les contraintes des technologies informatiques ne peuvent être complètement maîtrisées par les décideurs et maîtres d’ouvrage. Les projets itératifs À la différence des développements classiques en V ou incrémentaux, les projets de type IAD (Interactive Application Developement ) veulent produire rapidement des résultats, mêmes partiels, sous forme de modules ou de versions successives du produit. En matière de projets informatiques, un constat s’est imposé à tous : il ne suffit pas de mettre de l'argent et de la technique ; plus qu'ailleurs la qualité et la motivation des hommes sont prépondérantes. De plus, les projets accompagnent souvent ou provoquent des réorganisations et changements dans les processus métiers. De ce fait, en cas de difficultés, les ressentiments se cristallisent sur la partie visible du changement, le projet informatique, alors qu’il n’est que la conséquence d’une décision stratégique. • les bénéfices et gains réels apportés aux utilisateurs par l’emploi du logiciel, • la contribution directe à l’efficacité et à la valeur de l’entreprise que peut représenter un système d’informations performant et innovant. La diversité des projets informatiques Par projet informatique, on entend communément les deux grands classiques du métier : • les développements purs de logiciels complets ou de composants, • les évolutions importantes des projets de maintenance. Mais, aujourd’hui, d’autres types de projets apparaissent, qui peuvent souvent, dans les directions et les services informatiques, être en plus grand nombre que les développements classiques, par exemple : Cette liste de types de projets informatiques n’est pas exhaustive, on pourrait aussi citer : • les portages d’application, • les projets d’externalisation, • les déploiements, • les projets d’expérimentation, • … Différents contextes peuvent induire ce besoin : un impératif de délai pour une partie du système, des incertitudes au démarrage du projet portant sur des exigences fonctionnelles, sur une partie de l’environnement utilisateur, sur des solutions techniques… Les projets de mise en place de progiciel Dans un projet à base de progiciel, le sens donné aux différentes phases et leur contenu sont différents de ceux des projets de développements spécifiques : • l’orientation vers une solution à base de progiciel est d’ordre stratégique. Sa faisabilité est confirmée en phase d’avant-projet, • la conception générale prend un sens différent dans la mesure où le produit est pré-conçu : ce sont la consultation et le choix du couple progiciel-intégrateur qui prennent le pas, • la réalisation correspond au paramétrage du produit et au développement des outils périphériques. Elle s’appuie sur la méthodologie d’implémentation du progiciel et sa mise en pratique par l’intégrateur. Les projets d’infrastructure Dans un projet d’infrastructure, la difficulté consiste à bien identifier le commanditaire qui ne représente pas toujours les utilisateurs terminaux. En outre le déploiement est souvent une opération particulièrement délicate. Le cas particulier des grands programmes La notion de programme est habituellement employée pour caractériser un niveau de complexité supérieur à celui des projets courants : un programme n’est pas seulement un projet particulièrement important ou complexe, mais relève d’un développement de l’entreprise qui entraîne des changements dans les processus métier, des évolutions du périmètre initial, et dont l’ampleur traverse plusieurs frontières de filières métier. L’audit des programmes en tant que tel ne sera pas abordé dans cet ouvrage. • La revue n° 76 - Juillet 2004 Il est donc aujourd’hui facile de ne considérer les projets qu’à travers les résultats d’enquêtes qui en montrent, chaque année, les dérives et les insuccès. L’auditeur ne pourra se satisfaire de ces constats généraux et se posera continuellement la problématique de la définition des critères de succès d’un projet informatique. La tenue d’objectifs de délais, de coûts et de qualité en est-elle le seul garant, alors que les méthodes et techniques de fixation d’objectifs en ce domaine (estimation prévisionnelle des développements) sont connues comme peu précises et difficiles d’emploi sur des technologies en mouvement, et alors que l’environnement de réalisation des projets est souvent instable. L’auditeur peut aussi considérer deux critères essentiels de succès d’un projet : 5 dossier :Managements de projets Deux caractéristiques essentielles des projets informatiques Projets et risques Les projets informatiques sont aussi, et certains diront surtout, caractérisés par des risques. Projets et maturité des organisations Au-delà du type de projet mené, l’auditeur tiendra également compte du degré de maturité de l’organisation qui conditionne le mode de gestion et les possibilités réelles d’un projet. Un risque projet est un événement dont l'apparition n'est pas certaine et dont la manifestation est susceptible d'engendrer des dommages sur le projet ou en dehors du projet. Les risques sont nombreux et peuvent être classés en grandes catégories : • risques liés à l’environnement du projet, • risques liés à l’alignement des objectifs du projet sur la stratégie de l’entreprise, • risques liés à la méthodologie de gestion de projet : planning, monitoring, qualité…, • risques liés à la solution mise en place : élaboration, développement, test, migration, implémentation…, • risques liés aux ressources humaines : gestion du changement, communication, formation… • Niveau initial : Le processus est caractérisé par la prédominance d'interventions ponctuelles, voire chaotiques. Peu de procédures sont définies et la réussite dépend de l'effort individuel. • Niveau reproductible : Une gestion de projet élémentaire est définie pour assurer le suivi des coûts, des délais et des fonctionnalités du produit. Une discipline minimale sur les processus est en place permettant de capitaliser les réussites de projets d'un même domaine d'application. • Niveau défini : Les processus de gestion et d'ingénierie sont documentés, normalisés et intégrés dans le processus standard de l'organisation. Tout nouveau projet de développement ou de maintenance fait intervenir une version adaptée et approuvée du processus standard de l'organisation. • Niveau maîtrisé : Des mesures détaillées sont faites en ce qui concerne le déroulement du projet et la qualité des produits. Le processus et le niveau de qualité des produits sont connus et contrôlés quantitativement. • Niveau d'optimisation : Une amélioration continue du processus est mise en œuvre par une rétroaction quantitative émanant du processus lui-même et par l'application d'idées et de technologies innovatrices. • La revue n° 76 - Juillet 2004 Extrait du Modèle d'évolution des capacités logiciel 6 Les approches du type CMM (Capability Maturity Model) permettent d’évaluer et de situer le cadre d’exécution d’un projet, parmi cinq niveaux. L’auditeur peut tirer profit de la lecture, voire de la maîtrise du « Questionnaire sur la maturité du processus logiciel » diffusé par le Software Engineering Institute, pour : Il est impossible d’établir a priori une liste exhaustive des risques potentiels que l’auditeur doit surveiller ou contrôler, il n’existe pas non plus d’approche ou de technique déterministe d’identification des risques, lui permettant de les recenser sur un projet. L’auditeur est cependant amené à examiner les risques d’un projet et les moyens employés pour les maîtriser. Il n’appartient pas à la mission d’audit, le plus couramment, de refaire une analyse contradictoire des risques, mais plutôt d’examiner la qualité de la gestion des risques. Il aura alors à réaliser des tâches très similaires à celles qui sont recommandées par les différentes approches de gestion des risques : Identification du risque Recherche des risques et identification de ses causes (facteurs) et conséquences L’audit valide ou construit le portefeuille de risques du projet Évaluation du risque Estimation de sa criticité : importance en termes de probabilité d’apparition et d’impact (financiers, délais, qualité, …) L’audit expertise ou calcule la criticité relative ou absolue de chaque risque Recherche des moyens de réduction Solutions de prévention, contournements, transfert et de surveillance. L’audit examine ou émet les recommandations proposant une solution optimale dans le contexte du projet L’audit de projet est, pour l’organisation, un moyen de s’assurer que les risques liés à un projet sont maîtrisés. Le cas échéant, les recommandations d’audit permettent de sécuriser le projet. En bref • s’approprier les concepts qui sous-tendent la notion de maturité dans une organisation, L’auditeur peut, au cours de sa carrière, être confronté à des projets très dissemblables, chacun d’eux étant unique par son objet, les procédures et méthodes utilisées ainsi que son contexte et environnement. • mieux cerner les spécificités d’un projet et les situer clairement par rapport aux apports et contraintes de son environnement. Cette diversité de projets peut : • entraîner des besoins en compétences ponctuelles lors d’un audit. L’auditeur peut donc être amené à faire appel Managements de projets dossier Fin étude Fin spéc. préalable Tech. Fin Recette Fin Projet Qualité du produit Qualité de l’expression des besoins (Cahier des charges) *** Conformité de la définition de la solution (Spécifications) par rapport aux besoins exprimés Complétude des livrables du projet par rapport aux besoins *** Adéquation des choix techniques par rapport aux besoins * Qualité de la solution technique Maîtrise de l’intégration dans l’ensemble du SI * * * *** * *** * *** * * * * * Utilisabilité de la solution *** Adéquation des dispositifs Sécurité prévus • influer aussi sur les règles et procédures de l’audit : L’auditeur adaptera son savoir-faire et sa démarche à la spécificité de chaque cas rencontré. *** Qualité de la documentation fournie * * *** Conformité des processus projet aux procédures et standards applicables Qualité du management du projet Qualité du management des ressources humaines dans le projet Qualité de la maîtrise du besoin par le projet * Conclusion * * * * * * * * * Maîtrise des coûts par le projet * * Maîtrise des délais par le projet * * * * * *** * Conformité des choix techniques avec la stratégie informatique L’ouvrage traite de multiples autres facettes dont il est impossible de rendre compte ici, comme, par exemple, l’organisation de l’audit, les modèles de mesure, les compétences nécessaires aux auditeurs. Une très volumineuse bibliographie servira les lecteurs dans le dédale des publications autour des projets informatiques et des standards. * Qualité du management de la communication du projet Qualité de la gestion des risques sur le projet Le tableau ci-contre représente les objectifs possibles de l’audit en fonction de l’état d’avancement du projet (entre * facultatif et *** indispensable). Il apparaît ainsi que certaines phases du projet nécessitent impérativement un audit ou au moins la prise de conscience que, en passant outre, on décide implicitement du GO/NOGO qui serait un des résultats de l’audit. Mais les grands principes d’audit de projet décrits dans ce guide demeurent identiques et pourront être appliqués par l’auditeur quelle que soit la nature du projet audité. * Conduite de projet Opportunité du projet (en phase préalable) à des expertises, puisqu’il ne pourra probablement pas maîtriser seul l’étendue des domaines techniques ou métiers des projets informatiques, Maîtrise des technologies et outils employés par ce projet * Qualité du management des soustraitants et des approvisionnements * * Maîtrise des processus de Vérification & Validation * Maîtrise du produit par le projet * Maîtrise du déploiement par le projet *** Qualité de la communication du projet * Maîtrise de la conduite du changement par le projet *** Qualité des dispositifs prévus pour prendre en charge la fin du projet *** Adéquation des compétences affectées * *** Maîtrise des conditions de succès par le projet * * * Composition du groupe de travail AFAI " audit des projets informatiques " : Annick Cavalin, Christian Masson, Frédéric Fichot, Frédéric Vert, Michel Le Goff, Jean-Michel Sarda, Sébastien Albert. * • La revue n° 76 - Juillet 2004 Objectifs 7