Quand une organisation adopte HERMES, la méthode suisse officielle de gestion de projet, elle ne met pas seulement en place une séquence de phases. Elle instaure un système de gouvernance complet, avec des rôles précis, des circuits de décision formalisés et un partage des responsabilités qui laisse peu de place à l’ambiguïté. Cette rigueur constitue la principale force de la méthode, mais aussi la source de la plupart des résistances qu’elle suscite.
Un modèle à trois niveaux hiérarchiques
HERMES structure ses rôles sur trois niveaux distincts qui séparent clairement les responsabilités de pilotage, de gestion et d’exécution.
Au niveau de pilotage, le mandant (équivalent du sponsor dans d’autres référentiels) porte la responsabilité globale du projet. Il est assisté par le comité de pilotage, qui valide les jalons et prend les décisions de poursuite, de réorientation ou d’arrêt du projet. Un responsable qualité et risques complète ce niveau en apportant une perspective indépendante sur la maîtrise des risques.
Au niveau de gestion, le chef de projet coordonne l’ensemble des activités, gère les ressources et rend compte au comité de pilotage. Il peut être assisté par des chefs de sous-projets et une structure de support projet. Un comité technique intervient pour les arbitrages à caractère spécialisé lorsque le projet le justifie.
Au niveau d’exécution, les rôles se spécialisent: représentant des utilisateurs, responsable d’exploitation, analyste métier (business analyst, soit le spécialiste qui traduit les besoins métier en exigences formalisées), développeur, architecte IT, testeur, responsable de la sécurité de l’information. Chaque rôle est documenté avec ses responsabilités, ses compétences requises et ses livrables attendus.
Pourquoi cette séparation est-elle importante?
Dans les référentiels comme le PMBOK du PMI, les rôles sont décrits de manière générique et leur instanciation est laissée à l’organisation. HERMES adopte l’approche inverse: la méthode prescrit qui décide quoi à chaque jalon, et cette prescription est suffisamment détaillée pour qu’un auditeur puisse vérifier, a posteriori, si le processus de décision a été respecté.
Cette traçabilité n’est pas un luxe bureaucratique. Dans le contexte de l’administration publique suisse, où les projets sont financés par les contribuables et soumis au contrôle du Contrôle fédéral des finances, pouvoir démontrer que chaque décision a été prise par l’instance compétente est une exigence légale autant qu’une bonne pratique.
Les tâches décisionnelles: colonne vertébrale de la gouvernance
Parmi les tâches que HERMES définit, 16 sont qualifiées de “décisionnelles”. Ce sont les moments où un organe de gouvernance (généralement le comité de pilotage ou le mandant) doit formellement approuver un livrable ou valider le passage à une étape suivante.
Ces tâches décisionnelles fonctionnent comme des points de contrôle systématiques. À la fin de la phase d’initialisation, par exemple, le comité de pilotage examine la charte de projet, le plan de gestion et l’analyse de faisabilité avant de libérer les ressources pour la phase suivante. Chaque décision est documentée et associée à un statut parmi les 22 que la méthode prédéfinit (“projet approuvé”, “concept validé”, “exploitation activée”, entre autres).
Ce mécanisme de jalons décisionnels n’est pas propre à HERMES: PRINCE2 repose sur un principe similaire avec ses “stage gates”. La particularité de HERMES est d’avoir standardisé non seulement les points de décision, mais aussi les documents qui les alimentent. Avec 55 modèles couvrant l’intégralité du cycle de vie, de la demande initiale au bilan de clôture, la méthode fournit un cadre documentaire prêt à l’emploi.
Le chef de projet HERMES: un rôle encadré
Le chef de projet HERMES opère dans un cadre plus contraint que dans beaucoup d’autres méthodologies. Sa marge de manœuvre est définie par les tolérances (de coût, de délai, de périmètre) que lui accorde le comité de pilotage. Au-delà de ces tolérances, il doit escalader la décision. Ce principe de gestion par exception, partagé avec PRINCE2, évite que le comité de pilotage ne soit sollicité pour chaque décision opérationnelle tout en garantissant son intervention quand les écarts deviennent significatifs.
En pratique, cette structure exige du chef de projet une double compétence: la maîtrise technique de la gestion de projet (planification, suivi, reporting) et la capacité à naviguer dans une structure de gouvernance formalisée. Un praticien habitué à des environnements plus informels peut trouver cette formalisation contraignante, mais pour quiconque a vécu un projet où personne ne savait qui avait le pouvoir de décider, la clarté de HERMES a une valeur immédiate.
Comment le sizing adapte les rôles au projet
HERMES prévoit une vingtaine de rôles, mais tous ne sont pas mobilisés sur chaque projet. Le mécanisme de sizing permet d’ajuster le dispositif à la taille de l’initiative. Sur un petit projet, une même personne peut cumuler plusieurs rôles: le mandant peut aussi présider le comité de pilotage, le chef de projet peut assurer le support projet. Sur un programme complexe, chaque rôle sera tenu par une personne distincte, voire par plusieurs personnes.
Cette flexibilité dans l’instanciation des rôles est documentée dans les scénarios de la méthode. Chacun des cinq scénarios standards (développement de service, adaptation IT, adaptation organisationnelle, entre autres) précise les rôles pertinents et leur niveau d’implication attendu, ce qui fournit un point de départ concret pour dimensionner l’équipe de projet.
Gouvernance et agilité: le compromis de HERMES 2022
L’introduction du modèle agile dans HERMES 2022 a posé un défi de gouvernance: comment maintenir les jalons décisionnels et la traçabilité des décisions dans un cadre itératif où le périmètre évolue en continu?
La réponse de HERMES est pragmatique. Les jalons de gouvernance (décisions du comité de pilotage) subsistent, mais le rythme et le contenu des livrables entre ces jalons sont déterminés par l’équipe selon des cycles courts. Le mandant et le comité de pilotage conservent leur rôle de validation stratégique, tandis que l’équipe d’exécution gagne en autonomie sur la manière de produire les livrables, tout en restant redevable sur le périmètre et le budget.
Ce compromis ne satisfait pas les puristes de l’agilité, qui y voient une contrainte bureaucratique sur l’auto-organisation de l’équipe, ni les tenants de la gouvernance stricte, qui craignent une perte de contrôle dans les phases itératives. Il reflète cependant la réalité de la plupart des projets en contexte institutionnel, où l’agilité totale est rarement possible et la rigidité totale rarement souhaitable.