La direction interministérielle du numérique et du système d’information et de communication de l’Etat (Dinsic) a publié l’ensemble des avis qu’elle a rendu concernant les grands projets du système d’information de l’État.
A partir de ces recommandations, on peut identifier les bonnes pratiques de management des projets, qui s’appliquent d’ailleurs à tous les secteurs. Afin de garantir la conformité des grands projets informatiques de l’État et leur déploiement effectif, tout projet de plus de neuf millions d’euros doit, depuis 2014, être soumis au directeur de la Dinsic, qui formule un avis de conformité ou de non-conformité.
Chaque projet est alors évalué selon cinq axes : stratégie, finances, gouvernance, réalisation et planning. Chaque avis rendu est accompagné de recommandations spécifiant les axes d’amélioration à prendre en compte pour le bon déroulement du projet. Nous avons analysé 41 grands projets publics pour identifier 43 bonnes pratiques, issues des recommandations de la Dinsic, mais qui sont en fait universelles.
Stratégie, conception et cadrage des projets : prendre le temps de la réflexion
- Mettre en place une plateforme ne suffit pas, à elle seule, à la réussite d’un projet : ce n’est pas parce que la notion de plateforme est devenue très à la mode que cela résout les difficultés potentielles d’un projet. Bien au contraire même, car une plateforme, par définition, agrège de multiples usages, des besoins hétérogènes et des parties prenantes qui peuvent ne pas avoir les mêmes objectifs. D’où la nécessité d’être encore plus vigilant.
- Définir le périmètre au regard de la cible et non de l’architecture et des solutions existantes : il est tentant, comme en cuisine, d’utiliser ce qui existe pour concocter un nouveau plat, au lieu de se fixer un repas cible et d’acquérir les ingrédients adaptés. En matière de gestion de projet, c’est l’objectif final qui compte (donc les usages), tant mieux si des applications ou des composants existants font l’affaire.
- Oublier le cadrage fonctionnel et technique global nuit à l’identification des mutualisations possibles et à la maîtrise du SI : pour les systèmes d’information suffisamment matures, avec des périmètres étendus, il est toujours possible de mutualiser, surtout dans le secteur public, avec les contraintes budgétaires et la nécessité d’une bonne gestion des deniers publics. Mais il faut y penser dès le début, au moment de la définition des fonctionnalités. Après, il est souvent trop tard pour mutualiser à moindre coût. Il convient donc de formaliser les dossiers de conception fonctionnelle, applicative et technique en veillant à maximiser le potentiel d’utilisation de briques existantes et la modularité des services proposés aux utilisateurs.
- Imposer des développements spécifiques de bout en bout entraîne une faible modularité de la solution et nécessite la maîtrise des choix fonctionnels et techniques : le succès du cloud et de ses applications en mode SaaS tend à frustrer certains utilisateurs, qui, face à des applications très standardisées, plébiscitent toujours la personnalisation. Mais cette approche, si elle peut se justifier en partie, a un effet pervers : il est souvent très difficile de faire évoluer les fonctionnalités à des coûts raisonnables, sans parler de la difficulté à mobiliser les bonnes compétences quand on en a besoin.
- Expliciter et documenter les choix techniques réalisés, y compris via une rétro-spécification des éléments structurants, il faut pouvoir garantir la réversibilité et l’évolutivité : les choix techniques restent très difficiles car les facteurs de risques sont multiples (manque d’interopérabilité de la technologie, roadmap approximative de l’éditeur, coûts cachés de maintenance, trop forte dépendance vis-à-vis du fournisseur…). La réversibilité doit être privilégiée.
Relations avec les fournisseurs : ne rien lâcher
- Éviter de faire piloter un projet majoritairement par des prestataires : il faut internaliser les compétences clés de pilotage et d’architecture fonctionnelle. Si les prestataires ont la main sur un projet, ils seront tentés d’en profiter. Pas tous et pas de façon brutale, bien sûr, mais il est naturel de privilégier ses intérêts. La vigilance s’impose et commence par une implication au quotidien des équipes internes. Ce qui suppose, au préalable, qu’elles disposent du temps et des compétences nécessaires. La Dinsic suggère ainsi de ne pas dépasser le ratio d’une personne interne pour un prestataire en assistance à maîtrise d’ouvrage et d’une personne interne pour trois prestataires en développement et en intégration.
- Maîtriser les fournisseurs en lotissant les projets : c’est le principe de diversification des risques, mais pas seulement. Il est rare qu’un seul prestataire puisse assurer la réalisation de la totalité d’un projet, il y a forcément des aspects sur lesquels il est moins compétent et/ou moins performant que ses concurrents. Certes, piloter de multiples prestataires est plus complexe, mais le niveau de risque n’est pas le même…
- Mettre en place un outil de pilotage de la qualité des livraisons techniques du fournisseur dès la phase de réalisation : la qualité des prestations externes doit être constante tout au long du cycle de vie du projet. Ce point mérite d’être évalué très régulièrement, afin d’éviter tout relâchement de la part des fournisseurs.
Gestion des ressources et des compétences : improvisation interdite
- Sécuriser la disponibilité des moyens humains (ressources internes et prestataires sur la durée du projet) et financiers : un projet sans financement adapté et sans ressources pour le mettre en œuvre n’ira pas bien loin. Ce principe de bon sens est, hélas, encore trop souvent oublié, toujours pour de bonnes raisons : « On a une grande ambition et peu de moyens, mais on peut réussir quand même », « nos équipes sauront résoudre tous les problèmes », « les consultants coûtent trop cher »…
- Clarifier les prises de décisions aux vues de l’allocation des moyens : même si les moyens humains, technologiques et financiers sont bien dimensionnés, il reste à devoir justifier les choix avec un minimum de transparence. Car il y aura toujours des questions, autant y répondre avec un maximum d’objectivité et de conviction…
- Développer une expertise technico-fonctionnelle au sein d’un centre de compétences : si les volumes de projets le justifient, il est pertinent de mettre en place un centre de compétences pour capitaliser la connaissance et l’expertise. Et cela facilite la mutualisation…
- Ne pas se focaliser excessivement, compte tenu des ressources disponibles, sur les activités opérationnelles par rapport aux autres dimensions du projet (consolidation de la gouvernance, efforts de mutualisation…) : le poids et le rythme du quotidien l’emportent rapidement sur la prise de recul ; entre la gestion de l’urgence et la gouvernance, le choix se porte souvent sur la première. Cela peut se justifier dans certains cas, mais si c’est récurrent, cela dénote une carence dans l’adaptation des ressources.
- Renforcer par une assistance extérieure ne peut pas remplacer les compétences internes nécessaires, surtout lors de la phase critique de conception générale : on retrouve le risque de confier trop de maîtrise à des prestataires, au détriment du contrôle interne des éléments fondamentaux. La conception générale se trouvera biaisée si un ou plusieurs prestataires sont aux commandes.
Intégration et relations avec les métiers : les intérêts mutuels existent toujours
- Aligner la conduite du projet, la réingénierie des processus et l’organisation : dans la mesure où tout projet s’insère dans un existant, une organisation avec ses modes de fonctionnement et des processus plus ou moins optimisés, il doit être aligné. Sinon, on se retrouve avec un projet innovant dans un environnement en décalage ou une organisation trop bureaucratique pour capitaliser sur la valeur créée par ledit projet. Et c’est dommage…
- Renforcer la gestion de projet par une équipe mixte (métier et DSI), couplée à l’adoption d’une feuille de route de la transformation des métiers, afin de permettre une plus grande stabilité et résilience au projet : c’est, là encore, un principe de base pour faciliter l’adhésion des utilisateurs, y compris dans une approche prospective d’évolution des usages.
- Réaliser une étude du cycle de vie des informations et du fonctionnement des principaux cas de gestion qui seront supportés par le SI : la valeur créée dépend en grande partie de la nature des usages et des données sur lesquels ils reposent. L’analyse des cycles de vie devient pertinente car elle peut révéler des usages sous-estimés ou cachés.
- Si toutes les fonctionnalités initialement prévues ne sont pas toutes opérationnelles au moment de la mise en production, prévoir une trajectoire de finalisation clairement définie : il peut arriver que tout ce qui était prévu au début du projet ne puisse être mis en production et livré à temps aux utilisateurs. Dans ce cas, des actions de communication s’imposent avec un planning mis à jour, de manière à éviter un effet tunnel fort préjudiciable. Les DSI n’ont généralement pas besoin de ça…
- Expertiser la mise en place des échanges d’informations avec les autres SI en interface, avec une concertation technique et fonctionnelle entre les différentes parties prenantes : lorsqu’une nouvelle application interagit avec d’autres, existantes, ou échange des informations avec d’autres systèmes d’information, aucune ambiguïté ne doit subsister. Ce qui suppose un travail d’audit et de cartographie des flux, en collaboration avec les métiers pour analyser l’intégration avec les systèmes d’information tiers.
- Stabiliser les points structurants de périmètre fonctionnel cible : si la probabilité qu’un projet dérape est significative, il faut au moins sécuriser ce qui peut l’être, essentiellement les fonctionnalités indispensables, par exemple les 20 % qui contribuent à 80 % de la satisfaction des métiers.
- La trajectoire retenue doit être porteuse de valeur à court terme : différentes raisons expliquent cette divergence de trajectoire, par exemple une dérive des coûts, un changement de prestataire, un turn-over trop important dans les équipes internes et externes, des modifications exigées par les métiers… Il faut identifier au plus vite cette divergence et prioriser les modules fonctionnels pour maximiser la valeur à court terme.
- Garantir la valeur des services numériques à intégrer dans un portail, avec des mécanismes permettant de concevoir, adapter et faire évoluer rapidement ces services : le succès des portails ou des sites de e-commerce reposent sur une appropriation rapide des utilisateurs. Cela demande deux prérequis : d’une part, que les utilisateurs perçoivent une valeur et, d’autre part, qu’ils puissent trouver des services qui s’adaptent à l’évolution de leurs usages. Deux contraintes qui interdisent, de fait, de figer des applications et demandent de privilégier l’amélioration continue.
- Ouvrir l’architecture applicative pour développer de nouveaux usages : des environnements trop fermés, trop propriétaires, ne favorisent guère l’agilité. Et comme on ne peut jamais prévoir l’évolution des usages, autant considérer en amont que ceux-ci vont se transformer très rapidement, avec trois principes clés : interopérabilité (pour reconfigurer le SI), Open Source (pour disposer de compétences) et réutilisation de composants (pour livrer plus vite).
Aspects budgétaires : éviter le piège des coûts cachés
- Optimiser les coûts de fonctionnement de la solution : il convient de prendre en compte les coûts complets, y compris indirects, sur l’ensemble de la durée de vie de la solution, pas seulement les coûts de licences ou de développement. Il y a toujours des sources d’optimisation. • Réaliser une analyse de la valeur du projet et sa rentabilité, avec une analyse fine des coûts, pour faciliter le calibrage fonctionnel technique et économique du SI : c’est là encore une bonne pratique fondamentale de n’importe quel projet IT. Même si la rentabilité est quelquefois difficile à quantifier, par exemple lorsqu’elle se traduit par des améliorations qualitatives qu’on ne peut traduire totalement en valeur monétaire, l’analyse des coûts est, elle, indispensable. Les méthodes existent pour la réaliser.
- Éviter de sous-dimensionner le coût total, par exemple en oubliant le coût des interfaces temporaires pour un fonctionnement hybride, ainsi que le coût du maintien en conditions opérationnelles : les dépassements budgétaires sont monnaie courante (et souvent perdue), tout le monde s’y est habitué, mais ce n’est pas une raison pour les tolérer systématiquement. Il convient de prévoir des provisions pour risques. Si l’on se base sur le taux moyen de dépassement (26,4 % pour les grands projets du secteur public), une proportion de 20 à 25 % du budget semble réaliste.
Migration et déploiements : le plan B en ligne de mire
- Privilégier la reprise des fonctionnalités existantes ne permet pas de s’adapter aux nouveaux besoins métiers : la mise en production d’une nouvelle application doit être l’occasion de s’interroger sur les usages des fonctionnalités de l’ancien système. Cela évite de reprendre celles qui ne sont pas ou peu utilisées. Mieux vaut être impopulaire vis-à-vis d’une minorité d’utilisateurs plutôt que de construire un système trop complexe, obèse de fonctionnalités inutiles « parce qu’on les a toujours eues et qu’il n’y a pas de raison que ça change… ».
- Sécuriser le décommissionnement des applications : lors de la migration vers une nouvelle application, se pose le problème de l’arrêt de celle(s) qu’elle remplace. Avec deux choix : faire durer et exploiter anciens et nouveaux systèmes en parallèle, ou arrêter au plus vite pour provoquer une rupture dans les habitudes des utilisateurs. Dans les deux cas, il faut sécuriser l’opération, surtout en cas de remplacement dans des délais très courts, voulus ou contraints.
- Déployer en paliers interdépendants expose au risque que tout retard sur un palier conduise à un report du calendrier des paliers ultérieurs : c’est le principe des dominos ou des effets en chaîne. Un compartimentage, lorsque cela est possible, permet de limiter les risques sur les délais, toujours du plus mauvais effet pour l’image des équipes qui en sont responsables.
- Lancer trop de chantiers en parallèle entraîne un risque, pour les équipes de développement, au moment de la réalisation, de se heurter au nombre et à la complexité des chantiers, malgré les compétences et l’implication des équipes : on retrouve un effet cumulatif lié à la complexité. Il y a un seuil, hélas impossible à déterminer a priori, à partir duquel la complexité n’est plus maîtrisable.
Pilotage : conserver le cap
- Sécuriser le pilotage en s’attachant, avant de le début de la réalisation, à préciser la gouvernance et l’organisation du projet, fiabiliser le calendrier et réévaluer les éléments de coûts : sans définition préalable des responsabilités de chaque partie prenante, du timing et de qui dépense quoi, il est quasiment impossible d’organiser un pilotage de projet digne de ce nom. S’il est partiel, il ne sert à rien, et surtout pas à anticiper les risques de dérives.
- Maîtriser la réalisation de la solution en ne laissant pas les prestataires porter l’architecture fonctionnelle applicative et technique du projet, notamment en termes de découpage des développements, de définition des modules et des choix technologiques : laisser les prestataires concevoir, décider et piloter constitue une triple peine pour les DSI. A moins de tomber sur un fournisseur très doué en tout et qui ne pense qu’à l’intérêt de son client, ce qui est, reconnaissons-le, assez rare…
- Disposer d’un outil permettant de qualifier précisément le risque réel du projet, à défaut de tableau de bord pour piloter par les délais l’ensemble des sous-projets : l’anticipation des signaux faibles liés aux possibles dérives de projets est bien utile. Une véritable gestion des risques est indispensable, mais on retrouve, hélas, deux situations : d’une part, le fait de considérer qu’un risque est tellement peu probable qu’il n’est pas utile de s’en préoccuper. D’autre part, le fait de se dire que si un risque survient, il pourra toujours être contenu et que les dégâts ne seront pas si importants… Une double erreur d’analyse qui peut coûter très cher !
Gestion des risques : toujours explorer l’improbable
- Sécuriser les travaux de conception et de reprise des données afin de ne pas impacter négativement le calendrier du projet et la qualité : il est toujours désagréable de découvrir que la qualité des données, au moment de leur reprise, n’est pas à la hauteur et qu’il faut consacrer du temps supplémentaire pour les modifier. On imagine facilement que le calendrier de déploiement ou de migration s’en trouvera affecté.
- Sécuriser la maintenabilité du système d’information : que se passe-t-il lorsque l’on oublie qu’une application doit être maintenue tout au long de son cycle de vie ? Des surcoûts qu’il faudra bien financer. Comme l’acheteur d’un appartement qui oublie qu’il aura des charges à payer pour maintenir son bien en état. La sécurisation de la maintenabilité concerne à la fois les aspects financiers, mais aussi technologiques, et les ressources, internes ou externes.
- Identifier et centraliser, grâce à une cartographie, tous les risques susceptibles d’affecter la valeur, avec un plan d’action et de qualification du risque résiduel : le seul moyen de maîtriser les risques est de les connaître et d’en identifier la potentialité et la gravité. Avec une cartographie, des scénarios et un plan d’action.
- Coupler une organisation complexe à l’absence de direction du programme risque de paralyser sa gouvernance : il est certain que si personne ne sait où il va et qu’il n’y a personne pour prendre les commandes, le projet ira dans le mur.
- Gérer plusieurs projets en parallèle nécessite de clarifier l’articulation entre eux et de limiter les adhérences (terminologie commune, description claire des étapes, calendrier global) : il est fortement déconseillé de mener de front plusieurs projets d’envergure, surtout s’il apparaît que des interdépendances sont susceptibles de créer des perturbations. Si les adhérences ne sont pas mesurées, elles risquent de freiner l’efficience des déploiements.
Gestion des délais : pas de place pour l’approximation
- Éviter des délais trop longs pour des projets censés combler une obsolescence technique : lorsqu’il faut moderniser une application pour des raisons liées à l’obsolescence des technologies, le pilotage par les délais s’impose. Encore faut-il avoir une bonne vision de la nature de l’obsolescence, de son degré de « gravité » pour les utilisateurs et des coûts de migration.
- Préciser les jalons intermédiaires et l’échelonnement des fonctionnalités : le timing de développement et de mise en production d’une application doit être associé à un cadencement précis. Il y a trois avantages : d’abord, cela facilite la communication au sein des équipes et vers les métiers ; ensuite, on évite les embouteillages, lorsque trop de fonctionnalités sont à livrer en même temps ; enfin, cela sécurise l’ensemble du projet en minimisant les dépassements de délais.
- Sécuriser le calendrier en vérifiant que les durées des chantiers sont réalistes et itérer régulièrement le calendrier en fonction des résultats : il ne sert à rien de prévoir des délais trop courts, qui ne seront jamais tenus, tout le monde le sait, ni des délais trop longs, au risque d’avoir un effet tunnel et une impatience des métiers.
Gouvernance : une opération de maintien de l’ordre
- Mettre en œuvre une gouvernance technique centralisée et définir un service de bout en bout cohérent pour l’utilisateur : la cohérence technique est essentielle pour assurer une fluidité dans les usages, surtout pour les projets très structurants et orientés vers les consommateurs.
- Aligner l’organisation projet avec la méthodologie agile, lorsque celle-ci est privilégiée : la gouvernance et l’organisation du projet doivent permettre d’assurer des prises de décision rapides et réactives, ce qui n’est pas possible si une organisation peu flexible doit coexister avec une volonté de privilégier les méthodes agiles.
- Privilégier des convergences méthodologiques et techniques, avec des pôles de compétences et une gouvernance transversale, par exemple pour le choix des solutions applicatives et l’architecture technique : c’est, là aussi, une question de cohérence, diversifier les méthodologies coûte cher (parce qu’il faut les maîtriser), de même que privilégier les technologies hétérogènes. Si, en plus, la gouvernance s’avère bancale, le projet court à l’échec, avec des surcoûts, des délais dépassés et une maintenabilité aléatoire.
Les cinq mythes du management de projet1
Un projet peut être implémenté rapidement, pour pas cher et facilement.
La conduite du changement, la formation et la communication ne constituent pas des challenges.
Il suffit de confier le projet à des consultants, des éditeurs ou des intégrateurs.
Il n’y a pas besoin de documenter les processus existants.
La duplication des bonnes pratiques rend l’implémentation plus facile.
Source : « Top Five Urban Myths of Digital Transformation Initiatives », Panorama Consulting.
Gestion de projet : les erreurs les plus fréquentes
Le manque d’identification du périmètre complet du projet.
L’incapacité à définir clairement les objectifs.
L’impossibilité de tenir les délais.
La confusion ou le mauvais alignement avec les priorités du projet.
De mauvaises définitions et répartition des responsabilités entre les membres de l’équipe projet.
L’incapacité de conserver une visibilité sur les budgets.
La mauvaise préparation des chefs de projets pour affronter les difficultés ou les conflits.
Source : Project management : how to survive deadlines, remote teams & inadequate communication, Mavenlink.
Les principales causes de contre-performance des projets
Les spécificités n’ont pas été correctement définies en amont (51 % des échecs).
Des changements sont intervenus après le démarrage du projet (35 %).
Du temps a été perdu dans les processus de prises de décision (21 %).
Les ressources humaines affectées au projet ont été insuffisantes (20 %).
Les responsabilités et le sponsoring n’ont pas été suffisamment définis (17 %).
Source : Innovation management : how leaders outperform their peers, Aberdeen Group.
