Quand une organisation doit choisir un référentiel de gestion de projet, trois noms reviennent systématiquement: PMBOK, PRINCE2 et, en Suisse, HERMES. Les deux premiers sont des standards internationaux, largement documentés et adossés à des systèmes de certification reconnus. Le troisième est le standard national suisse, moins visible à l’étranger mais obligatoire pour tout projet IT de la Confédération. Comparer ces trois approches révèle des choix philosophiques très différents sur ce qu’un référentiel de projet doit couvrir, et sur ce qu’il choisit délibérément de laisser de côté.
PMBOK: un catalogue de bonnes pratiques
Le PMBOK Guide (Project Management Body of Knowledge) de PMI organise les connaissances en gestion de projet autour de dix domaines: périmètre, calendrier, coûts, qualité, ressources, communication, risques, approvisionnements, parties prenantes et intégration. Sa 7e édition a marqué une évolution notable en passant d’une logique de processus prescriptifs à une approche par principes, plus adaptable aux différents contextes organisationnels et sectoriels.
Sa force reste sa généralité: le PMBOK est applicable à tout secteur et tout type de projet, de la construction à la transformation numérique. Son angle mort est symétrique: le guide ne dit rien sur la façon dont le produit est conçu, développé ou déployé. La planification du travail technique, les méthodes de développement et les livrables d’exécution restent en dehors de son périmètre, quel que soit le domaine d’activité.
PRINCE2: la gouvernance comme priorité
PRINCE2 (Projects IN Controlled Environments) structure le projet autour de sept principes, sept thèmes et sept processus. Son architecture est centrée sur la justification business continue et la prise de décision par étapes. Le comité de pilotage joue un rôle central, chaque étape de management se terminant par une décision explicite de poursuivre, d’ajuster ou d’arrêter le projet.
Comme le PMBOK, PRINCE2 gère le projet, pas le contenu technique. La méthode assume explicitement que l’organisation dispose de ses propres pratiques pour le développement du produit, que ce soit du logiciel, une infrastructure ou un processus organisationnel. Le chef de projet orchestre les séquences de travail, contrôle les tolérances et rend compte au comité de pilotage, mais le “comment” technique n’entre pas dans le périmètre de la méthode.
HERMES: le projet et son contenu dans un même cadre
HERMES prend une direction fondamentalement différente. Développée dès 1975 pour les centres informatiques de l’administration fédérale suisse, la méthode intègre dès l’origine les activités de gestion de projet et les activités techniques dans un même plan de structure de travail (Arbeitsstrukturplan).
Le WBS (Work Breakdown Structure, la décomposition hiérarchique du travail en livrables) de HERMES ne se limite pas aux livrables de pilotage. Il inclut les résultats techniques: spécifications fonctionnelles, architecture du système, tests d’intégration, migration de données, formation des utilisateurs. Chaque résultat est associé à un rôle responsable, à des tâches décrites et à un point de décision formel dans le modèle de phases.
Cette intégration repose sur un système de scénarios. Au lieu d’un processus unique que chaque organisation doit adapter à son contexte (le “tailoring” que PMBOK et PRINCE2 laissent à la charge du chef de projet), HERMES fournit des scénarios prédéfinis selon la nature du travail: développement de systèmes, adaptation de systèmes existants, développement organisationnel ou développement de services. Chaque scénario embarque son propre modèle de phases, soit cinq phases pour l’approche traditionnelle (initialisation, conception, réalisation, déploiement, clôture), soit trois pour l’approche agile (initialisation, exécution, clôture).
Qu’est-ce que cette intégration change en pratique?
Pour un chef de projet habitué à PMBOK ou PRINCE2, piloter un projet HERMES modifie le rapport au travail technique de l’équipe. La méthode ne permet pas de se cantonner au suivi des délais et des coûts tout en déléguant intégralement le contenu technique à un responsable d’équipe. Les résultats techniques font partie du plan de projet au même titre que les livrables de gouvernance, avec leurs jalons et leurs critères de validation.
L’avantage est une meilleure visibilité: le chef de projet sait structurellement quels livrables techniques sont attendus à chaque phase et quels rôles en sont responsables. Le risque de décalage entre le plan de management et la réalité du développement diminue, parce que les deux partagent le même cadre de suivi et les mêmes points de décision.
La contrepartie est une exigence de compréhension technique plus élevée. Le chef de projet HERMES ne peut pas être un pur coordinateur administratif: il doit comprendre suffisamment le contenu des résultats techniques pour piloter leur avancement et évaluer leur qualité lors des jalons. Dans un environnement PMBOK ou PRINCE2, cette compétence est souhaitable; dans HERMES, elle est structurellement requise par la méthode elle-même.
Un standard ouvert dans un marché de certifications
HERMES est un standard ouvert et gratuit, publié par la Confédération suisse. Templates, descriptions de rôles, checklists et générateur de scénarios en ligne sont accessibles sans licence ni abonnement, ce qui contraste avec l’écosystème payant qui entoure PMBOK et PRINCE2.
Son adoption dépasse l’administration fédérale: cantons, communes, hôpitaux universitaires, assurances et certaines entreprises privées l’utilisent. Sa reconnaissance reste cependant essentiellement suisse, ce qui limite sa portabilité pour un chef de projet actif à l’international. Pour les praticiens qui découvrent HERMES après une formation PMBOK ou PRINCE2, l’essentiel est de comprendre cette différence d’approche: là où les référentiels internationaux séparent gestion et exécution technique, HERMES les réunit dans un cadre unique qui exige du chef de projet une implication plus directe dans le contenu du travail.