Dans la banque, comme dans l’industrie ou les armées, tout projet informatique est vecteur de risques. Les directions générales des établissements bancaires s’emploient fort justement à garder la maîtrise des conséquences des risques portés par ces projets. Force est en effet de constater que la mesure du risque avéré se chiffre toujours en cash : projets non aboutis ou aboutis mais remis en question par de nouvelles orientations stratégiques, investissements significatifs jamais ou peu rentabilisés, impact sur le compte de résultat ou éventuellement sur les capitaux propres…
Rapide état des lieux des facteurs de risque en gestion de projet
Lorsque la décision de s'engager est prise, tout projet informatique d’envergure embarque une part d’inconnu, quel que soit le niveau de qualité des études préalables. Cela s’explique, par la complexité des composantes :
- fonctionnelles : concernant le périmètre, les besoins étant de plus en plus nombreux et complexes à formaliser, le cahier des charges est-il complet ? Les principes structurants, fonctionnels, techniques, mais également d’architecture sont-ils bien établis et validés par tous les acteurs ?
- de budget et de planification : les charges sont-elles correctement estimées ? sur- ou sous- dimensionnées et à quelle hauteur ? Quel est l’impact sur l’estimation des coûts ? Le budget est-il réaliste ? Les délais annoncés sont-ils tenables ou trop tendus ? Existe-t-il des interrelations entre projets ? Quelles seraient les conséquences d’un éventuel retard de tel ou tel autre projet lié, du fait des interdépendances existantes ?
- techniques : ici, les risques portent sur la maîtrise des modalités de bascule ou de reprise des données historiques, la qualité des données ou encore la cohérence de leurs traitements avec la déclinaison opérationnelle des processus. Il est également difficile d’estimer dans quelle mesure les plans des tests sont complets et se dérouleront effectivement en amont de la mise en production. L’utilisation de robots est-elle envisagée ? Si un interfaçage est prévu avec un SI plus important, l’environnement cible sera-t-il stable dans le temps ? Quels seront les impacts des modifications portées au SI cible sur le projet en cours ? Enfin, il existe un risque de temps de réponse inadapté, si la puissance des machines d’exploitation allouée au projet et les espaces de travail, les environnements de développement et de recette s’avèrent sous-dimensionnés ;
- en matière de stratégie SI : les questions porteront sur l’architecture, dont il est toujours intéressant de vérifier le bien-fondé et la bonne compréhension, au travers du partage et de la validation par l’ensemble des acteurs, de schémas descriptifs de l’architecture. La pérennité des technologies utilisées et la rationalisation des plates-formes sont toujours susceptibles de remettre en question le projet. Ultime questionnement quant à la vision stratégique du SI, est-elle partagée par les plus hautes instances managériales ?
- sur le choix d’organisation et de méthode : l’organisation interne est-elle suffisamment stable, qui sera le sponsor en interne ? Quels seront ses niveaux d’implication et de disponibilité ? La responsabilité du projet et son pilotage sont-ils confiés à des collaborateurs suffisamment expérimentés, capables de mobiliser les compétences et de partager des niveaux d’expertise pour assurer un bon niveau de transversalité ? Les acteurs ou partenaires du projet disposent-ils des compétences fonctionnelles, techniques et organisationnelles nécessaires ? Sont-ils suffisamment avertis et sensibles à la gestion des hommes, pour garder à leurs côtés des acteurs motivés sur toute la durée du projet ? Quels seront les degrés d’implication et de motivation des utilisateurs finaux au changement ou à la mise en place de nouvelles pratiques opérationnelles ?
Le choix de la méthode de gestion
Tout manquement, tout oubli portant sur le développement de l’un des points énumérés (et cette liste est non exhaustive) sera de nature à générer du risque, de l’inconfort, des régressions fonctionnelles subies plutôt qu’arbitrées, du retard, des coûts et des délais supplémentaires, difficilement acceptables pour le sponsor.
Une première réponse pour y remédier passe par la mise en place d’outils de pilotage des risques.
Ils serviront à référencer et calibrer ces points de vulnérabilité. Les risques verront leurs impacts de survenance estimés, avant d’être pris en charge et traités à la source dans le meilleur cas, acceptés comme tels dans l’autre cas.
Le choix d’une méthode de gestion de projet peut également impacter la maîtrise des risques. Traditionnellement, les projets informatiques sont suivis dans le cadre d’un cycle en V, passant des études d’opportunité et préalables à la définition des besoins, puis aux spécifications générales détaillées, elles-mêmes suivies par les phases de réalisation, de tests unitaires et d’intégration, avant la mise en production. Autant d’étapes qui supposent d’être équipé, en tout début de projet, des capacités de conception détaillée et de formalisation. Or les établissements n’en disposent pas toujours. Ces études demeurent fortement consommatrices de temps. Face à ces limites, un constat se devait d’être fait : chercher à prévoir toutes les actions à mener dans un projet dès le début et dans toutes ses dimensions ne permet pas de réduire les risques ou les écarts entre les attendus et les résultats obtenus.
Une autre réponse consiste en la pratique de la méthode « agile ». Celle-ci considère que la complexité des projets peut se gérer par des avancées « à petits pas », chaque avancée faisant l’objet d’un point sur les résultats, sur les méthodes de travail les plus adaptées pour les obtenir, en collaboration avec les utilisateurs du produit développé. Dans ce nouveau cadre de pensée dit « agile » (mindset, en anglais), la notion de feedback terrain est essentielle, à l'image d'un thermostat qui prend la mesure de la température d’une pièce pour en réguler la chaleur. Les feedbacks réguliers dans un projet mené en mode agile permettent de corriger le tir régulièrement et au plus tôt, par petits pas ou itérations, en adressant progressivement l’ensemble des usages d’un produit, les incréments fonctionnels.
La méthode agile se fonde ainsi sur les postulats suivants (voir Encadré 1) :
- les personnes et leurs interactions sont plus importantes que les processus et les outils ;
- un logiciel opérationnel est plus important qu’une documentation exhaustive ;
- la collaboration avec les clients est préférable à la négociation contractuelle ;
- l’adaptation au changement passe avant le suivi d’un
plan. [1]
La méthode agile en pratique
Un développement agile est avant tout itératif et incrémental (voir Figure 1), alors qu’un planning figé a priori de bout en bout, comme l’impose la pratique des méthodes respectant le cycle en V, ne permet pas de s’adapter aux changements incessants subis par les projets dans toutes les dimensions évoquées précédemment. Les résultats des études du Standish
Par comparaison avec les méthodes classiques, la méthode agile de conduite de projets organise une entrée rapide dans des cycles de développement-livraison, qui se différencie des longues phases de rédaction de cahier des charges, de définition des besoins, des spécifications… Elle suppose l’implication des utilisateurs tout au long du projet, et la réception très tôt des premières fonctionnalités, plutôt que l’attente de la réception d’une livraison globale, par les équipes en fin de projet. Elle prévoit la pratique de tests, unitaires, de non-régression, au fil des développements. Enfin, la documentation intervient a posteriori d’une application, qui fonctionne déjà, plutôt qu’a priori.
Ainsi le travail est organisé en cycles courts, les objectifs sont définis par les usages du produit (user stories) avant le démarrage de chaque cycle, les performances sont mesurées à l’issue de chaque cycle (voir Figure 2). Le cas échéant, la levée des obstacles est systématiquement recherchée.
À chaque itération, les activités classiques d’un projet sont potentiellement toutes appliquées en fonction de l’état d’avancement de ce projet.
La diffusion de la méthode
La méthode agile la plus utilisée dans le monde et en France est la méthode Scrum, signifiant « mêlée » au
Parmi les organisations utilisant une méthode agile, la méthode Scrum est utilisée dans 40 % des cas selon l’étude de la Scrum Alliance de
Le changement de paradigme est en cours : ainsi, les services informatiques de SGCIB, BNP Paribas, ou encore ceux du Centre national des études spatiales (qui présentaient des retours d’expérience lors du dernier
Certaines entreprises en font également une pratique globale au plan de leur gestion. Cette diffusion s’explique par l’internationalisation des pratiques et de la concurrence, avec une attente toujours pressante de retours rapides. Par référence au passé, il apparaît possible, avec cette méthode, de fonctionner sur des budgets informatiques plus faibles et mieux maîtrisés, dans la mesure où des arbitrages sont envisageables en cours de projet, en fonction des priorités de l’entreprise.
Aux États-Unis, en IT, le business en mode agile est devenu une pratique courante (voir ncadré 3). Ainsi 80 à 90 % des annonces de recrutement parues cette année sur ce marché imposent la pratique de l’agilité. Ultime illustration, les fonds d’investissement qui décident aujourd’hui d’évaluer l’intérêt d’investir dans telle ou telle entreprise, font de la pratique de l’agilité une condition de l’expression de leur intérêt. Un message fort s’il en est !
Au-delà de l’IT
La pratique de cette méthode ne s’improvise pas cependant. Comme toute démarche d’amélioration ou de transformation, il convient d’avoir vérifié qu’un certain nombre de conditions initiales sont bien respectées. Elles portent sur :
- la composition des équipes ;
- leur maîtrise technique ;
- le partage des enjeux et des objectifs avec la direction générale, ou la DSI ;
- la fixation du cap ;
- le choix de laisser aux équipes un large niveau d’autonomie et de responsabilité ;
- la capacité de la hiérarchie à intervenir rapidement pour débloquer les éventuels points de frottements entre départements, acteurs internes et externes ;
- un système de motivation et de reconnaissance associé aux niveaux de réactivité et de compétence des ressources nécessaires à la réussite du projet.
Avec ces nouvelles pratiques, les organisations peuvent à nouveau se consacrer aux métiers, à l’ensemble des fonctions de l’entreprise, et se recentrer sur de nouvelles opportunités, libérant énergie, créativité, pour la conquête de nouveaux marchés…
